From poelstra at redhat.com Thu Oct 1 00:10:42 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 30 Sep 2009 17:10:42 -0700 Subject: Final Review of Incomplete Fedora 12 Features Message-ID: <4AC3F382.7020207@redhat.com> Hi FESCo, With the passing of Beta Freeze we are now at the point in our release process where we expect all features to be at 100% completion. After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status. https://www.redhat.com/archives/fedora-devel-announce/2009-September/msg00008.html https://fedoraproject.org/wiki/Features/DisplayPort https://fedoraproject.org/wiki/Features/LowerProcessCapabilities https://fedoraproject.org/wiki/Features/NFSv4Default In accordance with our recorded policy of requiring that all features be at 100% at Beta Freeze, I am proposing these features for your review to determine what their disposition should be. https://fedoraproject.org/wiki/Features/Policy/Dropping Thank you, John p.s. I'm going based solely on the information on the feature page. p.s.s. Feature owners are also being bcc'd on this message and a copy is also being sent to fedora-devel-announce. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jgarzik at pobox.com Thu Oct 1 00:26:09 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Wed, 30 Sep 2009 20:26:09 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <1254353321.2242.34.camel@localhost.localdomain> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> Message-ID: <4AC3F721.7020605@pobox.com> On 09/30/2009 07:28 PM, Jesse Keating wrote: > On Wed, 2009-09-30 at 18:55 -0400, Jeff Garzik wrote: >> Both ppc and ppc64 have been excellent at catching software bugs in my >> projects that long went unnoticed on i386/x86-64. >> >> The lack of big endian builds by default is a notable loss, and will >> lead to a decline in software quality. >> >> I think this is a net-negative for Fedora. >> > > Builds will still be done on ppc32/ppc64 as part of the secondary arch > effort. Of course, there will still be an extremely small amount of > people who test those builds and can help fix things. Are you willing > to be one of those people since you find value in it? Helping to ensure > ppc remains a successful secondary arch is the best thing you can do to > help. I would rather the problem be approached in a logical, scalable fashion: by distributing the workload across the package maintainers who have firsthand knowledge. ie. how things worked before. But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M > N by orders of magnitude. Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated an ability to detect problems not found on LE, it seems like this policy change will directly lead to missed bugs, and an attendent decline in software quality. Was ppc really such a burden? Jeff From petersen at redhat.com Thu Oct 1 00:38:36 2009 From: petersen at redhat.com (Jens Petersen) Date: Wed, 30 Sep 2009 20:38:36 -0400 (EDT) Subject: bitmap-fonts by default? In-Reply-To: Message-ID: <1399102181.839471254357516591.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > IMHO default packages in default groups should have a clear user, or > be downgraded to optional. Right I suggest we make it optional in comps-f13 and see if anything "breaks". Jens From jkeating at redhat.com Thu Oct 1 00:47:15 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 Sep 2009 17:47:15 -0700 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <4AC3F721.7020605@pobox.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: <1254358035.2242.41.camel@localhost.localdomain> On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: > Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Thu Oct 1 00:58:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 02:58:15 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: Jeff Garzik wrote: > I would rather the problem be approached in a logical, scalable fashion: > by distributing the workload across the package maintainers who have > firsthand knowledge. ie. how things worked before. > > But you're dodging the larger point -- Fedora has, de facto, demoted big > endian support in its entirety to a second-hand effort, rather than > distributed the workload much more widely. Given M package maintainers > and N secondary-platform volunteers, it is clear M > N by orders of > magnitude. I think it is only fair that the people who actually care get to do the work. Package maintainers can still fix their packages for PPC, they'll even get e-mail reports from the secondary arch Koji if the builds fail. (It already happens for the other secondary architectures.) They just won't be required to do it anymore. You can't force volunteers (and many Fedora developers are volunteers; even those paid by RH are paid primarily to work on RHEL, not Fedora, and often do Fedora work in their own free time) to work on something they're not interested in. > Was ppc really such a burden? Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages. In fact, my "favorite" ppc64 issue was a problem with OpenBabel hitting a limitation in the ppc64 toolchain: there's a "table of contents" which can grow only to a small fixed size, so large compilation units just don't compile on ppc64, while being perfectly valid C/C++ and compiling fine on all other architectures. (And that's already with the "minimal TOC". Without it, the limit is for the whole executable!) OpenBabel's SWIG-generated bindings exceeded that limit. We were the only ones hitting it as no other distribution is insane enough to build their packages for ppc64. (The binaries don't even get actually used as ppc32 is the preferred multilib on 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce the amount of TOC entries, which worked for 2 beta releases (requiring additional tweaking for the second one), but then it overflowed again. This was a big annoyance because the new OpenBabel betas were required for new kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream removed some things from their bindings to get them to build, a quite suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs to be redesigned from scratch. Kevin Kofler From MathStuf at gmail.com Thu Oct 1 01:02:13 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 30 Sep 2009 21:02:13 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeff Garzik wrote: > I would rather the problem be approached in a logical, scalable fashion: > by distributing the workload across the package maintainers who have > firsthand knowledge. ie. how things worked before. PPC hardware isn't exactly common these days. I'm sure there are a few machines on campus that have PPC (there are definitely SPARC workstations sprinkled around). As it stands, I have no useful access to any of the machines (I guess a Live CD could get some special access, though at what cost to my status as a student, I don't know). > But you're dodging the larger point -- Fedora has, de facto, demoted big > endian support in its entirety to a second-hand effort, rather than > distributed the workload much more widely. Given M package maintainers > and N secondary-platform volunteers, it is clear M > N by orders of > magnitude. > > Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated > an ability to detect problems not found on LE, it seems like this policy > change will directly lead to missed bugs, and an attendent decline in > software quality. > > Was ppc really such a burden? > > Jeff Build times were the worst part of it IMO. With how it was set up (ppc being default even on ppc64) ppc64 could have been dropped and ppc be left intact. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKw/+VAAoJEKaxavVX4C1XccEP/RwHvNRhDexa5klFpl3mDvlQ pFLpT2OogtNWT58RuxvyOIlQMHs8NJbWdu+cjBYxav70Uhk2a7zqCN8g+ExJz0YM QSRd8HVyNTglOOT9kVLpQR9JM9E7gehnqTbDUY3l7kb9It02oQ8xf08M7Z+UNwgB FRFcXRQRZ8m8PfkOpTAEFlwXccRuyYQcm1CgvVX52NMVma32FxkFWxfBfBEL4vkH lfSeuU1z6bzKsHbUOFV0qBcteDYRRE7UjG698qlFJY2PCu5mSZzwt8QQiiXaqemS oYRDvXxoLEL6xHVlwboYAbT5ej/Gt51EOzlH6GMinLaJCfXwbe4Eb1hkpS09p4k4 rB4ttazM5rl1SEYuXP318X0qHguhNjZeFvg4NPuep+Xbk1uy2cKDFygk5XDxgsH+ sJxGnsv09f6An7+y2seK+P9TviIr1g2SqeebaZeK2lOCIOBU0Ip7aXVM0A0/tNK8 By0qZOfOjhYoac5FvXTuJUU3+Zh7SZDxexwnsfUM8gyIMRllDMpIwp2tfqQHY6wJ AwuNoCPTchqXzr+WE24Y/9QX2Merbj0AooKzIFuHIAtpC/usD2/bggvVYiq1PM+k frIuFJmugcsMt6Yool6Sl7kJqFW4nin5xUdbPJuY6UQP+6x7oouV53WMsVFtW5zk fBXSd9Rm2dMgiXQp/2JR =MGWo -----END PGP SIGNATURE----- From trever.adams at gmail.com Thu Oct 1 01:04:40 2009 From: trever.adams at gmail.com (Trever L. Adams) Date: Wed, 30 Sep 2009 19:04:40 -0600 Subject: CalDAV Calendar (BedeWork) Message-ID: <4AC40028.1000600@gmail.com> Hello all, About a year ago, I suggested that BedeWork (http://bedework.org) be included. I offered to package it with some help. I unfortunately ran out of time. I now have time to package it and hopefully maintain the package. Unfortunately, I haven't written an Java code in a decade or so. I have never messed with Java packages. The problems I have: This package has a bunch of property files that you have to edit before you build the program. (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18) These include database names, locations, user/passwords for the database, etc. I do not know if this is normal or not. I do not know how to package this, how to suggest people customize this information, etc. This program also requires JBoss or Tomcat (maybe there are others that will work). Since I do not see JBoss in Fedora, Tomcat would be fine. I have not experience with this. It would be nice if a Tomcat person can help me with documentation on how to get this working and to use AD (Kerberos [SPNEGO/GSSAPI] and LDAP) for the authentication and user/group information as well. I have a few packages that I have not yet submitted that I have packaged. These include PyKota (and its dependencies), DSPAM, and C-ICAP (not yet ready as I have some code I am writing that will be turned over before I submit this package). I have no clue about any of the build systems in Fedora, so I will need help with this as well. I know that F12 is closed for this, but I could get it ready for F13. Thank you, Trever -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Thu Oct 1 01:02:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 03:02:04 +0200 Subject: [KDE] Which Phonon? Phonon backend - GStreamer or Xine? References: <200909291703.55030.jreznik@redhat.com> <20090930161033.GD16459@tango.0pointer.de> <200909302007.38047.jreznik@redhat.com> Message-ID: Jaroslav Reznik wrote: > That's not about "standardize on GTK+" That was just an example of how "one size fits it all" doesn't always work when it comes to libraries, there will always be more than one library for some purposes. > We should choose better technology over politics. That's exactly why I voted for Phonon-Xine in the meeting. ;-) "All the world must use GStreamer" == politics Phonon-Xine is considered by Phonon upstream to be the better technology. Kevin Kofler From kevin.kofler at chello.at Thu Oct 1 01:37:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 03:37:42 +0200 Subject: Buyer Beware: A Major Change in NFS is about to happen References: <4AC27D1B.4010803@RedHat.com> <1254260591.2303.20.camel@localhost.localdomain> <4AC281A0.2090009@RedHat.com> <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <1254293108.2242.17.camel@localhost.localdomain> <1254335788.2242.27.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > This isn't a post-facto justification. The only "one-off" for F12 was > the removal of the milestone previously known as alpha. Making the renaming a one-time-only change as I'm proposing would be "post facto". > The rest of the milestone adjustment proposal came out of the Fedora > Activity day, had lots of time to be communicated, discussed, and voted on > by the community at large, FESCo specifically. I don't remember FESCo ever voting on that issue and I can't find it in the meeting summaries either (and I also checked the ones from before I joined, back to April). AFAIK, this was just posted to the fedora-devel-list for feedback, got almost none, which was taken by you as "everyone is fine with it" (whereas I think most people probably just ignored it as "yet another wacky proposal which is never going to get implemented sent to fedora-devel- list") and a few days later it was a rel-eng decision. (I remember having been really surprised by this having been implemented ("Huh, there's a F12 Alpha now?"), given that there was no consensus at all on the mailing list.) I don't doubt there was some in-person discussion at the FAD, but that will never be as inclusive as a mailing list discussion (which never happened because a huge list of "brainstorming results" (which turned out to actually mean "almost decided items", which also wasn't clear from the wording or you might have gotten more objections) was dumped onto the mailing list in one e-mail). I think a small circle of people flying to some location to make lots of decisions in person in one day is really bad for transparency in an international project like ours. Ideas really need to be sent one at a time to the public mailing lists. And there's an additional important point: we have additional evidence now that the renames were harmful! So, independently from how the decision was originally achieved, we should revisit it now based on the new evidence. Back when the renames were proposed, I didn't quite see the point, but I didn't think it'd be a big issue either. But as time has progressed, I have seen many developers come to FESCo with things like "oh, I was supposed to have this feature ready for Alpha? I thought it was Beta as always!". These renames turned out to have produced lots of lateness in the feature process, and Fedora development as a whole. So I'm now proposing to solve this problem by restoring the names people are used to. I think having our developers deliver on time is much more important than using pedantically "correct" names which lost most of their meaning anyway ("beta" can be everything from unusable pre-alpha code to Google's "betas" these days) in end-user communication. Those users are going to be the ones hurt the most by buggy, incomplete or entirely missing features, so having the milestone names make sense for developers is also what's most important for THEM. > I'm really not in favor of changing it again. A group of developers, > release engineers, and QA folks brainstormed on fixing the milestone > issues and what we have now is the product of that effort. If you > really think it wasn't for the eventual better, float your own proposal > and get approval from developers, release engineers, QA folks, and > eventually FESCo. My proposal is plain and simple: go back to the 3 milestones and their naming from F11. It worked and developers all knew what the milestones corresponded to. The change was completely unnecessary and just caused confusion. Kevin Kofler From kevin.kofler at chello.at Thu Oct 1 01:45:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 03:45:04 +0200 Subject: CalDAV Calendar (BedeWork) References: <4AC40028.1000600@gmail.com> Message-ID: Trever L. Adams wrote: > I know that F12 is closed for this, but I could get it ready for F13. Actually, new packages can be pushed as updates. You can add them even to F11, and F10 if you're really quick (new packages are accepted in F10 until 1 month before its end of life, which is basically the day of F12's release, as the end of life for Fedora n is 1 month after Fedora n+2's release). Kevin Kofler From jwboyer at gmail.com Thu Oct 1 02:19:39 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 30 Sep 2009 22:19:39 -0400 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <1254293108.2242.17.camel@localhost.localdomain> <1254335788.2242.27.camel@localhost.localdomain> Message-ID: <20091001021938.GW5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 03:37:42AM +0200, Kevin Kofler wrote: >Jesse Keating wrote: >> This isn't a post-facto justification. The only "one-off" for F12 was >> the removal of the milestone previously known as alpha. > >Making the renaming a one-time-only change as I'm proposing would be "post >facto". > >> The rest of the milestone adjustment proposal came out of the Fedora >> Activity day, had lots of time to be communicated, discussed, and voted on >> by the community at large, FESCo specifically. > >I don't remember FESCo ever voting on that issue and I can't find it in the >meeting summaries either (and I also checked the ones from before I joined, http://meetbot.fedoraproject.org/fedora-meeting/2009-06-12/fedora-meeting.2009-06-12-17.01.html https://fedorahosted.org/fesco/ticket/162 >back to April). AFAIK, this was just posted to the fedora-devel-list for >feedback, got almost none, which was taken by you as "everyone is fine with >it" (whereas I think most people probably just ignored it as "yet another >wacky proposal which is never going to get implemented sent to fedora-devel- >list") and a few days later it was a rel-eng decision. (I remember having https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00714.html https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal >been really surprised by this having been implemented ("Huh, there's a F12 >Alpha now?"), given that there was no consensus at all on the mailing list.) > >I don't doubt there was some in-person discussion at the FAD, but that will >never be as inclusive as a mailing list discussion (which never happened >because a huge list of "brainstorming results" (which turned out to actually >mean "almost decided items", which also wasn't clear from the wording or you >might have gotten more objections) was dumped onto the mailing list in one >e-mail). I think a small circle of people flying to some location to make >lots of decisions in person in one day is really bad for transparency in an >international project like ours. Ideas really need to be sent one at a time >to the public mailing lists. This is utter fucking bullshit. Nobody went off and decided. We made a very large point of NOT just changing stuff and we posted every single proposal that came out of that FAD. Some of them were approved, some of them are still pending. NONE of them were just changed without going through FESCo. josh From tgl at redhat.com Thu Oct 1 03:12:37 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 30 Sep 2009 23:12:37 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: <8010.1254366757@sss.pgh.pa.us> Kevin Kofler writes: > Jeff Garzik wrote: >> But you're dodging the larger point -- Fedora has, de facto, demoted big >> endian support in its entirety to a second-hand effort, rather than >> distributed the workload much more widely. Given M package maintainers >> and N secondary-platform volunteers, it is clear M > N by orders of >> magnitude. > I think it is only fair that the people who actually care get to do the > work. Package maintainers can still fix their packages for PPC, they'll even > get e-mail reports from the secondary arch Koji if the builds fail. (It > already happens for the other secondary architectures.) They just won't be > required to do it anymore. You can't force volunteers (and many Fedora > developers are volunteers; even those paid by RH are paid primarily to work > on RHEL, not Fedora, and often do Fedora work in their own free time) to > work on something they're not interested in. You may have a point about volunteer maintainers, though I'd hope they'd be concerned about the quality and portability of their packages anyway. But for anyone working for Red Hat, it's insanely shortsighted to think that not testing on BE platforms is going to save work. We're going to have to make this stuff work on BE platforms for RHEL later on, and it will just be that much more painful if it happens months or years after the changes are fresh. Quite aside from people having forgotten the details of what they changed, upstream projects could be locked into little-endian-only file formats or other hard-to-change decisions by that time. >> Was ppc really such a burden? > Yes. It slowed down builds, and it often triggered bizarre build failures > which were NOT bugs in the program, but in the toolchain or in some core > library like glibc, which in turn delayed important updates to the affected > packages. Again, would you rather debug glibc now, or later? "Not at all" is not an option. > [ ppc64 horror story snipped ] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. regards, tom lane From jgarzik at pobox.com Thu Oct 1 03:51:36 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Wed, 30 Sep 2009 23:51:36 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <8010.1254366757@sss.pgh.pa.us> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <8010.1254366757@sss.pgh.pa.us> Message-ID: <4AC42748.3060009@pobox.com> On 09/30/2009 11:12 PM, Tom Lane wrote: > Again, would you rather debug glibc now, or later? "Not at all" is not > an option. [...] > Well, I'm by no means wedded to ppc64; I just want *some* BE > architecture in the primary set. Maybe a reasonable compromise would be > to include ppc but not ppc64? That would cover basic BE portability > issues, if not the occasional BE-and-64-bit bug. And it would halve the > present workload of the PPC builders, which might help the build time > issue. Seconded on all points. If sheer number of build machines is an issue, one could spin up a qemu running ppc on a non-ppc box. One does reach a tipping point where a modern machine + emulation winds up beating a native machine, as progress marches on, too. Jeff From trever.adams at gmail.com Thu Oct 1 04:26:59 2009 From: trever.adams at gmail.com (Trever L. Adams) Date: Wed, 30 Sep 2009 22:26:59 -0600 Subject: CalDAV Calendar (BedeWork) In-Reply-To: References: <4AC40028.1000600@gmail.com> Message-ID: <4AC42F93.4070800@gmail.com> Kevin Kofler wrote: > Actually, new packages can be pushed as updates. You can add them even to > F11, and F10 if you're really quick (new packages are accepted in F10 until > 1 month before its end of life, which is basically the day of F12's release, > as the end of life for Fedora n is 1 month after Fedora n+2's release). > > Kevin Kofler > As I said, I have a lot to learn. I need help from Java package experts so that I can get up and running quickly. Thank you, Trever -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Thu Oct 1 05:06:48 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Oct 2009 07:06:48 +0200 Subject: yum update vs. blender In-Reply-To: <4AC3589A.9010400@freenet.de> References: <4AC3589A.9010400@freenet.de> Message-ID: <4AC438E8.10307@freenet.de> On 09/30/2009 03:09 PM, Ralf Corsepius wrote: > Hi, > > today's > yum update came along with this: > > # yum update > ... > Updating : blender-2.49b 1.fc11.x86_64 16/57 > Unknown media type in type 'all/all' > > Unknown media type in type 'all/allfiles' > What is this? Seems to me, as is something is very broken with blender's > scriptlets? Upon closer inspection, the culprit seems to be FC11's kdelibs. Apparently, it corrupts the mime database, causing /usr/bin/update-mime-database /usr/share/mime to complain about it. Ralf From pravin.d.s at gmail.com Thu Oct 1 05:31:59 2009 From: pravin.d.s at gmail.com (=?UTF-8?B?4KSq4KWN4KSw4KS14KS/4KSjIOCkuOCkvuCkpOCkquClgeCkpOClhyA=?=) Date: Thu, 1 Oct 2009 11:01:59 +0530 Subject: bitmap-fonts by default? In-Reply-To: <1399102181.839471254357516591.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1399102181.839471254357516591.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <764372c80909302231r4be09c55qfcb5d0a44857d33d@mail.gmail.com> 2009/10/1 Jens Petersen > > IMHO default packages in default groups should have a clear user, or > > be downgraded to optional. > > Right I suggest we make it optional in comps-f13 and see if anything > "breaks". > Yep, this looks nice In merge review of bitmap-fonts, we are splitting it as per font family we will get sufficient time to come at conclusion, which to keep default and which optional Thanks & Regards, ---------------------- Pravin Satpute -------------- next part -------------- An HTML attachment was scrubbed... URL: From npatil at redhat.com Thu Oct 1 06:10:44 2009 From: npatil at redhat.com (Nilesh Patil) Date: Thu, 01 Oct 2009 11:40:44 +0530 Subject: kvm failing to install. Message-ID: <4AC447E4.2070608@redhat.com> Hi, I download the latest kvm-88 from http://sourceforge.net/projects/kvm/files/ . But when i did /'make'/ its failing for following error, CC [M] /dl/kvm-88/kvm/kernel/x86/x86.o In file included from /dl/kvm-88/kvm/kernel/x86/trace.h:355, from /dl/kvm-88/kvm/kernel/x86/x86.c:83: include/trace/define_trace.h:53:43: error: arch/x86/kvm/trace.h: No such file or directory make[4]: *** [/dl/kvm-88/kvm/kernel/x86/x86.o] Error 1 make[3]: *** [/dl/kvm-88/kvm/kernel/x86] Error 2 make[2]: *** [_module_/dl/kvm-88/kvm/kernel] Error 2 make[1]: *** [all] Error 2 make: *** [kvm-kmod] Error 2 I have AMD processor supported '/svm/' Is this known error? - Nilesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at danny.cz Thu Oct 1 06:35:31 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 01 Oct 2009 08:35:31 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20090930235131.GU5260@hansolo.jdub.homelinux.org> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> <20090930235131.GU5260@hansolo.jdub.homelinux.org> Message-ID: <1254378931.4024.34.camel@eagle.danny.cz> Josh Boyer p??e v St 30. 09. 2009 v 19:52 -0400: > On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > >Jeff Garzik writes: > >> The lack of big endian builds by default is a notable loss, and will > >> lead to a decline in software quality. > >> I think this is a net-negative for Fedora. > > > >I think the same, but it's getting harder to find PPC machines. > > s/machines/desktop machines. You can find all kinds of PPC machines, just > typically not in desktop form. The only new one that I am aware of is the > fixstars.us Powerstation. But there should be enough of older IBM Power4+ workstations (IntelliStation 275) with prices around 100 EUR (at least here in Europe) making it possible to buy one just for playing with. > >Is there another big-endian platform that is on the upswing? > > Not to my knowledge, but I haven't paid much attention to that. We do have > secondary arches at least building, like sparc and s390x. I have a ppc > effort 1/2 going. Dan From oget.fedora at gmail.com Thu Oct 1 07:11:31 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Thu, 1 Oct 2009 03:11:31 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20090928162112.GH5260@hansolo.jdub.homelinux.org> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> Message-ID: On Mon, Sep 28, 2009 at 12:21 PM, Josh Boyer wrote: > Hi All, > > As of today, ppc and ppc64 are no longer primary architectures in koji starting > with the dist-f13 tag. ?This is in accordance with the FESCo approved demotion > of PowerPC starting with Fedora 13 development. > Can we drop AOT bits from java packages now? Orcan From jreznik at redhat.com Thu Oct 1 07:41:06 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 1 Oct 2009 09:41:06 +0200 Subject: [KDE] Which Phonon? Phonon backend - GStreamer or Xine? In-Reply-To: References: <200909291703.55030.jreznik@redhat.com> <200909302007.38047.jreznik@redhat.com> Message-ID: <200910010941.06381.jreznik@redhat.com> On Thursday 01 October 2009 03:02:04 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > That's not about "standardize on GTK+" > > That was just an example of how "one size fits it all" doesn't always work > when it comes to libraries, there will always be more than one library for > some purposes. > > > We should choose better technology over politics. > > That's exactly why I voted for Phonon-Xine in the meeting. ;-) > > "All the world must use GStreamer" == politics > Phonon-Xine is considered by Phonon upstream to be the better technology. By one developer who admits that Phonon is dying slowly and not developed anymore ;-) No, I don't want one multimedia framework rule them all but currently it's the best what we have (I'm not talking about Phonon backend - just GStreamer). In case of better framework in the future I believe I'd be one of first supporters (even it could bring troubles to Fedora). Jaroslav > Kevin Kofler > -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From ssorce at redhat.com Thu Oct 1 08:46:21 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 01 Oct 2009 04:46:21 -0400 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <4AC3D06A.8070109@redhat.com> References: <1252964039.2311.93.camel@adam.local.net> <4AC31F76.2040705@redhat.com> <20090930092505.GA16349@suse.de> <4AC39510.4080907@gmail.com> <20090930174350.GA6899@suse.de> <4AC3D06A.8070109@redhat.com> Message-ID: <1254386781.3164.20.camel@localhost.localdomain> On Wed, 2009-09-30 at 23:40 +0200, Florian Festi wrote: > On 09/30/2009 07:43 PM, Michael Schroeder wrote: > > Fedora's rpm used to have a > > modified copy of zlib so that the created rpms were more rsync > > friendly. As deltarpm needs to recreate the same compressed > > payload I also had to support this. > > > Always nice to see how insanity leads to even more insanity. And nice to > see that we can remove it now. Not to be distrusting but I am also going to watch out and see how easily we might break something, just for nazi-like mindset in enforcing a policy. Mind you, I am not against the policy itself, I think it is a good policy, and I am not trying to ask for exceptions for rsync,. But we also need to reasonable, and unless someone volunteers to do the actual work *without* breaking the tool in the process, I think a policy like this need to be evaluated case by case and not just blindly and rigidly enforced. Simo. From jdieter at gmail.com Thu Oct 1 09:26:07 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 01 Oct 2009 12:26:07 +0300 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <1254386781.3164.20.camel@localhost.localdomain> References: <1252964039.2311.93.camel@adam.local.net> <4AC31F76.2040705@redhat.com> <20090930092505.GA16349@suse.de> <4AC39510.4080907@gmail.com> <20090930174350.GA6899@suse.de> <4AC3D06A.8070109@redhat.com> <1254386781.3164.20.camel@localhost.localdomain> Message-ID: <1254389167.23326.664.camel@jdlaptop.lesbg.loc> On Thu, 2009-10-01 at 04:46 -0400, Simo Sorce wrote: > But we also need to reasonable, and unless someone volunteers to do the > actual work *without* breaking the tool in the process, I think a policy > like this need to be evaluated case by case and not just blindly and > rigidly enforced. And, in that vein, I'd like to say a huge thank you to Toshio for fixing deltarpm to use the system zlib library *without* breaking it (at least as far as my testing has gone). It is hugely appreciated! Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Thu Oct 1 09:28:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 11:28:35 +0200 Subject: Buyer Beware: A Major Change in NFS is about to happen References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <1254293108.2242.17.camel@localhost.localdomain> <1254335788.2242.27.camel@localhost.localdomain> <20091001021938.GW5260@hansolo.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > http://meetbot.fedoraproject.org/fedora-meeting/2009-06-12/fedora- > meeting.2009-06-12-17.01.html Ah, there it is, I must have missed it when going through the summaries, sorry. :-( So I'll have to blame the previous FESCo for voting this through with practically no feedback, as they observed themselves before the vote: 17:14:04 has there been any feedback on lists or wiki? 17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion page 17:14:25 yeah, haven't seen much But in any case, I don't think any of us realized the amount of maintainer confusion this would cause (I know I didn't or I would have complained on the mailing list right when this was proposed). In hindsight, it was definitely a mistake. This thread is just one of the examples of maintainers having been led to believe they have more time to develop their features than they actually do, I've seen several more while sitting in FESCo feature meetings. We should fix the mistake at the first opportunity (Fedora 13). Kevin Kofler From rjones at redhat.com Thu Oct 1 09:29:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 Oct 2009 10:29:07 +0100 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <8827.1254351728@sss.pgh.pa.us> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> Message-ID: <20091001092907.GA2736@amd.home.annexia.org> On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > Jeff Garzik writes: > > The lack of big endian builds by default is a notable loss, and will > > lead to a decline in software quality. > > I think this is a net-negative for Fedora. > > I think the same, but it's getting harder to find PPC machines. This was my problem too with PPC builds - it's hard to get time on a PPC/PPC64 machine to fix the problems. > Is there another big-endian platform that is on the upswing? Is ARM big endian? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Thu Oct 1 09:34:38 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 Oct 2009 10:34:38 +0100 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <4AC42748.3060009@pobox.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <8010.1254366757@sss.pgh.pa.us> <4AC42748.3060009@pobox.com> Message-ID: <20091001093438.GB2736@amd.home.annexia.org> On Wed, Sep 30, 2009 at 11:51:36PM -0400, Jeff Garzik wrote: > If sheer number of build machines is an issue, one could spin up a qemu > running ppc on a non-ppc box. This isn't as easy as it sounds. I couldn't get qemu-system-ppc[1] to boot at all, *even* with the supposed PPC experts on the qemu list helping me. There are multiple problems with the BIOS that ships with qemu. Rich. [1] or qemu-system-ppc64, or both, I can't recall now. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From mcepl at redhat.com Thu Oct 1 09:34:33 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 1 Oct 2009 09:34:33 +0000 (UTC) Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: Kevin Kofler, Thu, 01 Oct 2009 02:58:15 +0200: > Yes. It slowed down builds, and it often triggered bizarre build > failures which were NOT bugs in the program, but in the toolchain or in > some core library like glibc, which in turn delayed important updates to > the affected packages. I.e., it was discovering bugs ... not in your program but in glibc, gcc, etc. (I have experienced this couple of times with pspp on Sparc). Mat?j From kevin.kofler at chello.at Thu Oct 1 09:32:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 11:32:59 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <8010.1254366757@sss.pgh.pa.us> Message-ID: Tom Lane wrote: > > [ ppc64 horror story snipped ] > > Well, I'm by no means wedded to ppc64; I just want *some* BE > architecture in the primary set. Maybe a reasonable compromise would be > to include ppc but not ppc64? That would cover basic BE portability > issues, if not the occasional BE-and-64-bit bug. And it would halve the > present workload of the PPC builders, which might help the build time > issue. Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just has room for twice as many entries because pointers are half the size, so in practice projects trigger the awfully low ppc64 limit first. Kevin Kofler From dan at danny.cz Thu Oct 1 09:37:35 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 01 Oct 2009 11:37:35 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20091001092907.GA2736@amd.home.annexia.org> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> <20091001092907.GA2736@amd.home.annexia.org> Message-ID: <1254389855.4024.63.camel@eagle.danny.cz> Richard W.M. Jones p??e v ?t 01. 10. 2009 v 10:29 +0100: > On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: > > Jeff Garzik writes: > > > The lack of big endian builds by default is a notable loss, and will > > > lead to a decline in software quality. > > > I think this is a net-negative for Fedora. > > > > I think the same, but it's getting harder to find PPC machines. > > This was my problem too with PPC builds - it's hard to get time on a > PPC/PPC64 machine to fix the problems. > > > Is there another big-endian platform that is on the upswing? > > Is ARM big endian? The chips can usually do both endians, but Fedora/ARM is built as little endian, because the targeted HW is little endian. Dan From mcepl at redhat.com Thu Oct 1 09:34:38 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 1 Oct 2009 09:34:38 +0000 (UTC) Subject: Buyer Beware: A Major Change in NFS is about to happen References: <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> Message-ID: Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: > Maybe removing the "Final Development" part and replace it with > something like "Beta Freeze (Bug Fixes ONLY)" might have helped. Well my problem with the current state is that it is not "Bug Fixes ONLY", we are getting to acks (Red Hat people know what I am talking about) by somebody who is neither PM, nor developer, nor QA. Oh well, at least finally I know for whom not to vote in the elections. Mat?j From mcepl at redhat.com Thu Oct 1 09:34:36 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 1 Oct 2009 09:34:36 +0000 (UTC) Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> Message-ID: Jeff Garzik, Wed, 30 Sep 2009 18:55:56 -0400: > Both ppc and ppc64 have been excellent at catching software bugs in my > projects that long went unnoticed on i386/x86-64. > > The lack of big endian builds by default is a notable loss, and will > lead to a decline in software quality. > > I think this is a net-negative for Fedora. I don't think it is that bad with secondary archs ... I maintain PSPP (I didn't know what I've fallen into when I packaged that ;)) and we are routinely finding bugs on SPARC ... in pspp as well as in glibc, gcc, and other places. PSPP by its nature has quite extensive unit tests, so it is catching a lot of stuff which otherwise goes unnoticed. Mat?j From jakub at redhat.com Thu Oct 1 09:50:00 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 1 Oct 2009 11:50:00 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <8010.1254366757@sss.pgh.pa.us> Message-ID: <20091001095000.GU14664@tyan-ft48-01.lab.bos.redhat.com> On Thu, Oct 01, 2009 at 11:32:59AM +0200, Kevin Kofler wrote: > Tom Lane wrote: > > > [ ppc64 horror story snipped ] > > > > Well, I'm by no means wedded to ppc64; I just want *some* BE > > architecture in the primary set. Maybe a reasonable compromise would be > > to include ppc but not ppc64? That would cover basic BE portability > > issues, if not the occasional BE-and-64-bit bug. And it would halve the > > present workload of the PPC builders, which might help the build time > > issue. > > Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just > has room for twice as many entries because pointers are half the size, so in > practice projects trigger the awfully low ppc64 limit first. And many other targets have similar limitations. Even x86-64 has them, just big enough that you rarely notice (you need to go over 2GB of code/data to start having issues there, and even then there are code models that allow larger code). In some cases it is just -fpic vs. -fPIC, but in other cases the limitations are more severe. Most of the limitations are related to the encoding of instructions, what immediates they allow and what addressing modes they support. It is actually very desirable if developers don't think all the world is i386/x86_64, that leads to horribly unportable code and many bugs go unnoticed. In the OpenBabel case just using an array, or changing the generator to spit more smaller sources, etc. would be desirable for portability. So I think making PPC a secondary arch is a very bad idea and will hurt Fedora quality. Jakub From josephine.tannhauser at googlemail.com Thu Oct 1 10:10:11 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Thu, 1 Oct 2009 12:10:11 +0200 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <1252964039.2311.93.camel@adam.local.net> References: <1252964039.2311.93.camel@adam.local.net> Message-ID: <3668e9f50910010310h4ca2244ds40ebcb3e4009318c@mail.gmail.com> 2009/9/14 Adam Williamson > Hi, everyone. We - the QA group - have recently been researching the > feasibility of using zsync to reduce the size of live image downloads. > This has hit a roadblock in the form of the problem where both rsync and > zsync use forked zlibs rather than linking against the system copy. > Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, the problem of zsync will be solved as well, cause the integrity of zsync in fedora fails on rsync-compatibility, which needs a forked zlib. -- Josephine "Fine" Tannh?user 2.6.29.6-213.fc11.i586 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Thu Oct 1 11:32:53 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 1 Oct 2009 07:32:53 -0400 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> Message-ID: <20091001113253.GX5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 09:34:38AM +0000, Matej Cepl wrote: >Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: >> Maybe removing the "Final Development" part and replace it with >> something like "Beta Freeze (Bug Fixes ONLY)" might have helped. > >Well my problem with the current state is that it is not "Bug Fixes >ONLY", we are getting to acks (Red Hat people know what I am talking >about) by somebody who is neither PM, nor developer, nor QA. Could you elaborate there? Rel-eng is comprised of several people with varying backgrounds, and there are certianly developers and QA oriented people in that group... >Oh well, at least finally I know for whom not to vote in the elections. Rel-eng isn't elected... again confused. josh From khc at pm.waw.pl Thu Oct 1 11:54:03 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Thu, 01 Oct 2009 13:54:03 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20091001092907.GA2736@amd.home.annexia.org> (Richard W. M. Jones's message of "Thu, 1 Oct 2009 10:29:07 +0100") References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> <20091001092907.GA2736@amd.home.annexia.org> Message-ID: "Richard W.M. Jones" writes: > Is ARM big endian? It can be either. Intel's IXP4xx networking chips are usually running BE since their internal network engines are BE-only and it's thus more efficient. -- Krzysztof Halasa From SteveD at redhat.com Thu Oct 1 11:56:09 2009 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 01 Oct 2009 07:56:09 -0400 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> Message-ID: <4AC498D9.20901@RedHat.com> On 10/01/2009 05:34 AM, Matej Cepl wrote: > Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: >> Maybe removing the "Final Development" part and replace it with >> something like "Beta Freeze (Bug Fixes ONLY)" might have helped. > > Well my problem with the current state is that it is not "Bug Fixes > ONLY", we are getting to acks (Red Hat people know what I am talking > about) by somebody who is neither PM, nor developer, nor QA. I thought about this as well... what might be better than "Bug Fixes ONLY" is "CVS commits turned off" which is more accurate to what happens... steved. From mcepl at redhat.com Thu Oct 1 11:59:47 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 1 Oct 2009 11:59:47 +0000 (UTC) Subject: Buyer Beware: A Major Change in NFS is about to happen References: <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> <4AC498D9.20901@RedHat.com> Message-ID: Steve Dickson, Thu, 01 Oct 2009 07:56:09 -0400: > I thought about this as well... what might be better than "Bug Fixes > ONLY" is "CVS commits turned off" which is more accurate to what > happens... Well, RHEL commits (hopefully I am not leaking some NDA-covered information ;)) have to have something like "fixes #123435" in the commit message. We could do the same easily but requesting that updates in bodhi have to be just bugfixes. Mat?j From rawhide at fedoraproject.org Thu Oct 1 13:24:13 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 1 Oct 2009 13:24:13 +0000 Subject: rawhide report: 20091001 changes Message-ID: <20091001132413.GA16154@releng2.fedora.phx.redhat.com> Compose started at Thu Oct 1 06:15:05 UTC 2009 Broken deps for i386 ---------------------------------------------------------- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.i586 requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 labrea-2.5.1-2.fc10.i386 requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfagent.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidcommon.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfagent.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidclient.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfcommon.so.2 network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 ngrep-1.45-5.fc11.i586 requires libpcap.so.0.9 perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) >= 0:0.0901 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30 yersinia-0.7.1-3.fc11.i586 requires libpcap.so.0.9 Broken deps for x86_64 ---------------------------------------------------------- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.x86_64 requires libpcap.so.0.9()(64bit) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) labrea-2.5.1-2.fc10.x86_64 requires libpcap.so.0.9()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfagent.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidclient.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfagent.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidclient.so.2()(64bit) network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) ngrep-1.45-5.fc11.x86_64 requires libpcap.so.0.9()(64bit) perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) >= 0:0.0901 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30 yersinia-0.7.1-3.fc11.x86_64 requires libpcap.so.0.9()(64bit) Broken deps for ppc ---------------------------------------------------------- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.ppc requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.ppc requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.ppc64 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.ppc requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.ppc requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.ppc64 requires libgdamm-4.0.so.11()(64bit) labrea-2.5.1-2.fc10.ppc requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfagent.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidcommon.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfcommon.so.2 matahari-0.0.4-5.fc12.ppc requires libqmfagent.so.2 matahari-0.0.4-5.fc12.ppc requires libqpidclient.so.2 matahari-0.0.4-5.fc12.ppc requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.ppc requires libqmfcommon.so.2 network-manager-netbook-1.2-5.fc12.ppc requires libnm_glib.so.0 ngrep-1.45-5.fc11.ppc requires libpcap.so.0.9 perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) >= 0:0.0901 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30 yersinia-0.7.1-3.fc11.ppc requires libpcap.so.0.9 Broken deps for ppc64 ---------------------------------------------------------- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.ppc64 requires libpcap.so.0.9()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.ppc64 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.ppc64 requires libgdamm-4.0.so.11()(64bit) glom-libs-1.10.1-1.fc12.ppc64 requires libgdamm-4.0.so.11()(64bit) labrea-2.5.1-2.fc10.ppc64 requires libpcap.so.0.9()(64bit) libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqpidcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqmfagent.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqmfcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqpidclient.so.2()(64bit) matahari-0.0.4-5.fc12.ppc64 requires libqpidcommon.so.2()(64bit) matahari-0.0.4-5.fc12.ppc64 requires libqmfagent.so.2()(64bit) matahari-0.0.4-5.fc12.ppc64 requires libqmfcommon.so.2()(64bit) matahari-0.0.4-5.fc12.ppc64 requires libqpidclient.so.2()(64bit) network-manager-netbook-1.2-5.fc12.ppc64 requires libnm_glib.so.0()(64bit) ngrep-1.45-5.fc11.ppc64 requires libpcap.so.0.9()(64bit) perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) >= 0:0.0901 python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30 yersinia-0.7.1-3.fc11.ppc64 requires libpcap.so.0.9()(64bit) Removed package perl-POE-Component-Client-Keepalive Updated Packages: anerley-0.1.4-1.fc12 -------------------- * Wed Sep 30 2009 Peter Robinson 0.1.4-1 - New upstream 0.1.4 release, drop upstreamed MC5 patches control-center-2.28.0-12.fc12 ----------------------------- * Wed Sep 30 2009 Matthias Clasen 2.28.0-12 - Fix a crash in the display capplet cups-1.4.1-6.fc12 ----------------- * Wed Sep 30 2009 Tim Waugh 1:1.4.1-6 - Don't use cached PPD for raw queue (bug #526405, STR #3356). gdb-6.8.91.20090930-2.fc12 -------------------------- * Wed Sep 30 2009 Jan Kratochvil - 6.8.91.20090930-1 - Fix broken python "help()" command "modules" (BZ 526552). - Upgrade to the FSF GDB gdb-7.0 snapshot: 6.8.91.20090930 - archer-jankratochvil-fedora12 commit: 7cb860f03e2437c97239334ebe240d06f45723e0 * Wed Sep 30 2009 Jan Kratochvil - 6.8.91.20090930-2 - Bump release. * Sun Sep 27 2009 Jan Kratochvil - 6.8.91.20090925-3 - New test for step-resume breakpoint placed in multiple threads at once. kio_sysinfo-20090930-1.fc12 --------------------------- * Wed Sep 30 2009 Luk?? Tinkl - 20090930-1 - fix mounting devices using Solid, HTML template fixes * Fri Aug 28 2009 Luk?? Tinkl - 20090828-1 - new upstream version with a couple of small fixes (most notably the empty disk Label fix) koffice-langpack-1.6.3-4.fc12 ----------------------------- * Sat Sep 26 2009 Rex Dieter 2:1.1.6-4 - Epoch++ (revert koffice2 -> koffice1) libvirt-0.7.1-7.fc12 -------------------- * Wed Sep 30 2009 Mark McLoughlin - 0.7.1-7 - Fix USB device passthrough (#522683) moblin-panel-people-0.0.3-1.fc12 -------------------------------- * Wed Sep 30 2009 Peter Robinson 0.0.3-1 - New upstream 0.0.3 release, drop upstreamed MC5 patches moblin-panel-status-0.0.6-1.fc12 -------------------------------- * Wed Sep 30 2009 Peter Robinson 0.0.6-1 - New upstream 0.0.6 release, drop upstreamed MC5 patches mutter-moblin-0.39.3-1.fc12 --------------------------- yum-3.2.24-9.fc12 ----------------- * Wed Sep 30 2009 Seth Vidal - 3.2.24-8 - fix up broken build b/c of version-groups.conf file * Wed Sep 30 2009 Seth Vidal - 3.2.24-9 - revert yum. import patch b/c it breaks a bunch of things * Tue Sep 29 2009 Seth Vidal - 3.2.24-7 - fixes for odd outputs from ts.run and logs for what we store in history Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 11 From jreiser at bitwagon.com Thu Oct 1 13:41:35 2009 From: jreiser at bitwagon.com (John Reiser) Date: Thu, 01 Oct 2009 06:41:35 -0700 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> <20091001092907.GA2736@amd.home.annexia.org> Message-ID: <4AC4B18F.1060403@bitwagon.com> On 10/01/2009 04:54 AM, Krzysztof Halasa wrote: > "Richard W.M. Jones" writes: > >> Is ARM big endian? > > It can be either. Intel's IXP4xx networking chips are usually running > BE since their internal network engines are BE-only and it's thus > more efficient. The IXP4xx networking engine operates big endian only. Nevertheless many NSLU2 machines run little-endian and still use that networking hardware. Current and future Debian releases for ARM (which is a top-tier architecture on Debian) are little-endian only. Little- endian operation of the CPU offers the advantage that an unaligned fetch from memory gives results that are usable after quick fixup. An unaligned fetch in big-endian mode essentially gives junk. -- From skvidal at fedoraproject.org Thu Oct 1 13:47:36 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 1 Oct 2009 09:47:36 -0400 (EDT) Subject: status of forked zlibs in rsync and zsync In-Reply-To: <1254386781.3164.20.camel@localhost.localdomain> References: <1252964039.2311.93.camel@adam.local.net> <4AC31F76.2040705@redhat.com> <20090930092505.GA16349@suse.de> <4AC39510.4080907@gmail.com> <20090930174350.GA6899@suse.de> <4AC3D06A.8070109@redhat.com> <1254386781.3164.20.camel@localhost.localdomain> Message-ID: On Thu, 1 Oct 2009, Simo Sorce wrote: >> see that we can remove it now. > > Not to be distrusting but I am also going to watch out and see how > easily we might break something, just for nazi-like mindset in enforcing > a policy. Godwin's law? Really? This early in the thread? Maybe we should cool off the dramatic statements all around... -sv Your friendly neighborhood hall-monitor. From rwheeler at redhat.com Thu Oct 1 13:49:03 2009 From: rwheeler at redhat.com (Ric Wheeler) Date: Thu, 01 Oct 2009 09:49:03 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <1254358035.2242.41.camel@localhost.localdomain> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <1254358035.2242.41.camel@localhost.localdomain> Message-ID: <4AC4B34F.10909@redhat.com> On 09/30/2009 08:47 PM, Jesse Keating wrote: > On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: >> Was ppc really such a burden? > > When it breaks and only it breaks, slowing down or delaying a release, > yes. > > I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric From jkeating at j2solutions.net Thu Oct 1 14:39:16 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 07:39:16 -0700 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> Message-ID: <9ED29563-BCDD-4B06-B1E2-EB1CB4F47DFF@j2solutions.net> On Oct 1, 2009, at 2:34, Matej Cepl wrote: > Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: >> Maybe removing the "Final Development" part and replace it with >> something like "Beta Freeze (Bug Fixes ONLY)" might have helped. > > Well my problem with the current state is that it is not "Bug Fixes > ONLY", we are getting to acks (Red Hat people know what I am talking > about) by somebody who is neither PM, nor developer, nor QA. > > Oh well, at least finally I know for whom not to vote in the > elections. > We've stopped caring about anything outside of the critical path. -- Jes From kevin.kofler at chello.at Thu Oct 1 14:41:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 16:41:23 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: Matej Cepl wrote: > I.e., it was discovering bugs ... not in your program but in glibc, gcc, > etc. (I have experienced this couple of times with pspp on Sparc). But usually in target-specific code. Plus, it's not the toolchain's updates which get stalled, but the updates for some package which just happens to trigger the toolchain bug. Having the arches be secondary allows to at least proceed with building things on the primary arches while the bug on the secondary arch is being fixed. Kevin Kofler From jkeating at j2solutions.net Thu Oct 1 14:45:22 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 07:45:22 -0700 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <4AC4B34F.10909@redhat.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <1254358035.2242.41.camel@localhost.localdomain> <4AC4B34F.10909@redhat.com> Message-ID: <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> On Oct 1, 2009, at 6:49, Ric Wheeler wrote: > On 09/30/2009 08:47 PM, Jesse Keating wrote: >> On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: >>> Was ppc really such a burden? >> >> When it breaks and only it breaks, slowing down or delaying a >> release, >> yes. >> >> > > I know that last week several ppc people (IBM, etc) expressed alarm > and concern about the demotion of ppc to a secondary arch. Most of > those people I pointed at Bill and Jesse who were staffing the > fedora booth. > > Did we get any positive feedback/offers of help from them? > > Ric > > No. They heard that here would be a secondary arch effort and seemed to think "oh, they will fix it for us". Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. -- Jes From jkeating at j2solutions.net Thu Oct 1 14:47:02 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 07:47:02 -0700 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <1254293108.2242.17.camel@localhost.localdomain> <1254335788.2242.27.camel@localhost.localdomain> <20091001021938.GW5260@hansolo.jdub.homelinux.org> Message-ID: <81D50DA4-F1B4-4721-ABBA-285D8AB28D9B@j2solutions.net> On Oct 1, 2009, at 2:28, Kevin Kofler wrote: > Josh Boyer wrote: >> http://meetbot.fedoraproject.org/fedora-meeting/2009-06-12/fedora- >> meeting.2009-06-12-17.01.html > > Ah, there it is, I must have missed it when going through the > summaries, > sorry. :-( > > So I'll have to blame the previous FESCo for voting this through with > practically no feedback, as they observed themselves before the vote: > 17:14:04 has there been any feedback on lists or wiki? > 17:14:15 * nirik just sees one 'sounds fine to me' comment on the > discussion > page > 17:14:25 yeah, haven't seen much > > But in any case, I don't think any of us realized the amount of > maintainer > confusion this would cause (I know I didn't or I would have > complained on > the mailing list right when this was proposed). In hindsight, it was > definitely a mistake. This thread is just one of the examples of > maintainers > having been led to believe they have more time to develop their > features > than they actually do, I've seen several more while sitting in FESCo > feature > meetings. We should fix the mistake at the first opportunity (Fedora > 13). > Or we should correct this that got confused and move on rather than continuing to use our own made up meanings for otherwise industry standard words or worse our own made up words. -- Jes From jwboyer at gmail.com Thu Oct 1 14:58:26 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 1 Oct 2009 10:58:26 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <1254358035.2242.41.camel@localhost.localdomain> <4AC4B34F.10909@redhat.com> <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> Message-ID: <20091001145826.GY5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: >> I know that last week several ppc people (IBM, etc) expressed alarm >> and concern about the demotion of ppc to a secondary arch. Most of >> those people I pointed at Bill and Jesse who were staffing the fedora >> booth. >> >> Did we get any positive feedback/offers of help from them? >> > > > No. They heard that here would be a secondary arch effort and seemed to > think "oh, they will fix it for us". Seems to be the running theme. > People want ppc to stick around but nobody wants to work on it. That's > why secondary arch seems right. People who care can work on it but lack > of care won't hold Fedora back. Keep in mind that many upstreams (most?) > don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). josh From jkeating at j2solutions.net Thu Oct 1 15:09:02 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 08:09:02 -0700 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20091001145826.GY5260@hansolo.jdub.homelinux.org> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <1254358035.2242.41.camel@localhost.localdomain> <4AC4B34F.10909@redhat.com> <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> <20091001145826.GY5260@hansolo.jdub.homelinux.org> Message-ID: On Oct 1, 2009, at 7:58, Josh Boyer wrote: > On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: >>> I know that last week several ppc people (IBM, etc) expressed alarm >>> and concern about the demotion of ppc to a secondary arch. Most of >>> those people I pointed at Bill and Jesse who were staffing the >>> fedora >>> booth. >>> >>> Did we get any positive feedback/offers of help from them? >>> >> >> >> No. They heard that here would be a secondary arch effort and >> seemed to >> think "oh, they will fix it for us". Seems to be the running theme. >> People want ppc to stick around but nobody wants to work on it. >> That's >> why secondary arch seems right. People who care can work on it but >> lack >> of care won't hold Fedora back. Keep in mind that many upstreams >> (most?) >> don't have access or care about ppc. In the nonserver world ppc is >> dead. > > s/nonserver/desktop > > Lots of embedded PPC still out there (yes, running Linux). > > Fair point! From notting at redhat.com Thu Oct 1 15:10:51 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Oct 2009 11:10:51 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <4AC3F721.7020605@pobox.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: <20091001151051.GA21238@nostromo.devel.redhat.com> Jeff Garzik (jgarzik at pobox.com) said: > But you're dodging the larger point -- Fedora has, de facto, demoted > big endian support in its entirety to a second-hand effort, rather > than distributed the workload much more widely. Given M package > maintainers and N secondary-platform volunteers, it is clear M > N > by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has very few users. This is demonstratable by smolt stats and download stats. - ppc has declining hardware availability, unless you're counting increased scavenging via dumpsters. - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. In essence, if the bug doesn't affect the build or install environment, it *doesn't get noticed*, in most regards. > Given that ppc32 and ppc64 (or pick your BE platform) have > demonstrated an ability to detect problems not found on LE, it seems > like this policy change will directly lead to missed bugs, and an > attendent decline in software quality. If you feel that this is the case, *step up and join the PPC secondary arch effort*. They could use the help. But I don't see the logic in making Fedora a charity case. As to the RHEL argument, well, that's a RHEL problem. If Red Hat (or anyone, really) feels that it's worth a significant effort to have an up-to-date, maintained, PPC tree, then they should pony up for that effort. Saying "Fedora should do this!" and not providing real resources to accomplish that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. Bill From jwboyer at gmail.com Thu Oct 1 15:35:04 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 1 Oct 2009 11:35:04 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20091001151051.GA21238@nostromo.devel.redhat.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <20091001151051.GA21238@nostromo.devel.redhat.com> Message-ID: <20091001153503.GZ5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 11:10:51AM -0400, Bill Nottingham wrote: >Jeff Garzik (jgarzik at pobox.com) said: >> But you're dodging the larger point -- Fedora has, de facto, demoted >> big endian support in its entirety to a second-hand effort, rather >> than distributed the workload much more widely. Given M package >> maintainers and N secondary-platform volunteers, it is clear M > N >> by orders of magnitude. > >Sure, but it's not like M, in a sizeable percentage of cases, is particularly >useful in this regard. > >In any case: > >- ppc has no one looking at the actual bugs in any case. LiveCDs have > been broken on PPC for *years*, for example, and no one cares. Graphics > drivers have been broken on PPC throughout the F11 release and no one > cares. Going to counter this one. I look at bugs. I know David look(s/ed) at bugs. We just can't get to all of them. This echos your point about community, but I didn't want you to get away with saying that nobody is trying. LiveCDs are pretty useless because demand for them is non-existent. So yes, it is broken and I don't think it works even after some of the recent fixes I sent to livecd-tools. So yeah, no one cares on that. I know I don't, mostly because I'm actually busy with the other stuff. I file bugs on graphics drivers regularly. I know Dave A has been pretty great about helping me get him info to fix the Radeon stuff. I have a bug opened against nouveau right now as well and Ben has been helpful there too (need to get back to that.) If you mean some other driver, then yeah maybe. I can only test/file bugs on hardware I have. >that; well, I don't think Fedora necessarily should be a charity for cases >there's no community for. s/no/a small. Pretending we don't exist isn't exactly kind, but I will admit the few of us that participate are limited in time and resources. josh From kevin.kofler at chello.at Thu Oct 1 15:57:03 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 17:57:03 +0200 Subject: Buyer Beware: A Major Change in NFS is about to happen References: <1254262439.2303.25.camel@localhost.localdomain> <4AC2886F.9070708@RedHat.com> <20090929225553.GW28169@localhost.localdomain> <4AC29443.7030501@RedHat.com> <20090929231620.GA28169@localhost.localdomain> <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com> <20090930191819.GC10134@nostromo.devel.redhat.com> <4AC3B47F.7060302@RedHat.com> <4AC498D9.20901@RedHat.com> Message-ID: Matej Cepl wrote: > Well, RHEL commits (hopefully I am not leaking some NDA-covered > information ;)) have to have something like "fixes #123435" in the commit > message. We could do the same easily but requesting that updates in bodhi > have to be just bugfixes. I can make a "bug" out of almost everything. All this bureaucracy would lead to is lots of Bugzilla "bug reports" to justify updates. Heck, even the existing automated FEver "New version available" "bugs" would qualify. Requiring bug references for Bodhi updates would make no sense whatsoever. Please let maintainers decide, most of us know what we're doing. ;-) Kevin Kofler From a.badger at gmail.com Thu Oct 1 16:17:30 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 Oct 2009 09:17:30 -0700 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <3668e9f50910010310h4ca2244ds40ebcb3e4009318c@mail.gmail.com> References: <1252964039.2311.93.camel@adam.local.net> <3668e9f50910010310h4ca2244ds40ebcb3e4009318c@mail.gmail.com> Message-ID: <4AC4D61A.2080505@gmail.com> On 10/01/2009 03:10 AM, Josephine Tannh?user wrote: > 2009/9/14 Adam Williamson > >> Hi, everyone. We - the QA group - have recently been researching the >> feasibility of using zsync to reduce the size of live image downloads. >> This has hit a roadblock in the form of the problem where both rsync and >> zsync use forked zlibs rather than linking against the system copy. >> > > Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, > the problem of zsync will be solved as well, cause the integrity of zsync in > fedora fails on rsync-compatibility, which needs a forked zlib. > If you want it in, do the work. I've outlined the possibilities several times: A) You're a coder and want to get your hands dirty with the rsync protocol. Check out how librsync manages to use the system zlib and if possible to do this compatibly, apply it to zsync and rsync, possible as a build time option. Push the changes upstream if possible. If it's impossible to apply the librsync strategy, having a good explanation of what librsync is doing and why it can't work for rsync/zsync would be great for crossing this option off the list. B) You're a sometime coder and good with talking to other people. Try to convince zlib to take the patches from rsync (and the zlib-rsyncable patches while you're at it). zlib has a mailing list that's open to developers and testers of zlib. AFAICS from looking at subjects in the entire archive, neither of these patches have gone to that mailing list. Since the mailing list archives aren't wide open, I'm thinking that the patches went directly to one of the developers mailboxes where it was ignored or forgotten. Getting them to the mailing list would be a good first start. http://zlib.net/mailman/listinfo/zlib-devel_madler.net C) You're a coder and want to be responsible for maintaining a new, more forward moving zlib. Pull the zlib code out of rsync, start a new upstream for it, package it for Fedora. You can also pull other requested features in (like the zlib-rsyncable patches that were in the zlib I just pulled out of deltarpm). Get someone to announce to other distributions that this library exists. D) You're good with build scripts like autoconf and configure and good with talking to other people. Work on the rsync build so that it builds and installs the bundled zlib as a shared library with a new name. Push the changes to the rsync upstream so they maintain the fork. Asking for an exception when: 1) I just spent all of yesterday dealing with a security flaw due to a bundled zlib and 2) a request for an exception has already been turned down is beating on a dead horse with a wet noodle. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jan.klepek at brandforge.sk Thu Oct 1 16:24:19 2009 From: jan.klepek at brandforge.sk (Jan Klepek) Date: Thu, 01 Oct 2009 18:24:19 +0200 Subject: orphaning argus In-Reply-To: <20090930135808.GA22554@hedwig.net.cmu.edu> References: <20090930135808.GA22554@hedwig.net.cmu.edu> Message-ID: <1254414259.4724.1.camel@localhost.localdomain> On Wed, 2009-09-30 at 09:58 -0400, L. Gabriel Somlo wrote: > Not using argus anymore, and no cycles to do right by it. I will take it. From jonathan.underwood at gmail.com Thu Oct 1 16:42:00 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Oct 2009 17:42:00 +0100 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <4AC4D61A.2080505@gmail.com> References: <1252964039.2311.93.camel@adam.local.net> <3668e9f50910010310h4ca2244ds40ebcb3e4009318c@mail.gmail.com> <4AC4D61A.2080505@gmail.com> Message-ID: <645d17210910010942p2874941ja7115a36ff2c2bc7@mail.gmail.com> 2009/10/1 Toshio Kuratomi : > On 10/01/2009 03:10 AM, Josephine Tannh?user wrote: >> 2009/9/14 Adam Williamson >> >>> Hi, everyone. We - the QA group - have recently been researching the >>> feasibility of using zsync to reduce the size of live image downloads. >>> This has hit a roadblock in the form of the problem where both rsync and >>> zsync use forked zlibs rather than linking against the system copy. >>> >> >> Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, >> the problem of zsync will be solved as well, cause the integrity of zsync in >> fedora fails on rsync-compatibility, which needs a forked zlib. >> > If you want it in, do the work. ?I've outlined the possibilities several > times: > > A) You're a coder and want to get your hands dirty with the rsync > protocol. ?Check out how librsync manages to use the system zlib and if > possible to do this compatibly, apply it to zsync and rsync, possible as > a build time option. ?Push the changes upstream if possible. ?If it's > impossible to apply the librsync strategy, having a good explanation of > what librsync is doing and why it can't work for rsync/zsync would be > great for crossing this option off the list. > librsync is not wire compatible with rsync, and also hasn't kept up to date with rsync protocol changes, so it may not be as straightforward to lift ideas from librsync. From a.badger at gmail.com Thu Oct 1 16:43:59 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 Oct 2009 09:43:59 -0700 Subject: status of forked zlibs in rsync and zsync In-Reply-To: <645d17210910010942p2874941ja7115a36ff2c2bc7@mail.gmail.com> References: <1252964039.2311.93.camel@adam.local.net> <3668e9f50910010310h4ca2244ds40ebcb3e4009318c@mail.gmail.com> <4AC4D61A.2080505@gmail.com> <645d17210910010942p2874941ja7115a36ff2c2bc7@mail.gmail.com> Message-ID: <4AC4DC4F.7060106@gmail.com> On 10/01/2009 09:42 AM, Jonathan Underwood wrote: > 2009/10/1 Toshio Kuratomi : >> A) You're a coder and want to get your hands dirty with the rsync >> protocol. Check out how librsync manages to use the system zlib and if >> possible to do this compatibly, apply it to zsync and rsync, possible as >> a build time option. Push the changes upstream if possible. If it's >> impossible to apply the librsync strategy, having a good explanation of >> what librsync is doing and why it can't work for rsync/zsync would be >> great for crossing this option off the list. >> > > librsync is not wire compatible with rsync, and also hasn't kept up to > date with rsync protocol changes, so it may not be as straightforward > to lift ideas from librsync. > Good to know. So we can cross this one off the list. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From michael.silvanus at gmail.com Thu Oct 1 16:57:57 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Thu, 1 Oct 2009 12:57:57 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <1254358035.2242.41.camel@localhost.localdomain> <4AC4B34F.10909@redhat.com> <0A0CD731-F582-4153-AABA-6625728BF013@j2solutions.net> Message-ID: <615c05430910010957s2f5795famc8545314bac457e8@mail.gmail.com> On Thu, Oct 1, 2009 at 10:45 AM, Jesse Keating wrote: >> I know that last week several ppc people (IBM, etc) expressed alarm and >> concern about the demotion of ppc to a secondary arch. Most of those people >> I pointed at Bill and Jesse who were staffing the fedora booth. >> >> Did we get any positive feedback/offers of help from them? >> >> Ric >> >> > > > No. They heard that here would be a secondary arch effort and seemed to > think "oh, they will fix it for us". Seems to be the running theme. People > want ppc to stick around but nobody wants to work on it. That's why > secondary arch seems right. People who care can work on it but lack of care > won't hold Fedora back. Keep in mind that many upstreams (most?) don't have > access or care about ppc. In the nonserver world ppc is dead. > That is sadly true, even of Apple (PPC support is dropped from Snow Leopard, and their LLVM framework is more buggy on PPC -- fastcall does not work, etc. A lot of maintainers probably do care that their software does not have broken assumptions about endianness, so it would be nice that, for a given package N-V-R, we can see both the primary and secondary Kojis' build results. Regards, -- Michel Alexandre Salim From dmalcolm at redhat.com Thu Oct 1 17:15:09 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 01 Oct 2009 13:15:09 -0400 Subject: Proposal: Python 3 in Fedora 13 Message-ID: <1254417309.9551.34.camel@radiator.bos.redhat.com> Proposal: Python 3 in Fedora 13 "Evolutionary, not revolutionary": build a python 3 stack parallel-installable with the python 2 stack. = High-level summary = - Python 3.0 was released almost 10 months ago, on 2008-12-03, and the latest release of the 3.* branch is 3.1.1, released on 2009-08-17. - Other distros have python 3, though not necessarily with anything "on top" resembling the full python 2 stack. - We have a working, valuable python 2 stack, which is used by critical system components (yum and anaconda): we must not destabilize the python 2 stack. - Python 3 is sufficiently different from python 2 that we need them to be independent software stacks. - I plan to spend a large chunk of my $DAYJOB over the next few months trying to build a useful Python 3 stack for Fedora 13, for some definition of "useful" (help will be appreciated!) - I don't want to add extra work for package maintainers: if you maintain an SRPM of a python 2 module that's working for you, you shouldn't feel obligated to own a separate SRPM for python 3. If someone has a need for the module on python 3, they can take on that work. = Background = Python 3 is intended by upstream to be the future of Python, but we have many critical components that use Python 2. Python 2 and Python 3 are sufficiently different that we need both (try writing "print" in each). Python 2 will be around for a long time. An interesting summary of Python 3 adoption can be seen here: http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html An earlier proposal about python 3 in Fedora is here: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html Going forward, I will have plenty of time to spend, as part of my dayjob, on Python in Fedora [1] = Proposal = I want to get python 3 into Fedora, but I don't want to break yum or anaconda (or anything else, for that matter!) How to do this? I propose that Fedora shall have separate, parallel-installable Python 2 and Python 3 stacks. I believe we can get things to the point where on a Fedora box you'd be able to install both stacks, and have some processes running python 2 code, and some running python 3, simultaneously. Where I would draw the line is on having both python 2 and python 3 running within the same _process_: the two libraries share most of their symbol names, but with differing implementations, and the result of trying to dynamically link the two into the same address space would be highly unstable. As an example, you'd be able to install both mod_python and mod_python3 rpms, but you wouldn't be able to (sanely) configure httpd to have both running simultaneously (I guess we should add a run-time warning for this case) Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so - the proposal is for python 2 vs python 3. It could be extended to support having multiple minor-versions of Python as well, but that's a big extension of the work involved and not something I'm planning to work on myself. = Details = We should split python 2 and python 3 at the source RPM level, where possible. The easy case is when upstream release separate tarballs for the python 2 and python 3 versions of code. For example, given package "python-foo" in packaging CVS, there would be a separate "python3-foo" for the python 3 version. There would be no expectation that the two would need to upgrade in lock-step. (The two SRPMS could have different maintainers within Fedora: the packager of a python 2 module might not yet have any interest in python 3) The more difficult case is when the python module is emitted as part of the build of a larger module. Some examples: - the build of "rpm" itself emits an "rpm-python" subpackage. - Another example is the "postgres" srpm, which emits a "postgresql-python" subpackage. In a quick attempt at seeing other examples, on my laptop (F11), here are the packages installed that provide python modules where the package name differs from the srpm name: $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not owned" | sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE} %{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0, col1 from - where col0 != col1 col0| col1| ----------------------------------------+----------------------------------+ at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11| audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11| cracklib-python-2.8.13-4| cracklib-2.8.13-4| gamin-python-0.1.10-4.fc11| gamin-0.1.10-4.fc11| hplip-libs-3.9.8-12.fc11| hplip-3.9.8-12.fc11| libproxy-python-0.2.3-10.fc11| libproxy-0.2.3-10.fc11| libselinux-python-2.0.80-1.fc11| libselinux-2.0.80-1.fc11| libsemanage-python-2.0.31-4.fc11| libsemanage-2.0.31-4.fc11| libuser-python-0.56.9-3| libuser-0.56.9-3| libxml2-python-2.7.3-3.fc11| libxml2-2.7.3-3.fc11| newt-python-0.52.10-4.fc11| newt-0.52.10-4.fc11| plague-common-0.4.5.7-5.20090612cvs.fc11| plague-0.4.5.7-5.20090612cvs.fc11| policycoreutils-python-2.0.62-12.12.fc11| policycoreutils-2.0.62-12.12.fc11| python-magic-5.03-2.fc11| file-5.03-2.fc11| python-slip-dbus-0.1.15-3.fc11| python-slip-0.1.15-3.fc11| python-slip-gtk-0.1.15-3.fc11| python-slip-0.1.15-3.fc11| rpm-python-4.7.1-1.fc11| rpm-4.7.1-1.fc11| setroubleshoot-server-2.1.14-3.fc11| setroubleshoot-2.1.14-3.fc11| system-config-printer-libs-1.1.8-6.fc11|system-config-printer-1.1.8-6.fc11| Such SRPMS have a: BuildRequires: python-devel which is a subpackage from the python build (2.6) My plan here is that we should create a python3-devel subpackage as a subpackage of the python3 build, and have it parallel-installable with the python-devel package. We could then %prep the rpm build for each of the above so that the python 3 support is built as a parallel component of the build, independently of the python 2 support e.g. by copying the python2 support into a separate dir, then applying a patch as necessary (and somehow wiring up the configuration/make so it builds both...) The caveat here is that I haven't tried actually doing this yet for any of these packages. Issues with this approach: - I don't yet know if autoconfiguration will work well with both -devel packages installed - It will probably involve actually doing the porting work for each package (yay, we get to be leaders!) - Whoever does this for a package needs to work closely with the upstream for that package I'll have a go at doing this for rpm when I get back from vacation. Arguably the existing python 2 binding of rpm isn't great, but it's probably best to go for close compatibility between python 2 and python 3 rather than try to overhaul the bindings as part of the port to python 3: one thing at a time! "Naming convention" proposal: How does this sound: - an rpm with a "python-" prefix means a python 2 rpm, of the "default" python 2 minor version (for Fedora this will be the most recent stable upstream minor release, for EPEL it will be the minor release of 2 that came with the distro, so 2.4 for EPEL5) - an rpm with a "python3-" prefix means a python 3 rpm, of the "default" python 3 minor version (for Fedora this will be the most recent stable upstream release) (we could extend this to have specific minor-releases (e.g. use "python24-" for a python 2.4 stack, in case some brave soul wants to get zope/plone running. But may be better to try to fix the zope/2.6 incompatibility at that point (caveat: haven't looked at the details of the issue). I don't intend to work on such versions)) What about packages without a "python-" prefix? Proposal: If upstream has a naming convention for python2 vs python3, use it. Otherwise, add a "python3-" prefix to make things clear. I'm not sure about the details here. Examples? There have been various discussions upstream about what to call the python 3 binary. My favorite quote on the subject is from Guido, http://mail.python.org/pipermail/python-3000/2008-March/012421.html : > During the next 3 years or so, installing Py3k as the default "python" > will be a deed of utter irresponsibility and is likely to break your > system in subtle ways (both OSX and Linux these days use Python for > certain system tasks). If you *really* want to shoot yourself in the > foot this way, go ahead and explicitly use "make altinstall > bininstall" or link it yourself. I propose that for Fedora we have "/usr/bin/python3" for the system/default version of python 3 and "/usr/bin/python" for the system/default version of python 2. Both would be symlinks to a binary with the minor-release embedded in the name ("/usr/bin/python3.1" and "/usr/bin/python/2.6"). As I understand things, this should make us broadly in agreement with upstream; see e.g.: http://mail.python.org/pipermail/python-dev/2009-April/088862.html http://mail.python.org/pipermail/python-dev/2009-April/088884.html A rough plan for Fedora 13 might be: - get python3 packaged in a manner compatible with the above - (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct python when building rpms containing .py files) - get rpm bindings working with python3 - get some useful components working e.g. a web stack: Django, TurboGears etc (though e.g. Django's py3k support is a long way off IIRC); ideas? - solidify packaging guidelines for python 2 vs python 3 once we've got some experience with the above and hopefully proven the techniques - look at porting major components over to python3 (but probably don't actually do this for F13; leave python 2 as the critical component, I suspect): - yum (rpm) - anaconda However "no plan survives contact with the enemy", we'll see how things turn out in reality when trying to get a full integrated stack working. Future work (F14?) could involve cutting over the major components, so that the base install would bring in "python3", and "python" would become optional. Obviously there's a _lot_ to be done before that can be done sanely. = Progress so far = I've put together a somewhat-working python3 srpm, based on the python srpm (with lots of FIXMEs added...) It's not yet ready for a formal package review (I'm working through the various patches, and it's not yet fully installable in parallel with the python 2 stack), but you can see the specfile here: http://people.redhat.com/dmalcolm/python3/python3.spec and an SRPM here: http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm After I did this work, I saw that a couple of other people have written Python 3 srpms for Fedora: http://ivazquez.fedorapeople.org/packages/python3000/ and https://bugzilla.redhat.com/show_bug.cgi?id=526126 and there was this proposal for doing Python 3 in F10: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html similar to this one. Obviously I want to work with those people to come up with a working python 3 rpm in Fedora. There's also the merge-review for python: https://bugzilla.redhat.com/show_bug.cgi?id=226342 ; many of the comments there would thus also apply to my srpm, given that I used the former as my starting point. On a tangent: we currently have 2.6.2 in F12/rawhide. Upstream is preparing a 2.6.3 release, with many bugfixes. This seems to me like a candidate for F13. (the release notes for the 2.6.3 rc are long; I'd want it to have a _lot_ of testing before pushing it to F12)) Thoughts? Dave [1] I'm being transferred at work, and will be able to spend a lot of time on Python within Fedora. Previously, my job involved keeping various internal RH systems working (with any Fedora work done afterhours or as a side project). Having said that, I'm about to go on vacation with no access to a computer for the period October 3rd-10th From alsadi at gmail.com Thu Oct 1 17:32:29 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Thu, 1 Oct 2009 20:32:29 +0300 Subject: yum update vs. blender In-Reply-To: <4AC438E8.10307@freenet.de> References: <4AC3589A.9010400@freenet.de> <4AC438E8.10307@freenet.de> Message-ID: <385866f0910011032k47ce2d40m4d94e9419741f4eb@mail.gmail.com> and the solution is ? have you reported that on bugzilla against kde ? From fedora at matbooth.co.uk Thu Oct 1 17:42:08 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 1 Oct 2009 18:42:08 +0100 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> Message-ID: <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> 2009/10/1 Kevin Kofler : > Jeff Garzik wrote: >> Was ppc really such a burden? > > Yes. It slowed down builds, and it often triggered bizarre build failures > which were NOT bugs in the program, but in the toolchain or in some core > library like glibc, which in turn delayed important updates to the affected > packages. > > In fact, my "favorite" ppc64 issue was a problem with OpenBabel hitting a > limitation in the ppc64 toolchain: there's a "table of contents" which can > grow only to a small fixed size, so large compilation units just don't > compile on ppc64, while being perfectly valid C/C++ and compiling fine on > all other architectures. (And that's already with the "minimal TOC". Without > it, the limit is for the whole executable!) OpenBabel's SWIG-generated > bindings exceeded that limit. We were the only ones hitting it as no other > distribution is insane enough to build their packages for ppc64. (The > binaries don't even get actually used as ppc32 is the preferred multilib on > 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce > the amount of TOC entries, which worked for 2 beta releases (requiring > additional tweaking for the second one), but then it overflowed again. This > was a big annoyance because the new OpenBabel betas were required for new > kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream > removed some things from their bindings to get them to build, a quite > suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs > to be redesigned from scratch. > > ? ? ? ?Kevin Kofler > Nice bug; this one is my favourite: https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds don't expand %{_libdir} to the correct place. You absolutely *cannot* build Eclipse plugins on ppc64 hosts because of this beauty. The current workaround is to just keep resubmitting the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do with Eclipse either, BTW, seems like an RPM or mock problem.) -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From fedora at matbooth.co.uk Thu Oct 1 17:48:48 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 1 Oct 2009 18:48:48 +0100 Subject: CalDAV Calendar (BedeWork) In-Reply-To: <4AC42F93.4070800@gmail.com> References: <4AC40028.1000600@gmail.com> <4AC42F93.4070800@gmail.com> Message-ID: <9497e9990910011048l7c5d2c4l66f01ade9c2642ec@mail.gmail.com> 2009/10/1 Trever L. Adams : > Kevin Kofler wrote: >> Actually, new packages can be pushed as updates. You can add them even to >> F11, and F10 if you're really quick (new packages are accepted in F10 until >> 1 month before its end of life, which is basically the day of F12's release, >> as the end of life for Fedora n is 1 month after Fedora n+2's release). >> >> ? ? ? ? Kevin Kofler >> > As I said, I have a lot to learn. I need help from Java package experts > so that I can get up and running quickly. > > Thank you, > Trever > > > There is a Fedora Java Devel mailing list at https://www.redhat.com/mailman/listinfo/fedora-devel-java-list -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From fedora at matbooth.co.uk Thu Oct 1 17:58:04 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 1 Oct 2009 18:58:04 +0100 Subject: CalDAV Calendar (BedeWork) In-Reply-To: <4AC40028.1000600@gmail.com> References: <4AC40028.1000600@gmail.com> Message-ID: <9497e9990910011058k4146123eo942609318a763159@mail.gmail.com> 2009/10/1 Trever L. Adams : > Hello all, > > About a year ago, I suggested that BedeWork (http://bedework.org) be > included. I offered to package it with some help. I unfortunately ran > out of time. I now have time to package it and hopefully maintain the > package. Unfortunately, I haven't written an Java code in a decade or > so. I have never messed with Java packages. > > The problems I have: > > This package has a bunch of property files that you have to edit before > you build the program. > (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18) > These include database names, locations, user/passwords for the > database, etc. I do not know if this is normal or not. I do not know how > to package this, how to suggest people customize this information, etc. > Also, setting usernames and passwords at compile time is definitely not normal for *any* kind of application. Are you sure they are not runtime properties? -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From jwboyer at gmail.com Thu Oct 1 17:59:10 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 1 Oct 2009 13:59:10 -0400 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> Message-ID: <20091001175910.GB5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: >Scoping: > - this work would target Fedora 13. I'd avoid pushing it into F12 >until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said "I will not push this into F12 at all." josh From tgl at redhat.com Thu Oct 1 18:00:45 2009 From: tgl at redhat.com (Tom Lane) Date: Thu, 01 Oct 2009 14:00:45 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> Message-ID: <198.1254420045@sss.pgh.pa.us> Mat Booth writes: > Nice bug; this one is my favourite: > https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds > don't expand %{_libdir} to the correct place. > You absolutely *cannot* build Eclipse plugins on ppc64 hosts because > of this beauty. The current workaround is to just keep resubmitting > the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do > with Eclipse either, BTW, seems like an RPM or mock problem.) Sweet ... and of course removing PPC64 from the primary arch set does nothing to help you on this, since those machines are still in the build farm, and will have to stay there for at least another year to support F11/F12. regards, tom lane From cmadams at hiwaay.net Thu Oct 1 18:07:49 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 Oct 2009 13:07:49 -0500 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <20091001175910.GB5260@hansolo.jdub.homelinux.org> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: <20091001180748.GK1039762@hiwaay.net> Once upon a time, Josh Boyer said: > On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: > >Scoping: > > - this work would target Fedora 13. I'd avoid pushing it into F12 > >until it's proven safe to do so > > I'm going to think on the overall proposal more, but I very very very much > wish this sentence said "I will not push this into F12 at all." Yeah, we seem to have too much "churn" going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at j2solutions.net Thu Oct 1 18:10:24 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 11:10:24 -0700 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <198.1254420045@sss.pgh.pa.us> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> <198.1254420045@sss.pgh.pa.us> Message-ID: On Oct 1, 2009, at 11:00, Tom Lane wrote: > Mat Booth writes: >> Nice bug; this one is my favourite: >> https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds >> don't expand %{_libdir} to the correct place. > >> You absolutely *cannot* build Eclipse plugins on ppc64 hosts because >> of this beauty. The current workaround is to just keep resubmitting >> the build until Koji picks an i386, x86_64 or ppc host. (Nothing to >> do >> with Eclipse either, BTW, seems like an RPM or mock problem.) > > Sweet ... and of course removing PPC64 from the primary arch set does > nothing to help you on this, since those machines are still in the > build > farm, and will have to stay there for at least another year to support > F11/F12. > Actually when removed as a primary arch I do believe no build will be done (even noarch) on a ppc builder. It cannot init a buildroot as there are no archful packages for ppc. -- Jes From jkeating at j2solutions.net Thu Oct 1 18:11:26 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 1 Oct 2009 11:11:26 -0700 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <20091001175910.GB5260@hansolo.jdub.homelinux.org> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: On Oct 1, 2009, at 10:59, Josh Boyer wrote: > On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: >> Scoping: >> - this work would target Fedora 13. I'd avoid pushing it into F12 >> until it's proven safe to do so > > I'm going to think on the overall proposal more, but I very very > very much > wish this sentence said "I will not push this into F12 at all." > > josh > Ditto. This is not something you would push as an update to a released product. -- Jes From khc at pm.waw.pl Thu Oct 1 18:15:12 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Thu, 01 Oct 2009 20:15:12 +0200 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <4AC4B18F.1060403@bitwagon.com> (John Reiser's message of "Thu, 01 Oct 2009 06:41:35 -0700") References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <8827.1254351728@sss.pgh.pa.us> <20091001092907.GA2736@amd.home.annexia.org> <4AC4B18F.1060403@bitwagon.com> Message-ID: John Reiser writes: > The IXP4xx networking engine operates big endian only. Nevertheless > many NSLU2 machines run little-endian and still use that networking > hardware. With a performance penalty since all buffers have to be swapped. > Little- > endian operation of the CPU offers the advantage that an unaligned > fetch from memory gives results that are usable after quick fixup. > An unaligned fetch in big-endian mode essentially gives junk. Both BE and LE obviously have advantages and disadvantages. -- Krzysztof Halasa From kevin.kofler at chello.at Thu Oct 1 18:22:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 20:22:20 +0200 Subject: orphaning argus References: <20090930135808.GA22554@hedwig.net.cmu.edu> <1254414259.4724.1.camel@localhost.localdomain> Message-ID: Jan Klepek wrote: > On Wed, 2009-09-30 at 09:58 -0400, L. Gabriel Somlo wrote: >> Not using argus anymore, and no cycles to do right by it. > > I will take it. Please make sure you fix the broken dependency in F-12 (on an old version of libpcap) as soon as possible and get the fixed package tagged into the release (request tagging at https://fedorahosted.org/rel-eng/newticket ? explain it's to fix a broken dependency). Kevin Kofler From a.badger at gmail.com Thu Oct 1 18:23:36 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 Oct 2009 11:23:36 -0700 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: <4AC4F3A8.8050704@gmail.com> On 10/01/2009 11:11 AM, Jesse Keating wrote: > > > On Oct 1, 2009, at 10:59, Josh Boyer wrote: > >> On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: >>> Scoping: >>> - this work would target Fedora 13. I'd avoid pushing it into F12 >>> until it's proven safe to do so >> >> I'm going to think on the overall proposal more, but I very very very >> much >> wish this sentence said "I will not push this into F12 at all." >> >> josh >> > > Ditto. This is not something you would push as an update to a released > product. > I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dmalcolm at redhat.com Thu Oct 1 18:23:01 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 01 Oct 2009 14:23:01 -0400 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <20091001180748.GK1039762@hiwaay.net> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> <20091001180748.GK1039762@hiwaay.net> Message-ID: <1254421381.9551.49.camel@radiator.bos.redhat.com> On Thu, 2009-10-01 at 13:07 -0500, Chris Adams wrote: > Once upon a time, Josh Boyer said: > > On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: > > >Scoping: > > > - this work would target Fedora 13. I'd avoid pushing it into F12 > > >until it's proven safe to do so > > > > I'm going to think on the overall proposal more, but I very very very much > > wish this sentence said "I will not push this into F12 at all." > > Yeah, we seem to have too much "churn" going with some things as it is > during a release. What possible reason would there be to push a major > new component into an existing release? Agreed. This part of my post was clumsy. I think what I meant to say was that I'd want to veto anyone wanting to push it into F12, that they'd have a significant burden of proof of safety before such an action could occur. I don't have any interest in such a backport. Sorry Dave From deadbabylon at googlemail.com Thu Oct 1 18:38:30 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Thu, 1 Oct 2009 20:38:30 +0200 Subject: KDE-SIG weekly report (40/2009) In-Reply-To: <200909301431.23961.jreznik@redhat.com> References: <200909301431.23961.jreznik@redhat.com> Message-ID: <200910012038.35919.deadbabylon@googlemail.com> Am Mittwoch 30 September 2009 schrieb Jaroslav Reznik: > o future of Phonon > * Upstream (sandsmark) recommends building/packaging phonon from qt, and > building/packaging backends separately. > * Mandriva developments integrating pulseaudio support (and improving > gstreamer backend). [1] > * We will move back to building a standalone phonon SRPM. > * The vote for the default backend is split 3:3, needs the 7th vote from > svahl. Sorry for the delay. Was a bit busy and not at home. I tend to xine as default backend for several reasons: - It worked fine for me for several releases (and according to bugs for other too) - It is recommend by upstream. - We won't get trouble with the amarok guys. :) - At least on one system I have no sound with gstreamer (maybe caused by other issues, have to re-check that). So I'm a bit conservative here, but +1 for xine. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jwboyer at gmail.com Thu Oct 1 18:40:12 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 1 Oct 2009 14:40:12 -0400 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> Message-ID: <20091001184012.GD5260@hansolo.jdub.homelinux.org> On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote: >Nice bug; this one is my favourite: >https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds >don't expand %{_libdir} to the correct place. I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}' repeated several times. josh From dmalcolm at redhat.com Thu Oct 1 18:39:26 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 01 Oct 2009 14:39:26 -0400 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <4AC4F3A8.8050704@gmail.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> <4AC4F3A8.8050704@gmail.com> Message-ID: <1254422366.9551.64.camel@radiator.bos.redhat.com> On Thu, 2009-10-01 at 11:23 -0700, Toshio Kuratomi wrote: > On 10/01/2009 11:11 AM, Jesse Keating wrote: > > > > > > On Oct 1, 2009, at 10:59, Josh Boyer wrote: > > > >> On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: > >>> Scoping: > >>> - this work would target Fedora 13. I'd avoid pushing it into F12 > >>> until it's proven safe to do so > >> > >> I'm going to think on the overall proposal more, but I very very very > >> much > >> wish this sentence said "I will not push this into F12 at all." > >> > >> josh > >> > > > > Ditto. This is not something you would push as an update to a released > > product. > > > I disagree. The proposal is really treating python3 as a new language. > We can and do push such things into a released Fedora. Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Dave From skvidal at fedoraproject.org Thu Oct 1 19:03:21 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 1 Oct 2009 15:03:21 -0400 (EDT) Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <1254422366.9551.64.camel@radiator.bos.redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> <4AC4F3A8.8050704@gmail.com> <1254422366.9551.64.camel@radiator.bos.redhat.com> Message-ID: On Thu, 1 Oct 2009, David Malcolm wrote: > Treating it as a new language is the intent, and I'll make every effort > to keep them separated. > > In theory there wouldn't be any problems. However if I screw up and > somehow cross the streams, I run the risk of breaking _lots_ of things; > yum is the most obvious victim in the critical path. Obviously I don't > want to do that. > > I'm not volunteering to put it into F12. I think that anyone wanting to > push it into F12 needs to sign up for a lot of testing (brainstorming > some testcases: can you still compile and build external modules with > both 2 and 3 -devel subpackages installed? does every configure script > pick up the correct version? etc) Now- perhaps a repo with your package in it that someone could consume on f12 would be a straightforward goal... if you need extra space on fedorapeople.org for this - let me know. -sv From walters at verbum.org Thu Oct 1 19:04:09 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 1 Oct 2009 15:04:09 -0400 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <1254422366.9551.64.camel@radiator.bos.redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> <4AC4F3A8.8050704@gmail.com> <1254422366.9551.64.camel@radiator.bos.redhat.com> Message-ID: On Thu, Oct 1, 2009 at 2:39 PM, David Malcolm wrote: > > > I'm not volunteering to put it into F12. I think that anyone wanting to > push it into F12 needs to sign up for a lot of testing (brainstorming > some testcases: can you still compile and build external modules with > both 2 and 3 -devel subpackages installed? does every configure script > pick up the correct version? etc) > Which brings up a useful point in that the critical path has two components; the closure of their Requires, and the closure of their BuildRequires. However - this still seems like low risk to me because the builders only build with what's specified in BuildRequires, so you'd have to have quite a contortion to get python3-devel in there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Thu Oct 1 19:17:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 Oct 2009 12:17:24 -0700 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> Message-ID: <4AC50044.6090804@gmail.com> On 10/01/2009 10:15 AM, David Malcolm wrote: > Proposal: Python 3 in Fedora 13 > > "Evolutionary, not revolutionary": build a python 3 stack > parallel-installable with the python 2 stack. > First: Overall +1. Note: liberally snipped, throughout. > = Proposal = > Where I would draw the line is on having both python 2 and python 3 > running within the same _process_: the two libraries share most of their > symbol names, but with differing implementations, and the result of > trying to dynamically link the two into the same address space would be > highly unstable. > > As an example, you'd be able to install both mod_python and mod_python3 > rpms, but you wouldn't be able to (sanely) configure httpd to have both > running simultaneously (I guess we should add a run-time warning for > this case) > I don't see any way around this atm but it is something to think about possibilities more. For instance, if we get TurboGears2 ported to python3 while TurboGears1 is still on python2 people will need to run two apache servers (one with python2-mod_wsgi and one with python3-mod_wsgi). > Scoping: > - this work would target Fedora 13. I'd avoid pushing it into F12 > until it's proven safe to do so There's value in pushing the interpreter to F12 as it opens up porting of code from python2 to python3 to more people. I don't think porting applications to python3 in F12 is of great benefit. Pushing libraries back is somewhere in-between. Of course, at some point this is a matter of maintainers doing what's interesting to them. > - the proposal is for python 2 vs python 3. It could be extended to > support having multiple minor-versions of Python as well, but that's a > big extension of the work involved and not something I'm planning to > work on myself. > Unless someone actively wants to work on this right now, I'd like to keep that a separate issue as it just makes matters more confusing. > The more difficult case is when the python module is emitted as part of > the build of a larger module. Some examples: > - the build of "rpm" itself emits an "rpm-python" subpackage. > - Another example is the "postgres" srpm, which emits a > "postgresql-python" subpackage. > There's another case where this exists: upstream plans to do automated translation using a tool like 2to3. This has seemed a bit of a fragile strategy to me but it is recommended by upstream python. > "Naming convention" proposal: > How does this sound: > - an rpm with a "python-" prefix means a python 2 rpm, of the > "default" python 2 minor version (for Fedora this will be the most > recent stable upstream minor release, for EPEL it will be the minor > release of 2 that came with the distro, so 2.4 for EPEL5) > > - an rpm with a "python3-" prefix means a python 3 rpm, of the > "default" python 3 minor version (for Fedora this will be the most > recent stable upstream release) > > What about packages without a "python-" prefix? Proposal: If upstream > has a naming convention for python2 vs python3, use it. Otherwise, add > a "python3-" prefix to make things clear. I'm not sure about the > details here. Examples? > +1 to the basics. There are a lot of details to work out: This seems fine even though it's a bit redundant: python3-pygtk2 and python3-pygpgme. What to do with things that have python in their suffix: gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or python3-gstreamer-python? Most of these are subpackages of existing packages. A cornercase is the gnome-python2 package. These are python bindings to gnome2. gnome-python2 is the upstream name. For python3, do we want python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? > A rough plan for Fedora 13 might be: > - get python3 packaged in a manner compatible with the above > - (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct > python when building rpms containing .py files) > - get rpm bindings working with python3 > - get some useful components working e.g. a web stack: Django, > TurboGears etc (though e.g. Django's py3k support is a long way off > IIRC); ideas? I'm going to go out on a limb and say this is a bigger goal than we'll be able to achieve for F13 but I like it :-) > - solidify packaging guidelines for python 2 vs python 3 once we've > got some experience with the above and hopefully proven the techniques Speaking from FPC experience, +1 to this. > - look at porting major components over to python3 (but probably don't > actually do this for F13; leave python 2 as the critical component, I > suspect): > - yum (rpm) > - anaconda > > However "no plan survives contact with the enemy", we'll see how things > turn out in reality when trying to get a full integrated stack working. > > Future work (F14?) could involve cutting over the major components, so > that the base install would bring in "python3", and "python" would > become optional. Obviously there's a _lot_ to be done before that can > be done sanely. > I'm going to say we'll be beyond F14 when this happens. F14 is roughly a year away and there's a ton of work to do. We may need to have more packagers *and* coders (python and C) to both modify code and maintain the new library packages and bindings. Porting the programs over isn't > = Progress so far = > I've put together a somewhat-working python3 srpm, based on the python > srpm (with lots of FIXMEs added...) It's not yet ready for a formal > package review (I'm working through the various patches, and it's not > yet fully installable in parallel with the python 2 stack), but you can > see the specfile here: > http://people.redhat.com/dmalcolm/python3/python3.spec > and an SRPM here: > http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm > > After I did this work, I saw that a couple of other people have written > Python 3 srpms for Fedora: > http://ivazquez.fedorapeople.org/packages/python3000/ I was just going to suggest you contact ivazquez :-) he's done a lot of work, both to get a python3 package working and on the update from python2.5 to python2.6. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From fedora at matbooth.co.uk Thu Oct 1 19:24:41 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Thu, 1 Oct 2009 20:24:41 +0100 Subject: PPC/PPC64 disabled in Koji for dist-f13 In-Reply-To: <20091001184012.GD5260@hansolo.jdub.homelinux.org> References: <20090928162112.GH5260@hansolo.jdub.homelinux.org> <4AC3E1FC.6070608@pobox.com> <1254353321.2242.34.camel@localhost.localdomain> <4AC3F721.7020605@pobox.com> <9497e9990910011042o327cfd5ajea38e7b5fa4dff59@mail.gmail.com> <20091001184012.GD5260@hansolo.jdub.homelinux.org> Message-ID: <9497e9990910011224y42632262o3fe4adb9d86aadd2@mail.gmail.com> 2009/10/1 Josh Boyer : > On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote: >>Nice bug; this one is my favourite: >>https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds >>don't expand %{_libdir} to the correct place. > > I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}' > repeated several times. > Eclipse is an archful package and that plonks files in %{_libdir} that are needed during the build of plugins that may or may not be noarch. -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? From harald at redhat.com Thu Oct 1 19:35:25 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 01 Oct 2009 21:35:25 +0200 Subject: HOWTO debug dracut Message-ID: <4AC5047D.8020609@redhat.com> * read the dracut man page * remove "rhgb" from the kernel command line and maybe "quiet" * add "rdshell" to the kernel command line and you are dropped to a shell * add "rdshell rdinitdebug" to the kernel command line and dracut shell commands are printed as they are executed * with dracut >= 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less From jlaska at redhat.com Thu Oct 1 19:43:25 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 01 Oct 2009 15:43:25 -0400 Subject: [Test-Announce] F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) Message-ID: <1254426205.2388.251.camel@localhost.localdomain> When: Friday, 2009-10-02 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net Join us this Friday for another alliterative installment of ... ... the Beta Blocker Bug review. Previous reviews have been successful at keeping the blocker bug list active. Let's continue this trend by reviewing the current list of unresolved F12Beta bugs [1]. The list of Fedora 12 Beta blocker bugs [1] includes: * 516042 - MODIFIED - Unable to add NFS yum repo during installation * 524599 - MODIFIED - Https repository problems * 519237 - ASSIGNED - bash: cannot set terminal process group (-1): Inappropriate ioctl for device * 522675 - ASSIGNED - mouse,keyboard don't work when boot from LiveCD * 526158 - NEW - font of f12 beta terminal is very big * 526208 - ASSIGNED - preupgrade failed from old release (f10, f11) * 526320 - ASSIGNED - ppc64.img and ppc32.img missing from tree * 526380 - NEW - Xorg update kills graphics * 526470 - NEW - NFSv3 mounting broken in dracut netboot Have an issue you'd like to propose for F12Beta? Please consider the following criteria when escalating an issue: * Can this issue be fixed with a future rawhide update or is it part of the critical path? [2] * Is this defect a high (or greater) severity [3] with no, or an unreasonable, workaround? * Does the presence of this bug dramatically reduce beta test coverage? See you there! James [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1 [2] https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_how_to_determine_packages_within_the_path [3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ test-announce mailing list test-announce at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce From pasik at iki.fi Thu Oct 1 19:51:36 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 1 Oct 2009 22:51:36 +0300 Subject: preupgrade from f11 to rawhide broken? python traceback In-Reply-To: References: <20090926161023.GZ31123@reaktio.net> Message-ID: <20091001195136.GN1434@reaktio.net> On Mon, Sep 28, 2009 at 01:01:32PM -0400, Seth Vidal wrote: > > > On Sat, 26 Sep 2009, Pasi K?rkk?inen wrote: > > >Hello, > > > >I have fully updated Fedora 11 x86_64 system, and when I run > >"preupgrade-cli" I get this: > > > >.. > >.. > >Saving Primary metadata > >Saving file lists metadata > >Saving other metadata > >Generating sqlite DBs > > > >(process:1779): GLib-WARNING **: GError set over the top of a previous > >GError or uninitialized memory. > >This indicates a bug in someone's code. You must ensure an error is NULL > >before it's set. > >The overwriting error message was: Parsing primary.xml error: Couldn't > >find end of Start Tag rpm:entry line 99665 > > > >Traceback (most recent call last): > > File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in > > pu.main(myrelease) > > File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main > > self.generate_repo(cachedir, comps) # TODO: callback? > > File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651, > > in generate_repo > > misc.generate_repodata(dir,comps,callback) > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in > > generate_repodata > > generate_repodata(dir, comps, callback) > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in > > generate_repodata_f9 > > mdgen.doRepoMetadata() > > File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829, > > in doRepoMetadata > > rp.getPrimary(complete_path, csum) > > File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in > > getPrimary > > self.repoid)) > >TypeError: Parsing primary.xml error: attributes construct error > > > > > >Known problem? How to fix it? > > this is the second time I've seen this one - if you can find > the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate > seeing it. > # ls /var/cache/yum fedora preupgrade updates # cd /var/cache/yum # find -iname '*primary*' ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite ./preupgrade/.repodata/primary.xml.gz ./preupgrade/.repodata/primary.xml.gz.sqlite ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite I put it available online here: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Firefox complains about it btw.. XML Parsing Error: not well-formed Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Line Number 42622, Column 68: -------------------------------------------------------------------^ -- Pasi From harald at redhat.com Thu Oct 1 19:59:50 2009 From: harald at redhat.com (Harald Hoyer) Date: Thu, 01 Oct 2009 21:59:50 +0200 Subject: HOWTO debug dracut In-Reply-To: <4AC5047D.8020609@redhat.com> References: <4AC5047D.8020609@redhat.com> Message-ID: <4AC50A36.1030801@redhat.com> Am 01.10.2009 21:35, schrieb Harald Hoyer: > * read the dracut man page > * remove "rhgb" from the kernel command line and maybe "quiet" > * add "rdshell" to the kernel command line and you are dropped to a shell > * add "rdshell rdinitdebug" to the kernel command line and dracut shell > commands are printed as they are executed > * with dracut >= 002-11 ( > http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can > inspect the rdinitdebug output with: > # less /init.log > and > # dmesg | less > oh, and you might be able to * mount /boot or * ifup eth0 and nfs mount a share to copy over /init.log or the whole dmesg output From jlaska at redhat.com Thu Oct 1 20:00:21 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 01 Oct 2009 16:00:21 -0400 Subject: HOWTO debug dracut In-Reply-To: <4AC5047D.8020609@redhat.com> References: <4AC5047D.8020609@redhat.com> Message-ID: <1254427221.2388.252.camel@localhost.localdomain> On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote: > * read the dracut man page > * remove "rhgb" from the kernel command line and maybe "quiet" > * add "rdshell" to the kernel command line and you are dropped to a shell > * add "rdshell rdinitdebug" to the kernel command line and dracut shell commands > are printed as they are executed > * with dracut >= 002-11 ( > http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect > the rdinitdebug output with: > # less /init.log > and > # dmesg | less It could probably use some more polish, but I've added your comments to https://fedoraproject.org/wiki/How_to_debug_Dracut_problems Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From awilliam at redhat.com Thu Oct 1 20:02:34 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 01 Oct 2009 13:02:34 -0700 Subject: HOWTO debug dracut In-Reply-To: <4AC5047D.8020609@redhat.com> References: <4AC5047D.8020609@redhat.com> Message-ID: <1254427354.2269.32.camel@adam.local.net> On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote: > * read the dracut man page > * remove "rhgb" from the kernel command line and maybe "quiet" > * add "rdshell" to the kernel command line and you are dropped to a shell > * add "rdshell rdinitdebug" to the kernel command line and dracut shell commands > are printed as they are executed > * with dracut >= 002-11 ( > http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect > the rdinitdebug output with: > # less /init.log > and > # dmesg | less Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin.kofler at chello.at Thu Oct 1 21:21:25 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 01 Oct 2009 23:21:25 +0200 Subject: Proposal: Python 3 in Fedora 13 References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: Jesse Keating wrote: > Ditto. This is not something you would push as an update to a released > product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Kevin Kofler From jkeating at redhat.com Thu Oct 1 21:25:15 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 01 Oct 2009 14:25:15 -0700 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: <1254432315.3120.5.camel@localhost.localdomain> On Thu, 2009-10-01 at 23:21 +0200, Kevin Kofler wrote: > Jesse Keating wrote: > > Ditto. This is not something you would push as an update to a released > > product. > > I don't see why a parallel-installable python3/python3000 would cause any > problems as an update. > > Kevin Kofler > The potential to disrupt the regular python, which is critically important to Fedora, makes me very wary of doing something like this on a release that is supposed to be and stay stable. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Thu Oct 1 21:35:33 2009 From: poelstra at redhat.com (John Poelstra) Date: Thu, 01 Oct 2009 14:35:33 -0700 Subject: Buyer Beware: A Major Change in NFS is about to happen In-Reply-To: References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com> <1254293108.2242.17.camel@localhost.localdomain> <1254335788.2242.27.camel@localhost.localdomain> <20091001021938.GW5260@hansolo.jdub.homelinux.org> Message-ID: <4AC520A5.1070001@redhat.com> Kevin Kofler said the following on 10/01/2009 02:28 AM Pacific Time: > So I'll have to blame the previous FESCo for voting this through with > practically no feedback, as they observed themselves before the vote: > 17:14:04 has there been any feedback on lists or wiki? > 17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion > page > 17:14:25 yeah, haven't seen much The current FESCo might also want to consider taking more of a leadership role in monitoring the release processes, tracking the schedule, and evaluating the quality of the release under development and our ability to release on time. As the group responsible for guiding the technical direction of our releases I think this is something they should be more involved in. I'd be glad to help gather data they might need to do this and there might be others who would be willing to help too. I'm suggesting more proactive leadership from FESCo and clear initiatives to take Fedora to the next level versus only being responsible for approving features, proven packagers, and policy matters. This is also my vision for the Fedora Board. > But in any case, I don't think any of us realized the amount of maintainer > confusion this would cause (I know I didn't or I would have complained on > the mailing list right when this was proposed). In hindsight, it was > definitely a mistake. This thread is just one of the examples of maintainers > having been led to believe they have more time to develop their features > than they actually do, I've seen several more while sitting in FESCo feature > meetings. We should fix the mistake at the first opportunity (Fedora 13). > In other threads developers complained that the schedule was greatly shortened (not completely true either). It is unreasonable to assume that before the change to "Alpha" and "Beta" for Fedora 12, that EVERYONE was clear what happened in "Alpha," "Beta," and "Preview" in the previous releases. That has never been the case. Labeling "Alpha," "Beta," and "Preview" were not evaluated based on their actual industry meanings but were relabeled from the original test1," "test2," and "test3," which were equally unclear. At the same time, when the change for Fedora 12 was proposed it was based on a variety of experiences and reactions to our previous test phases and schedule changes for Fedora 12. It lacked hard data and we still don't have any clear criteria to determine which way is better or measure the results. So it is hard to argue that switching back would be any better, though my "gut" says it would... I know other "guts" will disagree ;-) We need some guiding criteria or we're just going to keep going around in circles. This is one reason I believe defining our target audience and defining what we want to create and be (separate board thread on fedora-advisory-board list) matters a great deal. John From cmadams at hiwaay.net Thu Oct 1 22:14:03 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 Oct 2009 17:14:03 -0500 Subject: Proposal: Python 3 in Fedora 13 In-Reply-To: References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <20091001175910.GB5260@hansolo.jdub.homelinux.org> Message-ID: <20091001221403.GD1072031@hiwaay.net> Once upon a time, Kevin Kofler said: > Jesse Keating wrote: > > Ditto. This is not something you would push as an update to a released > > product. > > I don't see why a parallel-installable python3/python3000 would cause any > problems as an update. Are you able to guarantee that it will in no way interfere with python2 (including in the build root)? Major changes like that during a release are what get Fedora considered a "rolling beta" quality distribution. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From johannbg at hi.is Thu Oct 1 22:09:54 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 01 Oct 2009 22:09:54 +0000 Subject: HOWTO debug dracut In-Reply-To: <1254427354.2269.32.camel@adam.local.net> References: <4AC5047D.8020609@redhat.com> <1254427354.2269.32.camel@adam.local.net> Message-ID: <4AC528B2.6070107@hi.is> On 10/01/2009 08:02 PM, Adam Williamson wrote: > On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote: > >> * read the dracut man page >> * remove "rhgb" from the kernel command line and maybe "quiet" >> * add "rdshell" to the kernel command line and you are dropped to a shell >> * add "rdshell rdinitdebug" to the kernel command line and dracut shell commands >> are printed as they are executed >> * with dracut>= 002-11 ( >> http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect >> the rdinitdebug output with: >> # less /init.log >> and >> # dmesg | less >> > Please also see > https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the > permanent reference for this topic. I'll add anything in Harald's mail > that's not currently on that page to it. Thanks. > > Is this the new format/path of debugging pages for a given component how_to_debug__problem as opposed to https://fedoraproject.org/wiki/Dracut/Debugging or /Debugging> and are we going to move all debugging pages under how_to_debug?? Who ever changed the original one should take the time and update https://fedoraproject.org/wiki/Dracut/Options to current options listen in git logs or atleast the man page and remove all 
 and {{admon}} 
to make it consistent with the new debugging page..

JBG



From awilliam at redhat.com  Thu Oct  1 22:26:05 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 01 Oct 2009 15:26:05 -0700
Subject: HOWTO debug dracut
In-Reply-To: <4AC528B2.6070107@hi.is>
References: <4AC5047D.8020609@redhat.com>
	<1254427354.2269.32.camel@adam.local.net>  <4AC528B2.6070107@hi.is>
Message-ID: <1254435965.2269.41.camel@adam.local.net>

On Thu, 2009-10-01 at 22:09 +0000, "J?hann B. Gu?mundsson" wrote:

> > Please also see
> > https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the
> > permanent reference for this topic. I'll add anything in Harald's mail
> > that's not currently on that page to it. Thanks.
> >
> >    
> Is this the new format/path of debugging pages for a given component 
> how_to_debug__problem as opposed to 
> https://fedoraproject.org/wiki/Dracut/Debugging  or 
> /Debugging> and are we going to move all debugging pages 
> under how_to_debug??

It hasn't been officially discussed anywhere - I was using
Bug_info_componentname myself - but I think it's a good choice by
whoever came up with it. It also fits in with the request of the Wiki
admin team that we use flat page names, not nested ones.

> Who ever changed the original one should take the time and update 
> https://fedoraproject.org/wiki/Dracut/Options to current options listen 
> in git logs or atleast the man page and remove all 
 and {{admon}} 
> to make it consistent with the new debugging page..

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From kevin.kofler at chello.at  Thu Oct  1 22:53:21 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 02 Oct 2009 00:53:21 +0200
Subject: Buyer Beware: A  Major Change in NFS is about to happen
References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<1254293108.2242.17.camel@localhost.localdomain>
	
	
	
	<1254335788.2242.27.camel@localhost.localdomain>
	
	<20091001021938.GW5260@hansolo.jdub.homelinux.org>
	 <4AC520A5.1070001@redhat.com>
Message-ID: 

John Poelstra wrote:
> The current FESCo might also want to consider taking more of a
> leadership role in monitoring the release processes, tracking the
> schedule, and evaluating the quality of the release under development
> and our ability to release on time.  As the group responsible for
> guiding the technical direction of our releases I think this is
> something they should be more involved in.  I'd be glad to help gather
> data they might need to do this and there might be others who would be
> willing to help too.
> 
> I'm suggesting more proactive leadership from FESCo and clear
> initiatives to take Fedora to the next level versus only being
> responsible for approving features, proven packagers, and policy matters.

And when should we find the time for that? Our meetings already usually take 
2 hours, and during the rest of the week, we have other things to do as 
well. Being on FESCo is not a paid full-time job!

        Kevin Kofler



From dmalcolm at redhat.com  Thu Oct  1 23:05:25 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Thu, 01 Oct 2009 19:05:25 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <4AC50044.6090804@gmail.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	<4AC50044.6090804@gmail.com>
Message-ID: <1254438325.9551.96.camel@radiator.bos.redhat.com>

On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote:
> On 10/01/2009 10:15 AM, David Malcolm wrote:
> > Proposal: Python 3 in Fedora 13
> > 
> > "Evolutionary, not revolutionary": build a python 3 stack
> > parallel-installable with the python 2 stack.
> > 
> 
> First: Overall +1.
> 
> Note: liberally snipped, throughout.

[likewise snipped lots of stuff]


> > "Naming convention" proposal:
> > How does this sound:
> >   - an rpm with a "python-" prefix means a python 2 rpm, of the
> > "default" python 2 minor version (for Fedora this will be the most
> > recent stable upstream minor release, for EPEL it will be the minor
> > release of 2 that came with the distro, so 2.4 for EPEL5)
> > 
> >   - an rpm with a "python3-" prefix means a python 3 rpm, of the
> > "default" python 3 minor version (for Fedora this will be the most
> > recent stable upstream release)
> > 
> > What about packages without a "python-" prefix?  Proposal:  If upstream
> > has a naming convention for python2 vs python3, use it.  Otherwise, add
> > a "python3-" prefix to make things clear.  I'm not sure about the
> > details here.  Examples?
> >  
> +1 to the basics.  There are a lot of details to work out:

[snip the details]

Thanks.  Given that, I went ahead and created a Feature page for this:
https://fedoraproject.org/wiki/Features/Python3F13

So far it's mostly just a restatement of my post, though I've started
fleshing out some sections e.g. "how to test".  I've assumed the naming
convention from my post "python3" for the srpm, and for the symlink to
the binary.  

Feel free to dive in and edit.  I marked myself as owner of the feature
as I know I'm going to be able to devote a big chunk of time to this.
Hope that's OK.

We now have 3 competing srpms for Python 3:
(i) the one from ivazquez:
> >   http://ivazquez.fedorapeople.org/packages/python3000/
("python3000")

(ii) the one by Andrew McNabb:
https://bugzilla.redhat.com/show_bug.cgi?id=526126 (named "python3")

(iii) and the one I did, also named "python3":
> >   http://people.redhat.com/dmalcolm/python3/python3.spec
> > and an SRPM here:
> >   http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm


> I was just going to suggest you contact ivazquez :-)  he's done a lot of
> work, both to get a python3 package working and on the update from
> python2.5 to python2.6.
I'm assuming ivazquez is seeing these emails (I _think_ he said he'd
seen it on IRC earlier today), and I added a link to my email to the
review bug above so hopefully Andrew is seeing this.

I hope to have a look at the commonality/differences between the 3
efforts tomorrow.  I think "python3" is a better name (if nothing else,
it's shorter to type!).

I'd like it if the eventually python 3 specfile could resemble the
python 2 specfile so that we can meaningfully look at the textual diffs
between them (but it may be necessary to clean up the python specfile to
achieve this!  I'll try to have a look at the merge-review)

Thanks for the feedback; hope this all sounds sane
Dave



From MathStuf at gmail.com  Thu Oct  1 23:12:31 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Thu, 01 Oct 2009 19:12:31 -0400
Subject: Proposal: Python 3 in Fedora 13
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David Malcolm wrote:
> "Naming convention" proposal:
> How does this sound:
>   - an rpm with a "python-" prefix means a python 2 rpm, of 
the
> "default" python 2 minor version (for Fedora this will be the 
most
> recent stable upstream minor release, for EPEL it will be the 
minor
> release of 2 that came with the distro, so 2.4 for EPEL5)
> 
>   - an rpm with a "python3-" prefix means a python 3 rpm, of 
the
> "default" python 3 minor version (for Fedora this will be the 
most
> recent stable upstream release)
> 
>  (we could extend this to have specific minor-releases (e.g. 
use
> "python24-" for a python 2.4 stack, in case some brave soul 
wants to get
> zope/plone running.  But may be better to try to fix the 
zope/2.6
> incompatibility at that point (caveat: haven't looked at the 
details of
> the issue).  I don't intend to work on such versions))
> 
> What about packages without a "python-" prefix?  Proposal:  If 
upstream
> has a naming convention for python2 vs python3, use it.  
Otherwise, add
> a "python3-" prefix to make things clear.  I'm not sure about 
the
> details here.  Examples?
>  
> There have been various discussions upstream about what to 
call the
> python 3 binary.  My favorite quote on the subject is from 
Guido,
> http://mail.python.org/pipermail/python-3000/2008-
March/012421.html :
>> During the next 3 years or so, installing Py3k as the default 
"python"
>> will be a deed of utter irresponsibility and is likely to 
break your
>> system in subtle ways (both OSX and Linux these days use 
Python for
>> certain system tasks). If you *really* want to shoot yourself 
in the
>> foot this way, go ahead and explicitly use "make altinstall
>> bininstall" or link it yourself.
> 
> I propose that for Fedora we have "/usr/bin/python3" for the
> system/default version of python 3 and "/usr/bin/python" for 
the
> system/default version of python 2.  Both would be symlinks to 
a binary
> with the minor-release embedded in the name 
("/usr/bin/python3.1" and
> "/usr/bin/python/2.6").
> 
> As I understand things, this should make us broadly in 
agreement with
> upstream; see e.g.:
> http://mail.python.org/pipermail/python-dev/2009-
April/088862.html
> http://mail.python.org/pipermail/python-dev/2009-
April/088884.html

Could we do something similar to what qt and kdelibs packages 
have done? While qt3 was default, the 'qt' package points to qt3 
and qt4 is an entirely separate package. When qt4 became 
default, qt3 was the one with the explicit version on it (and 
qt4 still exists, but the default 'qt' is qt4 now). This would 
mean that python2 packages grow 'Provides: python2-foo = 
%{version}-%{release}'. When python3 is the default, then have 
python point to python3 (and we can drop the Provides/Obsoletes 
for python3- prefixed packages later if wanted).

My thought process is that I would not like, after python3 is 
the default, to still have to put the explicit 3 on there 
because python is still python2. Just thinking ahead here.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKxTdfAAoJEKaxavVX4C1Xdf0QANdjkM1iZhZfnxSLErl8qsrr
Eqhg51xTZdolE/8/Z08DTxE3EF5yj5BsfGPgTfiyTgzqiFgMYpAxU6NYKRZI0WmL
C3eC8oHMINRJGotklzHZiTnyUbZd2MZQuPWhMljOchOGOTktT9oaXZND/co1Aixo
xNVqXLYQAYWAlF0A0fjVJ12x2eq4jcG8d2rDaOmiXMj4UTI1ZfVFyofBHm++4hUB
dQ6JNrN11Tzd7fOnGZKvLUgvfEOXlP8K51dFKiaZI+iBxvU14GnU4e7p3ri4CEjT
CKk8AzSKkwLcKk8ipCwN3+BvLCMvq91RtBoh1amhevCg2FgULnbe2ZWv9qhZkpJg
EG4HVCbhXgeMvIbX6prGMtcDAe4X8QNesMX2C7OCqwwkFDea9qSNCb7ZLVscGCZQ
OeRKfgD7DN1XnH/6F2a6p5lxNQF6EQ0G7oWjloSwWtOCNLTU+pDI1waTPM74yh/Y
1sabs31wYUi+gbW3sFqfWoMnkAisKRLXeKzxsZvotz4R87+GEwoV1ZZJNL+NWvZz
V+IGhU+B6PTu8Jo6KfV2xJ6Y0kx8qKSlk9LdiZ9RKTyxgnZVaxj3YJceeUv1TSI/
U8xVwEjcMxDdink2NBlyGkd+its4+9ZlShHLMOKdYIAnibov72WlMLKXYNr8plpO
kQYYB0B/z9A1fXFxNqKu
=dgBR
-----END PGP SIGNATURE-----




From dmalcolm at redhat.com  Thu Oct  1 23:26:21 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Thu, 01 Oct 2009 19:26:21 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: 
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
Message-ID: <1254439581.9551.113.camel@radiator.bos.redhat.com>

On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> David Malcolm wrote:
> > "Naming convention" proposal:
> > How does this sound:
> >   - an rpm with a "python-" prefix means a python 2 rpm, of 
> the
> > "default" python 2 minor version (for Fedora this will be the 
> most
> > recent stable upstream minor release, for EPEL it will be the 
> minor
> > release of 2 that came with the distro, so 2.4 for EPEL5)
> > 
> >   - an rpm with a "python3-" prefix means a python 3 rpm, of 
> the
> > "default" python 3 minor version (for Fedora this will be the 
> most
> > recent stable upstream release)
> > 
> >  (we could extend this to have specific minor-releases (e.g. 
> use
> > "python24-" for a python 2.4 stack, in case some brave soul 
> wants to get
> > zope/plone running.  But may be better to try to fix the 
> zope/2.6
> > incompatibility at that point (caveat: haven't looked at the 
> details of
> > the issue).  I don't intend to work on such versions))
> > 
> > What about packages without a "python-" prefix?  Proposal:  If 
> upstream
> > has a naming convention for python2 vs python3, use it.  
> Otherwise, add
> > a "python3-" prefix to make things clear.  I'm not sure about 
> the
> > details here.  Examples?
> >  
> > There have been various discussions upstream about what to 
> call the
> > python 3 binary.  My favorite quote on the subject is from 
> Guido,
> > http://mail.python.org/pipermail/python-3000/2008-
> March/012421.html :
> >> During the next 3 years or so, installing Py3k as the default 
> "python"
> >> will be a deed of utter irresponsibility and is likely to 
> break your
> >> system in subtle ways (both OSX and Linux these days use 
> Python for
> >> certain system tasks). If you *really* want to shoot yourself 
> in the
> >> foot this way, go ahead and explicitly use "make altinstall
> >> bininstall" or link it yourself.
> > 
> > I propose that for Fedora we have "/usr/bin/python3" for the
> > system/default version of python 3 and "/usr/bin/python" for 
> the
> > system/default version of python 2.  Both would be symlinks to 
> a binary
> > with the minor-release embedded in the name 
> ("/usr/bin/python3.1" and
> > "/usr/bin/python/2.6").
> > 
> > As I understand things, this should make us broadly in 
> agreement with
> > upstream; see e.g.:
> > http://mail.python.org/pipermail/python-dev/2009-
> April/088862.html
> > http://mail.python.org/pipermail/python-dev/2009-
> April/088884.html
> 
> Could we do something similar to what qt and kdelibs packages 
> have done? While qt3 was default, the 'qt' package points to qt3 
> and qt4 is an entirely separate package. When qt4 became 
> default, qt3 was the one with the explicit version on it (and 
> qt4 still exists, but the default 'qt' is qt4 now). This would 
> mean that python2 packages grow 'Provides: python2-foo = 
> %{version}-%{release}'. When python3 is the default, then have 
> python point to python3 (and we can drop the Provides/Obsoletes 
> for python3- prefixed packages later if wanted).
> 
> My thought process is that I would not like, after python3 is 
> the default, to still have to put the explicit 3 on there 
> because python is still python2. Just thinking ahead here.

Thanks!  If I'm correctly reading your mail, this approach is one I did
think of, but I'm not fond of it.

I think that anyone dealing with Python is going to have to be thinking
"is this python 2 or python 3" for some years to come, so having an
explicit "python3-" prefix is probably not too painful.

What I think would be painful in your suggestion is the flag day where
we'd change the meaning of "python-" in RPM names.  Currently in Fedora
and EPEL, "python-" implies the system-supplied minor release of python
2, be it in Fedora (2.6), or in EPEL (2.4).  I worry that changing it to
imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by
that point) would be thoroughly confusing, since we'd have to update
everything all at once.  It wouldn't fly within EPEL, since the
pre-existing Enterprise downstreams of Fedora aren't going to change
(far too disruptive).

One middle ground might be to start using "python2-" explicitly for
_new_ packages.  That wouldn't break anything, but could easily be
confusing as well.  I think I prefer keeping things consistent.

Perhaps at some point we could cut over "/usr/bin/python" from being
Python 2 to Python 3, but I refer you again to this quote from Guido:
http://mail.python.org/pipermail/python-3000/2008-March/012421.html


(The other fun thing to do might be to package Unladen Swallow.  Not at
all sure what to call _that_ though!)

Dave



From johannbg at hi.is  Thu Oct  1 23:39:37 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Thu, 01 Oct 2009 23:39:37 +0000
Subject: HOWTO debug dracut
In-Reply-To: <1254435965.2269.41.camel@adam.local.net>
References: <4AC5047D.8020609@redhat.com>	<1254427354.2269.32.camel@adam.local.net>
	<4AC528B2.6070107@hi.is> <1254435965.2269.41.camel@adam.local.net>
Message-ID: <4AC53DB9.9030103@hi.is>

On 10/01/2009 10:26 PM, Adam Williamson wrote:
> On Thu, 2009-10-01 at 22:09 +0000, "J?hann B. Gu?mundsson" wrote:
>
>    
>>> Please also see
>>> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the
>>> permanent reference for this topic. I'll add anything in Harald's mail
>>> that's not currently on that page to it. Thanks.
>>>
>>>
>>>        
>> Is this the new format/path of debugging pages for a given component
>> how_to_debug__problem as opposed to
>> https://fedoraproject.org/wiki/Dracut/Debugging  or
>> /Debugging>  and are we going to move all debugging pages
>> under how_to_debug??
>>      
> It hasn't been officially discussed anywhere - I was using
> Bug_info_componentname myself - but I think it's a good choice by
> whoever came up with it. It also fits in with the request of the Wiki
> admin team that we use flat page names, not nested ones.
>
>    

Well I think the documentation team ( doc list cc-ed ) should provide us 
with rules and regulation ( or templates ) on how component page should 
be written including bug reporting etc.. and who the target audience is 
so at-least some consistency exist in the wiki, I personally write pages 
targeted at novice end user so they tend to be more step by step 
oriented since I believe that we should expose testing of a component to 
as wide audience as possible regardless of the individual skill ( it 
might be a kid taking his first step into the linux, Fedora community 
and participate or it might be an experienced user ) set while other 
voices in the community think that they should have University, RHCE or 
some other degree stuck up their ass to be able to participate in 
testing or other aspects of the community. When an indvidual changes the 
layout of my wiki written pages ( other than simply fix my ken-lee 
English ) I believe ( since he thinks he does a better job than me 
delivering the content of the page to well what he sees as the target 
audience ) that he will maintain the given component pages and keep it 
update to upstream documentation.  ( since he has the time to totally 
rewrite the page he should have the time to do the necessary research 
and keep it updated to upstream documentation/changes/git logs  ). It's 
not enough simply write those pages they need to be maintained and 
updated as well and I for one don't participate in wiki writing ping 
pong game..

JBG



From awilliam at redhat.com  Thu Oct  1 23:53:18 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 01 Oct 2009 16:53:18 -0700
Subject: HOWTO debug dracut
In-Reply-To: <4AC53DB9.9030103@hi.is>
References: <4AC5047D.8020609@redhat.com>
	<1254427354.2269.32.camel@adam.local.net> <4AC528B2.6070107@hi.is>
	<1254435965.2269.41.camel@adam.local.net>  <4AC53DB9.9030103@hi.is>
Message-ID: <1254441198.2269.51.camel@adam.local.net>

On Thu, 2009-10-01 at 23:39 +0000, "J?hann B. Gu?mundsson" wrote:
> set while other 
> voices in the community think that they should have University, RHCE
> or 
> some other degree stuck up their ass to be able to participate in 
> testing or other aspects of the community 

I think you're setting up a straw man here. I haven't seen anyone on
this list suggest any such thing, and I don't see that any of the
existing pages are intentionally written in this way. It would be good
to have consistent styles for such pages, but there's no need to set it
up in such a confrontational way.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From MathStuf at gmail.com  Fri Oct  2 00:26:59 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Thu, 01 Oct 2009 20:26:59 -0400
Subject: Proposal: Python 3 in Fedora 13
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
	<1254439581.9551.113.camel@radiator.bos.redhat.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David Malcolm wrote:
> On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
>> Could we do something similar to what qt and kdelibs packages 
>> have done? While qt3 was default, the 'qt' package points to 
qt3 
>> and qt4 is an entirely separate package. When qt4 became 
>> default, qt3 was the one with the explicit version on it (and 
>> qt4 still exists, but the default 'qt' is qt4 now). This 
would 
>> mean that python2 packages grow 'Provides: python2-foo = 
>> %{version}-%{release}'. When python3 is the default, then 
have 
>> python point to python3 (and we can drop the 
Provides/Obsoletes 
>> for python3- prefixed packages later if wanted).
>> 
>> My thought process is that I would not like, after python3 is 
>> the default, to still have to put the explicit 3 on there 
>> because python is still python2. Just thinking ahead here.
> 
> Thanks!  If I'm correctly reading your mail, this approach is 
one I did
> think of, but I'm not fond of it.
> 
> I think that anyone dealing with Python is going to have to be 
thinking
> "is this python 2 or python 3" for some years to come, so 
having an
> explicit "python3-" prefix is probably not too painful.
Package names wouldn't change for some time. Guido says 2--3 
years, so python meaning python3 is some time away yet.

> What I think would be painful in your suggestion is the flag 
day where
> we'd change the meaning of "python-" in RPM names.  Currently 
in Fedora
> and EPEL, "python-" implies the system-supplied minor release 
of python
> 2, be it in Fedora (2.6), or in EPEL (2.4).  I worry that 
changing it to
> imply the system-supplied minor release of Python 3 (3.1, or 
3.2/3.3? by
> that point) would be thoroughly confusing, since we'd have to 
update
> everything all at once.  It wouldn't fly within EPEL, since 
the
> pre-existing Enterprise downstreams of Fedora aren't going to 
change
> (far too disruptive).
This is where the 'Provides: python2-foo' kicks in. 'Requires:' 
in other packages would be updated to point to the python2-foo 
Provides for dependency solving. Over time, packages should be 
updated and if some deadline isn't met, start opening bugs, then 
finally using provenpackager when another deadline is hit. Even 
after the change, python3 packages would Provides/Obsoletes 
their old python3- names but would be moved to have the main 
package name be python-. Dependency chains should hold as long 
as the python2- and python3- Requires are used instead of the 
python- ones.

> One middle ground might be to start using "python2-" 
explicitly for
> _new_ packages.  That wouldn't break anything, but could 
easily be
> confusing as well.  I think I prefer keeping things 
consistent.
This would still leave python2 to hold claim to the python- 
prefix and python3- left with the 3 in it. And I am for 
consistency here.

> Perhaps at some point we could cut over "/usr/bin/python" from 
being
> Python 2 to Python 3, but I refer you again to this quote from 
Guido:
> http://mail.python.org/pipermail/python-3000/2008-
March/012421.html
Yes, and after that time, what? Always use python3? I'd like to 
start a transition route worked out now before we start down 
towards python3 so that things aren't rushed later.

> (The other fun thing to do might be to package Unladen 
Swallow.  Not at
> all sure what to call _that_ though!)
Hopefully these changes will get merged some day. A faster 
python is on my list of wants for python (as well as a debugger 
and a valgrind-like tool to see where loose references are being 
kept).

> Dave

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKxUjTAAoJEKaxavVX4C1XuycQANByZEaH5Z0894ajjQKkEaaE
IG35V4n1WBVVR/77UPh5sBtJtRvsYXIGduYDdZZL/cwAq8LXS8Kn0j8yOB8Y0V0z
bU6WzAb6UAyZqxRYVL1DKsELAbzonqSTHr9g1as3bGiEsZchKjKNLM+C+RRGMpGr
mgkWCZyyuCEUzt+fZSaQ11TMat2eWApLyDuNupmSkCIxzG7EI5R8ovYT2jiQ732W
YUfnclY9sU3T/KhRUHsHCDsGsJOJMzt3SfZxrCgKzfdh3C/RuIi7v3u//1szGLk4
eK0XTruPwNrmkd7/kOwkjyFDVI/HnGWwvGnljz2bMfPC9he3qJdmPC03X1a91hTR
M6Bljqd4m52X/IebPx+O4i9oEXByaK+UwYkvliEqUqPXdjYijGogTha0KQP8F1RU
b0LFuPy1/MZ99Vizl++gwIKu5cXRuOu00H+G7sRbb0SnhY8qZUcz8HvgAR141lwY
d34f8jnxCXlu0KorxHhg6qMstD6EoATA0wfPeGwPv8MWB6YD3ar5q8vkLykb6qQ/
VJONpAwNLMGGv03IzC60HG+s0kDlcJkdRjPzs20lj1siKS8N4Oza0FvBFFCcyCA5
G1w3BEzAILv2SbxCs9KRrvdUSjVmjC2HKnmYcT2wlv8Hv8Ec5BsN19i/UaYIAD/1
P5VAEUJafmJPovLw2oR6
=GaN9
-----END PGP SIGNATURE-----




From jwboyer at gmail.com  Fri Oct  2 00:51:08 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 1 Oct 2009 20:51:08 -0400
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: 
References: <1254293108.2242.17.camel@localhost.localdomain>
	
	
	
	<1254335788.2242.27.camel@localhost.localdomain>
	
	<20091001021938.GW5260@hansolo.jdub.homelinux.org>
	 <4AC520A5.1070001@redhat.com>
	
Message-ID: <20091002005108.GG5260@hansolo.jdub.homelinux.org>

On Fri, Oct 02, 2009 at 12:53:21AM +0200, Kevin Kofler wrote:
>John Poelstra wrote:
>> The current FESCo might also want to consider taking more of a
>> leadership role in monitoring the release processes, tracking the
>> schedule, and evaluating the quality of the release under development
>> and our ability to release on time.  As the group responsible for
>> guiding the technical direction of our releases I think this is
>> something they should be more involved in.  I'd be glad to help gather
>> data they might need to do this and there might be others who would be
>> willing to help too.
>> 
>> I'm suggesting more proactive leadership from FESCo and clear
>> initiatives to take Fedora to the next level versus only being
>> responsible for approving features, proven packagers, and policy matters.
>
>And when should we find the time for that? Our meetings already usually take 
>2 hours, and during the rest of the week, we have other things to do as 

How about starting now?  Our last two meetings took about 20 min combined.

We're through the Feature process mostly, and we're entering the part of the
development cycle that people need help with, reminders for, planning, etc.

I actually agree with some of what John said.  I had a discussion with
someone earlier today that echoed many of those sentiments.

josh



From johannbg at hi.is  Fri Oct  2 01:35:13 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Fri, 02 Oct 2009 01:35:13 +0000
Subject: HOWTO debug dracut
In-Reply-To: <1254441198.2269.51.camel@adam.local.net>
References: <4AC5047D.8020609@redhat.com>	<1254427354.2269.32.camel@adam.local.net>
	<4AC528B2.6070107@hi.is>	<1254435965.2269.41.camel@adam.local.net>
	<4AC53DB9.9030103@hi.is> <1254441198.2269.51.camel@adam.local.net>
Message-ID: <4AC558D1.6020605@hi.is>

On 10/01/2009 11:53 PM, Adam Williamson wrote:
> On Thu, 2009-10-01 at 23:39 +0000, "J?hann B. Gu?mundsson" wrote:
>    
>> set while other
>> voices in the community think that they should have University, RHCE
>> or
>> some other degree stuck up their ass to be able to participate in
>> testing or other aspects of the community
>>      
> I think you're setting up a straw man here. I haven't seen anyone on
> this list suggest any such thing, and I don't see that any of the
> existing pages are intentionally written in this way. It would be good
> to have consistent styles for such pages, but there's no need to set it
> up in such a confrontational way.
>
>    

As I said "other voices" I never said they resided on this list ( I dont 
keep tap who's on this list or any other list for that matter ) however 
you should recall atleast one such debate when we rewrote/redesigned the 
QA frontpage on the wiki..  I feel we definitively needs some wiki rules 
and regulations. When I started to write wiki pages I was pointed out 
that I should write those pages on my name space followed by pointing 
other members of the community to that page and if the community was 
happy with the content/layout it would be move to the front  if not I 
should A) rewrite the page according to suggestion and resubmit or B) 
those that did not agree with the content layout of that page should 
draft what ever they think it should look like and submit that. if I 
would change an already published wiki page I should comment in the page 
it self why I made those changes . Now I had barely finished wikifying 
for example Sysrq ( Now  https://fedoraproject.org/wiki/QA/Sysrq ) and 
was waiting for feed back from the community ( for example if it was 
simple/clear enough ) when it got yanked out of my personal space and 
dump where it resides now ( which probably not where the wiki admins 
want it to reside ). Either we create pages at will submit them when 
accepted they get move to the front then if a rewriting ( other than 
minor changes such as typo fixing etc ) occurs the individual that wants 
to rewrite the current page does so on his own name space and submits 
his changes or everybody hack everything everywhere on the wiki and 
constantly play wiki rewriting ping pong game of how their perception on 
how things should look/be written. One half says user your own namespace 
and submit your suggestion comment when changing.the other halfs says 
wanna change something on the wiki change it. I think the community 
needs to agree on which way it should be.

JBG

PS.
      Good coders make crappy documents. If and when they find the time 
to write them they usually tend to be to technical/development oriented 
even tho the indented audience is the end user.



From jonstanley at gmail.com  Fri Oct  2 02:50:59 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 1 Oct 2009 22:50:59 -0400
Subject: Plan for tomorrow's (20091002) FESCo meeting
Message-ID: 

Sorry for the late notice.  There's only one agenda item for
tomorrow's FESCo meeting, and that's the dropping of features that are
not yet 100% complete.  The meeting will be held tomorrow at 17:00UTC
(13:00EDT) in #fedora-meeting on irc.freenode.net

I've also copied the relevant feature owners, in the hopes this winds
up in their inbox :)

The features proposed to be dropped (also in FESCo ticket 254):

https://fedoraproject.org/wiki/Features/DisplayPort
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
https://fedoraproject.org/wiki/Features/NFSv4Default



From jonstanley at gmail.com  Fri Oct  2 03:04:47 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 1 Oct 2009 23:04:47 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <4AC50044.6090804@gmail.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com> 
	<4AC50044.6090804@gmail.com>
Message-ID: 

On Thu, Oct 1, 2009 at 3:17 PM, Toshio Kuratomi  wrote:

> I don't see any way around this atm but it is something to think about
> possibilities more.

One way around this that I use at $DAYJOB (to minimize exposure of a
PHP enabled webserver, thus minimizing attack surface, and also
allowing apache to fail for a site without taking 15 unrelated sites
with it), is to actually have two separate instances of httpd running,
one with mod_python, and the other with mod_python3.  Of course this
requires manual intervention on the part of the local admin, but I
would think that any admin that wanted to do this would be
sufficiently competent to handle the intricacies of that choice.



From jonstanley at gmail.com  Fri Oct  2 03:34:32 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 1 Oct 2009 23:34:32 -0400
Subject: Buyer Beware: A Major Change in NFS is about to happen
In-Reply-To: <20091002005108.GG5260@hansolo.jdub.homelinux.org>
References: <1254293108.2242.17.camel@localhost.localdomain> 
	
	 
	<1254335788.2242.27.camel@localhost.localdomain>
	 
	<20091001021938.GW5260@hansolo.jdub.homelinux.org>
	 
	<4AC520A5.1070001@redhat.com>  
	<20091002005108.GG5260@hansolo.jdub.homelinux.org>
Message-ID: 

On Thu, Oct 1, 2009 at 8:51 PM, Josh Boyer  wrote:

> How about starting now? ?Our last two meetings took about 20 min combined.
>
> We're through the Feature process mostly, and we're entering the part of the
> development cycle that people need help with, reminders for, planning, etc.
>
> I actually agree with some of what John said. ?I had a discussion with
> someone earlier today that echoed many of those sentiments.

+1. I've been sorta lax in this area, due to a whole bunch of things,
a large one of which is $DAYJOB, which keeps me *quite* busy.
However, for the original topic of this thread, I 100% agree that we
should have noticed that NFSv4 mounts weren't the default and pestered
Steve about that.  This is a Big Thing(TM) that someone with the
visibility that we have into the feature process should have noticed,
since that was the entire point of the feature!

At $DAYJOB I get to harp on the proactive vs. reactive bit.  I think
it's about the same that we do the same, where we can, in Fedora as
well.



From awilliam at redhat.com  Fri Oct  2 04:02:11 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 01 Oct 2009 21:02:11 -0700
Subject: HOWTO debug dracut
In-Reply-To: <4AC558D1.6020605@hi.is>
References: <4AC5047D.8020609@redhat.com>
	<1254427354.2269.32.camel@adam.local.net> <4AC528B2.6070107@hi.is>
	<1254435965.2269.41.camel@adam.local.net> <4AC53DB9.9030103@hi.is>
	<1254441198.2269.51.camel@adam.local.net>  <4AC558D1.6020605@hi.is>
Message-ID: <1254456131.2269.56.camel@adam.local.net>

On Fri, 2009-10-02 at 01:35 +0000, "J?hann B. Gu?mundsson" wrote:

> As I said "other voices" I never said they resided on this list ( I dont 
> keep tap who's on this list or any other list for that matter ) however 
> you should recall atleast one such debate when we rewrote/redesigned the 
> QA frontpage on the wiki..  I feel we definitively needs some wiki rules 

It would help if you'd split things into paragraphs, my eyes keep
glazing over after four lines...

> and regulations. When I started to write wiki pages I was pointed out 
> that I should write those pages on my name space followed by pointing 
> other members of the community to that page and if the community was 
> happy with the content/layout it would be move to the front  if not I 
> should A) rewrite the page according to suggestion and resubmit or B) 
> those that did not agree with the content layout of that page should 
> draft what ever they think it should look like and submit that. 

That's the procedure we follow for particularly significant and
important pages - like the most popular few pages for a group (the
Bugzappers front page, joining page etc). It doesn't scale to _every
page in the Wiki_, there just aren't the resources to review everything.
For a less significant page like this, it doesn't need review.

> if I 
> would change an already published wiki page I should comment in the page 
> it self why I made those changes .

That's not correct, you should explain in the comment box when you make
the change. If you need a longer justification than that space allows,
put it on the Talk page.

>  Now I had barely finished wikifying 
> for example Sysrq ( Now  https://fedoraproject.org/wiki/QA/Sysrq ) and 
> was waiting for feed back from the community ( for example if it was 
> simple/clear enough ) when it got yanked out of my personal space and 
> dump where it resides now ( which probably not where the wiki admins 
> want it to reside ). 

That sounds strange, I didn't know anything about it happening at the
time. Who moved it? What was the rationale?

Having said that, that's probably an example of a page it's fine to just
create directly - it's not crucial enough to require drafting and formal
review, though of course it's always good to get other people's opinions
on the page if you can :)

> Either we create pages at will submit them when 
> accepted they get move to the front then if a rewriting ( other than 
> minor changes such as typo fixing etc ) occurs the individual that wants 
> to rewrite the current page does so on his own name space and submits 
> his changes or everybody hack everything everywhere on the wiki and 
> constantly play wiki rewriting ping pong game of how their perception on 
> how things should look/be written. 

In practice, it's usually easy to compromise. Since everyone's basically
pointing in the same direction here, and it's easy to collaborate, that
kind of ping-ponging doesn't happen too often. When it does get started,
we can agree to bring both perspectives to a meeting or ML discussion
and decide on the best approach with the approval of the rest of the
group.

> One half says user your own namespace 
> and submit your suggestion comment when changing.the other halfs says 
> wanna change something on the wiki change it. I think the community 
> needs to agree on which way it should be.

As I said, I don't think this is an area where there needs to be One
True Way. Different groups and different pages can take different
approaches. As long as the information gets out there in the end, it's
okay.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mcepl at redhat.com  Fri Oct  2 06:08:16 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 2 Oct 2009 06:08:16 +0000 (UTC)
Subject: Buyer Beware: A  Major Change in NFS is about to happen
References: <1254262439.2303.25.camel@localhost.localdomain>
	<4AC2886F.9070708@RedHat.com>
	<20090929225553.GW28169@localhost.localdomain>
	<4AC29443.7030501@RedHat.com>
	<20090929231620.GA28169@localhost.localdomain>
	<4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<4AC2CD81.2000401@RedHat.com>
	<20090930191819.GC10134@nostromo.devel.redhat.com>
	<4AC3B47F.7060302@RedHat.com> 
	<9ED29563-BCDD-4B06-B1E2-EB1CB4F47DFF@j2solutions.net>
Message-ID: 

Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700:
> We've stopped caring about anything outside of the critical path.

Thanks for clarifying it. At least I know now that I should give up on 
maintaining Fedora packages because nobody cares about them. Will do next 
week.

Mat?j



From jreznik at redhat.com  Fri Oct  2 07:34:33 2009
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Fri, 2 Oct 2009 09:34:33 +0200
Subject: KDE-SIG weekly report (40/2009)
In-Reply-To: <200910012038.35919.deadbabylon@googlemail.com>
References: <200909301431.23961.jreznik@redhat.com>
	<200910012038.35919.deadbabylon@googlemail.com>
Message-ID: <200910020934.33397.jreznik@redhat.com>

On Thursday 01 October 2009 20:38:30 Sebastian Vahl wrote:
> Am Mittwoch 30 September 2009 schrieb Jaroslav Reznik:
> > o future of Phonon
> > * Upstream (sandsmark) recommends building/packaging phonon from qt, and
> > building/packaging backends separately.
> > * Mandriva developments integrating pulseaudio support (and improving
> > gstreamer backend). [1]
> > * We will move back to building a standalone phonon SRPM.
> > * The vote for the default backend is split 3:3, needs the 7th vote from
> > svahl.
> 
> Sorry for the delay. Was a bit busy and not at home.
> 
> I tend to xine as default backend for several reasons:
> - It worked fine for me for several releases (and according to bugs for
>  other too)
> - It is recommend by upstream.
> - We won't get trouble with the amarok guys. :)
> - At least on one system I have no sound with gstreamer (maybe caused by
>  other issues, have to re-check that).
> 
> So I'm a bit conservative here, but +1 for xine.

Hi Svahl,
thanks for your vote. So it's now 4:3 for Xine backend.

So what are the required steps now? As we already missed freeze but we can 
work it out with rel engs.

I like idea of shipping both backends as proposed rdieter but set the Xine one 
as default one. But first we should fix bug with switching backends...

Distant future: I'll try to look at GStreamer backend more deeply later as I 
think it's the future - not only for Fedora but for upstream too and I hope we 
can get it at least to the the point to be comparable with Xine one. Then we 
can reconsider this decision.
 
> Sebastian
> 

Jaroslav
-- 
Jaroslav ?ezn?k 
Associate Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.                               http://cz.redhat.com/



From Quentin at Armitage.org.uk  Fri Oct  2 07:41:56 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Fri, 02 Oct 2009 08:41:56 +0100
Subject: Problems building kernel
Message-ID: <1254469316.6046.18.camel@samson.armitage.org.uk>

I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an
up-to-date F-11 system, but I keep getting a build failure. I have
tracked it down to the following.

At the beginning of the %install stage, it executes
'[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' /
']
rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
but there are already files in that directory that have been created
earlier in the build process  and are needed for the install (see
extract of build log below).

I notice that when kernels are build in koji, this rm ... does not get
executed, but also, looking at other packages' build.log in koji (the
example I took was rpm itself), then the equivalent rm command is
executed.

I cannot see where the rm ... command comes from, or how to stop it.

Can anyone give me some pointers?

Q


> mkdir -p /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/usr/src/kernels
> + mv /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386//usr/src/kernels/2.6.29.1-46.fc11.i586
> + ln -sf ../../../usr/src/kernels/2.6.29.1-46.fc11.i586 /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build
> + exit 0
> Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NR0ESi
> + umask 022
> + cd /u/home/hsn/rpmbuild/BUILD
> + '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / ']'
> + rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> ++ dirname /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> + mkdir -p /u/home/hsn/rpmbuild/BUILDROOT
> + mkdir /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> + cd kernel-2.6.29
> + LANG=C
> + export LANG
> + unset DISPLAY
> + cd linux-2.6.29.i586




From Quentin at Armitage.org.uk  Fri Oct  2 07:43:06 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Fri, 02 Oct 2009 08:43:06 +0100
Subject: Problems building kernel
Message-ID: <1254469386.14546.1.camel@samson.armitage.org.uk>

I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an
up-to-date F-11 system, but I keep getting a build failure. I have
tracked it down to the following.

At the beginning of the %install stage, it executes
'[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' /
']
rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
but there are already files in that directory that have been created
earlier in the build process  and are needed for the install (see
extract of build log below).

I notice that when kernels are build in koji, this rm ... does not get
executed, but also, looking at other packages' build.log in koji (the
example I took was rpm itself), then the equivalent rm command is
executed.

I cannot see where the rm ... command comes from, or how t


> mkdir -p /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/usr/src/kernels
> + mv /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386//usr/src/kernels/2.6.29.1-46.fc11.i586
> + ln -sf ../../../usr/src/kernels/2.6.29.1-46.fc11.i586 /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build
> + exit 0
> Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NR0ESi
> + umask 022
> + cd /u/home/hsn/rpmbuild/BUILD
> + '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / ']'
> + rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> ++ dirname /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> + mkdir -p /u/home/hsn/rpmbuild/BUILDROOT
> + mkdir /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> + cd kernel-2.6.29
> + LANG=C
> + export LANG
> + unset DISPLAY
> + cd linux-2.6.29.i586




From christof at damian.net  Fri Oct  2 07:46:51 2009
From: christof at damian.net (Christof Damian)
Date: Fri, 2 Oct 2009 09:46:51 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
Message-ID: 

On Thu, Oct 1, 2009 at 19:15, David Malcolm  wrote:
> ?- We have a working, valuable python 2 stack, which is used by
> critical system components (yum and anaconda): we must not destabilize
> the python 2 stack.

Do we have an idea how far our stack is from working on python3 ?

And how far all the rest of python packages is?

I think at one point the decision to switch to python3 has do be done
and some packages will be left behind (at least for a while). It is
just a question when the switch will happen.

A parallel python3 stack now would mostly be usable for people using
python3 for work and for these a separate repo would be enough, they
probably will need this for RHEL/CentOS too.

Cheers,
Christof



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Oct  2 08:00:16 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 02 Oct 2009 17:00:16 +0900
Subject: Problems building kernel
In-Reply-To: <1254469386.14546.1.camel@samson.armitage.org.uk>
References: <1254469386.14546.1.camel@samson.armitage.org.uk>
Message-ID: <4AC5B310.3060304@ioa.s.u-tokyo.ac.jp>

Quentin Armitage wrote, at 10/02/2009 04:43 PM +9:00:
> I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an
> up-to-date F-11 system, but I keep getting a build failure. I have
> tracked it down to the following.
> 
> At the beginning of the %install stage, it executes
> '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' /
> ']
> rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
> but there are already files in that directory that have been created
> earlier in the build process  and are needed for the install (see
> extract of build log below).
> 
> I notice that when kernels are build in koji, this rm ... does not get
> executed, but also, looking at other packages' build.log in koji (the
> example I took was rpm itself), then the equivalent rm command is
> executed.
> 
> I cannot see where the rm ... command comes from, or how t

This change (i.e. deleting %buildroot tree at the beginning of %install)
comes from the change in redhat-rpm-config 
(see $ rpm -q --changelog redhat-rpm-config and the file /usr/lib/rpm/redhat/macros )

Recent kernel.spec has the following lines at the top to prevent this
behavior.
-------------------------------------------------------------------
# We have to override the new %%install behavior because, well... the kernel is special.
%global __spec_install_pre %{___build_pre}
-------------------------------------------------------------------

Regards,
Mamoru



From mschmidt at redhat.com  Fri Oct  2 08:15:30 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Fri, 2 Oct 2009 10:15:30 +0200
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: 
References: <1254262439.2303.25.camel@localhost.localdomain>
	<4AC2886F.9070708@RedHat.com>
	<20090929225553.GW28169@localhost.localdomain>
	<4AC29443.7030501@RedHat.com>
	<20090929231620.GA28169@localhost.localdomain>
	<4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<4AC2CD81.2000401@RedHat.com>
	<20090930191819.GC10134@nostromo.devel.redhat.com>
	<4AC3B47F.7060302@RedHat.com> 
	<9ED29563-BCDD-4B06-B1E2-EB1CB4F47DFF@j2solutions.net>
	
Message-ID: <20091002101530.24441fd4@leela>

Dne Fri, 2 Oct 2009 06:08:16 +0000 (UTC) Matej Cepl napsal(a):
> Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700:
> > We've stopped caring about anything outside of the critical path.
> 
> Thanks for clarifying it. At least I know now that I should give up
> on maintaining Fedora packages because nobody cares about them.

You're misinterpreting Jesse's quote out of context.

I'm sure the intent was NOT "nobody cares about your packages".

I read it as: "We (rel-eng) will always approve your tag request for
a non-critical package because we trust you as a packager that the
package is a bugfix. We will be more careful with critical path
packages though, because of the inherent risk of breaking the release."

Michal



From karlthered at gmail.com  Fri Oct  2 09:20:35 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Fri, 02 Oct 2009 11:20:35 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: 
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
Message-ID: <4AC5C5E3.2080508@gmail.com>

Le 02/10/2009 09:46, Christof Damian a ?crit :
> 
> Do we have an idea how far our stack is from working on python3 ?
> 
> And how far all the rest of python packages is?
> 

Not much, there are few external modules working though the list is
slowly growing (pyqt4, openCV etc, libxml...). Here are some python3
modules hosted on PyPI
http://pypi.python.org/pypi?:action=browse&c=533&show=all

> I think at one point the decision to switch to python3 has do be done
> and some packages will be left behind (at least for a while). It is
> just a question when the switch will happen.
> 

There should be no discussion of switching to python3 as default
interpreter before the upcoming python 2.7.
Python 2.7 is planned to the last offspring of python2.x and to further
reduce the gap between python2 and python3.


> A parallel python3 stack now would mostly be usable for people using
> python3 for work and for these a separate repo would be enough, they
> probably will need this for RHEL/CentOS too.
> 

It won't.
*BSD, fellow GNU/Linux distro like Debian, Mandriva, Ubuntu even
macports are able to ship multiples python stacks and we (Fedora) are
not ? Isn't Fedora supposed to lead ?
Since Python is parallel installable by design, our main issues are to
deal with packaging guidelines (naming, possible conflicts, etc ...) and
considering porting our own python modules and/or fixing them to ease
the port.

Though a separate repo would help to identify and fix possible
conflicts, we should be able to provide a minimal python3 stack for F-13
(and maybe F-12 through updates) and eventually few blessed third-party
modules. After all, others are already shipping it or will ship it in
their next release.
Besides, that would encourage python modules maintainers to port and
test their modules on python3.



Besides, the longer we wait, the harder/longer the transition will be.

H.



From forum at ru.bir.ru  Fri Oct  2 11:29:11 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 02 Oct 2009 15:29:11 +0400
Subject: -doc, -devel and -examples sub-packages question
Message-ID: 

I've pack library ne7ssh 
https://bugzilla.redhat.com/show_bug.cgi?id=521909 .

History in two words:

It contain 6 examples files and Makefile to built it.

I've package it into ne7ssh-examples sub-package.

Michael Schwendt say what it should not be separate sub-package, and 
right point me what other documentation have minor size and candidate to 
-doc sub-package. I done that. But for right dependency include Require: 
ne7ssh-devel, without that examples filed to built. It was also treated 
as wrong. I wasn't agree with solution place all docs into -doc but 
examples in -devel. I think it is incorrect. I also treat presents of 
source files to end-user with known result - missing build dependency is 
not correct maintainer decision. Also I agree what -devel dependency in 
-doc too is not best...

So, is there any guidelines, policy or something else on this case?

With best wishes, Pavel Alexeev aka Pahan-Hubbitus.



From forum at ru.bir.ru  Fri Oct  2 11:07:28 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 02 Oct 2009 15:07:28 +0400
Subject: -doc, -examples sub-packages creation question
Message-ID: 

I've pack library ne7ssh 
https://bugzilla.redhat.com/show_bug.cgi?id=521909 .

History in two words:

It contain 6 examples files and Makefile to built it.

I've package it into ne7ssh-examples sub-package.

Michael Schwendt say what it should not be separate sub-package, and 
right point me what other documentation have minor size and candidate to 
-doc sub-package. I done that. But for right dependency include Require: 
ne7ssh-devel, without that examples filed to built. It was also treated 
as wrong. I wasn't agree with solution place all docs into -doc but 
examples in -devel. I think it is incorrect. I also treat presents of 
source files to end-user with known result - missing build dependency is 
not correct maintainer decision. Also I agree what -devel dependency in 
-doc too is not best...

So, is there any guidelines, policy or something else on this case?

With best wishes, Pavel Alexeev aka Pahan-Hubbitus.



From forum at ru.bir.ru  Fri Oct  2 11:07:01 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 02 Oct 2009 15:07:01 +0400
Subject: -doc, -examples sub-packages creation question
Message-ID: 

I'm package library ne7ssh 
https://bugzilla.redhat.com/show_bug.cgi?id=521909 .

History in two words:

It contain 6 examples files and Makefile to built it.

I've package it into ne7ssh-examples sub-package.

Michael Schwendt say what it should not be separate sub-package, and 
right point me what other documentation have minor size and candidate to 
-doc sub-package. I done that. But for right dependency include Require: 
ne7ssh-devel, without that examples filed to built. It was also treated 
as wrong. I wasn't agree with solution place all docs into -doc but 
examples in -devel. I think it is incorrect. I also treat presents of 
source files to end-user with known result - missing build dependency is 
not correct maintainer decision. Also I agree what -devel dependency in 
-doc too is not best...

So, is there any guidelines, policy or something else on this case?

With best wishes, Pavel Alexeev aka Pahan-Hubbitus.



From skvidal at fedoraproject.org  Fri Oct  2 12:03:52 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 2 Oct 2009 08:03:52 -0400 (EDT)
Subject: Buyer Beware: A Major Change in NFS is about to happen
In-Reply-To: 
References: <1254262439.2303.25.camel@localhost.localdomain>
	<4AC2886F.9070708@RedHat.com>
	<20090929225553.GW28169@localhost.localdomain>
	<4AC29443.7030501@RedHat.com>
	<20090929231620.GA28169@localhost.localdomain>
	<4AC299AD.6070808@RedHat.com>
	<4AC2A390.90200@redhat.com> <4AC2A89F.4030800@RedHat.com>
	<4AC2B280.6000400@gmail.com> <4AC2CD81.2000401@RedHat.com>
	<20090930191819.GC10134@nostromo.devel.redhat.com>
	<4AC3B47F.7060302@RedHat.com> 
	<9ED29563-BCDD-4B06-B1E2-EB1CB4F47DFF@j2solutions.net>
	
Message-ID: 



On Fri, 2 Oct 2009, Matej Cepl wrote:

> Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700:
>> We've stopped caring about anything outside of the critical path.
>
> Thanks for clarifying it. At least I know now that I should give up on
> maintaining Fedora packages because nobody cares about them. Will do next
> week.
>

Oh the drama. A little less hyperbole and a little more understanding 
would probably help everyone.



-sv



From rawhide at fedoraproject.org  Fri Oct  2 13:02:44 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 2 Oct 2009 13:02:44 +0000
Subject: rawhide report: 20091002 changes
Message-ID: <20091002130244.GA20686@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct  2 06:15:09 UTC 2009

Broken deps for i386
----------------------------------------------------------
	PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public
	argus-2.0.6.fixes.1-16.fc11.i586 requires libpcap.so.0.9
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)
	labrea-2.5.1-2.fc10.i386 requires libpcap.so.0.9
	libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidclient.so.2
	libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfagent.so.2
	libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidcommon.so.2
	libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfcommon.so.2
	matahari-0.0.4-5.fc12.i686 requires libqpidclient.so.2
	matahari-0.0.4-5.fc12.i686 requires libqmfagent.so.2
	matahari-0.0.4-5.fc12.i686 requires libqpidcommon.so.2
	matahari-0.0.4-5.fc12.i686 requires libqmfcommon.so.2
	rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30
	yersinia-0.7.1-3.fc11.i586 requires libpcap.so.0.9



Broken deps for x86_64
----------------------------------------------------------
	PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public
	argus-2.0.6.fixes.1-16.fc11.x86_64 requires libpcap.so.0.9()(64bit)
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8)
	labrea-2.5.1-2.fc10.x86_64 requires libpcap.so.0.9()(64bit)
	libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidcommon.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfagent.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfcommon.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidclient.so.2()(64bit)
	matahari-0.0.4-5.fc12.x86_64 requires libqpidcommon.so.2()(64bit)
	matahari-0.0.4-5.fc12.x86_64 requires libqmfagent.so.2()(64bit)
	matahari-0.0.4-5.fc12.x86_64 requires libqmfcommon.so.2()(64bit)
	matahari-0.0.4-5.fc12.x86_64 requires libqpidclient.so.2()(64bit)
	rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30
	yersinia-0.7.1-3.fc11.x86_64 requires libpcap.so.0.9()(64bit)



Broken deps for ppc
----------------------------------------------------------
	PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public
	argus-2.0.6.fixes.1-16.fc11.ppc requires libpcap.so.0.9
	clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8)
	labrea-2.5.1-2.fc10.ppc requires libpcap.so.0.9
	libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidclient.so.2
	libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfagent.so.2
	libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidcommon.so.2
	libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfcommon.so.2
	matahari-0.0.4-5.fc12.ppc requires libqpidclient.so.2
	matahari-0.0.4-5.fc12.ppc requires libqmfagent.so.2
	matahari-0.0.4-5.fc12.ppc requires libqpidcommon.so.2
	matahari-0.0.4-5.fc12.ppc requires libqmfcommon.so.2
	rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30
	yersinia-0.7.1-3.fc11.ppc requires libpcap.so.0.9



Broken deps for ppc64
----------------------------------------------------------
	PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public
	argus-2.0.6.fixes.1-16.fc11.ppc64 requires libpcap.so.0.9()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8)
	labrea-2.5.1-2.fc10.ppc64 requires libpcap.so.0.9()(64bit)
	libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqpidcommon.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqmfagent.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqmfcommon.so.2()(64bit)
	libvirt-qpid-0.2.17-0.fc12.ppc64 requires libqpidclient.so.2()(64bit)
	matahari-0.0.4-5.fc12.ppc64 requires libqpidcommon.so.2()(64bit)
	matahari-0.0.4-5.fc12.ppc64 requires libqmfagent.so.2()(64bit)
	matahari-0.0.4-5.fc12.ppc64 requires libqmfcommon.so.2()(64bit)
	matahari-0.0.4-5.fc12.ppc64 requires libqpidclient.so.2()(64bit)
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin >= 0:0.5.3-30
	yersinia-0.7.1-3.fc11.ppc64 requires libpcap.so.0.9()(64bit)



New package iwl1000-firmware



From jeff at ocjtech.us  Fri Oct  2 13:56:21 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Fri, 2 Oct 2009 08:56:21 -0500
Subject: Trying to build zkt 0.99c on Fedora 11
Message-ID: <935ead450910020656w219aa054p5cee69846a57a64c@mail.gmail.com>

I'm trying to build zkt 0.99c on Fedora 11 (x86_64) and am running
into the following error:

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g
-DHAVE_CONFIG_H -I. -Wall  -Wmissing-prototypes     -c -o soaserial.o
soaserial.c
In file included from /usr/include/sys/syslog.h:207,
                 from /usr/include/syslog.h:1,
                 from log.h:43,
                 from nscomm.h:44,
                 from nscomm.c:46:
/usr/include/bits/syslog.h: In function 'syslog':
/usr/include/bits/syslog.h:32: error: invalid use of '__builtin_va_arg_pack ()'

Google tells me this has more to do with changes in newer GCC versions
to improve compile-time error detection, but I'm unable to figure out
what the right solution is.  Can anyone help out here?  I've
successfully compiled older versions of zkt on older versions of
Fedora - this is the first time I've tried it on Fedora 11.  I've
attached the spec file that I'm using to build the RPM package.

-- 
Jeff Ollie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zkt.spec
Type: application/octet-stream
Size: 1827 bytes
Desc: not available
URL: 

From trever.adams at gmail.com  Fri Oct  2 14:02:17 2009
From: trever.adams at gmail.com (Trever L. Adams)
Date: Fri, 02 Oct 2009 08:02:17 -0600
Subject: CalDAV Calendar (BedeWork)
In-Reply-To: <9497e9990910011058k4146123eo942609318a763159@mail.gmail.com>
References: <4AC40028.1000600@gmail.com>
	<9497e9990910011058k4146123eo942609318a763159@mail.gmail.com>
Message-ID: <4AC607E9.3040205@gmail.com>

Mat Booth wrote:
>> This package has a bunch of property files that you have to edit before
>> you build the program.
>> (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18)
> Also, setting usernames and passwords at compile time is definitely
> not normal for *any* kind of application. Are you sure they are not
> runtime properties?
>   

I do not know if it is just part of the package or at compile time. If
you read the referenced url, you will see. I am taking this to the Java
list as suggested.

Trever

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: 

From chasd at silveroaks.com  Fri Oct  2 15:07:36 2009
From: chasd at silveroaks.com (chasd)
Date: Fri, 02 Oct 2009 10:07:36 -0500
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <20091002074728.051878E0258@hormel.redhat.com>
References: <20091002074728.051878E0258@hormel.redhat.com>
Message-ID: <0463534732828ec7f2a8449654c5549f@silveroaks.com>


Taking a step back to look at a broader picture,
what is determined here might be helpful when migrating
other packages such as :

perl6
php6
java2 ( or whatever Sunacle calls it officially )
ruby2

Although none of those are as central to the operation
of Fedora as python, they all will suffer migration pains,
and likely will require some type of parallel install
of old and new versions, as well as migration of
requires and provides. perl 6 is in F12 as I recall,
under a pseudonym.

Keeping python2 around ( and perl5, etc. ) named that way
and not moving to compat-python2 or compat-perl5 may not
be a bad thing. Using compat-* as a naming convention does
signal " don't use this unless you have to " however is it
really required ? I know, it may be too early to think about
when python2 moves to a compat-* status, but as slowly as the
migration to python3 is going, there may be a need for
parallel installs of python2, python3, and python4.
I know, ick, but possible.

It might be best to keep the major version number as part
of the package name(s) permanent.


-- 
Charles Dostale




From nicolas.mailhot at laposte.net  Fri Oct  2 15:14:07 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 2 Oct 2009 17:14:07 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <0463534732828ec7f2a8449654c5549f@silveroaks.com>
References: <20091002074728.051878E0258@hormel.redhat.com>
	<0463534732828ec7f2a8449654c5549f@silveroaks.com>
Message-ID: <154827591c6db37936c329818ebdf7df.squirrel@arekh.dyndns.org>



Le Ven 2 octobre 2009 17:07, chasd a ?crit :

> java2 ( or whatever Sunacle calls it officially )

We use our own naming for this because SUN changed its mind too often on how
it should be named. So now we ignore upstream naming and use our own
consistent one.

-- 
Nicolas Mailhot




From mcepl at redhat.com  Fri Oct  2 15:26:09 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 2 Oct 2009 15:26:09 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in
 NFS is about to happen]
Message-ID: 

(intentionally breaking the thread so this is not burried somewhere in 
depths)
Michal Schmidt, Fri, 02 Oct 2009 10:15:30 +0200:
> You're misinterpreting Jesse's quote out of context.

I am misunderstanding them (in case your interpretation is more correct). 
So that's just that rel-eng doesn't have enough work to do (otherwise, 
why they do not control only critical path components?).

So, this is not in protest of the current policy (this was just the last 
straw which broke me to do The Right Thing? finally) and I don't want to 
make a drama from this (quoting Seth). However, for personal reasons I 
need to decrease my personal involvment in non-work related Fedora work. 

So, I am orphaning these packages:

pspp -- A program for statistical analysis of sampled data (simple free 
clone of SPSS statistical package)
syncevolution -- SyncML client for evolution
jbrout -- Photo manager, written in python/pygtk
pyexiv2 -- Python binding to exiv2 (used by jbrout)
cycle -- Calendar program for women
ldapvi -- An interactive LDAP client

I really care about these packages, so please somebody take them. I am 
willing to comaintain (meaning probably mostly to advice on the ways how 
the community around them works), and if nobody will step up to maintain 
them, I will probably stay maintaining them.

pspp is close to the new release, I was building for Rawhide all 
prereleases (it mostly involves filing a bug report upstream for reach 
rebuild, because pspp seems to be hitting many issues with our super-new 
gcc and glibc).
syncevolution was just released and upgraded in Fedora.

I also wish to orphan these packages, and frankly I care about them much 
less, so if nobody steps up, I will probably just let them die.

JSDoc -- Produces javadoc-style documentation from JavaScript sourcefiles
nimbus -- Desktop theme originally from Sun
python-libasyncns -- Python binding for libasyncns
python-urllib2_kerberos -- Kerberos over HTTP Negotiate/SPNEGO support 
for urllib2
vim-vimoutliner -- Script for building an outline editor on top of Vim

All my packages are in good shape and I don't see any serious outstanding 
issue in them.

Thanks a lot for anybody taking these.

Mat?j



From christof at damian.net  Fri Oct  2 15:43:49 2009
From: christof at damian.net (Christof Damian)
Date: Fri, 2 Oct 2009 17:43:49 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <0463534732828ec7f2a8449654c5549f@silveroaks.com>
References: <20091002074728.051878E0258@hormel.redhat.com> 
	<0463534732828ec7f2a8449654c5549f@silveroaks.com>
Message-ID: 

On Fri, Oct 2, 2009 at 17:07, chasd  wrote:
>
> Taking a step back to look at a broader picture,
> what is determined here might be helpful when migrating
> other packages such as :
>
> perl6
> php6
> java2 ( or whatever Sunacle calls it officially )
> ruby2

the good thing is that they then can end up in EPEL too.

This would make a lot of PHP users happy, which are currently living
in the RHEL PHP stone age. (or use some other repo)

Christof



From bochecha at fedoraproject.org  Fri Oct  2 15:44:43 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Fri, 2 Oct 2009 17:44:43 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <0463534732828ec7f2a8449654c5549f@silveroaks.com>
References: <20091002074728.051878E0258@hormel.redhat.com> 
	<0463534732828ec7f2a8449654c5549f@silveroaks.com>
Message-ID: <2d319b780910020844p2b420f7ei8f5b0a9f2fe71375@mail.gmail.com>

> perl6

That's already a Fedora 12 feature.
https://fedoraproject.org/wiki/Features/Rakudo_Perl_6


----------

Mathieu Bridon (bochecha)



From walters at verbum.org  Fri Oct  2 15:48:01 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 2 Oct 2009 15:48:01 +0000
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <4AC5C5E3.2080508@gmail.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
	<4AC5C5E3.2080508@gmail.com>
Message-ID: 

On Fri, Oct 2, 2009 at 9:20 AM, Ha?kel Gu?mar  wrote:

>
> *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples
> python stacks


In Debian's case of course there are actually *two* separate Python systems
;)

http://wiki.debian.org/DebianPythonFAQ

I didn't understand either and was quite confused trying to debug one of my
Python applications on Debian, but if they're useful we might consider
adopting one of them rather than reinventing another parallel install
system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin at scrye.com  Fri Oct  2 15:49:57 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Fri, 2 Oct 2009 09:49:57 -0600
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: <4AC520A5.1070001@redhat.com>
References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<1254293108.2242.17.camel@localhost.localdomain>
	
	
	
	<1254335788.2242.27.camel@localhost.localdomain>
	
	<20091001021938.GW5260@hansolo.jdub.homelinux.org>
	 <4AC520A5.1070001@redhat.com>
Message-ID: <20091002094957.7590ebd3@ohm.scrye.com>

On Thu, 01 Oct 2009 14:35:33 -0700
John Poelstra  wrote:

...snip...

> The current FESCo might also want to consider taking more of a 
> leadership role in monitoring the release processes, tracking the 
> schedule, and evaluating the quality of the release under development 
> and our ability to release on time.  As the group responsible for 
> guiding the technical direction of our releases I think this is 
> something they should be more involved in.  I'd be glad to help
> gather data they might need to do this and there might be others who
> would be willing to help too.

I would love to. Can you show me the 28 hour days so I have some extra
hours? :) 

Seriously tho, I think many of the FESCo folks _DO_ stay involved in
lots of things, some of them might not be as visible as people think
they would be. Or did you mean at some higher level? 

> I'm suggesting more proactive leadership from FESCo and clear 
> initiatives to take Fedora to the next level versus only being 
> responsible for approving features, proven packagers, and policy
> matters.
> 
> This is also my vision for the Fedora Board.

I think move involvement wherever we can get it great, but I don't
think we should try and force people to do X hours of work on Y. 

Also, if we want to require fesco and/or the board to be more involved
and proactive, we should note these requirements for the next election. 

A possible idea for the next cycle: 

- Wait until we have the list of approved features. 
- Divide them up amoung fesco and have a 'point contact' for each that
  is a fesco member. 
- Each member is responsible for testing/tracking/talking to the
  feature owner and getting them what they need to get things done as
  well as knowing if something is not ready/etc. 

I don't know how feasible this is given the large list of features
however. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

From jkeating at redhat.com  Fri Oct  2 16:18:28 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 02 Oct 2009 09:18:28 -0700
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References: 
Message-ID: <1254500308.2546.3.camel@localhost.localdomain>

On Fri, 2009-10-02 at 15:26 +0000, Matej Cepl wrote:
> 
> I am misunderstanding them (in case your interpretation is more correct). 
> So that's just that rel-eng doesn't have enough work to do (otherwise, 
> why they do not control only critical path components?).
> 

Releng and QA are very small groups.  The Fedora package set is
extremely large.  Over 8K packages.  The rate of change is far too grate
to provide second guessing over every package.  So releng/qa decided to
draw a line around the packages that are critical to everybody, and
those that are critical to select few.  For the packages that are
critical to everybdoy, releng/qa will promise to take a second look at
them before allowing them to break freeze.  This is to prevent things
like the dbus fiasco last release (sorry to keep picking on dbus).  We
just simply cannot do that for the rest of the package set.  Also, the
most important thing in a Fedora release is that it installs, it boots,
and the user can get online and get updates after that.  Anything
outside of that is less critical and can be fixed by updates, so when
gearing up for a release, that is where our efforts will be focused on
for testing.

Is this any clearer now?


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From lemenkov at gmail.com  Fri Oct  2 17:18:09 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 2 Oct 2009 21:18:09 +0400
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: 
References: 
Message-ID: 

2009/10/2 Matej Cepl :

> pspp -- A program for statistical analysis of sampled data

I can take care of if.

> jbrout -- Photo manager, written in python/pygtk
> pyexiv2 -- Python binding to exiv2 (used by jbrout)

I'm using it, so I'll take care of it..
-- 
With best regards, Peter Lemenkov.



From mcepl at redhat.com  Fri Oct  2 17:37:18 2009
From: mcepl at redhat.com (=?utf-8?b?TWF0xJtq?= Cepl)
Date: Fri, 2 Oct 2009 17:37:18 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
References: 
	<1254500308.2546.3.camel@localhost.localdomain>
Message-ID: 

Jesse Keating  redhat.com> writes:
> Releng and QA are very small groups.  The Fedora package set is
> extremely large.  Over 8K packages.  The rate of change is far too grate
> to provide second guessing over every package.

That's why I am surprised you want to click through all those requests for fixes
in non-essential packages. Why not leave them open (or allow updates only when
bug number is attached)?

Mat?j



From jonstanley at gmail.com  Fri Oct  2 17:56:21 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 2 Oct 2009 13:56:21 -0400
Subject: FESCo meeting summary for 2009-10-02
Message-ID: 

=======================================
#fedora-meeting: FESCo meeting 20091002
=======================================


Meeting started by jds2001 at 17:00:47 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-02/fedora-meeting.2009-10-02-17.00.log.html
.



Meeting summary
---------------
* incomplete features  (jds2001, 17:04:12)
  * AGREED: DisplayPort feature is punted to F13, unles sthere's some
    other information we don't have  (jds2001, 17:14:30)
  * LINK: http://marc.info/?l=linux-bluetooth&m=125447683916247&w=2
    (sgrubb, 17:17:31)
  * AGREED: Lower Porcess Capabilities is retained, dbus changes are
    being committed to complet the feature.  (jds2001, 17:38:58)
  * AGREED: NFSv4Default feature is deferred to F13, will land very
    early (like now-ish :) )  (jds2001, 17:45:46)

* open floor  (jds2001, 17:53:28)

Meeting ended at 17:54:44 UTC.




Action Items
------------





Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* jds2001 (74)
* sgrubb (44)
* Kevin_Kofler (43)
* nirik (41)
* notting (12)
* walters (11)
* steved (8)
* dgilmore (8)
* zodbot (7)
* sharkcz (3)
* skvidal (2)
* j-rod (2)
* buggbot (2)
* Oxf13 (2)
* jwb (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



From christoph.wickert at googlemail.com  Fri Oct  2 17:58:58 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 02 Oct 2009 19:58:58 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References: 
Message-ID: <1254506338.2742.7.camel@localhost>

Am Freitag, den 02.10.2009, 15:26 +0000 schrieb Matej Cepl:

> I also wish to orphan these packages, and frankly I care about them much 
> less, so if nobody steps up, I will probably just let them die.
> 
> JSDoc -- Produces javadoc-style documentation from JavaScript sourcefiles
> nimbus -- Desktop theme originally from Sun

Hi Mat?j,

I'm going to take over nimbus. I already reviewed it and you asked me
for co-maintenance. Sorry I didn't find the time to look into the EPEL
build error sooner, it's still on my todo list.

Please release ownership in pkg-db, so I can claim it.

Regards,
Christoph





From itamar at ispbrasil.com.br  Fri Oct  2 18:13:59 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Fri, 2 Oct 2009 15:13:59 -0300
Subject: creating a updated DVD with fedora install
Message-ID: 

anyone can help ?

it's possible to create a updated DVD with fedora install ?

how ?



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From valent.turkovic at gmail.com  Fri Oct  2 18:13:42 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 2 Oct 2009 18:13:42 +0000 (UTC)
Subject: NFS and slow boot
Message-ID: 

Hi,
I'm building custom Fedora remix with some packages from RPMFusion and
updated Fedora packages. Last Live USB image I created booted really slow
(over 5 minutes). I tracked down the issue to nfs service. Even when this
ISO image is used for installing Fedora to HDD the same issue is present.

After stopping nfs service boot time was around 30 seconds!

Did anybody else experience this issue? Should I report this as a bug 
agaings NFS or livecd-creator?

Cheers.



-- 
pratite me na twitteru - www.twitter.com/valentt
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jeff at ocjtech.us  Fri Oct  2 18:16:05 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Fri, 2 Oct 2009 13:16:05 -0500
Subject: Switching to Native Upstart Scripts?
Message-ID: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>

I was wondering what the consensus on switching to native Upstart
scripts (/etc/event.d/*) vs. keeping the "traditional" SysV init
scripts (/etc/rc.d/init.d) for daemons was?  I was looking at
switching Asterisk over and have an Upstart script that seems to work
fairly well.  I would be making the change for F-13...

-- 
Jeff Ollie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asterisk
Type: application/octet-stream
Size: 331 bytes
Desc: not available
URL: 

From dmalcolm at redhat.com  Fri Oct  2 18:20:54 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 02 Oct 2009 14:20:54 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
Message-ID: <1254507654.9551.131.camel@radiator.bos.redhat.com>

On Thu, 2009-10-01 at 13:15 -0400, David Malcolm wrote:
[snip]

(replying to self, with some archive links)

> An earlier proposal about python 3 in Fedora is here:
> https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html

...which was the "Let's make a plan for python3.0 in Fedora 10+" thread.

FWIW, looking back in the logs there was also:
"python-2.6 and python-3.x"
( https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html )

and further back:

"The looming Python 3(000) monster"
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html

[snip]




From jreiser at bitwagon.com  Fri Oct  2 18:34:17 2009
From: jreiser at bitwagon.com (John Reiser)
Date: Fri, 02 Oct 2009 11:34:17 -0700
Subject: creating a updated DVD with fedora install
In-Reply-To: 
References: 
Message-ID: <4AC647A9.7060708@bitwagon.com>

> it's possible to create a updated DVD with fedora install ?

yum install pungi
man pungi

VERSION=12
DESTDIR=/my_destination_directory/Fedora$VERSION
ARCH=i386

# These are for re-using the destination directory(ies)
# such as when using the destination by more than one $ARCH.
rm -rf $DESTDIR/work/$ARCH
rm -rf $DESTDIR/$VERSION/$ARCH

mkdir -p      $DESTDIR/work/$ARCH/tmp
export TMPDIR=$DESTDIR/work/$ARCH/tmp

/usr/sbin/setenforce 0

pungi -c /usr/share/pungi/rawhide-fedora.ks --destdir=$DESTDIR --name Fedora --ver $VERSION --nosource

It will download and cache all the packages (about 2000 or more.)  It requires about
three times as much disk space as the final DVD, plus about an hour after download.

-- 



From notting at redhat.com  Fri Oct  2 18:42:43 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 2 Oct 2009 14:42:43 -0400
Subject: Switching to Native Upstart Scripts?
In-Reply-To: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>
References: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>
Message-ID: <20091002184243.GA22116@nostromo.devel.redhat.com>

Jeffrey Ollie (jeff at ocjtech.us) said: 
> I was wondering what the consensus on switching to native Upstart
> scripts (/etc/event.d/*) vs. keeping the "traditional" SysV init
> scripts (/etc/rc.d/init.d) for daemons was?  I was looking at
> switching Asterisk over and have an Upstart script that seems to work
> fairly well.  I would be making the change for F-13...

1) Likely for F-13 we're moving to upstart 0.6.x. This will likely
require changes (if nothing else, to the script location), so you're
best holding off until after then.

2) We currently have no mechanism for the following:

- not starting services automatically that happen to have jobs installed
  (i.e., chkconfig  off)
- enforcing dependencies between SysV and upstart scripts  - if a package
  that provides a service that a SysV service depends on (via LSB headers)
  changes to an upstart script, things go wrong.

Bill



From valent.turkovic at gmail.com  Fri Oct  2 18:43:27 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 2 Oct 2009 18:43:27 +0000 (UTC)
Subject: NFS and slow boot
References: 
Message-ID: 

On Fri, 02 Oct 2009 18:13:42 +0000, Valent Turkovic wrote:

> After stopping nfs service boot time was around 30 seconds!

I ment to say before stoping, sorry.



-- 
pratite me na twitteru - www.twitter.com/valentt
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From jeff at ocjtech.us  Fri Oct  2 18:47:06 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Fri, 2 Oct 2009 13:47:06 -0500
Subject: Switching to Native Upstart Scripts?
In-Reply-To: <20091002184243.GA22116@nostromo.devel.redhat.com>
References: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>
	<20091002184243.GA22116@nostromo.devel.redhat.com>
Message-ID: <935ead450910021147j75b451fdv87930f1cd91d3203@mail.gmail.com>

On Fri, Oct 2, 2009 at 1:42 PM, Bill Nottingham  wrote:
>
> 1) Likely for F-13 we're moving to upstart 0.6.x.
>
> 2) We currently have no mechanism for the following:
>
> - not starting services automatically that happen to have jobs installed
> - enforcing dependencies between SysV and upstart scripts

Sounds the plan for now is to add the upstart script as a %doc until
these issues get sorted out.

-- 
Jeff Ollie



From jlaska at redhat.com  Fri Oct  2 18:47:39 2009
From: jlaska at redhat.com (James Laska)
Date: Fri, 02 Oct 2009 14:47:39 -0400
Subject: F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) - Recap
In-Reply-To: <1254426205.2388.251.camel@localhost.localdomain>
References: <1254426205.2388.251.camel@localhost.localdomain>
Message-ID: <1254509259.2253.75.camel@localhost.localdomain>

On Thu, 2009-10-01 at 15:43 -0400, James Laska wrote:
> When: Friday, 2009-10-02 @ 15:00 UTC (11 AM EDT)
> Where: #fedora-bugzappers on irc.freenode.net

Thanks to all in attendance!  See below for the meeting summary.

================================================
#fedora-bugzappers: F-12 Beta Blocker Bug Review
================================================


Meeting started by jlaska at 14:58:39 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-02/fedora-bugzappers.2009-10-02-14.58.log.html
.



Meeting summary
---------------
* Gathering warm bodies ...  (jlaska, 14:59:05)
  * LINK:
    https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1
    (jlaska, 15:04:34)

* https://bugzilla.redhat.com/show_bug.cgi?id=516042  (jlaska, 15:04:56)
  * ACTION: jlaska to retest using anaconda-12.32 and post feedback into
    516042  (jlaska, 15:07:18)
  * ACTION: kparal to assist with filing any additional failures on the
    repo dialogs next week  (jlaska, 15:07:39)

* https://bugzilla.redhat.com/show_bug.cgi?id=519237  (jlaska, 15:08:00)
  * ACTION: jlaska to retest updated util-linux packages in 519237 using
    a rebuilt initrd  (jlaska, 15:10:32)
  * AGREED: keep 519237 on the F12Beta list ... impacts developers and
    servers  (jlaska, 15:21:04)
  * ACTION: jlaska will retest after rebuilding the initrd with the
    updated packages installed  (jlaska, 15:21:22)
  * AGREED: keep 519237 on the F12Beta list ... impacts developers and
    servers  (jlaska, 15:22:17)

* https://bugzilla.redhat.com/show_bug.cgi?id=522675  (jlaska, 15:22:27)
  * HELP: anyone experiencing problems with USB keyboard/mouse ...
    please add thoughts to bug#522675  (jlaska, 15:26:09)
  * ACTION: remove from F12Beta and continue working this issue
    (jlaska, 15:27:48)

* https://bugzilla.redhat.com/show_bug.cgi?id=526158  (jlaska, 15:28:56)
  * AGREED: remove bug#526158 from F12Beta  ... reasonable workaround
    exists and specific to VGA on ppc64  (jlaska, 15:32:49)
  * ACTION: jlaska to remove 526158 from F12Beta  (jlaska, 15:33:10)

* https://bugzilla.redhat.com/show_bug.cgi?id=526208  (jlaska, 15:34:05)
  * LINK: http://docs.fedoraproject.org/drafts.html   (stickster,
    15:37:19)
  * LINK:
    http://docs.fedoraproject.org/install-guide/f12/en-US/html-single/#d0e17809
    (jlaska, 15:38:34)
  * HELP: Help testing preupgrade from F-11 -> rawhide is needed ...
    please update bug#526208 with your findings  (jlaska, 15:44:52)
  * AGREED: Bug#526208 remains on the list and awaits additional testing
    to provide traceback  (jlaska, 15:45:46)

* https://bugzilla.redhat.com/show_bug.cgi?id=526320  (jlaska, 15:46:00)
  * AGREED: Bug#526320 remains a F12Beta blocker - can't have install
    images go missing for a primary arch  (jlaska, 15:48:24)
  * ACTION: Oxf13 will continue working 526320 for root cause  (jlaska,
    15:48:46)

* https://bugzilla.redhat.com/show_bug.cgi?id=526380  (jlaska, 15:49:02)
  * AGREED: bug#526380 remains on blocker list ... newer package already
    tagged  (jlaska, 15:51:44)
  * ACTION: move 526380 to CLOSED -> RAWHIDE as a newer package is
    already available  (jlaska, 15:52:00)
  * LINK: https://fedorahosted.org/rel-eng/ticket/2250   (Oxf13,
    15:53:02)

* https://bugzilla.redhat.com/show_bug.cgi?id=526470  (jlaska, 15:54:12)
  * AGREED: bug#526470 represents a larger issue related to the
    nfs-utils defaulting to v4 mounts (and then reverting).  This issue
    should remain a blocker and needs retesting  (jlaska, 16:07:49)
  * ACTION: Provide test root=nfs:... test feedback for bug 526470
    (jlaska, 16:08:30)

* https://bugzilla.redhat.com/show_bug.cgi?id=517260  (jlaska, 16:09:12)
  * AGREED: reopened bug 517260 is a valid blocker  (jlaska, 16:11:20)
  * ACTION: denise will help gather some devel feedback on the issue
    (jlaska, 16:11:39)

* https://bugzilla.redhat.com/show_bug.cgi?id=523862  (jlaska, 16:11:49)
  * AGREED: bug 523862 is a valid beta blocker  (jlaska, 16:14:39)
  * ACTION: feedback needed from dledford on 523862  (jlaska, 16:15:37)
  * ACTION: denise and jlaska reaching out for helpers  (jlaska,
    16:17:23)

* https://bugzilla.redhat.com/show_bug.cgi?id=526535  (jlaska, 16:17:50)
  * AGREED: after good discussion around related changes, the group
    agreed to accept a fix for bug#526535 and several other NM changes
    that would be good to get broad testing from beta testers  (jlaska,
    16:36:46)

* open discussion  (jlaska, 16:38:53)
  * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges,
    then follow up on the jlaska's mail with link to packages  (jlaska,
    16:39:38)

* https://bugzilla.redhat.com/show_bug.cgi?id=526652  (jlaska, 16:40:44)
  * ACTION: twaugh going to retest 526652 to further isolate the root
    cause  (jlaska, 16:52:10)

* https://bugzilla.redhat.com/show_bug.cgi?id=518880  (jlaska, 16:52:45)
  * AGREED: 518880 remains a final F12Blocker but isn't appropriate to
    block beta.  (jlaska, 16:56:20)
  * AGREED: bug 526208 represents a valid F-11 preupgrade package bug
    that should be fixed for F-12-Beta release  (jlaska, 17:05:24)

* https://bugzilla.redhat.com/show_bug.cgi?id=526652  (jlaska, 17:09:34)
  * AGREED: #526652 does not get promoted to beta blocker as it is not
    reproducible on other systems and a workaround is available  (adamw,
    17:20:05)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=526842 ?  (adamw,
    17:28:35)
  * AGREED: 526842 becomes a beta blocker, action is on developers
    (clumens+plymouth team)  (adamw, 17:32:19)

Meeting ended at 17:36:08 UTC.




Action Items
------------
* jlaska to retest using anaconda-12.32 and post feedback into 516042
* kparal to assist with filing any additional failures on the repo
  dialogs next week
* jlaska to retest updated util-linux packages in 519237 using a rebuilt
  initrd
* jlaska will retest after rebuilding the initrd with the updated
  packages installed
* remove from F12Beta and continue working this issue
* jlaska to remove 526158 from F12Beta
* Oxf13 will continue working 526320 for root cause
* move 526380 to CLOSED -> RAWHIDE as a newer package is already
  available
* Provide test root=nfs:... test feedback for bug 526470
* denise will help gather some devel feedback on the issue
* feedback needed from dledford on 523862
* denise and jlaska reaching out for helpers
* dcbw will fix keys not shown as well, then rebuild pacakges, then
  follow up on the jlaska's mail with link to packages
* twaugh going to retest 526652 to further isolate the root cause




Action Items, by person
-----------------------
* dcbw
  * dcbw will fix keys not shown as well, then rebuild pacakges, then
    follow up on the jlaska's mail with link to packages
* denise
  * denise will help gather some devel feedback on the issue
  * denise and jlaska reaching out for helpers
* jlaska
  * jlaska to retest using anaconda-12.32 and post feedback into 516042
  * jlaska to retest updated util-linux packages in 519237 using a
    rebuilt initrd
  * jlaska will retest after rebuilding the initrd with the updated
    packages installed
  * jlaska to remove 526158 from F12Beta
  * denise and jlaska reaching out for helpers
  * dcbw will fix keys not shown as well, then rebuild pacakges, then
    follow up on the jlaska's mail with link to packages
* Oxf13
  * Oxf13 will continue working 526320 for root cause
* twaugh
  * twaugh going to retest 526652 to further isolate the root cause
* **UNASSIGNED**
  * kparal to assist with filing any additional failures on the repo
    dialogs next week
  * remove from F12Beta and continue working this issue
  * move 526380 to CLOSED -> RAWHIDE as a newer package is already
    available
  * Provide test root=nfs:... test feedback for bug 526470
  * feedback needed from dledford on 523862




People Present (lines said)
---------------------------
* jlaska (214)
* adamw (185)
* Oxf13 (102)
* mclasen (31)
* buggbot (29)
* twaugh (28)
* wwoods (26)
* dcbw (17)
* steved (13)
* denise (10)
* greenlion (7)
* nirik (4)
* stickster (4)
* zodbot (3)
* thomasj (2)
* notting (2)
* crobinso (2)
* SMParrish (1)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From bruno at wolff.to  Fri Oct  2 18:50:46 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 2 Oct 2009 13:50:46 -0500
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References: 
	<1254500308.2546.3.camel@localhost.localdomain>
	
Message-ID: <20091002185046.GC20654@wolff.to>

On Fri, Oct 02, 2009 at 17:37:18 +0000,
  Mat?j Cepl  wrote:
> Jesse Keating  redhat.com> writes:
> > Releng and QA are very small groups.  The Fedora package set is
> > extremely large.  Over 8K packages.  The rate of change is far too grate
> > to provide second guessing over every package.
> 
> That's why I am surprised you want to click through all those requests for fixes
> in non-essential packages. Why not leave them open (or allow updates only when
> bug number is attached)?

Bugs can include RFEs as well as actual brokeness. I don't think that really
buys you anything. And a bad maintainer could just file an RFE for an
upgrade and refer to that bug when they provide the upgrade.



From mcepl at redhat.com  Fri Oct  2 18:51:15 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 2 Oct 2009 14:51:15 -0400 (EDT)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: <20091002185046.GC20654@wolff.to>
Message-ID: <1252729396.1310611254509475957.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>

----- "Bruno Wolff III"  wrote:
> Bugs can include RFEs as well as actual brokeness. I don't think that
> really buys you anything. And a bad maintainer could just file an RFE for an
> upgrade and refer to that bug when they provide the upgrade.

Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon.

Mat?j



From sgrubb at redhat.com  Fri Oct  2 18:51:33 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Fri, 2 Oct 2009 14:51:33 -0400
Subject: Switching to Native Upstart Scripts?
In-Reply-To: <20091002184243.GA22116@nostromo.devel.redhat.com>
References: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>
	<20091002184243.GA22116@nostromo.devel.redhat.com>
Message-ID: <200910021451.33159.sgrubb@redhat.com>

On Friday 02 October 2009 02:42:43 pm Bill Nottingham wrote:
> enforcing dependencies between SysV and upstart scripts  - if a package
>   that provides a service that a SysV service depends on (via LSB headers)
>   changes to an upstart script, things go wrong.

Also last time I checked, they still have not specified an audit facility. They 
have one for syslog, but not audit. And yes this matters.

-Steve



From SteveD at redhat.com  Fri Oct  2 18:53:35 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Fri, 02 Oct 2009 14:53:35 -0400
Subject: NFS and slow boot
In-Reply-To: 
References: 
Message-ID: <4AC64C2F.8040806@RedHat.com>



On 10/02/2009 02:13 PM, Valent Turkovic wrote:
> Hi,
> I'm building custom Fedora remix with some packages from RPMFusion and
> updated Fedora packages. Last Live USB image I created booted really slow
> (over 5 minutes). I tracked down the issue to nfs service. Even when this
> ISO image is used for installing Fedora to HDD the same issue is present.
> 
> After stopping nfs service boot time was around 30 seconds!
> 
> Did anybody else experience this issue? Should I report this as a bug 
> agaings NFS or livecd-creator?
Against livecd-creator of course!! ;-)

Is there any kind of a error being logged in /var/log/messages?

steved.



From walters at verbum.org  Fri Oct  2 18:59:11 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 2 Oct 2009 18:59:11 +0000
Subject: NFS and slow boot
In-Reply-To: <4AC64C2F.8040806@RedHat.com>
References:  <4AC64C2F.8040806@RedHat.com>
Message-ID: 

On Fri, Oct 2, 2009 at 6:53 PM, Steve Dickson  wrote:

>
> Is there any kind of a error being logged in /var/log/messages?
>

Wild guess; nfs client service is trying to look up the hostname (possibly
repeatedly), but it's broken.  I think in F11 something regressed in
anaconda/NetworkManager which no longer caused custom hostnames to be
written to /etc/hosts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valent.turkovic at gmail.com  Fri Oct  2 19:39:34 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 2 Oct 2009 19:39:34 +0000 (UTC)
Subject: NFS and slow boot
References:  <4AC64C2F.8040806@RedHat.com>
	
Message-ID: 

On Fri, 02 Oct 2009 18:59:11 +0000, Colin Walters wrote:

> Wild guess; nfs client service is trying to look up the hostname
> (possibly repeatedly), but it's broken.  I think in F11 something
> regressed in

Here you can see the bootchart from freshly built Fedora 11 updated 
packages:
http://dl.getdropbox.com/u/184632/bootchart-slow.png

and this is with nfs service turned off:
http://dl.getdropbox.com/u/184632/bootchart.png



-- 
pratite me na twitteru - www.twitter.com/valentt
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From a.badger at gmail.com  Fri Oct  2 20:19:57 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 02 Oct 2009 13:19:57 -0700
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: 
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>		<4AC5C5E3.2080508@gmail.com>
	
Message-ID: <4AC6606D.9000407@gmail.com>

On 10/02/2009 08:48 AM, Colin Walters wrote:
> On Fri, Oct 2, 2009 at 9:20 AM, Ha?kel Gu?mar  wrote:
> 
>>
>> *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples
>> python stacks
> 
> 
> In Debian's case of course there are actually *two* separate Python systems
> ;)
> 
> http://wiki.debian.org/DebianPythonFAQ
> 
> I didn't understand either and was quite confused trying to debug one of my
> Python applications on Debian, but if they're useful we might consider
> adopting one of them rather than reinventing another parallel install
> system.
> 
I brought up Debian's parallel install system before (I believe the last
time python24 python2 python3 came up) and someone did a quick anaysis
and said it wasn't a good idea.

Beyond that, I know that it won't work for managing python2 and python3.
 The languages have diverged too much.  It can manage things like
python24 python25 python26.... but that's not at issue right now.

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: 

From alsadi at gmail.com  Fri Oct  2 20:28:33 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 2 Oct 2009 23:28:33 +0300
Subject: creating a updated DVD with fedora install
In-Reply-To: <4AC647A9.7060708@bitwagon.com>
References: 
	<4AC647A9.7060708@bitwagon.com>
Message-ID: <385866f0910021328q1dc3efd5wea5e72fd370f474@mail.gmail.com>

we in ojuba.org have produced an updated Fedora-11-based distro +
rpmfusion + extra Arabic/Islamic software

this was on 2009/09/16

you may like to give it a try.

http://distrowatch.com/ojuba
http://www.ojuba.org/wiki/news/14300926-en

as mentioned by John Reiser we have used pungi



From drago01 at gmail.com  Fri Oct  2 20:31:51 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 2 Oct 2009 22:31:51 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: <1252729396.1310611254509475957.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
References: <20091002185046.GC20654@wolff.to>
	<1252729396.1310611254509475957.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
Message-ID: 

On Fri, Oct 2, 2009 at 8:51 PM, Matej Cepl  wrote:
> ----- "Bruno Wolff III"  wrote:
>> Bugs can include RFEs as well as actual brokeness. I don't think that
>> really buys you anything. And a bad maintainer could just file an RFE for an
>> upgrade and refer to that bug when they provide the upgrade.
>
> Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon.

Well but doesn't this defeats the purpose of "most have a bug attached" ?
If we trust maintainers to apply common sense a hard policy should not
be needed.

Also if you are unhappy with a process you should at least try to fix
it before drawing consequences like this (orphaning packages).



From jkeating at redhat.com  Fri Oct  2 20:44:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 02 Oct 2009 13:44:55 -0700
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References: 
	<1254500308.2546.3.camel@localhost.localdomain>
	
Message-ID: <1254516295.2511.1.camel@localhost.localdomain>

On Fri, 2009-10-02 at 17:37 +0000, Mat?j Cepl wrote:
> That's why I am surprised you want to click through all those requests for fixes
> in non-essential packages. Why not leave them open (or allow updates only when
> bug number is attached)? 

Because we don't have the infrastructure to handle only freezing some
packages at this point.  We're working on rolling that into bodhi, so
that once we freeze, bodhi is the tool used to propose freeze breaks,
publish proposed freeze breaks, and move things into the proper tags.
The critical path packages will just require QA/releng to sign off on
them before they get moved.  So freeze breaks will be treated just like
updates.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From michael.silvanus at gmail.com  Fri Oct  2 21:28:19 2009
From: michael.silvanus at gmail.com (Michel Alexandre Salim)
Date: Fri, 2 Oct 2009 17:28:19 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
Message-ID: <615c05430910021428h549ffa15xd7f7fd2c7d262854@mail.gmail.com>

On Thu, Oct 1, 2009 at 1:15 PM, David Malcolm  wrote:
> Proposal: Python 3 in Fedora 13
>
[snip]
> ?- I don't want to add extra work for package maintainers: ?if you
> maintain an SRPM of a python 2 module that's working for you, you
> shouldn't feel obligated to own a separate SRPM for python 3. ?If
> someone has a need for the module on python 3, they can take on that
> work.

In the case of a Python binding produced as part of a larger package,
though, how do we go about doing this?

Seems like the sensible way is to have the person wanting to do the
work sign up as co-maintainer, and take charge of the Rawhide branch
of the package.

Care must then be taken to make sure the F-12 and rawhide packages
don't diverge much, apart from any Python 3 fixes required. Any fix
that is 2.x-compatible should probably be merged to the F-12 build as
well, and upstreamed.


> The more difficult case is when the python module is emitted as part of
> the build of a larger module. ?Some examples:
> ?- the build of "rpm" itself emits an "rpm-python" subpackage.
> ?- Another example is the "postgres" srpm, which emits a
> "postgresql-python" subpackage.
>
>
> We could then %prep the rpm build for each of the above so that the
> python 3 support is built as a parallel component of the build,
> independently of the python 2 support e.g. by copying the python2
> support into a separate dir, then applying a patch as necessary (and
> somehow wiring up the configuration/make so it builds both...) ?The
> caveat here is that I haven't tried actually doing this yet for any of
> these packages. ?Issues with this approach:
> ?- I don't yet know if autoconfiguration will work well with both
> -devel packages installed
> ?- It will probably involve actually doing the porting work for each
> package (yay, we get to be leaders!)
> ?- Whoever does this for a package needs to work closely with the
> upstream for that package
>
Since yum is available during build, this would work (but is fugly):
- build as normal
- push out python2 files to buildroot
- after everything else is done, yum remove python-devel && yum
install python3-devel
- build python3 modules

Regards,

-- 
Michel Alexandre Salim



From a.badger at gmail.com  Fri Oct  2 22:00:34 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 02 Oct 2009 15:00:34 -0700
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <615c05430910021428h549ffa15xd7f7fd2c7d262854@mail.gmail.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	<615c05430910021428h549ffa15xd7f7fd2c7d262854@mail.gmail.com>
Message-ID: <4AC67802.7010209@gmail.com>

On 10/02/2009 02:28 PM, Michel Alexandre Salim wrote:

> Since yum is available during build, this would work (but is fugly):
> - build as normal
> - push out python2 files to buildroot
> - after everything else is done, yum remove python-devel && yum
> install python3-devel
> - build python3 modules

There used to be locking issues with running from inside of the spec.
Don't know if that still applies.  We may also be denying network access
to processes running inside of the buildroot.  (AFAIK, the buildroot is
constructed from outside.  Then we chroot into it and run the build).

Even if those aren't problems, we're probably better off going with the
traditional, build once, move build files to a new location, build a
second time.  install both sets of built files route.

(For instance, vim-minimal and vim-enhanced)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: 

From walters at verbum.org  Fri Oct  2 22:30:34 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 2 Oct 2009 22:30:34 +0000
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <4AC6606D.9000407@gmail.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
	<4AC5C5E3.2080508@gmail.com>
	
	<4AC6606D.9000407@gmail.com>
Message-ID: 

On Fri, Oct 2, 2009 at 8:19 PM, Toshio Kuratomi  wrote:

>
> I brought up Debian's parallel install system before (I believe the last
> time python24 python2 python3 came up) and someone did a quick anaysis
> and said it wasn't a good idea.
>

Fair enough, just wanted to be sure it was at least looked at.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dmaphy at googlemail.com  Fri Oct  2 23:46:04 2009
From: dmaphy at googlemail.com (Dominic Hopf)
Date: Sat, 03 Oct 2009 01:46:04 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References: 
Message-ID: <1254527164.12179.169.camel@localhost.localdomain>

Am Freitag, den 02.10.2009, 15:26 +0000 schrieb Matej Cepl:
> syncevolution -- SyncML client for evolution

I would like to maintain this package then.

Regards,
Dominic

-- 
Dominic Hopf 

http://dominichopf.de/

Key Fingerprint:
A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From poelstra at redhat.com  Fri Oct  2 23:50:54 2009
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 02 Oct 2009 16:50:54 -0700
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: <20091002094957.7590ebd3@ohm.scrye.com>
References: <4AC299AD.6070808@RedHat.com>
	<4AC2A390.90200@redhat.com>	<4AC2A89F.4030800@RedHat.com>
	<4AC2B280.6000400@gmail.com>	<1254293108.2242.17.camel@localhost.localdomain>				<1254335788.2242.27.camel@localhost.localdomain>		<20091001021938.GW5260@hansolo.jdub.homelinux.org>	
	<4AC520A5.1070001@redhat.com>
	<20091002094957.7590ebd3@ohm.scrye.com>
Message-ID: <4AC691DE.7020805@redhat.com>

Kevin Fenzi said the following on 10/02/2009 08:49 AM Pacific Time:
> On Thu, 01 Oct 2009 14:35:33 -0700
> John Poelstra  wrote:
> 
> ...snip...
> 
>> The current FESCo might also want to consider taking more of a 
>> leadership role in monitoring the release processes, tracking the 
>> schedule, and evaluating the quality of the release under development 
>> and our ability to release on time.  As the group responsible for 
>> guiding the technical direction of our releases I think this is 
>> something they should be more involved in.  I'd be glad to help
>> gather data they might need to do this and there might be others who
>> would be willing to help too.
> 
> I would love to. Can you show me the 28 hour days so I have some extra
> hours? :) 
> 
> Seriously tho, I think many of the FESCo folks _DO_ stay involved in
> lots of things, some of them might not be as visible as people think
> they would be. Or did you mean at some higher level? 
> 

I was thinking at a higher level and no, I wasn't trying to imply that 
nobody is working hard enough of needs to do more.  As I think about 
this more it was a suggestion of trading some things out and replacing 
them with others.  I'm also not intending to tell FESCo how to do their 
job or say that they are doing it wrong :-)

This came out of the original thread about people not understanding the 
milestones, etc.  It occurred to me that we might have a gap in our 
processes and I wondered who is responsible for all the maintainers 
knowing what the process and policies are around our important milestones.

Some of this happens naturally when I have to send out my email nags 
about stale feature pages, but what if in a perfect world there were no 
stale feature pages and thus my messages never went out? :)

FWIW I am hoping to update some of our wiki pages and send out more 
email reminders during Fedora 13.  Hopefully it will be helpful and not 
be considered spam.

>> I'm suggesting more proactive leadership from FESCo and clear 
>> initiatives to take Fedora to the next level versus only being 
>> responsible for approving features, proven packagers, and policy
>> matters.
>>
>> This is also my vision for the Fedora Board.
> 
> I think move involvement wherever we can get it great, but I don't
> think we should try and force people to do X hours of work on Y. 
> 

Absolutely agree.  It becomes more a matter of how we spend the same 
amount of time we are already.  It is easy to get really focused on 
managing the stuff we are already doing vs. looking for ways to stop 
doing some things (so meetings don't run two hours) and taking a broader 
view of asking if we are going in the direction we want to with the 
distro.  Are our releases getting better?  Are we meeting the needs of 
the community we are trying to build and serve?  How will we know if we 
are or are not?

> Also, if we want to require fesco and/or the board to be more involved
> and proactive, we should note these requirements for the next election. 
> 

I'm not sure if it is a requirement so much as it is a mindset that I am 
advocating.

> A possible idea for the next cycle: 
> 
> - Wait until we have the list of approved features. 
> - Divide them up amoung fesco and have a 'point contact' for each that
>   is a fesco member. 
> - Each member is responsible for testing/tracking/talking to the
>   feature owner and getting them what they need to get things done as
>   well as knowing if something is not ready/etc. 
> 
> I don't know how feasible this is given the large list of features
> however. 
> 

Sounds great to me, but would other members go for it? :)  Maybe this is 
along the lines of the "Features SIG" that someone suggested a ways back.

John



From sundaram at fedoraproject.org  Fri Oct  2 23:53:34 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Oct 2009 05:23:34 +0530
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: <4AC691DE.7020805@redhat.com>
References: <4AC299AD.6070808@RedHat.com>	<4AC2A390.90200@redhat.com>	<4AC2A89F.4030800@RedHat.com>	<4AC2B280.6000400@gmail.com>	<1254293108.2242.17.camel@localhost.localdomain>				<1254335788.2242.27.camel@localhost.localdomain>		<20091001021938.GW5260@hansolo.jdub.homelinux.org>		<4AC520A5.1070001@redhat.com>	<20091002094957.7590ebd3@ohm.scrye.com>
	<4AC691DE.7020805@redhat.com>
Message-ID: <4AC6927E.60106@fedoraproject.org>

On 10/03/2009 05:20 AM, John Poelstra wrote:

> 
> Sounds great to me, but would other members go for it? :)  Maybe this is
> along the lines of the "Features SIG" that someone suggested a ways back.

A important oddness of the feature process is that it is not actually
necessary for the feature to be in the distribution. So you send a nag
mail, feature owners ignores it, you "drop" the feature and the
functionality is still there. So unless the feature owner is actually
convinced it is worth the effort, he or she can let the feature be
"dropped" and continue just working on whatever they are.  I don't know
whether this can be fixed or is considered a problem but I think we
should see if we can do it in a different way.

Rahul



From sundaram at fedoraproject.org  Fri Oct  2 23:55:59 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Oct 2009 05:25:59 +0530
Subject: Switching to Native Upstart Scripts?
In-Reply-To: <200910021451.33159.sgrubb@redhat.com>
References: <935ead450910021116y704956c3xe064afb4cb015bd1@mail.gmail.com>	<20091002184243.GA22116@nostromo.devel.redhat.com>
	<200910021451.33159.sgrubb@redhat.com>
Message-ID: <4AC6930F.4000401@fedoraproject.org>

On 10/03/2009 12:21 AM, Steve Grubb wrote:
> On Friday 02 October 2009 02:42:43 pm Bill Nottingham wrote:
>> enforcing dependencies between SysV and upstart scripts  - if a package
>>   that provides a service that a SysV service depends on (via LSB headers)
>>   changes to an upstart script, things go wrong.
> 
> Also last time I checked, they still have not specified an audit facility. They 
> have one for syslog, but not audit. And yes this matters.

Have you talked to upstream about it? Upstart has been in the
distribution for quite sometime already. If there are particular
requirements for Fedora, we should have already communicated that.

Rahul



From christoph.wickert at googlemail.com  Sat Oct  3 00:54:19 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 03 Oct 2009 02:54:19 +0200
Subject: NFS and slow boot
In-Reply-To: 
References:  <4AC64C2F.8040806@RedHat.com>
	
	
Message-ID: <1254531259.4645.16.camel@localhost>

Am Freitag, den 02.10.2009, 19:39 +0000 schrieb Valent Turkovic:
> 
> Here you can see the bootchart from freshly built Fedora 11 updated 
> packages:
> http://dl.getdropbox.com/u/184632/bootchart-slow.png

I didn't know that akmods are part of a freshly installed Fedora. ;)

Regards,
Christoph



From dcbw at redhat.com  Sat Oct  3 01:17:48 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 02 Oct 2009 18:17:48 -0700
Subject: F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) -
 Recap
In-Reply-To: <1254509259.2253.75.camel@localhost.localdomain>
References: <1254426205.2388.251.camel@localhost.localdomain>
	<1254509259.2253.75.camel@localhost.localdomain>
Message-ID: <1254532668.11531.1.camel@localhost.localdomain>

On Fri, 2009-10-02 at 14:47 -0400, James Laska wrote:
> * https://bugzilla.redhat.com/show_bug.cgi?id=526535  (jlaska, 16:17:50)
>   * AGREED: after good discussion around related changes, the group
>     agreed to accept a fix for bug#526535 and several other NM changes
>     that would be good to get broad testing from beta testers  (jlaska,
>     16:36:46)
> 
> * open discussion  (jlaska, 16:38:53)
>   * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges,
>     then follow up on the jlaska's mail with link to packages  (jlaska,
>     16:39:38)

http://koji.fedoraproject.org/koji/taskinfo?taskID=1725454

* Fri Oct  2 2009 Dan Williams  - 0.7.996-4.git20091002
- install: fix -gnome package %pre script failures (rh #526519)
- nm: fix failures validating private keys when using the NSS crypto backend
- applet: fix crashes when clicking on menu but not associated (rh #526535)
- editor: fix crash editing wired 802.1x settings
- editor: fix secrets retrieval when editing connections

Testing much appreciated.

Thanks!
Dan




From bruno at wolff.to  Sat Oct  3 05:22:07 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Oct 2009 00:22:07 -0500
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: <1252729396.1310611254509475957.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
References: <20091002185046.GC20654@wolff.to>
	<1252729396.1310611254509475957.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
Message-ID: <20091003052207.GA6147@wolff.to>

On Fri, Oct 02, 2009 at 14:51:15 -0400,
  Matej Cepl  wrote:
> ----- "Bruno Wolff III"  wrote:
> > Bugs can include RFEs as well as actual brokeness. I don't think that
> > really buys you anything. And a bad maintainer could just file an RFE for an
> > upgrade and refer to that bug when they provide the upgrade.
> 
> Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon.

Which was sort of my point. If you trust them to behave, why not trust them
to do only appropriate updates? It could be argued that requiring a bug
number is a reminder that they should only be doing bug fixes. It still
seems like an unnecessary hoop to jump through if one wants to push out
an upstream bugfix release for which no open bugs exist.



From a.badger at gmail.com  Sat Oct  3 05:53:58 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 02 Oct 2009 22:53:58 -0700
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: <4AC6927E.60106@fedoraproject.org>
References: <4AC299AD.6070808@RedHat.com>	<4AC2A390.90200@redhat.com>	<4AC2A89F.4030800@RedHat.com>	<4AC2B280.6000400@gmail.com>	<1254293108.2242.17.camel@localhost.localdomain>				<1254335788.2242.27.camel@localhost.localdomain>		<20091001021938.GW5260@hansolo.jdub.homelinux.org>		<4AC520A5.1070001@redhat.com>	<20091002094957.7590ebd3@ohm.scrye.com>	<4AC691DE.7020805@redhat.com>
	<4AC6927E.60106@fedoraproject.org>
Message-ID: <4AC6E6F6.9020705@gmail.com>

On 10/02/2009 04:53 PM, Rahul Sundaram wrote:

> A important oddness of the feature process is that it is not actually
> necessary for the feature to be in the distribution. So you send a nag
> mail, feature owners ignores it, you "drop" the feature and the
> functionality is still there. So unless the feature owner is actually
> convinced it is worth the effort, he or she can let the feature be
> "dropped" and continue just working on whatever they are.  I don't know
> whether this can be fixed or is considered a problem but I think we
> should see if we can do it in a different way.
> 
It isn't always a problem at all.  Other times it is a huge problem.
NFSv4 by default is an example of a change that could cause problems.
The reason being that it affected numerous other pieces of the distro.
That kind of change needs coordination (even if it's just break the
world at the beginning of the cycle and everyone figures out workarounds
before beta.)

OTOH, Better WebCam Support was self contained among a few developers
who were already talking to each other.  This is a feature where
dropping it is only dropping the release notes portion, not the actual work.

So do we need to fix this?  I think recognizing that there's different
types of features and some of them can continue even if they are dropped
while others must be (wholly or partially) reverted if they are dropped
is step one.  Putting more effort (tracking development, making sure
that the owner knows what things need to be in place for what deadlines,
finding extra manpower if possible if a feature is slipping) towards the
ones that would need to be reverted if they don't complete is step two.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: 

From bruno at wolff.to  Sat Oct  3 06:57:51 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Oct 2009 01:57:51 -0500
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: 
References: <4AC29443.7030501@RedHat.com>
	<20090929231620.GA28169@localhost.localdomain>
	<4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<1254293108.2242.17.camel@localhost.localdomain>
	
	
	
Message-ID: <20091003065751.GB18342@wolff.to>

On Wed, Sep 30, 2009 at 19:00:12 +0200,
  Kevin Kofler  wrote:
> 
> So really, I see no practical argument against switching back to the 
> Alpha/Beta/Preview naming (and reintroducing the old Alpha ? again, as 
> useless as it was in practice, the psychological impact on developers 
> shouldn't be underestimated).

The (old) alpha freeze is extra work for some people and may not be worth the
extra work as compared to say the nightly snapshots. I also find freezes
annoying in that my rawhide machines don't get some updates during the
freeze. If there are things I am interested in, I have to grab them manually.
If the no frozen rawhide becomes a reality for F13, then this latter complaint
will become moot.

I'd rather see more work spent on clearly documenting what developers need
to get done by when and how to determine if stricter guidelines apply
to your package(s), because it is a feature or an especially important
package.



From pbrobinson at gmail.com  Sat Oct  3 09:09:20 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Oct 2009 10:09:20 +0100
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: 
References: 
Message-ID: <5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>

> syncevolution -- SyncML client for evolution

I'll take this one.

Peter



From ilyes.gouta at gmail.com  Sat Oct  3 09:12:04 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 3 Oct 2009 10:12:04 +0100
Subject: wmii window manager
Message-ID: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>

Hi all,

Do we have wmii (a window manager, http://wmii.suckless.org) packaged
for Fedora?

Regards,
Ilyes Gouta.



From dtimms at iinet.net.au  Sat Oct  3 12:06:28 2009
From: dtimms at iinet.net.au (David Timms)
Date: Sat, 03 Oct 2009 22:06:28 +1000
Subject: wmii window manager
In-Reply-To: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
Message-ID: <4AC73E44.4000900@iinet.net.au>

On 10/03/2009 07:12 PM, Ilyes Gouta wrote:
> Do we have wmii (a window manager, http://wmii.suckless.org) packaged
> for Fedora?
Not that I can see for f11 or rawhide.
Would you like to begin packaging it ?

DaveT.



From choeger at cs.tu-berlin.de  Sat Oct  3 12:23:01 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sat, 03 Oct 2009 14:23:01 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: <5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>
References: 
	<5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>
Message-ID: <1254572581.2949.2.camel@choeger5.umpa.netz>

Am Samstag, den 03.10.2009, 10:09 +0100 schrieb Peter Robinson:
> > syncevolution -- SyncML client for evolution
> 
> I'll take this one.
> 
> Peter


I've just commented on that package, but you're not yet maintaining it,
so I'll repeat what I've discussed with Mat?j already:

1. There is some bug with the libraries lying in /usr/lib/syncevolution
without patching no binary works out of the box

2. The sync-ui binary (which I wanted to test the most ;)) is missing.

regars

Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From pbrobinson at gmail.com  Sat Oct  3 12:55:06 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Oct 2009 13:55:06 +0100
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: <1254572581.2949.2.camel@choeger5.umpa.netz>
References: 
	<5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>
	<1254572581.2949.2.camel@choeger5.umpa.netz>
Message-ID: <5256d0b0910030555o80c715etf7a286f787c15625@mail.gmail.com>

2009/10/3 Christoph H?ger :
> Am Samstag, den 03.10.2009, 10:09 +0100 schrieb Peter Robinson:
>> > syncevolution -- SyncML client for evolution
>>
>> I'll take this one.
>>
>> Peter
>
>
> I've just commented on that package, but you're not yet maintaining it,
> so I'll repeat what I've discussed with Mat?j already:
>
> 1. There is some bug with the libraries lying in /usr/lib/syncevolution
> without patching no binary works out of the box
>
> 2. The sync-ui binary (which I wanted to test the most ;)) is missing.

yes, I'm aware of both of those issues. There's also a moblin gui for
it as well which is one of the reasons I'd like to maintain it. Plan
to add all of that in and a few other bits.

Peter



From ilyes.gouta at gmail.com  Sat Oct  3 13:45:06 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 3 Oct 2009 14:45:06 +0100
Subject: wmii window manager
In-Reply-To: <4AC73E44.4000900@iinet.net.au>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com> 
	<4AC73E44.4000900@iinet.net.au>
Message-ID: <234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>

Hi,

> Would you like to begin packaging it ?

Sounds good, still I've got to learn the process. It's all about
rebasing on rawhide and providing the right .spec file integrated into
the build system, isn't it?

Regards,
Ilyes Gouta.

On Sat, Oct 3, 2009 at 1:06 PM, David Timms  wrote:
> On 10/03/2009 07:12 PM, Ilyes Gouta wrote:
>>
>> Do we have wmii (a window manager, http://wmii.suckless.org) packaged
>> for Fedora?
>
> Not that I can see for f11 or rawhide.
> Would you like to begin packaging it ?
>
> DaveT.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From thomasj at fedoraproject.org  Sat Oct  3 13:51:27 2009
From: thomasj at fedoraproject.org (Thomas Janssen)
Date: Sat, 3 Oct 2009 15:51:27 +0200
Subject: wmii window manager
In-Reply-To: <234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
	<4AC73E44.4000900@iinet.net.au>
	<234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
Message-ID: 

2009/10/3 Ilyes Gouta :
> On Sat, Oct 3, 2009 at 1:06 PM, David Timms  wrote:
>> On 10/03/2009 07:12 PM, Ilyes Gouta wrote:
>>>
>>> Do we have wmii (a window manager, http://wmii.suckless.org) packaged
>>> for Fedora?

>> Would you like to begin packaging it ?

> Sounds good, still I've got to learn the process. It's all about
> rebasing on rawhide and providing the right .spec file integrated into
> the build system, isn't it?

http://fedoraproject.org/wiki/PackageMaintainers/Join

I could package it as well.. Check the page and the links in it. See
if you like to package and maintain it.

-- 
LG Thomas

Dubium sapientiae initium



From sundaram at fedoraproject.org  Sat Oct  3 13:49:01 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Oct 2009 19:19:01 +0530
Subject: wmii window manager
In-Reply-To: <234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
	<4AC73E44.4000900@iinet.net.au>
	<234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
Message-ID: <4AC7564D.3050705@fedoraproject.org>

On 10/03/2009 07:15 PM, Ilyes Gouta wrote:
> Hi,
> 
>> Would you like to begin packaging it ?
> 
> Sounds good, still I've got to learn the process. It's all about
> rebasing on rawhide and providing the right .spec file integrated into
> the build system, isn't it?

More or less. Refer to

http://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Feel free to ask if you need more help. A number of existing
contributors will be willing to guide you.

Rahul



From skvidal at fedoraproject.org  Sat Oct  3 13:55:47 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sat, 3 Oct 2009 09:55:47 -0400 (EDT)
Subject: Buyer Beware: A Major Change in NFS is about to happen
In-Reply-To: <4AC6E6F6.9020705@gmail.com>
References: <4AC299AD.6070808@RedHat.com> <4AC2A390.90200@redhat.com>
	<4AC2A89F.4030800@RedHat.com> <4AC2B280.6000400@gmail.com>
	<1254293108.2242.17.camel@localhost.localdomain>
	
	
	
	<1254335788.2242.27.camel@localhost.localdomain>
	
	<20091001021938.GW5260@hansolo.jdub.homelinux.org>
	 <4AC520A5.1070001@redhat.com>
	<20091002094957.7590ebd3@ohm.scrye.com>
	<4AC691DE.7020805@redhat.com> <4AC6927E.60106@fedoraproject.org>
	<4AC6E6F6.9020705@gmail.com>
Message-ID: 



On Fri, 2 Oct 2009, Toshio Kuratomi wrote:

> On 10/02/2009 04:53 PM, Rahul Sundaram wrote:
>
>
> So do we need to fix this?  I think recognizing that there's different
> types of features and some of them can continue even if they are dropped
> while others must be (wholly or partially) reverted if they are dropped
> is step one.  Putting more effort (tracking development, making sure
> that the owner knows what things need to be in place for what deadlines,
> finding extra manpower if possible if a feature is slipping) towards the
> ones that would need to be reverted if they don't complete is step two.
>

So it sounds like features for critical-path items need to be completely 
in or completely out. Versus features for non-critical path.

But is nfs critical path B/c anaconda can call mount to an 
nfs:// install point?


-sv




From sundaram at fedoraproject.org  Sat Oct  3 14:04:57 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Oct 2009 19:34:57 +0530
Subject: Buyer Beware: A  Major Change in NFS is about to happen
In-Reply-To: <20091002094957.7590ebd3@ohm.scrye.com>
References: <4AC299AD.6070808@RedHat.com>
	<4AC2A390.90200@redhat.com>	<4AC2A89F.4030800@RedHat.com>
	<4AC2B280.6000400@gmail.com>	<1254293108.2242.17.camel@localhost.localdomain>				<1254335788.2242.27.camel@localhost.localdomain>		<20091001021938.GW5260@hansolo.jdub.homelinux.org>	
	<4AC520A5.1070001@redhat.com>
	<20091002094957.7590ebd3@ohm.scrye.com>
Message-ID: <4AC75A09.3060909@fedoraproject.org>

On 10/02/2009 09:19 PM, Kevin Fenzi wrote:

> 
> - Wait until we have the list of approved features. 
> - Divide them up amoung fesco and have a 'point contact' for each that
>   is a fesco member. 

Having a FESCo owner to every feature in addition to the feature owner
might help. Abrt was part of the Fedora 11 feature list even though it
wasn't working as expected at that point. I posted to fedora-devel list
about this at a later point but nothing was changed. It is working now
well and deserves to be part of the Fedora 12 feature list but that
wasn't the case for the previous release.

It is a failure of the feature process not to have caught that.

Rahul



From mclasen at redhat.com  Sat Oct  3 14:47:39 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 03 Oct 2009 10:47:39 -0400
Subject: F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) -
 Recap
In-Reply-To: <1254532668.11531.1.camel@localhost.localdomain>
References: <1254426205.2388.251.camel@localhost.localdomain>
	<1254509259.2253.75.camel@localhost.localdomain>
	<1254532668.11531.1.camel@localhost.localdomain>
Message-ID: <1254581259.1690.0.camel@planemask>

On Fri, 2009-10-02 at 18:17 -0700, Dan Williams wrote:
> On Fri, 2009-10-02 at 14:47 -0400, James Laska wrote:
> > * https://bugzilla.redhat.com/show_bug.cgi?id=526535  (jlaska, 16:17:50)
> >   * AGREED: after good discussion around related changes, the group
> >     agreed to accept a fix for bug#526535 and several other NM changes
> >     that would be good to get broad testing from beta testers  (jlaska,
> >     16:36:46)
> > 
> > * open discussion  (jlaska, 16:38:53)
> >   * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges,
> >     then follow up on the jlaska's mail with link to packages  (jlaska,
> >     16:39:38)
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1725454
> 
> * Fri Oct  2 2009 Dan Williams  - 0.7.996-4.git20091002
> - install: fix -gnome package %pre script failures (rh #526519)
> - nm: fix failures validating private keys when using the NSS crypto backend
> - applet: fix crashes when clicking on menu but not associated (rh #526535)
> - editor: fix crash editing wired 802.1x settings
> - editor: fix secrets retrieval when editing connections
> 

Shouldn't you have built that in dist-f12 ?




From a.badger at gmail.com  Sat Oct  3 14:54:34 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 03 Oct 2009 07:54:34 -0700
Subject: Trade review for two zikula packages
Message-ID: <4AC765AA.2050104@gmail.com>

Hi,

Anyone want to trade reviews for two zikula packages?  We want to get
them approved and in so that Fedora Insight can be deployed with them
for Fedora 12.  Mel Chua and Rahul are in charge of them but I packaged
one of them and the other I reworked a bit.  I don't feel comfortable
reviewing the one I packaged and more eyes are always better on the other.

We one I packaged and needs to be reviewed by someone else:
  zikula-module-filterutils:
https://bugzilla.redhat.com/show_bug.cgi?id=526595

The one I modified so if no one else steps up I'll finish off once
filterutils is done (it depends on filterutils):
  zikula-module-pagemaster:
https://bugzilla.redhat.com/show_bug.cgi?id=519483

Together they will let Fedora Insight create pages with dynamic content.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: 

From joshuacov at googlemail.com  Sat Oct  3 15:13:21 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 3 Oct 2009 17:13:21 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
Message-ID: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>

I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
read the instructions here
http://www.x.org/wiki/Development/Documentation/ServerDebugging but
this didin't help. My Xserver goes in an infinite loop and starts
consuming 100% my cpu. Therefore the whole system freezes and I have
to manually reboot it. This happens all the time when I use firefox on
random sites. After restart there is nothing in the xorg.0.log and
everything repeats itself when I start firefox again. Therefore I need
to remove the savesession.js from the firefox home directory.

On the second mashine I also turned this on: handle SIGUSR1 nostop,
handle SIGUSR2 nostop, handle SIGPIPE nostop.

The Xserver just keeps running and I get no messages on the second
mashine. How to debug it?



From kevin.kofler at chello.at  Sat Oct  3 15:36:12 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 03 Oct 2009 17:36:12 +0200
Subject: "Fedora Insight" naming (was: Re: Trade review for two zikula
	packages)
References: <4AC765AA.2050104@gmail.com>
Message-ID: 

Toshio Kuratomi wrote:
> Fedora Insight

Hmmm, do we really have to conflict with RH's own software names?
http://sources.redhat.com/insight/

There are also several other pieces of software, companies etc. called 
"Insight". I think we need a more original name!

        Kevin Kofler



From pbrobinson at gmail.com  Sat Oct  3 15:54:06 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Oct 2009 16:54:06 +0100
Subject: dist-f12 locked?
Message-ID: <5256d0b0910030854p3f32b2br30229ffdef33eee2@mail.gmail.com>

Hi All,

The last day or so I've been getting the following error when doing a
'make build' on the F-12 branches of various packages. Is there a
reason for the branch being locked?

Peter

Usage: koji build [options] target URL
(Specify the --help global option for a list of other help options)

koji: error: Destination tag dist-f12 is locked
make: *** [build] Error 1



From Fedora at FamilleCollet.com  Sat Oct  3 16:02:24 2009
From: Fedora at FamilleCollet.com (Remi Collet)
Date: Sat, 03 Oct 2009 18:02:24 +0200
Subject: dist-f12 locked?
In-Reply-To: <5256d0b0910030854p3f32b2br30229ffdef33eee2@mail.gmail.com>
References: <5256d0b0910030854p3f32b2br30229ffdef33eee2@mail.gmail.com>
Message-ID: <4AC77590.8080608@FamilleCollet.com>

Le 03/10/2009 17:54, Peter Robinson a ?crit :
> Hi All,
> 
> The last day or so I've been getting the following error when doing a
> 'make build' on the F-12 branches of various packages. Is there a
> reason for the branch being locked?

cvs update ?
(new build target is updates candidates)

> 
> Peter
> 
> Usage: koji build [options] target URL
> (Specify the --help global option for a list of other help options)
> 
> koji: error: Destination tag dist-f12 is locked
> make: *** [build] Error 1
> 



From mclasen at redhat.com  Sat Oct  3 15:40:19 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 03 Oct 2009 11:40:19 -0400
Subject: F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) -
 Recap
In-Reply-To: <1254581259.1690.0.camel@planemask>
References: <1254426205.2388.251.camel@localhost.localdomain>
	<1254509259.2253.75.camel@localhost.localdomain>
	<1254532668.11531.1.camel@localhost.localdomain>
	<1254581259.1690.0.camel@planemask>
Message-ID: <1254584419.1690.8.camel@planemask>

On Sat, 2009-10-03 at 10:47 -0400, Matthias Clasen wrote:
> On Fri, 2009-10-02 at 18:17 -0700, Dan Williams wrote:
> > On Fri, 2009-10-02 at 14:47 -0400, James Laska wrote:
> > > * https://bugzilla.redhat.com/show_bug.cgi?id=526535  (jlaska, 16:17:50)
> > >   * AGREED: after good discussion around related changes, the group
> > >     agreed to accept a fix for bug#526535 and several other NM changes
> > >     that would be good to get broad testing from beta testers  (jlaska,
> > >     16:36:46)
> > > 
> > > * open discussion  (jlaska, 16:38:53)
> > >   * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges,
> > >     then follow up on the jlaska's mail with link to packages  (jlaska,
> > >     16:39:38)
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1725454
> > 
> > * Fri Oct  2 2009 Dan Williams  - 0.7.996-4.git20091002
> > - install: fix -gnome package %pre script failures (rh #526519)
> > - nm: fix failures validating private keys when using the NSS crypto backend
> > - applet: fix crashes when clicking on menu but not associated (rh #526535)
> > - editor: fix crash editing wired 802.1x settings
> > - editor: fix secrets retrieval when editing connections
> > 
> 
> Shouldn't you have built that in dist-f12 ?

I've started an F12 build now, so we can get some testing over the
weekend:  http://koji.fedoraproject.org/koji/taskinfo?taskID=1725789




From pbrobinson at gmail.com  Sat Oct  3 16:07:19 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Oct 2009 17:07:19 +0100
Subject: dist-f12 locked?
In-Reply-To: <4AC77590.8080608@FamilleCollet.com>
References: <5256d0b0910030854p3f32b2br30229ffdef33eee2@mail.gmail.com>
	<4AC77590.8080608@FamilleCollet.com>
Message-ID: <5256d0b0910030907sd466048v1414e1f1c8a7814b@mail.gmail.com>

On Sat, Oct 3, 2009 at 5:02 PM, Remi Collet  wrote:
> Le 03/10/2009 17:54, Peter Robinson a ?crit :
>> Hi All,
>>
>> The last day or so I've been getting the following error when doing a
>> 'make build' on the F-12 branches of various packages. Is there a
>> reason for the branch being locked?
>
> cvs update ?
> (new build target is updates candidates)

ah, did that on the local branch not the root of the package. I was
sure had but its fixed the problem. Thanks!

Peter



From maxamillion at gmail.com  Sat Oct  3 17:04:49 2009
From: maxamillion at gmail.com (Adam Miller)
Date: Sat, 3 Oct 2009 12:04:49 -0500
Subject: wmii window manager
In-Reply-To: 
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
	<4AC73E44.4000900@iinet.net.au>
	<234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
	<4AC7564D.3050705@fedoraproject.org>
	
Message-ID: 

Doesn't it mention somewhere in the wmii documentation that wmii is not
intended for packaging because many of the user configuration options are to
be set in a header file pre compile? I could be wrong but seem to remember
reading that about both wmii and ion.

-Adam
>From Android

On Oct 3, 2009 8:52 AM, "Rahul Sundaram"  wrote:

On 10/03/2009 07:15 PM, Ilyes Gouta wrote: > Hi, > >> Would you like to
begin packaging it ? > > S...
More or less. Refer to

http://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Feel free to ask if you need more help. A number of existing
contributors will be willing to guide you.

Rahul

--

fedora-devel-list mailing list fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mcepl at redhat.com  Sat Oct  3 18:11:21 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 3 Oct 2009 18:11:21 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
References:  <1254506338.2742.7.camel@localhost>
Message-ID: 

Christoph Wickert, Fri, 02 Oct 2009 19:58:58 +0200:
> I'm going to take over nimbus. I already reviewed it and you asked me
> for co-maintenance. Sorry I didn't find the time to look into the EPEL
> build error sooner, it's still on my todo list.

Ownership released. Concernig bug https://bugzilla.redhat.com/
show_bug.cgi?id=522151 I think, I've got there a working solution. It 
might not be as cool as possible, but I think it works, and it should be 
(hopefully) reliable solution.

Basically I believe that this bug is solved pending your approval.

Mat?j



From mcepl at redhat.com  Sat Oct  3 18:21:17 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 3 Oct 2009 18:21:17 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
References: 
	<1254527164.12179.169.camel@localhost.localdomain>
Message-ID: 

Dominic Hopf, Sat, 03 Oct 2009 01:46:04 +0200:
>> syncevolution -- SyncML client for evolution
> 
> I would like to maintain this package then.

Talk with Peter Robinson about comaintainership.

Mat?j



From pbrobinson at gmail.com  Sat Oct  3 18:42:03 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Oct 2009 19:42:03 +0100
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: 
References: 
	<1254527164.12179.169.camel@localhost.localdomain>
	
Message-ID: <5256d0b0910031142m7672e877y1aa8bd347b8950ff@mail.gmail.com>

On Sat, Oct 3, 2009 at 7:21 PM, Matej Cepl  wrote:
> Dominic Hopf, Sat, 03 Oct 2009 01:46:04 +0200:
>>> syncevolution -- SyncML client for evolution
>>
>> I would like to maintain this package then.
>
> Talk with Peter Robinson about comaintainership.

I'll quite happily have someone to help co-maintain it :) Just request
it in pkgdb :)

Peter



From mcepl at redhat.com  Sat Oct  3 18:20:47 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 3 Oct 2009 18:20:47 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
References: 
	<5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>
	<1254572581.2949.2.camel@choeger5.umpa.netz>
Message-ID: 

Christoph H?ger, Sat, 03 Oct 2009 14:23:01 +0200:
> 2. The sync-ui binary (which I wanted to test the most ;)) is missing.

It is not missing in devel (now F-12) package. But it is still not 
working correctly due to %{_libdir}/syncevolution packages.

Mat?j



From mcepl at redhat.com  Sat Oct  3 18:19:44 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 3 Oct 2009 18:19:44 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
References: 
	<5256d0b0910030209u5ac96f59t98033d8956309213@mail.gmail.com>
Message-ID: 

Peter Robinson, Sat, 03 Oct 2009 10:09:20 +0100:
>> syncevolution -- SyncML client for evolution
> 
> I'll take this one.

Released in pkgdb. Thanks.

Mat?j



From christoph.wickert at googlemail.com  Sat Oct  3 18:01:40 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 03 Oct 2009 20:01:40 +0200
Subject: wmii window manager
In-Reply-To: 
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
	<4AC73E44.4000900@iinet.net.au>
	<234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com>
	<4AC7564D.3050705@fedoraproject.org>
	
	
Message-ID: <1254592900.2762.1.camel@localhost>

Am Samstag, den 03.10.2009, 12:04 -0500 schrieb Adam Miller:
> Doesn't it mention somewhere in the wmii documentation that wmii is
> not intended for packaging because many of the user configuration
> options are to be set in a header file pre compile? I could be wrong
> but seem to remember reading that about both wmii and ion.

That was dwm, which is also hosted at suckless.org and from the same
author IIRC:
"Because dwm is customized through editing its source code, it?s
pointless to make binary packages of it. This keeps its userbase small
and elitist. No novices asking stupid questions."

http://dwm.suckless.org/

> -Adam

Regards,
Christoph




From yersinia.spiros at gmail.com  Sat Oct  3 20:09:17 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Sat, 3 Oct 2009 22:09:17 +0200
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: <1254417309.9551.34.camel@radiator.bos.redhat.com>
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
Message-ID: 

On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm  wrote:

> Proposal: Python 3 in Fedora 13
>
> "Evolutionary, not revolutionary": build a python 3 stack
> parallel-installable with the python 2 stack.
>
> = High-level summary =
>  - Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
> latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
>  - Other distros have python 3, though not necessarily with anything
> "on top" resembling the full python 2 stack.
>  - We have a working, valuable python 2 stack, which is used by
> critical system components (yum and anaconda): we must not destabilize
> the python 2 stack.
>  - Python 3 is sufficiently different from python 2 that we need them
> to be independent software stacks.
>  - I plan to spend a large chunk of my $DAYJOB over the next few months
> trying to build a useful Python 3 stack for Fedora 13, for some
> definition of "useful" (help will be appreciated!)
>  - I don't want to add extra work for package maintainers:  if you
> maintain an SRPM of a python 2 module that's working for you, you
> shouldn't feel obligated to own a separate SRPM for python 3.  If
> someone has a need for the module on python 3, they can take on that
> work.
>
> = Background =
> Python 3 is intended by upstream to be the future of Python, but we have
> many critical components that use Python 2.  Python 2 and Python 3 are
> sufficiently different that we need both (try writing "print" in each).
> Python 2 will be around for a long time.
>
> An interesting summary of Python 3 adoption can be seen here:
>
> http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html
>
> An earlier proposal about python 3 in Fedora is here:
> https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
>
> Going forward, I will have plenty of time to spend, as part of my
> dayjob, on Python in Fedora [1]
>
> = Proposal =
> I want to get python 3 into Fedora, but I don't want to break yum or
> anaconda (or anything else, for that matter!)
>
> How to do this?  I propose that Fedora shall have separate,
> parallel-installable Python 2 and Python 3 stacks.  I believe we can get
> things to the point where on a Fedora box you'd be able to install both
> stacks, and have some processes running python 2 code, and some running
> python 3, simultaneously.
>
> Where I would draw the line is on having both python 2 and python 3
> running within the same _process_: the two libraries share most of their
> symbol names, but with differing implementations, and the result of
> trying to dynamically link the two into the same address space would be
> highly unstable.
>
> As an example, you'd be able to install both mod_python and mod_python3
> rpms, but you wouldn't be able to (sanely) configure httpd to have both
> running simultaneously (I guess we should add a run-time warning for
> this case)
>
> Scoping:
>  - this work would target Fedora 13.  I'd avoid pushing it into F12
> until it's proven safe to do so
>  - the proposal is for python 2 vs python 3.  It could be extended to
> support having multiple minor-versions of Python as well, but that's a
> big extension of the work involved and not something I'm planning to
> work on myself.
>
> = Details =
> We should split python 2 and python 3 at the source RPM level, where
> possible.
>
> The easy case is when upstream release separate tarballs for the python
> 2 and python 3 versions of code.  For example, given package
> "python-foo" in packaging CVS, there would be a separate "python3-foo"
> for the python 3 version.  There would be no expectation that the two
> would need to upgrade in lock-step.  (The two SRPMS could have different
> maintainers within Fedora: the packager of a python 2 module might not
> yet have any interest in python 3)
>
> The more difficult case is when the python module is emitted as part of
> the build of a larger module.  Some examples:
>  - the build of "rpm" itself emits an "rpm-python" subpackage.
>  - Another example is the "postgres" srpm, which emits a
> "postgresql-python" subpackage.
>
> In a quick attempt at seeing other examples, on my laptop (F11), here
> are the packages installed that provide python modules where the package
> name differs from the srpm name:
> $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not owned" |
>
SIA, this is off of topic , i am sure. BUT, it is very strange that could be
exists, perhaps, some file or directory  not owned by someone. Isn't it ?

> sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}
> %{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0, col1 from
> - where col0 != col1
>                                    col0|                              col1|
>
> ----------------------------------------+----------------------------------+
>             at-spi-python-1.26.0-1.fc11|              at-spi-1.26.0-1.fc11|
>         audit-libs-python-1.7.13-1.fc11|               audit-1.7.13-1.fc11|
>                cracklib-python-2.8.13-4|                 cracklib-2.8.13-4|
>              gamin-python-0.1.10-4.fc11|               gamin-0.1.10-4.fc11|
>                hplip-libs-3.9.8-12.fc11|               hplip-3.9.8-12.fc11|
>           libproxy-python-0.2.3-10.fc11|            libproxy-0.2.3-10.fc11|
>         libselinux-python-2.0.80-1.fc11|          libselinux-2.0.80-1.fc11|
>        libsemanage-python-2.0.31-4.fc11|         libsemanage-2.0.31-4.fc11|
>                 libuser-python-0.56.9-3|                  libuser-0.56.9-3|
>             libxml2-python-2.7.3-3.fc11|              libxml2-2.7.3-3.fc11|
>              newt-python-0.52.10-4.fc11|               newt-0.52.10-4.fc11|
> plague-common-0.4.5.7-5.20090612cvs.fc11|
> plague-0.4.5.7-5.20090612cvs.fc11|
> policycoreutils-python-2.0.62-12.12.fc11|
> policycoreutils-2.0.62-12.12.fc11|
>                python-magic-5.03-2.fc11|                  file-5.03-2.fc11|
>          python-slip-dbus-0.1.15-3.fc11|         python-slip-0.1.15-3.fc11|
>           python-slip-gtk-0.1.15-3.fc11|         python-slip-0.1.15-3.fc11|
>                 rpm-python-4.7.1-1.fc11|                  rpm-4.7.1-1.fc11|
>     setroubleshoot-server-2.1.14-3.fc11|      setroubleshoot-2.1.14-3.fc11|
>
>  system-config-printer-libs-1.1.8-6.fc11|system-config-printer-1.1.8-6.fc11|
>
> Such SRPMS have a:
>  BuildRequires: python-devel
> which is a subpackage from the python build (2.6)
>
> My plan here is that we should create a python3-devel subpackage as a
> subpackage of the python3 build, and have it parallel-installable with
> the python-devel package.
>
> We could then %prep the rpm build for each of the above so that the
> python 3 support is built as a parallel component of the build,
> independently of the python 2 support e.g. by copying the python2
> support into a separate dir, then applying a patch as necessary (and
> somehow wiring up the configuration/make so it builds both...)  The
> caveat here is that I haven't tried actually doing this yet for any of
> these packages.  Issues with this approach:
>  - I don't yet know if autoconfiguration will work well with both
> -devel packages installed
>  - It will probably involve actually doing the porting work for each
> package (yay, we get to be leaders!)
>  - Whoever does this for a package needs to work closely with the
> upstream for that package
>
> I'll have a go at doing this for rpm when I get back from vacation.
> Arguably the existing python 2 binding of rpm isn't great, but it's
> probably best to go for close compatibility between python 2 and python
> 3 rather than try to overhaul the bindings as part of the port to python
> 3: one thing at a time!
>
>
> "Naming convention" proposal:
> How does this sound:
>  - an rpm with a "python-" prefix means a python 2 rpm, of the
> "default" python 2 minor version (for Fedora this will be the most
> recent stable upstream minor release, for EPEL it will be the minor
> release of 2 that came with the distro, so 2.4 for EPEL5)
>
>  - an rpm with a "python3-" prefix means a python 3 rpm, of the
> "default" python 3 minor version (for Fedora this will be the most
> recent stable upstream release)
>
>  (we could extend this to have specific minor-releases (e.g. use
> "python24-" for a python 2.4 stack, in case some brave soul wants to get
> zope/plone running.  But may be better to try to fix the zope/2.6
> incompatibility at that point (caveat: haven't looked at the details of
> the issue).  I don't intend to work on such versions))
>
> What about packages without a "python-" prefix?  Proposal:  If upstream
> has a naming convention for python2 vs python3, use it.  Otherwise, add
> a "python3-" prefix to make things clear.  I'm not sure about the
> details here.  Examples?
>
> There have been various discussions upstream about what to call the
> python 3 binary.  My favorite quote on the subject is from Guido,
> http://mail.python.org/pipermail/python-3000/2008-March/012421.html :
> > During the next 3 years or so, installing Py3k as the default "python"
> > will be a deed of utter irresponsibility and is likely to break your
> > system in subtle ways (both OSX and Linux these days use Python for
> > certain system tasks). If you *really* want to shoot yourself in the
> > foot this way, go ahead and explicitly use "make altinstall
> > bininstall" or link it yourself.
>
> I propose that for Fedora we have "/usr/bin/python3" for the
> system/default version of python 3 and "/usr/bin/python" for the
> system/default version of python 2.  Both would be symlinks to a binary
> with the minor-release embedded in the name ("/usr/bin/python3.1" and
> "/usr/bin/python/2.6").
>
> As I understand things, this should make us broadly in agreement with
> upstream; see e.g.:
> http://mail.python.org/pipermail/python-dev/2009-April/088862.html
> http://mail.python.org/pipermail/python-dev/2009-April/088884.html
>
> A rough plan for Fedora 13 might be:
>  - get python3 packaged in a manner compatible with the above
>    - (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct
> python when building rpms containing .py files)
>  - get rpm bindings working with python3
>  - get some useful components working e.g. a web stack: Django,
> TurboGears etc (though e.g. Django's py3k support is a long way off
> IIRC); ideas?
>  - solidify packaging guidelines for python 2 vs python 3 once we've
> got some experience with the above and hopefully proven the techniques
>  - look at porting major components over to python3 (but probably don't
> actually do this for F13; leave python 2 as the critical component, I
> suspect):
>    - yum (rpm)
>    - anaconda
>
> However "no plan survives contact with the enemy", we'll see how things
> turn out in reality when trying to get a full integrated stack working.
>
> Future work (F14?) could involve cutting over the major components, so
> that the base install would bring in "python3", and "python" would
> become optional.  Obviously there's a _lot_ to be done before that can
> be done sanely.
>
> = Progress so far =
> I've put together a somewhat-working python3 srpm, based on the python
> srpm (with lots of FIXMEs added...)  It's not yet ready for a formal
> package review (I'm working through the various patches, and it's not
> yet fully installable in parallel with the python 2 stack), but you can
> see the specfile here:
>  http://people.redhat.com/dmalcolm/python3/python3.spec
> and an SRPM here:
>  http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm
>
> After I did this work, I saw that a couple of other people have written
> Python 3 srpms for Fedora:
>  http://ivazquez.fedorapeople.org/packages/python3000/
> and
>  https://bugzilla.redhat.com/show_bug.cgi?id=526126
> and there was this proposal for doing Python 3 in F10:
>
> https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
> similar to this one.  Obviously I want to work with those people to come
> up with a working python 3 rpm in Fedora.
>
> There's also the merge-review for python:
> https://bugzilla.redhat.com/show_bug.cgi?id=226342 ; many of the
> comments there would thus also apply to my srpm, given that I used the
> former as my starting point.
>
> On a tangent: we currently have 2.6.2 in F12/rawhide.  Upstream is
> preparing a 2.6.3 release, with many bugfixes.  This seems to me like a
> candidate for F13.  (the release notes for the 2.6.3 rc are long; I'd
> want it to have a _lot_ of testing before pushing it to F12))
>
>
> Thoughts?
> Dave
>
> [1] I'm being transferred at work, and will be able to spend a lot of
> time on Python within Fedora.  Previously, my job involved keeping
> various internal RH systems working (with any Fedora work done
> afterhours or as a side project).  Having said that, I'm about to go on
> vacation with no access to a computer for the period October 3rd-10th
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dmaphy at googlemail.com  Sat Oct  3 21:04:54 2009
From: dmaphy at googlemail.com (Dominic Hopf)
Date: Sat, 03 Oct 2009 23:04:54 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: <5256d0b0910031142m7672e877y1aa8bd347b8950ff@mail.gmail.com>
References: 
	<1254527164.12179.169.camel@localhost.localdomain>
	
	<5256d0b0910031142m7672e877y1aa8bd347b8950ff@mail.gmail.com>
Message-ID: <1254603894.12179.270.camel@localhost.localdomain>

Am Samstag, den 03.10.2009, 19:42 +0100 schrieb Peter Robinson:
> On Sat, Oct 3, 2009 at 7:21 PM, Matej Cepl  wrote:
> > Dominic Hopf, Sat, 03 Oct 2009 01:46:04 +0200:
> >>> syncevolution -- SyncML client for evolution
> >>
> >> I would like to maintain this package then.
> >
> > Talk with Peter Robinson about comaintainership.
> 
> I'll quite happily have someone to help co-maintain it :) Just request
> it in pkgdb :)

Done. :)

Regards,
Dominic

-- 
Dominic Hopf 

http://dominichopf.de/

Key Fingerprint:
A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From ilyes.gouta at gmail.com  Sat Oct  3 21:58:14 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 3 Oct 2009 22:58:14 +0100
Subject: wmii window manager
In-Reply-To: <1254592900.2762.1.camel@localhost>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com> 
	<4AC73E44.4000900@iinet.net.au>
	<234fa2210910030645k4fe3da4ci89ff62d21bb00595@mail.gmail.com> 
	<4AC7564D.3050705@fedoraproject.org>
	 
	 
	<1254592900.2762.1.camel@localhost>
Message-ID: <234fa2210910031458v16d55891td9eefd63d09da7a0@mail.gmail.com>

Hi,

wmii requires dmenu, libixp-0.4 and p9p. Packages for Debian already
exist. I guess it's doable for Fedora too.

Regards,
Ilyes Gouta.

On Sat, Oct 3, 2009 at 7:01 PM, Christoph Wickert
 wrote:
> Am Samstag, den 03.10.2009, 12:04 -0500 schrieb Adam Miller:
>> Doesn't it mention somewhere in the wmii documentation that wmii is
>> not intended for packaging because many of the user configuration
>> options are to be set in a header file pre compile? I could be wrong
>> but seem to remember reading that about both wmii and ion.
>
> That was dwm, which is also hosted at suckless.org and from the same
> author IIRC:
> "Because dwm is customized through editing its source code, it?s
> pointless to make binary packages of it. This keeps its userbase small
> and elitist. No novices asking stupid questions."
>
> http://dwm.suckless.org/
>
>> -Adam
>
> Regards,
> Christoph
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From opensource at till.name  Sat Oct  3 22:00:44 2009
From: opensource at till.name (Till Maas)
Date: Sun, 04 Oct 2009 00:00:44 +0200
Subject: wmii window manager
In-Reply-To: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
Message-ID: <20091003220044.GA4593@genius.kawo2.rwth-aachen.de>

On Sat, Oct 03, 2009 at 10:12:04AM +0100, Ilyes Gouta wrote:

> Do we have wmii (a window manager, http://wmii.suckless.org) packaged
> for Fedora?

I packaged it a while ago for myself, but I am currently using xmonad.
Maybe you can use my old SPECS / SRPMS:

http://till.fedorapeople.org/tmp/libixp-0.2-1.src.rpm
http://till.fedorapeople.org/tmp/libixp.spec
http://till.fedorapeople.org/tmp/wmii-3.5.1-1.src.rpm
http://till.fedorapeople.org/tmp/wmii-4.0-0.1.20060705.src.rpm
http://till.fedorapeople.org/tmp/wmii.spec

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From ilyes.gouta at gmail.com  Sat Oct  3 22:10:35 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 3 Oct 2009 23:10:35 +0100
Subject: wmii window manager
In-Reply-To: <20091003220044.GA4593@genius.kawo2.rwth-aachen.de>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com> 
	<20091003220044.GA4593@genius.kawo2.rwth-aachen.de>
Message-ID: <234fa2210910031510r2a3582cfv7315d401249f22ac@mail.gmail.com>

Till,

Is it in line with rawhide? Did you ever pushed it into koji? Do you
have a packaged p2p (plan9 on Unix)?

-Ilyes

On Sat, Oct 3, 2009 at 11:00 PM, Till Maas  wrote:
> On Sat, Oct 03, 2009 at 10:12:04AM +0100, Ilyes Gouta wrote:
>
>> Do we have wmii (a window manager, http://wmii.suckless.org) packaged
>> for Fedora?
>
> I packaged it a while ago for myself, but I am currently using xmonad.
> Maybe you can use my old SPECS / SRPMS:
>
> http://till.fedorapeople.org/tmp/libixp-0.2-1.src.rpm
> http://till.fedorapeople.org/tmp/libixp.spec
> http://till.fedorapeople.org/tmp/wmii-3.5.1-1.src.rpm
> http://till.fedorapeople.org/tmp/wmii-4.0-0.1.20060705.src.rpm
> http://till.fedorapeople.org/tmp/wmii.spec
>
> Regards
> Till
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From opensource at till.name  Sun Oct  4 00:49:10 2009
From: opensource at till.name (Till Maas)
Date: Sun, 04 Oct 2009 02:49:10 +0200
Subject: wmii window manager
In-Reply-To: <234fa2210910031510r2a3582cfv7315d401249f22ac@mail.gmail.com>
References: <234fa2210910030212g69b9b762m834cd36a8c589559@mail.gmail.com>
	<20091003220044.GA4593@genius.kawo2.rwth-aachen.de>
	<234fa2210910031510r2a3582cfv7315d401249f22ac@mail.gmail.com>
Message-ID: <20091004004910.GA28735@genius.kawo2.rwth-aachen.de>

On Sat, Oct 03, 2009 at 11:10:35PM +0100, Ilyes Gouta wrote:

> Is it in line with rawhide? Did you ever pushed it into koji? Do you
> have a packaged p2p (plan9 on Unix)?

I never submitted it into Fedora, I just created the SPEC for myself to
test wmii. As you can see from the dates of the changelogs, the files
are from February 2007 and probably need some adjusting. I don't think I
created a SPEC for p2p.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From kevin.kofler at chello.at  Sun Oct  4 02:02:39 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Oct 2009 04:02:39 +0200
Subject: clutter-cairomm is obsolete and should be retired
Message-ID: 

Hi,

(I've already mailed this to the maintainer on October 1st, no answer so far.)

clutter-cairomm has longstanding broken dependencies in Fedora 12:
        clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
        clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
        clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
        clutter-cairomm-devel-0.7.4-2.fc11.i586 requires 
pkgconfig(cluttermm-0.8)
        clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)

It turns out this is because clutter-cairo, which this was wrapping, isn't in
Fedora at all anymore, clutter obsoletes it:
http://cvs.fedoraproject.org/viewvc/rpms/clutter/devel/clutter.spec?r1=1.28&r2=1.29
https://fedorahosted.org/rel-eng/ticket/2005

Upstream also considers it obsolete:
http://git.gnome.org/cgit/clutter-cairomm/commit/?id=cb06f43f509b6609ddc055b08aa1a3d7a43d500e

and there will apparently be no new release to work with the new Clutter API,
instead cluttermm should be used directly.

So IMHO we should:
1. have cluttermm obsolete clutter-cairomm and
2. follow the package retirement policy: 
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life for
clutter-cairomm, in particular get it blocked from F12 by rel-eng as soon as
possible.

Nothing in Rawhide requires clutter-cairomm according to:
repoquery --repoid=rawhide --whatrequires --alldeps clutter-cairomm

        Kevin Kofler



From jan.klepek at brandforge.sk  Sun Oct  4 08:02:42 2009
From: jan.klepek at brandforge.sk (jan.klepek at brandforge.sk)
Date: Sun, 4 Oct 2009 10:02:42 +0200 (CEST)
Subject: orphaning argus
In-Reply-To: 
References: <20090930135808.GA22554@hedwig.net.cmu.edu>
	<1254414259.4724.1.camel@localhost.localdomain>
	
Message-ID: <2572.84.242.106.93.1254643362.squirrel@www.brandforge.sk>

> Jan Klepek wrote:
>
>> On Wed, 2009-09-30 at 09:58 -0400, L. Gabriel Somlo wrote:
>>> Not using argus anymore, and no cycles to do right by it.
>>
>> I will take it.
>
> Please make sure you fix the broken dependency in F-12 (on an old version
> of
> libpcap) as soon as possible and get the fixed package tagged into the
> release (request tagging at https://fedorahosted.org/rel-eng/newticket ???
> explain it's to fix a broken dependency).
>
>         Kevin Kofler

Yes, seems that you done some patches, thank you.
However, I have in plans to update it to 3.0.2 version for F-12 as 2.0.6
is like 5 years old.

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From ilyes.gouta at gmail.com  Sun Oct  4 09:30:08 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sun, 4 Oct 2009 10:30:08 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora 11
Message-ID: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>

Hi,

The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.

Regards,
Ilyes Gouta.



From jreiser at bitwagon.com  Sun Oct  4 15:05:48 2009
From: jreiser at bitwagon.com (John Reiser)
Date: Sun, 04 Oct 2009 08:05:48 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
Message-ID: <4AC8B9CC.8050703@bitwagon.com>

> The title says it all. How about that? We really need it for old intel
> h/w such as an i855 for example.

Enumerate the reasons, please.  Which _specific_ bugs or features have been
improved elsewhere but not in F11?  Why are they important to you and others?

-- 



From ilyes.gouta at gmail.com  Sun Oct  4 16:36:49 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sun, 4 Oct 2009 17:36:49 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4AC8B9CC.8050703@bitwagon.com>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com> 
	<4AC8B9CC.8050703@bitwagon.com>
Message-ID: <234fa2210910040936kea85866h401e4a499d7fadb9@mail.gmail.com>

Hi John,

I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and
I still have the Xv video acceleration locking up the entire machine
as soon as I start a video playback. I dug a bit actually and I'm not
sure anymore if it's the kernel or the intel xorg driver which is
causing this issue (I'd say the former). I'm pretty sure about the
lockup though. I'm going to try gather more information and then may
be report a bug on bugzilla.redhat.com.

-Ilyes

On Sun, Oct 4, 2009 at 4:05 PM, John Reiser  wrote:
>> The title says it all. How about that? We really need it for old intel
>> h/w such as an i855 for example.
>
> Enumerate the reasons, please. ?Which _specific_ bugs or features have been
> improved elsewhere but not in F11? ?Why are they important to you and
> others?
>
> --
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From mschwendt at gmail.com  Sun Oct  4 17:14:00 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 4 Oct 2009 19:14:00 +0200
Subject: rpms/libgdiplus/devel .cvsignore, 1.24, 1.25 import.log, 1.14, 
 1.15 libgdiplus.spec, 1.46, 1.47 sources, 1.27, 1.28
In-Reply-To: <20091004152824.161E511C00E5@cvs1.fedora.phx.redhat.com>
References: <20091004152824.161E511C00E5@cvs1.fedora.phx.redhat.com>
Message-ID: <20091004191400.0796370d@faldor.intranet>

On Sun,  4 Oct 2009 15:28:24 +0000 (UTC), Paul wrote:

> Author: pfj
> 
> Update of /cvs/pkgs/rpms/libgdiplus/devel

> Log Message:
> 
> Bump to 2.6 preview 1 

> +libgdiplus-2_6-1_fc12:HEAD:libgdiplus-2.6-1.fc12.src.rpm:1254669963

You need to update your "common" checkout, because devel has become
".fc13" some time ago.
 
> -%check
> -make check
> -
> -

> -%doc COPYING NEWS README TODO AUTHORS
> +%doc COPYING NEWS README TODO MPL-1.1.html AUTHORS

>  %changelog
> -* Thu Sep  3 2009 Michel Salim  - 2.4.2-3
> -- Enable unit tests
> -- Corrected project and source URLs
> -- Remove obsolete license files
> +* Wed Sep 30 2009 Paul F. Johnson  2.6-1
> +- Update to 2.6 preview 1

(and other changes)

Overwriting cvs contents with cvs-import.sh is frowned upon.



From awilliam at redhat.com  Sun Oct  4 19:05:09 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sun, 04 Oct 2009 12:05:09 -0700
Subject: yum-presto not on by default
In-Reply-To: <20090924050519.GA27546@nostromo.devel.redhat.com>
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
Message-ID: <1254683109.2269.87.camel@adam.local.net>

On Wed, 2009-09-23 at 22:05 -0700, Bill Nottingham wrote:
> 
> So... just set the xz compression level to 2, let it be that way for
> future
> builds, and go about our business? 

Quick follow-up on this issue: I heard that this part at least has been
done, and it certainly seems to have done the trick. Delta rebuild
speeds have increased approx ten-fold here, and are now faster than my
(pretty quick) download speeds.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From erikina at gmail.com  Sun Oct  4 20:42:06 2009
From: erikina at gmail.com (Eric Springer)
Date: Mon, 5 Oct 2009 06:42:06 +1000
Subject: yum-presto not on by default
In-Reply-To: <1254683109.2269.87.camel@adam.local.net>
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc> 
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
Message-ID: 

On Mon, Oct 5, 2009 at 5:05 AM, Adam Williamson  wrote:
>
> Quick follow-up on this issue: I heard that this part at least has been
> done, and it certainly seems to have done the trick. Delta rebuild
> speeds have increased approx ten-fold here, and are now faster than my
> (pretty quick) download speeds.

Is it possible to do the rebuilds in parallel? I noticed that only one
of my four cores was used. And that on smolt 63% of people have a
dual-core or greater, so it could lead to massive speed-ups as well.

Although, personally I would be happy even if the rebuild was a tenth
the current speed -- as for me the priority is reducing the load on
the network link. Which brings me to the next point:

Would it be possible to have a diff on the filelist db? It seems like
a very large download for something that would change very little.



From drago01 at gmail.com  Sun Oct  4 20:45:43 2009
From: drago01 at gmail.com (drago01)
Date: Sun, 4 Oct 2009 22:45:43 +0200
Subject: yum-presto not on by default
In-Reply-To: 
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
	
Message-ID: 

On Sun, Oct 4, 2009 at 10:42 PM, Eric Springer  wrote:
> On Mon, Oct 5, 2009 at 5:05 AM, Adam Williamson  wrote:
>>
>> Quick follow-up on this issue: I heard that this part at least has been
>> done, and it certainly seems to have done the trick. Delta rebuild
>> speeds have increased approx ten-fold here, and are now faster than my
>> (pretty quick) download speeds.
>
> Is it possible to do the rebuilds in parallel? I noticed that only one
> of my four cores was used. And that on smolt 63% of people have a
> dual-core or greater, so it could lead to massive speed-ups as well.

xz is not threaded yet, I did some benchmark on my core i7 systems:

http://193.200.113.196/apache2-default/res

pbzip2 and pigz are threaded (compare them with bzip2 and gzip in the
output to see what kind of speedup is possible).



From jreiser at bitwagon.com  Sun Oct  4 20:51:53 2009
From: jreiser at bitwagon.com (John Reiser)
Date: Sun, 04 Oct 2009 13:51:53 -0700
Subject: yum-presto not on by default
In-Reply-To: 
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>	<1254683109.2269.87.camel@adam.local.net>
	
Message-ID: <4AC90AE9.1060703@bitwagon.com>

> Is it possible to do the rebuilds in parallel? I noticed that only one
> of my four cores was used. And that on smolt 63% of people have a
> dual-core or greater, so it could lead to massive speed-ups as well.

The speedup would be noticeably less than the number of cores.
xz uses a history+search table that is significantly larger than dcache.
There is competition for memory bandwidth, not just CPU+cache cycles.

> Would it be possible to have a diff on the filelist db? It seems like
> a very large download for something that would change very little.

Agreed, this would be a 99% savings.

-- 



From sundaram at fedoraproject.org  Sun Oct  4 21:07:39 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 05 Oct 2009 02:37:39 +0530
Subject: couchdb and odd dependencies
Message-ID: <4AC90E9B.6000507@fedoraproject.org>

Hi

Can someone with more insight into the updated directory ownership rules
look into

https://bugzilla.redhat.com/show_bug.cgi?id=527052

Couchdb also seems to be bundling a copy of mochiweb.

Rahul



From wtogami at redhat.com  Sun Oct  4 21:21:22 2009
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 04 Oct 2009 17:21:22 -0400
Subject: yum-presto not on by default
In-Reply-To: 
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>	<20090924050519.GA27546@nostromo.devel.redhat.com>	<1254683109.2269.87.camel@adam.local.net>	
	
Message-ID: <4AC911D2.8040500@redhat.com>

On 10/04/2009 04:45 PM, drago01 wrote:
> On Sun, Oct 4, 2009 at 10:42 PM, Eric Springer  wrote:
>> On Mon, Oct 5, 2009 at 5:05 AM, Adam Williamson  wrote:
>>>
>>> Quick follow-up on this issue: I heard that this part at least has been
>>> done, and it certainly seems to have done the trick. Delta rebuild
>>> speeds have increased approx ten-fold here, and are now faster than my
>>> (pretty quick) download speeds.
>>
>> Is it possible to do the rebuilds in parallel? I noticed that only one
>> of my four cores was used. And that on smolt 63% of people have a
>> dual-core or greater, so it could lead to massive speed-ups as well.
>
> xz is not threaded yet, I did some benchmark on my core i7 systems:
>

Although that isn't a problem if multiple packages are reconstructed 
simultaneously.

Warren



From cra at WPI.EDU  Sun Oct  4 21:35:52 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 4 Oct 2009 17:35:52 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
Message-ID: <20091004213552.GC28455@angus.ind.WPI.EDU>

Dracut currently tries to find and activate all RAID, LVM, and LUKS 
partitions on the hard disks when booting the LiveCD.

Several of my systems are made up of many RAID, LVM, and LUKS 
partitions in various combinations.  Booting the LiveCD now goes and 
activates these and asks for passphrases that I have to "skip over" by 
entering blank/bogus values to get the system to boot up.  I now know 
that you can pass various "rd_*" options such as "rd_NO_LUKS" to grub 
to have dracut skip these things, but I was hoping for something 
better, perhaps a "skip" button.

The new behavior makes the LiveCD less independent of and more "tied" 
to the existing installations on the hard disk.  This is surprising 
and unexpected.  Many uses of LiveCD's expect that the live 
environment will be completely independent of, and unaffected by, what 
is on the hard disk.  This is no longer true.  It may be confusing for 
users of LiveCD's when an (unidentified) passphrase input text box 
pops up when booting the LiveCD.

What do others think?  Should the LiveCD by default access and 
activate storage volumes, including encrypted partitions, on the hard 
disks?  Should the LUKS prompts better identify the volume so that 
users know what passphrase to enter?

I would prefer a LiveCD that doesn't do anything to the hard disk at 
all, at least by default when booting up.  It should be 
"self-contained".  Perhaps we should create another entry in 
syslinux.cfg that enables rd_NO_LUKS by default, and call it "Boot 
without accessing hard disk".



From warren at togami.com  Sun Oct  4 21:44:22 2009
From: warren at togami.com (Warren Togami)
Date: Sun, 04 Oct 2009 17:44:22 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091004213552.GC28455@angus.ind.WPI.EDU>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
Message-ID: <4AC91736.5010604@togami.com>

LiveCD boot has "liveimg" in cmdline.  We could automatically skip 
various parts of the bootup if parameter exists.  I suppose there are no 
drawbacks to this?

Warren Togami
wtogami at redhat.com



From drago01 at gmail.com  Sun Oct  4 21:48:48 2009
From: drago01 at gmail.com (drago01)
Date: Sun, 4 Oct 2009 23:48:48 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <4AC91736.5010604@togami.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<4AC91736.5010604@togami.com>
Message-ID: 

On Sun, Oct 4, 2009 at 11:44 PM, Warren Togami  wrote:
> LiveCD boot has "liveimg" in cmdline. ?We could automatically skip various
> parts of the bootup if parameter exists. ?I suppose there are no drawbacks
> to this?

Well it makes stuff easier if you are booting to fix up your existing
system, but this still shouldn't be the default behavior.



From bjorn at xn--rombobjrn-67a.se  Sun Oct  4 21:55:12 2009
From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=)
Date: Sun, 4 Oct 2009 23:55:12 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091004213552.GC28455@angus.ind.WPI.EDU>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
Message-ID: <200910042355.27024.bjorn@xn--rombobjrn-67a.se>

Chuck Anderson wrote:
> Should the LiveCD by default access and
> activate storage volumes, including encrypted partitions, on the hard
> disks?

There should be an easy and intuitive way to access the hard disks from the 
live system. Whether unencrypted volumes are mounted at boot or on demand 
doesn't matter much to me, as long as nothing is modified except on the user's 
request. Encrypted volumes should be unlocked only on demand. Failing that, a 
choice should be offered at boot.

> Should the LUKS prompts better identify the volume so that
> users know what passphrase to enter?

Absolutely! Asking for a passphrase and not specifying which passphrase is a 
very bad idea.

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: 

From mmcgrath at redhat.com  Sun Oct  4 22:33:53 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sun, 4 Oct 2009 17:33:53 -0500 (CDT)
Subject: "Fedora Insight" naming (was: Re: Trade review for two zikula
 packages)
In-Reply-To: 
References: <4AC765AA.2050104@gmail.com> 
Message-ID: 

On Sat, 3 Oct 2009, Kevin Kofler wrote:

> Toshio Kuratomi wrote:
> > Fedora Insight
>
> Hmmm, do we really have to conflict with RH's own software names?
> http://sources.redhat.com/insight/
>
> There are also several other pieces of software, companies etc. called
> "Insight". I think we need a more original name!
>

Fedora Insight isn't a software package, its the name of the website
(which is an online magazine type deal I believe)

	-Mike



From sundaram at fedoraproject.org  Sun Oct  4 22:33:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 05 Oct 2009 04:03:26 +0530
Subject: "Fedora Insight" naming
In-Reply-To: 
References: <4AC765AA.2050104@gmail.com> 
	
Message-ID: <4AC922B6.3040605@fedoraproject.org>

On 10/05/2009 04:03 AM, Mike McGrath wrote:
> On Sat, 3 Oct 2009, Kevin Kofler wrote:
> 
>> Toshio Kuratomi wrote:
>>> Fedora Insight
>>
>> Hmmm, do we really have to conflict with RH's own software names?
>> http://sources.redhat.com/insight/
>>
>> There are also several other pieces of software, companies etc. called
>> "Insight". I think we need a more original name!
>>
> 
> Fedora Insight isn't a software package, its the name of the website
> (which is an online magazine type deal I believe)

We are going to launch soon.

https://fedoraproject.org/wiki/Fedora_Insight

Rahul



From halfline at gmail.com  Sun Oct  4 22:44:47 2009
From: halfline at gmail.com (Ray Strode)
Date: Sun, 4 Oct 2009 18:44:47 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091004213552.GC28455@angus.ind.WPI.EDU>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
Message-ID: <45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>

Hi,

> What do others think? ?Should the LiveCD by default access and
> activate storage volumes, including encrypted partitions, on the hard
> disks? ?Should the LUKS prompts better identify the volume so that
> users know what passphrase to enter?
This seems like a misfeature in dracut for LiveCD or otherwise.

The initrd should be about getting / mounted read-only and nothing else.

There's a reason why plymouth doesn't identify the volume in the initrd.
Plymouth is graphical and so would need to ship fonts, font
renderering libraries,
and translations in the initrd to display text. That's a non-starter.

It's okay though, because in most cases the user should only ever get
asked for one passphrase from the initrd,
so we don't need to show anything but a lock icon and an entry box.

If that's no longer the case in a dracut world, we probably need to fix dracut.

The alternative would be to drop to the console when unlocking and
show untranslated messages.

--Ray



From MathStuf at gmail.com  Mon Oct  5 00:08:10 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Sun, 04 Oct 2009 20:08:10 -0400
Subject: yum-presto not on by default
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
	
	<4AC90AE9.1060703@bitwagon.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Reiser wrote:
>> Would it be possible to have a diff on the filelist db? It 
seems like
>> a very large download for something that would change very 
little.
> 
> Agreed, this would be a 99% savings.

Relatedly, I am amused every time the presto metadata is larger 
than the resultant package itself (usually 700k or less). Maybe 
there could/should be some heuristic for this?

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKyTjqAAoJEKaxavVX4C1X7SAQAJTHRkYs0/GIQBuCcR5AiTmr
UitxucY0VVVWHh7aw/4lWnfH0hhIsEEP95f9TbY3I0Vf6pL0N67xm0SO54/mbXxk
FeAyJFdDyyAZziOrdmjw93Y3lLs8n65j1MX5IrwOrhKAa1NOOORS/IXdVGkVWtrj
xIWB8MZ2NEr5rlBv1vzuBV33hzEq1pfG9BRKsCIpRUVzPbiq/ealoqXxPwg/XlF9
pLV7rwRU606LfTQsDUl11P01Zdu651hRPikfasUeJzJY8QcrZ0fLCkmDmZcUXpoa
UIWfa9yhnQ5QHwZTyQXtM36vOE5pG/90/NgZlzii+dC/ZQuX+O8hbEEbhs5tAs3I
qGKXfBUYI+EYuI30CdUiA5CIyHTyYPCRqKjVtZ31RY8fxgMO2Sa3W/67vRy93v8M
5boUOWZya4SxY2UoktARs/3tVP2N3QMHAqdWcLMtjsiuUPpQCUq0XFWr33QRvB03
nsYD6kkywqk1hp3CmMBEWy2RmkeuwXAQKuPpePvgxHq9lUoQ7+MQeP1EqLXukZqe
Q5SlUgrBsM6NLf71Anb1OktKfl3xxcqU5LJaTpYZ/VjqtTIHSUvmUrZO5OcWy+pH
m/Y9tg9e4WTrwrZYxKAo5v16mfIO8QzvazpvF4wSPXLHxTUjQoGw2XFJD/K827BU
4kamNtc34AWmoGskoOzk
=cpwh
-----END PGP SIGNATURE-----




From cra at WPI.EDU  Mon Oct  5 02:25:18 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 4 Oct 2009 22:25:18 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
Message-ID: <20091005022518.GA30359@angus.ind.WPI.EDU>

On Sun, Oct 04, 2009 at 06:44:47PM -0400, Ray Strode wrote:
> > What do others think? ?Should the LiveCD by default access and
> > activate storage volumes, including encrypted partitions, on the hard
> > disks? ?Should the LUKS prompts better identify the volume so that
> > users know what passphrase to enter?
> This seems like a misfeature in dracut for LiveCD or otherwise.
> 
> The initrd should be about getting / mounted read-only and nothing else.
> 
> There's a reason why plymouth doesn't identify the volume in the initrd.
> Plymouth is graphical and so would need to ship fonts, font
> renderering libraries,
> and translations in the initrd to display text. That's a non-starter.
> 
> It's okay though, because in most cases the user should only ever get
> asked for one passphrase from the initrd,
> so we don't need to show anything but a lock icon and an entry box.
> 
> If that's no longer the case in a dracut world, we probably need to fix dracut.

I agree that this is the best solution.  Fix dracut to only activate 
and mount /.  I found these bugs closed as NOTABUG:

https://bugzilla.redhat.com/show_bug.cgi?id=512620
https://bugzilla.redhat.com/show_bug.cgi?id=524366

and this is the one I had just opened:

https://bugzilla.redhat.com/show_bug.cgi?id=525877

so if this is "working as intended" is there any chance of changing 
the default behavior to work as expected above?



From MathStuf at gmail.com  Mon Oct  5 05:20:02 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Mon, 05 Oct 2009 01:20:02 -0400
Subject: TeXLive 2009 autoprovides/autorequires
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I upgraded to F12 recently and enabled the TeXLive 2009 
packages. One thing that the massive split has created is that 
package dependencies are not made at all. I had to manually 
install some packages to satisfy some dependencies. I created 
these (rudimentary) .prov and .req scripts (attached) to try and 
kickstart something.

As they are, they don't do versioning yet (seems that some 
packages do versioning with LaTeX commands) nor does it support 
\RequirePackage being split over multiple lines (similar with 
\ProvidesPackage). I also may not be handling all of the 
possibilities of where the provides and requires information may 
be in the files.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKyYICAAoJEKaxavVX4C1XnjgQAOuvMB9WMhtkzN7h+IjHcRu2
u4WFJRLVB4J/8zpPz/mxFbGIbeeJSjaUde+7oRuz2RV1jD9bC4P3sP4bRQN77Xrc
ffC1lOI1X6S3+AQt/nUonJnmG0/vqdeILWp/AulBNngpzb7w50Kj3iWGg+Zws5gy
tTDBCp9dZJNkXylqI6UNjduMghvI41p2md2l7cd1gzudmXvLWaZMDFBQ81OZJt1g
RE5JBi7+1OkNfINEjShKg+o/SlllZvT4u5erHWy7Fb/rOUGPX7qbj9ZqwZaQNWqU
Dpr/8TSrXmsiuKk7tr+jL+GAtdB+fx18ZDV4E3umvmqzG+0KzIj6WmuW/DEyotRs
qdqryzxSeZwtTjScBHAQG+TWlkm9X24hjnKnbyqIRvT81hawxPI/e6RAXTuuDUl8
R+53le3RG6/mMy7MDD6Aky1h37R+4uIpmNpIb7JaNHhtfRanROxUw1Ii1Fjh5d45
qA8i2pWaHPRC3OEMhaIgTFO1yHSWC5uLZ75K0owWKVQzo/UqFNAJwlGdIefM4YHD
mSGesiawXEMAK0Ggfy2YxcNYPfhErk6cy7vGS/TlQhouO6utJVkc/a4sjmZj7rlb
3EvpRn3M/YGqeWg9536I8L9ugVFDnEwq958DRznB0FKCVpycnph1zMofGviLkrVv
vjL/wtA8bfitn/xgR24o
=8Hkv
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: texlive.prov
Type: application/x-shellscript
Size: 334 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: texlive.req
Type: application/x-shellscript
Size: 514 bytes
Desc: not available
URL: 

From denis at poolshark.org  Mon Oct  5 07:12:51 2009
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 05 Oct 2009 09:12:51 +0200
Subject: clutter-cairomm is obsolete and should be retired
In-Reply-To: 
References: 
Message-ID: <4AC99C73.1080003@poolshark.org>

On 10/04/2009 04:02 AM, Kevin Kofler wrote:
> Hi,
>
> (I've already mailed this to the maintainer on October 1st, no answer so far.)

was gone for the week-end. all done.



From kevin.kofler at chello.at  Mon Oct  5 07:24:11 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 05 Oct 2009 09:24:11 +0200
Subject: clutter-cairomm is obsolete and should be retired
References:  <4AC99C73.1080003@poolshark.org>
Message-ID: 

Denis Leroy wrote:
> was gone for the week-end. all done.

Uh, no, sorry, but you didn't do the retiring correctly:
* clutter-cairomm should be marked dead.package in both F-12 and devel. It 
is not marked dead.package in either, instead you marked cluttermm/devel as 
dead.package, which I can only assume was a mistake.
* cluttermm should get an "Obsoletes: clutter-cairomm < some-version" for 
upgrade paths, just like clutter now obsoletes clutter-cairo. And once you 
added that, you'll also need to get cluttermm tagged into f12-beta (or if 
you miss the beta, into f12-final).

        Kevin Kofler



From jreznik at redhat.com  Mon Oct  5 07:37:06 2009
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Mon, 5 Oct 2009 09:37:06 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
Message-ID: <200910050937.06402.jreznik@redhat.com>

Hi Ray,
I have to disagree. And why? Becuase of my experience. Few days ago one 
colleague came to my cubicle and asked me - KDE wants something and I don't 
know what they want. So I took a look and saw Plymouth with something that 
looks like password dialog. He was really surprised that it's asking for 
password. At first - really, I think it's dracut bug as I think it was password 
for encrypted device he uses on demand (I can ask him). But you can imagine - 
he's very experienced user and still he failed.
I'm not sure how difficult would be implementing font support (kernel's fonts?) 
and a few lines of translation wouldn't be such a problem.

Jaroslav

On Monday 05 October 2009 00:44:47 Ray Strode wrote:
> Hi,
> 
> > What do others think?  Should the LiveCD by default access and
> > activate storage volumes, including encrypted partitions, on the hard
> > disks?  Should the LUKS prompts better identify the volume so that
> > users know what passphrase to enter?
> 
> This seems like a misfeature in dracut for LiveCD or otherwise.
> 
> The initrd should be about getting / mounted read-only and nothing else.
> 
> There's a reason why plymouth doesn't identify the volume in the initrd.
> Plymouth is graphical and so would need to ship fonts, font
> renderering libraries,
> and translations in the initrd to display text. That's a non-starter.
> 
> It's okay though, because in most cases the user should only ever get
> asked for one passphrase from the initrd,
> so we don't need to show anything but a lock icon and an entry box.
> 
> If that's no longer the case in a dracut world, we probably need to fix
>  dracut.
> 
> The alternative would be to drop to the console when unlocking and
> show untranslated messages.
> 
> --Ray
> 

-- 
Jaroslav ?ezn?k 
Associate Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.                               http://cz.redhat.com/



From kevin.kofler at chello.at  Mon Oct  5 07:39:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 05 Oct 2009 09:39:47 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
Message-ID: 

Ray Strode wrote:
> There's a reason why plymouth doesn't identify the volume in the initrd.
> Plymouth is graphical and so would need to ship fonts, font
> renderering libraries, and translations in the initrd to display text.
> That's a non-starter.

Could we prerender the text on initrd creation time using ImageMagick or 
whatever?

        Kevin Kofler



From denis at poolshark.org  Mon Oct  5 07:54:31 2009
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 05 Oct 2009 09:54:31 +0200
Subject: clutter-cairomm is obsolete and should be retired
In-Reply-To: 
References:  <4AC99C73.1080003@poolshark.org>
	
Message-ID: <4AC9A637.6000401@poolshark.org>

On 10/05/2009 09:24 AM, Kevin Kofler wrote:
> Denis Leroy wrote:
>> was gone for the week-end. all done.
>
> Uh, no, sorry, but you didn't do the retiring correctly:
> * clutter-cairomm should be marked dead.package in both F-12 and devel. It
> is not marked dead.package in either, instead you marked cluttermm/devel as
> dead.package, which I can only assume was a mistake.

Repaired.

> * cluttermm should get an "Obsoletes: clutter-cairomm<  some-version" for
> upgrade paths, just like clutter now obsoletes clutter-cairo. And once you
> added that, you'll also need to get cluttermm tagged into f12-beta (or if
> you miss the beta, into f12-final).

I'll leave that up to the next maintainer.



From denis at poolshark.org  Mon Oct  5 07:55:05 2009
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 05 Oct 2009 09:55:05 +0200
Subject: Orphaning cluttermm and clutter-gtkmm
Message-ID: <4AC9A659.8010708@poolshark.org>



From debarshi.ray at gmail.com  Mon Oct  5 08:05:15 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 5 Oct 2009 11:05:15 +0300
Subject: Orphaning cluttermm and clutter-gtkmm
In-Reply-To: <4AC9A659.8010708@poolshark.org>
References: <4AC9A659.8010708@poolshark.org>
Message-ID: <3170f42f0910050105w1f060f08kc86e8a447eae9d45@mail.gmail.com>

Are you orphaning them? In that case I am interested in cluttermm as
the libchamplainmm bindings that I am writing depend on it.

Cheers,
Debarshi
-- 
One reason that life is complex is that it has a real part and an
imaginary part.
    -- Andrew Koenig



From denis at poolshark.org  Mon Oct  5 08:18:58 2009
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 05 Oct 2009 10:18:58 +0200
Subject: Orphaning cluttermm and clutter-gtkmm
In-Reply-To: <3170f42f0910050105w1f060f08kc86e8a447eae9d45@mail.gmail.com>
References: <4AC9A659.8010708@poolshark.org>
	<3170f42f0910050105w1f060f08kc86e8a447eae9d45@mail.gmail.com>
Message-ID: <4AC9ABF2.3030901@poolshark.org>

On 10/05/2009 10:05 AM, Debarshi Ray wrote:
> Are you orphaning them? In that case I am interested in cluttermm as
> the libchamplainmm bindings that I am writing depend on it.

Yup, it's yours if you want it :-) If you take cluttermm, I would 
recommend that you also take clutter-gtkmm along with it, though.

-denis



From joshuacov at googlemail.com  Mon Oct  5 09:25:16 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 5 Oct 2009 11:25:16 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
Message-ID: <5f6f8c5f0910050225q6b2df0e9lbf7f6576f410cf70@mail.gmail.com>

2009/10/3 Joshua C. :
> I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
> read the instructions here
> http://www.x.org/wiki/Development/Documentation/ServerDebugging but
> this didin't help. My Xserver goes in an infinite loop and starts
> consuming 100% my cpu. Therefore the whole system freezes and I have
> to manually reboot it. This happens all the time when I use firefox on
> random sites. After restart there is nothing in the xorg.0.log and
> everything repeats itself when I start firefox again. Therefore I need
> to remove the savesession.js from the firefox home directory.
>
> On the second mashine I also turned this on: handle SIGUSR1 nostop,
> handle SIGUSR2 nostop, handle SIGPIPE nostop.
>
> The Xserver just keeps running and I get no messages on the second
> mashine. How to debug it?
>

Anyone? Any ideas?



From mnowak at redhat.com  Mon Oct  5 09:40:50 2009
From: mnowak at redhat.com (Michal Nowak)
Date: Mon, 5 Oct 2009 05:40:50 -0400 (EDT)
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1790204082.997361254735319891.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1587659798.997431254735650709.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Ilyes Gouta"  wrote:

> Hi John,
> 
> I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
> intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and

Well, having i855 here too, and frankly, xorg-x11-drv-intel+libdrm+kernel
combination at F-11 was really horrible one. Upgrading to Rawhide seems to 
fixed it. I don't see any crash/hang for a some time.

> I still have the Xv video acceleration locking up the entire machine
> as soon as I start a video playback.

Well, Xv's still now working at all when KMS is enabled (and when is
disabled the whole system hangs at start :).

But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901
you might wanna test it -- looked good.

> I dug a bit actually and I'm not
> sure anymore if it's the kernel or the intel xorg driver which is
> causing this issue (I'd say the former). 

Indeed. Perhaps you may try to rebuild Rawhide kernel for F-11 and
test it? (Not that I knew what happens when you do so.)

> I'm pretty sure about the
> lockup though. I'm going to try gather more information and then may
> be report a bug on bugzilla.redhat.com.
> 
> -Ilyes

Michal

> 
> On Sun, Oct 4, 2009 at 4:05 PM, John Reiser 
> wrote:
> >> The title says it all. How about that? We really need it for old
> intel
> >> h/w such as an i855 for example.
> >
> > Enumerate the reasons, please. ?Which _specific_ bugs or features
> have been
> > improved elsewhere but not in F11? ?Why are they important to you
> and
> > others?
> >
> > --
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From jdieter at gmail.com  Mon Oct  5 10:43:35 2009
From: jdieter at gmail.com (Jonathan Dieter)
Date: Mon, 05 Oct 2009 13:43:35 +0300
Subject: bodhi question
Message-ID: <1254739415.23326.696.camel@jdlaptop.lesbg.loc>

I've just built deltarpm-3.4-18.fc11 and pushed it to testing, because
during the security fix in 3.4-17 (which is still in testing), we
accidentally undid the split of drpmsync into a separate subpackage.

I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17.  Is there
some way to push that to 3.4-18?

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From halfline at gmail.com  Mon Oct  5 12:06:48 2009
From: halfline at gmail.com (Ray Strode)
Date: Mon, 5 Oct 2009 08:06:48 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <200910050937.06402.jreznik@redhat.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	<200910050937.06402.jreznik@redhat.com>
Message-ID: <45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>

Hi,

On Mon, Oct 5, 2009 at 3:37 AM, Jaroslav Reznik  wrote:
> So I took a look and saw Plymouth with something that
> looks like password dialog. He was really surprised that it's asking for
> password. At first - really, I think it's dracut bug as I think it was password
> for encrypted device he uses on demand (I can ask him). But you can imagine -
> he's very experienced user and still he failed.
Right, showing an unexpected password dialog at boot with no prompt is
a serious bug.  It's the bug in dracut I think we need to fix.

If he had asked for his root partition to be encrypted he would have
expected that's the password he needed to enter before his computer
booted, so there would have been no problem.

It's only when it's something the user doesn't expect, or when there
is the possibility of multiple questions that it's a problem.

--Ray



From jwboyer at gmail.com  Mon Oct  5 12:07:13 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 5 Oct 2009 08:07:13 -0400
Subject: bodhi question
In-Reply-To: <1254739415.23326.696.camel@jdlaptop.lesbg.loc>
References: <1254739415.23326.696.camel@jdlaptop.lesbg.loc>
Message-ID: <20091005120713.GA25493@hansolo.jdub.homelinux.org>

On Mon, Oct 05, 2009 at 01:43:35PM +0300, Jonathan Dieter wrote:
>I've just built deltarpm-3.4-18.fc11 and pushed it to testing, because
>during the security fix in 3.4-17 (which is still in testing), we
>accidentally undid the split of drpmsync into a separate subpackage.
>
>I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17.  Is there
>some way to push that to 3.4-18?

3.4-18 will get it's own update id when it is pushed.

josh



From fedora at camperquake.de  Mon Oct  5 12:11:15 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 5 Oct 2009 14:11:15 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	<200910050937.06402.jreznik@redhat.com>
	<45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>
Message-ID: <20091005141115.61df10b9@dhcp03.addix.net>

Hi.

On Mon, 5 Oct 2009 08:06:48 -0400, Ray Strode wrote:


> Right, showing an unexpected password dialog at boot with no prompt is
> a serious bug.  It's the bug in dracut I think we need to fix.

Just for my information, do I read this correctly that dracut/plymouth
is supposed to show a graphical password prompt to unlock encrypted
partitions at boot time?



From halfline at gmail.com  Mon Oct  5 12:17:25 2009
From: halfline at gmail.com (Ray Strode)
Date: Mon, 5 Oct 2009 08:17:25 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: 
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	
Message-ID: <45abe7d80910050517s60c5df0fs70a444244a141ba1@mail.gmail.com>

Hi,

On Mon, Oct 5, 2009 at 3:39 AM, Kevin Kofler  wrote:
> Ray Strode wrote:
>> There's a reason why plymouth doesn't identify the volume in the initrd.
>> Plymouth is graphical and so would need to ship fonts, font
>> renderering libraries, and translations in the initrd to display text.
>> That's a non-starter.
>
> Could we prerender the text on initrd creation time using ImageMagick or
> whatever?
That's a creative solution that we could potentially do, but it has a
few problems;

1) It won't scale nicely with everything else
2) Getting the interaction between plymouth and the initrd right would
be a little complicated.
We'd have to pass a list of strings that dracut uses back to plymouth,
plymouth would have to write out those images in a place it knows
about,
know to use them from the splash, and know to pack them in the initrd.

It's doable, but awkward, and something we haven't needed yet.

Note, plymouth *does* support text once / is mounted.  It dynamically
loads the fonts and font renderering libraries, etc, as soon as
they're
needed after they're availabe.  So you still get "/home is password
protected" or whatever when /home is unlocked at boot.

This is only about what's unlocked in the initrd, which should only be
one thing, since that's the initrd is only supposed to do one thing:
mount /.

--Ray



From halfline at gmail.com  Mon Oct  5 12:18:37 2009
From: halfline at gmail.com (Ray Strode)
Date: Mon, 5 Oct 2009 08:18:37 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091005141115.61df10b9@dhcp03.addix.net>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	<200910050937.06402.jreznik@redhat.com>
	<45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>
	<20091005141115.61df10b9@dhcp03.addix.net>
Message-ID: <45abe7d80910050518l319adef0q3af6728a898934b9@mail.gmail.com>

Hi,

>> Right, showing an unexpected password dialog at boot with no prompt is
>> a serious bug. ?It's the bug in dracut I think we need to fix.
>
> Just for my information, do I read this correctly that dracut/plymouth
> is supposed to show a graphical password prompt to unlock encrypted
> partitions at boot time?
Yes, if you have modesetting enabled and get a graphical splash otherwise.

--Ray



From jdieter at gmail.com  Mon Oct  5 12:28:37 2009
From: jdieter at gmail.com (Jonathan Dieter)
Date: Mon, 05 Oct 2009 15:28:37 +0300
Subject: bodhi question
In-Reply-To: <20091005120713.GA25493@hansolo.jdub.homelinux.org>
References: <1254739415.23326.696.camel@jdlaptop.lesbg.loc>
	<20091005120713.GA25493@hansolo.jdub.homelinux.org>
Message-ID: <1254745717.2590.0.camel@jdlaptop.lesbg.loc>

On Mon, 2009-10-05 at 08:07 -0400, Josh Boyer wrote:
> >I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17.  Is there
> >some way to push that to 3.4-18?
> 
> 3.4-18 will get it's own update id when it is pushed.

Ok, thanks.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From fedora at camperquake.de  Mon Oct  5 12:39:19 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 5 Oct 2009 14:39:19 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <45abe7d80910050518l319adef0q3af6728a898934b9@mail.gmail.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	<200910050937.06402.jreznik@redhat.com>
	<45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>
	<20091005141115.61df10b9@dhcp03.addix.net>
	<45abe7d80910050518l319adef0q3af6728a898934b9@mail.gmail.com>
Message-ID: <20091005143919.053e70ca@dhcp03.addix.net>

Hi.

On Mon, 5 Oct 2009 08:18:37 -0400, Ray Strode wrote:

> > Just for my information, do I read this correctly that
> > dracut/plymouth is supposed to show a graphical password prompt to
> > unlock encrypted partitions at boot time?
> Yes, if you have modesetting enabled and get a graphical splash
> otherwise.

I do, both. I also have an encrypted partition (not /, entered in /etc/crypttab),
and I do have graphical boot. When the point is reached to unlock the partition
plymouth switches back to the text console so I can enter the passphase (there
is no prompt, but just entering the passphase works)

Where do I have to kick to get the graphical dialog?



From rrakus at redhat.com  Mon Oct  5 13:46:52 2009
From: rrakus at redhat.com (Roman Rakus)
Date: Mon, 05 Oct 2009 15:46:52 +0200
Subject: PPC/PPC64 disabled in Koji for dist-f13
In-Reply-To: <20090929144803.GL5260@hansolo.jdub.homelinux.org>
References: <20090928162112.GH5260@hansolo.jdub.homelinux.org>	<9497e9990909281500j3b4da388wb2ed8eacffc1f9d7@mail.gmail.com>	<1254177085.2106.20.camel@localhost.localdomain>	<4AC21224.4010902@redhat.com>
	<20090929144803.GL5260@hansolo.jdub.homelinux.org>
Message-ID: <4AC9F8CC.8020509@redhat.com>

On 09/29/2009 04:48 PM, Josh Boyer wrote:
> On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote:
>    
>> On 09/29/2009 12:31 AM, Jesse Keating wrote:
>>      
>>> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote:
>>>
>>>        
>>>> What do we have to do in order to build on PPC? Does it happen
>>>> automagically?
>>>>
>>>>          
>>> Once the ppc builders are setup and running smoothly, successful build
>>> requests on the primary arches will be tried on the secondary arches,
>>> which will include ppc.  You'll need to do nothing specific on your end
>>> for this to happen.
>>>
>>>
>>>        
>> What about ppc specific packages (with exclusive arch set to ppc/ppc64)?
>>      
> What about them?  They can exist in the CVS repo.  You just won't be able to
> build them in koji for F-13 until a secondary arch instance is going.
>
> josh
>
>    
Any idea when I will be able to build them? Is there any bug report or 
something like it?
Thanks.
RR



From jlaska at redhat.com  Mon Oct  5 14:12:29 2009
From: jlaska at redhat.com (James Laska)
Date: Mon, 05 Oct 2009 10:12:29 -0400
Subject: 2009-10-01 - Anaconda Storage Rewrite Test Day report
Message-ID: <1254751949.7736.81.camel@localhost.localdomain>

Greetings folks,

Many thanks to all who participated in the anaconda test day hosted last
Thursday [1].  A decent range of storage scenarios were tested,
including various combinations of LVM, RAID and encryption, iSCSI, USB
and PowerPC.  We had a few new faces helping shake out bugs.  Special
thanks to Alexey Torkhov who wrestled through some live image issues and
gets the prize for most reported issues for the event.

526699 NEW  - CryptoError: luks_format failed for '/dev/mapper/VolGroup-LogVol00'
526782 NEW  - setroubleshoot:      SELinux is preventing /bin/loadkeys access to a leaked /dev/mapper/control file descriptor.
526789 NEW  - Install didn't reboot at the end
526899 NEW  - Encrypted partitions has "Unknown" type in table and ext4 in editor
526975 NEW  - AttributeError: 'LVMPhysicalVolume' object has no attribute 'mapName'
527091 NEW  - Installer causes a number of popups when creating filesystems
526906 NEW  - Switching encryption on and off creates more and more luks devices
525615 NEW  - system can not automatically reboot after exit installer -f12 beta TC
526822 ASSIGNED  - Installer didn't install boot loader if /boot is on mdraid1
526842 ASSIGNED  - Firstboot not run after installation
526778 CLOSED NOTABUG - Some installation screens has no text on live cd
526898 CLOSED NOTABUG - Doesn't allow to edit LVM PV to set encryption
502310 CLOSED RAWHIDE - Editing partitions without providing a passphrase for previously encrypted partitions fails - IndexError: list index out of range
523862 CLOSED RAWHIDE - mdadm craps at boot

Dmraid is an area still in need of additional focus.  If you have dmraid
capable hardware, I invite you to join the RAID test day, this Thursday
Oct 8 [2].

Thanks,
James

[1]
https://fedoraproject.org/wiki/Test_Day:2009-10-01_Anaconda/Features/StorageFiltering
[2] https://fedoraproject.org/wiki/Test_Day:2009-10-08
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jwboyer at gmail.com  Mon Oct  5 14:13:31 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 5 Oct 2009 10:13:31 -0400
Subject: PPC/PPC64 disabled in Koji for dist-f13
In-Reply-To: <4AC9F8CC.8020509@redhat.com>
References: <20090928162112.GH5260@hansolo.jdub.homelinux.org>
	<9497e9990909281500j3b4da388wb2ed8eacffc1f9d7@mail.gmail.com>
	<1254177085.2106.20.camel@localhost.localdomain>
	<4AC21224.4010902@redhat.com>
	<20090929144803.GL5260@hansolo.jdub.homelinux.org>
	<4AC9F8CC.8020509@redhat.com>
Message-ID: <20091005141331.GA3053@hansolo.jdub.homelinux.org>

On Mon, Oct 05, 2009 at 03:46:52PM +0200, Roman Rakus wrote:
> On 09/29/2009 04:48 PM, Josh Boyer wrote:
>> On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote:
>>    
>>> On 09/29/2009 12:31 AM, Jesse Keating wrote:
>>>      
>>>> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote:
>>>>
>>>>        
>>>>> What do we have to do in order to build on PPC? Does it happen
>>>>> automagically?
>>>>>
>>>>>          
>>>> Once the ppc builders are setup and running smoothly, successful build
>>>> requests on the primary arches will be tried on the secondary arches,
>>>> which will include ppc.  You'll need to do nothing specific on your end
>>>> for this to happen.
>>>>
>>>>
>>>>        
>>> What about ppc specific packages (with exclusive arch set to ppc/ppc64)?
>>>      
>> What about them?  They can exist in the CVS repo.  You just won't be able to
>> build them in koji for F-13 until a secondary arch instance is going.
>>
>> josh
>>
>>    
> Any idea when I will be able to build them? Is there any bug report or  

I can build the for you for now if you just point out which ones you want
built.  The setup I have isn't publicly accessible yet (details on fedora-ppc
list).

> something like it?

No, no bug report per se.

josh



From j.w.r.degoede at hhs.nl  Mon Oct  5 14:27:05 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 05 Oct 2009 16:27:05 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091004213552.GC28455@angus.ind.WPI.EDU>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
Message-ID: <4ACA0239.3010000@hhs.nl>

On 10/04/2009 11:35 PM, Chuck Anderson wrote:
> Dracut currently tries to find and activate all RAID, LVM, and LUKS
> partitions on the hard disks when booting the LiveCD.
>
> Several of my systems are made up of many RAID, LVM, and LUKS
> partitions in various combinations.  Booting the LiveCD now goes and
> activates these and asks for passphrases that I have to "skip over" by
> entering blank/bogus values to get the system to boot up.  I now know
> that you can pass various "rd_*" options such as "rd_NO_LUKS" to grub
> to have dracut skip these things, but I was hoping for something
> better, perhaps a "skip" button.
>
> The new behavior makes the LiveCD less independent of and more "tied"
> to the existing installations on the hard disk.  This is surprising
> and unexpected.  Many uses of LiveCD's expect that the live
> environment will be completely independent of, and unaffected by, what
> is on the hard disk.  This is no longer true.  It may be confusing for
> users of LiveCD's when an (unidentified) passphrase input text box
> pops up when booting the LiveCD.
>
> What do others think?  Should the LiveCD by default access and
> activate storage volumes, including encrypted partitions, on the hard
> disks?  Should the LUKS prompts better identify the volume so that
> users know what passphrase to enter?
>
> I would prefer a LiveCD that doesn't do anything to the hard disk at
> all, at least by default when booting up.  It should be
> "self-contained".  Perhaps we should create another entry in
> syslinux.cfg that enables rd_NO_LUKS by default, and call it "Boot
> without accessing hard disk".
>

Hi,

Thanks for bringing this up. I'll create a patch for the scripts
generating the livecd to add rd_NO_LUKS to the normal livecd
syslinux.cfg entry. I already was planning on doing this, but I forgot.

Regards,

Hans



From rrakus at redhat.com  Mon Oct  5 14:29:11 2009
From: rrakus at redhat.com (Roman Rakus)
Date: Mon, 05 Oct 2009 16:29:11 +0200
Subject: PPC/PPC64 disabled in Koji for dist-f13
In-Reply-To: <20091005141331.GA3053@hansolo.jdub.homelinux.org>
References: <20090928162112.GH5260@hansolo.jdub.homelinux.org>	<9497e9990909281500j3b4da388wb2ed8eacffc1f9d7@mail.gmail.com>	<1254177085.2106.20.camel@localhost.localdomain>	<4AC21224.4010902@redhat.com>	<20090929144803.GL5260@hansolo.jdub.homelinux.org>	<4AC9F8CC.8020509@redhat.com>
	<20091005141331.GA3053@hansolo.jdub.homelinux.org>
Message-ID: <4ACA02B7.1070209@redhat.com>

On 10/05/2009 04:13 PM, Josh Boyer wrote:
> On Mon, Oct 05, 2009 at 03:46:52PM +0200, Roman Rakus wrote:
>    
>> On 09/29/2009 04:48 PM, Josh Boyer wrote:
>>      
>>> On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote:
>>>
>>>        
>>>> On 09/29/2009 12:31 AM, Jesse Keating wrote:
>>>>
>>>>          
>>>>> On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> What do we have to do in order to build on PPC? Does it happen
>>>>>> automagically?
>>>>>>
>>>>>>
>>>>>>              
>>>>> Once the ppc builders are setup and running smoothly, successful build
>>>>> requests on the primary arches will be tried on the secondary arches,
>>>>> which will include ppc.  You'll need to do nothing specific on your end
>>>>> for this to happen.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> What about ppc specific packages (with exclusive arch set to ppc/ppc64)?
>>>>
>>>>          
>>> What about them?  They can exist in the CVS repo.  You just won't be able to
>>> build them in koji for F-13 until a secondary arch instance is going.
>>>
>>> josh
>>>
>>>
>>>        
>> Any idea when I will be able to build them? Is there any bug report or
>>      
> I can build the for you for now if you just point out which ones you want
> built.  The setup I have isn't publicly accessible yet (details on fedora-ppc
> list).
>
>    
>> something like it?
>>      
> No, no bug report per se.
>
> josh
>
>    
Many thanks. Let's move this discussion to fedora-ppc-list.
RR



From ajax at redhat.com  Mon Oct  5 15:20:30 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 05 Oct 2009 11:20:30 -0400
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
Message-ID: <1254756030.11711.0.camel@atropine.boston.devel.redhat.com>

On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
> I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
> read the instructions here
> http://www.x.org/wiki/Development/Documentation/ServerDebugging but
> this didin't help. My Xserver goes in an infinite loop and starts
> consuming 100% my cpu. Therefore the whole system freezes and I have
> to manually reboot it. This happens all the time when I use firefox on
> random sites. After restart there is nothing in the xorg.0.log and
> everything repeats itself when I start firefox again. Therefore I need
> to remove the savesession.js from the firefox home directory.
>
> On the second mashine I also turned this on: handle SIGUSR1 nostop,
> handle SIGUSR2 nostop, handle SIGPIPE nostop.
> 
> The Xserver just keeps running and I get no messages on the second
> mashine. How to debug it?

I wouldn't expect you to get messages on the second machine.  If you're
using 100% of the CPU it's because you're busy doing something _other_
than printing to the log.

What does 'bt' in gdb show?

- ajax


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From joshuacov at googlemail.com  Mon Oct  5 15:39:01 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 5 Oct 2009 17:39:01 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
Message-ID: <5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>

2009/10/5 Adam Jackson :
> On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
>> I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
>> read the instructions here
>> http://www.x.org/wiki/Development/Documentation/ServerDebugging but
>> this didin't help. My Xserver goes in an infinite loop and starts
>> consuming 100% my cpu. Therefore the whole system freezes and I have
>> to manually reboot it. This happens all the time when I use firefox on
>> random sites. After restart there is nothing in the xorg.0.log and
>> everything repeats itself when I start firefox again. Therefore I need
>> to remove the savesession.js from the firefox home directory.
>>
>> On the second mashine I also turned this on: handle SIGUSR1 nostop,
>> handle SIGUSR2 nostop, handle SIGPIPE nostop.
>>
>> The Xserver just keeps running and I get no messages on the second
>> mashine. How to debug it?
>
> I wouldn't expect you to get messages on the second machine. ?If you're
> using 100% of the CPU it's because you're busy doing something _other_
> than printing to the log.
>
> What does 'bt' in gdb show?
>
> - ajax
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

When should I issue this command? After attaching gdb and sending the
handle options I type in cont and the server keeps going until it
freezes the mashine. No other messages are reported.


PS: I thought this isn't the right place for this question and
reposted it on the xorg-devel at lists.x.org.



From cdahlin at redhat.com  Mon Oct  5 15:51:36 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 05 Oct 2009 11:51:36 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <45abe7d80910050517s60c5df0fs70a444244a141ba1@mail.gmail.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>	
	<45abe7d80910050517s60c5df0fs70a444244a141ba1@mail.gmail.com>
Message-ID: <4ACA1608.7020901@redhat.com>

On 10/05/2009 08:17 AM, Ray Strode wrote:
> Note, plymouth *does* support text once / is mounted.  It dynamically
> loads the fonts and font renderering libraries, etc, as soon as
> they're
> needed after they're availabe.  So you still get "/home is password
> protected" or whatever when /home is unlocked at boot.
> 
> This is only about what's unlocked in the initrd, which should only be
> one thing, since that's the initrd is only supposed to do one thing:
> mount /.
> 
> --Ray
> 

What if / is encrypted, and /usr is a different volume encrypted with a different password? We can't leave initrd yet because everything in / that we actually _need_ isn't available.

Sysadmins on crack break everything...

--CJD



From ajax at redhat.com  Mon Oct  5 16:06:53 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 05 Oct 2009 12:06:53 -0400
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
Message-ID: <1254758813.11711.18.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-10-05 at 17:39 +0200, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
> > On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote:
> >> The Xserver just keeps running and I get no messages on the second
> >> mashine. How to debug it?
> >
> > I wouldn't expect you to get messages on the second machine.  If you're
> > using 100% of the CPU it's because you're busy doing something _other_
> > than printing to the log.
> >
> > What does 'bt' in gdb show?
> 
> When should I issue this command? After attaching gdb and sending the
> handle options I type in cont and the server keeps going until it
> freezes the mashine. No other messages are reported.

Before typing in cont, of course.  "cont" continues execution from where
you're currently stopped.  "bt" shows a backtrace of where you're
currently stopped.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From walters at verbum.org  Mon Oct  5 16:18:06 2009
From: walters at verbum.org (Colin Walters)
Date: Mon, 5 Oct 2009 16:18:06 +0000
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
Message-ID: 

On Mon, Oct 5, 2009 at 4:06 PM, Adam Jackson  wrote:

>
> Before typing in cont, of course.  "cont" continues execution from where
> you're currently stopped.  "bt" shows a backtrace of where you're
> currently stopped.
>

If you're not planning to actively debug and just want a stack, i'd
use: gstack $(pidof Xorg)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From joshuacov at googlemail.com  Mon Oct  5 17:19:42 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 5 Oct 2009 19:19:42 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: 
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
Message-ID: <5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>

2009/10/5 Colin Walters :
> On Mon, Oct 5, 2009 at 4:06 PM, Adam Jackson  wrote:
>>
>> Before typing in cont, of course. ?"cont" continues execution from where
>> you're currently stopped. ?"bt" shows a backtrace of where you're
>> currently stopped.
>
> If you're not planning to actively debug and just want a stack, i'd
> use:?gstack $(pidof Xorg)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

(gdb) bt
#0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
#1  0x00000000004e615a in WaitForSomething (
    pClientsReady=) at WaitFor.c:228
#2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
#3  0x000000000042d205 in main (argc=,
    argv=0x7fffa2ac9218, envp=) at main.c:397

[root at localhost ~]# gstack $(pidof X)
#0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
#1  0x00000000004e615a in WaitForSomething ()
#2  0x0000000000446ef2 in Dispatch ()
#3  0x000000000042d205 in main ()



From fedora at shmuelhome.mine.nu  Mon Oct  5 17:32:38 2009
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Mon, 05 Oct 2009 19:32:38 +0200
Subject: yum-presto not on by default
In-Reply-To: 
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>	<1254683109.2269.87.camel@adam.local.net>
	
Message-ID: <4ACA2DB6.2030505@shmuelhome.mine.nu>

Eric Springer wrote:
> Would it be possible to have a diff on the filelist db? It seems like
> a very large download for something that would change very little.
>
>   
Also the rawhide db itself. A guaranteed 8-12 megabyte download usually 
swamps out any saving from presto (barring changes to eclipse, kernel 
and openoffice).




From email.ahmedkamal at googlemail.com  Mon Oct  5 18:32:35 2009
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Mon, 5 Oct 2009 20:32:35 +0200
Subject: yum-presto not on by default
In-Reply-To: <4ACA2DB6.2030505@shmuelhome.mine.nu>
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
	
	<4ACA2DB6.2030505@shmuelhome.mine.nu>
Message-ID: <3da3b5b40910051132q17382173t27c6752f89c8b49@mail.gmail.com>

>
> Also the rawhide db itself. A guaranteed 8-12 megabyte download usually
> swamps out any saving from presto (barring changes to eclipse, kernel and
> openoffice).
>
>
Why aren't we rsync'ing that 12MB db, instead of re-downloading ? Wasn't
there some web friendly rsync fork
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rawhide at fedoraproject.org  Mon Oct  5 18:37:15 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 5 Oct 2009 18:37:15 +0000
Subject: rawhide report: 20091005 changes
Message-ID: <20091005183715.GA30574@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct  5 06:15:11 UTC 2009

Broken deps for i386
----------------------------------------------------------
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)



Broken deps for x86_64
----------------------------------------------------------
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8)



Broken deps for ppc
----------------------------------------------------------
	clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2
	clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8)



Broken deps for ppc64
----------------------------------------------------------
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit)
	clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8)
	clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8)
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package yum-rhn-plugin
        RHN support for yum
Removed package PolicyKit-olpc
Updated Packages:

akonadi-1.2.1-1.fc12
--------------------
* Tue Sep 01 2009 Luk?? Tinkl  - 1.2.1-1
- Akonadi 1.2.1


amarok-2.2.0-2.fc12
-------------------
* Fri Oct 02 2009 Rex Dieter  2.2.0-2
- Requires: kdebase-runtime (support for trash protocol needed)


argus-2.0.6.fixes.1-19.fc12
---------------------------
* Sun Oct 04 2009 Kevin Kofler  - 2.0.6.fixes.1-19
- Fix build with libpcap 1.0 (rename conflicting bpf_dump symbol, remove
  conflicting redeclaration of bpf_image)

* Wed Sep 30 2009 Gabriel Somlo  - 2.0.6.fixes.1-18
- Rebuilt for libpcap.1.0

* Fri Jul 24 2009 Fedora Release Engineering  - 2.0.6.fixes.1-17
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


brasero-2.28.0-2.fc12
---------------------
* Fri Oct 02 2009 Matthias Clasen  - 2.28.0-2
- Fix ejecting after burning


control-center-2.28.0-13.fc12
-----------------------------
* Fri Oct 02 2009 Matthias Clasen  2.28.0-13
- Don't show markup in the UI


empathy-2.28.0.1-1.fc12
-----------------------
* Fri Oct 02 2009 Brian Pepple  - 2.28.0.1-1
- Update to 2.28.0.1.
- See http://download.gnome.org/sources/empathy/2.28/empathy-2.28.0.1.news


file-roller-2.28.0-2.fc12
-------------------------
* Thu Oct 01 2009 Matthias Clasen  2.28.0-2
- Respect button-images setting


fonttools-2.2-7.fc12
--------------------
* Fri Oct 02 2009 Caol?n McNamara  - 2.2-7
* Resolves: rhbz#525444 as is a reserved keyword in python


gcolor2-0.4-3.fc12
------------------
* Sat Oct 03 2009 Christoph Wickert  - 0.4-3
- Fix missing includes (#525783)


gvfs-1.4.0-3.fc12
-----------------
* Thu Oct 01 2009 Matthias Clasen  - 1.4.0-3
- Consider logical partitions when deciding if a drive should be ignored


happy-1.18.4-4.fc12
-------------------
* Thu Oct 01 2009 Jens Petersen  - 1.18.4-4
- selinux fcontext no longer needed in post script


initscripts-9.00-1
------------------
* Fri Oct 02 2009 Bill Nottingham  - 9.00-1
- halt: wrap /sbin/killall5 to catch some return codes (#526539)
- netfs, netconsle, network: fix return codes to match LSB spec (#524489, #524480, #524486)
- handle kernels compiled both with and without CONFIG_RTC_HCTOSYS
- halt: use killall5's return code to avoid unncesssary sleeping (#524359, )
- halt: don't kill mdmon on shutdown. (#524357, )
- rc.sysinit: do not try and activate ISW raidsets, unless noiswmd is passed. (#524355, )
- translation updates: ca, cs, da, mai, po, sv, uk


itext-2.1.7-6.fc12
------------------
* Sat Oct 03 2009 Orcan Ogetbil  2.1.7-6
- Bump release

* Thu Oct 01 2009 Orcan Ogetbil  2.1.7-5
- Separate rtf, rups and toolbox packages
- Reduce dependencies of the main package (RHBZ#524066)


kdeplasma-addons-4.3.1-3.fc12
-----------------------------
* Sat Oct 03 2009 Kevin Kofler  - 4.3.1-3
- Ship -devel subpackage (#527011)

* Wed Sep 30 2009 Rex Dieter  - 4.3.1-2
- Microblogging Widget Does Not Fetch Tweets (#526524)


konversation-1.2-0.12.rc1.fc12
------------------------------
* Sat Oct 03 2009 Rex Dieter  - 1.2-0.12.rc1
- konversation-1.2-rc1


labrea-2.5.1-5.fc12
-------------------
* Sun Oct 04 2009 Kevin Kofler  - 2.5.1-5
- Fix build with GCC 4.4 (#511524)

* Fri Jul 24 2009 Fedora Release Engineering  - 2.5.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Wed Feb 25 2009 Fedora Release Engineering  - 2.5.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild


libuser-0.56.12-1.fc12
----------------------
* Fri Oct 02 2009 Miloslav Trma?  - 0.56.12-1
- Update to libuser-0.56.12.


libvirt-qpid-0.2.17-1.fc12
--------------------------
* Fri Oct 02 2009 Kevin Kofler  - 0.2.17-1
- Rebuild for new qpidc.


matahari-0.0.4-6.fc12
---------------------
* Fri Oct 02 2009 Kevin Kofler  - 0.0.4-6
- Rebuild for new qpidc.


mingw32-cppunit-1.12.1-3.fc12
-----------------------------
* Sun Oct 04 2009 Kevin Kofler  - 1.12.1-3
- Rebuild for MinGW debuginfo breakage


moblin-panel-status-0.0.7-1.fc12
--------------------------------
* Fri Oct 02 2009 Peter Robinson  0.0.7-1
- New upstream 0.0.7 release


nfs-utils-1.2.0-16.fc12
-----------------------
* Fri Oct 02 2009 Steve Dickson  1.2.0-16
- Fixed a whole where '-o v4' was not overriding the
  version in the conf file.


phonon-4.3.1-102.fc12
---------------------
* Sat Oct 03 2009 Rex Dieter  - 4.3.1-102
- Requires: qt4 >= 4.5.2-21

* Tue Sep 29 2009 Rex Dieter  - 4.3.1-101
- revert to kde/phonon
- inflate to Release: 101
- -backend-gstreamer: Epoch: 2


qemu-0.11.0-3.fc12
------------------
* Thu Oct 01 2009 Justin M. Forbes  - 2:0.11.0-3
- Improve error reporting on file access (#524695)


qt-4.5.2-22.fc12
----------------
* Sat Oct 03 2009 Rex Dieter  - 4.5.2-22
- if ! phonon_internal, exclude more/all phonon headers
- qt-devel must Requires: phonon-devel (#520323)

* Tue Sep 29 2009 Rex Dieter  - 4.5.2-21
- switch to external/kde phonon


rygel-0.4.2-1.fc12
------------------
* Fri Oct 02 2009 Peter Robinson  0.4.2-1
- Update to 0.4.2


xscope-1.2-1.fc12
-----------------
* Thu Oct 01 2009 Yanko Kaneti  1.2-1
- New upstream release. Drop patches.


yersinia-0.7.1-6.fc12
---------------------
* Sun Oct 04 2009 Kevin Kofler  - 0.7.1-6
- Add --with-pcap-includes to fix build with libpcap 1.0

* Thu Sep 24 2009 Fabian Affolter  - 0.7.1-5
- Rebuild for new libpcap

* Mon Jul 27 2009 Fedora Release Engineering  - 0.7.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


Summary:
Added Packages: 1
Removed Packages: 1
Modified Packages: 28



From notting at redhat.com  Mon Oct  5 18:37:34 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 5 Oct 2009 14:37:34 -0400
Subject: yum-presto not on by default
In-Reply-To: <3da3b5b40910051132q17382173t27c6752f89c8b49@mail.gmail.com>
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
	
	<4ACA2DB6.2030505@shmuelhome.mine.nu>
	<3da3b5b40910051132q17382173t27c6752f89c8b49@mail.gmail.com>
Message-ID: <20091005183734.GA10116@nostromo.devel.redhat.com>

Ahmed Kamal (email.ahmedkamal at googlemail.com) said: 
> > Also the rawhide db itself. A guaranteed 8-12 megabyte download usually
> > swamps out any saving from presto (barring changes to eclipse, kernel and
> > openoffice).
>
> Why aren't we rsync'ing that 12MB db, instead of re-downloading ? Wasn't
> there some web friendly rsync fork

rsync over http/ftp? We don't really have that.

Bill



From jkeating at redhat.com  Mon Oct  5 19:20:22 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 05 Oct 2009 12:20:22 -0700
Subject: Fedora Release Engineering meeting summary for 2009-10-05
Message-ID: <1254770422.2511.14.camel@localhost.localdomain>

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-05/fedora-meeting.2009-10-05-18.02.html

Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-05/fedora-meeting.2009-10-05-18.02.txt

Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-05/fedora-meeting.2009-10-05-18.02.log.html


Meeting started by Oxf13 at 18:02:25 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-05/fedora-meeting.2009-10-05-18.02.log.html
.



Meeting summary
---------------
* roll call  (Oxf13, 18:02:31)
  * LINK:

http://test1185.test.redhat.com/results/633-autotest/brutus.test.redhat.com/rats_sanity/results/critpath.log
    (Oxf13, 18:09:11)
  * AGREED: No-go for Fedora 12 Beta.  Slip 1 week (and all future dates
    by 1 week)  (Oxf13, 18:20:16)
  * ACTION: poelcat to update schedules and send out slip announcement.
    (Oxf13, 18:21:27)
  * IDEA: Slip Beta by 1 week, postpone the rest of the schedule
    discussion until more information is received regarding data center
    moves  (Oxf13, 18:49:36)
  * AGREED: Meeting for deciding what to do with the rest of the F12
    schedule set for this Thursday at 1800 UTC  (Oxf13, 19:16:58)

Meeting ended at 19:19:16 UTC.




Action Items
------------
* poelcat to update schedules and send out slip announcement.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From james at fedoraproject.org  Mon Oct  5 19:35:26 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 05 Oct 2009 15:35:26 -0400
Subject: yum-presto not on by default
In-Reply-To: <3da3b5b40910051132q17382173t27c6752f89c8b49@mail.gmail.com>
References: <1253678663.24144.115.camel@jdlaptop.lesbg.loc>
	<20090924050519.GA27546@nostromo.devel.redhat.com>
	<1254683109.2269.87.camel@adam.local.net>
	
	<4ACA2DB6.2030505@shmuelhome.mine.nu>
	<3da3b5b40910051132q17382173t27c6752f89c8b49@mail.gmail.com>
Message-ID: <1254771326.29348.27.camel@code.and.org>

On Mon, 2009-10-05 at 20:32 +0200, Ahmed Kamal wrote:
>         Also the rawhide db itself. A guaranteed 8-12 megabyte
>         download usually swamps out any saving from presto (barring
>         changes to eclipse, kernel and openoffice).
>
> 
> Why aren't we rsync'ing that 12MB db, instead of re-downloading ?
> Wasn't there some web friendly rsync fork

 zsync, see the recent thread for why it isn't in Fedora.

 And I doubt they'd be much savings, even if it worked (and you'd have
to be clever due to the names changing). Adding delta MD support would
be "easier", and by easier I mean significant amounts of code and
significant problems on the f-i side.

-- 
James Antill 
Fedora



From ajax at redhat.com  Mon Oct  5 19:50:54 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 05 Oct 2009 15:50:54 -0400
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
Message-ID: <1254772254.11711.126.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:

> (gdb) bt
> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
> #1  0x00000000004e615a in WaitForSomething (
>     pClientsReady=) at WaitFor.c:228
> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
> #3  0x000000000042d205 in main (argc=,
>     argv=0x7fffa2ac9218, envp=) at main.c:397

Okay, this isn't the server actually taking 100% of the CPU (almost
certainly), it's before that.  If you type 'cont' to resume, and then ^C
the gdb process once the CPU goes wild, you should break back to the gdb
prompt; _that_'s the backtrace I need.

Of course, you might not, in which case debugging this gets a bit
harder.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From joshuacov at googlemail.com  Mon Oct  5 21:05:54 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 5 Oct 2009 23:05:54 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
Message-ID: <5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>

2009/10/5 Adam Jackson :
> On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>
>> (gdb) bt
>> #0 ?0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>> #1 ?0x00000000004e615a in WaitForSomething (
>> ? ? pClientsReady=) at WaitFor.c:228
>> #2 ?0x0000000000446ef2 in Dispatch () at dispatch.c:386
>> #3 ?0x000000000042d205 in main (argc=,
>> ? ? argv=0x7fffa2ac9218, envp=) at main.c:397
>
> Okay, this isn't the server actually taking 100% of the CPU (almost
> certainly), it's before that. ?If you type 'cont' to resume, and then ^C
> the gdb process once the CPU goes wild, you should break back to the gdb
> prompt; _that_'s the backtrace I need.
>
> Of course, you might not, in which case debugging this gets a bit
> harder.
>
> - ajax
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

(gdb) handle SIGUSR1 nostop
Signal        Stop      Print   Pass to program Description
SIGUSR1       No        Yes     Yes             User defined signal 1
(gdb) handle SIGUSR2 nostop
Signal        Stop      Print   Pass to program Description
SIGUSR2       No        Yes     Yes             User defined signal 2
(gdb) handle SIGPIPE nostop
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        Yes     Yes             Broken pipe
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
#1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
arg=0x7fff78cabbc0) at xf86drm.c:187
#2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
drmCommandIndex=, data=0x7fff78cabbc0,
size=)
    at xf86drm.c:2363
#3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=) at radeon_bufmgr_gem.c:282
#4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
index=0) at radeon_exa.c:279
#5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
index=0) at exa.c:523
#6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
index=0, pReg=0x0) at exa.c:543
#7  0x00007f6c69beceac in ExaCheckComposite (op=,
pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=,
    ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
width=55, height=18) at exa_unaccel.c:342
#8  0x00007f6c69beb564 in exaComposite (op=,
pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=,
    ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
width=55, height=18) at exa_render.c:967
#9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc=, pMask=, pDst=0x27a04b0, xSrc=1,
ySrc=0,
    xMask=, yMask=, xDst=19,
yDst=85, width=55, height=) at damage.c:643
#10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
#11 0x00000000004471d4 in Dispatch () at dispatch.c:456
#12 0x000000000042d205 in main (argc=,
argv=0x7fff78cac198, envp=) at main.c:397



From ian at ianweller.org  Mon Oct  5 21:52:42 2009
From: ian at ianweller.org (Ian Weller)
Date: Mon, 5 Oct 2009 16:52:42 -0500
Subject: Docs preparing to convert to Creative Commons BY-SA 3.0 Unported
	license
Message-ID: <20091005215242.GA10890@deathray.l.ianweller.org>

Today, the Docs team finalized the conversion of the licensing of our
documentation and project content from the Open Publication License
(OPL) to a Creative Commons Attribution-Share Alike 3.0 Unported License
(CC-BY-SA). Docs originally reached a consensus to change the license in
June 2009, and after answering questions raised by the community, the
Docs team decided to go ahead with the transition.

While OPL is a free and open documentation license, moving to a more
widely known and adopted license and the one used by the likes of
Wikipedia and GNOME Project helps us share our content more easily with
the rest of the Free software community.

Additional information can be found at:
  https://fedoraproject.org/wiki/Relicensing_OPL_to_CC_BY_SA

We'd like to thank Tom 'spot' Callaway, Fedora's legal ninja, and
Richard Fontana of Red Hat Legal for their help with the conversion. We
look forward to continue working with the community and share our
documentation freely.

-- 
Ian Weller 
  "Why, a four-year-old could understand this report.
   Find me a four-year-old child.
   I can't make head or tail out of it." -- Groucho Marx, "Duck Soup"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From peter at thecodergeek.com  Fri Oct  2 03:23:28 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 01 Oct 2009 20:23:28 -0700
Subject: Heads-up: rb_libtorrent bump (Rawhide), rebuilds required
Message-ID: <1254453808.9471.39.camel@localhost>

Hi, all.

I just pushed an update to rb_libtorrent 0.14.16 in rawhide (F13+),
which bumps the library soname from "libtorrent-rasterbar.so.3" to
"libtorrent-rasterbar.so.5".

Because of this change, applications which use this library will need to
be rebuilt. According to repoquery, these are qbittorrent and
springlobby (maintainers CC-ed). I've successfully rebuilt these two
packages locally (from their CVS devel/ branches) with this update
earlier today and did not see any problems, so I don't expect any issues
in updating.

Packages such as Deluge and Miro which use rb_libtorrent through its
Python bindings remain unaffected by this change.

Please let me know if there are any related problems or questions as
they arise.

Thanks.
-- 
Peter Gordon (codergeek42) 
Who am I? :: http://thecodergeek.com/about-me
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From halfline at gmail.com  Mon Oct  5 23:00:43 2009
From: halfline at gmail.com (Ray Strode)
Date: Mon, 5 Oct 2009 19:00:43 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <4ACA1608.7020901@redhat.com>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	
	<45abe7d80910050517s60c5df0fs70a444244a141ba1@mail.gmail.com>
	<4ACA1608.7020901@redhat.com>
Message-ID: <45abe7d80910051600y36618d2fx3f56d84157938ef4@mail.gmail.com>

Hi,
> What if / is encrypted, and /usr is a different volume encrypted with a different password? We can't leave initrd yet because everything in / that we actually _need_ isn't available.
>
> Sysadmins on crack break everything...

True, if you

1) have encrypted /
2) have a separate /usr
3) have that /usr encrypted with a *different* password than /
4) are using a graphical splash instead of the verbose details one

Then you have to know to enter your /usr password after your /
password, because we don't have anyway to tell you.

--Ray



From halfline at gmail.com  Mon Oct  5 23:04:41 2009
From: halfline at gmail.com (Ray Strode)
Date: Mon, 5 Oct 2009 19:04:41 -0400
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <20091005143919.053e70ca@dhcp03.addix.net>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<45abe7d80910041544s4d5183d2k8645414eb0660002@mail.gmail.com>
	<200910050937.06402.jreznik@redhat.com>
	<45abe7d80910050506i2aa95453u6532c917d0ffb11a@mail.gmail.com>
	<20091005141115.61df10b9@dhcp03.addix.net>
	<45abe7d80910050518l319adef0q3af6728a898934b9@mail.gmail.com>
	<20091005143919.053e70ca@dhcp03.addix.net>
Message-ID: <45abe7d80910051604o35071ee5u41ba8a4e9d6a38d@mail.gmail.com>

Hi,

> On Mon, 5 Oct 2009 08:18:37 -0400, Ray Strode wrote:
>
>> > Just for my information, do I read this correctly that
>> > dracut/plymouth is supposed to show a graphical password prompt to
>> > unlock encrypted partitions at boot time?
>> Yes, if you have modesetting enabled and get a graphical splash
>> otherwise.
>
> I do, both. I also have an encrypted partition (not /, entered in /etc/crypttab),
> and I do have graphical boot. When the point is reached to unlock the partition
> plymouth switches back to the text console so I can enter the passphase (there
> is no prompt, but just entering the passphase works)
>
> Where do I have to kick to get the graphical dialog?
You shouldn't have to kick anything. Sounds like a bug, can you file it?

--Ray



From poelstra at redhat.com  Tue Oct  6 03:50:00 2009
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 05 Oct 2009 20:50:00 -0700
Subject: Fedora 12 Beta Release Rescheduled to 2009-10-20
Message-ID: <4ACABE68.8090005@redhat.com>

https://fedoraproject.org/wiki/Releases/12/Schedule

At the Release Engineering meeting today
https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00244.html
it was noted that we still do not have a beta RC composed because a few 
blocker bugs remain.

The decision was made to move the Fedora 12 Beta Release date to 
2009-10-20 instead of its scheduled date of 2009-10-13 (one week from 
Tuesday).  The original intention was also to move the final release 
date of Fedora 12 to 2009-11-17, but that decision has been deferred 
until Thursday while the Infrastructure team researches some issues 
related to an upcoming data center move.

The next meeting to determine the final release date for Fedora 12 will 
be this Thursday, 2009-10-08 at 18:00 UTC (2 PM EDT) in #fedora-meeting. 
  After that meeting all of the detailed Fedora 12 team schedules will 
be fully updated to reflect the plan of record.

REMINDER: we are in and will remain in FINAL FREEZE for Fedora 12.  This 
is not a new opportunity for more time to continue development work or 
squeeze more bug fixes into Fedora 12.  A new branch is already open 
where this work can continue for Fedora 13.
https://fedoraproject.org/wiki/Beta_Freeze_Policy

John


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From rakesh.pandit at gmail.com  Tue Oct  6 04:23:00 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 6 Oct 2009 09:53:00 +0530
Subject: Package Review Stats for last 7 days ending 4th
Message-ID: 

Top five FAS account holders who have completed reviewing "Package
review" components on bugzilla for 7 days ending 4th Oct were Mamoru
Tasaka, Alan Pevec, Chitlesh GOORAH, Jan Klepek and Thomas Janssen.

Start Date: 2009-09-27 00:00:00
End Date: 2009-10-04 00:00:00

Mamoru Tasaka - 5

	https://bugzilla.redhat.com/show_bug.cgi?id=466047
	https://bugzilla.redhat.com/show_bug.cgi?id=525988
	https://bugzilla.redhat.com/show_bug.cgi?id=525989
	https://bugzilla.redhat.com/show_bug.cgi?id=525210
	https://bugzilla.redhat.com/show_bug.cgi?id=525786


Alan Pevec - 4

	https://bugzilla.redhat.com/show_bug.cgi?id=526041
	https://bugzilla.redhat.com/show_bug.cgi?id=468804
	https://bugzilla.redhat.com/show_bug.cgi?id=468230
	https://bugzilla.redhat.com/show_bug.cgi?id=503591


Chitlesh GOORAH - 3

	https://bugzilla.redhat.com/show_bug.cgi?id=524545
	https://bugzilla.redhat.com/show_bug.cgi?id=526274
	https://bugzilla.redhat.com/show_bug.cgi?id=524346


Jan Klepek - 3

	https://bugzilla.redhat.com/show_bug.cgi?id=522988
	https://bugzilla.redhat.com/show_bug.cgi?id=520463
	https://bugzilla.redhat.com/show_bug.cgi?id=525913


Thomas Janssen - 3

	https://bugzilla.redhat.com/show_bug.cgi?id=526238
	https://bugzilla.redhat.com/show_bug.cgi?id=526544
	https://bugzilla.redhat.com/show_bug.cgi?id=525453


Guido Grazioli - 2

	https://bugzilla.redhat.com/show_bug.cgi?id=525795
	https://bugzilla.redhat.com/show_bug.cgi?id=525796


Jussi Lehtola - 2

	https://bugzilla.redhat.com/show_bug.cgi?id=225886
	https://bugzilla.redhat.com/show_bug.cgi?id=525909


Peter Lemenkov - 2

	https://bugzilla.redhat.com/show_bug.cgi?id=526303
	https://bugzilla.redhat.com/show_bug.cgi?id=509158


Ben Boeckel - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=489728


Bryan O'Sullivan - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=523883


Christian Krause - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=509310


Christoph Wickert - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526866


Gianluca Sforna - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=524888


Juan Manuel Rodriguez - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=518586


Martin Gieseking - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526055


Michael Schwendt - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=525929


Michel Alexandre Salim - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=475861


Nick Bebout - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526595


Nicolas Mailhot - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=512079


Peter Robinson - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=488563


Rex Dieter - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=525510


Roman Rakus - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=502854


Stefan Schulze Frielinghaus - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=524332


Steve Traylen - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=516529


Terje R??sten - 1

	https://bugzilla.redhat.com/show_bug.cgi?id=521430



Total reviews modified: 41
Merge Reviews: 1
Review Requests: 40

This report by generated by bzReviewReport.py.
The source is available at:
https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
Please submit patches or bug reports at: https://fedorahosted.org/triage/


-- 
Rakesh Pandit
https://fedoraproject.org/
freedom, friends, features, first



From awilliam at redhat.com  Tue Oct  6 04:29:32 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Mon, 05 Oct 2009 21:29:32 -0700
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <4ACA0239.3010000@hhs.nl>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>
	<4ACA0239.3010000@hhs.nl>
Message-ID: <1254803372.2291.20.camel@adam.local.net>

On Mon, 2009-10-05 at 16:27 +0200, Hans de Goede wrote:

> Thanks for bringing this up. I'll create a patch for the scripts
> generating the livecd to add rd_NO_LUKS to the normal livecd
> syslinux.cfg entry. I already was planning on doing this, but I forgot.

can you file a tag request to get this into the beta? it's the kind of
thing that shouldn't show up in the beta, and we can't fix it with
updates. and it's a pretty safe change (just switching a behaviour
choice when we know both choices do what they're supposed to). CCing
Jesse to accept the request.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From johannbg at hi.is  Tue Oct  6 07:17:57 2009
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Tue, 06 Oct 2009 07:17:57 +0000
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>		<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
Message-ID: <4ACAEF25.5010701@hi.is>

On 10/05/2009 09:05 PM, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
>   
>> On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>>
>>     
>>> (gdb) bt
>>> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>>> #1  0x00000000004e615a in WaitForSomething (
>>>     pClientsReady=) at WaitFor.c:228
>>> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
>>> #3  0x000000000042d205 in main (argc=,
>>>     argv=0x7fffa2ac9218, envp=) at main.c:397
>>>       
>> Okay, this isn't the server actually taking 100% of the CPU (almost
>> certainly), it's before that.  If you type 'cont' to resume, and then ^C
>> the gdb process once the CPU goes wild, you should break back to the gdb
>> prompt; _that_'s the backtrace I need.
>>
>> Of course, you might not, in which case debugging this gets a bit
>> harder.
>>
>> - ajax
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>     
> (gdb) handle SIGUSR1 nostop
> Signal        Stop      Print   Pass to program Description
> SIGUSR1       No        Yes     Yes             User defined signal 1
> (gdb) handle SIGUSR2 nostop
> Signal        Stop      Print   Pass to program Description
> SIGUSR2       No        Yes     Yes             User defined signal 2
> (gdb) handle SIGPIPE nostop
> Signal        Stop      Print   Pass to program Description
> SIGPIPE       No        Yes     Yes             Broken pipe
> (gdb) cont
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
> (gdb) bt
> #0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
> #1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
> arg=0x7fff78cabbc0) at xf86drm.c:187
> #2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
> drmCommandIndex=, data=0x7fff78cabbc0,
> size=)
>     at xf86drm.c:2363
> #3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf= optimized out>) at radeon_bufmgr_gem.c:282
> #4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
> index=0) at radeon_exa.c:279
> #5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
> index=0) at exa.c:523
> #6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
> index=0, pReg=0x0) at exa.c:543
> #7  0x00007f6c69beceac in ExaCheckComposite (op=,
> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>,
>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
> width=55, height=18) at exa_unaccel.c:342
> #8  0x00007f6c69beb564 in exaComposite (op=,
> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>,
>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
> width=55, height=18) at exa_render.c:967
> #9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc= optimized out>, pMask=, pDst=0x27a04b0, xSrc=1,
> ySrc=0,
>     xMask=, yMask=, xDst=19,
> yDst=85, width=55, height=) at damage.c:643
> #10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
> #11 0x00000000004471d4 in Dispatch () at dispatch.c:456
> #12 0x000000000042d205 in main (argc=,
> argv=0x7fff78cac198, envp=) at main.c:397
>
>   

Which kernel are you using ?

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: 

From Quentin at Armitage.org.uk  Tue Oct  6 08:11:40 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Tue, 06 Oct 2009 09:11:40 +0100
Subject: rawhide report: 20091002 changes
Message-ID: <1254816700.2466.10.camel@samson.armitage.org.uk>

The report for 20091001 shows the following broken dependency, and it is
not listed in the report for 20091002:
perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires
perl(POE::Component::Client::Keepalive) >= 0:0.0901

However, the report for 20091002 shows no relevant package update that
could have resolved this broken dependency. Is there something not quite
right here?

(I note that the perl-POE-Component-Client-HTTP package source was
updated on 30th September, but it doesn't appear to have been tagged or
rebuilt in Koji).




From joshuacov at googlemail.com  Tue Oct  6 08:52:18 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 6 Oct 2009 10:52:18 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <4ACAEF25.5010701@hi.is>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
	<4ACAEF25.5010701@hi.is>
Message-ID: <5f6f8c5f0910060152y7971690dsf81f6634ef7e13c6@mail.gmail.com>

2009/10/6 "J?hann B. Gu?mundsson" :
> On 10/05/2009 09:05 PM, Joshua C. wrote:
>> 2009/10/5 Adam Jackson :
>>
>>> On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>>>
>>>
>>>> (gdb) bt
>>>> #0 ?0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>>>> #1 ?0x00000000004e615a in WaitForSomething (
>>>> ? ? pClientsReady=) at WaitFor.c:228
>>>> #2 ?0x0000000000446ef2 in Dispatch () at dispatch.c:386
>>>> #3 ?0x000000000042d205 in main (argc=,
>>>> ? ? argv=0x7fffa2ac9218, envp=) at main.c:397
>>>>
>>> Okay, this isn't the server actually taking 100% of the CPU (almost
>>> certainly), it's before that. ?If you type 'cont' to resume, and then ^C
>>> the gdb process once the CPU goes wild, you should break back to the gdb
>>> prompt; _that_'s the backtrace I need.
>>>
>>> Of course, you might not, in which case debugging this gets a bit
>>> harder.
>>>
>>> - ajax
>>>
>>> --
>>> fedora-devel-list mailing list
>>> fedora-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>>
>> (gdb) handle SIGUSR1 nostop
>> Signal ? ? ? ?Stop ? ? ?Print ? Pass to program Description
>> SIGUSR1 ? ? ? No ? ? ? ?Yes ? ? Yes ? ? ? ? ? ? User defined signal 1
>> (gdb) handle SIGUSR2 nostop
>> Signal ? ? ? ?Stop ? ? ?Print ? Pass to program Description
>> SIGUSR2 ? ? ? No ? ? ? ?Yes ? ? Yes ? ? ? ? ? ? User defined signal 2
>> (gdb) handle SIGPIPE nostop
>> Signal ? ? ? ?Stop ? ? ?Print ? Pass to program Description
>> SIGPIPE ? ? ? No ? ? ? ?Yes ? ? Yes ? ? ? ? ? ? Broken pipe
>> (gdb) cont
>> Continuing.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> (gdb) bt
>> #0 ?0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> #1 ?0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
>> arg=0x7fff78cabbc0) at xf86drm.c:187
>> #2 ?0x0000003cd600335c in drmCommandWriteRead (fd=8,
>> drmCommandIndex=, data=0x7fff78cabbc0,
>> size=)
>> ? ? at xf86drm.c:2363
>> #3 ?0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=> optimized out>) at radeon_bufmgr_gem.c:282
>> #4 ?0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
>> index=0) at radeon_exa.c:279
>> #5 ?0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
>> index=0) at exa.c:523
>> #6 ?0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
>> index=0, pReg=0x0) at exa.c:543
>> #7 ?0x00007f6c69beceac in ExaCheckComposite (op=,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=> out>,
>> ? ? ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_unaccel.c:342
>> #8 ?0x00007f6c69beb564 in exaComposite (op=,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=> out>,
>> ? ? ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_render.c:967
>> #9 ?0x000000000052eb90 in damageComposite (op=8 '\b', pSrc=> optimized out>, pMask=, pDst=0x27a04b0, xSrc=1,
>> ySrc=0,
>> ? ? xMask=, yMask=, xDst=19,
>> yDst=85, width=55, height=) at damage.c:643
>> #10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
>> #11 0x00000000004471d4 in Dispatch () at dispatch.c:456
>> #12 0x000000000042d205 in main (argc=,
>> argv=0x7fff78cac198, envp=) at main.c:397
>>
>>
>
> Which kernel are you using ?
>
> JBG
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
 I think the following can be useful:

lspci -vvv:
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon
Xpress 200M] (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 010f
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- 

From mnowak at redhat.com  Tue Oct  6 09:17:46 2009
From: mnowak at redhat.com (Michal Nowak)
Date: Tue, 6 Oct 2009 05:17:46 -0400 (EDT)
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <120074877.1068591254820465286.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1283835916.1068631254820666316.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Michal Nowak"  wrote:

> But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901
> you might wanna test it -- looked good.

As of now it's "RESOLVED FIXED". Should be part of 2.6.32 kernel (when
is out).

Michal



From mcepl at redhat.com  Tue Oct  6 09:33:32 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 6 Oct 2009 09:33:32 +0000 (UTC)
Subject: Help with debuging Xserver / Goes in an infinite loop
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
Message-ID: 

Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:

Do we have a bug for this? If not, please do file one and include all 
those information you collected for this thread together with /var/log/
Xorg.0.log (if possible after the problem happened -- on reboot put 3 to 
the end of the kernel command line, so Xorg is not started on boot, and 
then you can save previous /var/log/Xorg.0.log from the session which 
ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg 
(if you can get it from other terminal than the one where you run gdb in 
moment things go bad).

Thank you very much,

Mat?j



From thomas.moschny at gmail.com  Tue Oct  6 09:41:15 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Tue, 6 Oct 2009 11:41:15 +0200
Subject: another spin of TeX Live 2009 packages
In-Reply-To: <20090826130218.GB2845@pucmeloud.brq.redhat.com>
References: <20090826130218.GB2845@pucmeloud.brq.redhat.com>
Message-ID: 

Hi,

the repository at http://jnovy.fedorapeople.org/texlive/packages/
contains a lot of rawhide (f12) packages, so it can no longer be used
on f11, was that intentional?

Thanks,
Thomas

-- 
Thomas Moschny 



From mcepl at redhat.com  Tue Oct  6 09:41:34 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 6 Oct 2009 09:41:34 +0000 (UTC)
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
References: 
Message-ID: 

Matej Cepl, Fri, 02 Oct 2009 15:26:09 +0000:
> However, for personal reasons I
> need to decrease my personal involvment in non-work related Fedora work.

I have still on my list:

* cycle -- Calendar program for women (any ladies would like to decrease
  gender gap in Fedora packaging? Or would like to switch your wife to
  Linux?)
* vim-vimoutliner -- Script for building an outline editor on top of Vim
  (for vim lovers I don't know about any better outline editor/task
  manager, heck some people use it for writing huge technical books :))
* ldapvi -- An interactive LDAP client (the best tool for managing LDAP
  server I know about in Fedora)
* JSDoc -- Produces javadoc-style documentation from JavaScript
  sourcefiles
* python-urllib2_kerberos -- Kerberos over HTTP Negotiate/SPNEGO support
  for urllib2

Please take them to your good hands.

Thanks,

Mat?j



From che666 at gmail.com  Tue Oct  6 09:59:46 2009
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 6 Oct 2009 11:59:46 +0200
Subject: olpc components in x86/x86_64 repo
Message-ID: 

yum list all |grep olpc
dracut-modules-olpc.x86_64              0.2.1-2.fc12                   rawhide
olpc-contents.x86_64                    2.6-2.fc12                     rawhide
olpc-library.noarch                     2.0.2-2.fc12                   rawhide
olpc-netutils.noarch                    0.7-4.fc12                     rawhide
olpc-switch-desktop.noarch              0.6-2.fc12                     rawhide
olpc-update.noarch                      2.20-1.fc12                    rawhide
olpc-utils.x86_64                       1.0.3-2.fc12                   rawhide

does it really make sense to have those modules available on
x86/x86_64? (this is from rawhide)

kind regards,
Rudolf Kastl



From steve at lonetwin.net  Tue Oct  6 10:58:52 2009
From: steve at lonetwin.net (steve)
Date: Tue, 06 Oct 2009 16:28:52 +0530
Subject: PolicyKitOne or consolehelper for command line tool ?
Message-ID: <4ACB22EC.6010802@lonetwin.net>

Hi,

I am a user of the 'usb_modeswitch'[1] tool which is also available as a Fedora 
package.

Since this is a tool to be run as super-user but currently does not error out or 
warn when it is not invoked by root. I thought that i'd file a bug against the 
package to prompt for root password.

I had a general idea that the general way to do this was by using 
consolehelper/userhelper. So, i decided to do some research and submit a bug 
report with a recommended solution, but i came across this:

   https://bugzilla.redhat.com/show_bug.cgi?id=502765
   http://fedoraproject.org/wiki/Features/PolicyKitOne

So, here are my questions
a. Does this also apply for CLI tools such as usb_modeswitch ?

b. If not, shouldn't that be explicitly stated in the BZ/wiki page ?

c. If yes, is there a doc where I can learn more about PolicyKitOne ? I admit, i 
really don't know much about the PolicyKit framework itself, but little that i 
know, had me believing that PolicyKit is more of a Gnome (or rather a 
freedesktop thing). In any case, an introduction/doc of the /current/ state of 
PolicyKit too would help.



cherrs,
- steve


[1] http://www.draisberghof.de/usb_modeswitch/
-- 
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/



From pbrobinson at gmail.com  Tue Oct  6 11:31:05 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 6 Oct 2009 12:31:05 +0100
Subject: olpc components in x86/x86_64 repo
In-Reply-To: 
References: 
Message-ID: <5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>

On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl  wrote:
> yum list all |grep olpc
> dracut-modules-olpc.x86_64 ? ? ? ? ? ? ?0.2.1-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
> olpc-contents.x86_64 ? ? ? ? ? ? ? ? ? ?2.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
> olpc-library.noarch ? ? ? ? ? ? ? ? ? ? 2.0.2-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
> olpc-netutils.noarch ? ? ? ? ? ? ? ? ? ?0.7-4.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
> olpc-switch-desktop.noarch ? ? ? ? ? ? ?0.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
> olpc-update.noarch ? ? ? ? ? ? ? ? ? ? ?2.20-1.fc12 ? ? ? ? ? ? ? ? ? ?rawhide
> olpc-utils.x86_64 ? ? ? ? ? ? ? ? ? ? ? 1.0.3-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>
> does it really make sense to have those modules available on
> x86/x86_64? (this is from rawhide)

Yes, because they are used on both x86 and x86_64 platforms. What is
the problem having them there?

Peter



From jnovy at redhat.com  Tue Oct  6 11:49:49 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 6 Oct 2009 13:49:49 +0200
Subject: Oracle DB 4.8.24 released
Message-ID: <20091006114949.GA28146@dhcp-lab-133.englab.brq.redhat.com>

Hi!

Oracle released a new DB 4.8.24 recently and it is now ready to hit
rawhide. Before that happens I want to let you test your package(s)
with this new release so that we may delay updating to the latest
version if severe problems with it are reported.

With an exception of the RPC support which was dropped by upstream you
shouldn't experience lots of incompatibilities.

For testing you can use packages from this scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1730146

Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From che666 at gmail.com  Tue Oct  6 11:58:05 2009
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 6 Oct 2009 13:58:05 +0200
Subject: olpc components in x86/x86_64 repo
In-Reply-To: <5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>
References: 
	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>
Message-ID: 

2009/10/6 Peter Robinson :
> On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl  wrote:
>> yum list all |grep olpc
>> dracut-modules-olpc.x86_64 ? ? ? ? ? ? ?0.2.1-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>> olpc-contents.x86_64 ? ? ? ? ? ? ? ? ? ?2.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>> olpc-library.noarch ? ? ? ? ? ? ? ? ? ? 2.0.2-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>> olpc-netutils.noarch ? ? ? ? ? ? ? ? ? ?0.7-4.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>> olpc-switch-desktop.noarch ? ? ? ? ? ? ?0.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>> olpc-update.noarch ? ? ? ? ? ? ? ? ? ? ?2.20-1.fc12 ? ? ? ? ? ? ? ? ? ?rawhide
>> olpc-utils.x86_64 ? ? ? ? ? ? ? ? ? ? ? 1.0.3-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>>
>> does it really make sense to have those modules available on
>> x86/x86_64? (this is from rawhide)
>
> Yes, because they are used on both x86 and x86_64 platforms. What is
> the problem having them there?
>
> Peter

somehow i had the impression they are atleast partially related to the
olpc hardware.

kind regards,
Rudolf Kastl

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From pbrobinson at gmail.com  Tue Oct  6 12:03:10 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 6 Oct 2009 13:03:10 +0100
Subject: olpc components in x86/x86_64 repo
In-Reply-To: 
References: 
	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>
	
Message-ID: <5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>

On Tue, Oct 6, 2009 at 12:58 PM, Rudolf Kastl  wrote:
> 2009/10/6 Peter Robinson :
>> On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl  wrote:
>>> yum list all |grep olpc
>>> dracut-modules-olpc.x86_64 ? ? ? ? ? ? ?0.2.1-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>>> olpc-contents.x86_64 ? ? ? ? ? ? ? ? ? ?2.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>>> olpc-library.noarch ? ? ? ? ? ? ? ? ? ? 2.0.2-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>>> olpc-netutils.noarch ? ? ? ? ? ? ? ? ? ?0.7-4.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>>> olpc-switch-desktop.noarch ? ? ? ? ? ? ?0.6-2.fc12 ? ? ? ? ? ? ? ? ? ? rawhide
>>> olpc-update.noarch ? ? ? ? ? ? ? ? ? ? ?2.20-1.fc12 ? ? ? ? ? ? ? ? ? ?rawhide
>>> olpc-utils.x86_64 ? ? ? ? ? ? ? ? ? ? ? 1.0.3-2.fc12 ? ? ? ? ? ? ? ? ? rawhide
>>>
>>> does it really make sense to have those modules available on
>>> x86/x86_64? (this is from rawhide)
>>
>> Yes, because they are used on both x86 and x86_64 platforms. What is
>> the problem having them there?
>>
>> Peter
>
> somehow i had the impression they are atleast partially related to the
> olpc hardware.

Those ones aren't necessarily, and even then why does that stop them
from being in rawhide. There's lots of packages for specific hardware
in Fedora and these devices run Fedora.

Peter



From limb at jcomserv.net  Tue Oct  6 12:05:59 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 06 Oct 2009 07:05:59 -0500
Subject: olpc components in x86/x86_64 repo
In-Reply-To: <5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>
References: 	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>	
	<5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>
Message-ID: <4ACB32A7.1080500@jcomserv.net>

Peter Robinson wrote:
> On Tue, Oct 6, 2009 at 12:58 PM, Rudolf Kastl  wrote:
>   
>> 2009/10/6 Peter Robinson :
>>     
>>> On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl  wrote:
>>>       
>>>> yum list all |grep olpc
>>>> dracut-modules-olpc.x86_64              0.2.1-2.fc12                   rawhide
>>>> olpc-contents.x86_64                    2.6-2.fc12                     rawhide
>>>> olpc-library.noarch                     2.0.2-2.fc12                   rawhide
>>>> olpc-netutils.noarch                    0.7-4.fc12                     rawhide
>>>> olpc-switch-desktop.noarch              0.6-2.fc12                     rawhide
>>>> olpc-update.noarch                      2.20-1.fc12                    rawhide
>>>> olpc-utils.x86_64                       1.0.3-2.fc12                   rawhide
>>>>
>>>> does it really make sense to have those modules available on
>>>> x86/x86_64? (this is from rawhide)
>>>>         
>>> Yes, because they are used on both x86 and x86_64 platforms. What is
>>> the problem having them there?
>>>
>>> Peter
>>>       
>> somehow i had the impression they are atleast partially related to the
>> olpc hardware.
>>     
>
> Those ones aren't necessarily, and even then why does that stop them
> from being in rawhide. There's lots of packages for specific hardware
> in Fedora and these devices run Fedora.
>
> Peter
>
>   
Additionally, having OLPC-specific RPMS in mainline Fedora helps with 
the end goal that is , as I understand it, to have OLPC's OS be 
essentially a Spin of stock Fedora.  It also helps OLPC devs who don't 
necessarily have XOs.

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie



From pmatilai at laiskiainen.org  Tue Oct  6 12:48:32 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 6 Oct 2009 15:48:32 +0300 (EEST)
Subject: Bug reporting URL field in packages
Message-ID: 


A while ago there was a request to add a bug reporting URL to packages:
https://bugzilla.redhat.com/show_bug.cgi?id=512774

This was added to Fedora's rpm recently, what's still missing is the 
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:

a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?

 	- Panu -



From karlthered at gmail.com  Tue Oct  6 13:10:17 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Tue, 06 Oct 2009 15:10:17 +0200
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
Message-ID: <4ACB41B9.3040509@gmail.com>

Le 06/10/2009 14:48, Panu Matilainen a ?crit :
> 
> A while ago there was a request to add a bug reporting URL to packages:
> https://bugzilla.redhat.com/show_bug.cgi?id=512774
> 
> This was added to Fedora's rpm recently, what's still missing is the
> default contents of the %{bugurl} macro in redhat-rpm-config.
> Opinions wanted:
> 
> a) just make it https://bugzilla.redhat.com
> b) use http://bugz.fedoraproject.org/%{name}
> c) something else, what?
> 
>     - Panu -
> 

I'd go for b) for mainly two reasons:
- the UI is less messed than bugzilla's (and also faster). People can
easily review existing bugs ===> potentially less work for triagers.
- since some are still confused about the whole fedora/redhat thing, I'd
rather use the fedoraproject url.
My 2 cts

H.



From Juha.Tuomala at iki.fi  Tue Oct  6 13:13:17 2009
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Tue, 6 Oct 2009 16:13:17 +0300
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
Message-ID: <200910061613.18324.Juha.Tuomala@iki.fi>




On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
> This was added to Fedora's rpm recently, what's still missing is the 
> default contents of the %{bugurl} macro in redhat-rpm-config.
> Opinions wanted:
> 
> a) just make it https://bugzilla.redhat.com
> b) use http://bugz.fedoraproject.org/%{name}
> c) something else, what?

  d) use host part from rpm-config, and rest from package metadata.

and then one would be able to change report database
by modifying only one package.

Something like:

rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
package    %{name} = bacula

--> %{bugreporthost}/%{name} 
--> http://bugzilla.redhat.com/bacula

Then downstream distros and IT-organizations could try to catch 
all reports to their own bug reporting systems before disturbing 
Fedora - as in many cases downstream may actually be the culprit 
for the problem after all.

If that would not be possible, it would force them to rebuild
all packages and burn rainforests while doing so.... or just
waste Fedoraproject's hours for issues that doesn't belong there.

This probably isn't something that cannot be fixed later, but 
while it's on plate....? ;-)


Tuju

-- 
Better to have one, and not need it, than to need one and not have it.



From jwboyer at gmail.com  Tue Oct  6 13:32:08 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 6 Oct 2009 09:32:08 -0400
Subject: Oracle DB 4.8.24 released
In-Reply-To: <20091006114949.GA28146@dhcp-lab-133.englab.brq.redhat.com>
References: <20091006114949.GA28146@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: <20091006133207.GB3053@hansolo.jdub.homelinux.org>

On Tue, Oct 06, 2009 at 01:49:49PM +0200, Jindrich Novy wrote:
>Hi!
>
>Oracle released a new DB 4.8.24 recently and it is now ready to hit
>rawhide. Before that happens I want to let you test your package(s)

You mean devel/dist-f13.  Rawhide is still tracking dist-f12.

/me tries to avoid confusion.

josh



From joshuacov at googlemail.com  Tue Oct  6 13:44:45 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 6 Oct 2009 15:44:45 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: 
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
	
Message-ID: <5f6f8c5f0910060644t6b0a48e2k2c0dca75f578d829@mail.gmail.com>

2009/10/6 Matej Cepl :
> Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
>
> Do we have a bug for this? If not, please do file one and include all
> those information you collected for this thread together with /var/log/
> Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
> the end of the kernel command line, so Xorg is not started on boot, and
> then you can save previous /var/log/Xorg.0.log from the session which
> ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
> (if you can get it from other terminal than the one where you run gdb in
> moment things go bad).
>
> Thank you very much,
>
> Mat?j
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452



From steve at lonetwin.net  Tue Oct  6 13:46:15 2009
From: steve at lonetwin.net (steve)
Date: Tue, 06 Oct 2009 19:16:15 +0530
Subject: Bug reporting URL field in packages
In-Reply-To: <200910061613.18324.Juha.Tuomala@iki.fi>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
Message-ID: <4ACB4A27.50109@lonetwin.net>

On 10/06/2009 06:43 PM, Juha Tuomala wrote:
> On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
>>  This was added to Fedora's rpm recently, what's still missing is the
>>  default contents of the %{bugurl} macro in redhat-rpm-config.
>>  Opinions wanted:
>>
>>  a) just make it https://bugzilla.redhat.com
>>  b) use http://bugz.fedoraproject.org/%{name}
>>  c) something else, what?
>
>    d) use host part from rpm-config, and rest from package metadata.
>
> and then one would be able to change report database
> by modifying only one package.
>
> Something like:
>
> rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
> package    %{name} = bacula
>
> -->  %{bugreporthost}/%{name}
> -->  http://bugzilla.redhat.com/bacula
>
+1 on this.

cheers,
- steve



-- 
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/



From jeff at ocjtech.us  Tue Oct  6 14:23:20 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 6 Oct 2009 09:23:20 -0500
Subject: Problem building Asterisk sounds
Message-ID: <935ead450910060723k7836e593ma7d0b418e4d2c2af@mail.gmail.com>

I'm trying to build the latest Asterisk sounds package, but I'm
getting the following error:

error: Recognition of file
"/builddir/build/BUILDROOT/asterisk-sounds-core-1.4.16-1.fc13.noarch/usr/share/asterisk/sounds/fr/digits/1.g729"
failed: mode 100444 zlib: invalid stored block lengthsempty (gzip
compressed data, reserved method, encrypted, last modified: Tue Nov  9
20:48:48 2010, max speed)

The full build log is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1730585

The build fails in mock locally as well but koji actually gives me a
better error message.  The file in question isn't gzip compressed,
it's an audio file compressed with G.729 audio compression.  Can
anyone help me out here?

-- 
Jeff Ollie



From pmatilai at laiskiainen.org  Tue Oct  6 14:37:38 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 6 Oct 2009 17:37:38 +0300 (EEST)
Subject: Bug reporting URL field in packages
In-Reply-To: <200910061613.18324.Juha.Tuomala@iki.fi>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
Message-ID: 

On Tue, 6 Oct 2009, Juha Tuomala wrote:
>
> On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
>> This was added to Fedora's rpm recently, what's still missing is the
>> default contents of the %{bugurl} macro in redhat-rpm-config.
>> Opinions wanted:
>>
>> a) just make it https://bugzilla.redhat.com
>> b) use http://bugz.fedoraproject.org/%{name}
>> c) something else, what?
>
>  d) use host part from rpm-config, and rest from package metadata.
>
> and then one would be able to change report database
> by modifying only one package.
>
> Something like:
>
> rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
> package    %{name} = bacula
>
> --> %{bugreporthost}/%{name}
> --> http://bugzilla.redhat.com/bacula
>
> Then downstream distros and IT-organizations could try to catch
> all reports to their own bug reporting systems before disturbing
> Fedora - as in many cases downstream may actually be the culprit
> for the problem after all.
>
> If that would not be possible, it would force them to rebuild
> all packages and burn rainforests while doing so.... or just
> waste Fedoraproject's hours for issues that doesn't belong there.
>
> This probably isn't something that cannot be fixed later, but
> while it's on plate....? ;-)

Something like that is quite easily doable by adding a RPMTAG_BUGURL tag 
extension which grabs its value from macro configuration if set, otherwise 
use the contents from the package.

It is out of scope for this discussion though, the question here is about 
the default value Fedora packages should have. The BUGURL tag contents is 
just a plain old string which is expanded from %bugurl macro at build time 
and currently no further processing is done on it.

 	- Panu -



From tcallawa at redhat.com  Tue Oct  6 15:03:19 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 06 Oct 2009 11:03:19 -0400
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 	<200910061613.18324.Juha.Tuomala@iki.fi>
	
Message-ID: <4ACB5C37.1080706@redhat.com>

On 10/06/2009 10:37 AM, Panu Matilainen wrote:
> It is out of scope for this discussion though, the question here is
> about the default value Fedora packages should have. The BUGURL tag
> contents is just a plain old string which is expanded from %bugurl macro
> at build time and currently no further processing is done on it.

http://bugz.fedoraproject.org/%{name} would be ideal here, but we would
need for %{name} to evaluate to the SRPM name, not the subpackage name.

~spot



From jkeating at redhat.com  Tue Oct  6 15:05:23 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Oct 2009 08:05:23 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
Message-ID: <1254841523.7609.14.camel@localhost.localdomain>

On Tue, 2009-10-06 at 17:37 +0300, Panu Matilainen wrote:
> Something like that is quite easily doable by adding a RPMTAG_BUGURL tag 
> extension which grabs its value from macro configuration if set, otherwise 
> use the contents from the package.
> 
> It is out of scope for this discussion though, the question here is about 
> the default value Fedora packages should have. The BUGURL tag contents is 
> just a plain old string which is expanded from %bugurl macro at build time 
> and currently no further processing is done on it. 

I think what we would like to avoid is hardcoding it in the binary rpm.
One of the goals of Fedora is to have our rpms used as is in downstream
respins, where it would be inappropriate for the rpm to define our
bugzilla as the bug filing location.  But if I get what you're saying
right, you could have it hardcoded in the rpm for a case where it isn't
defined (at least in part) in a macro file on the users's system, and
when there is a macro file that defines it on the users's system, use
that definition instead of the one in the rpm itself.  Is that what
you're saying?

We'd also want to avoid a flag day of mass rebuilding any time we want
to change the landing point for people to query/file bugs for a package.

For now, in the rpm itself, I don't think it's unreasonable to use
http://bugz.fedoraproject.org/%{name} although I think in the future
we'll want a redesigned landing spot that doesn't confuse users with
unnecessary fedora account system data, conflicting login buttons, etc..

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From deadbabylon at googlemail.com  Tue Oct  6 15:45:00 2009
From: deadbabylon at googlemail.com (Sebastian Vahl)
Date: Tue, 6 Oct 2009 17:45:00 +0200
Subject: KDE-SIG weekly report (41/2009)
Message-ID: <200910061745.08631.deadbabylon@googlemail.com>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 41/2009

Time: 2009-10-06 14:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-06

Meeting minutes: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-06/fedora-meeting.2009-10-06-14.01.html

Meeting log: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-06/fedora-meeting.2009-10-06-14.01.log.html

----------------------------------------------------------------------------------

= Participants =

*  BenBoeckel
* JaroslavReznik
* KevinKofler
* LukasTinkl
* RexDieter
* SebastianVahl
* StevenParrish
* ThanNgo
* ThomasJanssen 

----------------------------------------------------------------------------------

= Agenda =

* topics to discuss
o F-12 kde spin status
o Tracking ongoing development/projects: please use bugzilla. examples 
include: kdm fprint, ooo kde integration, PolKitOne-qt
o qt-4.5.3 builds broken, missing translations
o kde-4.3.2 status
o FUDCon Toronto 2009 

* recent bugs:
o qt/selinux 


= Summary =

o F-12 kde spin status:
* The x86_64 version of the KDE live images is a bit oversized due to new 
constantine-backgrounds package (703 megs).
* phonon-backend-gstreamer will also be added as default in @kde-desktop 
(phonon-backend-xine will still be the default used by phonon).
* The live images are affected by a new selinux denial which needs further 
investigation: #520022: SELinux is preventing loadkeys (loadkeys_t) "write" 
/home/liveuser/.xsession-errors (user_home_t). 

o Tracking ongoing development/projects:

* We've got complaints that we don't fill enough feature pages.
* Features pages for KDE 4.4, PackageKit1-qt, KDE fingerprint and abrt support 
will be created for F13.
* This way our cool new features would get the proper attention. 

o qt-4.5.3 builds broken, missing translations:

* The qt-4.5.3 builds are broken again.
* ThanNgo will look into that breakage. 

o kde-4.3.2 status:
* The rawhide builds for KDE 4.3.2 should be done by today. 

o FUDCon Toronto 2009:
* KDE SIG members who will attend: RexDieter, StephenParrish, BenBoeckel. 
Maybe: JaroslavReznik.
* Aaron Seigo will be there too (if funding for his costs will be provided). 

= Recent bugs =

#527079: setroubleshoot: SELinux is preventing /usr/bin/arora from changing a 
writable memory segment executable.
* The JIT disabler patch from Qt 4.5.3 will be backported to F12. 

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-13

----------------------------------------------------------------------------------

= Buglist =

https://bugzilla.redhat.com/show_bug.cgi?id=520022
https://bugzilla.redhat.com/show_bug.cgi?id=527079
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From plautrba at redhat.com  Tue Oct  6 16:47:13 2009
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 06 Oct 2009 18:47:13 +0200
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References:  
Message-ID: <4ACB7491.8060805@redhat.com>

On 10/06/2009 11:41 AM, Matej Cepl wrote:
> Matej Cepl, Fri, 02 Oct 2009 15:26:09 +0000:
>> However, for personal reasons I
>> need to decrease my personal involvment in non-work related Fedora work.
>
> I have still on my list:
>
> * vim-vimoutliner -- Script for building an outline editor on top of Vim
>    (for vim lovers I don't know about any better outline editor/task
>    manager, heck some people use it for writing huge technical books :))

Hi.

I use it for my notes so I will take it.

Regards,

Petr
-- 
Petr Lautrbach, Red Hat, Inc.



From pmatilai at laiskiainen.org  Tue Oct  6 16:59:03 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 6 Oct 2009 19:59:03 +0300 (EEST)
Subject: Bug reporting URL field in packages
In-Reply-To: <1254841523.7609.14.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
Message-ID: 

On Tue, 6 Oct 2009, Jesse Keating wrote:

> On Tue, 2009-10-06 at 17:37 +0300, Panu Matilainen wrote:
>> Something like that is quite easily doable by adding a RPMTAG_BUGURL tag
>> extension which grabs its value from macro configuration if set, otherwise
>> use the contents from the package.
>>
>> It is out of scope for this discussion though, the question here is about
>> the default value Fedora packages should have. The BUGURL tag contents is
>> just a plain old string which is expanded from %bugurl macro at build time
>> and currently no further processing is done on it.
>
> I think what we would like to avoid is hardcoding it in the binary rpm.
> One of the goals of Fedora is to have our rpms used as is in downstream
> respins, where it would be inappropriate for the rpm to define our
> bugzilla as the bug filing location.  But if I get what you're saying
> right, you could have it hardcoded in the rpm for a case where it isn't
> defined (at least in part) in a macro file on the users's system, and
> when there is a macro file that defines it on the users's system, use
> that definition instead of the one in the rpm itself.  Is that what
> you're saying?

More or less, but note that an rpm level configurable override would be 
system global for all packages. When you enter 3rd party repositories into 
the picture such a scheme wont work at all, except if capturing everything 
is what what you want (eg some corporate IT department might want just 
that).

> We'd also want to avoid a flag day of mass rebuilding any time we want
> to change the landing point for people to query/file bugs for a package.

Well in that case rpm is the wrong place entirely, and ditto for respins 
controlling their own bug report URLs. For these you'd want the bug 
reporting URL in repodata instead: spins are creating their own 
repositories so they can set it there, and regenerating the repodata to 
include a new url is cheaper than rebuilding all the packages.

 	- Panu -



From jnovy at redhat.com  Tue Oct  6 17:06:02 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 6 Oct 2009 19:06:02 +0200
Subject: Oracle DB 4.8.24 released
In-Reply-To: <20091006133207.GB3053@hansolo.jdub.homelinux.org>
References: <20091006114949.GA28146@dhcp-lab-133.englab.brq.redhat.com>
	<20091006133207.GB3053@hansolo.jdub.homelinux.org>
Message-ID: <20091006170602.GA29174@dhcp-lab-133.englab.brq.redhat.com>

On Tue, Oct 06, 2009 at 09:32:08AM -0400, Josh Boyer wrote:
> On Tue, Oct 06, 2009 at 01:49:49PM +0200, Jindrich Novy wrote:
> >Hi!
> >
> >Oracle released a new DB 4.8.24 recently and it is now ready to hit
> >rawhide. Before that happens I want to let you test your package(s)
> 
> You mean devel/dist-f13.  Rawhide is still tracking dist-f12.
> 
> /me tries to avoid confusion.

Yup, it's the F13. The new DB4 is not planned to occur in f12 at the
time.

Jindrich

> 
> josh
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From jkeating at redhat.com  Tue Oct  6 17:43:35 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Oct 2009 10:43:35 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
Message-ID: <1254851015.11617.3.camel@localhost.localdomain>

On Tue, 2009-10-06 at 19:59 +0300, Panu Matilainen wrote:
> Well in that case rpm is the wrong place entirely, and ditto for respins 
> controlling their own bug report URLs. For these you'd want the bug 
> reporting URL in repodata instead: spins are creating their own 
> repositories so they can set it there, and regenerating the repodata to 
> include a new url is cheaper than rebuilding all the packages. 

Yeah, if you always keep track of which packages you installed from
which repos and thus which bug system that particular package you
installed goes to.  (think of famous 3rd party repos that replace
packages from us)

You can't always guarantee that you'll find the exact n-v-r you're using
in an active repo in order to determine which bug URL to go to, your
version may be old or just no longer shipped.

So I guess the real question is do we want our packages built in koji to
assume a bug URL of fedora, even when used in downstream projects?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jcm at redhat.com  Tue Oct  6 18:02:57 2009
From: jcm at redhat.com (Jon Masters)
Date: Tue, 06 Oct 2009 14:02:57 -0400
Subject: Bug reporting URL field in packages
In-Reply-To: <1254851015.11617.3.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
Message-ID: <1254852177.3641.55.camel@localhost.localdomain>

On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote:

> So I guess the real question is do we want our packages built in koji to
> assume a bug URL of fedora, even when used in downstream projects?

I think that's a giant assumption - if the maintainer didn't put that
URL in the package themselves, what makes you think automatically
putting it in there is going to achieve anything different? ;)

I advocate letting people choose for themselves.

Jon.




From james at fedoraproject.org  Tue Oct  6 18:07:03 2009
From: james at fedoraproject.org (James Antill)
Date: Tue, 06 Oct 2009 14:07:03 -0400
Subject: Bug reporting URL field in packages
In-Reply-To: <1254851015.11617.3.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
Message-ID: <1254852423.29348.30.camel@code.and.org>

On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote:
> On Tue, 2009-10-06 at 19:59 +0300, Panu Matilainen wrote:
> > Well in that case rpm is the wrong place entirely, and ditto for respins 
> > controlling their own bug report URLs. For these you'd want the bug 
> > reporting URL in repodata instead: spins are creating their own 
> > repositories so they can set it there, and regenerating the repodata to 
> > include a new url is cheaper than rebuilding all the packages. 
> 
> Yeah, if you always keep track of which packages you installed from
> which repos and thus which bug system that particular package you
> installed goes to.  (think of famous 3rd party repos that replace
> packages from us)

 Yum already keeps track of that:

# yum list installed yum\*
Installed Packages
yum.noarch                              3.2.24-9.fc12                 @rawhide
yum-metadata-parser.x86_64              1.1.2-12.fc11                 @fedora 
yum-plugin-aliases.noarch               1.1.22-1.fc11                 @updates
yum-plugin-security.noarch              1.1.22-1.fc11                 @updates
yum-presto.noarch                       0.5.0-1.fc11                  @updates
yum-utils.noarch                        1.1.22-1.fc11                 @updates
yumex.noarch                            2.0.5-6.fc11                  @fedora 

-- 
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell



From jkeating at redhat.com  Tue Oct  6 18:15:40 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Oct 2009 11:15:40 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: <1254852423.29348.30.camel@code.and.org>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852423.29348.30.camel@code.and.org>
Message-ID: <1254852940.11617.4.camel@localhost.localdomain>

On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote:
>  Yum already keeps track of that:

"already" as in a brand new feature not seen outside of rawhide IIRC.
And that's great for packages installed via yum via repos, which leaves
the other junk to worry about.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From rawhide at fedoraproject.org  Tue Oct  6 20:13:14 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 6 Oct 2009 20:13:14 +0000
Subject: rawhide report: 20091006 changes
Message-ID: <20091006201314.GA26653@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct  6 06:15:15 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package pure
        A term-rewriting functional programming language
Removed package clutter-cairomm
Updated Packages:

DeviceKit-disks-007-4.fc12
--------------------------
* Mon Oct 05 2009 David Zeuthen  - 007-2.fc12
- Actually inhibit the daemon (#527091)

* Mon Oct 05 2009 David Zeuthen  - 007-3.fc12
- Rebuild

* Mon Oct 05 2009 David Zeuthen  - 007-4.fc12
- Rebuild


anaconda-12.33-1.fc12
---------------------
* Mon Oct 05 2009 David Cantrell  - 12.33-1
- Remove an errant popd. Probably cut/paste error. (jkeating)
- Only add the .img file to .treeinfo if it exists. (jkeating)
- Make the netboot dir before trying to use it (jkeating)
- Fix existing size calculation for NTFS (#520627) (dcantrell)
- Write label to filesystem if we have one set (#526226, #526242) (dcantrell)
- Add wget to the initrd, which is required for rhts. (clumens)
- Fix the check for no /boot request on PPC yet again (#526843). (clumens)
- Surround the stage2= parameter in quotes for RHEL (#526863). (clumens)
- Stop dragging mkinitrd into the install (hdegoede)
- Force interface up before checking link status (#525071). (dcantrell)
- Don't try to do format handling on drives without media (#523467)
  (hdegoede)
- Wait for mdraid arrays to become clean before reboot / halt (hdegoede)
- Stop /lib/udev/rules.d/65-md-incremental.rules from messing with mdraid
  sets (hdegoede)


at-spi-1.28.0-3.fc12
--------------------
* Fri Oct 02 2009 Matthias Clasen  - 1.28.0-3
- Fix an oversight in the previous patch that caused
  registryd to slow down logout by ~10 seconds


bluez-4.55-1.fc12
-----------------
* Mon Oct 05 2009 Bastien Nocera  4.55-1
- Update to 4.55


brasero-2.28.1-1.fc12
---------------------
* Mon Oct 05 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1, fixes a number of crashes and other serious bugs:
 - Fix a crash when we try to download a missing gstreamer plugin through PK
 - Don't fail if a drive cannot be checksumed after a burn
 - Fix a data corruption when libisofs was used for a dummy session
 - Fix #596625: brasero crashed with SIGSEGV in brasero_track_data_cfg_add
 - Fix progress reporting
 ...


control-center-2.28.0-14.fc12
-----------------------------

dcbd-0.9.15-5.fc12
------------------
* Mon Oct 05 2009 Jan Zeleny  - 0.9.15-5
- replaced the last patch, which was not fully functional, with
  the new one


dnsmasq-2.48-4.fc12
-------------------
* Mon Oct 05 2009 Mark McLoughlin  - 2.48-4
- Fix multiple TFTP server vulnerabilities (CVE-2009-2957, CVE-2009-2958)

* Wed Aug 12 2009 Ville Skytt?  - 2.48-3
- Use lzma compressed upstream tarball.


fedora-release-11.92-1
----------------------
* Mon Oct 05 2009 Jesse Keating  - 11.92-1
- Bump for 12-Beta


gnome-disk-utility-2.28.0-4.fc12
--------------------------------
* Mon Oct 05 2009 Matthias Clasen  - 2.28.0-4.fc12
- Incorporate fixes for translation issues from the stable upstream branch


gnome-keyring-2.28.0-2.fc12
---------------------------
* Fri Oct 02 2009 Matthias Clasen  - 2.28.0-2
- Avoid a 10 second delay at logout


gnome-terminal-2.28.0-2.fc12
----------------------------
* Mon Oct 05 2009 Matthias Clasen  - 2.28.0-2
- Fix a small memory leak


gpxe-0.9.7-6.fc12
-----------------
* Mon Oct 05 2009 Matt Domsch  - 0.9.7-6
- move rtl8029 from -roms to -roms-qemu for qemu ne2k_pci NIC (BZ 526776)


grsync-0.9.2-1.fc12
-------------------
* Mon Oct 05 2009 Christoph Wickert  - 0.9.2-1
- new upstream release (fixes #524169)


gstreamer-0.10.25-1.fc12
------------------------
* Mon Oct 05 2009 Bastien Nocera  0.10.25-1
- Update to 0.10.25


gstreamer-plugins-base-0.10.25-1.fc12
-------------------------------------
* Mon Oct 05 2009 Bastien Nocera  0.10.25-1
- Update to 0.10.25


libcap-ng-0.6.2-2.fc12
----------------------
* Sat Oct 03 2009 Steve Grubb  0.6.2-2
- Apply patch correcting pscap and netcap acct detection


libxklavier-4.0-5.fc12
----------------------
* Fri Oct 02 2009 Matthias Clasen  - 4.0-5
- Handle BadDrawable errors gracefully


mcelog-0.9pre1-0.1.fc12
-----------------------
* Mon Oct 05 2009 Orion Poplawski  - 1:0.9pre1-0.1
- Update to 0.9pre1
- Update URL
- Add patch to update mcelog kernel record length (bug #507026)


mdadm-3.0.2-1.fc12
------------------
* Fri Oct 02 2009 Hans de Goede  - 3.0.2-1
- New upstream release 3.0.2
- Add a patch fixing mdadm --detail -export segfaults (bz526761, bz523862)
- Add a patch making mdmon store its state under /dev/.mdadm for initrd
  mdmon, rootfs mdmon handover
- Restart mdmon from initscript (when running) for rootfs mdmon handover


mlocate-0.22.2-1.fc12
---------------------
* Fri Oct 02 2009 Miloslav Trma?  - 0.22.2-1
- Update to mlocate-0.22.2


nautilus-open-terminal-0.17-3.fc12
----------------------------------
* Mon Oct 05 2009 Matthias Clasen  - 0.17-2
- Plug a small leak


python-virtinst-0.500.0-5.fc12
------------------------------
* Mon Oct 05 2009 Cole Robinson  - 0.500.0-5.fc12
- Update translations (bz 493795)


system-config-audit-0.4.13-1.fc12
---------------------------------
* Mon Oct 05 2009 Miloslav Trma?  - 0.4.13-1
- Update to system-config-audit-0.4.13.


telepathy-gabble-0.8.5-1.fc12
-----------------------------
* Fri Oct 02 2009 Brian Pepple  - 0.8.5-1
- Update to 0.8.5.

* Wed Sep 30 2009 Brian Pepple  - 0.8.4-1
- Update to 0.8.4.


usermode-1.102-1.fc12
---------------------
* Mon Oct 05 2009 Miloslav Trma?  - 1.102-1
- Update to usermode-1.102


util-linux-ng-2.16-10.2.fc12
----------------------------
* Mon Oct 05 2009 Karel Zak  2.16-10.2
- fix #519237 - bash: cannot set terminal process group (-1): Inappropriate ioctl for device

* Fri Oct 02 2009 Karel Zak  2.16-10.1
- #514413 - Extra spaces at the end of CD mount point


vbetool-1.2.2-1.fc12
--------------------
* Fri Oct 02 2009 Dave Airlie  1.2.2-1
- update to 1.2.2 - fixes infinte loops on s/r (#516694)


virt-manager-0.8.0-7.fc12
-------------------------
* Mon Oct 05 2009 Cole Robinson  - 0.8.0-7.fc12
- More translations (bz 493795)
- Don't allow creating a volume without a name (bz 526111)
- Don't allow volume allocation > capacity (bz 526077)
- Add tooltips for toolbar buttons (bz 524083)


xorg-x11-server-1.7.0-1.fc12
----------------------------
* Mon Oct 05 2009 Dave Airlie  1.7.0-1
- rebase to 1.7.0 upstream release - were 99% this already


Summary:
Added Packages: 1
Removed Packages: 1
Modified Packages: 30



From nicolas.mailhot at laposte.net  Tue Oct  6 20:14:28 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 6 Oct 2009 22:14:28 +0200
Subject: Bug reporting URL field in packages
In-Reply-To: <4ACB5C37.1080706@redhat.com>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<4ACB5C37.1080706@redhat.com>
Message-ID: 



Le Mar 6 octobre 2009 17:03, Tom \"spot\" Callaway a ?crit :
>
> On 10/06/2009 10:37 AM, Panu Matilainen wrote:
>> It is out of scope for this discussion though, the question here is
>> about the default value Fedora packages should have. The BUGURL tag
>> contents is just a plain old string which is expanded from %bugurl macro
>> at build time and currently no further processing is done on it.
>
> http://bugz.fedoraproject.org/%{name} would be ideal here, but we would
> need for %{name} to evaluate to the SRPM name, not the subpackage name.

BTW, this is a more general problem: currently rpm metadata does not reference
the %{name} of the srpm, but its filename, which is a PITA, since srpm
filename is not really useful nowadays (also IIRC you can rename a srpm to
anything.src.rpm and the result will build and reference anything.src.rpm as
srpm info)


-- 
Nicolas Mailhot




From joshuacov at googlemail.com  Tue Oct  6 20:18:07 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 6 Oct 2009 22:18:07 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910060644t6b0a48e2k2c0dca75f578d829@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
	
	<5f6f8c5f0910060644t6b0a48e2k2c0dca75f578d829@mail.gmail.com>
Message-ID: <5f6f8c5f0910061318p3c18b383m95a3460e882f5ac5@mail.gmail.com>

2009/10/6 Joshua C. :
> 2009/10/6 Matej Cepl :
>> Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
>>
>> Do we have a bug for this? If not, please do file one and include all
>> those information you collected for this thread together with /var/log/
>> Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
>> the end of the kernel command line, so Xorg is not started on boot, and
>> then you can save previous /var/log/Xorg.0.log from the session which
>> ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
>> (if you can get it from other terminal than the one where you run gdb in
>> moment things go bad).
>>
>> Thank you very much,
>>
>> Mat?j
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
> Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452
>

I tried the latest F12-Snap3-x86_64-Live-KDE from 18.09.2009. There
were also other problems but I think this still exists in F12. I've
updated my bug report with the output from gdb.



From jlaska at redhat.com  Tue Oct  6 20:29:08 2009
From: jlaska at redhat.com (James Laska)
Date: Tue, 06 Oct 2009 16:29:08 -0400
Subject: [Test-Announce] 2009-10-08 - Fedora Test Day - RAID
Message-ID: <1254860948.5597.188.camel@localhost.localdomain>

Greetings folks,

This week features another test day focused on the installer.  The topic
is all things RAID.  The anaconda-devel team has asked for help testing
software RAID, BIOS RAID and hardware RAID.  While this is specific to
installation, I certainly welcome testing using mdadm tools on already
installed systems or even general live image testing.

Included in the 14 bugs found during last weeks installer test day were
3 additions to the F12Beta blocker list [1].  Thanks again to all who
participated.  I hope we can give similar attention to RAID this week.
If you have support for BIOS or hardware RAID, please do stop by on irc.
Your help is needed!

The fun starts this this Thursday, October 8 2009 in #fedora-test-day on
irc.freenode.net.  If you'd like to get started early, a live image is
already available along with a list of recommended test scenarios.  

Stay tuned for more details at
https://fedoraproject.org/wiki/Test_Day:2009-10-08_RAID.

Thanks,
James

[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
-------------- next part --------------
_______________________________________________
test-announce mailing list
test-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

From laurent.rineau__fedora at normalesup.org  Tue Oct  6 20:41:55 2009
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Tue, 6 Oct 2009 22:41:55 +0200
Subject: Bug reporting URL field in packages
In-Reply-To: <1254852940.11617.4.camel@localhost.localdomain>
References: 
	<1254852423.29348.30.camel@code.and.org>
	<1254852940.11617.4.camel@localhost.localdomain>
Message-ID: <200910062241.55642.laurent.rineau__fedora@normalesup.org>

Le mardi 06 octobre 2009 20:15:40, Jesse Keating a ?crit :
> On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote:
> >  Yum already keeps track of that:
> 
> "already" as in a brand new feature not seen outside of rawhide IIRC.
> And that's great for packages installed via yum via repos, which leaves
> the other junk to worry about.

That new feature of yum is also in F-11 updates:

Installed Packages
yum.noarch                      3.2.24-2.fc11                       @updates

And thank to the developer how has added it! That is very useful indeed.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From skvidal at fedoraproject.org  Tue Oct  6 21:00:07 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 6 Oct 2009 17:00:07 -0400 (EDT)
Subject: Bug reporting URL field in packages
In-Reply-To: <1254852940.11617.4.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852423.29348.30.camel@code.and.org>
	<1254852940.11617.4.camel@localhost.localdomain>
Message-ID: 



On Tue, 6 Oct 2009, Jesse Keating wrote:

> On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote:
>>  Yum already keeps track of that:
>
> "already" as in a brand new feature not seen outside of rawhide IIRC.
> And that's great for packages installed via yum via repos, which leaves
> the other junk to worry about.

that feature has been in since the first update of yum released for f11.

so it's been in use for at least 6 months, now.



-sv



From jkeating at redhat.com  Tue Oct  6 21:23:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Oct 2009 14:23:55 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852423.29348.30.camel@code.and.org>
	<1254852940.11617.4.camel@localhost.localdomain>
	
Message-ID: <1254864235.11617.8.camel@localhost.localdomain>

On Tue, 2009-10-06 at 17:00 -0400, Seth Vidal wrote:
> that feature has been in since the first update of yum released for
> f11.
> 
> so it's been in use for at least 6 months, now. 

I stand corrected.  I could have sworn we had a discussion about a late
landing change for the history db.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From orion at cora.nwra.com  Tue Oct  6 21:53:37 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 06 Oct 2009 15:53:37 -0600
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
 in NFS is about to happen]
In-Reply-To: 
References:  
Message-ID: <4ACBBC61.9000301@cora.nwra.com>

On 10/06/2009 03:41 AM, Matej Cepl wrote:
> Matej Cepl, Fri, 02 Oct 2009 15:26:09 +0000:
>> However, for personal reasons I
>> need to decrease my personal involvment in non-work related Fedora work.
>
> I have still on my list:
>
> * ldapvi -- An interactive LDAP client (the best tool for managing LDAP
>    server I know about in Fedora)

I'll take this

-- 
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 sebastian at when.com  Tue Oct  6 22:22:15 2009
From: sebastian at when.com (Sebastian Dziallas)
Date: Wed, 07 Oct 2009 00:22:15 +0200
Subject: TypePad Motion coming to Fedora...
Message-ID: <4ACBC317.5090601@when.com>

Hi everybody,

I've started packaging TypePad Motion [1] and thrown it into a repo at 
my FedoraPeople space [2] in case some of you wanted to give it a try.

It's pretty easy, just install the RPMs from above and run:

    django-admin typepadproject mymotion --settings=motion.settings

Executing the next line should already get you running, but you'll need 
to adjust some more stuff, as [3] explains:

    python manage.py runserver

Well, I could use a hand with the reviews, so [4] is the main bug that 
tracks all the other packages, too... reviews? swapsies? anybody? :)

--Sebastian

[1] http://blog.leahculver.com/2009/10/typepad-motion.html
[2] http://sdz.fedorapeople.org/typepad/
[3] http://developer.typepad.com/motion/create-motion.html
[4] https://bugzilla.redhat.com/show_bug.cgi?id=527319



From skvidal at fedoraproject.org  Tue Oct  6 22:26:02 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 6 Oct 2009 18:26:02 -0400 (EDT)
Subject: Bug reporting URL field in packages
In-Reply-To: <1254864235.11617.8.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852423.29348.30.camel@code.and.org>
	<1254852940.11617.4.camel@localhost.localdomain>
	
	<1254864235.11617.8.camel@localhost.localdomain>
Message-ID: 



On Tue, 6 Oct 2009, Jesse Keating wrote:

> On Tue, 2009-10-06 at 17:00 -0400, Seth Vidal wrote:
>> that feature has been in since the first update of yum released for
>> f11.
>>
>> so it's been in use for at least 6 months, now.
>
> I stand corrected.  I could have sworn we had a discussion about a late
> landing change for the history db.
>

that's not history. history is recording everything that happened and 
when. Recording which repo pkgs came from (and why) is yumdb. That's been 
in for a while.

-sv



From rjones at redhat.com  Tue Oct  6 22:34:37 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 6 Oct 2009 23:34:37 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: 
References: 
Message-ID: <20091006223437.GA21973@amd.home.annexia.org>

I don't know if this thread reached a conclusion, but I'd like to add
point #6 from here:

http://rwmj.wordpress.com/2009/10/06/what-things-make-p2vv2v-conversion-hard/

which is that we should avoid making permanent optimizations, and
instead try to do runtime tests wherever possible.  This is because
P2V, V2V and virtual machine migration makes it more likely that
CPU features such as SSE* can change unexpectedly.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From jspaleta at gmail.com  Tue Oct  6 23:05:27 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Oct 2009 15:05:27 -0800
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091006223437.GA21973@amd.home.annexia.org>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
Message-ID: <604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>

On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones  wrote:
> which is that we should avoid making permanent optimizations, and
> instead try to do runtime tests wherever possible. ?This is because
> P2V, V2V and virtual machine migration makes it more likely that
> CPU features such as SSE* can change unexpectedly.

This is going to be pretty important for scientific workloads where
atlas is going to be used. I've eavesdropped on several conversations
where people were talking about being able to run off-the-shelf
science code virtual appliance in order to reduce the environment
configuration workload for an individual researcher.

-jef



From andre at bwh.harvard.edu  Wed Oct  7 01:55:29 2009
From: andre at bwh.harvard.edu (Andre Robatino)
Date: Tue, 06 Oct 2009 21:55:29 -0400
Subject: didn't see "md5 mismatch" error on today's Rawhide noarch packages
Message-ID: <4ACBF511.4040700@bwh.harvard.edu>

There was at least one noarch package in today's Rawhide updates, and I
didn't see the usual "md5 mismatch" error when rebuilding the RPMs.
Does this mean that they are now being built on a little endian arch
(probably Intel), and if so, will this be done consistently from now on?
 (At least until xz is changed to generate the same compressed output on
big endian.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: 

From luoxing123 at gmail.com  Wed Oct  7 06:04:25 2009
From: luoxing123 at gmail.com (=?GB2312?B?wt7Qxw==?=)
Date: Wed, 7 Oct 2009 14:04:25 +0800
Subject: Orphaning some packages [Was: Re: Buyer Beware: A Major Change
	in NFS is about to happen]
In-Reply-To: <4ACBBC61.9000301@cora.nwra.com>
References:  
	<4ACBBC61.9000301@cora.nwra.com>
Message-ID: <4dead6330910062304i301ed7c8yd934517e2dc7225c@mail.gmail.com>

i like vim , I'll take it.

2009/10/7 Orion Poplawski 

> On 10/06/2009 03:41 AM, Matej Cepl wrote:
>
>> Matej Cepl, Fri, 02 Oct 2009 15:26:09 +0000:
>>
>>> However, for personal reasons I
>>> need to decrease my personal involvment in non-work related Fedora work.
>>>
>>
>> I have still on my list:
>>
>> * ldapvi -- An interactive LDAP client (the best tool for managing LDAP
>>   server I know about in Fedora)
>>
>
> I'll take this
>
> --
> 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
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sundaram at fedoraproject.org  Wed Oct  7 06:35:02 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Oct 2009 12:05:02 +0530
Subject: didn't see "md5 mismatch" error on today's Rawhide noarch
	packages
In-Reply-To: <4ACBF511.4040700@bwh.harvard.edu>
References: <4ACBF511.4040700@bwh.harvard.edu>
Message-ID: <4ACC3696.5040802@fedoraproject.org>

On 10/07/2009 07:25 AM, Andre Robatino wrote:
> There was at least one noarch package in today's Rawhide updates, and I
> didn't see the usual "md5 mismatch" error when rebuilding the RPMs.
> Does this mean that they are now being built on a little endian arch
> (probably Intel), and if so, will this be done consistently from now on?
>  (At least until xz is changed to generate the same compressed output on
> big endian.)

XZ upstream was informed of this problem and we have now inherited the
fix.

---

Wed Oct 07 2009 Jindrich Novy
4.999.9-0.1.20091007.beta
- update to 4.999.9beta
- sync with upstream to generate the same archives on machines with
different
  endianess
---

Rahul



From sundaram at fedoraproject.org  Wed Oct  7 07:12:21 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Oct 2009 12:42:21 +0530
Subject: olpc components in x86/x86_64 repo
In-Reply-To: <4ACB32A7.1080500@jcomserv.net>
References: 	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>		<5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>
	<4ACB32A7.1080500@jcomserv.net>
Message-ID: <4ACC3F55.7090508@fedoraproject.org>

On 10/06/2009 05:35 PM, Jon Ciesla wrote:

> Additionally, having OLPC-specific RPMS in mainline Fedora helps with
> the end goal that is , as I understand it, to have OLPC's OS be
> essentially a Spin of stock Fedora.  It also helps OLPC devs who don't
> necessarily have XOs.

IIRC, they already are shipping stock Fedora in their latest builds
except for the kernel. They are also responsible for the largest amount
of Fedora deployments in the world. So it is all mutually beneficial.

Rahul



From pbrobinson at gmail.com  Wed Oct  7 07:50:20 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 7 Oct 2009 08:50:20 +0100
Subject: olpc components in x86/x86_64 repo
In-Reply-To: <4ACC3F55.7090508@fedoraproject.org>
References: 
	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>
	
	<5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>
	<4ACB32A7.1080500@jcomserv.net> <4ACC3F55.7090508@fedoraproject.org>
Message-ID: <5256d0b0910070050n71153d0cm182f6cb72f9ea516@mail.gmail.com>

On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram
 wrote:
> On 10/06/2009 05:35 PM, Jon Ciesla wrote:
>
>> Additionally, having OLPC-specific RPMS in mainline Fedora helps with
>> the end goal that is , as I understand it, to have OLPC's OS be
>> essentially a Spin of stock Fedora. ?It also helps OLPC devs who don't
>> necessarily have XOs.
>
> IIRC, they already are shipping stock Fedora in their latest builds
> except for the kernel. They are also responsible for the largest amount
> of Fedora deployments in the world. So it is all mutually beneficial.

That is correct, we're all upstream now with no weird branches for
core packages :-)

Peter



From che666 at gmail.com  Wed Oct  7 08:51:01 2009
From: che666 at gmail.com (Rudolf Kastl)
Date: Wed, 7 Oct 2009 10:51:01 +0200
Subject: olpc components in x86/x86_64 repo
In-Reply-To: <5256d0b0910070050n71153d0cm182f6cb72f9ea516@mail.gmail.com>
References: 
	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>
	
	<5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>
	<4ACB32A7.1080500@jcomserv.net> <4ACC3F55.7090508@fedoraproject.org>
	<5256d0b0910070050n71153d0cm182f6cb72f9ea516@mail.gmail.com>
Message-ID: 

2009/10/7 Peter Robinson :
> On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram
>  wrote:
>> On 10/06/2009 05:35 PM, Jon Ciesla wrote:
>>
>>> Additionally, having OLPC-specific RPMS in mainline Fedora helps with
>>> the end goal that is , as I understand it, to have OLPC's OS be
>>> essentially a Spin of stock Fedora. ?It also helps OLPC devs who don't
>>> necessarily have XOs.
>>
>> IIRC, they already are shipping stock Fedora in their latest builds
>> except for the kernel. They are also responsible for the largest amount
>> of Fedora deployments in the world. So it is all mutually beneficial.
>
> That is correct, we're all upstream now with no weird branches for
> core packages :-)

Thats great to hear and interesting information. In no way the
question was meant as criticism. Basically i was just curious if the
packages are hardware related to the olpc hw or generally  useful.
Thanks for your answer. Best wishes for the olpc/sugar developers.
More knowledge and therefor power to the poor kids.

kind regards,
Rudolf Kastl


>
> Peter
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From rjones at redhat.com  Wed Oct  7 09:30:55 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 7 Oct 2009 10:30:55 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
Message-ID: <20091007092550.GA24906@amd.home.annexia.org>

On Tue, Oct 06, 2009 at 03:05:27PM -0800, Jeff Spaleta wrote:
> On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones  wrote:
> > which is that we should avoid making permanent optimizations, and
> > instead try to do runtime tests wherever possible. ?This is because
> > P2V, V2V and virtual machine migration makes it more likely that
> > CPU features such as SSE* can change unexpectedly.
> 
> This is going to be pretty important for scientific workloads where
> atlas is going to be used. I've eavesdropped on several conversations
> where people were talking about being able to run off-the-shelf
> science code virtual appliance in order to reduce the environment
> configuration workload for an individual researcher.

Yup.  The really fun starts when you do live migration.  The processor
literally changes underneath the running programs.  If you thought you
had SSE3 one minute, then the next you don't, or vice versa.

No one has to my knowledge come up with a good way to deal with this.
But it probably involves signalling the kernel and processes so that
they can redo processor detection.  You can see why that is not going
to be pleasant.

At the moment it's done by masking out processor flags or by limiting
migrations to known good combinations of hardware.  However that
reduces the utility of the hardware and makes system administration
more complex.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From pasik at iki.fi  Wed Oct  7 09:51:05 2009
From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=)
Date: Wed, 7 Oct 2009 12:51:05 +0300
Subject: preupgrade from f11 to rawhide broken? python traceback
In-Reply-To: <20091001195136.GN1434@reaktio.net>
References: <20090926161023.GZ31123@reaktio.net>
	
	<20091001195136.GN1434@reaktio.net>
Message-ID: <20091007095105.GS1434@reaktio.net>

On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi K?rkk?inen wrote:
> > >Traceback (most recent call last):
> > > File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in 
> > >   pu.main(myrelease)
> > > File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main
> > >   self.generate_repo(cachedir, comps) # TODO: callback?
> > > File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651, 
> > > in generate_repo
> > >   misc.generate_repodata(dir,comps,callback)
> > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in 
> > > generate_repodata
> > >   generate_repodata(dir, comps, callback)
> > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in 
> > > generate_repodata_f9
> > >   mdgen.doRepoMetadata()
> > > File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829, 
> > > in doRepoMetadata
> > >   rp.getPrimary(complete_path, csum)
> > > File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in 
> > > getPrimary
> > >   self.repoid))
> > >TypeError: Parsing primary.xml error: attributes construct error
> > >
> > >
> > >Known problem? How to fix it?
> > 
> > this is the second time I've seen this one - if you can find 
> > the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate 
> > seeing it.
> > 
> 
> # ls /var/cache/yum
> fedora  preupgrade  updates
> 
> # cd /var/cache/yum
> 
> # find -iname '*primary*'
> ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite
> ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite
> ./preupgrade/.repodata/primary.xml.gz
> ./preupgrade/.repodata/primary.xml.gz.sqlite
> ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite
> 
> 
> I put it available online here:
> http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
> 
> Firefox complains about it btw..
> 
> XML Parsing Error: not well-formed
> Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
> Line Number 42622, Column 68:      
>       
> -------------------------------------------------------------------^
> 

Does this help? Did you have time to take a look at it? Other people
seem to be having the same problem..

-- Pasi



From skvidal at fedoraproject.org  Wed Oct  7 12:19:28 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 7 Oct 2009 08:19:28 -0400 (EDT)
Subject: preupgrade from f11 to rawhide broken? python traceback
In-Reply-To: <20091007095105.GS1434@reaktio.net>
References: <20090926161023.GZ31123@reaktio.net>
	
	<20091001195136.GN1434@reaktio.net>
	<20091007095105.GS1434@reaktio.net>
Message-ID: 



On Wed, 7 Oct 2009, Pasi K?rkk?inen wrote:

> On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi K?rkk?inen wrote:
>>>> Traceback (most recent call last):
>>>> File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in 
>>>>   pu.main(myrelease)
>>>> File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main
>>>>   self.generate_repo(cachedir, comps) # TODO: callback?
>>>> File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651,
>>>> in generate_repo
>>>>   misc.generate_repodata(dir,comps,callback)
>>>> File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in
>>>> generate_repodata
>>>>   generate_repodata(dir, comps, callback)
>>>> File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in
>>>> generate_repodata_f9
>>>>   mdgen.doRepoMetadata()
>>>> File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829,
>>>> in doRepoMetadata
>>>>   rp.getPrimary(complete_path, csum)
>>>> File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in
>>>> getPrimary
>>>>   self.repoid))
>>>> TypeError: Parsing primary.xml error: attributes construct error
>>>>
>>>>
>>>> Known problem? How to fix it?
>>>
>>> this is the second time I've seen this one - if you can find
>>> the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate
>>> seeing it.
>>>
>>
>> # ls /var/cache/yum
>> fedora  preupgrade  updates
>>
>> # cd /var/cache/yum
>>
>> # find -iname '*primary*'
>> ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite
>> ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite
>> ./preupgrade/.repodata/primary.xml.gz
>> ./preupgrade/.repodata/primary.xml.gz.sqlite
>> ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite
>>
>>
>> I put it available online here:
>> http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
>>
>> Firefox complains about it btw..
>>
>> XML Parsing Error: not well-formed
>> Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
>> Line Number 42622, Column 68:
>>       
>> -------------------------------------------------------------------^
>>
>
> Does this help? Did you have time to take a look at it? Other people
> seem to be having the same problem..
>

update to yum from f11-updates (3.2.24) and the problem goes away.

-sv

From kevin.kofler at chello.at  Wed Oct  7 12:33:16 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 07 Oct 2009 14:33:16 +0200
Subject: didn't see "md5 mismatch" error on today's Rawhide noarch
	packages
References: <4ACBF511.4040700@bwh.harvard.edu>
	<4ACC3696.5040802@fedoraproject.org>
Message-ID: 

Rahul Sundaram wrote:
> XZ upstream was informed of this problem and we have now inherited the
> fix.
> 
> ---
> 
> Wed Oct 07 2009 Jindrich Novy
> 4.999.9-0.1.20091007.beta
> - update to 4.999.9beta
> - sync with upstream to generate the same archives on machines with
> different
>   endianess
> ---

That fix is not tagged into the release yet.

The noarch packages which didn't generate the error just happened to be 
built on x86 (~50% probability).

        Kevin Kofler



From limb at jcomserv.net  Wed Oct  7 12:46:24 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 07 Oct 2009 07:46:24 -0500
Subject: olpc components in x86/x86_64 repo
In-Reply-To: 
References: 	<5256d0b0910060431v1a8ab431g94c862bda2de4c4d@mail.gmail.com>		<5256d0b0910060503m6d64caa2mbe8ca5af67489f97@mail.gmail.com>	<4ACB32A7.1080500@jcomserv.net>
	<4ACC3F55.7090508@fedoraproject.org>	<5256d0b0910070050n71153d0cm182f6cb72f9ea516@mail.gmail.com>
	
Message-ID: <4ACC8DA0.7010101@jcomserv.net>

Rudolf Kastl wrote:
> 2009/10/7 Peter Robinson :
>   
>> On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram
>>  wrote:
>>     
>>> On 10/06/2009 05:35 PM, Jon Ciesla wrote:
>>>
>>>       
>>>> Additionally, having OLPC-specific RPMS in mainline Fedora helps with
>>>> the end goal that is , as I understand it, to have OLPC's OS be
>>>> essentially a Spin of stock Fedora.  It also helps OLPC devs who don't
>>>> necessarily have XOs.
>>>>         
>>> IIRC, they already are shipping stock Fedora in their latest builds
>>> except for the kernel. They are also responsible for the largest amount
>>> of Fedora deployments in the world. So it is all mutually beneficial.
>>>       
>> That is correct, we're all upstream now with no weird branches for
>> core packages :-)
>>     
>
> Thats great to hear and interesting information. In no way the
> question was meant as criticism. Basically i was just curious if the
> packages are hardware related to the olpc hw or generally  useful.
> Thanks for your answer. Best wishes for the olpc/sugar developers.
> More knowledge and therefor power to the poor kids.
>
>   
 My thanks to all concerned.

> kind regards,
> Rudolf Kastl
>
>
>   
>> Peter
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>     
>
>   


-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie



From terry1 at beam.ltd.uk  Wed Oct  7 14:15:06 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Wed, 07 Oct 2009 15:15:06 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <4AC8B9CC.8050703@bitwagon.com>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com>
Message-ID: <4ACCA26A.7020808@beam.ltd.uk>

On 10/04/2009 04:05 PM, John Reiser wrote:
>> The title says it all. How about that? We really need it for old intel
>> h/w such as an i855 for example.
>
> Enumerate the reasons, please. Which _specific_ bugs or features have been
> improved elsewhere but not in F11? Why are they important to you and
> others?
>
The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
on any of my computers (5 different graphics hardware versions).

I have been using drm/mesa/xf86-video-ati code from GIT to get around this,
but now the XServer is out of date so it has got difficult.
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.

I understand that changing the Graphics system could break many
users systems, so maybe a build of all the necessary packages could be put
into the testing repository or perhaps a special graphics-testing repository
could be added. This would help get the graphics issues fixed prior to
F12's release ...

It would be good to have a Linux system that could actually to 3D with the
major applications by the end of 2009 !

Cheers


Terry



From rawhide at fedoraproject.org  Wed Oct  7 14:25:57 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 7 Oct 2009 14:25:57 +0000
Subject: rawhide report: 20091007 changes
Message-ID: <20091007142557.GA2297@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct  7 06:15:12 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package fped
        A footprint editor used by openmoko developers
New package geda-gaf
        Design Automation toolkit for electronic design
New package oflb-smonohand-fonts
        A handwritten monospace font
New package windowlab
        Small and Simple Amiga-like Window Manager
Updated Packages:

PackageKit-0.5.3-1.fc12
-----------------------
* Mon Oct 05 2009 Richard Hughes   - 0.5.3-1
- Update to 0.5.3.
- Fix double free in pk-gstreamer-install which causes a crash. Fixes #526600
- Exit pk-command-not-found with 127 when we have not run a program. Fixes #527044
- Fix crash in notification daemon under some conditions due to non-resident
  GTK module.
- Don't explicitly download the file lists when using pk-command-not-found

* Tue Sep 29 2009 Richard Hughes   - 0.5.3-0.2.20090928git
- Do not build smart support on RHEL.

* Mon Sep 28 2009 Richard Hughes   - 0.5.3-0.1.20090928git
- Update to a newer git snapshot from the 0.5.x series.
- Fixes command-not-found functionality
- Lots of updated translations
- Lots of updates and bugfixes to the experimental glib2 library


R-nws-2.0.0.3-1.fc12
--------------------
* Mon Oct 05 2009 Tom "spot" Callaway  - 2.0.0.3-1
- update to 2.0.0.3


Terminal-0.4.2-1.fc12
---------------------
* Tue Oct 06 2009 Christoph Wickert  - 0.4.2-1
- Update to 0.4.2
- Update icon cache scriptlets


asymptote-1.88-1.fc12
---------------------
* Mon Oct 05 2009 Tom "spot" Callaway  - 1.88-1
- update to 1.88


control-center-2.28.0-15.fc12
-----------------------------
* Tue Oct 06 2009 Matthias Clasen  2.28.0-15
- Fix a crash in the about-me capplet (#525590)


crypto-utils-2.4.1-24
---------------------
* Sun Oct 04 2009 Elio Maldonado - 2.4.1-24
- Retagging for a Fedora-12 build (#526720)

* Thu Oct 01 2009 Elio Maldonado - 2.4.1-23
- Fix genkey to produce CSRs, certs, and key in ascii PEM format (#526720)


digikam-1.0.0-0.7.beta5.fc12
----------------------------
* Tue Oct 06 2009 Rex Dieter  - 1.0.0-0.7.beta5
- digikam-1.0.0-beta5
- tweak marble deps (again)


dracut-002-12.git8f397a9b.fc12
------------------------------
* Tue Oct 06 2009 Harald Hoyer  002-12
- add missing loginit helper
- corrected dracut manpage


gdm-2.28.0-6.fc12
-----------------
* Mon Oct 05 2009 Matthias Clasen  - 1:2.28.4-6
- Fix the autostart file for at-spi-registryd

* Thu Oct 01 2009 Matthias Clasen  - 1:2.28.4-5
- Handle keyboard layout variants


gnome-utils-2.28.0-2.fc12
-------------------------
* Mon Oct 05 2009 Matthias Clasen  - 1:2.28.0-2
- Move the usermode dep to the gnome-system-log package (#527295)


gtk2-2.18.2-1.fc12
------------------
* Mon Oct 05 2009 Matthias Clasen  - 2.18.2-1
- Update to 2.18.2


hyphen-kn-0.20090924-1.fc12
---------------------------
* Thu Sep 24 2009 Parag  - 0.20090924-1
- update to 20090924


hyphen-pa-0.20090924-1.fc12
---------------------------
* Thu Sep 24 2009 Parag  - 0.20090924-1
- update to 20090924


libbonobo-2.24.2-2.fc12
-----------------------
* Tue Oct 06 2009 Matthias Clasen  - 2.24.2-2
- Fix a use-after-free in the mime code


libburn-0.7.0-1.fc12
--------------------
* Wed Sep 30 2009 Denis Leroy  - 0.7.0-1
- Update to upstream 0.7.0
- Fixed binary installation
- Removed rpath


libvirt-0.7.1-10.fc12
---------------------
* Tue Oct 06 2009 Mark McLoughlin  - 0.7.1-9
- Change logrotate config to weekly (#526769)

* Tue Oct 06 2009 Mark McLoughlin  - 0.7.1-10
- Create /var/log/libvirt/{lxc,uml} dirs for logrotate
- Make libvirt-python dependon on libvirt-client
- Sync misc minor changes from upstream spec


ltsp-5.1.91-1.fc12
------------------
* Tue Oct 06 2009 Warren Togami  - 5.1.91-1
- 5.1.91 fixes install of chroots


nss-3.12.4-14.fc12
------------------
* Tue Oct 06 2009 Elio Maldonado - 3.12.4-14
- Fix bug where user was prompted for a password when listing keys on an empty system database (#527048)
- Fix setup-nsssysinit to handle more general flags formats (#527051)


nwsclient-1.6.4-1.fc12
----------------------
* Mon Oct 05 2009 Tom "spot" Callaway  - 1.6.4-1
- update to 1.6.4


nwsserver-2.0.0-1.fc12
----------------------
* Mon Oct 05 2009 Tom "spot" Callaway  2.0.0-1
- update to 2.0.0


plymouth-0.8.0-0.2009.29.09.3.fc12
----------------------------------
* Mon Oct 05 2009 Ray Strode  0.8.0-0.2009.29.09.2
- Fix --show-splash after --hide-splash (bug 527299)

* Mon Oct 05 2009 Ray Strode  0.8.0-0.2009.29.09.3
- Fix crasher in text plugin after password prompt (bug 526652)
- Actually apply the patch mentioned in 2009.29.09.2


qemu-0.11.0-4.fc12
------------------
* Mon Oct 05 2009 Mark McLoughlin  - 2:0.11.0-4
- Use rtl8029 PXE rom for ne2k_pci, not ne (#526777)
- Also, replace the gpxe-roms-qemu pkg requires with file-based requires


readahead-1.5.3-1.fc12
----------------------
* Tue Oct 06 2009 Harald Hoyer  1.5.3-1
- fix readhead for new libaudit (bug #523400)
- don't leak file descriptors (bug #525893)
- also collect openat() calls
- ignore files > 10MB


rhythmbox-0.12.5-4.fc12
-----------------------
* Tue Oct 06 2009 Matthias Clasen  0.12.5-4
- Make burning with brasero actually work, somewhat


shared-mime-info-0.70-1.fc12
----------------------------
* Tue Oct 06 2009 Bastien Nocera  0.70-1
- Update to 0.70


toped-0.9.5-1.fc12
------------------
* Sat Oct 03 2009 Chitlesh Goorah  - 0.9.5-0.1
- 0.9.5 test release

* Sat Oct 03 2009 Chitlesh Goorah  - 0.9.5-1
- 0.9.5 stable release


totem-2.28.1-2.fc12
-------------------
* Tue Oct 06 2009 Matthias Clasen  - 2.28.1-2
- Make video burning work again


xorg-x11-drv-ati-6.13.0-0.7.20091006git457646d73.fc12
-----------------------------------------------------
* Tue Oct 06 2009 Dave Airlie  6.13.0-0.7.20091006git457646d73
- resnapshot with VT switch fixes and mixed issue was in server which is fixed


xorg-x11-drv-intel-2.9.0-2.fc12
-------------------------------
* Thu Oct 01 2009 Kristian H?gsberg  - 2.9.0-2
- Rebase to 2.9.0.
- Need autoreconf also when patching a release (to pick up -ludev)


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 29



From bruno at wolff.to  Wed Oct  7 14:41:26 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 7 Oct 2009 09:41:26 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACCA26A.7020808@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
Message-ID: <20091007144126.GA15465@wolff.to>

On Wed, Oct 07, 2009 at 15:15:06 +0100,
  Terry Barnaby  wrote:
> The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
> ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
> on any of my computers (5 different graphics hardware versions).

3d seems to be working better on ATI r530 very recently. (I was finally able
to get glest to run.)
I am upgrading my last F11 machine now to try to get working 3d on my
ATI rv280 even though it will mean a hassle to try to get dahdi-linux
working. The yum update just started, so I might not have the answer
to whether or not 3d is working on that card until tomorrow, but I'll
followup when it is done to indicate whether or not it worked.
I'd really like to be able to test glest without needing a proprietary
driver. (I have some other scrounged machines that have nvidia cards, but
am using them for rawhide testing (including nouveau) and don't want to
mess them up by installing the nvidia drivers.



From jwboyer at gmail.com  Wed Oct  7 14:44:10 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 7 Oct 2009 10:44:10 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACCA26A.7020808@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
Message-ID: <20091007144410.GA30884@hansolo.jdub.homelinux.org>

On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
> A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
> new 1.7 XServer and 7.6 mesa would be very useful.

No, not really.

> I understand that changing the Graphics system could break many
> users systems, so maybe a build of all the necessary packages could be put
> into the testing repository or perhaps a special graphics-testing repository
> could be added. This would help get the graphics issues fixed prior to
> F12's release ...

Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
get the graphics issues fixed prior to F-12 release.  That is going to help
much more than wasting the developer's time trying to backport everything to
F-11, pushing it to updates-testing, and dealing with all the fallout.

> It would be good to have a Linux system that could actually to 3D with the
> major applications by the end of 2009 !

Fortunately, F-12 is scheduled for release by then!

josh



From notting at redhat.com  Wed Oct  7 15:29:11 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 7 Oct 2009 11:29:11 -0400
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007092550.GA24906@amd.home.annexia.org>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
Message-ID: <20091007152910.GC2250@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> > This is going to be pretty important for scientific workloads where
> > atlas is going to be used. I've eavesdropped on several conversations
> > where people were talking about being able to run off-the-shelf
> > science code virtual appliance in order to reduce the environment
> > configuration workload for an individual researcher.
> 
> Yup.  The really fun starts when you do live migration.  The processor
> literally changes underneath the running programs.  If you thought you
> had SSE3 one minute, then the next you don't, or vice versa.
> 
> No one has to my knowledge come up with a good way to deal with this.
> But it probably involves signalling the kernel and processes so that
> they can redo processor detection.  You can see why that is not going
> to be pleasant.

Surely the way to do this is to know what your workload is doing,
and not do live migration to random hardware? 

Bill



From kevin at scrye.com  Wed Oct  7 15:52:31 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 7 Oct 2009 09:52:31 -0600
Subject: Distro Summit 2010: call for papers extended until 18 Oct 2009
Message-ID: <20091007095231.49b8541c@ohm.scrye.com>

Forwarding this to the list for Martin, who isn't subscribed. 

Please reply to him, not me with any comments. 

kevin

From: martin f krafft 
To: fedora-devel-list at redhat.com
Subject: Distro Summit 2010: call for papers extended until 18 Oct 2009
Date: Wed, 07 Oct 2009 12:05:05 +0200
Reply-To: cfp at distrosummit.org

Please redistribute this call for papers.

The deadline has been extended to 18 Oct 2009.

===============
CALL FOR PAPERS
===============

Distro Summit 2010 is a one-day technical conference with a strong focus on
collaboration between Free Software distributions hosted at the linux.conf.au
2010.

We are looking for proposals from any Free Software distribution, from the
typical full distributions (both linux and non-linux) to the niche market
derivatives.

In spite of the strong focus on collaboration between Free Software
distributions, topics may include packaging, maintenance, relationship with
upstream developers, release management and QA.

For more informtion, please visit: http://distrosummit.org.


Important dates
===============

 * Call for papers ends: Wednesday 18 October 2009
 * Announcing the schedule: Friday 2 October 2009
 * Conference begins: Monday 18 January 2010


Presentation types
==================

We will accept proposals for:

 * 25 minute standard-length presentations;
 * 50 minute long presentations.

Session lengths include time for audience questions.

We intend for standard-length presentation to make up the vast majority of our
presentations. If you plan on submitting a proposal for a long presentation, a
willingness to present a standard-length presentation will impact positively on
your proposal.


Submit a proposal
=================

To submit your proposal, we'll need the following information:

 * Your name, contact details and a short biography;
 * Your proposal title;
 * Intended audience;
 * An abstract;
 * Presentation outline;
 * Presentation type (standard-length or long).

To submit a proposal, or get more information, please write to
cfp at distrosummit.org.

Unfortunately, we cannot offer sponsorship for speakers.


About the Distro Summit
=======================

The Distro Summit 2010 is a one-day developer conference with a strong focus on
collaboration between free software distributions hosted at the linux.conf.au
2010 (http://www.lca2010.org.nz). In addition to a schedule of technical,
social and policy talks, the Distro Summit provides an opportunity for
developers, contributors and other interested people to meet in person and work
together more closely.

Previous similar events have featured speakers from around the world. They have
also been extremely beneficial for developing key free software software
components and for improving collaboration and sharing between the different
distributions.


Target Audience
===============

The Distro Summit is (mainly) a technical event, but this does not mean that
the only target audience are developers and maintainers of free software
distributions: the event will feature talks that range from the development to
real-world use cases, going through marketing and the social aspects of the
maintenance of free software distributions.

-- 
Martin Krafft
on the behalf of the Distro Summit organizers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

From rjones at redhat.com  Wed Oct  7 16:13:15 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 7 Oct 2009 17:13:15 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007152910.GC2250@nostromo.devel.redhat.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
Message-ID: <20091007161315.GA27685@amd.home.annexia.org>

On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > Yup.  The really fun starts when you do live migration.  The processor
> > literally changes underneath the running programs.  If you thought you
> > had SSE3 one minute, then the next you don't, or vice versa.
> > 
> > No one has to my knowledge come up with a good way to deal with this.
> > But it probably involves signalling the kernel and processes so that
> > they can redo processor detection.  You can see why that is not going
> > to be pleasant.
> 
> Surely the way to do this is to know what your workload is doing,
> and not do live migration to random hardware? 

But we're talking -- in this very thread -- about the case where core
programs are starting to use SIMD instructions.  This is only going to
get more common because the only way to use a large proportion of the
compute power of modern processors is to use these instructions.

And in any case, the kernel is using them for checksumming and so on,
even if you can be absolutely sure your workload isn't.

As I said in my earier reply:

> > However that reduces the utility of the hardware and makes system
> > administration more complex.

OR we can use all the power of modern hardware and make system
administration easier.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From jspaleta at gmail.com  Wed Oct  7 16:21:12 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 7 Oct 2009 08:21:12 -0800
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007152910.GC2250@nostromo.devel.redhat.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
Message-ID: <604aa7910910070921p7bccf16eh6c88035cf18c2e74@mail.gmail.com>

On Wed, Oct 7, 2009 at 7:29 AM, Bill Nottingham  wrote:
> Surely the way to do this is to know what your workload is doing,
> and not do live migration to random hardware?

I think random hardware is going to be exactly what you will see a lot
of scientific research appliances being thrown at.  There are groups
interested in offering off the shelf appliances for some complex
computational codes meant to be run on private/academic/national lab
infrastructure to make it easier for scientific users to run the codes
correctly.  It's pretty pedantic stuff, and you can really screw up
the build configuration when you are trying to build your own
instances (DYI kernel compiles can be refreshingly less complicated
sometimes)  Live migrating appliances across those boundaries will
undoubtedly be desired.  National Lab run "clouds" are going to be
well defined hardware targets.... but academic clouds are going to be
all over the place.

-jef



From berrange at redhat.com  Wed Oct  7 16:29:13 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 7 Oct 2009 17:29:13 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007152910.GC2250@nostromo.devel.redhat.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
Message-ID: <20091007162913.GG32099@redhat.com>

On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > > This is going to be pretty important for scientific workloads where
> > > atlas is going to be used. I've eavesdropped on several conversations
> > > where people were talking about being able to run off-the-shelf
> > > science code virtual appliance in order to reduce the environment
> > > configuration workload for an individual researcher.
> > 
> > Yup.  The really fun starts when you do live migration.  The processor
> > literally changes underneath the running programs.  If you thought you
> > had SSE3 one minute, then the next you don't, or vice versa.
> > 
> > No one has to my knowledge come up with a good way to deal with this.
> > But it probably involves signalling the kernel and processes so that
> > they can redo processor detection.  You can see why that is not going
> > to be pleasant.
> 
> Surely the way to do this is to know what your workload is doing,
> and not do live migration to random hardware? 

Or just apply a CPUID mask to the guest, so it sees a constant set of
features no matter where its migrated to. This is what Xen, VMWare,
QEMU/KVM all do for this problem.  Trying to make the guest re-detect,
while nice in theory, is just not something people are going to bother
doing - witness the death of pure paravirt, since fullyvirt is 'good
enough' for most people - the same is true of CPUID masking to make
hardware appear homogeneous


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From fedora at camperquake.de  Wed Oct  7 16:40:38 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 7 Oct 2009 18:40:38 +0200
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007152910.GC2250@nostromo.devel.redhat.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
Message-ID: <20091007184038.2560fed2@fred.camperquake.de>

Hi.

On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote

> Surely the way to do this is to know what your workload is doing,
> and not do live migration to random hardware? 

Redetection of CPU features in a live system is complete madness.
The virt-infrastructure has to make sure that the system migrated to
has a superset of features of the machine migrated from.



From pbrobinson at gmail.com  Wed Oct  7 16:52:25 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 7 Oct 2009 17:52:25 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007152910.GC2250@nostromo.devel.redhat.com>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
Message-ID: <5256d0b0910070952h66f14bf1o86d6cdc4f3c0d282@mail.gmail.com>

On Wed, Oct 7, 2009 at 4:29 PM, Bill Nottingham  wrote:
> Richard W.M. Jones (rjones at redhat.com) said:
>> > This is going to be pretty important for scientific workloads where
>> > atlas is going to be used. I've eavesdropped on several conversations
>> > where people were talking about being able to run off-the-shelf
>> > science code virtual appliance in order to reduce the environment
>> > configuration workload for an individual researcher.
>>
>> Yup. ?The really fun starts when you do live migration. ?The processor
>> literally changes underneath the running programs. ?If you thought you
>> had SSE3 one minute, then the next you don't, or vice versa.
>>
>> No one has to my knowledge come up with a good way to deal with this.
>> But it probably involves signalling the kernel and processes so that
>> they can redo processor detection. ?You can see why that is not going
>> to be pleasant.
>
> Surely the way to do this is to know what your workload is doing,
> and not do live migration to random hardware?

In fact the proper way to do this it to have the same hardware in the
group of servers that VMs might be live migrated between so that its
not an issue. Then the only time this would then come into play is
when you are upgrading the group/cluster of machines to newer hardware
and that shouldn't be an issue as the newer hardware should have more
features in the CPU and not less. This is the way we do it in the
Enterprise hosting company that I work for which has a VM environment
over around 250 hosts runninng around 2500 VMs. We have a few
disparate clusters with different devices using different HW but in
that case we use the CPU masking features of the main proprietary
product that is in use in that particular case.

Cheers,
Peter



From lyos.gemininorezel at gmail.com  Wed Oct  7 17:49:49 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 13:49:49 -0400
Subject: Retiring ksensors, possibly id3lib as well?
Message-ID: <4ACCD4BD.1070507@gmail.com>

Greetings all...

I believe the time has come to retire ksensors.

The last update/release was 18/08/2004, and it appears upstream has been
defunct since at least that time.

Unless there are objections voiced and/or a maintainer steps forward before
Oct 9 (Friday), I will go ahead and retire this package.



id3lib also needs to be looked at, as it's upstream has been defunct 
since March 2 2003.

This one might hurt more than ksensors will, since several programs 
depend on id3lib.

This is a list of the programs that require id3lib:
audio-convert-mod
easytag
tagtool
id3lib-devel
id3v2
gmediaserver
liblicense-modules
kid3
grip

The list is alot shorter than I thought it would be, but it's still 
enough to cause problems.

Is there anyone willing to take up upstream development of id3lib?
Is there a possible (more active) replacement for id3lib?
Is there a valid reason for continuing to carry such a defunct package 
in Fedora?

I'm more than happy to continue maintaining id3lib if there is a valid 
reason to do so,
but my reasons are more sentimental than valid logical reasoning.

So I turn to you to answer that question:
Is there valid, logical, reasoning to continue to support such old code?


Lyos Gemini Norezel



From rjones at redhat.com  Wed Oct  7 18:10:28 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 7 Oct 2009 19:10:28 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007184038.2560fed2@fred.camperquake.de>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
	<20091007184038.2560fed2@fred.camperquake.de>
Message-ID: <20091007181028.GA28871@amd.home.annexia.org>

On Wed, Oct 07, 2009 at 06:40:38PM +0200, Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote
> 
> > Surely the way to do this is to know what your workload is doing,
> > and not do live migration to random hardware? 
> 
> Redetection of CPU features in a live system is complete madness.
> The virt-infrastructure has to make sure that the system migrated to
> has a superset of features of the machine migrated from.

Difficult, surely.  Madness, possibly.

I really meant from this thread that these are a list of things that
Linux distros should keep in mind.

If it's possible to build distro packages so that detection happens at
boot time, instead of installing hardware-specific packages, then
please try to use the boot-time method.

If it's possible to detect hardware availability when a program starts
up, rather than hard-coding it into the binary, please use that
method.

If it's possible to write programs and shared library loaders so that
redetection can be performed mid-execution, then prefer that method
over one which only detects hardware when the program starts up.

http://rwmj.wordpress.com/2009/10/06/what-things-make-p2vv2v-conversion-hard/

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From rrelyea at redhat.com  Wed Oct  7 18:10:51 2009
From: rrelyea at redhat.com (Robert Relyea)
Date: Wed, 07 Oct 2009 11:10:51 -0700
Subject: crypto consolidation status?
In-Reply-To: <43f35d30909282227h37cfdc92u3645db13f62335e9@mail.gmail.com>
References: <43f35d30909262244l6433669foc7ef9f9f20edc846@mail.gmail.com>	<4AC134D1.9080404@REDHAT.COM>
	<43f35d30909282227h37cfdc92u3645db13f62335e9@mail.gmail.com>
Message-ID: <4ACCD9AB.2020001@REDHAT.COM>

On 09/28/2009 10:27 PM, Ken Dreyer wrote:
> On Mon, Sep 28, 2009 at 4:12 PM, Robert Relyea  wrote:
>   
>> Currently there are also a half dozen features in mod_nss that aren't in
>> mod_ssl.  SNI is definately something that would be welcomed in NSS, and
>> would probably be implemented by the NSS team itself if it's not
>> contributed first;), particularly if it got added to the list of
>> impediments.
>>     
> How does one add to this impediments list? I wasn't sure from the wiki page.
>   
Basically it's bug tracking. Which bugs get pushed depends on how many
packages are affected and
the 'importance' of the package (and the missing feature).

bob
> It is not just the scorecard that's unclear - it was also confusing to
> see Apache marked as "Done (mod_nss ) ".[1] If that's true, what do
> all of these open httpd/apr bugs ([2],[3],[4],[5]) mean?
No, it means the mod_nss has been ported. These fixes are relatively
high on the list, but not yet at the top.

bob
>  On a related
> note, Joe didn't seem too enthusiastic about PHP, either [6].
>
> - Ken
>
> [1] https://fedoraproject.org/wiki/FedoraCryptoConsolidation
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=347181
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=347601
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=346541
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=346551
> [6] https://bugzilla.redhat.com/show_bug.cgi?id=347911
>
>   


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: 

From fedora at camperquake.de  Wed Oct  7 18:19:07 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 7 Oct 2009 20:19:07 +0200
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007181028.GA28871@amd.home.annexia.org>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
	<20091007184038.2560fed2@fred.camperquake.de>
	<20091007181028.GA28871@amd.home.annexia.org>
Message-ID: <20091007201907.3318fb55@fred.camperquake.de>

Hi.

On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote

> If it's possible to write programs and shared library loaders so that
> redetection can be performed mid-execution, then prefer that method
> over one which only detects hardware when the program starts up.

I have no qualms whatsoever with hardware changing between boots.
Network cards, hard disks, CPU features, you name it. But having
CPU features change from one instruction to the other (which the 
above would suggest, correct me if I'm wrong)... how do you suggest
this would work? Testing for the feature before using it (every time?
That should nullify any speedup gained by using the features in
the first place) does not work, because the machine may move between
the test and the instruction (maybe there's a way around this).

Catching SIGILL? What about the data that was in the registers that
are suddenly no longer there?

And it's not only userspace, the kernel can use SSE, too (at least it did,
once, for RAID checksumming at least).



From ajax at redhat.com  Wed Oct  7 18:26:06 2009
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 07 Oct 2009 14:26:06 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <20091007144410.GA30884@hansolo.jdub.homelinux.org>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
Message-ID: <1254939966.11711.555.camel@atropine.boston.devel.redhat.com>

On Wed, 2009-10-07 at 10:44 -0400, Josh Boyer wrote:
> On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
> > A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
> > new 1.7 XServer and 7.6 mesa would be very useful.
> 
> No, not really.
> 
> > I understand that changing the Graphics system could break many
> > users systems, so maybe a build of all the necessary packages could be put
> > into the testing repository or perhaps a special graphics-testing repository
> > could be added. This would help get the graphics issues fixed prior to
> > F12's release ...
> 
> Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
> get the graphics issues fixed prior to F-12 release.  That is going to help
> much more than wasting the developer's time trying to backport everything to
> F-11, pushing it to updates-testing, and dealing with all the fallout.

In fact, the major reason for not backporting the intel driver to F11 is
that it requires a bunch of kernel changes that no one really has time
for.  Among other things, 830 through 865 require GEM in the intel 2.9,
which we have disabled for the F11 kernel for those chips because (as
shipped) it's utterly broken.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From rjones at redhat.com  Wed Oct  7 18:44:45 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 7 Oct 2009 19:44:45 +0100
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <20091007201907.3318fb55@fred.camperquake.de>
References: 
	<20091006223437.GA21973@amd.home.annexia.org>
	<604aa7910910061605x6014e847h52a39678ff974193@mail.gmail.com>
	<20091007092550.GA24906@amd.home.annexia.org>
	<20091007152910.GC2250@nostromo.devel.redhat.com>
	<20091007184038.2560fed2@fred.camperquake.de>
	<20091007181028.GA28871@amd.home.annexia.org>
	<20091007201907.3318fb55@fred.camperquake.de>
Message-ID: <20091007182325.GA29015@amd.home.annexia.org>

On Wed, Oct 07, 2009 at 08:19:07PM +0200, Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote
> 
> > If it's possible to write programs and shared library loaders so that
> > redetection can be performed mid-execution, then prefer that method
> > over one which only detects hardware when the program starts up.
> 
> I have no qualms whatsoever with hardware changing between boots.
> Network cards, hard disks, CPU features, you name it. But having
> CPU features change from one instruction to the other (which the 
> above would suggest, correct me if I'm wrong)... how do you suggest
> this would work? Testing for the feature before using it (every time?
> That should nullify any speedup gained by using the features in
> the first place) does not work, because the machine may move between
> the test and the instruction (maybe there's a way around this).

I didn't say I had a way to do it, but in my earlier post I said
perhaps one could send a special migration signal to the process.
I've honestly no idea if that would work.


https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00305.html

No one has to my knowledge come up with a good way to deal with this.
But it probably involves signalling the kernel and processes so that
they can redo processor detection.  You can see why that is not going
to be pleasant.


Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From bjorn at xn--rombobjrn-67a.se  Wed Oct  7 19:19:43 2009
From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=)
Date: Wed, 7 Oct 2009 21:19:43 +0200
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCD4BD.1070507@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
Message-ID: <200910072119.56781.bjorn@xn--rombobjrn-67a.se>

Lyos Gemini Norezel wrote:
> Is there valid, logical, reasoning to continue to support such old code?

Are there any bugs that are so severe that we can't continue using the 
software? If not: Why throw out working software just because it's old?

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: 

From sandeen at redhat.com  Wed Oct  7 19:25:00 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 07 Oct 2009 14:25:00 -0500
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCD4BD.1070507@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
Message-ID: <4ACCEB0C.9030800@redhat.com>

Lyos Gemini Norezel wrote:

...

> id3lib also needs to be looked at, as it's upstream has been defunct 
> since March 2 2003.
> 
> This one might hurt more than ksensors will, since several programs 
> depend on id3lib.
> 
> This is a list of the programs that require id3lib:
> audio-convert-mod
> easytag
> tagtool
> id3lib-devel
> id3v2
> gmediaserver
> liblicense-modules
> kid3
> grip
> 
> The list is alot shorter than I thought it would be, but it's still 
> enough to cause problems.
> 
> Is there anyone willing to take up upstream development of id3lib?
> Is there a possible (more active) replacement for id3lib?
> Is there a valid reason for continuing to carry such a defunct package 
> in Fedora?

s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see 
your list of packages above ;)

> I'm more than happy to continue maintaining id3lib if there is a valid 
> reason to do so,
> but my reasons are more sentimental than valid logical reasoning.
> 
> So I turn to you to answer that question:
> Is there valid, logical, reasoning to continue to support such old code?

Yes, because other useful packages depend on it IMHO.

I'll take it if you don't want to keep it, I think that library needs to 
live on in Fedora.

-Eric



From bjorn at xn--rombobjrn-67a.se  Wed Oct  7 19:35:11 2009
From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=)
Date: Wed, 7 Oct 2009 21:35:11 +0200
Subject: Opinions on packaging ATLAS (for the x86 architecture)
In-Reply-To: <5256d0b0910070952h66f14bf1o86d6cdc4f3c0d282@mail.gmail.com>
References: 
	<20091007152910.GC2250@nostromo.devel.redhat.com>
	<5256d0b0910070952h66f14bf1o86d6cdc4f3c0d282@mail.gmail.com>
Message-ID: <200910072135.11160.bjorn@xn--rombobjrn-67a.se>

Peter Robinson wrote:
> In fact the proper way to do this it to have the same hardware in the
> group of servers that VMs might be live migrated between so that its
> not an issue. Then the only time this would then come into play is
> when you are upgrading the group/cluster of machines to newer hardware
> and that shouldn't be an issue as the newer hardware should have more
> features in the CPU and not less.

Unless you upgrade from old PowerPC Macs to new Intel Macs. :-)

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: 

From kwhiskerz at gmail.com  Wed Oct  7 19:37:32 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Wed, 07 Oct 2009 13:37:32 -0600
Subject: Retiring ksensors, possibly id3lib as well?
References: <4ACCD4BD.1070507@gmail.com>
Message-ID: 

Lyos Gemini Norezel wrote:

> I believe the time has come to retire ksensors.

ksensors never sensed anything

it is an old kde3 program that has been superseded by a 
nice kde4 system monitor plasmoid

keeping kde3 programs that aren't absolutely essential, 
for which a kde4 program already exists, is very 
confusing and causes for things not to work




From awilliam at redhat.com  Wed Oct  7 19:38:17 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 07 Oct 2009 12:38:17 -0700
Subject: Interesting post on future RPM changes
Message-ID: <1254944298.2291.60.camel@adam.local.net>

Hope I'm not pre-empting Seth or anyone here, but I thought it worth
pointing out a very interesting blog post on planned future changes to
RPM:

http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/

it lists several changes that were agreed in principle at a conference
between several Novell and Red Hat people. There's some stuff in there
which looks like it will likely lead to changes in Fedora packaging
policies once it's implemented, so if you want to get ahead of the
future it's a useful read =)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From skvidal at fedoraproject.org  Wed Oct  7 19:40:25 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 7 Oct 2009 15:40:25 -0400 (EDT)
Subject: Interesting post on future RPM changes
In-Reply-To: <1254944298.2291.60.camel@adam.local.net>
References: <1254944298.2291.60.camel@adam.local.net>
Message-ID: 



On Wed, 7 Oct 2009, Adam Williamson wrote:

> Hope I'm not pre-empting Seth or anyone here, but I thought it worth
> pointing out a very interesting blog post on planned future changes to
> RPM:
>
> http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/
>
> it lists several changes that were agreed in principle at a conference
> between several Novell and Red Hat people. There's some stuff in there
> which looks like it will likely lead to changes in Fedora packaging
> policies once it's implemented, so if you want to get ahead of the
> future it's a useful read =)

Pre-empting me for what? Nothing there is implemented as yet and I suspect 
it is not going to be implemented tomorrow.

When it is likely to land in rpm it'll come up. Until then it's just 
potential.

-sv



From awilliam at redhat.com  Wed Oct  7 19:53:46 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 07 Oct 2009 12:53:46 -0700
Subject: Interesting post on future RPM changes
In-Reply-To: 
References: <1254944298.2291.60.camel@adam.local.net>
	
Message-ID: <1254945226.2291.61.camel@adam.local.net>

On Wed, 2009-10-07 at 15:40 -0400, Seth Vidal wrote:
> 
> On Wed, 7 Oct 2009, Adam Williamson wrote:
> 
> > Hope I'm not pre-empting Seth or anyone here, but I thought it worth
> > pointing out a very interesting blog post on planned future changes to
> > RPM:
> >
> > http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/
> >
> > it lists several changes that were agreed in principle at a conference
> > between several Novell and Red Hat people. There's some stuff in there
> > which looks like it will likely lead to changes in Fedora packaging
> > policies once it's implemented, so if you want to get ahead of the
> > future it's a useful read =)
> 
> Pre-empting me for what? Nothing there is implemented as yet and I suspect 
> it is not going to be implemented tomorrow.

Pre-empting you talking about it is all I meant.

> When it is likely to land in rpm it'll come up. Until then it's just 
> potential.

Understood - as I said I just found it interesting from a 'what's
(possibly) coming down the pipe in future' perspective, that's all.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From lyos.gemininorezel at gmail.com  Wed Oct  7 19:55:10 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 15:55:10 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <200910072119.56781.bjorn@xn--rombobjrn-67a.se>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
Message-ID: <4ACCF21E.5070201@gmail.com>

On 10/07/2009 03:19 PM, Bj?rn Persson wrote:
> Lyos Gemini Norezel wrote:
>    
>> Is there valid, logical, reasoning to continue to support such old code?
>>      
> Are there any bugs that are so severe that we can't continue using the
> software?

No, actually.

Surprisingly enough... there are no current bugs open against id3lib.

>   If not: Why throw out working software just because it's old?
>    

Don't security risks grow exponentially as software 'bit rots'?

> Bj?rn Persson
>    

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From lyos.gemininorezel at gmail.com  Wed Oct  7 20:03:09 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 16:03:09 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCEB0C.9030800@redhat.com>
References: <4ACCD4BD.1070507@gmail.com> <4ACCEB0C.9030800@redhat.com>
Message-ID: <4ACCF3FD.8050802@gmail.com>

On 10/07/2009 03:25 PM, Eric Sandeen wrote:
> Lyos Gemini Norezel wrote:
>
> ...
>
>> id3lib also needs to be looked at, as it's upstream has been defunct 
>> since March 2 2003.
>>
>> This one might hurt more than ksensors will, since several programs 
>> depend on id3lib.
>>
>> This is a list of the programs that require id3lib:
>> audio-convert-mod
>> easytag
>> tagtool
>> id3lib-devel
>> id3v2
>> gmediaserver
>> liblicense-modules
>> kid3
>> grip
>>
>> The list is alot shorter than I thought it would be, but it's still 
>> enough to cause problems.
>>
>> Is there anyone willing to take up upstream development of id3lib?
>> Is there a possible (more active) replacement for id3lib?
>> Is there a valid reason for continuing to carry such a defunct 
>> package in Fedora?
>
> s/defunct/old/ - and yes there is a valid reason - 8 or so at least, 
> see your list of packages above ;)

Heh... sure, but surely such software could be made to work with a piece 
of code that's more recent
than id3lib?


>
>> I'm more than happy to continue maintaining id3lib if there is a 
>> valid reason to do so,
>> but my reasons are more sentimental than valid logical reasoning.
>>
>> So I turn to you to answer that question:
>> Is there valid, logical, reasoning to continue to support such old code?
>
> Yes, because other useful packages depend on it IMHO.
>
> I'll take it if you don't want to keep it, I think that library needs 
> to live on in Fedora.
>

I'm happy to maintain it... though I could definitely use a coder as a 
co-maintainer, or,
really, anyone who wishes to help.

The problem I have with continuing such code, is both the lack of an 
upstream...
and the potential for security risks as this piece of code is left to rot.

I have neither the skills, nor the time to take over upstream, and 
software cannot
last/stay compatible forever.

> -Eric
>

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From cemeyer at u.washington.edu  Wed Oct  7 20:04:35 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Wed, 7 Oct 2009 13:04:35 -0700
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCF21E.5070201@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>
Message-ID: <200910071304.35955.cemeyer@u.washington.edu>

On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote:
> On 10/07/2009 03:19 PM, Bj?rn Persson wrote:
> > Lyos Gemini Norezel wrote:
> >> Is there valid, logical, reasoning to continue to support such old code?
> >
> > Are there any bugs that are so severe that we can't continue using the
> > software?
> 
> No, actually.
> 
> Surprisingly enough... there are no current bugs open against id3lib.
> 
> >   If not: Why throw out working software just because it's old?
> 
> Don't security risks grow exponentially as software 'bit rots'?

Is it possible that id3lib is 'complete'? The id3 format isn't extremely 
complicated, it may just be a completely finished library. (Keep in mind, 
though, that I'm not familiar with the code.)

As far as being a security risk... it's not a network daemon, and there's no 
reason it should have suid root or anything like that. I imagine the worst you 
could do is throw a malformed media file at it.

Regards,
-- 
Conrad Meyer 



From lyos.gemininorezel at gmail.com  Wed Oct  7 20:07:44 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 16:07:44 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: 
References: <4ACCD4BD.1070507@gmail.com> 
Message-ID: <4ACCF510.8090707@gmail.com>

On 10/07/2009 03:37 PM, Petrus de Calguarium wrote:
> Lyos Gemini Norezel wrote:
>
>    
>> I believe the time has come to retire ksensors.
>>      
> ksensors never sensed anything
>
> it is an old kde3 program that has been superseded by a
> nice kde4 system monitor plasmoid
>
> keeping kde3 programs that aren't absolutely essential,
> for which a kde4 program already exists, is very
> confusing and causes for things not to work
>    

LOL... I find it to still be fully functional on the rare occasions
I actually fire it up . Of course... I actually use gnome ;-) .

At any rate, since it has been 'superseded', as you say, I'm going to
guess there's not going to be any objection to retiring ksensors.

Never-the-less, I will wait until Friday, like I said, to actually 
retire it.

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From lyos.gemininorezel at gmail.com  Wed Oct  7 20:29:24 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 16:29:24 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <200910071304.35955.cemeyer@u.washington.edu>
References: <4ACCD4BD.1070507@gmail.com>	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>	<4ACCF21E.5070201@gmail.com>
	<200910071304.35955.cemeyer@u.washington.edu>
Message-ID: <4ACCFA24.8080300@gmail.com>

On 10/07/2009 04:04 PM, Conrad Meyer wrote:
> Is it possible that id3lib is 'complete'? The id3 format isn't extremely
> complicated, it may just be a completely finished library. (Keep in mind,
> though, that I'm not familiar with the code.)
>    

I suppose it's possible, but even 'finished' software should have bug fixes
and compatibility updates.

> As far as being a security risk... it's not a network daemon, and there's no
> reason it should have suid root or anything like that. I imagine the worst you
> could do is throw a malformed media file at it.
>
>    

LOL... makes sense.


> Regards,
>    

Lyos Gemini Norezel



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From sandeen at redhat.com  Wed Oct  7 20:39:13 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 07 Oct 2009 15:39:13 -0500
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCF3FD.8050802@gmail.com>
References: <4ACCD4BD.1070507@gmail.com> <4ACCEB0C.9030800@redhat.com>
	<4ACCF3FD.8050802@gmail.com>
Message-ID: <4ACCFC71.40806@redhat.com>

Lyos Gemini Norezel wrote:
> On 10/07/2009 03:25 PM, Eric Sandeen wrote:
>> Lyos Gemini Norezel wrote:
...

>>> Is there a valid reason for continuing to carry such a defunct 
>>> package in Fedora?
>>
>> s/defunct/old/ - and yes there is a valid reason - 8 or so at least, 
>> see your list of packages above ;)
> 
> Heh... sure, but surely such software could be made to work with a piece 
> of code that's more recent
> than id3lib?

Is there a more recent id3 library?  I dunno.  If there is, and all the 
packages you mentioned can find/use it, then sure....

>>
>>> I'm more than happy to continue maintaining id3lib if there is a 
>>> valid reason to do so,
>>> but my reasons are more sentimental than valid logical reasoning.
>>>
>>> So I turn to you to answer that question:
>>> Is there valid, logical, reasoning to continue to support such old code?
>>
>> Yes, because other useful packages depend on it IMHO.
>>
>> I'll take it if you don't want to keep it, I think that library needs 
>> to live on in Fedora.
>>
> 
> I'm happy to maintain it... though I could definitely use a coder as a 
> co-maintainer, or,
> really, anyone who wishes to help.
> 
> The problem I have with continuing such code, is both the lack of an 
> upstream...
> and the potential for security risks as this piece of code is left to rot.
> 
> I have neither the skills, nor the time to take over upstream, and 
> software cannot
> last/stay compatible forever.

I'd say that if/when problems crop up you could revisit it.  Maybe the 
reason it's been idle for so long is that it's simple/done/perfect and 
could just stay that way.  :)

If you have any need for a comaintainer I'd be glad to though in any case.

-Eric



From awilliam at redhat.com  Wed Oct  7 20:40:45 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 07 Oct 2009 13:40:45 -0700
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCFA24.8080300@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>
	<200910071304.35955.cemeyer@u.washington.edu>
	<4ACCFA24.8080300@gmail.com>
Message-ID: <1254948045.2291.69.camel@adam.local.net>

On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote:
> On 10/07/2009 04:04 PM, Conrad Meyer wrote:
> > Is it possible that id3lib is 'complete'? The id3 format isn't extremely
> > complicated, it may just be a completely finished library. (Keep in mind,
> > though, that I'm not familiar with the code.)
> >    
> 
> I suppose it's possible, but even 'finished' software should have bug fixes
> and compatibility updates.

Compatibility with what? As noted, the IDv3 format hasn't changed.

There are some open bugs, though:

http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter

so it seems it's not quite complete.

taglib is probably the best actively-developed modern alternative.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Wed Oct  7 20:48:57 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 07 Oct 2009 13:48:57 -0700
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <1254948045.2291.69.camel@adam.local.net>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>
	<200910071304.35955.cemeyer@u.washington.edu>
	<4ACCFA24.8080300@gmail.com> <1254948045.2291.69.camel@adam.local.net>
Message-ID: <1254948537.2291.71.camel@adam.local.net>

On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote:

> There are some open bugs, though:
> 
> http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter
> 
> so it seems it's not quite complete.
> 
> taglib is probably the best actively-developed modern alternative.

There's also an Ubuntu bug report indicating the use of id3lib causes
some problems:

https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110

That bug report also points out that id3lib is optional for easytag.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From ville.skytta at iki.fi  Wed Oct  7 21:00:46 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 8 Oct 2009 00:00:46 +0300
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <1254948045.2291.69.camel@adam.local.net>
References: <4ACCD4BD.1070507@gmail.com> <4ACCFA24.8080300@gmail.com>
	<1254948045.2291.69.camel@adam.local.net>
Message-ID: <200910080000.46937.ville.skytta@iki.fi>

On Wednesday 07 October 2009, Adam Williamson wrote:

> taglib is probably the best actively-developed modern alternative.

I might not apply to all cases - kid3 for example uses both.  Based on a brief 
look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu, 
id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when 
converting from 2.4.0 to 2.3.0.  I don't know why though, I'm not sufficiently 
familiar with either.  Nor am I sure why one would convert from 2.4.0 to 
2.3.0, maybe for compatibility reasons with $something.  And yes, this is 
quite a corner case.



From bjorn at xn--rombobjrn-67a.se  Wed Oct  7 21:10:11 2009
From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-15?q?Bj=F6rn_Persson?=)
Date: Wed, 7 Oct 2009 23:10:11 +0200
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCF21E.5070201@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>
Message-ID: <200910072310.11318.bjorn@xn--rombobjrn-67a.se>

Lyos Gemini Norezel wrote:
> Don't security risks grow exponentially as software 'bit rots'?

If someone finds and publishes a security hole, and no one tries to fix it, then 
the risk increases dramatically. If no holes are published and the software 
doesn't change, then I'd say the risk is fairly constant.

There is always the possibility that some bad guy finds a hole that the good 
guys haven't found and fixed yet. The bad guy can then use the hole in a few 
directed attacks against selected targets. (In the case of id3lib he could for 
example send a malformed MP3 file to the victim by email.) In that case you're 
at risk only if you are the bad guy's target. He can also use the hole in a 
large-scale attack against the entire userbase (for example publish a 
malformed MP3 file on some popular file sharing networks), but only once, 
because then the hole will become publicly known and presumably fixed, and 
after that the risk is the same as for any other published hole. All of this 
is true both for stable software and for software in active development, and 
although the developers in an active project may occasionally find a hole and 
fix it, they may also introduce a new hole at any time.

I'm much more nervous over programs like Squirrelmail, Firefox and 
Thunderbird, for which there is a steady stream of security fixes, because it 
indicates that the code is of low quality or that the design is fundamentally 
flawed.

Bj?rn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: 

From lyos.gemininorezel at gmail.com  Wed Oct  7 21:10:22 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 17:10:22 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <1254948045.2291.69.camel@adam.local.net>
References: <4ACCD4BD.1070507@gmail.com>	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>	<4ACCF21E.5070201@gmail.com>	<200910071304.35955.cemeyer@u.washington.edu>	<4ACCFA24.8080300@gmail.com>
	<1254948045.2291.69.camel@adam.local.net>
Message-ID: <4ACD03BE.8070501@gmail.com>

On 10/07/2009 04:40 PM, Adam Williamson wrote:
> On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote:
>    
>> On 10/07/2009 04:04 PM, Conrad Meyer wrote:
>>      
>>> Is it possible that id3lib is 'complete'? The id3 format isn't extremely
>>> complicated, it may just be a completely finished library. (Keep in mind,
>>> though, that I'm not familiar with the code.)
>>>
>>>        
>> I suppose it's possible, but even 'finished' software should have bug fixes
>> and compatibility updates.
>>      
> Compatibility with what? As noted, the IDv3 format hasn't changed.
>    

Kernel changes, soname changes, api changes, etc.
The IDv3 format is not the only thing this program needs to be 
compatible with.

> There are some open bugs, though:
>
> http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter
>
> so it seems it's not quite complete.
>
> taglib is probably the best actively-developed modern alternative.
>
>    
Hmmm... might be worth looking into... if taglib is still being actively 
developed.

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 443 bytes
Desc: not available
URL: 

From sgrubb at redhat.com  Wed Oct  7 21:11:55 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 7 Oct 2009 17:11:55 -0400
Subject: FESCo meeting summary for 2009-10-02
In-Reply-To: 
References: 
Message-ID: <200910071711.55293.sgrubb@redhat.com>

On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote:
> Meeting summary
> ---------------
> * incomplete features  (jds2001, 17:04:12)

>   * AGREED: Lower Process Capabilities is retained, dbus changes are
>     being committed to complete the feature.  (jds2001, 17:38:58)

I'm wondering if this is still in work? I just checked koji and dbus was 
rebuilt today, but without applying the patch here:

https://bugzilla.redhat.com/show_bug.cgi?id=518541

I really want to mark this feature 100% done. All that needs to be done is 
change the BuildRequires to libcap-ng-devel and apply the attached patch.

Thanks,
-Steve



From lyos.gemininorezel at gmail.com  Wed Oct  7 21:13:53 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 17:13:53 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <1254948537.2291.71.camel@adam.local.net>
References: <4ACCD4BD.1070507@gmail.com>	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>	<4ACCF21E.5070201@gmail.com>	<200910071304.35955.cemeyer@u.washington.edu>	<4ACCFA24.8080300@gmail.com>
	<1254948045.2291.69.camel@adam.local.net>
	<1254948537.2291.71.camel@adam.local.net>
Message-ID: <4ACD0491.2090604@gmail.com>

On 10/07/2009 04:48 PM, Adam Williamson wrote:
> On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote:
>
>    
>> There are some open bugs, though:
>>
>> http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter
>>
>> so it seems it's not quite complete.
>>
>> taglib is probably the best actively-developed modern alternative.
>>      
> There's also an Ubuntu bug report indicating the use of id3lib causes
> some problems:
>
> https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110
>
> That bug report also points out that id3lib is optional for easytag.
>
>    

Nice. Good to know I'm not the only one pondering dropping id3lib from a 
modern distro,
also... these Ubuntu bugs/issues should be investigated on Fedora.

It's possible they've caught a bug we have not, though it could be 
Ubuntu specific (granted, not likely).

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 443 bytes
Desc: not available
URL: 

From kevin.kofler at chello.at  Wed Oct  7 21:13:19 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 07 Oct 2009 23:13:19 +0200
Subject: Retiring ksensors, possibly id3lib as well?
References: <4ACCD4BD.1070507@gmail.com>
Message-ID: 

Lyos Gemini Norezel wrote:
> I believe the time has come to retire ksensors.
> 
> The last update/release was 18/08/2004, and it appears upstream has been
> defunct since at least that time.
> 
> Unless there are objections voiced and/or a maintainer steps forward
> before Oct 9 (Friday), I will go ahead and retire this package.

Here's an objection! I still use KSensors all the time, it still works 
perfectly fine and it presents the information in a better way than the 
plasmoids. (For example, you can have actual numbers for the temperature in 
the systray as opposed to some funky curves or analog indicators which are 
hard to read on my small panel.) The plasmoids also seem not to display 
hddtemp information. But I'm willing to pick up KSensors maintainership if 
you want to orphan it.

        Kevin Kofler



From lyos.gemininorezel at gmail.com  Wed Oct  7 21:14:52 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 17:14:52 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <200910080000.46937.ville.skytta@iki.fi>
References: <4ACCD4BD.1070507@gmail.com>
	<4ACCFA24.8080300@gmail.com>	<1254948045.2291.69.camel@adam.local.net>
	<200910080000.46937.ville.skytta@iki.fi>
Message-ID: <4ACD04CC.6010709@gmail.com>

On 10/07/2009 05:00 PM, Ville Skytt? wrote:
> On Wednesday 07 October 2009, Adam Williamson wrote:
>
>    
>> taglib is probably the best actively-developed modern alternative.
>>      
> I might not apply to all cases - kid3 for example uses both.  Based on a brief
> look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu,
> id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when
> converting from 2.4.0 to 2.3.0.  I don't know why though, I'm not sufficiently
> familiar with either.  Nor am I sure why one would convert from 2.4.0 to
> 2.3.0, maybe for compatibility reasons with $something.  And yes, this is
> quite a corner case.
>
>    
That's odd. Surely a modern ID3 tag program should support all of the 
IDv3 formats/versions?

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 443 bytes
Desc: not available
URL: 

From lyos.gemininorezel at gmail.com  Wed Oct  7 21:17:19 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 17:17:19 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACCFC71.40806@redhat.com>
References: <4ACCD4BD.1070507@gmail.com>
	<4ACCEB0C.9030800@redhat.com>	<4ACCF3FD.8050802@gmail.com>
	<4ACCFC71.40806@redhat.com>
Message-ID: <4ACD055F.8090502@gmail.com>

On 10/07/2009 04:39 PM, Eric Sandeen wrote:
> I'd say that if/when problems crop up you could revisit it.  Maybe the 
> reason it's been idle for so long is that it's simple/done/perfect and 
> could just stay that way.  :)
>
> If you have any need for a comaintainer I'd be glad to though in any 
> case.


Need? Not really.

Though I would love to have another set of eyes on this program.

So in this case '$want = yes, while $need = no' ;-)


>
> -Eric
>

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From awilliam at redhat.com  Wed Oct  7 21:20:15 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 07 Oct 2009 14:20:15 -0700
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <4ACD03BE.8070501@gmail.com>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>	<200910071304.35955.cemeyer@u.washington.edu>
	<4ACCFA24.8080300@gmail.com> <1254948045.2291.69.camel@adam.local.net>
	<4ACD03BE.8070501@gmail.com>
Message-ID: <1254950415.2291.80.camel@adam.local.net>

On Wed, 2009-10-07 at 17:10 -0400, Lyos Gemini Norezel wrote:

> > Compatibility with what? As noted, the IDv3 format hasn't changed.
> >    
> 
> Kernel changes, soname changes, api changes, etc.
> The IDv3 format is not the only thing this program needs to be 
> compatible with.

id3lib depends on very little else, only very low-level libraries which
very rarely change API. Probably the last one to do so was libstdc++ ,
and that was years ago. As it works perfectly fine in current Rawhide,
it would seem apparent that none of these changes has been needed. :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From lyos.gemininorezel at gmail.com  Wed Oct  7 21:42:32 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 07 Oct 2009 17:42:32 -0400
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: 
References: <4ACCD4BD.1070507@gmail.com> 
Message-ID: <4ACD0B48.8000407@gmail.com>

On 10/07/2009 05:13 PM, Kevin Kofler wrote:
> Lyos Gemini Norezel wrote:
>    
>> I believe the time has come to retire ksensors.
>>
>> The last update/release was 18/08/2004, and it appears upstream has been
>> defunct since at least that time.
>>
>> Unless there are objections voiced and/or a maintainer steps forward
>> before Oct 9 (Friday), I will go ahead and retire this package.
>>      
> Here's an objection! I still use KSensors all the time, it still works
> perfectly fine and it presents the information in a better way than the
> plasmoids. (For example, you can have actual numbers for the temperature in
> the systray as opposed to some funky curves or analog indicators which are
> hard to read on my small panel.) The plasmoids also seem not to display
> hddtemp information.

I don't use KDE... so I cannot comment there.

However... have you considered trying  gnome-applet-sensors?


>   But I'm willing to pick up KSensors maintainership if
> you want to orphan it.
>    

It seems odd to continue such a package despite upstream being defunct.

As I no longer use ksensors, if you wish to maintain this package... I 
will happily
surrender maintainership to you.

>          Kevin Kofler
>    


Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From mclasen at redhat.com  Wed Oct  7 22:16:50 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 07 Oct 2009 18:16:50 -0400
Subject: FESCo meeting summary for 2009-10-02
In-Reply-To: <200910071711.55293.sgrubb@redhat.com>
References: 
	<200910071711.55293.sgrubb@redhat.com>
Message-ID: <1254953810.1800.7.camel@planemask>

On Wed, 2009-10-07 at 17:11 -0400, Steve Grubb wrote:
> On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote:
> > Meeting summary
> > ---------------
> > * incomplete features  (jds2001, 17:04:12)
> 
> >   * AGREED: Lower Process Capabilities is retained, dbus changes are
> >     being committed to complete the feature.  (jds2001, 17:38:58)
> 
> I'm wondering if this is still in work? I just checked koji and dbus was 
> rebuilt today, but without applying the patch here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=518541
> 
> I really want to mark this feature 100% done. All that needs to be done is 
> change the BuildRequires to libcap-ng-devel and apply the attached patch.


I just asked Colin, who looked at the patch. 
There must have been some miscommunication, since he had expected you to
do the build for F12...let me do a build now.


Matthias



From poelstra at redhat.com  Wed Oct  7 23:38:46 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 07 Oct 2009 16:38:46 -0700
Subject: Fedora 12 Beta Blocker Meeting :: 2009-10-09 @ 15:00 UTC (11 AM EDT)
Message-ID: <4ACD2686.20409@redhat.com>

When: Friday, 2009-10-09 @ 15:00 UTC (11 AM EDT)
Where: #fedora-bugzappers on irc.freenode.net

Join us Friday for what we hope is the LAST blocker bug review meeting 
for the Fedora 12 Beta. On Friday we will review the unresolved bugs on
https://bugzilla.redhat.com/showdependencytree.cgi?id=507678&hide_resolved=1

517260  [ASSIGNED - medium - dlehman at redhat.com - --- - Reopened] 
liveinst fails at partitioning screen
  https://bugzilla.redhat.com/show_bug.cgi?id=517260

526208 [ASSIGNED - low - skvidal at sethdot.org - --- -] preupgrade failed 
from old release(f10, f11)
https://bugzilla.redhat.com/show_bug.cgi?id=526208

526470 [MODIFIED - medium - harald at redhat.com - --- -] NFSv3 mounting 
broken in dracut netboot
https://bugzilla.redhat.com/show_bug.cgi?id=526470

526842 [MODIFIED - urgent - xgl-maint at redhat.com - --- - Desktop] 
Firstboot not run after installation
https://bugzilla.redhat.com/show_bug.cgi?id=526842

If you are aware of any bugs you think should block the Beta, please set 
them to block 'F12Beta'.  If you are able, please come to the meeting as 
well to help guide the discussion.

We will also start reviewing the Fedora 12 Blocker Bugs--current count 
== 67!
https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1

Thanks for your help and time,
John



From lists at sapience.com  Thu Oct  8 02:26:08 2009
From: lists at sapience.com (Mail Lists)
Date: Wed, 07 Oct 2009 22:26:08 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1254939966.11711.555.camel@atropine.boston.devel.redhat.com>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<1254939966.11711.555.camel@atropine.boston.devel.redhat.com>
Message-ID: <4ACD4DC0.3000303@sapience.com>

On 10/07/2009 02:26 PM, Adam Jackson wrote:

> In fact, the major reason for not backporting the intel driver to F11 is
> that it requires a bunch of kernel changes that no one really has time
> for.  Among other things, 830 through 865 require GEM in the intel 2.9,
> which we have disabled for the F11 kernel for those chips because (as
> shipped) it's utterly broken.
> 
> - ajax
> 

 I dont have this hardware - but just a question - why not just upgrade
to upstream (2.6.32 would be nice in  a couple of days ... ) ?



From kevin.kofler at chello.at  Thu Oct  8 02:27:51 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 08 Oct 2009 04:27:51 +0200
Subject: Retiring ksensors, possibly id3lib as well?
References: <4ACCD4BD.1070507@gmail.com> 
	<4ACD0B48.8000407@gmail.com>
Message-ID: 

Lyos Gemini Norezel wrote:
> However... have you considered trying  gnome-applet-sensors?

gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel.

> It seems odd to continue such a package despite upstream being defunct.
> 
> As I no longer use ksensors, if you wish to maintain this package... I
> will happily
> surrender maintainership to you.

I picked it up, thanks!

        Kevin Kofler



From mcepl at redhat.com  Thu Oct  8 07:28:10 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 8 Oct 2009 07:28:10 +0000 (UTC)
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<1254939966.11711.555.camel@atropine.boston.devel.redhat.com>
	<4ACD4DC0.3000303@sapience.com>
Message-ID: 

Mail Lists, Wed, 07 Oct 2009 22:26:08 -0400:
>  I dont have this hardware - but just a question - why not just upgrade
> to upstream (2.6.32 would be nice in  a couple of days ... ) ?

I guess because F11 is considered stable release? I don't know really, 
but I would just add a banal observation that every hour spend on 
backporting stuff to F11 (and from Adam's answer it seems to require many 
many hours) cannot be spent on making Rawhide-soon-to-be-F12 more stable 
and useful.

Mat?j



From pmatilai at laiskiainen.org  Thu Oct  8 08:29:55 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 8 Oct 2009 11:29:55 +0300 (EEST)
Subject: Bug reporting URL field in packages
In-Reply-To: <1254852177.3641.55.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852177.3641.55.camel@localhost.localdomain>
Message-ID: 

On Tue, 6 Oct 2009, Jon Masters wrote:

> On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote:
>
>> So I guess the real question is do we want our packages built in koji to
>> assume a bug URL of fedora, even when used in downstream projects?
>
> I think that's a giant assumption - if the maintainer didn't put that
> URL in the package themselves, what makes you think automatically
> putting it in there is going to achieve anything different? ;)
>
> I advocate letting people choose for themselves.

Well, there's no semantics attached to the bugurl tag so it's up to distro 
policies what to use it for: distro bugtracker or upstream bugtracker for 
that package.

One option that would allow "remapping" the bug address to whatever 
local configuration says would be leaving part of the bugurl tag as an 
unexpanded macro, so our buildsys would define bugurl like this:

%bugurl %%{_bugurl_os}/%{name}

With that, the %{name} part is expanded at build time to effectively the 
source rpm name, and the rest is up to query-time expansion. The extension 
could return empty if the macro expansion fails (ie when _bugurl_os isn't 
defined). Something like fedora-release could provide the %_bugurl_os 
definition by default, and downstream distros, IT admins etc could 
override it to whatever appropriate. It also permits controlling the 
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.

That's trivial to implement, but would that be sufficient to cover the 
concerns over arbitrary downstream distros pointing to Fedora bugtracker 
etc, or should I just let it be?

 	- Panu -



From thomasj at fedoraproject.org  Thu Oct  8 09:29:20 2009
From: thomasj at fedoraproject.org (Thomas Janssen)
Date: Thu, 8 Oct 2009 11:29:20 +0200
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: 
References: <4ACCD4BD.1070507@gmail.com> 
	<4ACD0B48.8000407@gmail.com> 
Message-ID: 

2009/10/8 Kevin Kofler :
> Lyos Gemini Norezel wrote:
>> However... have you considered trying ?gnome-applet-sensors?
>
> gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel.
>
>> It seems odd to continue such a package despite upstream being defunct.
>>
>> As I no longer use ksensors, if you wish to maintain this package... I
>> will happily
>> surrender maintainership to you.
>
> I picked it up, thanks!

Thanks Kevin, i use it here as well.

-- 
LG Thomas

Dubium sapientiae initium



From mschwendt at gmail.com  Thu Oct  8 09:29:58 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 8 Oct 2009 11:29:58 +0200
Subject: Retiring ksensors, possibly id3lib as well?
In-Reply-To: <200910071304.35955.cemeyer@u.washington.edu>
References: <4ACCD4BD.1070507@gmail.com>
	<200910072119.56781.bjorn@xn--rombobjrn-67a.se>
	<4ACCF21E.5070201@gmail.com>
	<200910071304.35955.cemeyer@u.washington.edu>
Message-ID: <20091008112958.64560a10@faldor.intranet>

On Wed, 7 Oct 2009 13:04:35 -0700, Conrad wrote:

> On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote:
> > On 10/07/2009 03:19 PM, Bj?rn Persson wrote:
> > > Lyos Gemini Norezel wrote:
> > >> Is there valid, logical, reasoning to continue to support such old code?
> > >
> > > Are there any bugs that are so severe that we can't continue using the
> > > software?
> > 
> > No, actually.
> > 
> > Surprisingly enough... there are no current bugs open against id3lib.
> > 
> > >   If not: Why throw out working software just because it's old?
> > 
> > Don't security risks grow exponentially as software 'bit rots'?
> 
> Is it possible that id3lib is 'complete'?

Would be unusual, considering how complex the later ID3v2 specs are.

> The id3 format isn't extremely complicated, 

Define "extremely complicated".
http://www.id3.org/Compliance_Issues



From jnovy at redhat.com  Thu Oct  8 09:36:16 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Thu, 8 Oct 2009 11:36:16 +0200
Subject: TeXLive 2009 autoprovides/autorequires
In-Reply-To: 
References: 
Message-ID: <20091008093616.GA326@dhcp-lab-133.englab.brq.redhat.com>

On Mon, Oct 05, 2009 at 01:20:02AM -0400, Ben Boeckel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> I upgraded to F12 recently and enabled the TeXLive 2009 
> packages. One thing that the massive split has created is that 
> package dependencies are not made at all. I had to manually 
> install some packages to satisfy some dependencies. I created 
> these (rudimentary) .prov and .req scripts (attached) to try and 
> kickstart something.

The upstream metadata do indeed contain incomplete dependecy
information. I'm not sure how upstream generates the metadata but it
makes sense to add dependencies present in STY files to the packages.

I'm not fan of adding a new texlive.prov/req to rpm. It is indeed a
general solution but it needs direct hacks and maintenance at rpm
side. We can take advantage of the fact that we actually have the
whole TeX distribution when packaging TeX Live so that I would rather
implement the STY dependency calculator to the TL package generator.

Maybe a good name for such deps would be tex-sty(foo) in order to
distinguish style dependencies from the others.

> 
> As they are, they don't do versioning yet (seems that some 
> packages do versioning with LaTeX commands) nor does it support 
> \RequirePackage being split over multiple lines (similar with 
> \ProvidesPackage). I also may not be handling all of the 
> possibilities of where the provides and requires information may 
> be in the files.

The versioning is tricky here as the description in the STY files is
available only in textual form with intention to parse it by brain and
not by script :)

Jindrich

> 
> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJKyYICAAoJEKaxavVX4C1XnjgQAOuvMB9WMhtkzN7h+IjHcRu2
> u4WFJRLVB4J/8zpPz/mxFbGIbeeJSjaUde+7oRuz2RV1jD9bC4P3sP4bRQN77Xrc
> ffC1lOI1X6S3+AQt/nUonJnmG0/vqdeILWp/AulBNngpzb7w50Kj3iWGg+Zws5gy
> tTDBCp9dZJNkXylqI6UNjduMghvI41p2md2l7cd1gzudmXvLWaZMDFBQ81OZJt1g
> RE5JBi7+1OkNfINEjShKg+o/SlllZvT4u5erHWy7Fb/rOUGPX7qbj9ZqwZaQNWqU
> Dpr/8TSrXmsiuKk7tr+jL+GAtdB+fx18ZDV4E3umvmqzG+0KzIj6WmuW/DEyotRs
> qdqryzxSeZwtTjScBHAQG+TWlkm9X24hjnKnbyqIRvT81hawxPI/e6RAXTuuDUl8
> R+53le3RG6/mMy7MDD6Aky1h37R+4uIpmNpIb7JaNHhtfRanROxUw1Ii1Fjh5d45
> qA8i2pWaHPRC3OEMhaIgTFO1yHSWC5uLZ75K0owWKVQzo/UqFNAJwlGdIefM4YHD
> mSGesiawXEMAK0Ggfy2YxcNYPfhErk6cy7vGS/TlQhouO6utJVkc/a4sjmZj7rlb
> 3EvpRn3M/YGqeWg9536I8L9ugVFDnEwq958DRznB0FKCVpycnph1zMofGviLkrVv
> vjL/wtA8bfitn/xgR24o
> =8Hkv
> -----END PGP SIGNATURE-----



> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From terry1 at beam.ltd.uk  Thu Oct  8 09:54:54 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Thu, 08 Oct 2009 10:54:54 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <20091007144410.GA30884@hansolo.jdub.homelinux.org>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
Message-ID: <4ACDB6EE.8080606@beam.ltd.uk>

On 10/07/2009 03:44 PM, Josh Boyer wrote:
> On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
>> A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
>> new 1.7 XServer and 7.6 mesa would be very useful.
>
> No, not really.
>
>> I understand that changing the Graphics system could break many
>> users systems, so maybe a build of all the necessary packages could be put
>> into the testing repository or perhaps a special graphics-testing repository
>> could be added. This would help get the graphics issues fixed prior to
>> F12's release ...
>
> Actually, installing rawhide or the F-12 Beta (or using a livecd) would help
> get the graphics issues fixed prior to F-12 release.  That is going to help
> much more than wasting the developer's time trying to backport everything to
> F-11, pushing it to updates-testing, and dealing with all the fallout.
>
>> It would be good to have a Linux system that could actually to 3D with the
>> major applications by the end of 2009 !
>
> Fortunately, F-12 is scheduled for release by then!
>
> josh
>
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?

Due to the range of graphics hardware and the differences between them, I would
have thought that a significant amount of user testing and bug fixing would need 
to be done to achieve this. I tried the F12 ATI graphics testing day and 
although a good idea the 3D tests were very limited and due to the amount of 
effort a user has to put in I guess limited in scope. Although people, myself 
included, feed back bugs upstream into the freedesktop GIT repository I would 
have thought that a larger audience was required ...

I would have thought that more people would be likely to try out the graphics
updates if it is easy for them to install on their running systems and use in 
their normal usage patterns rather than have to maintain a separate test system
just to test and feed back issues ...

It seems that the Fedora short release lifetime makes this sort of testing/bug 
fixing for X11 refinement harder.

Anyway I guess this is obviously a trade off between user/testers and developers 
time :)



From mschwendt at gmail.com  Thu Oct  8 10:38:11 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 8 Oct 2009 12:38:11 +0200
Subject: Retiring gai, gai-temp, gai-pal
Message-ID: <20091008123811.4fc63e21@faldor.intranet>

The current thread on "ksensors, id3lib" has reminded me to give
gnome-applet-sensors another try right now. In F11. It works for me
while that hasn't been true before (troubles with acpi thrm or
no sensors).

As a result, I'd like to retire GAI (General Applet Interface Library)
and two of the applets that are in the Fedora Package Collection:

  gai-temp
  gai-pal
  gai

There has not been any new release since 2005. Several patches
have been mailed upstream, but later without any response. No other
GAI applets have ever been included in the Fedora Package Collection.

I plan to keep the packages only for F-11 and F-10, but not for F-12 and
newer.



From jwboyer at gmail.com  Thu Oct  8 11:20:28 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 8 Oct 2009 07:20:28 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACDB6EE.8080606@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk>
Message-ID: <20091008112028.GF30884@hansolo.jdub.homelinux.org>

On Thu, Oct 08, 2009 at 10:54:54AM +0100, Terry Barnaby wrote:
>>> It would be good to have a Linux system that could actually to 3D with the
>>> major applications by the end of 2009 !
>>
>> Fortunately, F-12 is scheduled for release by then!
>>
>> josh
>>
> Are you confident that F12 will make 3D usable under Linux on the majority of
> mainstream graphics cards ?
>
> Due to the range of graphics hardware and the differences between them, I would
> have thought that a significant amount of user testing and bug fixing 
> would need to be done to achieve this. I tried the F12 ATI graphics 

It is.  Which is why we encourage people to test rawhide and Alpha and Beta
releases.

> testing day and although a good idea the 3D tests were very limited and 
> due to the amount of effort a user has to put in I guess limited in 
> scope. Although people, myself included, feed back bugs upstream into the 
> freedesktop GIT repository I would have thought that a larger audience 
> was required ...

A large tester base is needed, yes.

> I would have thought that more people would be likely to try out the graphics
> updates if it is easy for them to install on their running systems and 
> use in their normal usage patterns rather than have to maintain a 
> separate test system
> just to test and feed back issues ...

Except that is a major undertaking, and honestly I think it's not what we
should push onto users that are on a stable release.  Development happens
in rawhide.

> It seems that the Fedora short release lifetime makes this sort of 
> testing/bug fixing for X11 refinement harder.
>
> Anyway I guess this is obviously a trade off between user/testers and 
> developers time :)

Yes, and it's also about trying to consolidate as much of the testing effort
as we can.

josh



From rjones at redhat.com  Thu Oct  8 12:44:47 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 8 Oct 2009 13:44:47 +0100
Subject: Easy review swap
Message-ID: <20091008124447.GA2338@amd.home.annexia.org>


https://bugzilla.redhat.com/show_bug.cgi?id=527971
OCaml framework for Functional Reactive Programming (FRP)

The whole library is a single file, it's rpmlint clean, and there's a
Koji scratch build.

I'll swap for a similarly easy review.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From bruno at wolff.to  Thu Oct  8 12:51:59 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 8 Oct 2009 07:51:59 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACDB6EE.8080606@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk>
Message-ID: <20091008125159.GA25579@wolff.to>

On Thu, Oct 08, 2009 at 10:54:54 +0100,
  Terry Barnaby  wrote:
> Are you confident that F12 will make 3D usable under Linux on the majority of
> mainstream graphics cards ?

It's not going to provide 3d for nvidia, though it is hoped that nouveau will
be somewhat improved. Intel and all much of ATI (through at least r600 series)
is supposed to get working 3d with kernel mode setting.

> Due to the range of graphics hardware and the differences between them, I would
> have thought that a significant amount of user testing and bug
> fixing would need to be done to achieve this. I tried the F12 ATI
> graphics testing day and although a good idea the 3D tests were very
> limited and due to the amount of effort a user has to put in I guess
> limited in scope. Although people, myself included, feed back bugs
> upstream into the freedesktop GIT repository I would have thought
> that a larger audience was required ...

So you'd prefer to force F11 users to do testing whether they want to
or not?

> I would have thought that more people would be likely to try out the graphics
> updates if it is easy for them to install on their running systems
> and use in their normal usage patterns rather than have to maintain
> a separate test system
> just to test and feed back issues ...

It isn't going to be simple to do this. With the modesetting changes there
are a lot of interactions between parts and you need to change a number of
things (X, mesa, drm, kernel) at once to have a working system.



From terry1 at beam.ltd.uk  Thu Oct  8 13:05:22 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Thu, 08 Oct 2009 14:05:22 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <20091008125159.GA25579@wolff.to>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
Message-ID: <4ACDE392.1060208@beam.ltd.uk>

On 10/08/2009 01:51 PM, Bruno Wolff III wrote:
> On Thu, Oct 08, 2009 at 10:54:54 +0100,
>    Terry Barnaby  wrote:
>> Are you confident that F12 will make 3D usable under Linux on the majority of
>> mainstream graphics cards ?
>
> It's not going to provide 3d for nvidia, though it is hoped that nouveau will
> be somewhat improved. Intel and all much of ATI (through at least r600 series)
> is supposed to get working 3d with kernel mode setting.
>
>> Due to the range of graphics hardware and the differences between them, I would
>> have thought that a significant amount of user testing and bug
>> fixing would need to be done to achieve this. I tried the F12 ATI
>> graphics testing day and although a good idea the 3D tests were very
>> limited and due to the amount of effort a user has to put in I guess
>> limited in scope. Although people, myself included, feed back bugs
>> upstream into the freedesktop GIT repository I would have thought
>> that a larger audience was required ...
>
> So you'd prefer to force F11 users to do testing whether they want to
> or not?
No, I don't what to force testing on anyone (although F11 has done that
already :) )
I was just suggesting that a separate yum archive with the packages necessary
to test the later graphics development code that will be in F12 could be
made available for people to try out easily with their F11 systems.
They can optionally try these. I think it will allow 3D to work for many people
(from my experience of the latest GIT versions) although others would not be so 
lucky. They can easily back these changes out if they have more issues than
the standard graphics system.

>
>> I would have thought that more people would be likely to try out the graphics
>> updates if it is easy for them to install on their running systems
>> and use in their normal usage patterns rather than have to maintain
>> a separate test system
>> just to test and feed back issues ...
>
> It isn't going to be simple to do this. With the modesetting changes there
> are a lot of interactions between parts and you need to change a number of
> things (X, mesa, drm, kernel) at once to have a working system.
Yes, there are quite a few changes, that is why it is difficult for people
to test the changes ... Although I would have though that for the most part
it would be just building the appropriate set of the F12 packages for F11.

Ah well, I will probably have to wait for F12 or F13 before I can truly move 
from F8 :(



From jdieter at gmail.com  Thu Oct  8 14:24:36 2009
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Oct 2009 17:24:36 +0300
Subject: Package updates not replaced by newer package in -testing
Message-ID: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>

A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a
subpackage that had accidentally been merged into the main package in
deltarpm-3.4-17.fc11.  I pushed -18 into -testing, and assumed (since it
was newer than -17) that -17 wouldn't get pushed to stable
automatically.

Now I've just received an email from koji saying that -17 has been
pushed to updates from updates-testing.  I've just pushed -18 into
updates, but is there any way to avoid a one or two day delay where -17
makes it into updates before -18 does?

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From kevin.kofler at chello.at  Thu Oct  8 14:36:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 08 Oct 2009 16:36:52 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<1254939966.11711.555.camel@atropine.boston.devel.redhat.com>
	<4ACD4DC0.3000303@sapience.com> 
Message-ID: 

Matej Cepl wrote:
> I guess because F11 is considered stable release? I don't know really,
> but I would just add a banal observation that every hour spend on
> backporting stuff to F11 (and from Adam's answer it seems to require many
> many hours) cannot be spent on making Rawhide-soon-to-be-F12 more stable
> and useful.

The suggestion was not to backport the kernel changes, but to just upgrade 
the kernel. The F11 kernel was already upgraded from 2.6.29.4 to 2.6.30.8, 
so why not 2.6.31.x or (once it's out) 2.6.32.x?

        Kevin Kofler



From thomasj at fedoraproject.org  Thu Oct  8 14:38:58 2009
From: thomasj at fedoraproject.org (Thomas Janssen)
Date: Thu, 8 Oct 2009 16:38:58 +0200
Subject: Package updates not replaced by newer package in -testing
In-Reply-To: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>
References: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>
Message-ID: 

2009/10/8 Jonathan Dieter :
> A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a
> subpackage that had accidentally been merged into the main package in
> deltarpm-3.4-17.fc11. ?I pushed -18 into -testing, and assumed (since it
> was newer than -17) that -17 wouldn't get pushed to stable
> automatically.
>
> Now I've just received an email from koji saying that -17 has been
> pushed to updates from updates-testing. ?I've just pushed -18 into
> updates, but is there any way to avoid a one or two day delay where -17
> makes it into updates before -18 does?

How was it automatic pushed to stable? Automatic karma push? Disable
that then. Or unpush it.

That's all *i* know.

-- 
LG Thomas

Dubium sapientiae initium



From a.badger at gmail.com  Thu Oct  8 14:44:50 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 8 Oct 2009 07:44:50 -0700
Subject: Package updates not replaced by newer package in -testing
In-Reply-To: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>
References: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>
Message-ID: <20091008144450.GF28231@clingman.lan>

On Thu, Oct 08, 2009 at 05:24:36PM +0300, Jonathan Dieter wrote:
> A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a
> subpackage that had accidentally been merged into the main package in
> deltarpm-3.4-17.fc11.  I pushed -18 into -testing, and assumed (since it
> was newer than -17) that -17 wouldn't get pushed to stable
> automatically.
> 
> Now I've just received an email from koji saying that -17 has been
> pushed to updates from updates-testing.  I've just pushed -18 into
> updates, but is there any way to avoid a one or two day delay where -17
> makes it into updates before -18 does?
>
This is partially my fault -- my network connection hasn't been good for the
last day so instead of clearing with you which Fedora releases had the new
package, I just looked quickly at bodhi and didn't see any obsoletes so I
requested it be pushed to stable.  I now remember that obsoletes had to be
disabled in bodhi due to other bugs :-( so that didn't clue me in.

Sorry, mea culpa. rel-eng can unpush packages -- but it might be better if
they could just push the new set with the fixed deltarpm instead.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From jkeating at redhat.com  Thu Oct  8 15:11:23 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 08 Oct 2009 08:11:23 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <4ACDB6EE.8080606@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk>
Message-ID: <1255014684.3656.3.camel@localhost.localdomain>

On Thu, 2009-10-08 at 10:54 +0100, Terry Barnaby wrote:
> I would have thought that more people would be likely to try out the graphics
> updates if it is easy for them to install on their running systems and use in 
> their normal usage patterns rather than have to maintain a separate test system
> just to test and feed back issues ... 

This is why live images are useful.  Boot the live image, do some of
your normal work, throw it away when done and don't disrupt your already
installed OS.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jkeating at redhat.com  Thu Oct  8 15:13:06 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 08 Oct 2009 08:13:06 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852177.3641.55.camel@localhost.localdomain>
	
Message-ID: <1255014786.3656.4.camel@localhost.localdomain>

On Thu, 2009-10-08 at 11:29 +0300, Panu Matilainen wrote:
> With that, the %{name} part is expanded at build time to effectively the 
> source rpm name, and the rest is up to query-time expansion. The extension 
> could return empty if the macro expansion fails (ie when _bugurl_os isn't 
> defined). Something like fedora-release could provide the %_bugurl_os 
> definition by default, and downstream distros, IT admins etc could 
> override it to whatever appropriate. It also permits controlling the 
> bugurl for packages from different sources like 3rd party repositories.
> And changing the bug tracker base address doesn't require mass-rebuild.
> 
> That's trivial to implement, but would that be sufficient to cover the 
> concerns over arbitrary downstream distros pointing to Fedora bugtracker 
> etc, or should I just let it be? 

Hrm, how does it help for 3rd party packages?  They would hardcode the
entire string into their rpms?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From rawhide at fedoraproject.org  Thu Oct  8 15:45:33 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 8 Oct 2009 15:45:33 +0000
Subject: rawhide report: 20091008 changes
Message-ID: <20091008154533.GA25348@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct  8 06:15:12 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Removed package compat-wxGTK26
Updated Packages:

GConf2-2.28.0-2.fc12
--------------------
* Wed Oct 07 2009 Matthias Clasen  - 2.28.0-2
- Fix a problem with schema translations


aria2-1.6.1-1.fc12
------------------
* Thu Oct 08 2009 Rahul Sundaram  - 1.6.1-1
- Fixes memory leak in HTTP/FTP downloads and other minor bug fixes
- http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1569


bognor-regis-0.4.10-3.fc12
--------------------------
* Wed Oct 07 2009 Peter Robinson  0.4.10-3
- Add upstream patch to fix a crash


brasero-2.28.1-2.fc12
---------------------
* Wed Oct 07 2009 Bastien Nocera  2.28.1-2
- Fix command-line parsing (#527484)


dbus-1.2.16-8.fc12
------------------
* Wed Oct 07 2009 Matthias Clasen  - 1:1.2.16-7
- Add missing diagrams to the docs (#527650)

* Wed Oct 07 2009 Matthias Clasen  - 1:1.2.16-8
- Drop capabilities (#518541)


evolution-2.28.0-2.fc12
-----------------------
* Fri Oct 02 2009 Matthew Barnes  - 2.28.0-2.fc12
- Tweak desktop file for GNOME Shell.


glib2-2.22.2-1.fc12
-------------------
* Wed Oct 07 2009 Matthias Clasen  - 2.22.2-1
- Update to 2.22.2


gnome-media-2.28.1-1.fc12
-------------------------
* Wed Oct 07 2009 Bastien Nocera  2.28.1-1
- Update to 2.28.1


gnome-panel-2.28.0-2.fc12
-------------------------
* Wed Oct 07 2009 Matthias Clasen  2.28.0-2
- Add a default location to the clock applet


gupnp-0.13.1-1.fc12
-------------------
* Wed Oct 07 2009 Peter Robinson  0.13.1-1
- Update to 0.13.1


moblin-gtk-engine-1.0.2-1.fc12
------------------------------
* Wed Oct 07 2009 Peter Robinson  1.0.2-1
- New upstream 1.0.2 release


moblin-panel-myzone-0.0.7-1.fc12
--------------------------------
* Wed Oct 07 2009 Peter Robinson  0.0.7-1
- New upstream 0.0.7 release


moblin-session-0.12-6.fc12
--------------------------
* Wed Oct 07 2009 Peter Robinson  0.12-6
- Shorten desktop name to plain Moblin


mojito-0.21.2-1.fc12
--------------------
* Fri Oct 02 2009 Peter Robinson  0.21.2-1
- Update to 0.21.2


mutter-2.28.0-2.fc12
--------------------
* Wed Oct 07 2009 Owen Taylor  - 2.28.0-1
- Update to 2.28.0


openldap-2.4.18-5.fc12
----------------------
* Wed Oct 07 2009 Jan Zeleny  2.4.18-5
- updated smbk5pwd patch to be linked with libldap (#526500)

* Wed Sep 30 2009 Jan Zeleny  2.4.18-4
- buffer overflow patch from upstream
- added /etc/openldap/slapd.d and /etc/openldap/slapd.conf.bak
  to files owned by openldap-servers


plymouth-0.8.0-0.2009.29.09.6.fc12
----------------------------------
* Wed Oct 07 2009 Ray Strode  0.8.0-0.2009.29.09.5
- Prevent firstboot's X from crashing on radeon hardware. This should
  only affect multihead users, but for some reason it's getting some
  single head users as well.

* Wed Oct 07 2009 Ray Strode  0.8.0-0.2009.29.09.6
- Fix the reason radeon single head users were affected.

* Tue Oct 06 2009 Ray Strode  0.8.0-0.2009.29.09.4
- Prevent firstboot's X from crashing on intel hardware


polkit-gnome-0.95-0.git20090913.6.fc12
--------------------------------------
* Wed Oct 07 2009 Matthias Clasen  - 0.95.0.git20090913.6
- Prevent the statusicon from eating whitespace


rhythmbox-0.12.5-5.fc12
-----------------------
* Wed Oct 07 2009 Bastien Nocera  0.12.5-5
- Remove work-around for brasero bug


rubygem-actionmailer-2.3.4-2.fc12
---------------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


rubygem-actionpack-2.3.4-2.fc12
-------------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


rubygem-activerecord-2.3.4-2.fc12
---------------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


rubygem-activeresource-2.3.4-2.fc12
-----------------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


rubygem-activesupport-2.3.4-2.fc12
----------------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


rubygem-rails-2.3.4-2.fc12
--------------------------
* Wed Oct 07 2009 David Lutterkort  - 1:2.3.4-2
- Bump Epoch to ensure upgrade path from F-11


seahorse-plugins-2.28.0-2.fc12
------------------------------
* Wed Oct 07 2009 Matthias Clasen  - 2.28.0-2
- Implement GETINFO to make seahorse-agent work with gnupg >= 2.0.12


selinux-policy-3.6.32-22.fc12
-----------------------------
* Wed Oct 07 2009 Dan Walsh  3.6.32-22
- Allow polickit to read meminfo

* Mon Oct 05 2009 Dan Walsh  3.6.32-21
- Allow dovecot_t getcap, setcap

* Fri Oct 02 2009 Dan Walsh  3.6.32-19
- Add labeling for /var/run/kdm

* Fri Oct 02 2009 Dan Walsh  3.6.32-20
- Add chrome-sandbox policy
- Split out execmem policy

* Thu Oct 01 2009 Dan Walsh  3.6.32-17
- Allow vpnc request the kernel to load modules

* Thu Oct 01 2009 Dan Walsh  3.6.32-18
- Allow svirt to list sysfs_t directory

* Wed Sep 30 2009 Dan Walsh  3.6.32-15
- Add plymouth policy
- Allow local_login to sys_admin

* Wed Sep 30 2009 Dan Walsh  3.6.32-16
- Fix minimum policy installs
- Allow udev and rpcbind to request the kernel to load modules

* Tue Sep 29 2009 Dan Walsh  3.6.32-13
- Allow cupsd_config to read user tmp
- Allow snmpd_t to signal itself
- Allow sysstat_t to makedir in sysstat_log_t


setroubleshoot-2.2.37-1.fc12
----------------------------
* Wed Oct 07 2009 Dan Walsh  - 2.2.37-1
- Don't throw up an error box if yum cache is not setup

* Mon Oct 05 2009 Dan Walsh  - 2.2.36-1
- Fix Fix It button
- Remove Setroubleshoot: from every heading

* Thu Oct 01 2009 Dan Walsh  - 2.2.35-1
- Fix translations, plurals and glade
	- Update Po
	- Fix plural form
	- Add support for Green Plugins


totem-2.28.1-3.fc12
-------------------
* Wed Oct 07 2009 Bastien Nocera  2.28.1-3
- Remove work-around for brasero bug


xscreensaver-5.10-2.fc12
------------------------
* Thu Oct 08 2009 Mamoru Tasaka  - 1:5.10-2
- Restrict Autostart effect to GNOME session only (bug 517391)
- Use planet.fedoraproject.org for textURL (still the default textMode
  is "file", i.e. no net connection)


xz-4.999.9-0.1.beta.20091007git.fc12
------------------------------------
* Wed Oct 07 2009 Jindrich Novy  4.999.9-0.1.20091007.beta
- sync with upstream again

* Fri Oct 02 2009 Jindrich Novy  4.999.9-0.1.20091002.beta
- sync with upstream to generate the same archives on machines with different
  endianess


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 31



From awilliam at redhat.com  Thu Oct  8 16:37:19 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 08 Oct 2009 09:37:19 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <4ACDE392.1060208@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
Message-ID: <1255019839.2291.91.camel@adam.local.net>

On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
> No, I don't what to force testing on anyone (although F11 has done
> that
> already :) )
> I was just suggesting that a separate yum archive with the packages
> necessary
> to test the later graphics development code that will be in F12 could
> be
> made available for people to try out easily with their F11 systems.
> They can optionally try these. I think it will allow 3D to work for
> many people
> (from my experience of the latest GIT versions) although others would
> not be so 
> lucky. They can easily back these changes out if they have more issues
> than
> the standard graphics system. 

Then please feel free to make one. :) I don't mean that in a snide
fashion, but it really is the answer. As noted, having our X.org
developers spend time on such a repository directly subtracts that
amount of time from the time they would otherwise spend actually
developing the drivers (our X.org maintainers are also major upstream
developers) and fixing reported bugs.

Given that there is a lot of development work to do on these drivers
(which is why you find the newer versions better...) and a lot of bugs
to fix (we generally barely keep up with the rate of bugs filed as it
is), we don't see that as a good trade-off. You'd get backported drivers
for stable releases, but the rate of development of the actual upstream
drivers would be noticeably slowed, and fewer reported bugs would
ultimately get fixed.

Backporting packages is not intrinsically very difficult, though it is
somewhat time-consuming, so it's something for which a far greater
candidate pool exists than X driver development. Thus, the suggestion
that someone else do it. For instance, you. It seems you've already
successfully built the latest versions of things locally; if you can do
that, you can put them in a package and put the package in a repository,
it's not a very hard process and it's all documented on the Wiki.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From jdieter at gmail.com  Thu Oct  8 16:51:56 2009
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Oct 2009 19:51:56 +0300
Subject: Package updates not replaced by newer package in -testing
In-Reply-To: <20091008144450.GF28231@clingman.lan>
References: <1255011876.1331.13.camel@jdlaptop.lesbg.loc>
	<20091008144450.GF28231@clingman.lan>
Message-ID: <1255020716.1331.16.camel@jdlaptop.lesbg.loc>

On Thu, 2009-10-08 at 07:44 -0700, Toshio Kuratomi wrote:
> This is partially my fault -- my network connection hasn't been good for the
> last day so instead of clearing with you which Fedora releases had the new
> package, I just looked quickly at bodhi and didn't see any obsoletes so I
> requested it be pushed to stable.  I now remember that obsoletes had to be
> disabled in bodhi due to other bugs :-( so that didn't clue me in.
> 
> Sorry, mea culpa. rel-eng can unpush packages -- but it might be better if
> they could just push the new set with the fixed deltarpm instead.

No problem, I'll open a ticket for the new version to be pushed.  I
should have communicated that I'd pushed a new version to testing.

Thanks again for your work,

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From orion at cora.nwra.com  Thu Oct  8 16:55:27 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 08 Oct 2009 10:55:27 -0600
Subject: Trying to build jackrabbit
Message-ID: <4ACE197F.2030907@cora.nwra.com>

Trying to build apache jackrabbit 1.6.0 on F12.  Getting:

+ export 
MAVEN_REPO_LOCAL=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository
+ MAVEN_REPO_LOCAL=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository
+ mkdir -p /builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository
+ mvn-jpp 
-Dmaven.repo.local=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository 
install javadoc:javadoc
/usr/lib/jvm/java
[INFO] Scanning for projects...
Downloading: 
file:///usr/share/maven2/repository/JPP/maven2/default_poms/org.apache.jackrabbit-parent.pom 

[WARNING] Skipping non filebased repository 
http://repo1.maven.org/maven2 in full offline mode 

[INFO] 
------------------------------------------------------------------------ 

[ERROR] FATAL ERROR
[INFO] 
------------------------------------------------------------------------ 

[INFO] Error building POM (may not be this project's POM).
Project ID: null:jackrabbit-parent:pom:1.6.0
Reason: Cannot find parent: org.apache.jackrabbit:parent for project: 
null:jackrabbit-parent:pom:1.6.0 for project 
null:jackrabbit-parent:pom:1.6.0

Any ideas?

http://www.cora.nwra.com/~orion/fedora/jackrabbit-1.6.0-1.fc11.src.rpm

Thanks!

-- 
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 sgrubb at redhat.com  Thu Oct  8 16:57:20 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 8 Oct 2009 12:57:20 -0400
Subject: FESCo meeting summary for 2009-10-02
In-Reply-To: <1254953810.1800.7.camel@planemask>
References: 
	<200910071711.55293.sgrubb@redhat.com>
	<1254953810.1800.7.camel@planemask>
Message-ID: <200910081257.20368.sgrubb@redhat.com>

On Wednesday 07 October 2009 06:16:50 pm Matthias Clasen wrote:
> On Wed, 2009-10-07 at 17:11 -0400, Steve Grubb wrote:
> > On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote:
> > > Meeting summary
> > > ---------------
> > > * incomplete features  (jds2001, 17:04:12)
> > >
> > >   * AGREED: Lower Process Capabilities is retained, dbus changes are
> > >     being committed to complete the feature.  (jds2001, 17:38:58)
> >
> > I'm wondering if this is still in work? I just checked koji and dbus was
> > rebuilt today, but without applying the patch here:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=518541
> >
> > I really want to mark this feature 100% done. All that needs to be done
> > is change the BuildRequires to libcap-ng-devel and apply the attached
> > patch.
> 
> I just asked Colin, who looked at the patch.
> There must have been some miscommunication, since he had expected you to
> do the build for F12

Sometime earlier this year something was changed in the package db that 
requires you to be a proven packager to touch other people's packages. I found 
this out when I tried to rebuild all the dependencies for the audit-libs 
soname number bump back in August.

> ...let me do a build now.

Thanks. The Lower Process Capabilities Feature is now 100% complete. Wiki page 
has been updated. The testing plan has been updated. Now we just need testing. 
:)

-Steve



From bruno at wolff.to  Thu Oct  8 17:49:28 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 8 Oct 2009 12:49:28 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACDE392.1060208@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
Message-ID: <20091008174928.GB28554@wolff.to>

On Thu, Oct 08, 2009 at 14:05:22 +0100,
> I was just suggesting that a separate yum archive with the packages necessary
> to test the later graphics development code that will be in F12 could be
> made available for people to try out easily with their F11 systems.
> They can optionally try these. I think it will allow 3D to work for many people

It is probably just as good for the user to try out rawhide and see if it
is worth going to F12. And it's a lot less work for developers and graphics
seems to have a developer bottleneck, so I think savign their effort is
beneficial to the project.



From bruno at wolff.to  Thu Oct  8 17:59:18 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 8 Oct 2009 12:59:18 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACCA26A.7020808@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
Message-ID: <20091008175918.GA2884@wolff.to>

On Wed, Oct 07, 2009 at 15:15:06 +0100,
  Terry Barnaby  wrote:
> The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
> ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
> on any of my computers (5 different graphics hardware versions).

I was able to start testing my rv280 based ATI 9200 card this morning
and I was able to do stuff in tremulous, so it looks like 3d is working
again. For F11 I had needed to use no modeset which broke 3d.

I still have some more testing to do and I need to set up at least one
modeline since modeline detection doesn't work for me (probably because
my monitor doesn't do EDID correctly or at all).

So it might be worth you trying out F12. Note that I used a very recent
kernel and ati driver which might not have been tagged for the beta.
This seemed to be an improvement over my first reboot after going to
F12 which had stuff a day or so older.

I am going to be very happy if this preliminary result bears out under
further testing.



From pmatilai at laiskiainen.org  Thu Oct  8 18:00:55 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 8 Oct 2009 21:00:55 +0300 (EEST)
Subject: Bug reporting URL field in packages
In-Reply-To: <1255014786.3656.4.camel@localhost.localdomain>
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852177.3641.55.camel@localhost.localdomain>
	
	<1255014786.3656.4.camel@localhost.localdomain>
Message-ID: 

On Thu, 8 Oct 2009, Jesse Keating wrote:

> On Thu, 2009-10-08 at 11:29 +0300, Panu Matilainen wrote:
>> With that, the %{name} part is expanded at build time to effectively the
>> source rpm name, and the rest is up to query-time expansion. The extension
>> could return empty if the macro expansion fails (ie when _bugurl_os isn't
>> defined). Something like fedora-release could provide the %_bugurl_os
>> definition by default, and downstream distros, IT admins etc could
>> override it to whatever appropriate. It also permits controlling the
>> bugurl for packages from different sources like 3rd party repositories.
>> And changing the bug tracker base address doesn't require mass-rebuild.
>>
>> That's trivial to implement, but would that be sufficient to cover the
>> concerns over arbitrary downstream distros pointing to Fedora bugtracker
>> etc, or should I just let it be?
>
> Hrm, how does it help for 3rd party packages?  They would hardcode the
> entire string into their rpms?

They could hardcode the entire string or use their own macro for it, like 
%{_bugurl_myrepo} and provide a macro in their -release package that 
provides the macro definition.

 	- Panu -



From jkeating at redhat.com  Thu Oct  8 18:15:43 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 08 Oct 2009 11:15:43 -0700
Subject: Bug reporting URL field in packages
In-Reply-To: 
References: 
	<200910061613.18324.Juha.Tuomala@iki.fi>
	
	<1254841523.7609.14.camel@localhost.localdomain>
	
	<1254851015.11617.3.camel@localhost.localdomain>
	<1254852177.3641.55.camel@localhost.localdomain>
	
	<1255014786.3656.4.camel@localhost.localdomain>
	
Message-ID: <1255025743.3656.13.camel@localhost.localdomain>

On Thu, 2009-10-08 at 21:00 +0300, Panu Matilainen wrote:
> They could hardcode the entire string or use their own macro for it, like 
> %{_bugurl_myrepo} and provide a macro in their -release package that 
> provides the macro definition.
> 
> 

Oh I see, yeah that could work.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From wcohen at redhat.com  Thu Oct  8 18:20:59 2009
From: wcohen at redhat.com (William Cohen)
Date: Thu, 08 Oct 2009 14:20:59 -0400
Subject: Easy review swap
In-Reply-To: <20091008124447.GA2338@amd.home.annexia.org>
References: <20091008124447.GA2338@amd.home.annexia.org>
Message-ID: <4ACE2D8B.6090602@redhat.com>

Richard W.M. Jones wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=527971
> OCaml framework for Functional Reactive Programming (FRP)
> 
> The whole library is a single file, it's rpmlint clean, and there's a
> Koji scratch build.
> 
> I'll swap for a similarly easy review.
> 
> Rich.
> 

I could trade you the papi package for review. It isn't quite as simple, but I
have gone through the fedora package review checklist and made a couple
iterations on the papi srpm:

https://bugzilla.redhat.com/show_bug.cgi?id=525346
Review Request: papi - Performance Application Programming Interface

A scratch build has been put through koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1722841

-Will



From terry1 at beam.ltd.uk  Thu Oct  8 18:33:01 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Thu, 08 Oct 2009 19:33:01 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255019839.2291.91.camel@adam.local.net>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
Message-ID: <4ACE305D.40105@beam.ltd.uk>

On 10/08/2009 05:37 PM, Adam Williamson wrote:
> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
>> No, I don't what to force testing on anyone (although F11 has done
>> that
>> already :) )
>> I was just suggesting that a separate yum archive with the packages
>> necessary
>> to test the later graphics development code that will be in F12 could
>> be
>> made available for people to try out easily with their F11 systems.
>> They can optionally try these. I think it will allow 3D to work for
>> many people
>> (from my experience of the latest GIT versions) although others would
>> not be so
>> lucky. They can easily back these changes out if they have more issues
>> than
>> the standard graphics system.
>
> Then please feel free to make one. :) I don't mean that in a snide
> fashion, but it really is the answer. As noted, having our X.org
> developers spend time on such a repository directly subtracts that
> amount of time from the time they would otherwise spend actually
> developing the drivers (our X.org maintainers are also major upstream
> developers) and fixing reported bugs.
>
> Given that there is a lot of development work to do on these drivers
> (which is why you find the newer versions better...) and a lot of bugs
> to fix (we generally barely keep up with the rate of bugs filed as it
> is), we don't see that as a good trade-off. You'd get backported drivers
> for stable releases, but the rate of development of the actual upstream
> drivers would be noticeably slowed, and fewer reported bugs would
> ultimately get fixed.
>
> Backporting packages is not intrinsically very difficult, though it is
> somewhat time-consuming, so it's something for which a far greater
> candidate pool exists than X driver development. Thus, the suggestion
> that someone else do it. For instance, you. It seems you've already
> successfully built the latest versions of things locally; if you can do
> that, you can put them in a package and put the package in a repository,
> it's not a very hard process and it's all documented on the Wiki.
>
I was thinking of doing that, I have done this sort of thing before, until
the drivers/drm/mesa needed changes in the XServer which is dependent on a
lot of things. I would then be fighting a battle with the main updates 
repositories for evermore, well until F12 which will then bring in its own
set of problems....



From awilliam at redhat.com  Thu Oct  8 18:39:12 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 08 Oct 2009 11:39:12 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <4ACE305D.40105@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<4ACE305D.40105@beam.ltd.uk>
Message-ID: <1255027153.2291.95.camel@adam.local.net>

On Thu, 2009-10-08 at 19:33 +0100, Terry Barnaby wrote:

> > Backporting packages is not intrinsically very difficult, though it is
> > somewhat time-consuming, so it's something for which a far greater
> > candidate pool exists than X driver development. Thus, the suggestion
> > that someone else do it. For instance, you. It seems you've already
> > successfully built the latest versions of things locally; if you can do
> > that, you can put them in a package and put the package in a repository,
> > it's not a very hard process and it's all documented on the Wiki.
> >
> I was thinking of doing that, I have done this sort of thing before, until
> the drivers/drm/mesa needed changes in the XServer which is dependent on a
> lot of things. I would then be fighting a battle with the main updates 
> repositories for evermore, well until F12 which will then bring in its own
> set of problems....

well, yes, and that's the exact reason it would be finicky and
time-consuming and not a good way for our X developers to spend their
time :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From pasik at iki.fi  Thu Oct  8 19:54:28 2009
From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=)
Date: Thu, 8 Oct 2009 22:54:28 +0300
Subject: preupgrade from f11 to rawhide broken? python traceback
In-Reply-To: 
References: <20090926161023.GZ31123@reaktio.net>
	
	<20091001195136.GN1434@reaktio.net>
	<20091007095105.GS1434@reaktio.net>
	
Message-ID: <20091008195428.GG1434@reaktio.net>

On Wed, Oct 07, 2009 at 08:19:28AM -0400, Seth Vidal wrote:
> 
> 
> On Wed, 7 Oct 2009, Pasi K?rkk?inen wrote:
> 
> >On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi K?rkk?inen wrote:
> >>>>Traceback (most recent call last):
> >>>>File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in 
> >>>>  pu.main(myrelease)
> >>>>File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main
> >>>>  self.generate_repo(cachedir, comps) # TODO: callback?
> >>>>File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 
> >>>>651,
> >>>>in generate_repo
> >>>>  misc.generate_repodata(dir,comps,callback)
> >>>>File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in
> >>>>generate_repodata
> >>>>  generate_repodata(dir, comps, callback)
> >>>>File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in
> >>>>generate_repodata_f9
> >>>>  mdgen.doRepoMetadata()
> >>>>File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 
> >>>>829,
> >>>>in doRepoMetadata
> >>>>  rp.getPrimary(complete_path, csum)
> >>>>File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in
> >>>>getPrimary
> >>>>  self.repoid))
> >>>>TypeError: Parsing primary.xml error: attributes construct error
> >>>>
> >>>>
> >>>>Known problem? How to fix it?
> >>>
> >>>this is the second time I've seen this one - if you can find
> >>>the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate
> >>>seeing it.
> >>>
> >>
> >># ls /var/cache/yum
> >>fedora  preupgrade  updates
> >>
> >># cd /var/cache/yum
> >>
> >># find -iname '*primary*'
> >>./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite
> >>./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite
> >>./preupgrade/.repodata/primary.xml.gz
> >>./preupgrade/.repodata/primary.xml.gz.sqlite
> >>./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite
> >>
> >>
> >>I put it available online here:
> >>http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
> >>
> >>Firefox complains about it btw..
> >>
> >>XML Parsing Error: not well-formed
> >>Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz
> >>Line Number 42622, Column 68:
> >>       >>      ver=""Saslauthd"/>
> >>-------------------------------------------------------------------^
> >>
> >
> >Does this help? Did you have time to take a look at it? Other people
> >seem to be having the same problem..
> >
> 
> update to yum from f11-updates (3.2.24) and the problem goes away.
> 
> -sv

Indeed, yum 3.2.24 fixed the problem.

Thanks!

-- Pasi



From jonstanley at gmail.com  Thu Oct  8 20:58:37 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 8 Oct 2009 16:58:37 -0400
Subject: Plan for tomorrow's (20091008) FESCo meeting
Message-ID: 

Following are a list of topics to be discussed at tomorrow's FESCo
meeting, taking place at 17:00UTC in #fedora-meeting on
irc.freenode.net

255	Proposal: Revert "Milestone Adjustment Proposal"
256	yum-presto by default
257	Fedora Packaging Committee items for ratification (2009-10-07)
254	Incomplete features

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.



From poelstra at redhat.com  Thu Oct  8 21:44:35 2009
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 08 Oct 2009 14:44:35 -0700
Subject: Fedora 12 Final Release Date Rescheduled to 2009-11-17
Message-ID: <4ACE5D43.5050305@redhat.com>

Update from the previous announcement on changes to the Fedora 12 
schedule described here:
https://www.redhat.com/archives/fedora-devel-announce/2009-October/msg00003.html

The deadline affecting the data center move which was putting a final 
release date if 2009-11-17 into question has been extended.  As a result 
we are now able to go forward with the original decision from the 
2009-10-05 Release Engineering meeting to move the final release date of 
Fedora 12 to 2009-11-17.

All of the schedules have been updated to reflect these changes.
Key milestones: https://fedoraproject.org/wiki/Releases/12

Detailed team schedules and ics (calendar) files:
http://poelstra.fedorapeople.org/schedules/f-12/

John




_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From airlied at redhat.com  Thu Oct  8 23:19:06 2009
From: airlied at redhat.com (Dave Airlie)
Date: Fri, 09 Oct 2009 09:19:06 +1000
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255019839.2291.91.camel@adam.local.net>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
Message-ID: <1255043946.18105.3.camel@localhost>

On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
> > No, I don't what to force testing on anyone (although F11 has done
> > that
> > already :) )
> > I was just suggesting that a separate yum archive with the packages
> > necessary
> > to test the later graphics development code that will be in F12 could
> > be
> > made available for people to try out easily with their F11 systems.
> > They can optionally try these. I think it will allow 3D to work for
> > many people
> > (from my experience of the latest GIT versions) although others would
> > not be so 
> > lucky. They can easily back these changes out if they have more issues
> > than
> > the standard graphics system. 
> 
> Then please feel free to make one. :) I don't mean that in a snide
> fashion, but it really is the answer. As noted, having our X.org
> developers spend time on such a repository directly subtracts that
> amount of time from the time they would otherwise spend actually
> developing the drivers (our X.org maintainers are also major upstream
> developers) and fixing reported bugs.

I thought about doing something like this the other day, but really
if we had something like Ubuntu PPA, which I think is on the longterm
plans for Fedora then it would be a lot easier to do.

At the moment its just too distracting to do.

The thing with doing updates for F11 is the regression rate due to
lack of QA, I put Mesa packages into updates-testing that fixed a 
lot of r300/r500 bugs back at the start of F11 and it went into
testing a few weeks later and broke Intel, I got 0 reports during that
u-t phase about breakage. So now I have a package in stable that
lets 3D works for x num of people and breaks compiz for y number.

So I've pretty much given up on pushing anything to previous Fedora
releases that isn't a security fix or major crash fix, because we simply
don't have the QA in place to avoid regression current users, at least
if you install F11 on your hw, and it doesn't work well, you know that,
if you install it and it works well then later stops working well, thats
a lot worse situation to end up in.

I think for F12 updates we could really do with some sort of side repo
setup, so we could have a stability period where QA could happen on 
packages that may end up in updates a month or two later.

Dave.

> Given that there is a lot of development work to do on these drivers
> (which is why you find the newer versions better...) and a lot of bugs
> to fix (we generally barely keep up with the rate of bugs filed as it
> is), we don't see that as a good trade-off. You'd get backported drivers
> for stable releases, but the rate of development of the actual upstream
> drivers would be noticeably slowed, and fewer reported bugs would
> ultimately get fixed.
> 
> Backporting packages is not intrinsically very difficult, though it is
> somewhat time-consuming, so it's something for which a far greater
> candidate pool exists than X driver development. Thus, the suggestion
> that someone else do it. For instance, you. It seems you've already
> successfully built the latest versions of things locally; if you can do
> that, you can put them in a package and put the package in a repository,
> it's not a very hard process and it's all documented on the Wiki.
> 
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
> 




From james at fedoraproject.org  Fri Oct  9 03:56:18 2009
From: james at fedoraproject.org (James Antill)
Date: Thu, 08 Oct 2009 23:56:18 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255043946.18105.3.camel@localhost>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
Message-ID: <1255060578.9958.11.camel@code.and.org>

On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote:
> On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
> > Then please feel free to make one. :) I don't mean that in a snide
> > fashion, but it really is the answer. As noted, having our X.org
> > developers spend time on such a repository directly subtracts that
> > amount of time from the time they would otherwise spend actually
> > developing the drivers (our X.org maintainers are also major upstream
> > developers) and fixing reported bugs.
> 
> I thought about doing something like this the other day, but really
> if we had something like Ubuntu PPA, which I think is on the longterm
> plans for Fedora then it would be a lot easier to do.
> 
> At the moment its just too distracting to do.
> 
> The thing with doing updates for F11 is the regression rate due to
> lack of QA, I put Mesa packages into updates-testing that fixed a 
> lot of r300/r500 bugs back at the start of F11 and it went into
> testing a few weeks later and broke Intel, I got 0 reports during that
> u-t phase about breakage. So now I have a package in stable that
> lets 3D works for x num of people and breaks compiz for y number.

 The problem is that PPAs/KoPeRs are going to get much less testing than
stuff in updates-testing, so if you don't think you are getting enough
testing in updates-testing I really don't see how KoPeRs will solve that
problem.

 Personally I'd suggest pushing to updates-testing but wait a _long_
time (maybe even never) before pushing to stable.
 Of course you are kind of screwed in having a package which might work
fine on one machine, but fail on many others.

> I think for F12 updates we could really do with some sort of side repo
> setup, so we could have a stability period where QA could happen on 
> packages that may end up in updates a month or two later.

 How would this be different from updates-testing? If you install
yum-plugin-aliases it even has predefined aliases lsuT and upT to get
the list of updates from testing, and update to them. bodhi has support
for it etc.

-- 
James Antill 
Fedora



From MathStuf at gmail.com  Fri Oct  9 04:30:37 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Fri, 09 Oct 2009 00:30:37 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

James Antill wrote:
>  The problem is that PPAs/KoPeRs are going to get much less 
testing than
> stuff in updates-testing, so if you don't think you are 
getting enough
> testing in updates-testing I really don't see how KoPeRs will 
solve that
> problem.
> 
>  Personally I'd suggest pushing to updates-testing but wait a 
_long_
> time (maybe even never) before pushing to stable.
>  Of course you are kind of screwed in having a package which 
might work
> fine on one machine, but fail on many others.
> 
>> I think for F12 updates we could really do with some sort of 
side repo
>> setup, so we could have a stability period where QA could 
happen on 
>> packages that may end up in updates a month or two later.
> 
>  How would this be different from updates-testing? If you 
install
> yum-plugin-aliases it even has predefined aliases lsuT and upT 
to get
> the list of updates from testing, and update to them. bodhi 
has support
> for it etc.

The problem with forcing two pipelines through u-t for one 
package is that if the stable package has something that needs 
to go through updates-testing, the new, possibly unstable, 
version shadows the new stable build. Side repos (preferably 
"themed" per s?; KDE updates separate from GNOME packages that 
the same maintainer happens to maintain as well so that users 
don't have to update something they use on the side and can't 
test as well) is the only way to fit a double pipeline for a 
single package through the update system as it stands.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L
nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9
oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU
qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt
iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv//
4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49
AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI
u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5
hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT
6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0
H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY
cIK16m8HKZQ0mYZOhgPe
=AIHy
-----END PGP SIGNATURE-----




From ilyes.gouta at gmail.com  Fri Oct  9 08:21:36 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Fri, 9 Oct 2009 09:21:36 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com> 
	<4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org> 
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to> 
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net> 
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	
Message-ID: <234fa2210910090121s25037d52hdd4adb31eefc3ad4@mail.gmail.com>

Hi,

I actually (think?) that I fixed the issue. It's all related to a
check in the intel i915 drm code in the kernel, which is still present
in the latest Fedora 2.6.30.8-64 kernel. It's in the form of
data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff
disabled for my i855GM. I compared with a stock kernel and found that
it was enabled by default for all the intel chips and just reverted
that change (and kept the other redhat patches, such as the mchbar and
the suspend/restore code) and well, it fixed my problem with Xv. I
think that the has_gem thing is exported for X11 and Xv user-space
through a GEM ioctl property and it doesn't interfere with the rest of
the kernel drm code. Anyway, it's working here :) Any confirmation
from redhat's engineers?

Regards,
Ilyes Gouta.

On Fri, Oct 9, 2009 at 5:30 AM, Ben Boeckel  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> James Antill wrote:
>> ?The problem is that PPAs/KoPeRs are going to get much less
> testing than
>> stuff in updates-testing, so if you don't think you are
> getting enough
>> testing in updates-testing I really don't see how KoPeRs will
> solve that
>> problem.
>>
>> ?Personally I'd suggest pushing to updates-testing but wait a
> _long_
>> time (maybe even never) before pushing to stable.
>> ?Of course you are kind of screwed in having a package which
> might work
>> fine on one machine, but fail on many others.
>>
>>> I think for F12 updates we could really do with some sort of
> side repo
>>> setup, so we could have a stability period where QA could
> happen on
>>> packages that may end up in updates a month or two later.
>>
>> ?How would this be different from updates-testing? If you
> install
>> yum-plugin-aliases it even has predefined aliases lsuT and upT
> to get
>> the list of updates from testing, and update to them. bodhi
> has support
>> for it etc.
>
> The problem with forcing two pipelines through u-t for one
> package is that if the stable package has something that needs
> to go through updates-testing, the new, possibly unstable,
> version shadows the new stable build. Side repos (preferably
> "themed" per s?; KDE updates separate from GNOME packages that
> the same maintainer happens to maintain as well so that users
> don't have to update something they use on the side and can't
> test as well) is the only way to fit a double pipeline for a
> single package through the update system as it stands.
>
> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L
> nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9
> oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU
> qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt
> iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv//
> 4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49
> AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI
> u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5
> hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT
> 6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0
> H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY
> cIK16m8HKZQ0mYZOhgPe
> =AIHy
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From terry1 at beam.ltd.uk  Fri Oct  9 08:35:23 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Fri, 09 Oct 2009 09:35:23 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255043946.18105.3.camel@localhost>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
Message-ID: <4ACEF5CB.6090709@beam.ltd.uk>

On 10/09/2009 12:19 AM, Dave Airlie wrote:
> On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
>> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
>>> No, I don't what to force testing on anyone (although F11 has done
>>> that
>>> already :) )
>>> I was just suggesting that a separate yum archive with the packages
>>> necessary
>>> to test the later graphics development code that will be in F12 could
>>> be
>>> made available for people to try out easily with their F11 systems.
>>> They can optionally try these. I think it will allow 3D to work for
>>> many people
>>> (from my experience of the latest GIT versions) although others would
>>> not be so
>>> lucky. They can easily back these changes out if they have more issues
>>> than
>>> the standard graphics system.
>>
>> Then please feel free to make one. :) I don't mean that in a snide
>> fashion, but it really is the answer. As noted, having our X.org
>> developers spend time on such a repository directly subtracts that
>> amount of time from the time they would otherwise spend actually
>> developing the drivers (our X.org maintainers are also major upstream
>> developers) and fixing reported bugs.
>
> I thought about doing something like this the other day, but really
> if we had something like Ubuntu PPA, which I think is on the longterm
> plans for Fedora then it would be a lot easier to do.
>
> At the moment its just too distracting to do.
>
> The thing with doing updates for F11 is the regression rate due to
> lack of QA, I put Mesa packages into updates-testing that fixed a
> lot of r300/r500 bugs back at the start of F11 and it went into
> testing a few weeks later and broke Intel, I got 0 reports during that
> u-t phase about breakage. So now I have a package in stable that
> lets 3D works for x num of people and breaks compiz for y number.
>
> So I've pretty much given up on pushing anything to previous Fedora
> releases that isn't a security fix or major crash fix, because we simply
> don't have the QA in place to avoid regression current users, at least
> if you install F11 on your hw, and it doesn't work well, you know that,
> if you install it and it works well then later stops working well, thats
> a lot worse situation to end up in.
>
> I think for F12 updates we could really do with some sort of side repo
> setup, so we could have a stability period where QA could happen on
> packages that may end up in updates a month or two later.
>
> Dave.
>
>> Given that there is a lot of development work to do on these drivers
>> (which is why you find the newer versions better...) and a lot of bugs
>> to fix (we generally barely keep up with the rate of bugs filed as it
>> is), we don't see that as a good trade-off. You'd get backported drivers
>> for stable releases, but the rate of development of the actual upstream
>> drivers would be noticeably slowed, and fewer reported bugs would
>> ultimately get fixed.
>>
>> Backporting packages is not intrinsically very difficult, though it is
>> somewhat time-consuming, so it's something for which a far greater
>> candidate pool exists than X driver development. Thus, the suggestion
>> that someone else do it. For instance, you. It seems you've already
>> successfully built the latest versions of things locally; if you can do
>> that, you can put them in a package and put the package in a repository,
>> it's not a very hard process and it's all documented on the Wiki.
>>
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>> http://www.happyassassin.net
>>
>
>
I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
seen any real set of tests to be performed on Fedora 3D graphics.
I tried the ATI test day for graphics. On the 3D graphics side it said to
run "glxgears" and if you like other 3D apps that you use. Running your
other 3D apps is difficult from a limited Live distribution...
I really think a simple test procedure should be implemented and documented
to at least check for basic functionality with the main 3D applications.
Ideally an automatic test program should be part of this.
This would allow a relative novice to test the 3D system on their hardware
and hopefully automatically feed back constructive results from the
myriad of different graphics hardware options.




From rjones at redhat.com  Fri Oct  9 08:36:39 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 9 Oct 2009 09:36:39 +0100
Subject: Easy review swap
In-Reply-To: <4ACE2D8B.6090602@redhat.com>
References: <20091008124447.GA2338@amd.home.annexia.org>
	<4ACE2D8B.6090602@redhat.com>
Message-ID: <20091009083639.GA14628@amd.home.annexia.org>

On Thu, Oct 08, 2009 at 02:20:59PM -0400, William Cohen wrote:
> Richard W.M. Jones wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=527971
> > OCaml framework for Functional Reactive Programming (FRP)
> > 
> > The whole library is a single file, it's rpmlint clean, and there's a
> > Koji scratch build.
> > 
> > I'll swap for a similarly easy review.
> > 
> > Rich.
> > 
> 
> I could trade you the papi package for review. It isn't quite as simple, but I
> have gone through the fedora package review checklist and made a couple
> iterations on the papi srpm:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=525346
> Review Request: papi - Performance Application Programming Interface
> 
> A scratch build has been put through koji:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1722841

PAPI sounded like a very interesting program that I'd not heard
of before, so I've taken that bug.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From ilyes.gouta at gmail.com  Fri Oct  9 09:00:50 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Fri, 9 Oct 2009 10:00:50 +0100
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <234fa2210910090121s25037d52hdd4adb31eefc3ad4@mail.gmail.com>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com> 
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> 
	<20091008125159.GA25579@wolff.to> <4ACDE392.1060208@beam.ltd.uk> 
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> 
	<1255060578.9958.11.camel@code.and.org>  
	<234fa2210910090121s25037d52hdd4adb31eefc3ad4@mail.gmail.com>
Message-ID: <234fa2210910090200v36da2697pc92e0221facaa9d5@mail.gmail.com>

Obviously i915.modeset == 0 all the time (including when I reported the issue).

-Ilyes

On Fri, Oct 9, 2009 at 9:21 AM, Ilyes Gouta  wrote:
> Hi,
>
> I actually (think?) that I fixed the issue. It's all related to a
> check in the intel i915 drm code in the kernel, which is still present
> in the latest Fedora 2.6.30.8-64 kernel. It's in the form of
> data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff
> disabled for my i855GM. I compared with a stock kernel and found that
> it was enabled by default for all the intel chips and just reverted
> that change (and kept the other redhat patches, such as the mchbar and
> the suspend/restore code) and well, it fixed my problem with Xv. I
> think that the has_gem thing is exported for X11 and Xv user-space
> through a GEM ioctl property and it doesn't interfere with the rest of
> the kernel drm code. Anyway, it's working here :) Any confirmation
> from redhat's engineers?
>
> Regards,
> Ilyes Gouta.
>
> On Fri, Oct 9, 2009 at 5:30 AM, Ben Boeckel  wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> James Antill wrote:
>>> ?The problem is that PPAs/KoPeRs are going to get much less
>> testing than
>>> stuff in updates-testing, so if you don't think you are
>> getting enough
>>> testing in updates-testing I really don't see how KoPeRs will
>> solve that
>>> problem.
>>>
>>> ?Personally I'd suggest pushing to updates-testing but wait a
>> _long_
>>> time (maybe even never) before pushing to stable.
>>> ?Of course you are kind of screwed in having a package which
>> might work
>>> fine on one machine, but fail on many others.
>>>
>>>> I think for F12 updates we could really do with some sort of
>> side repo
>>>> setup, so we could have a stability period where QA could
>> happen on
>>>> packages that may end up in updates a month or two later.
>>>
>>> ?How would this be different from updates-testing? If you
>> install
>>> yum-plugin-aliases it even has predefined aliases lsuT and upT
>> to get
>>> the list of updates from testing, and update to them. bodhi
>> has support
>>> for it etc.
>>
>> The problem with forcing two pipelines through u-t for one
>> package is that if the stable package has something that needs
>> to go through updates-testing, the new, possibly unstable,
>> version shadows the new stable build. Side repos (preferably
>> "themed" per s?; KDE updates separate from GNOME packages that
>> the same maintainer happens to maintain as well so that users
>> don't have to update something they use on the side and can't
>> test as well) is the only way to fit a double pipeline for a
>> single package through the update system as it stands.
>>
>> - --Ben
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L
>> nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9
>> oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU
>> qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt
>> iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv//
>> 4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49
>> AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI
>> u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5
>> hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT
>> 6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0
>> H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY
>> cIK16m8HKZQ0mYZOhgPe
>> =AIHy
>> -----END PGP SIGNATURE-----
>>
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>



From andreas.tunek at gmail.com  Fri Oct  9 12:08:41 2009
From: andreas.tunek at gmail.com (Andreas Tunek)
Date: Fri, 9 Oct 2009 14:08:41 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACEF5CB.6090709@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
Message-ID: 

2009/10/9 Terry Barnaby :
> On 10/09/2009 12:19 AM, Dave Airlie wrote:
>>
>> On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
>>>
>>> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
>>>>
>>>> No, I don't what to force testing on anyone (although F11 has done
>>>> that
>>>> already :) )
>>>> I was just suggesting that a separate yum archive with the packages
>>>> necessary
>>>> to test the later graphics development code that will be in F12 could
>>>> be
>>>> made available for people to try out easily with their F11 systems.
>>>> They can optionally try these. I think it will allow 3D to work for
>>>> many people
>>>> (from my experience of the latest GIT versions) although others would
>>>> not be so
>>>> lucky. They can easily back these changes out if they have more issues
>>>> than
>>>> the standard graphics system.
>>>
>>> Then please feel free to make one. :) I don't mean that in a snide
>>> fashion, but it really is the answer. As noted, having our X.org
>>> developers spend time on such a repository directly subtracts that
>>> amount of time from the time they would otherwise spend actually
>>> developing the drivers (our X.org maintainers are also major upstream
>>> developers) and fixing reported bugs.
>>
>> I thought about doing something like this the other day, but really
>> if we had something like Ubuntu PPA, which I think is on the longterm
>> plans for Fedora then it would be a lot easier to do.
>>
>> At the moment its just too distracting to do.
>>
>> The thing with doing updates for F11 is the regression rate due to
>> lack of QA, I put Mesa packages into updates-testing that fixed a
>> lot of r300/r500 bugs back at the start of F11 and it went into
>> testing a few weeks later and broke Intel, I got 0 reports during that
>> u-t phase about breakage. So now I have a package in stable that
>> lets 3D works for x num of people and breaks compiz for y number.
>>
>> So I've pretty much given up on pushing anything to previous Fedora
>> releases that isn't a security fix or major crash fix, because we simply
>> don't have the QA in place to avoid regression current users, at least
>> if you install F11 on your hw, and it doesn't work well, you know that,
>> if you install it and it works well then later stops working well, thats
>> a lot worse situation to end up in.
>>
>> I think for F12 updates we could really do with some sort of side repo
>> setup, so we could have a stability period where QA could happen on
>> packages that may end up in updates a month or two later.
>>
>> Dave.
>>
>>> Given that there is a lot of development work to do on these drivers
>>> (which is why you find the newer versions better...) and a lot of bugs
>>> to fix (we generally barely keep up with the rate of bugs filed as it
>>> is), we don't see that as a good trade-off. You'd get backported drivers
>>> for stable releases, but the rate of development of the actual upstream
>>> drivers would be noticeably slowed, and fewer reported bugs would
>>> ultimately get fixed.
>>>
>>> Backporting packages is not intrinsically very difficult, though it is
>>> somewhat time-consuming, so it's something for which a far greater
>>> candidate pool exists than X driver development. Thus, the suggestion
>>> that someone else do it. For instance, you. It seems you've already
>>> successfully built the latest versions of things locally; if you can do
>>> that, you can put them in a package and put the package in a repository,
>>> it's not a very hard process and it's all documented on the Wiki.
>>>
>>> --
>>> Adam Williamson
>>> Fedora QA Community Monkey
>>> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>>> http://www.happyassassin.net
>>>
>>
>>
> I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
> seen any real set of tests to be performed on Fedora 3D graphics.
> I tried the ATI test day for graphics. On the 3D graphics side it said to
> run "glxgears" and if you like other 3D apps that you use. Running your
> other 3D apps is difficult from a limited Live distribution...
> I really think a simple test procedure should be implemented and documented
> to at least check for basic functionality with the main 3D applications.
> Ideally an automatic test program should be part of this.
> This would allow a relative novice to test the 3D system on their hardware
> and hopefully automatically feed back constructive results from the
> myriad of different graphics hardware options.
>
>
Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
tests and removes stuff like abiword and gnumeric?

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jwboyer at gmail.com  Fri Oct  9 12:30:41 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 9 Oct 2009 08:30:41 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: 
References: <4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
	
Message-ID: <20091009123040.GK30884@hansolo.jdub.homelinux.org>

On Fri, Oct 09, 2009 at 02:08:41PM +0200, Andreas Tunek wrote:
>Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
>tests and removes stuff like abiword and gnumeric?

If the tests are in Fedora and you find someone willing to create the
kickstart file for the spin, sure.

josh



From mhlavink at redhat.com  Fri Oct  9 13:31:45 2009
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Fri, 9 Oct 2009 15:31:45 +0200
Subject: does fedora have anything requiring :mail rw access?
Message-ID: <200910091531.45573.mhlavink@redhat.com>

Hi all!

I've got quite simple question from dovecot's upstream: Why do we have rw 
access on mails for mail group? Why /var/mail/ files have 0660 
:mail permissions instead of 0600 permissions? The fact is, I don't 
know the answer and I'd appreciate your help.

Some facts:

distro   | group | perm
---------+-------+---------
Fedora   | mail  | 0660
Ubuntu   | mail  | 0600
openSuSE | users | 0600 (user is member of users group)
debian 4.0 | mail | 0660

(Note: This is result of my own investigations on installed systems or 
livecds, I don't know if any installed system had changed settings.)

Interesting thing is, that when new user is added to the system, useradd 
creates /var/mail/ file with :mail 0660 permissions, but 
when you delete this file and the user gets new email, this file will be 
autocreated with 0600 permissions (still :group owned) and it seems 
everything still works.

useradd command comes from shadow-utils and fedora contains no patch changing 
permissions to 0660.

The most important question is: Is there anything that requires these files can 
be read and written by mail group? 

If you have any info regarding this, please share.

Thanks,
Michal Hlavinka



From mhlavink at redhat.com  Fri Oct  9 13:48:47 2009
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Fri, 9 Oct 2009 15:48:47 +0200
Subject: does fedora have anything requiring :mail rw access?
In-Reply-To: <200910091531.45573.mhlavink@redhat.com>
References: <200910091531.45573.mhlavink@redhat.com>
Message-ID: <200910091548.48252.mhlavink@redhat.com>

On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote:

> The most important question is: Is there anything that requires these files
>  can be read and written by mail group?

Well, I already know one, cyrus-imapd most probably requires mail rw. Is there 
anything else?



From mmcgrath at redhat.com  Fri Oct  9 14:36:34 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 9 Oct 2009 09:36:34 -0500 (CDT)
Subject: does fedora have anything requiring :mail rw access?
In-Reply-To: <200910091531.45573.mhlavink@redhat.com>
References: <200910091531.45573.mhlavink@redhat.com>
Message-ID: 

On Fri, 9 Oct 2009, Michal Hlavinka wrote:

> Hi all!
>
> I've got quite simple question from dovecot's upstream: Why do we have rw
> access on mails for mail group? Why /var/mail/ files have 0660
> :mail permissions instead of 0600 permissions? The fact is, I don't
> know the answer and I'd appreciate your help.
>
> Some facts:
>
> distro   | group | perm
> ---------+-------+---------
> Fedora   | mail  | 0660
> Ubuntu   | mail  | 0600
> openSuSE | users | 0600 (user is member of users group)
> debian 4.0 | mail | 0660
>
> (Note: This is result of my own investigations on installed systems or
> livecds, I don't know if any installed system had changed settings.)
>
> Interesting thing is, that when new user is added to the system, useradd
> creates /var/mail/ file with :mail 0660 permissions, but
> when you delete this file and the user gets new email, this file will be
> autocreated with 0600 permissions (still :group owned) and it seems
> everything still works.
>
> useradd command comes from shadow-utils and fedora contains no patch changing
> permissions to 0660.
>
> The most important question is: Is there anything that requires these files can
> be read and written by mail group?
>
> If you have any info regarding this, please share.
>

Just a guess, but if you run useradd from shell, your umask is likely
0002.  Sendmail's umask is probably 022 as set in /etc/init.d/functions

That might explain the difference, as to why it's done that way I don't
know.

	-Mike



From awilliam at redhat.com  Fri Oct  9 14:57:51 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 09 Oct 2009 07:57:51 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
	
Message-ID: <1255100271.2339.6.camel@adam.local.net>

On Fri, 2009-10-09 at 14:08 +0200, Andreas Tunek wrote:

> Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
> tests and removes stuff like abiword and gnumeric?

We're not huge fans of the Phoronix tests for a variety of reasons
(including that you don't really have a clue what it's installing most
of the time). It would be nice to have more comprehensive 3D tests.
Frankly, the reason they're so rudimentary ATM is that even basic 3D
functionality is broken in sufficient numbers of cases to keep the
developers busy...basic 3D or Compiz was broken in the majority of cases
in both the Intel and Radeon test days this time around (although I
think those bugs are fixed now). But if people want to contribute more
extensive 3D test cases, that would be awesome, and the kind of
contribution we'd love to have to the QA group.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From ndbecker2 at gmail.com  Fri Oct  9 15:15:45 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Oct 2009 11:15:45 -0400
Subject: does fedora have anything requiring :mail rw access?
References: <200910091531.45573.mhlavink@redhat.com>
	<200910091548.48252.mhlavink@redhat.com>
Message-ID: 

Michal Hlavinka wrote:

> On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote:
> 
>> The most important question is: Is there anything that requires these
>> files
>>  can be read and written by mail group?
> 
> Well, I already know one, cyrus-imapd most probably requires mail rw. Is
> there anything else?
> 

The default exim config says:

# This transport is used for local delivery to user mailboxes in traditional
# BSD mailbox format. By default it will be run under the uid and gid of the
# local user, and requires the sticky bit to be set on the /var/mail 
directory.
# Some systems use the alternative approach of running mail deliveries under 
a
# particular group instead of using the sticky bit. The commented options 
below
# show how this can be done.




From ndbecker2 at gmail.com  Fri Oct  9 15:21:42 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Oct 2009 11:21:42 -0400
Subject: does fedora have anything requiring :mail rw access?
References: <200910091531.45573.mhlavink@redhat.com>
	<200910091548.48252.mhlavink@redhat.com>
	
Message-ID: 

Neal Becker wrote:

> Michal Hlavinka wrote:
> 
>> On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote:
>> 
>>> The most important question is: Is there anything that requires these
>>> files
>>>  can be read and written by mail group?
>> 
>> Well, I already know one, cyrus-imapd most probably requires mail rw. Is
>> there anything else?
>> 
> 
> The default exim config says:
> 
> # This transport is used for local delivery to user mailboxes in
> # traditional BSD mailbox format. By default it will be run under the uid
> # and gid of the local user, and requires the sticky bit to be set on the
> # /var/mail
> directory.
> # Some systems use the alternative approach of running mail deliveries
> # under
> a
> # particular group instead of using the sticky bit. The commented options
> below
> # show how this can be done.
> 
> 

I should have been clearer- the default exim config used the mail group 
method:
local_delivery:
  driver = appendfile
  file = /var/mail/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660




From dwalsh at redhat.com  Fri Oct  9 15:48:50 2009
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 09 Oct 2009 11:48:50 -0400
Subject: If you are building a dbus/PolicyKit "mechanism" please tell SELinux
 developers about it.
Message-ID: <4ACF5B62.1020302@redhat.com>

Remember if you need to build a tool that will run partially as root, we would like to write policy to confine it.  A badly written Dbus activation service, can be just as dangerous as a badly written setuid application.  We need to have SELinux confinement on the "root" portion of your application.

Dan



From bruno at wolff.to  Fri Oct  9 16:15:46 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 9 Oct 2009 11:15:46 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <4ACEF5CB.6090709@beam.ltd.uk>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
Message-ID: <20091009161546.GA4422@wolff.to>

On Fri, Oct 09, 2009 at 09:35:23 +0100,
  Terry Barnaby  wrote:
> I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
> seen any real set of tests to be performed on Fedora 3D graphics.
> I tried the ATI test day for graphics. On the 3D graphics side it said to
> run "glxgears" and if you like other 3D apps that you use. Running your
> other 3D apps is difficult from a limited Live distribution...

Try the games spin. I have a related problem in that it is hard for me as
the spin maintainer to test the 3d games on the spin because the stock
drivers haven't been supporting 3d on any of my machines at home. And
3d testing on my work machine (which also hasn't worked real well) is
pretty limited to testing that 3d works on that machine, not really the
kind of testing of the spin that I'd like to do to test the spin itself.

> I really think a simple test procedure should be implemented and documented
> to at least check for basic functionality with the main 3D applications.

I am supposed to be doing test cases for the games spin. That isn't going to
get done for F12 though.

> Ideally an automatic test program should be part of this.
> This would allow a relative novice to test the 3D system on their hardware
> and hopefully automatically feed back constructive results from the
> myriad of different graphics hardware options.



From chasd at silveroaks.com  Fri Oct  9 16:22:33 2009
From: chasd at silveroaks.com (chasd)
Date: Fri, 9 Oct 2009 11:22:33 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <20091009152233.C671061885A@hormel.redhat.com>
References: <20091009152233.C671061885A@hormel.redhat.com>
Message-ID: <8568602E-C2D3-4F5F-86F7-47ECEEE39A11@silveroaks.com>

It's Friday, so I'll allow myself to digress -

Ilyes Gouta wrote:

> think that the has_gem thing is exported for X11 and Xv user-space
> through a GEM ioctl property and it doesn't interfere with the rest of

Whenever I see " GEM " I get weird DOS GUI flashbacks, and they hurt.
Couldn't they have called it something else ?
( Not expecting an answer )


-- 
Charles Dostale



From henrik at kaarposoft.dk  Fri Oct  9 16:20:44 2009
From: henrik at kaarposoft.dk (Henrik /KaarPoSoft)
Date: Fri, 09 Oct 2009 18:20:44 +0200
Subject: Development packages for Thunderbird/Sunbird
Message-ID: <4ACF62DC.9010702@kaarposoft.dk>

Dear Fedora developers!

I am the developer of blueZync (see http://bluezync.kaarposoft.dk/)
which is based on OpenSync (see http://www.opensync.org/).

blueZync can synchronize Thunderbird/Sunbird with a mobile phone
(and many other peers).

I would like blueZync to work on Fedora too
(currently developing on Debian and Ubuntu).

However, to compile blueZync, development packages for
thunderbird and sunbird are needed
(i.e. header files, idl files etc).

As far as I can see, not such -devel packages are available
for Fedora 11 or 12.

Can anybody guide me as to how to kindly request such
packages for Fedora?

I have looked at
https://fedoraproject.org/wiki/Package_maintainers_wishlist
but since I am not a Fedora maintainer,
it seems I cannot add my wish here...

Thanks in advance for any help...

/Henrik



From rawhide at fedoraproject.org  Fri Oct  9 17:30:01 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 9 Oct 2009 17:30:01 +0000
Subject: rawhide report: 20091009 changes
Message-ID: <20091009173001.GA20760@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct  9 06:45:02 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package couchdb-glib
        A glib api to access CouchDB servers
New package dalston
        Moblin System Information Icons
Updated Packages:

anaconda-12.35-1.fc12
---------------------
* Thu Oct 08 2009 Radek Vykydal  - 12.35-1
- Override fstabSpec in PartitionDevice for by-path DASD (#526364). (dcantrell)
- Create DASDDevice objects for DASD devices when building devicetree. 
  (dcantrell)
- Add udev_device_is_dasd() to detect DASD devices. (dcantrell)
- Change existing call to deviceNameToDiskByPath(). (dcantrell)
- Make storage.devices.deviceNameToDiskByPath() more robust. (dcantrell)
- Do not copy over 70-persistent.rules if instPath is '' (#527707) (dcantrell)
- Filter out 'Sending translation for' log messages in bumpver. (dcantrell)
- Don't copy _raidSet, but merely pass around a reference (hdegoede)
- Action...Format setup device before modifying the partition table (hdegoede)
- map() -> filter() in storage.writeEscrowPackets() (dcantrell)
- Only initialize escrow packet code if there's devices that need it (#527668).
  (clumens)
- Stop trying to run xrandr (#527678). (clumens)
- On lookup of a PartedDevice also check for _ped.DeviceException (#527699)
  (hdegoede)
- Set related ayum attributes if media is found when editing methodstr
  (#515441). (rvykydal)
- In repo editing UI do not use object we are creating (#515441). (rvykydal)

* Tue Oct 06 2009 David Cantrell  - 12.34-1
- Tell udev to ignore temporary cryptsetup devices. (#526699) (dlehman)
- Use $LIBDIR to find the boot-wrapper file. (jkeating)
- Have redhat.exec reference generic.prm, not redhat.parm (dcantrell)
- Bring back cio_ignore=all, !0.0.0009 for generic.prm on s390x (#463544)
  (dcantrell)
- Take 70-persistent-net.rules generated at installation (#526322)
  (dcantrell)
- formatByDefault: Don't traceback when mountpoint is None (#522609)
  (hdegoede)
- Don't warn /usr should be formatted when "Format as:" is already selected
  (hdegoede)
- Bring up network interface before trying to use it for FCoE (hdegoede)
- DMRaidArray: Don't report no media present when in teared down state
  (hdegoede)
- Wait for udev to settle before trying to find dmraid sets in udev DB
  (hdegoede)


cups-1.4.1-9.fc12
-----------------
* Thu Oct 08 2009 Tim Waugh  1:1.4.1-9
- Fixed naming of 'Generic PostScript Printer' entry.

* Wed Oct 07 2009 Tim Waugh  1:1.4.1-8
- Use upstream patch for STR #3356 (bug #526405).

* Fri Oct 02 2009 Tim Waugh  1:1.4.1-7
- Fixed orientation of page labels when printing text in landscape
  mode (bug #520141, STR #3334).


dracut-002-13.git8f397a9b.fc12
------------------------------
* Wed Oct 07 2009 Harald Hoyer  002-13
- fixed init= handling
- kill loginit if "rdinitdebug" specified
- run dmsquash-live-root after udev has settled (bug #527514)


gnome-keyring-2.28.0-3.fc12
---------------------------
* Thu Oct 08 2009 Matthias Clasen  - 2.28.0-3
- Fix handling of rsa1 keys


gnome-panel-2.28.0-4.fc12
-------------------------
* Thu Oct 08 2009 Matthias Clasen  2.28.0-3
- Accept more bookmarks in the places menu before overflowing

* Thu Oct 08 2009 Matthias Clasen  2.28.0-4
- Fix possible crashes related to randr events


gnome-shell-2.28.0-3.fc12
-------------------------
* Wed Oct 07 2009 Owen Taylor  - 2.28.0-1
- Update to 2.28.0


gnome-vfs2-2.24.2-1.fc12
------------------------
* Thu Oct 08 2009 Alexander Larsson  - 2.24.2-1
- update to 2.24.2 - fixes mimetypes


gtk-vnc-0.3.9-2.fc12
--------------------
* Thu Oct 08 2009 Matthias Clasen  - 0.3.9-2
- Request a full screen refresh when receives a desktop-resize encoding


libgnomekbd-2.28.0-2.fc12
-------------------------
* Thu Oct 08 2009 Matthias Clasen  - 2.28.0-2
- Incorporate visual fixes from upstream


parted-1.9.0-17.fc12
--------------------
* Thu Oct 08 2009 Hans de Goede  1.9.0-17
- Only change the partition type to 82 when setting the swap flag on dos
  labels, not when resetting it

* Tue Oct 06 2009 Hans de Goede  1.9.0-15
- ped_partition_is_busy() should not throw exceptions (#527035)
- msdos_partition_is_flag_available() should return 1 for swap flag (#513729)

* Tue Oct 06 2009 Hans de Goede  1.9.0-16
- Correctly handle GPT labels on big endian machines


plymouth-0.8.0-0.2009.29.09.7.fc12
----------------------------------
* Thu Oct 08 2009 Ray Strode  0.8.0-0.2009.29.09.7
- Fix emergency shell horkage (bug 526597)
- Fix problem with details splash not showing up (bug 527426, bug 527254)


python-markdown2-1.0.1.15-1.fc12
--------------------------------
* Thu Oct 08 2009 Thomas Moschny  - 1.0.1.15-1
- Update to 1.0.1.15. Fixes three issues, two of them being
  security-related.


python-pyblock-0.44-1.fc12
--------------------------
* Wed Oct 07 2009 Hans de Goede  - 0.44-1
- Use dmraid's status instead of figuring out if a set is degraded ourselves
  (#524168)
- Fix typo causing backtrace when doing activate deactivate 2x for dmraid 10


shared-mime-info-0.70-3.fc12
----------------------------
* Thu Oct 08 2009 Bastien Nocera  0.70-2
- Fix brasero desktop filenames

* Thu Oct 08 2009 Bastien Nocera  0.70-3
- Fix gnumeric, gthumb and abiword desktop files


system-config-firewall-1.2.21-1.fc12
------------------------------------
* Thu Oct 08 2009 Thomas Woerner  1.2.21-1
- fixed Policykit v0 compatibility for Fedora version 10 and 11: python-slip
  for PolicyKit v0 does not provide dbus
- updated translations: bn_IN, uk, zh_CN


vorbis-tools-1.2.0-6.fc12
-------------------------
* Tue Oct 06 2009 Kamil Dudka  - 1:1.2.0-6
- upstream patch fixing crash of oggenc --resample (#526653)


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 16



From kwhiskerz at gmail.com  Fri Oct  9 17:41:34 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 09 Oct 2009 11:41:34 -0600
Subject: Why SELinux is preventing /usr/lib64/nspluginwrapper/npviewer.bin
	"execmem" access on ?
Message-ID: 

I have noticed that trying to play some videos on You 
Tube generates this selinux denial and the video refuses 
to play.

However, other videos on You Tube don't generate this 
error and play just peachy.

What makes the videos different to selinux?




From poelstra at redhat.com  Fri Oct  9 17:43:28 2009
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 09 Oct 2009 10:43:28 -0700
Subject: Plan for tomorrow's (20091008) FESCo meeting
In-Reply-To: 
References: 
Message-ID: <4ACF7640.9040200@redhat.com>

Jon Stanley said the following on 10/08/2009 01:58 PM Pacific Time:
> Following are a list of topics to be discussed at tomorrow's FESCo
> meeting, taking place at 17:00UTC in #fedora-meeting on
> irc.freenode.net
> 
> 255	Proposal: Revert "Milestone Adjustment Proposal"
> 256	yum-presto by default
> 257	Fedora Packaging Committee items for ratification (2009-10-07)
> 254	Incomplete features
> 
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
> 
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor.
> 

We also have a reworked page for DisplayPort that reflects everything 
completed for Fedora 12 that the feature owner would like reconsidered 
by FESCo.

https://fedoraproject.org/wiki/Features/DisplayPort

John



From jonstanley at gmail.com  Fri Oct  9 17:48:54 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 9 Oct 2009 13:48:54 -0400
Subject: FESCo meeting summary for 20091009
Message-ID: 

=======================================
#fedora-meeting: FESCo meeting 20091009
=======================================


Meeting started by jds2001 at 17:00:16 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-09/fedora-meeting.2009-10-09-17.00.log.html
.



Meeting summary
---------------
* Revert Milestone adjustment  (jds2001, 17:01:36)
  * LINK: http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule
    (Kevin_Kofler, 17:02:29)
  * AGREED: Milestone Adjustment will not be reverted  (jds2001,
    17:03:13)

* yum-presto by default  (jds2001, 17:03:23)
  * AGREED: yum-presto is accepted as default for F12  (jds2001,
    17:12:02)

* FPC report  (jds2001, 17:12:13)
  * AGREED: rpath packaging draft is approved  (jds2001, 17:16:40)
  * AGREED: dir ownership packaging draft is approved  (jds2001,
    17:16:55)

* incomplete features  (jds2001, 17:17:17)
  * AGREED: DisplayPort feature was accepted with reduced scope (Intel
    only) via email  (jds2001, 17:18:39)

* open floor  (jds2001, 17:19:13)
  * AGREED: jwb resigns from FESCo to focus on other Fedora issues.
    jds2001 will initiate the succession process for the remainder of
    this term  (jwb_, 17:29:14)
  * LINK: https://fedoraproject.org/wiki/FESCo_election_policy
    (jds2001, 17:32:53)
  * HELP: teachers are needed for the Fedora classroom, please help!
    (jds2001, 17:45:18)

Meeting ended at 17:46:24 UTC.




Action Items
------------





Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* jds2001 (72)
* Kevin_Kofler (44)
* nirik (30)
* jwb_ (29)
* skvidal (19)
* j-rod (16)
* notting (13)
* zodbot_ (8)
* dgilmore (8)
* sharkcz (6)
* Oxf13 (3)
* jwb (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



From jlaska at redhat.com  Fri Oct  9 17:49:48 2009
From: jlaska at redhat.com (James Laska)
Date: Fri, 09 Oct 2009 13:49:48 -0400
Subject: Fedora 12 Beta Blocker Meeting :: 2009-10-09 @ 15:00 UTC (11 AM
 EDT) - Recap
In-Reply-To: <4ACD2686.20409@redhat.com>
References: <4ACD2686.20409@redhat.com>
Message-ID: <1255110588.2444.9.camel@localhost.localdomain>

=======================================================
#fedora-bugzappers: F-12Beta Blocker Bug Review meeting
=======================================================


Meeting started by jlaska at 15:00:17 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-09/fedora-bugzappers.2009-10-09-15.00.log.html
.



Meeting summary
---------------
* gathering minds ...  (jlaska, 15:00:53)

* https://bugzilla.redhat.com/show_bug.cgi?id=517260  (jlaska, 15:06:19)
  * jlaska unable to reproduce 517260 using the procedure posted to the
    bugzilla  (jlaska, 15:11:05)
  * AGREED: 517260 will be moved to F12Blocker and accepted post-beta
    (jlaska, 15:13:27)

* https://bugzilla.redhat.com/show_bug.cgi?id=526208  (jlaska, 15:13:36)
  * "as discussed previously, preupgrade can be fixed in an F11 updates
    push after Beta" -wwoods  (jlaska, 15:18:16)
  * "I think the first step toward identifying the problem would be to
    narrow 'between 2.16.0 and 2.16.6 to a single version step" -mclasen
    (jlaska, 15:29:07)
  * LINK: http://git.gnome.org/cgit/gtk+/log/?h=gtk-2-16   (mclasen,
    15:31:04)
  * AGREED: wwoods and mclasen will continue to identify root cause on
    526208 with the goal of a new F-11 update in time for F-12-Beta
    (jlaska, 15:44:17)

* https://bugzilla.redhat.com/show_bug.cgi?id=517260  (jlaska, 15:44:34)
  * ACTION: jlaska will work w/ dlehman to verify the bug#517260 patch
    before it hits next anaconda  (jlaska, 15:51:00)

* https://bugzilla.redhat.com/show_bug.cgi?id=526320  (jlaska, 15:51:17)
  * LINK:
    http://kojipkgs.fedoraproject.org/mash/rawhide-20091009/development/ppc/os/images/netboot/
    (jlaska, 15:52:23)

* https://bugzilla.redhat.com/show_bug.cgi?id=526899  (jlaska, 15:53:15)
  * AGREED: 526899 will stay on beta blocker awaiting review from
    dlehman  (jlaska, 16:06:05)

* https://bugzilla.redhat.com/show_bug.cgi?id=528077  (jlaska, 16:06:15)
  * AGREED: retest 528077 on live images built today and provide
    feedback in bz  (jlaska, 16:15:19)

* https://bugzilla.redhat.com/show_bug.cgi?id=498026  (jlaska, 16:16:48)
  * AGREED: 498026 will remain on list - dlehman will have a patch
    available soon for verification  (jlaska, 16:32:16)

* https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=527920  (jlaska,
  16:32:52)
  * AGREED: 527920 affects all ldap and krb users during gdm login ...
    accepted as a beta blocker  (jlaska, 16:40:57)

* Open discussion  (jlaska, 16:41:42)

* Beta Compose Readiness  (jlaska, 16:43:39)
  * LINK:
    https://www.redhat.com/archives/fedora-test-list/2009-October/msg00132.html
    (jlaska, 16:46:28)
  * once the F12Beta bugs are all in MODIFIED (exluding preupgrade
    526208) - RC compose will proceed  (jlaska, 16:49:55)

Meeting ended at 16:50:12 UTC.




Action Items
------------
* jlaska will work w/ dlehman to verify the bug#517260 patch before it
  hits next anaconda




Action Items, by person
-----------------------
* jlaska
  * jlaska will work w/ dlehman to verify the bug#517260 patch before it
    hits next anaconda
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* jlaska (189)
* adamw (87)
* Oxf13 (52)
* wwoods (44)
* mclasen (21)
* halfline (15)
* buggbot (14)
* greenlion (13)
* rjune_wrk (11)
* denise (10)
* warren (7)
* notting (5)
* greenlion1 (3)
* zodbot_ (2)
* poelcat (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From dwalsh at redhat.com  Fri Oct  9 18:48:43 2009
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 09 Oct 2009 14:48:43 -0400
Subject: Why SELinux is preventing
 /usr/lib64/nspluginwrapper/npviewer.bin
 "execmem" access on ?
In-Reply-To: 
References: 
Message-ID: <4ACF858B.70308@redhat.com>

On 10/09/2009 01:41 PM, Petrus de Calguarium wrote:
> I have noticed that trying to play some videos on You 
> Tube generates this selinux denial and the video refuses 
> to play.
> 
> However, other videos on You Tube don't generate this 
> error and play just peachy.
> 
> What makes the videos different to selinux?
> 
> 
Probably code paths on flashplayer are causing execmem while others are not.


Which Version of the OS/Policy are you seeing execmem problems at youtube?



From kwhiskerz at gmail.com  Fri Oct  9 18:53:03 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 09 Oct 2009 12:53:03 -0600
Subject: Why SELinux is preventing
	/usr/lib64/nspluginwrapper/npviewer.bin "execmem" access on
	?
References:  <4ACF858B.70308@redhat.com>
Message-ID: 

Daniel J Walsh wrote:

> Which Version of the OS/Policy are you seeing execmem 
problems at youtube?

selinux-policy-targeted-3.6.32-22.fc12.noarch

Using f11.92, obviously :-)




From dwalsh at redhat.com  Fri Oct  9 18:57:41 2009
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 09 Oct 2009 14:57:41 -0400
Subject: Why SELinux is
 preventing	/usr/lib64/nspluginwrapper/npviewer.bin
 "execmem" access on	?
In-Reply-To: 
References:  <4ACF858B.70308@redhat.com>
	
Message-ID: <4ACF87A5.6030107@redhat.com>

On 10/09/2009 02:53 PM, Petrus de Calguarium wrote:
> Daniel J Walsh wrote:
> 
>> Which Version of the OS/Policy are you seeing execmem 
> problems at youtube?
> 
> selinux-policy-targeted-3.6.32-22.fc12.noarch
> 
> Using f11.92, obviously :-)
> 
> 
Download the latest policy package from koji, should fix your problems.


http://koji.fedoraproject.org/koji/buildinfo?buildID=135962

I just submitted a request to get this package into beta.



From kwhiskerz at gmail.com  Fri Oct  9 19:31:02 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 09 Oct 2009 13:31:02 -0600
Subject: Why SELinux is
	preventing	/usr/lib64/nspluginwrapper/npviewer.bin "execmem"
	access on	?
References:  <4ACF858B.70308@redhat.com>
	 <4ACF87A5.6030107@redhat.com>
Message-ID: 

Daniel J Walsh wrote:

> Download the latest policy package from koji, should 
fix your problems.

Thanks!




From christoph.wickert at googlemail.com  Fri Oct  9 19:34:11 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 09 Oct 2009 21:34:11 +0200
Subject: Maintainer MIA: Claudio Tomasoni
Message-ID: <1255116851.6035.20.camel@localhost>

I am starting the AWOL procedure [1] for Claudio Tomasoni, because he
didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried
to contact him for more than 7 months [3]. We should prepare for taking
over Claudio's packages [4].

If anybody knows whats up with Claudio or how to contact him, please let
us know.

Regards,
Christoph

[1]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2] https://bugzilla.redhat.com/show_bug.cgi?id=500068
[3] https://bugzilla.redhat.com/show_bug.cgi?id=486753 
[4] https://admin.fedoraproject.org/pkgdb/users/packages/claudiotomasoni





From fedora at camperquake.de  Fri Oct  9 19:55:41 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 9 Oct 2009 21:55:41 +0200
Subject: does fedora have anything requiring :mail rw access?
In-Reply-To: <200910091548.48252.mhlavink@redhat.com>
References: <200910091531.45573.mhlavink@redhat.com>
	<200910091548.48252.mhlavink@redhat.com>
Message-ID: <20091009215541.60876237@fred.camperquake.de>

Hi.

On Fri, 9 Oct 2009 15:48:47 +0200, Michal Hlavinka wrote

> Well, I already know one, cyrus-imapd most probably requires mail rw.
> Is there anything else?

Cyrus is running it's own mailspool.



From jlaska at redhat.com  Fri Oct  9 20:28:32 2009
From: jlaska at redhat.com (James Laska)
Date: Fri, 09 Oct 2009 16:28:32 -0400
Subject: 2009-10-08 - RAID Test Day report
Message-ID: <1255120112.2444.86.camel@localhost.localdomain>

Many thanks to participants of the RAID test day held this past Thursday
[1].  With Liam's guidance, we also had a list of RAID test cases
designed to target real world scenarios.  Not only did this event help
exercise these code paths in the installer, but helped to shake out
kinks in the test cases.

Also, thanks to Hans De Goede for providing updated live images and for
his help configuring an existing system to present BIOS RAID devices.  I
too can enjoy the world of dmraid!  The following bug reports were noted
in the Test Day wiki:

527913 NEW  - DeviceTreeError: duplicate paths in device tree
527952 NEW  - AttributeError: 'NoneType' object has no attribute 'disk'
498026 NEW  - RuntimeError: Returning partitions to state prior to edit failed
527965 NEW  - Unable to clone disk for raid
527969 NEW  - Device Setup Failed: device has not been created
526971 NEW  - DeviceTreeError: duplicate paths in device tree
528117 NEW  - Asking for cache data failed on raid
517260 ASSIGNED  - liveinst fails at partitioning screen
522609 MODIFIED  - AttributeError: 'NoneType' object has no attribute 'startswith'
528051 CLOSED NEXTRELEASE - Exception: device-mapper: create ioctl failed: Device or resource busy
527961 CLOSED DUPLICATE - Anaconda doesn't save partition binding to disk
527991 CLOSED DUPLICATE - Editing existing partition results in - The mountpoint '/' is in use.  Please pick another
528017 CLOSED DUPLICATE - Rescue unable to mount system on bios raid
527995 CLOSED NOTABUG - Problem measuring available size when 4 RAID partitions are on one volume - fourth partition is smaller than the others

Thanks,
James

[1] https://fedoraproject.org/wiki/Test_Day:2009-10-08_RAID
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From orion at cora.nwra.com  Fri Oct  9 21:21:02 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 09 Oct 2009 15:21:02 -0600
Subject: cmake 2.8.0 in F-13
Message-ID: <4ACFA93E.7000805@cora.nwra.com>

I've just built cmake 2.8.0 RC 2 for F-13.  Please report any trouble to 
the cmake mailing list or the kitware cmake bug tracker.

One nice new feature is the parallel capability of ctest.  You can put:

ctest -V %{?_smp_mflags}

in the %check section of your specfiles and the tests will run in 
parallel on multi-core machines.  Perhaps this could be added to 
 ?

-- 
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 ndbecker2 at gmail.com  Fri Oct  9 22:56:34 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Oct 2009 18:56:34 -0400
Subject: Howto handle multilib conflict?
Message-ID: 

Just received:
https://bugzilla.redhat.com/show_bug.cgi?id=528237

yum install libotf-devel.i586 libotf-devel.x86_64

yields:

Transaction Check Error:
  file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
  file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
libotf-devel-0.9.8-2.fc11.x86_64

What is the recommended way to resolve this?




From awilliam at redhat.com  Fri Oct  9 23:13:22 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 09 Oct 2009 16:13:22 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: 
References: 
Message-ID: <1255130002.2330.9.camel@adam.local.net>

On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
> Just received:
> https://bugzilla.redhat.com/show_bug.cgi?id=528237
> 
> yum install libotf-devel.i586 libotf-devel.x86_64
> 
> yields:
> 
> Transaction Check Error:
>   file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
> conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
>   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
> libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
> libotf-devel-0.9.8-2.fc11.x86_64
> 
> What is the recommended way to resolve this?

It's not to be considered a bug, AFAIK. We don't stipulate that
development packages be installable side-by-side in this way, we only
stipulate that for library packages where there's a need for it. There's
no particular use case where you absolutely need both -devel packages
installed at once.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From jkeating at redhat.com  Fri Oct  9 23:27:12 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 09 Oct 2009 16:27:12 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <1255130002.2330.9.camel@adam.local.net>
References: 
	<1255130002.2330.9.camel@adam.local.net>
Message-ID: <1255130832.3656.29.camel@localhost.localdomain>

On Fri, 2009-10-09 at 16:13 -0700, Adam Williamson wrote:
> On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
> > Just received:
> > https://bugzilla.redhat.com/show_bug.cgi?id=528237
> > 
> > yum install libotf-devel.i586 libotf-devel.x86_64
> > 
> > yields:
> > 
> > Transaction Check Error:
> >   file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
> > conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
> >   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
> > libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
> > libotf-devel-0.9.8-2.fc11.x86_64
> > 
> > What is the recommended way to resolve this?
> 
> It's not to be considered a bug, AFAIK. We don't stipulate that
> development packages be installable side-by-side in this way, we only
> stipulate that for library packages where there's a need for it. There's
> no particular use case where you absolutely need both -devel packages
> installed at once.
> 
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
> 

Actually this is a bug.  If the packages are offered in the same repo,
they should install together (barring explicit conflicts listed in the
spec file).  Looks like the example makefile may be generated at build
time, or touched in someway so that it is different when on i686 and
x86_64.  That should not happen, they should be the same.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From christoph.wickert at googlemail.com  Fri Oct  9 23:29:16 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 10 Oct 2009 01:29:16 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: 
References: 
Message-ID: <1255130956.6035.103.camel@localhost>

Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
> Just received:
> https://bugzilla.redhat.com/show_bug.cgi?id=528237
> 
> yum install libotf-devel.i586 libotf-devel.x86_64
> 
> yields:
> 
> Transaction Check Error:
>   file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
> conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
>   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
> libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
> libotf-devel-0.9.8-2.fc11.x86_64
> 
> What is the recommended way to resolve this?

If the contents of the file is the same and they only their timestamps
differ, you can touch them reversely after install as in
http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39

Regards,
Christoph



From a.badger at gmail.com  Fri Oct  9 23:41:27 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 9 Oct 2009 16:41:27 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <1255130002.2330.9.camel@adam.local.net>
References: 
	<1255130002.2330.9.camel@adam.local.net>
Message-ID: <20091009234127.GD5033@clingman.lan>

On Fri, Oct 09, 2009 at 04:13:22PM -0700, Adam Williamson wrote:
> On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
> > Just received:
> > https://bugzilla.redhat.com/show_bug.cgi?id=528237
> > 
> > yum install libotf-devel.i586 libotf-devel.x86_64
> > 
> > yields:
> > 
> > Transaction Check Error:
> >   file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
> > conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
> >   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
> > libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
> > libotf-devel-0.9.8-2.fc11.x86_64
> > 
> > What is the recommended way to resolve this?
> 
> It's not to be considered a bug, AFAIK. We don't stipulate that
> development packages be installable side-by-side in this way, we only
> stipulate that for library packages where there's a need for it. There's
> no particular use case where you absolutely need both -devel packages
> installed at once.
> 
I believe this is incorrect.  devel packages are supposed to be multilib
installable.  There's two things that are two files that conflict above and
there's two different fixes for each.
  /usr/bin/libotf-config -- This is a script or binary for the user to run.
  It likely has different library paths depending on whether we're
  installing on x86_64 or i386.  One of the better ways to fix this is to
  make libotf-config into a wrapper around pkg-config and then send the
  modifications to upstream.  pkg-config stores the data filesabout each
  library in %{_libdir}/pkgconfig so it's multilib safe. If upstream doesn't
  want that or the libotf-config script has very different ideas of what
  information it needs to give out than pkg-config, renaming the binary to
  libotf-config32 and libotf-config64 is another method.  However, this has
  the drawback of requiring patches to code which invokes libotf-config in
  other packages.  The pkg-config wrapper is greatly prefered.

  Makefile -- You'll have to download the two packages and check what's
  changed in the Makefile.  Perhaps it's hardcoding the installed library
  path needlessly or youcanuse pkg-config/libotf-config to make the Makefile
  the same onall arches.  If you get stuck you can post the diff of the
  Makefiles here and we can help more.

There are some methods of working around these issues here:
https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From ndbecker2 at gmail.com  Fri Oct  9 23:45:46 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Oct 2009 19:45:46 -0400
Subject: Howto handle multilib conflict?
References: 
	<1255130002.2330.9.camel@adam.local.net>
	<1255130832.3656.29.camel@localhost.localdomain>
Message-ID: 

Jesse Keating wrote:

> On Fri, 2009-10-09 at 16:13 -0700, Adam Williamson wrote:
>> On Fri, 2009-10-09 at 18:56 -0400, Neal Becker wrote:
>> > Just received:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=528237
>> > 
>> > yum install libotf-devel.i586 libotf-devel.x86_64
>> > 
>> > yields:
>> > 
>> > Transaction Check Error:
>> >   file /usr/bin/libotf-config from install of
>> >   libotf-devel-0.9.8-2.fc11.i586
>> > conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
>> >   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install
>> >   of
>> > libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
>> > libotf-devel-0.9.8-2.fc11.x86_64
>> > 
>> > What is the recommended way to resolve this?
>> 
>> It's not to be considered a bug, AFAIK. We don't stipulate that
>> development packages be installable side-by-side in this way, we only
>> stipulate that for library packages where there's a need for it. There's
>> no particular use case where you absolutely need both -devel packages
>> installed at once.
>> 
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>> http://www.happyassassin.net
>> 
> 
> Actually this is a bug.  If the packages are offered in the same repo,
> they should install together (barring explicit conflicts listed in the
> spec file).  Looks like the example makefile may be generated at build
> time, or touched in someway so that it is different when on i686 and
> x86_64.  That should not happen, they should be the same.
> 

Both /usr/bin/libotf-config and example/Makefile are autoconf-generated.  
Suggestions?



From oget.fedora at gmail.com  Fri Oct  9 23:48:20 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Fri, 9 Oct 2009 19:48:20 -0400
Subject: Howto handle multilib conflict?
In-Reply-To: <1255130956.6035.103.camel@localhost>
References:  <1255130956.6035.103.camel@localhost>
Message-ID: 

On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
> Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
>> Just received:
>> https://bugzilla.redhat.com/show_bug.cgi?id=528237
>>
>> yum install libotf-devel.i586 libotf-devel.x86_64
>>
>> yields:
>>
>> Transaction Check Error:
>> ? file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
>> conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
>> ? file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
>> libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
>> libotf-devel-0.9.8-2.fc11.x86_64
>>
>> What is the recommended way to resolve this?
>
> If the contents of the file is the same and they only their timestamps
> differ, you can touch them reversely after install as in
> http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39
>

What if the generated docbook documents are different due to different
"id"s? Do we need to separate the docs into a noarch subpackage?

Orcan



From christoph.wickert at googlemail.com  Sat Oct 10 00:03:24 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 10 Oct 2009 02:03:24 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: 
References:  <1255130956.6035.103.camel@localhost>
	
Message-ID: <1255133004.6035.105.camel@localhost>

Am Freitag, den 09.10.2009, 19:48 -0400 schrieb Orcan Ogetbil:
> On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
...
> >
> > If the contents of the file is the same and they only their timestamps
> > differ, you can touch them reversely after install as in
> > http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39
> >
> 
> What if the generated docbook documents are different due to different
> "id"s? Do we need to separate the docs into a noarch subpackage?

Honestly I have no idea, but I prefer noatch subpackages for docs
anyway. Of course, this depends on their size.

> Orcan

Regards,
Christoph



From awilliam at redhat.com  Sat Oct 10 00:48:38 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 09 Oct 2009 17:48:38 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <20091009234127.GD5033@clingman.lan>
References:  <20091009234127.GD5033@clingman.lan>
Message-ID: <1255135718.2330.11.camel@adam.local.net>

On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:

> > It's not to be considered a bug, AFAIK. We don't stipulate that
> > development packages be installable side-by-side in this way, we only
> > stipulate that for library packages where there's a need for it. There's
> > no particular use case where you absolutely need both -devel packages
> > installed at once.
> > 
> I believe this is incorrect.  devel packages are supposed to be multilib
> installable.  There's two things that are two files that conflict above and
> there's two different fixes for each.

I'm happy to be wrong :), but is this documented anywhere? That's why I
thought the opposite was the case, I couldn't find anything to this
effect in the packaging documentation when I was starting out.

It seems like a lot of work for very little return if it is our policy,
especially fiddling around with *-config and the like executables, which
are far from uncommon...what's the use case for multilib -devel
packages? When is it actually useful to have both arches installed at
once for a -devel package?

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From ndbecker2 at gmail.com  Sat Oct 10 01:12:15 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Oct 2009 21:12:15 -0400
Subject: Howto handle multilib conflict?
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
Message-ID: 

Adam Williamson wrote:

> On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
> 
>> > It's not to be considered a bug, AFAIK. We don't stipulate that
>> > development packages be installable side-by-side in this way, we only
>> > stipulate that for library packages where there's a need for it.
>> > There's no particular use case where you absolutely need both -devel
>> > packages installed at once.
>> > 
>> I believe this is incorrect.  devel packages are supposed to be multilib
>> installable.  There's two things that are two files that conflict above
>> and there's two different fixes for each.
> 
> I'm happy to be wrong :), but is this documented anywhere? That's why I
> thought the opposite was the case, I couldn't find anything to this
> effect in the packaging documentation when I was starting out.
> 
> It seems like a lot of work for very little return if it is our policy,
> especially fiddling around with *-config and the like executables, which
> are far from uncommon...what's the use case for multilib -devel
> packages? When is it actually useful to have both arches installed at
> once for a -devel package?
> 

Fortunately, it seems that this particular case (2 file conflicts) was 
pretty easy to fix (just remove the offending files).  Looking at 
emacs-23.1, it appears to be using pkgconfig, and libotf already was 
installing a proper libotf.pc.  I'm hoping /usr/bin/libotf-config isn't 
essential.



From skvidal at fedoraproject.org  Sat Oct 10 02:25:40 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 9 Oct 2009 22:25:40 -0400 (EDT)
Subject: Howto handle multilib conflict?
In-Reply-To: <1255135718.2330.11.camel@adam.local.net>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
Message-ID: 



On Fri, 9 Oct 2009, Adam Williamson wrote:

> On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
>
>>> It's not to be considered a bug, AFAIK. We don't stipulate that
>>> development packages be installable side-by-side in this way, we only
>>> stipulate that for library packages where there's a need for it. There's
>>> no particular use case where you absolutely need both -devel packages
>>> installed at once.
>>>
>> I believe this is incorrect.  devel packages are supposed to be multilib
>> installable.  There's two things that are two files that conflict above and
>> there's two different fixes for each.
>
> I'm happy to be wrong :), but is this documented anywhere? That's why I
> thought the opposite was the case, I couldn't find anything to this
> effect in the packaging documentation when I was starting out.
>

Well, I know it is documented that file conflicts are never allowed, ever, 
at all w/o an explicit conflicts: in the spec file.

-sv



From bruno at wolff.to  Sat Oct 10 06:54:32 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 10 Oct 2009 01:54:32 -0500
Subject: Packaging tips for sound?
Message-ID: <20091010065432.GB11858@wolff.to>

I am wondering if there is any documentation on tips for packagers for
helping them integrate sound features of their packages in Fedora.

In my specific case the volume controls on glest are not affecting the
volume in F12 and I am wondering where to start looking for infomation
that may be relevant for fixing this.



From pmatilai at laiskiainen.org  Sat Oct 10 08:30:26 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 10 Oct 2009 11:30:26 +0300 (EEST)
Subject: Howto handle multilib conflict?
In-Reply-To: <1255130956.6035.103.camel@localhost>
References:  <1255130956.6035.103.camel@localhost>
Message-ID: 

On Sat, 10 Oct 2009, Christoph Wickert wrote:

> Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:
>> Just received:
>> https://bugzilla.redhat.com/show_bug.cgi?id=528237
>>
>> yum install libotf-devel.i586 libotf-devel.x86_64
>>
>> yields:
>>
>> Transaction Check Error:
>>   file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
>> conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
>>   file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
>> libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
>> libotf-devel-0.9.8-2.fc11.x86_64
>>
>> What is the recommended way to resolve this?
>
> If the contents of the file is the same and they only their timestamps
> differ, you can touch them reversely after install as in
> http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39

Timestamp differences do NOT cause file conflicts. Content (and 
permission) differences do.

 	- Panu -



From rc040203 at freenet.de  Sat Oct 10 09:13:20 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 10 Oct 2009 11:13:20 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: 
References:  <1255130956.6035.103.camel@localhost>
	
Message-ID: <4AD05030.5060409@freenet.de>

On 10/10/2009 01:48 AM, Orcan Ogetbil wrote:
> On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote:
>> Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker:

> What if the generated docbook documents are different due to different
> "id"s? Do we need to separate the docs into a noarch subpackage?
Nope, this doesn't actually help.

The actual fix would be to fix docbook[1] rsp. these docbook-documents' 
sources to not apply "ids" rsp. to produce "deterministic ids".

An alternative work-around would be to "filter out/process" (e.g. by 
using sed) these "id"s, such the generated docs can be generated 
deterministically.

Last resort would be to move such docs into arch' dependent directories 
in arch-dependent packages.

Ralf



From rawhide at fedoraproject.org  Sat Oct 10 12:59:24 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 10 Oct 2009 12:59:24 +0000
Subject: rawhide report: 20091010 changes
Message-ID: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 10 06:15:04 UTC 2009

Broken deps for i386
----------------------------------------------------------
	konversation-1.2-1.fc12.i686 requires kdelibs4 >= 0:4.3.2
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	konversation-1.2-1.fc12.x86_64 requires kdelibs4 >= 0:4.3.2
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	konversation-1.2-1.fc12.ppc requires kdelibs4 >= 0:4.3.2
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	konversation-1.2-1.fc12.ppc64 requires kdelibs4 >= 0:4.3.2
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Removed package gai
Removed package gai-pal
Removed package gai-temp
Removed package python-json
Updated Packages:

NetworkManager-0.7.996-4.git20091002.fc12
-----------------------------------------
* Fri Oct 02 2009 Dan Williams  - 0.7.996-4.git20091002
- install: fix -gnome package %pre script failures (rh #526519)
- nm: fix failures validating private keys when using the NSS crypto backend
- applet: fix crashes when clicking on menu but not associated (rh #526535)
- editor: fix crash editing wired 802.1x settings
- editor: fix secrets retrieval when editing connections


Terminal-0.4.2-2.fc12
---------------------
* Thu Oct 08 2009 Christoph Wickert  - 0.4.2-2
- Fix locale problems in the UI (bugzilla.xfce.org #5842)


chromium-bsu-0.9.14-6.fc12
--------------------------
* Fri Oct 09 2009 Hans de Goede  0.9.14-6
- Switch to quesoglc instead of ftgl (glc is the upstream default)
- This fixes chromium-bsu not finding its font, as quesoglc properly uses
  fontconfig instead of using a hardcoded path to the font (#526995)


dopewars-1.5.12-9.1033svn.fc12
------------------------------
* Fri Oct 09 2009 Jussi Lehtola  - 1.5.12-8.1033svn
- Update to svn release to address security issues.

* Fri Oct 09 2009 Jussi Lehtola  - 1.5.12-9.1033svn
- Increment release to be able to tag in F-12.


dracut-002-13.4.git8f397a9b.fc12
--------------------------------
* Fri Oct 09 2009 Harald Hoyer  002-13.2
- do not fail, if libdmraid-events-isw.so is not present

* Fri Oct 09 2009 Harald Hoyer  002-13.3
- removed one wildcard of libdmraid-events-isw.so install

* Fri Oct 09 2009 Jesse Keating  - 002-13.4
- Requires(pre) on plymouth to ensure plymouth is installed before kernel


drupal-service_links-6.x.1.0-5.fc12
-----------------------------------
* Fri Oct 09 2009 Jon Ciesla  - 6.x.1.0-5
- Patch for CVE-2009-3648 from madirish.net, BZ 528200, 528201.


gcc-4.4.1-20.fc12
-----------------
* Thu Oct 08 2009 Jakub Jelinek  4.4.1-20
- update from gcc-4_4-branch
  - PRs c++/39863, c++/41038
- avoid redundant DW_AT_const_value when abstract origin already has one
  (#527430) 
- another VTA debug stmt renaming bugfix (#521991)

* Mon Oct 05 2009 Jakub Jelinek  4.4.1-19
- update from gcc-4_4-branch
  - PRs fortran/41479, fortran/41515
- VTA backports
  - PRs debug/41353, debug/41404, rtl-optimization/41511
  - another debug info fix for decls passed by reference (#527057,
    PR debug/41558)
  - don't emit DW_AT_name on DW_TAG_const_type (#526970)
- avoid invalid folding of casts to addresses of first fields
  (#527121, PR middle-end/41317)

* Thu Oct 01 2009 Jakub Jelinek  4.4.1-18
- update from gcc-4_4-branch
  - PRs ada/41100, target/22093
- VTA backports
  - PRs debug/41438, debug/41474, target/41279, testsuite/41444
- fix VTA ICE on Linux kernel (#521991)
- AMD Orochi -mfma4 support
- don't run install-info if info files are missing because of --excludedocs
  (#515921, #515960, #515962, #515965, #516000, #516008, #516014)


gdm-2.28.0-9.fc12
-----------------
* Fri Oct 09 2009 Matthias Clasen  - 1:2.28.0-8
- Move bubbles to the lower right on the login screen

* Fri Oct 09 2009 Ray Strode  2.28.0-9
- Fix Other... user.

* Wed Oct 07 2009 Ray Strode  - 1:2.28.0-7
- Fix gdm-password / xguest interaction (bug 524421)


gtk2-2.18.2-2.fc12
------------------
* Fri Oct 09 2009 Matthias Clasen  - 2.18.2-2
- Make selecting the final char work again (#528072)


konversation-1.2-1.fc12
-----------------------
* Fri Oct 09 2009 Rex Dieter  - 1.2-1
- konversation-1.2 (final)


libcap-ng-0.6.2-3.fc12
----------------------
* Fri Oct 09 2009 Steve Grubb  0.6.2-3
- Apply patch to retain setpcap only if clearing bounding set


libv4l-0.6.2-1.fc12
-------------------
* Fri Oct 09 2009 Hans de Goede  0.6.2-1
- New upstream release 0.6.2


libvirt-0.7.1-11.fc12
---------------------
* Fri Oct 09 2009 Mark McLoughlin  - 0.7.1-11
- Fix libvirtd memory leak during error reply sending (#528162)
- Add several PCI hot-unplug typo fixes from upstream


libvoikko-2.2.1-1.fc12
----------------------
* Fri Oct 09 2009 Ville-Pekka Vainio  - 2.2.1-1
- New upstream release, fixes bugs found in 2.2


openoffice.org-3.1.1-19.11.fc12
-------------------------------
* Thu Oct 08 2009 Caol?n McNamara  - 1:3.1.1-19.11
- Resolves: rhbz#527177 add openoffice.org-3.1.1.ooo105613.vcl.a11y.exceptions.patch (caolanm)
- Resolves: rhbz#527719 add openoffice.org-3.1.1.oooXXXXXX.vcl.sniffscriptforsubs.patch


openssl-1.0.0-0.9.beta3.fc12
----------------------------
* Thu Oct 08 2009 Tomas Mraz  1.0.0-0.9.beta3
- fix typo in DTLS1 code (#527015)
- fix leak in error handling of d2i_SSL_SESSION()


plymouth-0.8.0-0.2009.29.09.9.fc12
----------------------------------
* Fri Oct 09 2009 Ray Strode  0.8.0-0.2009.29.09.8
- Fix crash in text plugin on shutdown

* Fri Oct 09 2009 Ray Strode  0.8.0-0.2009.29.09.9
- Fix frame-buffer fallback plugin
  (broken by details fix in 0.8.0-0.2009.29.09.7)


pybluez-0.16-2.fc12
-------------------
* Thu Oct 08 2009 Paulo Roma  - 0.16-2
- Applied btmodule patch.


qemu-0.11.0-6.fc12
------------------
* Fri Oct 09 2009 Mark McLoughlin  - 2:0.11.0-6
- Fix fs errors with virtio and qcow2 backing file (#524734)
- Fix ksm initscript errors on kernel missing ksm (#527653)
- Add missing Requires(post): getent, useradd, groupadd (#527087)

* Tue Oct 06 2009 Mark McLoughlin  - 2:0.11.0-5
- Add 'retune' verb to ksmtuned init script


qt-4.5.2-25.fc12
----------------
* Fri Oct 09 2009 Rex Dieter  - 4.5.2-25
- qt webkit crash on drag (#528094)

* Tue Oct 06 2009 Jaroslav Reznik  - 4.5.2-24
- disable JavaScriptCore JIT, SE Linux crashes (#527079)

* Sun Oct 04 2009 Than Ngo  - 4.5.2-23
- rhel cleanup


selinux-policy-3.6.32-24.fc12
-----------------------------
* Sat Oct 10 2009 Dan Walsh  3.6.32-24
- Add home_cert_t for labeling of certs in the homedir

* Thu Oct 08 2009 Dan Walsh  3.6.32-23
- Allow xdm to unlink xauth_home_t


xen-3.4.1-5.fc12
----------------
* Wed Oct 07 2009 Justin M. Forbes  - 3.4.1-5
- add PyXML to dependencies. (#496135)
- Take ownership of {_libdir}/fs (#521806)


Summary:
Added Packages: 0
Removed Packages: 4
Modified Packages: 22



From casimiro.barreto at gmail.com  Sat Oct 10 14:09:12 2009
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Sat, 10 Oct 2009 11:09:12 -0300
Subject: cups/guttenprint color schemes wrong for Epson Stylus CX3500 and
 other printers
Message-ID: <4AD09588.6050603@gmail.com>

Maybe off topic but, how to correct color schemes for Epson Printers?
Default is horrible (excess of red, wrong gamma/brightness, etc). I
guess someone must have dealt with that.

Best regards

CdAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: 

From awilliam at redhat.com  Sat Oct 10 14:47:59 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sat, 10 Oct 2009 07:47:59 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: 
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
Message-ID: <1255186079.2330.14.camel@adam.local.net>

On Fri, 2009-10-09 at 22:25 -0400, Seth Vidal wrote:
> 
> On Fri, 9 Oct 2009, Adam Williamson wrote:
> 
> > On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote:
> >
> >>> It's not to be considered a bug, AFAIK. We don't stipulate that
> >>> development packages be installable side-by-side in this way, we only
> >>> stipulate that for library packages where there's a need for it. There's
> >>> no particular use case where you absolutely need both -devel packages
> >>> installed at once.
> >>>
> >> I believe this is incorrect.  devel packages are supposed to be multilib
> >> installable.  There's two things that are two files that conflict above and
> >> there's two different fixes for each.
> >
> > I'm happy to be wrong :), but is this documented anywhere? That's why I
> > thought the opposite was the case, I couldn't find anything to this
> > effect in the packaging documentation when I was starting out.
> >
> 
> Well, I know it is documented that file conflicts are never allowed, ever, 
> at all w/o an explicit conflicts: in the spec file.

Ah, yeah. That would cover it without any need for a specific multilib
policy, for sure. (I checked, and libotf-devel i686 is in the x86-64
repo).

Of course, that turns the larger question into 'why do we put i686
-devel packages in the x86-64 repo, not just the lib packages', but it
does explain for sure that I was wrong in my initial reply, sorry for
that!

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From scottt.tw at gmail.com  Sat Oct 10 15:02:32 2009
From: scottt.tw at gmail.com (Scott Tsai)
Date: Sat, 10 Oct 2009 15:02:32 +0000 (UTC)
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
	
	<1255100271.2339.6.camel@adam.local.net>
Message-ID: 

On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote:

> It would be nice to have more comprehensive 3D tests.

I think it's worth packaging the "piglit" OopenGL test suite:
http://cgit.freedesktop.org/piglit
and using it in graphics test days.

According tho this blog post by Eric Anholt and the git commit log,
upstream open source graphics driver developers are still constantly
adding tests to it:
http://anholt.livejournal.com/41522.html



From awilliam at redhat.com  Sat Oct 10 15:15:53 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sat, 10 Oct 2009 08:15:53 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost> <4ACEF5CB.6090709@beam.ltd.uk>
	
	<1255100271.2339.6.camel@adam.local.net> 
Message-ID: <1255187753.2330.18.camel@adam.local.net>

On Sat, 2009-10-10 at 15:02 +0000, Scott Tsai wrote:
> On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote:
> 
> > It would be nice to have more comprehensive 3D tests.
> 
> I think it's worth packaging the "piglit" OopenGL test suite:
> http://cgit.freedesktop.org/piglit
> and using it in graphics test days.
> 
> According tho this blog post by Eric Anholt and the git commit log,
> upstream open source graphics driver developers are still constantly
> adding tests to it:
> http://anholt.livejournal.com/41522.html

Good point. I think Francois Cami had some plans to this effect, but
he's been away from the project for a few months lately, so maybe I'll
do it instead. Thanks for the reminder.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From christoph.wickert at googlemail.com  Sat Oct 10 15:21:37 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 10 Oct 2009 17:21:37 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: 
References:  <1255130956.6035.103.camel@localhost>
	
Message-ID: <1255188097.7848.20.camel@wicktop.localdomain>

Am Samstag, den 10.10.2009, 11:30 +0300 schrieb Panu Matilainen:
> On Sat, 10 Oct 2009, Christoph Wickert wrote:
> >
> > If the contents of the file is the same and they only their timestamps
> > differ, you can touch them reversely after install as in
> > http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39
> 
> Timestamp differences do NOT cause file conflicts. 

Indeed, obviously this has changed. Changes like this should be
announced somewhere, I guess Kevin and me are not the only one packagers
who still believe they have to care for timestamps.

> Content (and permission) differences do.

I took a look at the files from exo and they did differ. Tanks for the
pointer.

>  	- Panu -

Regards,
Christoph



From pertusus at free.fr  Sat Oct 10 15:32:40 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 10 Oct 2009 17:32:40 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: <1255188097.7848.20.camel@wicktop.localdomain>
References:  <1255130956.6035.103.camel@localhost>
	
	<1255188097.7848.20.camel@wicktop.localdomain>
Message-ID: <20091010152716.GA16025@free.fr>

On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
> > 
> > Timestamp differences do NOT cause file conflicts. 
> 
> Indeed, obviously this has changed. Changes like this should be
> announced somewhere, I guess Kevin and me are not the only one packagers
> who still believe they have to care for timestamps.

I am not sure that timestamps created conflicts in the past. However
in rpm -V there were marked as being modified. Maybe this is what changed.
In any case I think that we should care for timestamps even if they are
not reasons for conflicts. Some packagers disagree, though, that
timestamps are useful and should be correct.

--
Pat



From mschwendt at gmail.com  Sat Oct 10 16:05:12 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 10 Oct 2009 18:05:12 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: <1255186079.2330.14.camel@adam.local.net>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
	<1255186079.2330.14.camel@adam.local.net>
Message-ID: <20091010180512.041a0f80@faldor.intranet>

On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:

> Of course, that turns the larger question into 'why do we put i686
> -devel packages in the x86-64 repo, not just the lib packages',

Because not all files in -devel packages cover multiple target
platforms. Example: You could not build for i686 with headers that
are specific to x86_64, and you would also need the .so symlinks for
libraries in the appropriate libdir.



From mschwendt at gmail.com  Sat Oct 10 16:09:01 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 10 Oct 2009 18:09:01 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: <20091010152716.GA16025@free.fr>
References:  <1255130956.6035.103.camel@localhost>
	
	<1255188097.7848.20.camel@wicktop.localdomain>
	<20091010152716.GA16025@free.fr>
Message-ID: <20091010180901.4d39606b@faldor.intranet>

On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote:

> On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
> > > 
> > > Timestamp differences do NOT cause file conflicts. 
> > 
> > Indeed, obviously this has changed. Changes like this should be
> > announced somewhere, 

What is the source of these rumours that file timestamp differences
would cause conflicts?

> > I guess Kevin and me are not the only one packagers
> > who still believe they have to care for timestamps.
> 
> I am not sure that timestamps created conflicts in the past.

If they have ever lead to conflicts, then only as a result of
a temporary bug.



From awilliam at redhat.com  Sat Oct 10 17:17:16 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sat, 10 Oct 2009 10:17:16 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <20091010180512.041a0f80@faldor.intranet>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
	<1255186079.2330.14.camel@adam.local.net>
	<20091010180512.041a0f80@faldor.intranet>
Message-ID: <1255195036.2330.23.camel@adam.local.net>

On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
> On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
> 
> > Of course, that turns the larger question into 'why do we put i686
> > -devel packages in the x86-64 repo, not just the lib packages',
> 
> Because not all files in -devel packages cover multiple target
> platforms. Example: You could not build for i686 with headers that
> are specific to x86_64, and you would also need the .so symlinks for
> libraries in the appropriate libdir.

Well, that's only valid if we actually do anything to ensure multilib
compilation actually *works*, right now all we enforce is that the
packages don't conflict (which isn't the same thing at all). I hope I'm
not dragging him into the conversation unwillingly, but Colin Walters
raised those points on IRC:

 well, what's the ultimate goal?  just avoiding the OS
exploding if you happen to somehow get an i386 -devel?  or actually be
able to compile 32 bit on 64 hosts?
 those are pretty different things

...

 people keep trying to scope creep multilib to include
compilation, which we need to clamp down on, and tell them to use mock
 well last time we tried to make major changes to our multilib
strategy, Jeremy was the one to play Captain No
 and he's gone now, so....

I guess the point is that if we actually intend to support 'you can
cross-compile with any -devel package from another arch that's included
in the repository' we may need more strict policies / work to ensure
that's actually possible, and if we intend *not* to support that, but
rather tell people to use mock, there's no reason to include -devel
packages in multilib.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Sat Oct 10 17:34:55 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sat, 10 Oct 2009 10:34:55 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <1255195036.2330.23.camel@adam.local.net>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
	<1255186079.2330.14.camel@adam.local.net>
	<20091010180512.041a0f80@faldor.intranet>
	<1255195036.2330.23.camel@adam.local.net>
Message-ID: <1255196095.2330.24.camel@adam.local.net>

On Sat, 2009-10-10 at 10:17 -0700, Adam Williamson wrote:

> I guess the point is that if we actually intend to support 'you can
> cross-compile with any -devel package from another arch that's included

gah, I know I don't really mean cross-compile, it's been pointed out to
me before that it's the wrong term. you know what I mean. sorry.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Oct 10 18:18:45 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 11 Oct 2009 03:18:45 +0900
Subject: Howto handle multilib conflict?
In-Reply-To: <20091010180901.4d39606b@faldor.intranet>
References: 
	<1255130956.6035.103.camel@localhost>		<1255188097.7848.20.camel@wicktop.localdomain>	<20091010152716.GA16025@free.fr>
	<20091010180901.4d39606b@faldor.intranet>
Message-ID: <4AD0D005.2020606@ioa.s.u-tokyo.ac.jp>

Michael Schwendt wrote, at 10/11/2009 01:09 AM +9:00:
> On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote:
> 
>> On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote:
>>>> Timestamp differences do NOT cause file conflicts. 
>>> Indeed, obviously this has changed. Changes like this should be
>>> announced somewhere, 
> 
> What is the source of these rumours that file timestamp differences
> would cause conflicts?

I guess these rumors came because sometimes some programs creating
document files (mostly html files) or so embeded the timestamp
of the date in those files and that actually caused multilib
conflict (i.e. not the timestamp of the files but the embedded strings
in those files).

Regards,
Mamoru



From chitlesh.goorah at gmail.com  Sat Oct 10 19:41:39 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sat, 10 Oct 2009 21:41:39 +0200
Subject: Maintainer MIA: Claudio Tomasoni
In-Reply-To: <1255116851.6035.20.camel@localhost>
References: <1255116851.6035.20.camel@localhost>
Message-ID: <50baabb30910101241u1b0ebed2i2515d5156b2bed77@mail.gmail.com>

On Fri, Oct 9, 2009 at 9:34 PM, Christoph Wickert wrote:
> I am starting the AWOL procedure [1] for Claudio Tomasoni, because he
> didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried
> to contact him for more than 7 months [3]. We should prepare for taking
> over Claudio's packages [4].

I'm willing to take over :
https://admin.fedoraproject.org/pkgdb/packages/name/octaviz
https://admin.fedoraproject.org/pkgdb/packages/name/qtoctave

Chitlesh



From christoph.wickert at googlemail.com  Sat Oct 10 20:43:33 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 10 Oct 2009 22:43:33 +0200
Subject: Maintainer MIA: Claudio Tomasoni
In-Reply-To: <50baabb30910101241u1b0ebed2i2515d5156b2bed77@mail.gmail.com>
References: <1255116851.6035.20.camel@localhost>
	<50baabb30910101241u1b0ebed2i2515d5156b2bed77@mail.gmail.com>
Message-ID: <1255207413.7848.53.camel@wicktop.localdomain>

Am Samstag, den 10.10.2009, 21:41 +0200 schrieb Chitlesh GOORAH:
> On Fri, Oct 9, 2009 at 9:34 PM, Christoph Wickert wrote:
> > I am starting the AWOL procedure [1] for Claudio Tomasoni, because he
> > didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried
> > to contact him for more than 7 months [3]. We should prepare for taking
> > over Claudio's packages [4].
> 
> I'm willing to take over :
> https://admin.fedoraproject.org/pkgdb/packages/name/octaviz
> https://admin.fedoraproject.org/pkgdb/packages/name/qtoctave

Great, but there are still two weeks left.

> Chitlesh

Regards,
Christoph



From felix at fetzig.org  Sat Oct 10 21:06:40 2009
From: felix at fetzig.org (Felix Kaechele)
Date: Sat, 10 Oct 2009 23:06:40 +0200
Subject: Development packages for Thunderbird/Sunbird
In-Reply-To: <4ACF62DC.9010702@kaarposoft.dk>
References: <4ACF62DC.9010702@kaarposoft.dk>
Message-ID: <4AD0F760.7020301@fetzig.org>

-------- Original Message  --------
Subject: Development packages for Thunderbird/Sunbird
From: Henrik /KaarPoSoft 
To: fedora-devel-list at redhat.com
Date: 09.10.2009 18:20


> I would like blueZync to work on Fedora too
> (currently developing on Debian and Ubuntu).

Me too. I did start a packaging effort some time ago and caused a little 
disaster by updating libsyncml to a newer version to build blueZync. Our 
problem was that nothing else could be built against the new version of 
libsyncml.

> As far as I can see, not such -devel packages are available
> for Fedora 11 or 12.

That is correct.

> Can anybody guide me as to how to kindly request such
> packages for Fedora?

The best would be to file a bug against both thunderbird and sunbird and 
kindly state what you would need for building blueZync.
If you as the developer did that, that would be great. As soon as the 
development files are available I'd be glad working with you on getting 
blueZync into Fedora.

Felix



From imntreal at gmail.com  Sat Oct 10 21:37:43 2009
From: imntreal at gmail.com (Jameson)
Date: Sat, 10 Oct 2009 17:37:43 -0400
Subject: libprojectM Packaging Problem
Message-ID: 

I'm having trouble getting the new version of libprojectM packaged,
and hope someone can shed some light on this for me.  When I enter the
commands to build it manually, it builds fine, but when trying to
package it, it comes out with commands like:

cd /home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer &&
/usr/lib64/ccache/c++   -DUSE_FBO -DLINUX -DSTBI_NO_DDS -DUSE_THREADS
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic ;-fPIC
-I/home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295
-DCMAKE_INSTALL_PREFIX="\"/usr\"" -o CMakeFiles/Renderer.dir/FBO.o -c
/home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer/FBO.cpp

Which fail due to ;-fPIC.  Any ideas on why this is happening?  It
looks to me that it's a simple matter of getting rid of the ; in the
command, but I have no idea why it's there using rpmbuild, but not
when I build manually.

Thanks,
=-Jameson



From mcepl at redhat.com  Sat Oct 10 22:26:59 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 10 Oct 2009 22:26:59 +0000 (UTC)
Subject: Development packages for Thunderbird/Sunbird
References: <4ACF62DC.9010702@kaarposoft.dk>
Message-ID: 

Henrik /KaarPoSoft, Fri, 09 Oct 2009 18:20:44 +0200:
> However, to compile blueZync, development packages for thunderbird and
> sunbird are needed
> (i.e. header files, idl files etc).
> 
> As far as I can see, not such -devel packages are available for Fedora
> 11 or 12.

When you install xulrunner*devel what files you are missing?

Mat?j



From pertusus at free.fr  Sat Oct 10 23:47:40 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 11 Oct 2009 01:47:40 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: <1255195036.2330.23.camel@adam.local.net>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
	<1255186079.2330.14.camel@adam.local.net>
	<20091010180512.041a0f80@faldor.intranet>
	<1255195036.2330.23.camel@adam.local.net>
Message-ID: <20091010234740.GA29452@free.fr>

On Sat, Oct 10, 2009 at 10:17:16AM -0700, Adam Williamson wrote:
> 
> Well, that's only valid if we actually do anything to ensure multilib
> compilation actually *works*, right now all we enforce is that the
> packages don't conflict (which isn't the same thing at all).

It's also valid if we want to help people to be able to have multilib
compilation work, even if it is not used in fedora rpm builds. I have
no knowledge about this issue, but I guess that having multilib devel
packages installed allows users comppiling software to easily use one
or the other library, even if it involves setting some flags by hand,
and, hopefully, with pkg-config setting flags by hand is not required.

--
Pat



From jgarzik at pobox.com  Sun Oct 11 04:07:43 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Sun, 11 Oct 2009 00:07:43 -0400
Subject: thunderbird upgrade - wtf?
Message-ID: <4AD15A0F.9080708@pobox.com>


Just upgraded my F11 workstation, which included an upgrade to 
thunderbird-3.0-2.7.b4.fc11.x86_64

Without any prompting or warning, my email layout -- a key interface 
into my open source development workflow -- was changed to use something 
called "smart folders".

Also annoying, though of less impact to me personally, was the decision 
(again, without prompting or warning) to index all of my email -- of 
which there is a considerable amount.

Now, I'm sure smart folders are a nifty new feature, but where was the 
warning about this upgrade?  Why was this done late in F11, rather than F12?

IMO, major MUA upgrades should be handled better than this.

	Jeff





From mike at cchtml.com  Sun Oct 11 06:03:01 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 11 Oct 2009 01:03:01 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD15A0F.9080708@pobox.com>
References: <4AD15A0F.9080708@pobox.com>
Message-ID: <4AD17515.4070606@cchtml.com>

On 10/10/2009 11:07 PM, Jeff Garzik wrote:
>
> Just upgraded my F11 workstation, which included an upgrade to 
> thunderbird-3.0-2.7.b4.fc11.x86_64
>
> Without any prompting or warning, my email layout -- a key interface 
> into my open source development workflow -- was changed to use 
> something called "smart folders".
>

Wrong list and a week late[1]. No need to continue the old discussion here.

[1] https://www.redhat.com/archives/fedora-list/2009-October/msg00110.html



From mtasaka at ioa.s.u-tokyo.ac.jp  Sun Oct 11 06:27:51 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 11 Oct 2009 15:27:51 +0900
Subject: libprojectM Packaging Problem
In-Reply-To: 
References: 
Message-ID: <4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>

Jameson wrote, at 10/11/2009 06:37 AM +9:00:
> I'm having trouble getting the new version of libprojectM packaged,
> and hope someone can shed some light on this for me.  

Would you upload the srpm you are trying somewhere?

> When I enter the
> commands to build it manually, it builds fine, but when trying to
> package it, it comes out with commands like:
> 

> Which fail due to ;-fPIC.  Any ideas on why this is happening?  It
> looks to me that it's a simple matter of getting rid of the ; in the
> command, but I have no idea why it's there using rpmbuild, but not
> when I build manually.
> 
> Thanks,
> =-Jameson

Regards,
Mamoru



From dodji at redhat.com  Sun Oct 11 08:41:54 2009
From: dodji at redhat.com (Dodji Seketeli)
Date: Sun, 11 Oct 2009 10:41:54 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD17515.4070606@cchtml.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
Message-ID: <20091011084154.GA1481@tutu.torimasen.com>

On Sun, Oct 11, 2009 at 01:03:01AM -0500, Michael Cronenworth wrote:
> Wrong list and a week late[1]. No need to continue the old discussion here.
>
> [1] https://www.redhat.com/archives/fedora-list/2009-October/msg00110.html

I don't think so. Not willing to put words in Jeff's mouth, but I don't
think he was discussing the UI changes of Thunderbird. I took it as he was rather
discussing the upgrade process within Fedora.

FWIW, I felt the disruption in my workflow as well. All of a sudden, TB
almost freezed my computer, eating ~ 1GB of memory (OK, I have a lot of
emails but still) and all that, in F-11 which is a stable version of the distro.

I think this is the right forum to discuss how we can avoid or a least
manage users workflow disruption within stable versions of our distro.

-- 
Dodji Seketeli
Red Hat, Inc.



From sundaram at fedoraproject.org  Sun Oct 11 08:54:53 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Oct 2009 14:24:53 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <20091011084154.GA1481@tutu.torimasen.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
Message-ID: <4AD19D5D.7000403@fedoraproject.org>

On 10/11/2009 02:11 PM, Dodji Seketeli wrote:
> On Sun, Oct 11, 2009 at 01:03:01AM -0500, Michael Cronenworth wrote:
>> Wrong list and a week late[1]. No need to continue the old discussion here.
>>
>> [1] https://www.redhat.com/archives/fedora-list/2009-October/msg00110.html
> 
> I don't think so. Not willing to put words in Jeff's mouth, but I don't
> think he was discussing the UI changes of Thunderbird. I took it as he was rather
> discussing the upgrade process within Fedora.

It is a bit of both really. A single update causes the folders to move
around because "smart folders" was suddenly enabled and that UI change
is very disruptive. It took some time to figure out what the heck was
happening.

The second problem was that thunderbird started indexing all my mails
all of a sudden and again, that is a dirsuption because it essentially
makes the mail client unusable for quite sometime.

It was ok to ship a "beta" release of thunderbird but updates shouldn't
cause such issues. If the fixes were necessary to push as updates then
it would have prudent to disable "smart folders" and "indexing" by
default and leave it enabled in Fedora 12.

Rahul



From jgarzik at pobox.com  Sun Oct 11 09:16:22 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Sun, 11 Oct 2009 05:16:22 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD19D5D.7000403@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org>
Message-ID: <4AD1A266.4090902@pobox.com>

On 10/11/2009 04:54 AM, Rahul Sundaram wrote:
> It was ok to ship a "beta" release of thunderbird but updates shouldn't
> cause such issues. If the fixes were necessary to push as updates then
> it would have prudent to disable "smart folders" and "indexing" by
> default and leave it enabled in Fedora 12.

Precisely.  F11 is supposed to be a stable release.  The sudden 
appearance of both smart folders and indexing was unexpected, disruptive 
and IMO did not achieve the desired quality level for a Fedora stable 
release upgrade.

	Jeff




From henrik at kaarposoft.dk  Sun Oct 11 09:17:00 2009
From: henrik at kaarposoft.dk (Henrik /KaarPoSoft)
Date: Sun, 11 Oct 2009 11:17:00 +0200
Subject: Development packages for Thunderbird/Sunbird
In-Reply-To: <4AD0F760.7020301@fetzig.org>
References: <4ACF62DC.9010702@kaarposoft.dk> <4AD0F760.7020301@fetzig.org>
Message-ID: <4AD1A28C.1000005@kaarposoft.dk>


>
> The best would be to file a bug against both thunderbird and sunbird 
> and kindly state what you would need for building blueZync.
Thanks for the hint. Bugs filed:
https://bugzilla.redhat.com/show_bug.cgi?id=528320
https://bugzilla.redhat.com/show_bug.cgi?id=528321

>
> If you as the developer did that, that would be great. As soon as the 
> development files are available I'd be glad working with you on 
> getting blueZync into Fedora. 
> I did start a packaging effort some time ago and caused a little 
> disaster by updating libsyncml to a newer version to build blueZync. 
> Our problem was that nothing else could be built against the new 
> version of libsyncml.

blueZync requires the newest versions of opensync, libsyncml, and 
libwbxml. Those are not production ready yet. So I think it is too early 
to include those (and hence blueZync) as official packages now.
However with the *bird-devel packages, it would be simple to compile 
from source (as we do on Ubuntu and others).



From tim.lauridsen at googlemail.com  Sun Oct 11 09:29:19 2009
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sun, 11 Oct 2009 11:29:19 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD1A266.4090902@pobox.com>
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD19D5D.7000403@fedoraproject.org>
	<4AD1A266.4090902@pobox.com>
Message-ID: <4AD1A56F.1040305@googlemail.com>

On 10/11/2009 11:16 AM, Jeff Garzik wrote:
> On 10/11/2009 04:54 AM, Rahul Sundaram wrote:
>> It was ok to ship a "beta" release of thunderbird but updates shouldn't
>> cause such issues. If the fixes were necessary to push as updates then
>> it would have prudent to disable "smart folders" and "indexing" by
>> default and leave it enabled in Fedora 12.
>
> Precisely.  F11 is supposed to be a stable release.  The sudden 
> appearance of both smart folders and indexing was unexpected, 
> disruptive and IMO did not achieve the desired quality level for a 
> Fedora stable release upgrade.
>
>     Jeff
>
>
There is a difference between stable and static, if we have a beta of 
thunderbird in F11, then it expected to change between beta releases.
The new search features are very cool, we should be happy someone uses 
the time to give us all this cool new features.

Tim



From dodji at redhat.com  Sun Oct 11 10:08:24 2009
From: dodji at redhat.com (Dodji Seketeli)
Date: Sun, 11 Oct 2009 12:08:24 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD1A56F.1040305@googlemail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org>
	<4AD1A266.4090902@pobox.com> <4AD1A56F.1040305@googlemail.com>
Message-ID: <20091011100823.GA32620@adjoa.torimasen.com>

On Sun, Oct 11, 2009 at 11:29:19AM +0200, Tim Lauridsen wrote:
> There is a difference between stable and static, if we have a beta of  
> thunderbird in F11, then it expected to change between beta releases.

Sure. But at the same time the word "stable" in the expression
"stable version" ought to mean something, I guess.

My point is this is a matter of personal judgement. If the change is
going to be "too" disruptive (and that's a maintainer call)
then maybe having a "Fedora-blessed" repository like this great one
http://rpms.famillecollet.com/fedora/11/remi/x86_64/repoview
could be a possible way to go. At the same time, the package could be
updated straight to Rawhide, of course.

> The new search features are very cool, we should be happy someone uses  
> the time to give us all this cool new features.

I was not discussing that. Those changes are cool. I agree. But we also have
to take in account the drawbacks that come with that coolness and strike
a balance so that stable distro users aren't too disrupted in
their workflows.

-- 
Dodji Seketeli
Red Hat



From rc040203 at freenet.de  Sun Oct 11 10:42:20 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 11 Oct 2009 12:42:20 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD1A56F.1040305@googlemail.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD19D5D.7000403@fedoraproject.org>	<4AD1A266.4090902@pobox.com>
	<4AD1A56F.1040305@googlemail.com>
Message-ID: <4AD1B68C.9020509@freenet.de>

On 10/11/2009 11:29 AM, Tim Lauridsen wrote:
> On 10/11/2009 11:16 AM, Jeff Garzik wrote:
>> On 10/11/2009 04:54 AM, Rahul Sundaram wrote:
>>> It was ok to ship a "beta" release of thunderbird but updates shouldn't
>>> cause such issues. If the fixes were necessary to push as updates then
>>> it would have prudent to disable "smart folders" and "indexing" by
>>> default and leave it enabled in Fedora 12.
>>
>> Precisely. F11 is supposed to be a stable release. The sudden
>> appearance of both smart folders and indexing was unexpected,
>> disruptive and IMO did not achieve the desired quality level for a
>> Fedora stable release upgrade.
ACK, but ...

> There is a difference between stable and static,  if we have a beta of
 > thunderbird in F11, then it expected to change between beta releases.

... to me, in this context "stable" should also imply "sufficently 
"functional" rsp. "near release quality". From my experiences with the 
thunderbird-3*betas in F11, this does not apply to any of the 
thunderbird we had in F11 [1].

> The new search features are very cool, we should be happy someone uses
> the time to give us all this cool new features.
Well, "coolness" is relative - It's a "feature", I have never missed or 
been waiting for :-)

Ralf

[1] I have been (and still am) facing: Corrupted (imap) mail-indices, 
mal-formated subject lines, being unable to send non-base64 encoded 
attachments, sth. occasionally producing duplicate mails and several 
other nuisances (e.g. one core dump at average per day).

New with 3*b4: A significant slowdown, seemingly due to indexing at 
startup, "compacting folders" triggers warnings in deep imap-folders 
(used to work with older thunderbirds and still works with evolution).





From henrik at kaarposoft.dk  Sun Oct 11 11:05:37 2009
From: henrik at kaarposoft.dk (Henrik /KaarPoSoft)
Date: Sun, 11 Oct 2009 13:05:37 +0200
Subject: Development packages for Thunderbird/Sunbird
In-Reply-To: 
References: <4ACF62DC.9010702@kaarposoft.dk> 
Message-ID: <4AD1BC01.1050801@kaarposoft.dk>

Matej Cepl wrote:
> When you install xulrunner*devel what files you are missing?
>
>   
I miss all the interfaces specific to Thunderbird and Sunbird: Address 
book, Calendar, etc.
Just one example: the whole /usr/include/thunderbird/addrbook directory 
with files like nsIAbDirectory.h and nsIAbCard.h

/Henrik



From rawhide at fedoraproject.org  Sun Oct 11 12:03:30 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 11 Oct 2009 12:03:30 +0000
Subject: rawhide report: 20091011 changes
Message-ID: <20091011120330.GA20375@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 11 06:15:06 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Updated Packages:

NetworkManager-openvpn-0.7.996-4.git20090923.fc12
-------------------------------------------------
* Mon Oct 05 2009 Dan Williams  - 1:0.7.996-4.git20090923
- Rebuild for updated NetworkManager


NetworkManager-vpnc-0.7.996-4.git20090921.fc12
----------------------------------------------
* Sat Oct 03 2009 Matthias Clasen  - 1:0.7.996-4
- Rebuild for updated NetworkManager


anaconda-12.36-1.fc12
---------------------
* Fri Oct 09 2009 David Cantrell  - 12.36-1
- Reset PartitionDevice attributes after failed edit. (#498026) (dlehman)
- Fix cut/paste error in commit 299519d4a0693330ff6a50f3111d61feefabb0da.
  (dlehman)
- Consider encryption when checking for duplicate mountpoint. (#526697)
  (dlehman)
- Fix filtering out of 'Sending translation for' log messages in bumpver.
  (rvykydal)
- Use addUdevPartitionDevice() for adding dmraid / multipath partitions
  (#527785) (hdegoede)
- Set partedPartition system to the correct FS when creating an FS (hdegoede)
- Reset parted flags in createFormat not destroyFormat (hdegoede)
- Default to mbr bootloader target for mdraid 1 boot device too (#526822).
  (rvykydal)
- Clear out state before calling XkbGetState. (clumens)


control-center-2.28.0-16.fc12
-----------------------------
* Fri Oct 09 2009 Matthias Clasen  2.28.0-16
- Cosmetic change to the background tab in the appearance capplet


exo-0.3.104-1.fc12
------------------
* Sat Oct 10 2009 Christoph Wickert  - 0.3.103-1
- Update to 0.3.103
- Drop patches for URL quoting and default mount options (fixed upstream)
- Revert useless touch -r trick

* Sat Oct 10 2009 Christoph Wickert  - 0.3.103-2
- Disable parallel make due to multilib conflicts.

* Sat Oct 10 2009 Christoph Wickert  - 0.3.104-1
- Update to 0.3.104


kde-l10n-4.3.2-1.fc12
---------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2

* Sat Oct 03 2009 Rex Dieter  - 4.3.1-3
- main virtual subpkg


kdeaccessibility-4.3.2-1.fc12
-----------------------------
* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdeadmin-4.3.2-1.fc12
---------------------
* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdeartwork-4.3.2-1.fc12
-----------------------
* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdebase-4.3.2-3.fc12
--------------------
* Fri Oct 09 2009 Kevin Kofler  - 4.3.2-3
- backport upstream patch for bookmark editor drag&drop crash (kde#160679)

* Wed Oct 07 2009 Than Ngo  - 4.3.2-2
- fix Dolphin crash (regression)

* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdebase-runtime-4.3.2-2.fc12
----------------------------
* Tue Oct 06 2009 Rex Dieter  4.3.2-2
- BR: bzip2-devel xz-devel
- -libs: move Requires: kdepimlibs... here

* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2

* Wed Sep 30 2009 Nils Philippsen  - 4.3.1-3
- if available, use the "manpath" command in the man kioslave to determine man
  page file locations

* Wed Sep 30 2009 Nils Philippsen  - 4.3.1-4
- fix manpath patch (spotted by Kevin Kofler)


kdebase-workspace-4.3.2-1.fc12
------------------------------
* Sun Oct 04 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdebindings-4.3.2-1.fc12
------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdeedu-4.3.2-1.fc12
-------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdegames-4.3.2-1.fc12
---------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdegraphics-4.3.2-3.fc12
------------------------
* Thu Oct 08 2009 Than Ngo  - 4.3.2-2
- rhel cleanup

* Thu Oct 08 2009 Rex Dieter  - 4.3.2-3
- okular does not handle escaped URL correctly (kde#207461)

* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdelibs-4.3.2-3.fc12
--------------------
* Thu Oct 08 2009 Rex Dieter  - 4.3.2-3
- khtml kpart crasher (kde #207173/209876)

* Wed Oct 07 2009 Than Ngo  - 4.3.2-2
- fix a deadlock in KLocale

* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdelibs-experimental-4.3.2-1.fc12
---------------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdemultimedia-4.3.2-1.fc12
--------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdenetwork-4.3.2-3.fc12
-----------------------
* Fri Oct 09 2009 Kevin Kofler  - 4.3.2-3
- fix BR to be on kdelibs-experimental-devel, not kdelibs-experimental

* Wed Oct 07 2009 Than Ngo  - 4.3.2-2
- enable jingle

* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdepim-4.3.2-1.fc12
-------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdepim-runtime-4.3.2-1.fc12
---------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdepimlibs-4.3.2-1.fc12
-----------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdeplasma-addons-4.3.2-1.fc12
-----------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdesdk-4.3.2-1.fc12
-------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdetoys-4.3.2-1.fc12
--------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


kdeutils-4.3.2-1.fc12
---------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


openal-soft-1.9.563-1.d6e439244ae00a1750f0dc8b249f47efb4967a23git.fc12
----------------------------------------------------------------------
* Fri Oct 09 2009 Hans de Goede  - 1.9.563-1.d6e439244ae00a1750f0dc8b249f47efb4967a23git
- Update to 1.9.563 + some fixes from git
- This fixes:
  - Not having any sound in chromium-bsu 
  - Various openal using programs hanging on exit


oxygen-icon-theme-4.3.2-1.fc12
------------------------------
* Mon Oct 05 2009 Than Ngo  - 4.3.2-1
- 4.3.2


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 29



From imntreal at gmail.com  Sun Oct 11 13:33:12 2009
From: imntreal at gmail.com (Jameson)
Date: Sun, 11 Oct 2009 09:33:12 -0400
Subject: libprojectM Packaging Problem
In-Reply-To: <4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>
References: 
	<4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>
Message-ID: 

On Sun, Oct 11, 2009 at 2:27 AM, Mamoru Tasaka
 wrote:
> Jameson wrote, at 10/11/2009 06:37 AM +9:00:
>>
>> I'm having trouble getting the new version of libprojectM packaged,
>> and hope someone can shed some light on this for me.
>
> Would you upload the srpm you are trying somewhere?

My current attempt at their SVN code can be found at:
http://www.vtscrew.com/libprojectM-1.2.0r1295-9.fc11.src.rpm

Thanks,
=-Jameson



From mschwendt at gmail.com  Sun Oct 11 14:02:36 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 11 Oct 2009 16:02:36 +0200
Subject: libprojectM Packaging Problem
In-Reply-To: 
References: 
	<4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>
	
Message-ID: <20091011160236.4985ea67@faldor.intranet>

On Sun, 11 Oct 2009 09:33:12 -0400, Jameson wrote:

> My current attempt at their SVN code can be found at:
> http://www.vtscrew.com/libprojectM-1.2.0r1295-9.fc11.src.rpm

Patch attached. Do the same for any other directories where it may be
necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libprojectM-1.2.0r1295-cmake.patch
Type: text/x-patch
Size: 785 bytes
Desc: not available
URL: 

From imntreal at gmail.com  Sun Oct 11 14:11:06 2009
From: imntreal at gmail.com (Jameson)
Date: Sun, 11 Oct 2009 10:11:06 -0400
Subject: libprojectM Packaging Problem
In-Reply-To: <20091011160236.4985ea67@faldor.intranet>
References: 
	<4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>
	
	<20091011160236.4985ea67@faldor.intranet>
Message-ID: 

I see.  Thanks for your quick reply.  Upstream has been working with
me recently to get this building natively without some patches that
were needed in the past, so I'll pass this along.



From lists at sapience.com  Sun Oct 11 14:48:59 2009
From: lists at sapience.com (Mail Lists)
Date: Sun, 11 Oct 2009 10:48:59 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD1B68C.9020509@freenet.de>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD19D5D.7000403@fedoraproject.org>	<4AD1A266.4090902@pobox.com>	<4AD1A56F.1040305@googlemail.com>
	<4AD1B68C.9020509@freenet.de>
Message-ID: <4AD1F05B.5020101@sapience.com>


 There are several issues being discussed here.

 Thunderbird itself and what upstream are doing:
  --------------------------------------------
   (i) In my view smart folders are silly most of the time.
       Comixing different accounts is a really bad idea.

   (ii) GLODA = the global indexing nonsense is beyond silly

      This is not just indexing each account - its accross ALL accounts.
      Especially when you note that it will only index things that TB
has a local copy of in mbox format - and TB switched to make local
copies of everything by default.

      This is a solution looking for a problem - its also a problematic
solution for most, with runaway indexing, 90% CPU, eating GiB of space
etc. A good example of a runaway idea.

   I run a local imap server precisely to be independent of mail client.
Having duplicate copies of everything in mbox format (ug) .... and GiB
of index .. ug.


 Upgrade Process:
 ---------------
     I believe we should be picking up the newer versions - in fact
moving to 3.0pre and 3.0 final. TB has quirks, but overall things are
improving. We still have evo too ..

    That all said - both the above changes are simple to turn off - and
as Rahul said, prolly shoulda been off by default in our version.

    In this case there is an easy way to make things smooth. In other
cases there may not be

    For such cases we can:

       a) Not update
       b) Update
       c) Install as alternative for those who want it.

   (c) is a nice possible option if something is invasive yet of interest.

gene/





From nicolas.mailhot at laposte.net  Sun Oct 11 16:02:37 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 11 Oct 2009 18:02:37 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD1F05B.5020101@sapience.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org> <4AD1A266.4090902@pobox.com>
	<4AD1A56F.1040305@googlemail.com> <4AD1B68C.9020509@freenet.de>
	<4AD1F05B.5020101@sapience.com>
Message-ID: <1e560542f208d3922c5071ded8b76836.squirrel@arekh.dyndns.org>



Le Dim 11 octobre 2009 16:48, Mail Lists a ?crit :

>       This is not just indexing each account - its accross ALL accounts.
>       Especially when you note that it will only index things that TB
> has a local copy of in mbox format - and TB switched to make local
> copies of everything by default.

It is nice to see that the ?reborn? Mozilla mail client still thinks in terms
of pop3+mbox. This is sooo typical of the FLOSS desktop: avoid hard issues
(such as thinking in maildir+imap, actually writing a ldap backend for gconf,
taking the time to think about non-laptop systems), and pile up demo-quality
bling (that no one will use because it's not robust enough for real life)

There are three schools of design: the latin
flashy-but-will-be-broken-in-a-week, the German
just-enough-minimalist-rock-solid-workhorse, and the worst
insufficient-minimalist-will-be-broken-in-a-month (people that think Germans
like black, and release gadgets in brittle plastic, when Germans like solid
plastic, which is usually black). Unfortunately our desktop people never seem
to choose option 2.

-- 
Nicolas Mailhot




From nicolas.mailhot at laposte.net  Sun Oct 11 16:08:25 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 11 Oct 2009 18:08:25 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1e560542f208d3922c5071ded8b76836.squirrel@arekh.dyndns.org>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org> <4AD1A266.4090902@pobox.com>
	<4AD1A56F.1040305@googlemail.com> <4AD1B68C.9020509@freenet.de>
	<4AD1F05B.5020101@sapience.com>
	<1e560542f208d3922c5071ded8b76836.squirrel@arekh.dyndns.org>
Message-ID: <168b302295b8380952a77cf7fc7840d7.squirrel@arekh.dyndns.org>



Le Dim 11 octobre 2009 18:02, Nicolas Mailhot a ?crit :

> There are three schools of design: [?]. Unfortunately our desktop people
never seem
> to choose option 2.

Sorry about the unfair generalization, there are of course exceptions
http://linuxplumbersconf.org/2009/slides/Paul-Davis-lpc2009.pdf

But it's sad they are so few.

-- 
Nicolas Mailhot




From mike at cchtml.com  Sun Oct 11 16:15:17 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 11 Oct 2009 11:15:17 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <20091011084154.GA1481@tutu.torimasen.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
Message-ID: <4AD20495.1000006@cchtml.com>

On 10/11/2009 03:41 AM, Dodji Seketeli wrote:
> I don't think so. Not willing to put words in Jeff's mouth, but I don't
> think he was discussing the UI changes of Thunderbird. I took it as he was rather
> discussing the upgrade process within Fedora.
>    

So.... never ship beta software? That nixes a lot of Fedora packages.

> FWIW, I felt the disruption in my workflow as well. All of a sudden, TB
> almost freezed my computer, eating ~ 1GB of memory (OK, I have a lot of
> emails but still) and all that, in F-11 which is a stable version of the distro.
>
> I think this is the right forum to discuss how we can avoid or a least
> manage users workflow disruption within stable versions of our distro.
>    

Heavily patch all TB 3.0 to act like TB 2.0? That seems silly, don't you 
think?

This is *not* the right forum. There is a right forum[1].

[1] 
http://www.mozilla.org/community/developer-forums.html#dev-apps-thunderbird



From sundaram at fedoraproject.org  Sun Oct 11 16:19:04 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Oct 2009 21:49:04 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20495.1000006@cchtml.com>
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
Message-ID: <4AD20578.4050404@fedoraproject.org>

On 10/11/2009 09:45 PM, Michael Cronenworth wrote:

> So.... never ship beta software? That nixes a lot of Fedora packages.

Whether to include a beta or not should be decided on a case by case
basis. It is a good idea to avoid those but if there are substantial
benefits, it is fine. The focal point of the discussion isn't what it
originally include but how the software changes in updates. Do you use
thunderbird as your main mail client? If so, did you find the changes in
the update not disruptive for you?

> Heavily patch all TB 3.0 to act like TB 2.0? That seems silly, don't you
> think?
> 
> This is *not* the right forum. There is a right forum[1].
> 
> [1]
> http://www.mozilla.org/community/developer-forums.html#dev-apps-thunderbird

We aren't talking about upstream development however.  It is the
responsibility of the thunderbird package maintainers in Fedora to avoid
updates that prevents the mail client from being usable for a
substantial amount of time and changes the UI in a unexplained way. The
modifications required to avoid those would have been rather simple.

Rahul



From mcepl at redhat.com  Sun Oct 11 16:32:26 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 11 Oct 2009 16:32:26 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org>
Message-ID: 

Rahul Sundaram, Sun, 11 Oct 2009 14:24:53 +0530:
> It was ok to ship a "beta" release of thunderbird but updates shouldn't
> cause such issues. If the fixes were necessary to push as updates then
> it would have prudent to disable "smart folders" and "indexing" by
> default and leave it enabled in Fedora 12.

Rahul, aren't you arguing that Rawhide is broken?

Mat?j



From mike at cchtml.com  Sun Oct 11 16:33:03 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 11 Oct 2009 11:33:03 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20578.4050404@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>
Message-ID: <4AD208BF.5040501@cchtml.com>

On 10/11/2009 11:19 AM, Rahul Sundaram wrote:
> Whether to include a beta or not should be decided on a case by case
> basis. It is a good idea to avoid those but if there are substantial
> benefits, it is fine. The focal point of the discussion isn't what it
> originally include but how the software changes in updates. Do you use
> thunderbird as your main mail client? If so, did you find the changes in
> the update not disruptive for you?
>    

I do use TB (read my email headers). I fully understood that TB 3.0 was 
in beta and could drastically change at any moment. I keep track of 
their development as well so I was prepared for the changes that have 
happened. If you expect beta software to act like stable software then 
you need to update your dictionary.

>
> We aren't talking about upstream development however.  It is the
> responsibility of the thunderbird package maintainers in Fedora to avoid
> updates that prevents the mail client from being usable for a
> substantial amount of time and changes the UI in a unexplained way. The
> modifications required to avoid those would have been rather simple.
>
>    

The TB 3.0 updates have been sitting in updates-testing for at least a 
week or so before they are released into updates. The karma being 
received has been overwhelmingly *positive* so it's one or two 
conservative folks that really dislike change that voice their opinions 
and get some attention for the sake of attention.




From sundaram at fedoraproject.org  Sun Oct 11 16:34:05 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Oct 2009 22:04:05 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD19D5D.7000403@fedoraproject.org>
	
Message-ID: <4AD208FD.1010900@fedoraproject.org>

On 10/11/2009 10:02 PM, Matej Cepl wrote:
> Rahul Sundaram, Sun, 11 Oct 2009 14:24:53 +0530:
>> It was ok to ship a "beta" release of thunderbird but updates shouldn't
>> cause such issues. If the fixes were necessary to push as updates then
>> it would have prudent to disable "smart folders" and "indexing" by
>> default and leave it enabled in Fedora 12.
> 
> Rahul, aren't you arguing that Rawhide is broken?

I don't see where I am arguing for that.

Rahul



From mcepl at redhat.com  Sun Oct 11 16:37:15 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 11 Oct 2009 16:37:15 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org> 
Message-ID: 

Matej Cepl, Sun, 11 Oct 2009 16:32:26 +0000:

> Rahul Sundaram, Sun, 11 Oct 2009 14:24:53 +0530:
>> It was ok to ship a "beta" release of thunderbird but updates shouldn't
>> cause such issues. If the fixes were necessary to push as updates then
>> it would have prudent to disable "smart folders" and "indexing" by
>> default and leave it enabled in Fedora 12.
> 
> Rahul, aren't you arguing that Rawhide is broken?

Sorry, misread your message. Forget about this please.

Mat?j



From kevin.kofler at chello.at  Sun Oct 11 16:47:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 11 Oct 2009 18:47:17 +0200
Subject: python-json (was: Re: rawhide report: 20091010 changes)
References: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>
Message-ID: 

Rawhide Report wrote:
> Removed package python-json

Why was this removed? sugar-toolkit requires this package and now has broken 
dependencies!

        Kevin Kofler



From sundaram at fedoraproject.org  Sun Oct 11 16:46:27 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Oct 2009 22:16:27 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD208BF.5040501@cchtml.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com>
Message-ID: <4AD20BE3.4030709@fedoraproject.org>

On 10/11/2009 10:03 PM, Michael Cronenworth wrote:

> I do use TB (read my email headers). I fully understood that TB 3.0 was
> in beta and could drastically change at any moment. I keep track of
> their development as well so I was prepared for the changes that have
> happened. If you expect beta software to act like stable software then
> you need to update your dictionary.

Oh please. Expecting all Fedora thunderbird users to keep track of
upstream development of software included in Fedora is totally
ridiculous. The package maintainer made the judgement to include a beta
release of thunderbird. If major UI or other behaviour changes were
expected to follow in later revisions, it would have been wise to not
include the beta release in the first place. Otherwise, it would have
been easy enough to disable those couple of features we are talking
about in the update and avoid the hassle for users.

It is NOT ok if I update my mail client in any stable release of Fedora
and get a different UI where my folders are rearranged and my mail
client proceeds to index gigabytes of my mail sucking up the CPU and
generally making it unusable for quite sometime. A new release with a
new UI and behaviour is ok. An update changing it like this is
definitely not.

Rahul



From pbrobinson at gmail.com  Sun Oct 11 16:51:11 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sun, 11 Oct 2009 17:51:11 +0100
Subject: python-json (was: Re: rawhide report: 20091010 changes)
In-Reply-To: 
References: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>
	
Message-ID: <5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>

On Sun, Oct 11, 2009 at 5:47 PM, Kevin Kofler  wrote:
> Rawhide Report wrote:
>> Removed package python-json
>
> Why was this removed? sugar-toolkit requires this package and now has broken
> dependencies!

Apparently the functionality has been merged into the main python
package. Looking at the cvs changelog sugar-toolkit was rebuilt
against the main package but it seems that the person that did so
hasn't filed a ticket with rel-eng to get it tagged into the release,
or if the ticket was filed it is yet to be tagged into the release.

Peter



From mike at cchtml.com  Sun Oct 11 16:54:25 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Sun, 11 Oct 2009 11:54:25 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20BE3.4030709@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>
Message-ID: <4AD20DC1.9090102@cchtml.com>

On 10/11/2009 11:46 AM, Rahul Sundaram wrote:
> Oh please. Expecting all Fedora thunderbird users to keep track of
> upstream development of software included in Fedora is totally
> ridiculous. The package maintainer made the judgement to include a beta
> release of thunderbird. If major UI or other behaviour changes were
> expected to follow in later revisions, it would have been wise to not
> include the beta release in the first place. Otherwise, it would have
> been easy enough to disable those couple of features we are talking
> about in the update and avoid the hassle for users.
>    

Did I say that people should do exactly as I do? No. Please don't put 
words in my mouth.


> It is NOT ok if I update my mail client in any stable release of Fedora
> and get a different UI where my folders are rearranged and my mail
> client proceeds to index gigabytes of my mail sucking up the CPU and
> generally making it unusable for quite sometime. A new release with a
> new UI and behaviour is ok. An update changing it like this is
> definitely not.
>    

Then were was your negative karma? I run TB on 3 different machines 
(different platforms/arches) and have not encountered any "disastrous" 
side effects so my positive karma does not accurately reflect all 
possible scenarios.



From sundaram at fedoraproject.org  Sun Oct 11 17:07:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Oct 2009 22:37:41 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20DC1.9090102@cchtml.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD20DC1.9090102@cchtml.com>
Message-ID: <4AD210DD.3040202@fedoraproject.org>

On 10/11/2009 10:24 PM, Michael Cronenworth wrote:

> Did I say that people should do exactly as I do? No. Please don't put
> words in my mouth.

It did clearly appear that you implied that. To simplify matters, the
basic question really is whether it is ok for updates to cause problems
for end users. I would argue that it is not

> Then were was your negative karma? I run TB on 3 different machines
> (different platforms/arches) and have not encountered any "disastrous"
> side effects so my positive karma does not accurately reflect all
> possible scenarios.

If maintainers choose to include a beta release, then it would have been
better to collect more feedback for a longer period of time for updates.
 My mails to this list is my "negative karma". Other users have
confirmed that there are problems as well. Let's address that issue now
instead of pretending that there is no problem.

Rahul



From pbrobinson at gmail.com  Sun Oct 11 17:25:24 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sun, 11 Oct 2009 18:25:24 +0100
Subject: python-json (was: Re: rawhide report: 20091010 changes)
In-Reply-To: <5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>
References: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>
	
	<5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>
Message-ID: <5256d0b0910111025w4a7ef68fvdabb81e1be7f280f@mail.gmail.com>

On Sun, Oct 11, 2009 at 5:51 PM, Peter Robinson  wrote:
> On Sun, Oct 11, 2009 at 5:47 PM, Kevin Kofler  wrote:
>> Rawhide Report wrote:
>>> Removed package python-json
>>
>> Why was this removed? sugar-toolkit requires this package and now has broken
>> dependencies!
>
> Apparently the functionality has been merged into the main python
> package. Looking at the cvs changelog sugar-toolkit was rebuilt
> against the main package but it seems that the person that did so
> hasn't filed a ticket with rel-eng to get it tagged into the release,
> or if the ticket was filed it is yet to be tagged into the release.

There's also a rel-eng to get the build tagged into the release here
https://fedorahosted.org/rel-eng/ticket/2447

Peter



From richmattes at gmail.com  Sun Oct 11 17:33:30 2009
From: richmattes at gmail.com (Rich Mattes)
Date: Sun, 11 Oct 2009 13:33:30 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD210DD.3040202@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD20DC1.9090102@cchtml.com>
	<4AD210DD.3040202@fedoraproject.org>
Message-ID: <4AD216EA.3000000@gmail.com>

An HTML attachment was scrubbed...
URL: 

From bnocera at redhat.com  Mon Oct 12 10:02:39 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 12 Oct 2009 11:02:39 +0100
Subject: Oprhaning python-gdata
Message-ID: <1255341759.3797.5.camel@localhost.localdomain>

Heya,

Totem isn't using python-gdata anymore, so I'm orphaning it.
Feel free to pick it up at:
https://admin.fedoraproject.org/pkgdb/packages/name/python-gdata

I used this RSS feed to keep on top of new releases:
http://code.google.com//feeds/p/gdata-python-client/downloads/basic

Cheers




From rakesh.pandit at gmail.com  Mon Oct 12 10:11:25 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 12 Oct 2009 15:41:25 +0530
Subject: Package Review Stats for last 7 days ending 11th
Message-ID: 

Top four FAS account holders who have completed reviewing "Package
review" components on bugzilla for last 7 days ending 11th Oct were
Parag AN(????), Mamoru Tasaka, Nicolas Mailhot and Roman Rakus.


Parag AN(????) : 13

	https://bugzilla.redhat.com/show_bug.cgi?id=226066
	https://bugzilla.redhat.com/show_bug.cgi?id=226068
	https://bugzilla.redhat.com/show_bug.cgi?id=226069
	https://bugzilla.redhat.com/show_bug.cgi?id=226071
	https://bugzilla.redhat.com/show_bug.cgi?id=503490
	https://bugzilla.redhat.com/show_bug.cgi?id=527316
	https://bugzilla.redhat.com/show_bug.cgi?id=527317
	https://bugzilla.redhat.com/show_bug.cgi?id=527428
	https://bugzilla.redhat.com/show_bug.cgi?id=527431
	https://bugzilla.redhat.com/show_bug.cgi?id=527433
	https://bugzilla.redhat.com/show_bug.cgi?id=527445
	https://bugzilla.redhat.com/show_bug.cgi?id=226065
	https://bugzilla.redhat.com/show_bug.cgi?id=226086


Mamoru Tasaka : 4

	https://bugzilla.redhat.com/show_bug.cgi?id=526179
	https://bugzilla.redhat.com/show_bug.cgi?id=526180
	https://bugzilla.redhat.com/show_bug.cgi?id=526181
	https://bugzilla.redhat.com/show_bug.cgi?id=525211


Nicolas Mailhot : 3

	https://bugzilla.redhat.com/show_bug.cgi?id=527406
	https://bugzilla.redhat.com/show_bug.cgi?id=526607
	https://bugzilla.redhat.com/show_bug.cgi?id=526058


Roman Rakus : 3

	https://bugzilla.redhat.com/show_bug.cgi?id=503727
	https://bugzilla.redhat.com/show_bug.cgi?id=503939
	https://bugzilla.redhat.com/show_bug.cgi?id=503495


Andrew Overholt : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=528149
	https://bugzilla.redhat.com/show_bug.cgi?id=526688


Christoph Wickert : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=521913
	https://bugzilla.redhat.com/show_bug.cgi?id=507223


Martin Gieseking : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=526998
	https://bugzilla.redhat.com/show_bug.cgi?id=526004


Michel Alexandre Salim : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=523553
	https://bugzilla.redhat.com/show_bug.cgi?id=524707


Nick Bebout : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=512021
	https://bugzilla.redhat.com/show_bug.cgi?id=519483


Peter Lemenkov : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=525389
	https://bugzilla.redhat.com/show_bug.cgi?id=527231


Ben Boeckel : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=505264


Chitlesh GOORAH : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526997


Christian Krause : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=510734


Emmanuel Seyman : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=525831


Josh Boyer : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527250


Julian Aloofi : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=520352


Kevin Fenzi : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527840


Lubomir Rintel : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528125


Luke Macken : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527544


Mattias Ellert : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=520479


Praveen K Paladugu : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=524147


Richard W.M. Jones : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=525346


Thomas Janssen : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527539


Thomas Spura : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526122


William Cohen : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527971



Total reviews modified: 50
Merge Reviews: 6
Review Requests: 44

This report by generated by bzReviewReport.py.
The source is available at:
https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
Please submit patches or bug reports at: https://fedorahosted.org/triage/

-- 
Rakesh Pandit
https://fedoraproject.org/
freedom, friends, features, first



From twaugh at redhat.com  Mon Oct 12 10:55:54 2009
From: twaugh at redhat.com (Tim Waugh)
Date: Mon, 12 Oct 2009 11:55:54 +0100
Subject: cups/guttenprint color schemes wrong for Epson Stylus CX3500
 and other printers
In-Reply-To: <4AD09588.6050603@gmail.com>
References: <4AD09588.6050603@gmail.com>
Message-ID: <1255344954.2860.7.camel@localhost.localdomain>

On Sat, 2009-10-10 at 11:09 -0300, Casimiro de Almeida Barreto wrote:
> Maybe off topic but, how to correct color schemes for Epson Printers?
> Default is horrible (excess of red, wrong gamma/brightness, etc). I
> guess someone must have dealt with that.

Best is to talk directly with the gutenprint team:
  http://gutenprint.sourceforge.net/

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: 

From rawhide at fedoraproject.org  Mon Oct 12 12:38:26 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 12 Oct 2009 12:38:26 +0000
Subject: rawhide report: 20091012 changes
Message-ID: <20091012123826.GA6808@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 12 06:15:12 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From tmz at pobox.com  Mon Oct 12 13:39:08 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 12 Oct 2009 09:39:08 -0400
Subject: rpms/libid3tag/F-12 libid3tag.spec,1.19,1.20
In-Reply-To: <20091012132633.B80BD11C00DB@cvs1.fedora.phx.redhat.com>
References: <20091012132633.B80BD11C00DB@cvs1.fedora.phx.redhat.com>
Message-ID: <20091012133907.GC32748@inocybe.localdomain>

Hi Marcela,

Marcela Ma?l??ov? wrote:
> Modified Files:
> 	libid3tag.spec
> Log Message:
> * Mon Oct 12 2009 Marcela Ma?l??ov?  - 0.15.1b-10
> - rebuilt of package with correct licence
[...]
> -License:        GPLv2+
> +License:        GPLv2 or GPL+ or MIT

I could easily be missing the obvious, but why is this change needed?
All of the *.c source files have:

 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.

The COPYRIGHT file included in the tarball states GPLv2+ as well.

So where does GPL+ come from?  And what code is MIT?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It could be that the purpose of your life is only to serve as a
warning to others.
    -- Demotivators (www.despair.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From joshuacov at googlemail.com  Mon Oct 12 14:37:41 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 12 Oct 2009 16:37:41 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910061318p3c18b383m95a3460e882f5ac5@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
	
	<5f6f8c5f0910060644t6b0a48e2k2c0dca75f578d829@mail.gmail.com>
	<5f6f8c5f0910061318p3c18b383m95a3460e882f5ac5@mail.gmail.com>
Message-ID: <5f6f8c5f0910120737q5bd14f07j6b193ed8bf65ea4c@mail.gmail.com>

2009/10/6 Joshua C. :
> 2009/10/6 Joshua C. :
>> 2009/10/6 Matej Cepl :
>>> Joshua C., Mon, 05 Oct 2009 23:05:54 +0200:
>>>
>>> Do we have a bug for this? If not, please do file one and include all
>>> those information you collected for this thread together with /var/log/
>>> Xorg.0.log (if possible after the problem happened -- on reboot put 3 to
>>> the end of the kernel command line, so Xorg is not started on boot, and
>>> then you can save previous /var/log/Xorg.0.log from the session which
>>> ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg
>>> (if you can get it from other terminal than the one where you run gdb in
>>> moment things go bad).
>>>
>>> Thank you very much,
>>>
>>> Mat?j
>>>
>>> --
>>> fedora-devel-list mailing list
>>> fedora-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>
>> Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452
>>
>
> I tried the latest F12-Snap3-x86_64-Live-KDE from 18.09.2009. There
> were also other problems but I think this still exists in F12. I've
> updated my bug report with the output from gdb.
>

Looking into the debug output I think this is bug in the radeon-driver
or the drm component. Most of the instances refer to drm*** or exa***
functions. Maybe I should update the bug report?



From mhlavink at redhat.com  Mon Oct 12 15:49:56 2009
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Mon, 12 Oct 2009 17:49:56 +0200
Subject: does fedora have anything requiring :mail rw access?
In-Reply-To: 
References: <200910091531.45573.mhlavink@redhat.com>
	
Message-ID: <200910121749.56801.mhlavink@redhat.com>

On Friday 09 October 2009 16:36:34 Mike McGrath wrote:
> On Fri, 9 Oct 2009, Michal Hlavinka wrote:
> > Hi all!
> >
> > I've got quite simple question from dovecot's upstream: Why do we have rw
> > access on mails for mail group? Why /var/mail/ files have 0660
> > :mail permissions instead of 0600 permissions? The fact is, I
> > don't know the answer and I'd appreciate your help.
> >
> > Some facts:
> >
> > distro   | group | perm
> > ---------+-------+---------
> > Fedora   | mail  | 0660
> > Ubuntu   | mail  | 0600
> > openSuSE | users | 0600 (user is member of users group)
> > debian 4.0 | mail | 0660
> >
> > (Note: This is result of my own investigations on installed systems or
> > livecds, I don't know if any installed system had changed settings.)
> >
> > Interesting thing is, that when new user is added to the system, useradd
> > creates /var/mail/ file with :mail 0660 permissions,
> > but when you delete this file and the user gets new email, this file will
> > be autocreated with 0600 permissions (still :group owned) and
> > it seems everything still works.
> >
> > useradd command comes from shadow-utils and fedora contains no patch
> > changing permissions to 0660.
> >
> > The most important question is: Is there anything that requires these
> > files can be read and written by mail group?
> >
> > If you have any info regarding this, please share.
> 
> Just a guess, but if you run useradd from shell, your umask is likely
> 0002.  Sendmail's umask is probably 022 as set in /etc/init.d/functions

0660 is explicitly set by useradd:

                gr = getgrnam ("mail"); /* local, no need for xgetgrnam */
                if (NULL == gr) {
                        fputs (_("Group 'mail' not found. Creating the user 
mailbox file with 0600 mode.\n"),
                               stderr);
                        gid = user_gid;
                        mode = 0600;
                } else {
                        gid = gr->gr_gid;
                        mode = 0660;
                }



From a.badger at gmail.com  Mon Oct 12 18:12:41 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 12 Oct 2009 11:12:41 -0700
Subject: Switching python-setuptools to distribute
Message-ID: <20091012181241.GA9716@clingman.lan>

I've been a comaintainer of the python-setuptools package for a long time
and recently became the owner when icon relinquished it.  It is currently a
tumultuous time for distributing python modules with a new and active
maintainer for distutils inside of the python stdlib and a fork of
setuptools being worked on.

That fork is named distribute and there are two branches of development on
it.  The 0.7 branch aims to implement API, metadata, and other features that
will make packaging python modules for upstream building and distribution
easier while being more concerned with the effects this has on
Linux packagers.  The 0.6 branch intends to be compatible with the current
seutptools package but to fix bugs and introduce features that are backwards
compatible and oft requested.  This branch is being actively maintained by a
core group of five committers including the new distutils maintainer.  By
contrast, setuptools is maintained by a single maintainer who often has
little time to work on it.

When installed, the 0.6 branch takes over the setuptools and pkg_resources
python modules.  The reasoning is that distribute-0.6 provides the same API
as setuptools and is meant to replace it.  If the module was installed
differently, consuming code (all the setup.py modules in any setuptools
using package as well as code that relies on setuptools features at runtime)
would all need to change their import statements to use the new names
explicitly.  This choice is being made upstream by the distribute project.

Upstream, the python community has viewed the fork favorably but since it's
not part of python proper, the only one with say in the matter is the
setuptools author.  He has not been willing to abandon the setuptools module
but at the same time hasn't gained any more free time to work on setuptools.

Several other Linux distributions (gentoo and arch) have started shipping
distribute-0.6 as the source of their setuptools package.  I am thinking of
doing the same for rawhide and pushing the change to older Fedora releases
if bugs are reported that are fixed in distribute but not in seutptools as
having a responsive upstream that cares about distribution packaging issues
is a great plus for us.  I raised this plan on fedora-python-devel and
received one positive comment and no negative feedback so I'm just
mentioning it here so a broader audience can ask any questions or raise any
issues before putting this into effect.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From a.badger at gmail.com  Mon Oct 12 18:16:10 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 12 Oct 2009 11:16:10 -0700
Subject: python-json (was: Re: rawhide report: 20091010 changes)
In-Reply-To: <5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>
References: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>
	
	<5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>
Message-ID: <20091012181610.GB9716@clingman.lan>

On Sun, Oct 11, 2009 at 05:51:11PM +0100, Peter Robinson wrote:
> On Sun, Oct 11, 2009 at 5:47 PM, Kevin Kofler  wrote:
> > Rawhide Report wrote:
> >> Removed package python-json
> >
> > Why was this removed? sugar-toolkit requires this package and now has broken
> > dependencies!
> 
> Apparently the functionality has been merged into the main python
> package. Looking at the cvs changelog sugar-toolkit was rebuilt
> against the main package but it seems that the person that did so
> hasn't filed a ticket with rel-eng to get it tagged into the release,
> or if the ticket was filed it is yet to be tagged into the release.
> 
Note that the json module in python-2.6+ is the simplejson module, not the
python-json module.  For almost all uses, porting is a simple matter of
changing two function calls to the equivalent in the new toolkit.  However,
the implementations and the API are not the same.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From a.badger at gmail.com  Mon Oct 12 18:54:33 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 12 Oct 2009 11:54:33 -0700
Subject: Howto handle multilib conflict?
In-Reply-To: <1255195036.2330.23.camel@adam.local.net>
References:  <20091009234127.GD5033@clingman.lan>
	<1255135718.2330.11.camel@adam.local.net>
	
	<1255186079.2330.14.camel@adam.local.net>
	<20091010180512.041a0f80@faldor.intranet>
	<1255195036.2330.23.camel@adam.local.net>
Message-ID: <20091012185433.GD9716@clingman.lan>

On Sat, Oct 10, 2009 at 10:17:16AM -0700, Adam Williamson wrote:
> On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
> > On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
> > 
> > > Of course, that turns the larger question into 'why do we put i686
> > > -devel packages in the x86-64 repo, not just the lib packages',
> > 
> > Because not all files in -devel packages cover multiple target
> > platforms. Example: You could not build for i686 with headers that
> > are specific to x86_64, and you would also need the .so symlinks for
> > libraries in the appropriate libdir.
> 
> Well, that's only valid if we actually do anything to ensure multilib
> compilation actually *works*, right now all we enforce is that the
> packages don't conflict (which isn't the same thing at all). I hope I'm
> not dragging him into the conversation unwillingly, but Colin Walters
> raised those points on IRC:
> 
Well.. not really.  it's valid if the goal is to allow people to do multilib
compilation.  Testing that the goal hasbeen met is a separate issue.

As for feature creep -- that may be.  I'm operating under the assumption
that this is a feature as there was amessage to the list stating that this
was a current goal.  It could be that someone posted it but it was only
their opinion of what needed to be done, not an actual fact.  Would someone
or someones care to put this up for discussion at FESCo and present
rationale for and against it?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From mw_triad at users.sourceforge.net  Mon Oct 12 19:52:04 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 12 Oct 2009 14:52:04 -0500
Subject: Howto handle multilib conflict?
In-Reply-To: <1255195036.2330.23.camel@adam.local.net>
References: 
	<20091009234127.GD5033@clingman.lan>	<1255135718.2330.11.camel@adam.local.net>		<1255186079.2330.14.camel@adam.local.net>	<20091010180512.041a0f80@faldor.intranet>
	<1255195036.2330.23.camel@adam.local.net>
Message-ID: 

Adam Williamson wrote:
> On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote:
>> On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote:
>>> Of course, that turns the larger question into 'why do we put i686
>>> -devel packages in the x86-64 repo, not just the lib packages',
>> Because not all files in -devel packages cover multiple target
>> platforms. Example: You could not build for i686 with headers that
>> are specific to x86_64, and you would also need the .so symlinks for
>> libraries in the appropriate libdir.
> 
> Well, that's only valid if we actually do anything to ensure multilib
> compilation actually *works*, right now all we enforce is that the
> packages don't conflict (which isn't the same thing at all).

Well... at $DAYJOB we *depend* on being able to compile 32-bit on 64-bit 
for at least a couple products. And not just on Red Hat (and in my case, 
Fedora), but also on Solaris, HP-UX, Darwin and AIX, all of which 
support this just fine. (Yes, "all" includes Fedora/RH, at least for the 
admittedly limited set of libs we use.)

That said, I'm not asking for it to be actually tested in Fedora, just 
that if it breaks and I complain, the reply won't be "we don't care 
because that is not supported and therefore it will not be fixed". IOW I 
am fine with the current status quo, but I don't want to see multilib 
dropped (not even sure it can be due to wine) or the policy otherwise 
become explicitly hostile toward multilib compilation.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"The government is not trying to destroy Microsoft, it's simply seeking 
to compel Microsoft to obey the law. It's quite revealing that Mr. Gates 
equates the two." -- A government official



From mw_triad at users.sourceforge.net  Mon Oct 12 19:56:01 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 12 Oct 2009 14:56:01 -0500
Subject: libprojectM Packaging Problem
In-Reply-To: <20091011160236.4985ea67@faldor.intranet>
References: 	<4AD17AE7.7030301@ioa.s.u-tokyo.ac.jp>	
	<20091011160236.4985ea67@faldor.intranet>
Message-ID: 

Michael Schwendt wrote:
> On Sun, 11 Oct 2009 09:33:12 -0400, Jameson wrote:
> 
>> My current attempt at their SVN code can be found at:
>> http://www.vtscrew.com/libprojectM-1.2.0r1295-9.fc11.src.rpm
> 
> Patch attached. Do the same for any other directories where it may be
> necessary.
> 
> SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
> SET (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")

This seems fishy. Why is adding -fPIC needed (i.e. why is CMake not 
taking care of this)?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"The government is not trying to destroy Microsoft, it's simply seeking 
to compel Microsoft to obey the law. It's quite revealing that Mr. Gates 
equates the two." -- A government official



From richardfearn at gmail.com  Mon Oct 12 20:01:06 2009
From: richardfearn at gmail.com (Richard Fearn)
Date: Mon, 12 Oct 2009 21:01:06 +0100
Subject: Oprhaning python-gdata
In-Reply-To: <1255341759.3797.5.camel@localhost.localdomain>
References: <1255341759.3797.5.camel@localhost.localdomain>
Message-ID: <212718d80910121301k518485f8ua7113a8990b3c130@mail.gmail.com>

Hi,

> Totem isn't using python-gdata anymore, so I'm orphaning it.
> Feel free to pick it up at:
> https://admin.fedoraproject.org/pkgdb/packages/name/python-gdata

As I'm currently using this (to talk to Google Calendar), I wouldn't
mind taking this over, unless bjohnson wants to...

Regards,

Rich



From ismael at olea.org  Mon Oct 12 21:16:53 2009
From: ismael at olea.org (Ismael Olea)
Date: Mon, 12 Oct 2009 23:16:53 +0200
Subject: Review Request: kompozer - Web Authoring System
Message-ID: <1255382213.25138.2.camel@lisergia.olea.org>


Hi:

I'm looking for a reviewer for Kompozer. A nice fact is the Kompozer
development is very active this days and the 0.8.* series are pretty
stable. I think this is a good tool for Fedora.

https://bugzilla.redhat.com/show_bug.cgi?id=519521


Spec URL: http://olea.org/tmp/kompozer.spec
SRPM URL: http://olea.org/paquetes-rpm/fedora-11/kompozer-0.8-0.2.b1.fc11.src.rpm

Description:

A complete Web authoring system for Linux Desktop users, similar to
Microsoft Windows programs like FrontPage and Dreamweaver.

KompoZer is an unofficial branch of Nvu, previously developed by
Linspire Inc.

It makes managing a Web site a snap. Now anyone can create Web pages
and manage a Web site with no technical expertise or HTML knowledge.

Features

* WYSIWYG editing of pages, making Web creation as easy as typing a
   letter with your word processor.

* Integrated file management via FTP.  Simply log in to your Web
   site and navigate through your files, editing Web pages on the
   fly, directly from your site.

* Reliable HTML code creation that works with today's most popular
   browsers.

* Jump between WYSIWYG editing mode and HTML using tabs.

* Tabbed editing to make working on multiple pages a snap.

* Powerful support for frames, forms, tables, and templates.  


-- 

        A. Ismael Olea Gonz?lez
 
        http://olea.org/diario/
        http://aduaneros.org, la ONG sin futuro.
 
        El mundo debe empezar a tener miedo a un planeta OLEA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3635 bytes
Desc: not available
URL: 

From dmalcolm at redhat.com  Mon Oct 12 22:17:46 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Mon, 12 Oct 2009 18:17:46 -0400
Subject: Proposal: Python 3 in Fedora 13
In-Reply-To: 
References: <1254417309.9551.34.camel@radiator.bos.redhat.com>
	
Message-ID: <1255385866.9551.250.camel@radiator.bos.redhat.com>

On Sat, 2009-10-03 at 22:09 +0200, yersinia wrote:
> On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm 
> wrote:

[snip]

>         $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not
>         owned" |
> SIA, this is off of topic , i am sure. BUT, it is very strange that
> could be exists, perhaps, some file or directory  not owned by
> someone. Isn't it ?

FWIW I've done a lot of packaging experimentation on that system, and
brute-force copying of .py files into place, so there's a fair amount of
"cruft" lurking about on my system.  That's why I had that in the shell
pipeline I gave.  (But yes, this is heading off-topic)
> 
>         sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}
>         %{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0,
>         col1 from
>         - where col0 != col1





From christoph.wickert at googlemail.com  Mon Oct 12 23:41:00 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 13 Oct 2009 01:41:00 +0200
Subject: Review Request: kompozer - Web Authoring System
In-Reply-To: <1255382213.25138.2.camel@lisergia.olea.org>
References: <1255382213.25138.2.camel@lisergia.olea.org>
Message-ID: <1255390860.21208.70.camel@wicktop.localdomain>

Am Montag, den 12.10.2009, 23:16 +0200 schrieb Ismael Olea:

> Description:
> 
> A complete Web authoring system for Linux Desktop users, similar to
> Microsoft Windows programs like FrontPage and Dreamweaver.

Please remove that part. See
https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description

> It makes managing a Web site a snap. Now anyone can create Web pages
> and manage a Web site with no technical expertise or HTML knowledge.

IMO this the most important part from a user's POV, so it should be at
the beginning.

Regards,
Christoph



From bnocera at redhat.com  Tue Oct 13 01:19:49 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 13 Oct 2009 02:19:49 +0100
Subject: Oprhaning python-gdata
In-Reply-To: <212718d80910121301k518485f8ua7113a8990b3c130@mail.gmail.com>
References: <1255341759.3797.5.camel@localhost.localdomain>
	<212718d80910121301k518485f8ua7113a8990b3c130@mail.gmail.com>
Message-ID: <1255396789.3797.24.camel@localhost.localdomain>

On Mon, 2009-10-12 at 21:01 +0100, Richard Fearn wrote:
> Hi,
> 
> > Totem isn't using python-gdata anymore, so I'm orphaning it.
> > Feel free to pick it up at:
> > https://admin.fedoraproject.org/pkgdb/packages/name/python-gdata
> 
> As I'm currently using this (to talk to Google Calendar), I wouldn't
> mind taking this over, unless bjohnson wants to...

Up to you guys. It's very low maintenance, I usually only bother pushing
updates.



From icon at fedoraproject.org  Tue Oct 13 02:40:23 2009
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Mon, 12 Oct 2009 22:40:23 -0400
Subject: Switching python-setuptools to distribute
In-Reply-To: <20091012181241.GA9716@clingman.lan>
References: <20091012181241.GA9716@clingman.lan>
Message-ID: 

2009/10/12 Toshio Kuratomi :
> I've been a comaintainer of the python-setuptools package for a long time
> and recently became the owner when icon relinquished it. ?It is currently a
> tumultuous time for distributing python modules with a new and active
> maintainer for distutils inside of the python stdlib and a fork of
> setuptools being worked on.

FWIW, as a former maintainer of the package, I'm all for the switch to
distribute.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From sundaram at fedoraproject.org  Tue Oct 13 02:50:18 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Oct 2009 08:20:18 +0530
Subject: Switching python-setuptools to distribute
In-Reply-To: <20091012181241.GA9716@clingman.lan>
References: <20091012181241.GA9716@clingman.lan>
Message-ID: <4AD3EAEA.9050707@fedoraproject.org>

On 10/12/2009 11:42 PM, Toshio Kuratomi wrote:

> Several other Linux distributions (gentoo and arch) have started shipping
> distribute-0.6 as the source of their setuptools package.  I am thinking of
> doing the same for rawhide 

You might want to post to distributions mailing list @ fd.o and get
other distributions feedback as well.

Rahul



From caillon at redhat.com  Tue Oct 13 05:58:36 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 12 Oct 2009 22:58:36 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20BE3.4030709@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>
Message-ID: <4AD4170C.40609@redhat.com>

On 10/11/2009 09:46 AM, Rahul Sundaram wrote:
> On 10/11/2009 10:03 PM, Michael Cronenworth wrote:
>
>> I do use TB (read my email headers). I fully understood that TB 3.0 was
>> in beta and could drastically change at any moment. I keep track of
>> their development as well so I was prepared for the changes that have
>> happened. If you expect beta software to act like stable software then
>> you need to update your dictionary.
>
> Oh please. Expecting all Fedora thunderbird users to keep track of
> upstream development of software included in Fedora is totally
> ridiculous. The package maintainer made the judgement to include a beta
> release of thunderbird. If major UI or other behaviour changes were
> expected to follow in later revisions, it would have been wise to not
> include the beta release in the first place. Otherwise, it would have
> been easy enough to disable those couple of features we are talking
> about in the update and avoid the hassle for users.

The changes were not expected.  Actually, the fact that TB3 is still in 
beta was not expected, since it was supposed to be released as a final 
within a week of FF35.  Clearly, things haven't been going as planned 
for upstream and that's had an effect on Fedora, too.  While the changes 
are unfortunate, they have gone through testing, and I'll note that 
Thunderbird is _NOT_ the default mail client in Fedora, so it won't 
impact the majority of Fedora users.  None of this is any excuse for 
things, but are important to consider when casting stones.



From sundaram at fedoraproject.org  Tue Oct 13 06:18:15 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Oct 2009 11:48:15 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD4170C.40609@redhat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
Message-ID: <4AD41BA7.5030004@fedoraproject.org>

On 10/13/2009 11:28 AM, Christopher Aillon wrote:
> 
> The changes were not expected.  Actually, the fact that TB3 is still in
> beta was not expected, since it was supposed to be released as a final
> within a week of FF35.  Clearly, things haven't been going as planned
> for upstream and that's had an effect on Fedora, too.  While the changes
> are unfortunate, they have gone through testing, and I'll note that
> Thunderbird is _NOT_ the default mail client in Fedora, so it won't
> impact the majority of Fedora users.  None of this is any excuse for
> things, but are important to consider when casting stones.

I am not casting stones. Just frustrated at Fedora updates frequently
causing problems. Was disabling those two features by default in the
update considered?

Rahul



From jgarzik at pobox.com  Tue Oct 13 06:43:45 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Tue, 13 Oct 2009 02:43:45 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD4170C.40609@redhat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
Message-ID: <4AD421A1.6060609@pobox.com>

On 10/13/2009 01:58 AM, Christopher Aillon wrote:
> On 10/11/2009 09:46 AM, Rahul Sundaram wrote:
>> On 10/11/2009 10:03 PM, Michael Cronenworth wrote:
>>
>>> I do use TB (read my email headers). I fully understood that TB 3.0 was
>>> in beta and could drastically change at any moment. I keep track of
>>> their development as well so I was prepared for the changes that have
>>> happened. If you expect beta software to act like stable software then
>>> you need to update your dictionary.
>>
>> Oh please. Expecting all Fedora thunderbird users to keep track of
>> upstream development of software included in Fedora is totally
>> ridiculous. The package maintainer made the judgement to include a beta
>> release of thunderbird. If major UI or other behaviour changes were
>> expected to follow in later revisions, it would have been wise to not
>> include the beta release in the first place. Otherwise, it would have
>> been easy enough to disable those couple of features we are talking
>> about in the update and avoid the hassle for users.
>
> The changes were not expected. Actually, the fact that TB3 is still in
> beta was not expected, since it was supposed to be released as a final
> within a week of FF35. Clearly, things haven't been going as planned for
> upstream and that's had an effect on Fedora, too. While the changes are
> unfortunate, they have gone through testing, and I'll note that


er, huh?  What does that mean?

If testing had been done, then why were these two _blindingly obvious_ 
behavior changes pushed to F11?

Where did the process break down, then?

Did the package maintainer think that UI and indexing changes in the 
middle of a stable Fedora release are acceptable, general practice?

The indexing change has created a new wrinkle, too:  I separate my work 
and non-work email for LEGAL reasons.  Now the index has smushed those 
two together.  Lovely, fscking lovely...

	Jeff





From sundaram at fedoraproject.org  Tue Oct 13 08:33:16 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Oct 2009 14:03:16 +0530
Subject: Oprhaning python-gdata
In-Reply-To: <1255396789.3797.24.camel@localhost.localdomain>
References: <1255341759.3797.5.camel@localhost.localdomain>	<212718d80910121301k518485f8ua7113a8990b3c130@mail.gmail.com>
	<1255396789.3797.24.camel@localhost.localdomain>
Message-ID: <4AD43B4C.1070302@fedoraproject.org>

On 10/13/2009 06:49 AM, Bastien Nocera wrote:
> On Mon, 2009-10-12 at 21:01 +0100, Richard Fearn wrote:
>> Hi,
>>
>>> Totem isn't using python-gdata anymore, so I'm orphaning it.
>>> Feel free to pick it up at:
>>> https://admin.fedoraproject.org/pkgdb/packages/name/python-gdata
>>
>> As I'm currently using this (to talk to Google Calendar), I wouldn't
>> mind taking this over, unless bjohnson wants to...
> 
> Up to you guys. It's very low maintenance, I usually only bother pushing
> updates.

I have picked it up.  Anyone else interested, feel free to add yourself
as a co-maintainer.

Rahul



From rodd at clarkson.id.au  Tue Oct 13 10:13:44 2009
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 13 Oct 2009 21:13:44 +1100
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
Message-ID: <1255428824.3049.7.camel@moose.localdomain>

On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
> 2009/10/5 Adam Jackson :
> > On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
> >
> >> (gdb) bt
> >> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
> >> #1  0x00000000004e615a in WaitForSomething (
> >>     pClientsReady=) at WaitFor.c:228
> >> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
> >> #3  0x000000000042d205 in main (argc=,
> >>     argv=0x7fffa2ac9218, envp=) at main.c:397
> >
> > Okay, this isn't the server actually taking 100% of the CPU (almost
> > certainly), it's before that.  If you type 'cont' to resume, and then ^C
> > the gdb process once the CPU goes wild, you should break back to the gdb
> > prompt; _that_'s the backtrace I need.
> >
> > Of course, you might not, in which case debugging this gets a bit
> > harder.
> >
> > - ajax
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> (gdb) handle SIGUSR1 nostop
> Signal        Stop      Print   Pass to program Description
> SIGUSR1       No        Yes     Yes             User defined signal 1
> (gdb) handle SIGUSR2 nostop
> Signal        Stop      Print   Pass to program Description
> SIGUSR2       No        Yes     Yes             User defined signal 2
> (gdb) handle SIGPIPE nostop
> Signal        Stop      Print   Pass to program Description
> SIGPIPE       No        Yes     Yes             Broken pipe
> (gdb) cont
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
> (gdb) bt
> #0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
> #1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
> arg=0x7fff78cabbc0) at xf86drm.c:187
> #2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
> drmCommandIndex=, data=0x7fff78cabbc0,
> size=)
>     at xf86drm.c:2363
> #3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf= optimized out>) at radeon_bufmgr_gem.c:282
> #4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
> index=0) at radeon_exa.c:279
> #5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
> index=0) at exa.c:523
> #6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
> index=0, pReg=0x0) at exa.c:543
> #7  0x00007f6c69beceac in ExaCheckComposite (op=,
> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>,
>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
> width=55, height=18) at exa_unaccel.c:342
> #8  0x00007f6c69beb564 in exaComposite (op=,
> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>,
>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
> width=55, height=18) at exa_render.c:967
> #9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc= optimized out>, pMask=, pDst=0x27a04b0, xSrc=1,
> ySrc=0,
>     xMask=, yMask=, xDst=19,
> yDst=85, width=55, height=) at damage.c:643
> #10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
> #11 0x00000000004471d4 in Dispatch () at dispatch.c:456
> #12 0x000000000042d205 in main (argc=,
> argv=0x7fff78cac198, envp=) at main.c:397
> 

Hmmm, I wonder if you're not having the same issues (or similar) to me.

See: https://bugzilla.redhat.com/show_bug.cgi?id=528593

If I run gdb I get the following:

#0  0x00000032c16d9717 in ioctl () at ../sysdeps/unix/syscall-template.S:82
#1  0x00000032dec03203 in drmIoctl (fd=9, request=3221775460, 
    arg=0x7fff192a1ab0) at xf86drm.c:188
#2  0x00000032dec0344c in drmCommandWriteRead (fd=, 
    drmCommandIndex=, data=, 
    size=) at xf86drm.c:2394
#3  0x00007f7cc9f81f59 in bo_wait (bo=0x1cdc780) at radeon_bo_gem.c:206
#4  0x00007f7cc9f82035 in bo_map (bo=0x1cdc780, write=)
    at radeon_bo_gem.c:181
#5  0x00007f7cca24f36d in _radeon_bo_map (line=2320, 
    func=, file=0x1 
, write=0, 
    bo=) at /usr/include/drm/radeon_bo.h:151
#6  R600DownloadFromScreenCS (line=2320, func=, 
    file=0x1 
, write=0, bo=)
    at r600_exa.c:2320
#7  0x00007f7cc9545100 in exaGetImage (pDrawable=0x1b37dc0, x=1536, y=704, 
    w=256, h=64, format=, 
    planeMask=, d=)
    at exa_accel.c:1283
#8  0x0000000000552a94 in miSpriteGetImage (pDrawable=0x1b37dc0, sx=1536, 
    sy=704, w=256, h=64, format=, 
    planemask=, pdstLine=)
    at misprite.c:425
#9  0x000000000042dec0 in DoGetImage (planemask=, 
    height=, width=, 
    y=, x=, 
    drawable=, format=, 
    client=0x1d2f5f0, im_return=) at dispatch.c:2244
#10 ProcGetImage (planemask=, 
    height=, width=, 
    y=, x=, 
    drawable=, format=, 
    client=0x1d2f5f0, im_return=) at dispatch.c:2331
#11 0x000000000042c60c in Dispatch () at dispatch.c:445
#12 0x0000000000421c9a in main (argc=, 
    argv=, envp=) at main.c:285




Rodd



From ndbecker2 at gmail.com  Tue Oct 13 11:10:06 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 13 Oct 2009 07:10:06 -0400
Subject: Howto handle multilib conflict?
References: 
Message-ID: 

I received the following from upstream.  Anyone know the answer to the 
question (how do freetype-config, etc workaround this issue?)

In article <200910092117.36851.ndbecker2 at gmail.com>, Neal Becker 
 writes:

> I maintain libotf for Fedora.

Thank you very much for that work!

> We have received a bug report of a multilib 
> conflict, which occurs when installing development packages for both i586 
and 
> x86_64.  The problem is /usr/bin/libotf-config, which occurs in both 
packages 
> but is not identical.

> My solution is to remove this file.  I'm hoping it's not really needed.   
> libotf already has package-config support (which is multilib compatible 
> already), so if all apps use package-config there should be no problem.

> Are there any apps that need /usr/bin/libotf-config to your knowledge?

As far as I know, there's none.  So, it's ok to remove
libotf-config.  But, why does libotf-config don't work with
multilib?  How do the other XXX-config programs
(e.g. freetype-config, fribidi-config, gtk-config, ...) work
with multilib?



From schwab at redhat.com  Tue Oct 13 11:22:32 2009
From: schwab at redhat.com (Andreas Schwab)
Date: Tue, 13 Oct 2009 13:22:32 +0200
Subject: Howto handle multilib conflict?
In-Reply-To:  (Neal Becker's message of "Tue, 13
	Oct 2009 07:10:06 -0400")
References:  
Message-ID: 

Neal Becker  writes:

> I received the following from upstream.  Anyone know the answer to the 
> question (how do freetype-config, etc workaround this issue?)

freetype-config is just a wrapper around pkg-config.

Andreas.

-- 
Andreas Schwab, schwab at redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."



From rawhide at fedoraproject.org  Tue Oct 13 11:30:37 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 13 Oct 2009 11:30:37 +0000
Subject: rawhide report: 20091013 changes
Message-ID: <20091013113037.GA22976@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 13 06:15:09 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Updated Packages:

anaconda-12.37-1.fc12
---------------------
* Mon Oct 12 2009 David Cantrell  - 12.37-1
- Missing volume_key shouldn't break LUKS support completely. (#526899)
  (dlehman)
- Write multipathd.conf in anaconda so that dracut can find it. (pjones)
- Add MultipathDevice.getDMNode(), because .updateSysfsPath() needs it.
  (pjones)
- Add MultipathDevice.updateSysfsPath() (pjones)
- Fix a segfault when stage2= boot parameter and kickstart url method is
  used (#524417). (rvykydal)
- Fix parsing of optional portnr in iscsi target IP (#525118) (hdegoede)


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1



From fedora at matbooth.co.uk  Tue Oct 13 11:52:30 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 13 Oct 2009 12:52:30 +0100
Subject: Switching python-setuptools to distribute
In-Reply-To: <20091012181241.GA9716@clingman.lan>
References: <20091012181241.GA9716@clingman.lan>
Message-ID: <9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>

2009/10/12 Toshio Kuratomi :
> I've been a comaintainer of the python-setuptools package for a long time
> and recently became the owner when icon relinquished it. ?It is currently a
> tumultuous time for distributing python modules with a new and active
> maintainer for distutils inside of the python stdlib and a fork of
> setuptools being worked on.
>
> That fork is named distribute and there are two branches of development on
> it. ?The 0.7 branch aims to implement API, metadata, and other features that
> will make packaging python modules for upstream building and distribution
> easier while being more concerned with the effects this has on
> Linux packagers. ?The 0.6 branch intends to be compatible with the current
> seutptools package but to fix bugs and introduce features that are backwards
> compatible and oft requested. ?This branch is being actively maintained by a
> core group of five committers including the new distutils maintainer. ?By
> contrast, setuptools is maintained by a single maintainer who often has
> little time to work on it.
>
> When installed, the 0.6 branch takes over the setuptools and pkg_resources
> python modules. ?The reasoning is that distribute-0.6 provides the same API
> as setuptools and is meant to replace it. ?If the module was installed
> differently, consuming code (all the setup.py modules in any setuptools
> using package as well as code that relies on setuptools features at runtime)
> would all need to change their import statements to use the new names
> explicitly. ?This choice is being made upstream by the distribute project.
>
> Upstream, the python community has viewed the fork favorably but since it's
> not part of python proper, the only one with say in the matter is the
> setuptools author. ?He has not been willing to abandon the setuptools module
> but at the same time hasn't gained any more free time to work on setuptools.
>
> Several other Linux distributions (gentoo and arch) have started shipping
> distribute-0.6 as the source of their setuptools package. ?I am thinking of
> doing the same for rawhide and pushing the change to older Fedora releases
> if bugs are reported that are fixed in distribute but not in seutptools as
> having a responsive upstream that cares about distribution packaging issues
> is a great plus for us. ?I raised this plan on fedora-python-devel and
> received one positive comment and no negative feedback so I'm just
> mentioning it here so a broader audience can ask any questions or raise any
> issues before putting this into effect.
>
> -Toshio
>

I was unaware of all this. Is there a reason why the setuptools author
will not grant commit rights to others? Going solely on your email it
seems like a fork would be unnecessary if he was willing to share the
workload...


-- 
Mat Booth

A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?



From pertusus at free.fr  Tue Oct 13 12:15:27 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Oct 2009 14:15:27 +0200
Subject: Howto handle multilib conflict?
In-Reply-To: 
References: 
 
Message-ID: <20091013121527.GA27425@free.fr>

On Tue, Oct 13, 2009 at 07:10:06AM -0400, Neal Becker wrote:
> 
> As far as I know, there's none.  So, it's ok to remove
> libotf-config.  But, why does libotf-config don't work with
> multilib?  How do the other XXX-config programs
> (e.g. freetype-config, fribidi-config, gtk-config, ...) work
> with multilib?

In many cases, conflict arise because there is a -L%{_libdir}
which is not needed anyway since it is already on the search
path. Otherwise it is possible for upstream to ship and old-style
*-config script and a wrapper around pkgconfig such that, as a 
packager you can chose to install the wrapper around pkgconfig.
If I recall well, this is what is done in libdap.

--
Pat



From mmaslano at redhat.com  Tue Oct 13 12:29:00 2009
From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=)
Date: Tue, 13 Oct 2009 14:29:00 +0200
Subject: rpms/libid3tag/F-12 libid3tag.spec,1.19,1.20
In-Reply-To: <20091012133907.GC32748@inocybe.localdomain>
References: <20091012132633.B80BD11C00DB@cvs1.fedora.phx.redhat.com>
	<20091012133907.GC32748@inocybe.localdomain>
Message-ID: <4AD4728C.6070903@redhat.com>

On 10/12/2009 03:39 PM, Todd Zullinger wrote:
> Hi Marcela,
>
> Marcela Ma?l??ov? wrote:
>    
>> Modified Files:
>> 	libid3tag.spec
>> Log Message:
>> * Mon Oct 12 2009 Marcela Ma?l??ov?  - 0.15.1b-10
>> - rebuilt of package with correct licence
>>      
> [...]
>    
>> -License:        GPLv2+
>> +License:        GPLv2 or GPL+ or MIT
>>      
> I could easily be missing the obvious, but why is this change needed?
> All of the *.c source files have:
>
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
>   * the Free Software Foundation; either version 2 of the License, or
>   * (at your option) any later version.
>
> The COPYRIGHT file included in the tarball states GPLv2+ as well.
>
> So where does GPL+ come from?  And what code is MIT?
>
>    
I'm really sorry. I went through reviews of many packages with
script, which has many false positives. Your package was perfectly
okay as it was before.

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From lmacken at redhat.com  Tue Oct 13 12:59:07 2009
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 13 Oct 2009 08:59:07 -0400
Subject: python-json (was: Re: rawhide report: 20091010 changes)
In-Reply-To: <5256d0b0910111025w4a7ef68fvdabb81e1be7f280f@mail.gmail.com>
References: <20091010125924.GA32204@releng2.fedora.phx.redhat.com>
	
	<5256d0b0910110951i307fa949u61717a186f671ef9@mail.gmail.com>
	<5256d0b0910111025w4a7ef68fvdabb81e1be7f280f@mail.gmail.com>
Message-ID: <20091013125907.GG3171@x300.cable.rcn.com>

On Sun, Oct 11, 2009 at 06:25:24PM +0100, Peter Robinson wrote:
> On Sun, Oct 11, 2009 at 5:51 PM, Peter Robinson  wrote:
> > On Sun, Oct 11, 2009 at 5:47 PM, Kevin Kofler  wrote:
> >> Rawhide Report wrote:
> >>> Removed package python-json
> >>
> >> Why was this removed? sugar-toolkit requires this package and now has broken
> >> dependencies!

I killed python-json and went through and nuked it from the distro,
as Python2.6 now provides simplejson as a 'json' module.

I tried to do this without causing any breakage, but I definitely forgot
to file the releng ticket to get the F12 build tagged.  Should be fixed
shortly.

Thanks,

luke



From joshuacov at googlemail.com  Tue Oct 13 12:59:08 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 13 Oct 2009 14:59:08 +0200
Subject: Help with debuging Xserver / Goes in an infinite loop
In-Reply-To: <1255428824.3049.7.camel@moose.localdomain>
References: <5f6f8c5f0910030813l78ccbdbdr20ba51abf619a418@mail.gmail.com>
	<1254756030.11711.0.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910050839u38efd8e8y68d7dc83d4e6c010@mail.gmail.com>
	<1254758813.11711.18.camel@atropine.boston.devel.redhat.com>
	
	<5f6f8c5f0910051019l15f3b419g89f4df8aaba5f98@mail.gmail.com>
	<1254772254.11711.126.camel@atropine.boston.devel.redhat.com>
	<5f6f8c5f0910051405nd107641gcb12cc2fe88e9c3c@mail.gmail.com>
	<1255428824.3049.7.camel@moose.localdomain>
Message-ID: <5f6f8c5f0910130559u461a613dg924853a6f965c349@mail.gmail.com>

2009/10/13 Rodd Clarkson :
> On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
>> 2009/10/5 Adam Jackson :
>> > On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
>> >
>> >> (gdb) bt
>> >> #0  0x0000003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
>> >> #1  0x00000000004e615a in WaitForSomething (
>> >>     pClientsReady=) at WaitFor.c:228
>> >> #2  0x0000000000446ef2 in Dispatch () at dispatch.c:386
>> >> #3  0x000000000042d205 in main (argc=,
>> >>     argv=0x7fffa2ac9218, envp=) at main.c:397
>> >
>> > Okay, this isn't the server actually taking 100% of the CPU (almost
>> > certainly), it's before that.  If you type 'cont' to resume, and then ^C
>> > the gdb process once the CPU goes wild, you should break back to the gdb
>> > prompt; _that_'s the backtrace I need.
>> >
>> > Of course, you might not, in which case debugging this gets a bit
>> > harder.
>> >
>> > - ajax
>> >
>> > --
>> > fedora-devel-list mailing list
>> > fedora-devel-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>> >
>>
>> (gdb) handle SIGUSR1 nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGUSR1       No        Yes     Yes             User defined signal 1
>> (gdb) handle SIGUSR2 nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGUSR2       No        Yes     Yes             User defined signal 2
>> (gdb) handle SIGPIPE nostop
>> Signal        Stop      Print   Pass to program Description
>> SIGPIPE       No        Yes     Yes             Broken pipe
>> (gdb) cont
>> Continuing.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x0000003cc3cd6827 in ioctl () from /lib64/libc.so.6
>> #1  0x0000003cd6003113 in drmIoctl (fd=8, request=3221775460,
>> arg=0x7fff78cabbc0) at xf86drm.c:187
>> #2  0x0000003cd600335c in drmCommandWriteRead (fd=8,
>> drmCommandIndex=, data=0x7fff78cabbc0,
>> size=)
>>     at xf86drm.c:2363
>> #3  0x00007f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=> optimized out>) at radeon_bufmgr_gem.c:282
>> #4  0x00007f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
>> index=0) at radeon_exa.c:279
>> #5  0x00007f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
>> index=0) at exa.c:523
>> #6  0x00007f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
>> index=0, pReg=0x0) at exa.c:543
>> #7  0x00007f6c69beceac in ExaCheckComposite (op=,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=> out>,
>>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_unaccel.c:342
>> #8  0x00007f6c69beb564 in exaComposite (op=,
>> pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=> out>,
>>     ySrc=, xMask=0, yMask=0, xDst=19, yDst=85,
>> width=55, height=18) at exa_render.c:967
>> #9  0x000000000052eb90 in damageComposite (op=8 '\b', pSrc=> optimized out>, pMask=, pDst=0x27a04b0, xSrc=1,
>> ySrc=0,
>>     xMask=, yMask=, xDst=19,
>> yDst=85, width=55, height=) at damage.c:643
>> #10 0x000000000052720c in ProcRenderComposite (client=0x2625310) at render.c:720
>> #11 0x00000000004471d4 in Dispatch () at dispatch.c:456
>> #12 0x000000000042d205 in main (argc=,
>> argv=0x7fff78cac198, envp=) at main.c:397
>>
>
> Hmmm, I wonder if you're not having the same issues (or similar) to me.
>
> See: https://bugzilla.redhat.com/show_bug.cgi?id=528593
>
> If I run gdb I get the following:
>
> #0  0x00000032c16d9717 in ioctl () at ../sysdeps/unix/syscall-template.S:82
> #1  0x00000032dec03203 in drmIoctl (fd=9, request=3221775460,
>    arg=0x7fff192a1ab0) at xf86drm.c:188
> #2  0x00000032dec0344c in drmCommandWriteRead (fd=,
>    drmCommandIndex=, data=,
>    size=) at xf86drm.c:2394
> #3  0x00007f7cc9f81f59 in bo_wait (bo=0x1cdc780) at radeon_bo_gem.c:206
> #4  0x00007f7cc9f82035 in bo_map (bo=0x1cdc780, write=)
>    at radeon_bo_gem.c:181
> #5  0x00007f7cca24f36d in _radeon_bo_map (line=2320,
>    func=, file=0x1 
, write=0,
>    bo=) at /usr/include/drm/radeon_bo.h:151
> #6  R600DownloadFromScreenCS (line=2320, func=,
>    file=0x1 
, write=0, bo=)
>    at r600_exa.c:2320
> #7  0x00007f7cc9545100 in exaGetImage (pDrawable=0x1b37dc0, x=1536, y=704,
>    w=256, h=64, format=,
>    planeMask=, d=)
>    at exa_accel.c:1283
> #8  0x0000000000552a94 in miSpriteGetImage (pDrawable=0x1b37dc0, sx=1536,
>    sy=704, w=256, h=64, format=,
>    planemask=, pdstLine=)
>    at misprite.c:425
> #9  0x000000000042dec0 in DoGetImage (planemask=,
>    height=, width=,
>    y=, x=,
>    drawable=, format=,
>    client=0x1d2f5f0, im_return=) at dispatch.c:2244
> #10 ProcGetImage (planemask=,
>    height=, width=,
>    y=, x=,
>    drawable=, format=,
>    client=0x1d2f5f0, im_return=) at dispatch.c:2331
> #11 0x000000000042c60c in Dispatch () at dispatch.c:445
> #12 0x0000000000421c9a in main (argc=,
>    argv=, envp=) at main.c:285
>
>
>
>
> Rodd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Yes, I think it's the same. In my case the mouse pointer also stops
working shortly after the screen freeezes. Until now I haven't seen
this happen after login but only with firefox. I also use kde, no
gnome here. You have radeon 3670 and mine is rs482. Testing with
F12-snap3 didn't show any improvements either.

I hope this gets fixed soon because the pc is almost useless (happens
100% of time).



From tmz at pobox.com  Tue Oct 13 13:29:35 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 13 Oct 2009 09:29:35 -0400
Subject: rpms/libid3tag/F-12 libid3tag.spec,1.19,1.20
In-Reply-To: <4AD4728C.6070903@redhat.com>
References: <20091012132633.B80BD11C00DB@cvs1.fedora.phx.redhat.com>
	<20091012133907.GC32748@inocybe.localdomain>
	<4AD4728C.6070903@redhat.com>
Message-ID: <20091013132935.GG32748@inocybe.localdomain>

Marcela Ma?l??ov? wrote:
> I'm really sorry. I went through reviews of many packages with
> script, which has many false positives. Your package was perfectly
> okay as it was before.

:)  No worries, I'm glad I asked.  Will you handle reverting this
change or shall I?  It wasn't ever built, just committed and tagged,
correct?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
User, n.: The word computer professionals use when they mean "idiot."
    -- Dave Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From caillon at redhat.com  Tue Oct 13 13:56:09 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 13 Oct 2009 06:56:09 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD421A1.6060609@pobox.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
Message-ID: <4AD486F9.5040300@redhat.com>

On 10/12/2009 11:43 PM, Jeff Garzik wrote:
> On 10/13/2009 01:58 AM, Christopher Aillon wrote:
>> On 10/11/2009 09:46 AM, Rahul Sundaram wrote:
>>> On 10/11/2009 10:03 PM, Michael Cronenworth wrote:
>>>
>>>> I do use TB (read my email headers). I fully understood that TB 3.0 was
>>>> in beta and could drastically change at any moment. I keep track of
>>>> their development as well so I was prepared for the changes that have
>>>> happened. If you expect beta software to act like stable software then
>>>> you need to update your dictionary.
>>>
>>> Oh please. Expecting all Fedora thunderbird users to keep track of
>>> upstream development of software included in Fedora is totally
>>> ridiculous. The package maintainer made the judgement to include a beta
>>> release of thunderbird. If major UI or other behaviour changes were
>>> expected to follow in later revisions, it would have been wise to not
>>> include the beta release in the first place. Otherwise, it would have
>>> been easy enough to disable those couple of features we are talking
>>> about in the update and avoid the hassle for users.
>>
>> The changes were not expected. Actually, the fact that TB3 is still in
>> beta was not expected, since it was supposed to be released as a final
>> within a week of FF35. Clearly, things haven't been going as planned for
>> upstream and that's had an effect on Fedora, too. While the changes are
>> unfortunate, they have gone through testing, and I'll note that
>
>
> er, huh? What does that mean?
>
> If testing had been done, then why were these two _blindingly obvious_
> behavior changes pushed to F11?
>
> Where did the process break down, then?
>
> Did the package maintainer think that UI and indexing changes in the
> middle of a stable Fedora release are acceptable, general practice?
>
> The indexing change has created a new wrinkle, too: I separate my work
> and non-work email for LEGAL reasons. Now the index has smushed those
> two together. Lovely, fscking lovely...

The UI change was obvious, but as it was upstream's decision, and we 
follow upstream, didn't think much of it.  In retrospect, we should have 
considered undoing that change.  We are looking into that now.

Not everyone had issues with the indexing so that seemed to slip past 
testing.  It was a change, but didn't seem to disrupt things, so we let 
it slide.

We are looking at reverting both in F11.



From caillon at redhat.com  Tue Oct 13 14:10:52 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 13 Oct 2009 07:10:52 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD41BA7.5030004@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD41BA7.5030004@fedoraproject.org>
Message-ID: <4AD48A6C.6000007@redhat.com>

On 10/12/2009 11:18 PM, Rahul Sundaram wrote:
> On 10/13/2009 11:28 AM, Christopher Aillon wrote:
>>
>> The changes were not expected.  Actually, the fact that TB3 is still in
>> beta was not expected, since it was supposed to be released as a final
>> within a week of FF35.  Clearly, things haven't been going as planned
>> for upstream and that's had an effect on Fedora, too.  While the changes
>> are unfortunate, they have gone through testing, and I'll note that
>> Thunderbird is _NOT_ the default mail client in Fedora, so it won't
>> impact the majority of Fedora users.  None of this is any excuse for
>> things, but are important to consider when casting stones.
>
> I am not casting stones. Just frustrated at Fedora updates frequently
> causing problems. Was disabling those two features by default in the
> update considered?

No, because they didn't cause problems for us or anyone in testing, and 
the changes were not expected to cause much of an issue.  The UI change 
was obvious, but we had no problem with it, and did not expect an uproar 
over it.  The indexer works for some people without issue, but 
apparently not for all people without issue.  It's unfortunate that the 
people who tried it after it was pushed live were the ones affected, but 
them's the breaks.  As I said, we're looking at what we can do for both 
issues in F11.



From ajax at redhat.com  Tue Oct 13 14:16:16 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 13 Oct 2009 10:16:16 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255060578.9958.11.camel@code.and.org>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
Message-ID: <1255443376.11711.2143.camel@atropine.boston.devel.redhat.com>

On Thu, 2009-10-08 at 23:56 -0400, James Antill wrote:
> On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote:
> > The thing with doing updates for F11 is the regression rate due to
> > lack of QA, I put Mesa packages into updates-testing that fixed a 
> > lot of r300/r500 bugs back at the start of F11 and it went into
> > testing a few weeks later and broke Intel, I got 0 reports during that
> > u-t phase about breakage. So now I have a package in stable that
> > lets 3D works for x num of people and breaks compiz for y number.
> 
>  The problem is that PPAs/KoPeRs are going to get much less testing than
> stuff in updates-testing, so if you don't think you are getting enough
> testing in updates-testing I really don't see how KoPeRs will solve that
> problem.

The problem for X is we have multiple interdependent parts, so if we
actually want to pull in an update we need to get X + kernel + driver +
mesa + libdrm all tagged into a buildroot override.  This is... slightly
risky.  Kernel is a particularly fun bit, since there are other reasons
why a kernel update would want to go out; you don't want to break drm
for Peter to fix Paul's wireless.

If we were more aggressive about backporting the kernel drm bits, and
there was some slightly easier (preferably Makefile.common-driven) way
of getting a package into the buildroot before being in -updates proper,
we could probably do without lookaside repos.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mmaslano at redhat.com  Tue Oct 13 14:19:16 2009
From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=)
Date: Tue, 13 Oct 2009 16:19:16 +0200
Subject: rpms/libid3tag/F-12 libid3tag.spec,1.19,1.20
In-Reply-To: <20091013132935.GG32748@inocybe.localdomain>
References: <20091012132633.B80BD11C00DB@cvs1.fedora.phx.redhat.com>
	<20091012133907.GC32748@inocybe.localdomain>
	<4AD4728C.6070903@redhat.com>
	<20091013132935.GG32748@inocybe.localdomain>
Message-ID: <4AD48C64.6060305@redhat.com>

On 10/13/2009 03:29 PM, Todd Zullinger wrote:
> Marcela Ma?l??ov? wrote:
>    
>> I'm really sorry. I went through reviews of many packages with
>> script, which has many false positives. Your package was perfectly
>> okay as it was before.
>>      
> :)  No worries, I'm glad I asked.  Will you handle reverting this
> change or shall I?  It wasn't ever built, just committed and tagged,
> correct?
>
>    
I checked koji builds and it wasn't build. I revert it in cvs. Sorry again.

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From a.badger at gmail.com  Tue Oct 13 14:30:57 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 13 Oct 2009 07:30:57 -0700
Subject: Switching python-setuptools to distribute
In-Reply-To: <9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
References: <20091012181241.GA9716@clingman.lan>
	<9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
Message-ID: <20091013143057.GE9716@clingman.lan>

On Tue, Oct 13, 2009 at 12:52:30PM +0100, Mat Booth wrote:
> 
> I was unaware of all this. Is there a reason why the setuptools author
> will not grant commit rights to others? Going solely on your email it
> seems like a fork would be unnecessary if he was willing to share the
> workload...
> 
He doesn't trust any of the people who want to work on it to touch his code.
He has made two or three other people committers but they lack either time
or interest in working on it.  In my personal interactions with him, he's a
control freak who wants to personally vette all the changes that go in.

This fork has been years in the making but if you want to see that yourself,
you'll need to read the python-dev archives for the past few months and
distutils-sig archives for the past few years.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From georgios.giannakis.stavros at gmail.com  Tue Oct 13 15:13:07 2009
From: georgios.giannakis.stavros at gmail.com (GEORGIOS GIANNAKIS)
Date: Tue, 13 Oct 2009 18:13:07 +0300
Subject: Switching python-setuptools to distribute
In-Reply-To: <9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
References: <20091012181241.GA9716@clingman.lan>
	<9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
Message-ID: <2add652f0910130813u55c29ff0yc6af0f5701ed9900@mail.gmail.com>

2009/10/13, Mat Booth :
> 2009/10/12 Toshio Kuratomi :
>> I've been a comaintainer of the python-setuptools package for a long time
>> and recently became the owner when icon relinquished it.  It is currently
>> a
>> tumultuous time for distributing python modules with a new and active
>> maintainer for distutils inside of the python stdlib and a fork of
>> setuptools being worked on.
>>
>> That fork is named distribute and there are two branches of development on
>> it.  The 0.7 branch aims to implement API, metadata, and other features
>> that
>> will make packaging python modules for upstream building and distribution
>> easier while being more concerned with the effects this has on
>> Linux packagers.  The 0.6 branch intends to be compatible with the current
>> seutptools package but to fix bugs and introduce features that are
>> backwards
>> compatible and oft requested.  This branch is being actively maintained by
>> a
>> core group of five committers including the new distutils maintainer.  By
>> contrast, setuptools is maintained by a single maintainer who often has
>> little time to work on it.
>>
>> When installed, the 0.6 branch takes over the setuptools and pkg_resources
>> python modules.  The reasoning is that distribute-0.6 provides the same
>> API
>> as setuptools and is meant to replace it.  If the module was installed
>> differently, consuming code (all the setup.py modules in any setuptools
>> using package as well as code that relies on setuptools features at
>> runtime)
>> would all need to change their import statements to use the new names
>> explicitly.  This choice is being made upstream by the distribute project.
>>
>> Upstream, the python community has viewed the fork favorably but since
>> it's
>> not part of python proper, the only one with say in the matter is the
>> setuptools author.  He has not been willing to abandon the setuptools
>> module
>> but at the same time hasn't gained any more free time to work on
>> setuptools.
>>
>> Several other Linux distributions (gentoo and arch) have started shipping
>> distribute-0.6 as the source of their setuptools package.  I am thinking
>> of
>> doing the same for rawhide and pushing the change to older Fedora releases
>> if bugs are reported that are fixed in distribute but not in seutptools as
>> having a responsive upstream that cares about distribution packaging
>> issues
>> is a great plus for us.  I raised this plan on fedora-python-devel and
>> received one positive comment and no negative feedback so I'm just
>> mentioning it here so a broader audience can ask any questions or raise
>> any
>> issues before putting this into effect.
>>
>> -Toshio
>>
>
> I was unaware of all this. Is there a reason why the setuptools author
> will not grant commit rights to others? Going solely on your email it
> seems like a fork would be unnecessary if he was willing to share the
> workload...
>
>
> --
> Mat Booth
>
> A: Because it destroys the order of the conversation.
> Q: Why shouldn't you do it?
> A: Posting your reply above the original message.
> Q: What is top-posting?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From georgios.giannakis.stavros at gmail.com  Tue Oct 13 15:22:27 2009
From: georgios.giannakis.stavros at gmail.com (GEORGIOS GIANNAKIS)
Date: Tue, 13 Oct 2009 18:22:27 +0300
Subject: Switching python-setuptools to distribute
In-Reply-To: <2add652f0910130813u55c29ff0yc6af0f5701ed9900@mail.gmail.com>
References: <20091012181241.GA9716@clingman.lan>
	<9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
	<2add652f0910130813u55c29ff0yc6af0f5701ed9900@mail.gmail.com>
Message-ID: <2add652f0910130822h21e1fce0nf8ac7242a344644f@mail.gmail.com>

WHO IS CORSEPIU?

2009/10/13, GEORGIOS GIANNAKIS :
> 2009/10/13, Mat Booth :
>> 2009/10/12 Toshio Kuratomi :
>>> I've been a comaintainer of the python-setuptools package for a long
>>> time
>>> and recently became the owner when icon relinquished it.  It is
>>> currently
>>> a
>>> tumultuous time for distributing python modules with a new and active
>>> maintainer for distutils inside of the python stdlib and a fork of
>>> setuptools being worked on.
>>>
>>> That fork is named distribute and there are two branches of development
>>> on
>>> it.  The 0.7 branch aims to implement API, metadata, and other features
>>> that
>>> will make packaging python modules for upstream building and
>>> distribution
>>> easier while being more concerned with the effects this has on
>>> Linux packagers.  The 0.6 branch intends to be compatible with the
>>> current
>>> seutptools package but to fix bugs and introduce features that are
>>> backwards
>>> compatible and oft requested.  This branch is being actively maintained
>>> by
>>> a
>>> core group of five committers including the new distutils maintainer.
>>> By
>>> contrast, setuptools is maintained by a single maintainer who often has
>>> little time to work on it.
>>>
>>> When installed, the 0.6 branch takes over the setuptools and
>>> pkg_resources
>>> python modules.  The reasoning is that distribute-0.6 provides the same
>>> API
>>> as setuptools and is meant to replace it.  If the module was installed
>>> differently, consuming code (all the setup.py modules in any setuptools
>>> using package as well as code that relies on setuptools features at
>>> runtime)
>>> would all need to change their import statements to use the new names
>>> explicitly.  This choice is being made upstream by the distribute
>>> project.
>>>
>>> Upstream, the python community has viewed the fork favorably but since
>>> it's
>>> not part of python proper, the only one with say in the matter is the
>>> setuptools author.  He has not been willing to abandon the setuptools
>>> module
>>> but at the same time hasn't gained any more free time to work on
>>> setuptools.
>>>
>>> Several other Linux distributions (gentoo and arch) have started
>>> shipping
>>> distribute-0.6 as the source of their setuptools package.  I am thinking
>>> of
>>> doing the same for rawhide and pushing the change to older Fedora
>>> releases
>>> if bugs are reported that are fixed in distribute but not in seutptools
>>> as
>>> having a responsive upstream that cares about distribution packaging
>>> issues
>>> is a great plus for us.  I raised this plan on fedora-python-devel and
>>> received one positive comment and no negative feedback so I'm just
>>> mentioning it here so a broader audience can ask any questions or raise
>>> any
>>> issues before putting this into effect.
>>>
>>> -Toshio
>>>
>>
>> I was unaware of all this. Is there a reason why the setuptools author
>> will not grant commit rights to others? Going solely on your email it
>> seems like a fork would be unnecessary if he was willing to share the
>> workload...
>>
>>
>> --
>> Mat Booth
>>
>> A: Because it destroys the order of the conversation.
>> Q: Why shouldn't you do it?
>> A: Posting your reply above the original message.
>> Q: What is top-posting?
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>



From georgios.giannakis.stavros at gmail.com  Tue Oct 13 15:22:33 2009
From: georgios.giannakis.stavros at gmail.com (GEORGIOS GIANNAKIS)
Date: Tue, 13 Oct 2009 18:22:33 +0300
Subject: Switching python-setuptools to distribute
In-Reply-To: <2add652f0910130822h21e1fce0nf8ac7242a344644f@mail.gmail.com>
References: <20091012181241.GA9716@clingman.lan>
	<9497e9990910130452j4ce956c9y8a891a0e3a1003eb@mail.gmail.com>
	<2add652f0910130813u55c29ff0yc6af0f5701ed9900@mail.gmail.com>
	<2add652f0910130822h21e1fce0nf8ac7242a344644f@mail.gmail.com>
Message-ID: <2add652f0910130822kc1fd794md9160a9cc7a34d2c@mail.gmail.com>

2009/10/13, GEORGIOS GIANNAKIS :
> WHO IS CORSEPIU?
>
> 2009/10/13, GEORGIOS GIANNAKIS :
>> 2009/10/13, Mat Booth :
>>> 2009/10/12 Toshio Kuratomi :
>>>> I've been a comaintainer of the python-setuptools package for a long
>>>> time
>>>> and recently became the owner when icon relinquished it.  It is
>>>> currently
>>>> a
>>>> tumultuous time for distributing python modules with a new and active
>>>> maintainer for distutils inside of the python stdlib and a fork of
>>>> setuptools being worked on.
>>>>
>>>> That fork is named distribute and there are two branches of development
>>>> on
>>>> it.  The 0.7 branch aims to implement API, metadata, and other features
>>>> that
>>>> will make packaging python modules for upstream building and
>>>> distribution
>>>> easier while being more concerned with the effects this has on
>>>> Linux packagers.  The 0.6 branch intends to be compatible with the
>>>> current
>>>> seutptools package but to fix bugs and introduce features that are
>>>> backwards
>>>> compatible and oft requested.  This branch is being actively maintained
>>>> by
>>>> a
>>>> core group of five committers including the new distutils maintainer.
>>>> By
>>>> contrast, setuptools is maintained by a single maintainer who often has
>>>> little time to work on it.
>>>>
>>>> When installed, the 0.6 branch takes over the setuptools and
>>>> pkg_resources
>>>> python modules.  The reasoning is that distribute-0.6 provides the same
>>>> API
>>>> as setuptools and is meant to replace it.  If the module was installed
>>>> differently, consuming code (all the setup.py modules in any setuptools
>>>> using package as well as code that relies on setuptools features at
>>>> runtime)
>>>> would all need to change their import statements to use the new names
>>>> explicitly.  This choice is being made upstream by the distribute
>>>> project.
>>>>
>>>> Upstream, the python community has viewed the fork favorably but since
>>>> it's
>>>> not part of python proper, the only one with say in the matter is the
>>>> setuptools author.  He has not been willing to abandon the setuptools
>>>> module
>>>> but at the same time hasn't gained any more free time to work on
>>>> setuptools.
>>>>
>>>> Several other Linux distributions (gentoo and arch) have started
>>>> shipping
>>>> distribute-0.6 as the source of their setuptools package.  I am
>>>> thinking
>>>> of
>>>> doing the same for rawhide and pushing the change to older Fedora
>>>> releases
>>>> if bugs are reported that are fixed in distribute but not in seutptools
>>>> as
>>>> having a responsive upstream that cares about distribution packaging
>>>> issues
>>>> is a great plus for us.  I raised this plan on fedora-python-devel and
>>>> received one positive comment and no negative feedback so I'm just
>>>> mentioning it here so a broader audience can ask any questions or raise
>>>> any
>>>> issues before putting this into effect.
>>>>
>>>> -Toshio
>>>>
>>>
>>> I was unaware of all this. Is there a reason why the setuptools author
>>> will not grant commit rights to others? Going solely on your email it
>>> seems like a fork would be unnecessary if he was willing to share the
>>> workload...
>>>
>>>
>>> --
>>> Mat Booth
>>>
>>> A: Because it destroys the order of the conversation.
>>> Q: Why shouldn't you do it?
>>> A: Posting your reply above the original message.
>>> Q: What is top-posting?
>>>
>>> --
>>> fedora-devel-list mailing list
>>> fedora-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>
>



From jreznik at redhat.com  Tue Oct 13 15:25:31 2009
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Tue, 13 Oct 2009 17:25:31 +0200
Subject: KDE-SIG weekly report (42/2009)
Message-ID: <200910131725.31983.jreznik@redhat.com>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 42/2009

Time: 2009-10-13 14:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-13

Meeting minutes: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-13/fedora-meeting.2009-10-13-14.04.html

Meeting log: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-13/fedora-meeting.2009-10-13-14.04.log.html

----------------------------------------------------------------------------------

= Participants =

* BenBoeckel
* JaroslavReznik
* KevinKofler
* LukasTinkl
* RexDieter
* SebastianVahl
* ThanNgo
* ThomasJanssen 

----------------------------------------------------------------------------------

= Agenda =

* topics to discuss
o a generic, F12 kde spin status
o the KDE spin website status
o FUDCon Toronto
o prelink issues

* recent bugs:
o #528283 - In Amarok the Browsers column is not selectable, meaning no music 
can be played

= Summary =

o a generic, F12 kde spin status
* the size is the same as last week (704M/x86_64) 
** it should fit CD
** svahl is still testing some removals
** kickstarts are not branched for beta yet

o the KDE spin website status
* we need content for KDE spin page
* currently only mockups, pre-HTML at [1] (see intructions [2])
* jreznik is going to coordinate effort
** but needs help from all members ;-) (thomasj)
* we need Fedora KDE description, more detailed info and screenshots
* depending on license we can use upstream bits as base

o FUDCon Toronto
* confirmed people - rdieter, SMParrish, mathstuf, aseigo!
* waiting for jreznik (pending passport, funding)

o prelink issues
* svahl asked if prelink issues are fixed and if it's ok to re-enable it on 
live CD
* all known issues are fixed
* we agreed we don't want prelink on live system but we'd like to have it on 
installed system
** enabled in livecd script

= Recent bugs =

#528283
* bug in qgtkstyle
** has to be fixed

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-20

----------------------------------------------------------------------------------

= Links =
[1] git://git.fedorahosted.org/git/fedora-web.git
[2] http://mairin.wordpress.com/2009/10/09/let-me-bling-your-
spin/#comment-3324

= Buglist =
https://bugzilla.redhat.com/show_bug.cgi?id=528283
-- 
Jaroslav ?ezn?k 
Associate Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.                               http://cz.redhat.com/



From panemade at gmail.com  Tue Oct 13 16:34:02 2009
From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=)
Date: Tue, 13 Oct 2009 22:04:02 +0530
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
	1.27 sources, 1.10, 1.11
In-Reply-To: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
Message-ID: 

Hi,

On Tue, Oct 13, 2009 at 9:26 PM, Adam Jackson  wrote:
> Author: ajax
>
> Update of /cvs/pkgs/rpms/libXres/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12383
>
> Modified Files:
> ? ? ? ?.cvsignore libXres.spec sources
> Log Message:
> * Tue Oct 13 2009 Adam Jackson  1.0.4-1
> - libXres 1.0.4
>
>
>
> Index: .cvsignore
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXres/devel/.cvsignore,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -p -r1.9 -r1.10
> --- .cvsignore ?6 Jan 2007 00:12:42 -0000 ? ? ? 1.9
> +++ .cvsignore ?13 Oct 2009 15:56:03 -0000 ? ? ?1.10
> @@ -1 +1 @@
> -libXres-1.0.3.tar.bz2
> +libXres-1.0.4.tar.bz2
>
>
> Index: libXres.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXres/devel/libXres.spec,v
> retrieving revision 1.26
> retrieving revision 1.27
> diff -u -p -r1.26 -r1.27
> --- libXres.spec ? ? ? ?14 Aug 2009 11:13:43 -0000 ? ? ?1.26
> +++ libXres.spec ? ? ? ?13 Oct 2009 15:56:03 -0000 ? ? ?1.27
> @@ -1,7 +1,7 @@
> ?Summary: X-Resource extension client library
> ?Name: libXres
> -Version: 1.0.3
> -Release: 9%{?dist}
> +Version: 1.0.4
> +Release: 1%{?dist}
> ?License: MIT
> ?Group: System Environment/Libraries
> ?URL: http://www.x.org
> @@ -9,9 +9,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version
>
> ?Source0: ftp://ftp.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
>
> -BuildRequires: pkgconfig
> -BuildRequires: libX11-devel
> -BuildRequires: libXext-devel
> +BuildRequires: pkgconfig(xext)
>
> ?%description
> ?X-Resource is an extension that allows a client to query
> @@ -21,7 +19,6 @@ the X server about its usage of various
> ?Summary: Development files for %{name}
> ?Group: Development/Libraries
> ?Requires: %{name} = %{version}-%{release}
> -Requires: pkgconfig

  According to Review Guidelines "MUST: Packages containing
pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory
ownership and usability)", this should not be removed.
>
> ?%description devel
> ?X.Org X11 libXres development package
> @@ -29,20 +26,14 @@ X.Org X11 libXres development package
> ?%prep
> ?%setup -q
>
> -# Disable static library creation by default.
> -%define with_static 0
> -
> ?%build
> -%configure \
> -%if ! %{with_static}
> - ? ? ? --disable-static
> -%endif
> +%configure --disable-static
> ?make %{?_smp_mflags}
>
> ?%install
> ?rm -rf $RPM_BUILD_ROOT
>
> -make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
> +make install DESTDIR=$RPM_BUILD_ROOT

  I think its good to keep timestamps.

>
> ?# We intentionally don't ship *.la files
> ?rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
> @@ -62,15 +53,15 @@ rm -rf $RPM_BUILD_ROOT
> ?%files devel
> ?%defattr(-,root,root,-)
> ?%{_includedir}/X11/extensions/XRes.h
> -%if %{with_static}
> -%{_libdir}/libXRes.a
> -%endif
> ?%{_libdir}/libXRes.so
> ?%{_libdir}/pkgconfig/xres.pc
> ?#%dir %{_mandir}/man3x
> ?%{_mandir}/man3/*.3*
>
> ?%changelog
> +* Tue Oct 13 2009 Adam Jackson  1.0.4-1
> +- libXres 1.0.4
> +
> ?* Thu Aug 13 2009 Parag  1.0.3-9
> ?- Merge-review cleanups #226086
>
>
>
> Index: sources
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXres/devel/sources,v
> retrieving revision 1.10
> retrieving revision 1.11
> diff -u -p -r1.10 -r1.11
> --- sources ? ? 6 Jan 2007 00:12:42 -0000 ? ? ? 1.10
> +++ sources ? ? 13 Oct 2009 15:56:03 -0000 ? ? ?1.11
> @@ -1 +1 @@
> -de66ffb657aba64c9d6dbdeabb757f3e ?libXres-1.0.3.tar.bz2
> +4daf91f93d924e693f6f6ed276791be2 ?libXres-1.0.4.tar.bz2
>
> --
> fedora-extras-commits mailing list
> fedora-extras-commits at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-commits
>

- Parag.



From panemade at gmail.com  Tue Oct 13 16:48:31 2009
From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=)
Date: Tue, 13 Oct 2009 22:18:31 +0530
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34 
	sources, 1.12, 1.13
In-Reply-To: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
Message-ID: 

Hi ,

On Tue, Oct 13, 2009 at 9:21 PM, Adam Jackson  wrote:
> Author: ajax
>
> Update of /cvs/pkgs/rpms/libXt/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv10252
>
> Modified Files:
> ? ? ? ?.cvsignore libXt.spec sources
> Log Message:
> * Tue Oct 13 2009 Adam Jackson  1.0.7-1
> - libXt 1.0.7
>
>
>
> Index: .cvsignore
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXt/devel/.cvsignore,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -p -r1.11 -r1.12
> --- .cvsignore ?2 Jul 2009 17:33:37 -0000 ? ? ? 1.11
> +++ .cvsignore ?13 Oct 2009 15:51:12 -0000 ? ? ?1.12
> @@ -1 +1 @@
> -libXt-1.0.6.tar.bz2
> +libXt-1.0.7.tar.bz2
>
>
> Index: libXt.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXt/devel/libXt.spec,v
> retrieving revision 1.33
> retrieving revision 1.34
> diff -u -p -r1.33 -r1.34
> --- libXt.spec ?25 Jul 2009 05:15:26 -0000 ? ? ?1.33
> +++ libXt.spec ?13 Oct 2009 15:51:12 -0000 ? ? ?1.34
> @@ -1,7 +1,7 @@
> ?Summary: X.Org X11 libXt runtime library
> ?Name: libXt
> -Version: 1.0.6
> -Release: 3%{?dist}
> +Version: 1.0.7
> +Release: 1%{?dist}
> ?License: MIT
> ?Group: System Environment/Libraries
> ?URL: http://www.x.org
> @@ -11,9 +11,7 @@ Source0: ftp://ftp.x.org/pub/individual/
>
> ?Patch0: ? ? libXt-1.0.2-libsm-fix.patch
>
> -BuildRequires: xorg-x11-proto-devel
> -BuildRequires: libX11-devel
> -BuildRequires: libSM-devel
> +BuildRequires: pkgconfig(xproto) pkgconfig(x11) pkgconfig(sm)
>
> ?%description
> ?X.Org X11 libXt runtime library
> @@ -23,11 +21,6 @@ Summary: X.Org X11 libXt development pac
> ?Group: Development/Libraries
> ?Requires: %{name} = %{version}-%{release}
>
> -# needed by xt.pc
> -Requires: xorg-x11-proto-devel
> -Requires: libX11-devel
> -Requires: libSM-devel
> -
  I am confused here. Why this is removed? I still see xt.pc needs
those "Requires".


> ?%description devel
> ?X.Org X11 libXt development package
>
> @@ -106,6 +99,9 @@ rm -rf $RPM_BUILD_ROOT
> ?%{_mandir}/man3/*.3*
>
> ?%changelog
> +* Tue Oct 13 2009 Adam Jackson  1.0.7-1
> +- libXt 1.0.7
> +
> ?* Fri Jul 24 2009 Fedora Release Engineering  - 1.0.6-3
> ?- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
>
>
>
> Index: sources
> ===================================================================
> RCS file: /cvs/pkgs/rpms/libXt/devel/sources,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -p -r1.12 -r1.13
> --- sources ? ? 2 Jul 2009 17:33:37 -0000 ? ? ? 1.12
> +++ sources ? ? 13 Oct 2009 15:51:13 -0000 ? ? ?1.13
> @@ -1 +1 @@
> -953930ddf9fdaa1405732c7f01e9e599 ?libXt-1.0.6.tar.bz2
> +96f3c93434a93186d178b60d4a262496 ?libXt-1.0.7.tar.bz2
>
> --
> fedora-extras-commits mailing list
> fedora-extras-commits at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-commits
>

- Parag.



From mike.cloaked at gmail.com  Tue Oct 13 17:01:21 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Tue, 13 Oct 2009 17:01:21 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>
Message-ID: 

Christopher Aillon  redhat.com> writes:

> The UI change was obvious, but as it was upstream's decision, and we 
> follow upstream, didn't think much of it.  In retrospect, we should have 
> considered undoing that change.  We are looking into that now.
> 
> Not everyone had issues with the indexing so that seemed to slip past 
> testing.  It was a change, but didn't seem to disrupt things, so we let 
> it slide.
> 
> We are looking at reverting both in F11.
> 

Please don't revert the package - now that I have configured TB to work well by
switching off gloda and also switching off smart folders it actually does work
well!  Maybe it could be an optional package revert?





From jkeating at redhat.com  Tue Oct 13 17:21:05 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Oct 2009 10:21:05 -0700
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34
 sources, 1.12, 1.13
In-Reply-To: 
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
Message-ID: <1255454465.4148.400.camel@localhost.localdomain>

On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:
>   I am confused here. Why this is removed? I still see xt.pc needs
> those "Requires". 

rpm now autogenerates the pkgconfig requirements,
both /usr/bin/pkg-config and also the pkgconfig(foo) level requirements.
Maybe the guidelines haven't caught up to this yet?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From ajax at redhat.com  Tue Oct 13 17:21:38 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 13 Oct 2009 13:21:38 -0400
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
 1.27 sources, 1.10, 1.11
In-Reply-To: 
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
	
Message-ID: <1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>

On Tue, 2009-10-13 at 22:04 +0530, Parag N(????) wrote:

> > -BuildRequires: pkgconfig
> > -BuildRequires: libX11-devel
> > -BuildRequires: libXext-devel
> > +BuildRequires: pkgconfig(xext)
> >
> >  %description
> >  X-Resource is an extension that allows a client to query
> > @@ -21,7 +19,6 @@ the X server about its usage of various
> >  Summary: Development files for %{name}
> >  Group: Development/Libraries
> >  Requires: %{name} = %{version}-%{release}
> > -Requires: pkgconfig
> 
>   According to Review Guidelines "MUST: Packages containing
> pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory
> ownership and usability)", this should not be removed.

atropine:~% repoquery --whatprovides 'pkgconfig(xext)'
libXext-devel-0:1.0.99.4-3.fc12.i686
atropine:~% repoquery --requires libXext-devel | grep pkg
pkgconfig
pkgconfig(x11)
pkgconfig(xextproto)

So, whatever.  Clearly the pkgconfig autorequires are doing the right
thing: -devel packages that provide a .pc file pick up a Requires:
pkgconfig.  The guidelines should be fixed.

- ajax


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From ajax at redhat.com  Tue Oct 13 17:25:05 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 13 Oct 2009 13:25:05 -0400
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34
 sources, 1.12, 1.13
In-Reply-To: 
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
Message-ID: <1255454705.11711.2166.camel@atropine.boston.devel.redhat.com>

On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:

> > -# needed by xt.pc
> > -Requires: xorg-x11-proto-devel
> > -Requires: libX11-devel
> > -Requires: libSM-devel
> > -
>   I am confused here. Why this is removed? I still see xt.pc needs
> those "Requires".

Because rpm is smart enough to figure that out for itself now.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From skvidal at fedoraproject.org  Tue Oct 13 17:32:10 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 13 Oct 2009 13:32:10 -0400 (EDT)
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34
 sources, 1.12, 1.13
In-Reply-To: <1255454465.4148.400.camel@localhost.localdomain>
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454465.4148.400.camel@localhost.localdomain>
Message-ID: 



On Tue, 13 Oct 2009, Jesse Keating wrote:

> On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:
>>   I am confused here. Why this is removed? I still see xt.pc needs
>> those "Requires".
>
> rpm now autogenerates the pkgconfig requirements,
> both /usr/bin/pkg-config and also the pkgconfig(foo) level requirements.
> Maybe the guidelines haven't caught up to this yet?

Probably true.


I'd just like to add a note to Parag: Thanks for reading the package 
commits. It pleases me that people are checking up on various commits that 
go in.

This change in particular seems harmless but it's nice to know there 
are people looking at any commits of any packages.

-sv



From a.badger at gmail.com  Tue Oct 13 17:32:28 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 13 Oct 2009 10:32:28 -0700
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
	1.27 sources, 1.10, 1.11
In-Reply-To: <1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>
Message-ID: <20091013173228.GG9716@clingman.lan>

On Tue, Oct 13, 2009 at 01:21:38PM -0400, Adam Jackson wrote:
> 
> atropine:~% repoquery --whatprovides 'pkgconfig(xext)'
> libXext-devel-0:1.0.99.4-3.fc12.i686
> atropine:~% repoquery --requires libXext-devel | grep pkg
> pkgconfig
> pkgconfig(x11)
> pkgconfig(xextproto)
> 
> So, whatever.  Clearly the pkgconfig autorequires are doing the right
> thing: -devel packages that provide a .pc file pick up a Requires:
> pkgconfig.  The guidelines should be fixed.
> 
Agreed - do you have time to find out when the pkgconfig autoprovides went
into effect and put up a draft on the wiki?  Link it to:
https://fedoraproject.org/wiki/PackagingDrafts

If all Fedora releases have the autoprovides but EL-5 is still affected, the
draft can be as simple as: rpm detects pkgconfig dependencies in all Fedora
releases, please move the pkgconfig requires from [LINK] to the EPEL
specific guidelines.

Thanks,
-Tosiho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From ajax at redhat.com  Tue Oct 13 18:20:52 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 13 Oct 2009 14:20:52 -0400
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
 1.27 sources, 1.10, 1.11
In-Reply-To: <20091013173228.GG9716@clingman.lan>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>
	<20091013173228.GG9716@clingman.lan>
Message-ID: <1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>

On Tue, 2009-10-13 at 10:32 -0700, Toshio Kuratomi wrote:
> If all Fedora releases have the autoprovides but EL-5 is still
> affected, the
> draft can be as simple as: rpm detects pkgconfig dependencies in all
> Fedora
> releases, please move the pkgconfig requires from [LINK] to the EPEL
> specific guidelines. 

Done:

https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires

AFAICT this became automagic in F-10, but I can't find any overt history
of that in redhat-rpm-macros.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From christoph.wickert at googlemail.com  Tue Oct 13 18:35:16 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 13 Oct 2009 20:35:16 +0200
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34
 sources, 1.12, 1.13
In-Reply-To: <1255454465.4148.400.camel@localhost.localdomain>
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454465.4148.400.camel@localhost.localdomain>
Message-ID: <1255458916.2968.80.camel@wicktop.localdomain>

Am Dienstag, den 13.10.2009, 10:21 -0700 schrieb Jesse Keating:
> On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:
> >   I am confused here. Why this is removed? I still see xt.pc needs
> > those "Requires". 
> 
> rpm now autogenerates the pkgconfig requirements,
> both /usr/bin/pkg-config and also the pkgconfig(foo) level requirements.

Changes like this really should be announced! And by "announced" I mean
a mail to fedora-devel-announce.

It's really funny that certain rpm developers (none of them involved in
this thread) blame people for still following outdated information but
are to lazy to write a quick announcement.

Regards,
Christoph



From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Oct 13 18:42:38 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 14 Oct 2009 03:42:38 +0900
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
 1.27 sources, 1.10, 1.11
In-Reply-To: <1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>		<1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>	<20091013173228.GG9716@clingman.lan>
	<1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AD4CA1E.6060504@ioa.s.u-tokyo.ac.jp>

Adam Jackson wrote, at 10/14/2009 03:20 AM +9:00:
> On Tue, 2009-10-13 at 10:32 -0700, Toshio Kuratomi wrote:
>> If all Fedora releases have the autoprovides but EL-5 is still
>> affected, the
>> draft can be as simple as: rpm detects pkgconfig dependencies in all
>> Fedora
>> releases, please move the pkgconfig requires from [LINK] to the EPEL
>> specific guidelines. 
> 
> Done:
> 
> https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires
> 
> AFAICT this became automagic in F-10, but I can't find any overt history
> of that in redhat-rpm-macros.
> 
> - ajax

Actually in the change of rpm (not redhat-rpm-config) and from F-11.
Note that F-10 rpm also generated pkgconfig related "Provides" lists,
but not "Requires" list (i.e. adding "Requires: pkgconfig" and some
pkgconfig related Requires list is still needed for F-10 packages, although
F-10 is going to be EOL).
The example is the following packages.

F-11: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1592955
F-10: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1592985

The explanation is:
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02173.html

Regards,
Mamoru



From mschwendt at gmail.com  Tue Oct 13 18:45:05 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 13 Oct 2009 20:45:05 +0200
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
 1.27 sources, 1.10, 1.11
In-Reply-To: <1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454498.11711.2165.camel@atropine.boston.devel.redhat.com>
	<20091013173228.GG9716@clingman.lan>
	<1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
Message-ID: <20091013204505.462040b7@faldor.intranet>

On Tue, 13 Oct 2009 14:20:52 -0400, Adam wrote:

> On Tue, 2009-10-13 at 10:32 -0700, Toshio Kuratomi wrote:
> > If all Fedora releases have the autoprovides but EL-5 is still
> > affected, the
> > draft can be as simple as: rpm detects pkgconfig dependencies in all
> > Fedora
> > releases, please move the pkgconfig requires from [LINK] to the EPEL
> > specific guidelines. 
> 
> Done:
> 
> https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires
> 
> AFAICT this became automagic in F-10, but I can't find any overt history
> of that in redhat-rpm-macros.

If memory serves correctly, the roll-out took place in two steps:
1) Enabling automatic pkgconfig Provides.
2) Enabling automatic pkgconfig Requires.
F-10 initially started with only 1 and a later RPM update added 2, but
F-11 started with both.



From awilliam at redhat.com  Tue Oct 13 19:25:17 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Tue, 13 Oct 2009 12:25:17 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD20495.1000006@cchtml.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
Message-ID: <1255461917.2330.86.camel@adam.local.net>

On Sun, 2009-10-11 at 11:15 -0500, Michael Cronenworth wrote:
> On 10/11/2009 03:41 AM, Dodji Seketeli wrote:
> > I don't think so. Not willing to put words in Jeff's mouth, but I don't
> > think he was discussing the UI changes of Thunderbird. I took it as he was rather
> > discussing the upgrade process within Fedora.
> >    
> 
> So.... never ship beta software? That nixes a lot of Fedora packages.
> 
> > FWIW, I felt the disruption in my workflow as well. All of a sudden, TB
> > almost freezed my computer, eating ~ 1GB of memory (OK, I have a lot of
> > emails but still) and all that, in F-11 which is a stable version of the distro.
> >
> > I think this is the right forum to discuss how we can avoid or a least
> > manage users workflow disruption within stable versions of our distro.
> >    
> 
> Heavily patch all TB 3.0 to act like TB 2.0? That seems silly, don't you 
> think?

I believe the suggestion was to make a very minor configuration change
so the new behaviours were not enabled by default.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From sundaram at fedoraproject.org  Tue Oct 13 19:27:17 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 00:57:17 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD48A6C.6000007@redhat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD41BA7.5030004@fedoraproject.org> <4AD48A6C.6000007@redhat.com>
Message-ID: <4AD4D495.4050103@fedoraproject.org>

On 10/13/2009 07:40 PM, Christopher Aillon wrote:

> No, because they didn't cause problems for us or anyone in testing, and
> the changes were not expected to cause much of an issue.  The UI change
> was obvious, but we had no problem with it, and did not expect an uproar
> over it.  The indexer works for some people without issue, but
> apparently not for all people without issue.  It's unfortunate that the
> people who tried it after it was pushed live were the ones affected, but
> them's the breaks.  As I said, we're looking at what we can do for both
> issues in F11.

The general attitude in this thread (not you) and elsewhere that it was
ok to cause problems was worrying me. Thanks for looking into this problem.

Rahul



From rdieter at math.unl.edu  Tue Oct 13 19:42:18 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 13 Oct 2009 14:42:18 -0500
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33,
	1.34 sources, 1.12, 1.13
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454465.4148.400.camel@localhost.localdomain>
	<1255458916.2968.80.camel@wicktop.localdomain>
Message-ID: 

Christoph Wickert wrote:

> Am Dienstag, den 13.10.2009, 10:21 -0700 schrieb Jesse Keating:
>> On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:
>> >   I am confused here. Why this is removed? I still see xt.pc needs
>> > those "Requires".
>> 
>> rpm now autogenerates the pkgconfig requirements,
>> both /usr/bin/pkg-config and also the pkgconfig(foo) level requirements.
> 
> Changes like this really should be announced! And by "announced" I mean
> a mail to fedora-devel-announce.

I see it first mentioned here anyway:
https://www.redhat.com/archives/fedora-devel-announce/2008-
July/msg00002.html

-- Rex



From mike.cloaked at gmail.com  Tue Oct 13 20:14:38 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Tue, 13 Oct 2009 20:14:38 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD41BA7.5030004@fedoraproject.org> <4AD48A6C.6000007@redhat.com>
	<4AD4D495.4050103@fedoraproject.org>
Message-ID: 

Rahul Sundaram  fedoraproject.org> writes:

> The general attitude in this thread (not you) and elsewhere that it was
> ok to cause problems was worrying me. Thanks for looking into this problem.
> 
> Rahul

I am not sure that there is evidence for that!  I think that some people were
justifyably concerned that a package was released that had a major change to
settings and user experience, and caused some serious difficulties including
problems that gave large CPU and disk loads for a considerable and unjustifiable
periods - (me included) until the workarounds were known, but that once this
package was released and the knowledge and guidance on how to resolve the main
problems was known then reversing the release was not really an option.

However 3.0pre is around the corner (well you can download and run it
independently if you want to), and there will hopefully be later versions that
avoid the main problems that have arisen. By the way beta 4 did fix some bugs
related to TLS connections that I had, and that were certainly present in beta 2
- so there were some advantages in moving to the more recent beta.

It would also be a real help to users if the feedback from testing both prior to
pushing to updates-testing as well as in the updates-testing phase could lead to
some "user notes" attached to the final release that would guide users who bump
into these kinds of problems when doing what would be a normal yum update, and
expect things in a stable release to "just work"? (Question mark intended)

I know that we can do "rpm -q --changelog foo" or those of use who know what we
are doing can check the comments in bodhi but many users don't even know about
these.

 






From christoph.wickert at googlemail.com  Tue Oct 13 22:37:13 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 14 Oct 2009 00:37:13 +0200
Subject: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34
 sources, 1.12, 1.13
In-Reply-To: 
References: <20091013155113.2A9FA11C00E8@cvs1.fedora.phx.redhat.com>
	
	<1255454465.4148.400.camel@localhost.localdomain>
	<1255458916.2968.80.camel@wicktop.localdomain>
	
Message-ID: <1255473433.2968.129.camel@wicktop.localdomain>

Am Dienstag, den 13.10.2009, 14:42 -0500 schrieb Rex Dieter:
> Christoph Wickert wrote:
> 
> > Am Dienstag, den 13.10.2009, 10:21 -0700 schrieb Jesse Keating:
> >> On Tue, 2009-10-13 at 22:18 +0530, Parag N(????) wrote:
> >> >   I am confused here. Why this is removed? I still see xt.pc needs
> >> > those "Requires".
> >> 
> >> rpm now autogenerates the pkgconfig requirements,
> >> both /usr/bin/pkg-config and also the pkgconfig(foo) level requirements.
> > 
> > Changes like this really should be announced! And by "announced" I mean
> > a mail to fedora-devel-announce.
> 
> I see it first mentioned here anyway:
> https://www.redhat.com/archives/fedora-devel-announce/2008-
> July/msg00002.html

Indeed, I recall this announcement. But it only covers Provides, not
Requires.

> -- Rex

Regards,
Christoph



From promac at gmail.com  Wed Oct 14 00:21:29 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 13 Oct 2009 21:21:29 -0300
Subject: mingw32 suite
Message-ID: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>

Hi,

I am really pleased to see how fast the cross-compile project has evolved,
and
I was able to create a very simple script to cross-compile mpg123:

http://orion.lcg.ufrj.br/RPMS/SPECS/cross-mingw-mpg123

However, I am more interested in cross-compiling opengl applications.
Any plans to provide any opengl support for mingw32 in Fedora?

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sundaram at fedoraproject.org  Wed Oct 14 00:27:04 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 05:57:04 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com>	<4AD41BA7.5030004@fedoraproject.org>
	<4AD48A6C.6000007@redhat.com>	<4AD4D495.4050103@fedoraproject.org>
	
Message-ID: <4AD51AD8.4030906@fedoraproject.org>

On 10/14/2009 01:44 AM, Mike Cloaked wrote:
> Rahul Sundaram writes:
> 
>> The general attitude in this thread (not you) and elsewhere that it was
>> ok to cause problems was worrying me. Thanks for looking into this problem.
>>
>> Rahul
> 
> I am not sure that there is evidence for that!  

Evidence for what? The people who are complaining about this problem are
doing so because it is a real problem.

I think that some people were
> justifyably concerned that a package was released that had a major change to
> settings and user experience, and caused some serious difficulties including
> problems that gave large CPU and disk loads for a considerable and unjustifiable
> periods - (me included) until the workarounds were known, but that once this
> package was released and the knowledge and guidance on how to resolve the main
> problems was known then reversing the release was not really an option.

Why not? The maintainer says it is a option and it is definitely
feasible to release a update that disables these couple of features by
default rather than make everybody go through the same problems. I don't
understand your view point at all.  Changelog or even testing notes is
useful to guide testers into checking for problems but once the problems
are evident, we should just address them directly. Only a tiny fraction
of our users will read such notes and it is not reasonable to expect
them to continue to suffer.

Rahul



From panemade at gmail.com  Wed Oct 14 03:38:11 2009
From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=)
Date: Wed, 14 Oct 2009 09:08:11 +0530
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
	1.27 sources, 1.10, 1.11
In-Reply-To: <1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com> 
	 
	<1255454498.11711.2165.camel@atropine.boston.devel.redhat.com> 
	<20091013173228.GG9716@clingman.lan>
	<1255458052.11711.2171.camel@atropine.boston.devel.redhat.com>
Message-ID: 

Hi,

On Tue, Oct 13, 2009 at 11:50 PM, Adam Jackson  wrote:
> On Tue, 2009-10-13 at 10:32 -0700, Toshio Kuratomi wrote:
>> If all Fedora releases have the autoprovides but EL-5 is still
>> affected, the
>> draft can be as simple as: rpm detects pkgconfig dependencies in all
>> Fedora
>> releases, please move the pkgconfig requires from [LINK] to the EPEL
>> specific guidelines.
>
> Done:
>
> https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires
>
> AFAICT this became automagic in F-10, but I can't find any overt history
> of that in redhat-rpm-macros.
>

 Thanks all.

- Parag.



From itamar at ispbrasil.com.br  Wed Oct 14 06:15:30 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Oct 2009 03:15:30 -0300
Subject: mingw32 suite
In-Reply-To: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
Message-ID: 

stop using rar.

be free.



On Tue, Oct 13, 2009 at 9:21 PM, Paulo Cavalcanti  wrote:
> Hi,
>
> I am really pleased to see how fast the cross-compile project has evolved,
> and
> I was able to create a very simple script to cross-compile mpg123:
>
> http://orion.lcg.ufrj.br/RPMS/SPECS/cross-mingw-mpg123
>
> However, I am more interested in cross-compiling opengl applications.
> Any plans to provide any opengl support for mingw32 in Fedora?
>
> Thanks.
>
> --
> Paulo Roma Cavalcanti
> LCG - UFRJ
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From kevin.kofler at chello.at  Wed Oct 14 06:58:45 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 08:58:45 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
Message-ID: 

James Antill wrote:
>  Personally I'd suggest pushing to updates-testing but wait a _long_
> time (maybe even never) before pushing to stable.

"Never" is definitely the wrong answer: updates-testing is not for stuff 
which is too unstable to go stable, ever. Any update sitting in testing for 
more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff 
should get approximately 2 weeks of testing and regression fixing; at least 
those are the timings our experience in KDE SIG showed optimal) is either 
broken, in which case it should be unpushed (and the maintainer should be 
more careful next time), or not, in which case it should be promoted to 
stable.

We really need some stricter enforcement against stuff sitting in testing 
forever.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:03:00 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:03 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	<1255443376.11711.2143.camel@atropine.boston.devel.redhat.com>
Message-ID: 

Adam Jackson wrote:
> If we were more aggressive about backporting the kernel drm bits, and
> there was some slightly easier (preferably Makefile.common-driven) way
> of getting a package into the buildroot before being in -updates proper,
> we could probably do without lookaside repos.

Well, if you ping one of the rel-eng folks on IRC, you'll normally get stuff 
tagged with the buildroot override tags fairly quickly.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:10:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:10:56 +0200
Subject: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26,
	1.27 sources, 1.10, 1.11
References: <20091013155603.B693111C00E8@cvs1.fedora.phx.redhat.com>
	
Message-ID: 

Parag N(????) wrote:
>> -make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
>> +make install DESTDIR=$RPM_BUILD_ROOT
> 
>   I think its good to keep timestamps.

Me too. Of course, decent build systems like CMake preserve timestamps by 
default?

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:19:26 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:19:26 +0200
Subject: mingw32 suite
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
	
Message-ID: 

Itamar Reis Peixoto wrote:
> stop using rar.
> 
> be free.

Agreed. (By the way, it is also a violation of the EULA to use rar for more 
than 30 days without paying. I'm sure many people are using it illegally. 
But the biggest problem with the format is that there is no Free as in 
speech decompressor for it. The "freeware" unrar, while "free as in beer", 
has quite outrageous licensing restrictions. Just say "no" to proprietary 
software!)

But for a more constructive suggestion: use p7zip instead. It can also build 
self-extracting archives, you just need the self-extracting stub from the 
W32 distribution of 7-Zip. And it's all LGPL (except the unrar plugin, see 
above; the Fedora p7zip package doesn't ship that plugin for this reason).

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:21:41 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:21:41 +0200
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD19D5D.7000403@fedoraproject.org>
	<4AD1A266.4090902@pobox.com> <4AD1A56F.1040305@googlemail.com>
	<20091011100823.GA32620@adjoa.torimasen.com>
Message-ID: 

Dodji Seketeli wrote:
> My point is this is a matter of personal judgement. If the change is
> going to be "too" disruptive (and that's a maintainer call)
> then maybe having a "Fedora-blessed" repository like this great one
> http://rpms.famillecollet.com/fedora/11/remi/x86_64/repoview
> could be a possible way to go. At the same time, the package could be
> updated straight to Rawhide, of course.

Not upgrading was not an option here, the new beta was needed to fix 
security issues. (F11 already shipped with a 3.0 beta, the newer beta is the 
only upgrade path.)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:43:16 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:43:16 +0200
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD20DC1.9090102@cchtml.com> <4AD210DD.3040202@fedoraproject.org>
Message-ID: 

Rahul Sundaram wrote:
> If maintainers choose to include a beta release, then it would have been
> better to collect more feedback for a longer period of time for updates.

I already answered this in more detail on your blog, but:
1. It's a security update, so a short testing period is normal.
2. It reached +3 karma and got automatically queued for stable.

>  My mails to this list is my "negative karma".

But it's too late, the update already got pushed.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 14 07:46:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Oct 2009 09:46:44 +0200
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>
	
Message-ID: 

Mike Cloaked wrote:
> Please don't revert the package - now that I have configured TB to work
> well by switching off gloda and also switching off smart folders it
> actually does work well!  Maybe it could be an optional package revert?

He's just talking about defaulting those 2 settings to off, so if you 
already turned them off, the update won't affect you at all.

        Kevin Kofler



From rjones at redhat.com  Wed Oct 14 08:11:05 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 09:11:05 +0100
Subject: mingw32 suite
In-Reply-To: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
Message-ID: <20091014081105.GA22532@amd.home.annexia.org>

On Tue, Oct 13, 2009 at 09:21:29PM -0300, Paulo Cavalcanti wrote:
> However, I am more interested in cross-compiling opengl applications.
> Any plans to provide any opengl support for mingw32 in Fedora?

We already support it.

The OpenGL API is supported by the base OS (ie. Windows or Wine) as a
library called opengl32.dll, so doesn't need any extra explicit
support from the cross-compiler project.

However where you might get stuck is that we don't currently ship GLUT
or freeglut.  I'm quite certain at some point I packaged freeglut, but
I can't seem to find it right now.

You'll have to use another high level library (eg. SDL which we do
package) instead.  Or compile freeglut -- a bit tricky because the
build system doesn't understand cross-compilation.

There's also a specific mailing list for Fedora MinGW questions:

https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw

and if you want to package something up, I've written some notes here:

http://fedoraproject.org/wiki/MinGW/New_package

For anything else, see our SIG:

http://fedoraproject.org/wiki/SIGs/MinGW

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From sundaram at fedoraproject.org  Wed Oct 14 08:12:21 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 13:42:21 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD20DC1.9090102@cchtml.com>
	<4AD210DD.3040202@fedoraproject.org> 
Message-ID: <4AD587E5.1080701@fedoraproject.org>

On 10/14/2009 01:13 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> If maintainers choose to include a beta release, then it would have been
>> better to collect more feedback for a longer period of time for updates.
> 
> I already answered this in more detail on your blog, but:
> 1. It's a security update, so a short testing period is normal.

That really depends on the severity of the update vs the potential to
cause problems.  Remember the d-bus security update that caused so many
problems not so long ago? That one was a security update as well.

https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615

The update neither details what the security issues or nor does it tell
what other changes have been made. Not even a link to the upstream
release notes. So let's look at that

http://www.mozillamessaging.com/en-US/thunderbird/3.0b4/releasenotes/

Hmmm. Not much details on what the security issue being fixed is. The
only mention of security is about some SSL change

http://www.rumblingedge.com/2009/09/23/thunderbird-3-beta-4-released/

So I have no idea how severe the security problem was

> 2. It reached +3 karma and got automatically queued for stable.

Are you claiming that there is no way for maintainers to determine how
long the update stays in updates-testing repository? If not, I don't see
this point as relevant.

>>  My mails to this list is my "negative karma".
> 
> But it's too late, the update already got pushed.

It isn't too late to push another update that fixes the problem.

Rahul



From rjones at redhat.com  Wed Oct 14 08:56:23 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 09:56:23 +0100
Subject: mingw32 suite
In-Reply-To: <20091014081105.GA22532@amd.home.annexia.org>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
	<20091014081105.GA22532@amd.home.annexia.org>
Message-ID: <20091014085623.GA22693@amd.home.annexia.org>

On Wed, Oct 14, 2009 at 09:11:05AM +0100, Richard W.M. Jones wrote:
> However where you might get stuck is that we don't currently ship GLUT
> or freeglut.  I'm quite certain at some point I packaged freeglut, but
> I can't seem to find it right now.

I've packaged mingw32-freeglut for you:

  https://bugzilla.redhat.com/show_bug.cgi?id=528892

With this I was able to compile some examples from the OpenGL page
here:

  http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html

eg:

  i686-pc-mingw32-gcc cube.c -o cube -lglut -lglu32 -lopengl32
  wine ./cube

You may need to set up Wine paths by following the instructions here:

  https://fedoraproject.org/wiki/MinGW/Configure_wine

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From mschwendt at gmail.com  Wed Oct 14 09:21:42 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 14 Oct 2009 11:21:42 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	
Message-ID: <20091014112142.5d208c6e@faldor.intranet>

On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote:

> We really need some stricter enforcement against stuff sitting in testing 
> forever.

Rather we need some rules against such mindset.

We don't guarantee anything about updates-testing. It's a place where
to test potential updates/upgrades. And if a test-update is still without
sufficient karma points (either positive or negative) for several weeks,
it may stay in updates-testing for a longer time. IMO, that's a good
thing.



From mcepl at redhat.com  Wed Oct 14 08:57:09 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Wed, 14 Oct 2009 10:57:09 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>	<1255043946.18105.3.camel@localhost>	<1255060578.9958.11.camel@code.and.org>
	
Message-ID: 

Dne 14.10.2009 08:58, Kevin Kofler napsal(a):
> "Never" is definitely the wrong answer: updates-testing is not for stuff 
> which is too unstable to go stable, ever. Any update sitting in testing for 
> more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff 
> should get approximately 2 weeks of testing and regression fixing; at least 
> those are the timings our experience in KDE SIG showed optimal) is either 
> broken, in which case it should be unpushed (and the maintainer should be 
> more careful next time), or not, in which case it should be promoted to 
> stable.
> 
> We really need some stricter enforcement against stuff sitting in testing 
> forever.

This is actually your personal opinion AFAIK, right? I tend to disagree
with this -- one example which seems to me legitimate is when I create a
new package (I remember I came to this conclusion with both PSPP and
nimbus-theme) then I sometimes push it into Fedora-[n-1] just for
updates-testing, because I really don't have enough computers to do real
testing on older distros. By that, people who really want it, can take
it and they are implicitly warned that this is not meant to be stable
(generally speaking, I guess, people who follow updates-testing has to
survive some amount of breakage), but it is not thrown on unsuspecting
users of stable.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

The ratio of literacy to illiteracy is a constant, but nowadays
the illiterates can read.
    -- Alberto Moravia



From promac at gmail.com  Wed Oct 14 09:46:41 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 14 Oct 2009 06:46:41 -0300
Subject: mingw32 suite
In-Reply-To: <20091014085623.GA22693@amd.home.annexia.org>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
	<20091014081105.GA22532@amd.home.annexia.org>
	<20091014085623.GA22693@amd.home.annexia.org>
Message-ID: <68720af30910140246t1dc7d6ddm83155ebc5d27c327@mail.gmail.com>

On Wed, Oct 14, 2009 at 5:56 AM, Richard W.M. Jones wrote:

> On Wed, Oct 14, 2009 at 09:11:05AM +0100, Richard W.M. Jones wrote:
> > However where you might get stuck is that we don't currently ship GLUT
> > or freeglut.  I'm quite certain at some point I packaged freeglut, but
> > I can't seem to find it right now.
>
> I've packaged mingw32-freeglut for you:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=528892
>
> With this I was able to compile some examples from the OpenGL page
> here:
>
>
> http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html
>
> eg:
>
>  i686-pc-mingw32-gcc cube.c -o cube -lglut -lglu32 -lopengl32
>  wine ./cube
>
> You may need to set up Wine paths by following the instructions here:
>
>  https://fedoraproject.org/wiki/MinGW/Configure_wine
>
>
>

I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm
and compiled cube.c, but it does not run on wine:

[cascavel:~/cg/TutorsMin1.0] cube.exe
err:module:import_dll Library glut32.dll (which is needed by
L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe") not found
err:module:LdrInitializeThunk Main exe initialization for
L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe" failed, status c0000135

However, it runs just fine on VirtualBox.

In fact, I built some other examples too:

http://orion.lcg.ufrj.br/temp/TutorsMin1.0/

Do you want me to review your mingw32-freeglut package?

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rawhide at fedoraproject.org  Wed Oct 14 11:32:44 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 14 Oct 2009 11:32:44 +0000
Subject: rawhide report: 20091014 changes
Message-ID: <20091014113244.GA17384@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct 14 06:15:07 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From rjones at redhat.com  Wed Oct 14 11:43:45 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 12:43:45 +0100
Subject: mingw32 suite
In-Reply-To: <68720af30910140246t1dc7d6ddm83155ebc5d27c327@mail.gmail.com>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
	<20091014081105.GA22532@amd.home.annexia.org>
	<20091014085623.GA22693@amd.home.annexia.org>
	<68720af30910140246t1dc7d6ddm83155ebc5d27c327@mail.gmail.com>
Message-ID: <20091014114345.GA23699@amd.home.annexia.org>

On Wed, Oct 14, 2009 at 06:46:41AM -0300, Paulo Cavalcanti wrote:
> I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm
> and compiled cube.c, but it does not run on wine:
> 
> [cascavel:~/cg/TutorsMin1.0] cube.exe
> err:module:import_dll Library glut32.dll (which is needed by
> L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe") not found
> err:module:LdrInitializeThunk Main exe initialization for
> L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe" failed, status c0000135

Did you adjust the Wine paths as described in my posting?  Without
doing that Wine won't be able to find the glut library.

> Do you want me to review your mingw32-freeglut package?

Sure, if you don't mind.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From SteveD at redhat.com  Wed Oct 14 12:21:09 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Wed, 14 Oct 2009 08:21:09 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD486F9.5040300@redhat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
Message-ID: <4AD5C235.9030608@RedHat.com>

On 10/13/2009 09:56 AM, Christopher Aillon wrote:
> 
> Not everyone had issues with the indexing so that seemed to slip past
> testing.  It was a change, but didn't seem to disrupt things, so we let
> it slide.
Not to pile on, believe me I know painful change is... 8-) but... 

This new indexing is the biggest pain of all the changes IMHO...
My laptop CPU start to and continues to be pegged when I start up and
shut down TB3b... I could not read mail for 24hrs due to TPB3 trying
to indexing all my mail... Granted I have a ton of mail, in large number
of folders...  but my CPU became pegged, TPB3 start to eat all the memory,
causing everything to be swapped out, which caused the system to finally hang!! 
This was happen continuously. So I figured the only way to get by this was to 
delete mail... Which became a race between me deleting mail and TB3b try 
to index that folder...  I have a feeling that scenario was not tested 
too well... ;-) 

So for you to say indexing "didn't seem to disrupt things" is simply 
inaccurate... It was a major disruption and a complete waste of time... 

steved.



From jgarzik at pobox.com  Wed Oct 14 12:47:35 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 14 Oct 2009 08:47:35 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5C235.9030608@RedHat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>
Message-ID: <4AD5C867.4080802@pobox.com>

On 10/14/2009 08:21 AM, Steve Dickson wrote:
> On 10/13/2009 09:56 AM, Christopher Aillon wrote:
>>
>> Not everyone had issues with the indexing so that seemed to slip past
>> testing.  It was a change, but didn't seem to disrupt things, so we let
>> it slide.
> Not to pile on, believe me I know painful change is... 8-) but...
>
> This new indexing is the biggest pain of all the changes IMHO...
> My laptop CPU start to and continues to be pegged when I start up and
> shut down TB3b... I could not read mail for 24hrs due to TPB3 trying
> to indexing all my mail... Granted I have a ton of mail, in large number
> of folders...  but my CPU became pegged, TPB3 start to eat all the memory,
> causing everything to be swapped out, which caused the system to finally hang!!
> This was happen continuously. So I figured the only way to get by this was to
> delete mail... Which became a race between me deleting mail and TB3b try
> to index that folder...  I have a feeling that scenario was not tested
> too well... ;-)
>
> So for you to say indexing "didn't seem to disrupt things" is simply
> inaccurate... It was a major disruption and a complete waste of time...

Agreed.

Or put more simply, this "bug fix update" dropped an unexpected, 2+ 
gigabyte turd into my NFS-mounted home directory

> [jgarzik at bd ~]$ ls -l ~/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite
> -rw-r--r-- 1 jgarzik jgarzik 2731515904 2009-10-14 08:42 /g/g/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite

as well as slowing down all my NFS accesses for ~24 hours.

I hope a thunderbird update is being prepared, to make 2 config tweaks 
for F11?

And a warning / release note for F12 users, noting that a __lot__ of 
additional disk space is required in ~/.thunderbird.

	Jeff





From jhorak at redhat.com  Wed Oct 14 13:04:45 2009
From: jhorak at redhat.com (Jan Horak)
Date: Wed, 14 Oct 2009 15:04:45 +0200
Subject: Upload debug-like-info to Mozilla servers every update
In-Reply-To: 
References: <4AB3862F.4040207@redhat.com>
	
Message-ID: <4AD5CC6D.3070104@redhat.com>

On 09/18/2009 05:22 PM, Colin Walters wrote:
> We could do that, but a more ideal world would be where our ABRT
> system can give them as useful and reliable data as their usage of
> breakpad on Windows and OS X does.  There are multiple components
> here, the biggest of which is that we need to avoid requiring a
> Bugzilla account for crash submissions, and we need to make it about
> one click.   Once we have the data reliably, Mozilla could pull
> crashes from our system into theirs, say a cron job which just does:
> wget http://crashes.fedoraproject.org/package/mozilla/20091018.tar.gz
>    
Mozilla prefers using their own system in this case. It has some pros, 
like user don't have to download debug packages (which is approx 80MB 
for each package). Building the symbols for Mozilla is also quite easy. 
They have everything prepared in their makefiles and their debug info is 
just one zip file. All we need is to put this zip file somewhere that 
mozilla could pull it (or we push it after package is released). This 
zip file should be left aside from regular rpm package (read unpublished).
-- 
Jan Horak



From lemenkov at gmail.com  Wed Oct 14 13:04:56 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 14 Oct 2009 17:04:56 +0400
Subject: Are packages w/o necessary kernel modules allowed?
Message-ID: 

Hello All!

Imagine an application, which relies on a specific kernel module. This
module is not a part of stock Fedora kernel (at least, yet), and we
don't allow stand-alone kernel modules.

Whether or not this package can be allowed?

-- 
With best regards, Peter Lemenkov.



From felix at fetzig.org  Wed Oct 14 13:07:04 2009
From: felix at fetzig.org (Felix Kaechele)
Date: Wed, 14 Oct 2009 15:07:04 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
Message-ID: <4AD5CCF8.10105@fetzig.org>

-------- Original Message  --------
Subject: Are packages w/o necessary kernel modules allowed?
From: Peter Lemenkov 
To: Development discussions related to Fedora 
Date: 14.10.2009 15:04

> Hello All!
>
> Imagine an application, which relies on a specific kernel module. This
> module is not a part of stock Fedora kernel (at least, yet), and we
> don't allow stand-alone kernel modules.
>
> Whether or not this package can be allowed?

If not, what does dahdi-tools do in Fedora then?

Felix



From itamar at ispbrasil.com.br  Wed Oct 14 13:08:15 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Oct 2009 10:08:15 -0300
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
Message-ID: 

yes, I am already told this for you.

for example I have user-mode-linux user space but I don't have
user-mode-linux enabled in kernel.


On Wed, Oct 14, 2009 at 10:04 AM, Peter Lemenkov  wrote:
> Hello All!
>
> Imagine an application, which relies on a specific kernel module. This
> module is not a part of stock Fedora kernel (at least, yet), and we
> don't allow stand-alone kernel modules.
>
> Whether or not this package can be allowed?
>
> --
> With best regards, Peter Lemenkov.





-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From lemenkov at gmail.com  Wed Oct 14 13:10:22 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 14 Oct 2009 17:10:22 +0400
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
	
Message-ID: 

2009/10/14 Itamar Reis Peixoto :
> yes, I am already told this for you.
>
> for example I have user-mode-linux user space but I don't have
> user-mode-linux enabled in kernel.

I have strong opinion, that this is a bad practice. So I decided to ask others.

-- 
With best regards, Peter Lemenkov.



From sgallagh at redhat.com  Wed Oct 14 13:10:41 2009
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Wed, 14 Oct 2009 09:10:41 -0400
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
Message-ID: <4AD5CDD1.8000801@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/14/2009 09:04 AM, Peter Lemenkov wrote:
> Hello All!
> 
> Imagine an application, which relies on a specific kernel module. This
> module is not a part of stock Fedora kernel (at least, yet), and we
> don't allow stand-alone kernel modules.
> 
> Whether or not this package can be allowed?
> 


This is an interesting question. Suppose someone wrote (for example) an
GPLed configuration tool for a closed-source hardware driver. Would it
be permissible to include an open-source tool in the distribution, even
knowing it would only ever be usable with a tainted kernel?

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrVzcsACgkQeiVVYja6o6NwgwCdG10cCIr2pn+HhRWBXx+u4aB7
o8gAn0X1WOxe0Tu8Jo90V0O+cJhnTMPk
=VFnY
-----END PGP SIGNATURE-----



From lemenkov at gmail.com  Wed Oct 14 13:14:56 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 14 Oct 2009 17:14:56 +0400
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5CDD1.8000801@redhat.com>
References: 
	<4AD5CDD1.8000801@redhat.com>
Message-ID: 

2009/10/14 Stephen Gallagher :

> This is an interesting question. Suppose someone wrote (for example) an
> GPLed configuration tool for a closed-source hardware driver. Would it
> be permissible to include an open-source tool in the distribution, even
> knowing it would only ever be usable with a tainted kernel?

An example from a real life is a proprietary drivers, which sometimes
has only kernel-part closed, while has opensourced userspace.


-- 
With best regards, Peter Lemenkov.



From jeff at ocjtech.us  Wed Oct 14 13:20:55 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 14 Oct 2009 08:20:55 -0500
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5CCF8.10105@fetzig.org>
References: 
	<4AD5CCF8.10105@fetzig.org>
Message-ID: <935ead450910140620y12ad37fcn760f106ee730159a@mail.gmail.com>

On Wed, Oct 14, 2009 at 8:07 AM, Felix Kaechele  wrote:
> -------- Original Message ?--------
> Subject: Are packages w/o necessary kernel modules allowed?
> From: Peter Lemenkov 
> To: Development discussions related to Fedora 
> Date: 14.10.2009 15:04
>>
>> Imagine an application, which relies on a specific kernel module. This
>> module is not a part of stock Fedora kernel (at least, yet), and we
>> don't allow stand-alone kernel modules.
>
> If not, what does dahdi-tools do in Fedora then?

Nothing, at least not without a kernel module that's not in the stock
Fedora kernel.  The DAHDI kernel modules are GPL, but Digium has been
unwilling to merge them into the upstream kernel.

-- 
Jeff Ollie



From walters at verbum.org  Wed Oct 14 13:40:49 2009
From: walters at verbum.org (Colin Walters)
Date: Wed, 14 Oct 2009 09:40:49 -0400
Subject: Upload debug-like-info to Mozilla servers every update
In-Reply-To: <4AD5CC6D.3070104@redhat.com>
References: <4AB3862F.4040207@redhat.com>
	
	<4AD5CC6D.3070104@redhat.com>
Message-ID: 

On Wed, Oct 14, 2009 at 9:04 AM, Jan Horak  wrote:
>
>
> Mozilla prefers using their own system in this case. It has some pros, like
> user don't have to download debug packages (which is approx 80MB for each
> package). Building the symbols for Mozilla is also quite easy. They have
> everything prepared in their makefiles and their debug info is just one zip
> file. All we need is to put this zip file somewhere that mozilla could pull
> it (or we push it after package is released). This zip file should be left
> aside from regular rpm package (read unpublished).

In that case I'd just make the mozilla spec file to put the .zip in
the -debuginfo package.  Then their crash handling code just needs to
get the built RPM NVRA (it should probably be compiled in, but forking
a "rpm -q" could work I guess), and their server side can fairly
easily script a "wget
http://download.fedoraproject.org/.../mozilla-debuginfo-12345.rpm".



From mike.cloaked at gmail.com  Wed Oct 14 14:09:09 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Wed, 14 Oct 2009 14:09:09 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com>	<4AD41BA7.5030004@fedoraproject.org>
	<4AD48A6C.6000007@redhat.com>	<4AD4D495.4050103@fedoraproject.org>
	
	<4AD51AD8.4030906@fedoraproject.org>
Message-ID: 

Rahul Sundaram  fedoraproject.org> writes:

> > problems was known then reversing the release was not really an option.
> 
> Why not? The maintainer says it is a option and it is definitely
> feasible to release a update that disables these couple of features by
> default rather than make everybody go through the same problems. I don't
> understand your view point at all.  Changelog or even testing notes is
> useful to guide testers into checking for problems but once the problems
> are evident, we should just address them directly. Only a tiny fraction
> of our users will read such notes and it is not reasonable to expect
> them to continue to suffer.

Yes if it is an option to release a new package update that will have smart
folders and GLODA turned off then great - however I presume that the significant
majority of F11 users will already have updated and therefore already have been
hit by the change - so have either gone through the pain and reset their
parameters by now or dumped TB in favour of another mail client.  Therefore the
gain of a new update will (to me) seem not provide much in the way of help now
that the damage (of the beta4) has already been done.

I guess that 3.0pre is not far away, and perhaps in this next update the smart
folders and GLODA can be off by default.  I must admit that I would also like to
see the normal icons unchanged on the top taskbar in TB - I simply re-instated
what I want, but I would have preferred that the update did not take them away
in the first place.  Again I have made the changes necessary to get 3.0b4
working nicely (there are some residual bugs though - like occasionally the
compose window gets its formatting slightly awry and won't send and restarting
TB then fixes it)

Anyway hopefully this event will inform how the next update gets planned so that
it does not upset as many people next time?




From mike.cloaked at gmail.com  Wed Oct 14 14:15:22 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Wed, 14 Oct 2009 14:15:22 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
Message-ID: 

Jeff Garzik  pobox.com> writes:

> I hope a thunderbird update is being prepared, to make 2 config tweaks 
> for F11?
> 
> And a warning / release note for F12 users, noting that a __lot__ of 
> additional disk space is required in ~/.thunderbird.
> 
> 	Jeff

Hopefully the default will be GLODA=off and smart folders=off and then the
additional humungous file space requirements will not be needed and the user
presentation a lot more familiar as well as functional?

I must admit I cannot imagine why the thunderbird developers wanted the global
indexing thing in the first place - I, like many others, keep mail accounts
separate for a good reason - and I don't want a global search - it is insane -
and I also don't want to munge my inboxes together - I keep work and private
mail as well as other accounts separate so they there is no mixing and merging.

Hopefully f12 TB will arrive and function smoothly (hands clasped together, eyes
looking upward, channelling all the power of prayer......and hoping the
developers are listening!)



From sundaram at fedoraproject.org  Wed Oct 14 14:15:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 19:45:41 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>	<4AD41BA7.5030004@fedoraproject.org>	<4AD48A6C.6000007@redhat.com>	<4AD4D495.4050103@fedoraproject.org>		<4AD51AD8.4030906@fedoraproject.org>
	
Message-ID: <4AD5DD0D.20002@fedoraproject.org>

On 10/14/2009 07:39 PM, Mike Cloaked wrote:

> 
> Yes if it is an option to release a new package update that will have smart
> folders and GLODA turned off then great - however I presume that the significant
> majority of F11 users will already have updated and therefore already have been
> hit by the change - so have either gone through the pain and reset their
> parameters by now or dumped TB in favour of another mail client. 

Not sure there is any basis for that claim since we don't collect
detailed stats on how frequent Fedora users do update but a problem of
this nature is known, it is better to resolve it quickly rather than
assume that everybody has already learned to cope up with it. Anyway,
this debate is essentially over at this point since a update with the
defaults changed is being pushed out.

http://mether.wordpress.com/2009/10/14/thunderbird-problem-gets-fixed/

Rahul



From mmcgrath at redhat.com  Wed Oct 14 14:27:07 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 09:27:07 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
Message-ID: 

On Wed, 14 Oct 2009, Mike Cloaked wrote:

> Jeff Garzik  pobox.com> writes:
>
> > I hope a thunderbird update is being prepared, to make 2 config tweaks
> > for F11?
> >
> > And a warning / release note for F12 users, noting that a __lot__ of
> > additional disk space is required in ~/.thunderbird.
> >
> > 	Jeff
>
> Hopefully the default will be GLODA=off and smart folders=off and then the
> additional humungous file space requirements will not be needed and the user
> presentation a lot more familiar as well as functional?
>

The problem isn't GLODA and smart folders, it's that we have no process in
place to identify and deal with problems like this before it's too late.

	-Mike



From mike.cloaked at gmail.com  Wed Oct 14 14:26:22 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Wed, 14 Oct 2009 14:26:22 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>	<4AD41BA7.5030004@fedoraproject.org>	<4AD48A6C.6000007@redhat.com>	<4AD4D495.4050103@fedoraproject.org>		<4AD51AD8.4030906@fedoraproject.org>
	
	<4AD5DD0D.20002@fedoraproject.org>
Message-ID: 

Rahul Sundaram  fedoraproject.org> writes:

> Anyway,
> this debate is essentially over at this point since a update with the
> defaults changed is being pushed out.
> 
> http://mether.wordpress.com/2009/10/14/thunderbird-problem-gets-fixed/
> 
> Rahul
> 

OK - I hope this runs smoothly.... and hopefully we all learned from this event
(just like the d-bus event!)



From jkeating at redhat.com  Wed Oct 14 14:31:51 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 07:31:51 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
Message-ID: <1255530711.4148.413.camel@localhost.localdomain>

On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> 
> The problem isn't GLODA and smart folders, it's that we have no process in
> place to identify and deal with problems like this before it's too late. 

Aside from updates-testing you mean, where people can test potential
updates and give feedback as to how they work on their systems?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mmcgrath at redhat.com  Wed Oct 14 14:37:39 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 09:37:39 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255530711.4148.413.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
Message-ID: 

On Wed, 14 Oct 2009, Jesse Keating wrote:

> On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> >
> > The problem isn't GLODA and smart folders, it's that we have no process in
> > place to identify and deal with problems like this before it's too late.
>
> Aside from updates-testing you mean, where people can test potential
> updates and give feedback as to how they work on their systems?
>

Fat lot of good it's doing.

	-Mike



From nicolas.mailhot at laposte.net  Wed Oct 14 14:48:41 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Oct 2009 16:48:41 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
Message-ID: 



Le Mer 14 octobre 2009 16:15, Mike Cloaked a ?crit :

> I must admit I cannot imagine why the thunderbird developers wanted the global
> indexing thing in the first place

Because searching is so ? cool ? you don't need to think about indexing costs.
And because no self-respecting cool-factor hacker will trust the same amount
of personal data to the code he's willing to push on unsuspecting users (this
was already true when Eazel inflicted Medusa on the world, Thunderbird is only
a decade late to the game)

And we'll continue to get this as long as people mistake the forward-looking
nature of Fedora with a free-for-all that needn't concern itself with
robustness, stability or data safety

-- 
Nicolas Mailhot




From a.badger at gmail.com  Wed Oct 14 14:49:41 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 14 Oct 2009 07:49:41 -0700
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
Message-ID: <20091014144941.GA3382@clingman.lan>

On Wed, Oct 14, 2009 at 05:04:56PM +0400, Peter Lemenkov wrote:
> Hello All!
> 
> Imagine an application, which relies on a specific kernel module. This
> module is not a part of stock Fedora kernel (at least, yet), and we
> don't allow stand-alone kernel modules.
> 
> Whether or not this package can be allowed?
> 
ATM, if there's no build time requirement for the kernel module (headers,
etc), then the userspace is fine.

I tentatively lean towards this being a good thing.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From jkeating at j2solutions.net  Wed Oct 14 14:53:45 2009
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 14 Oct 2009 07:53:45 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
Message-ID: <1255532025.4148.414.camel@localhost.localdomain>

On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote:
> On Wed, 14 Oct 2009, Jesse Keating wrote:
> 
> > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> > >
> > > The problem isn't GLODA and smart folders, it's that we have no process in
> > > place to identify and deal with problems like this before it's too late.
> >
> > Aside from updates-testing you mean, where people can test potential
> > updates and give feedback as to how they work on their systems?
> >
> 
> Fat lot of good it's doing.
> 
> 	-Mike
> 

And that's a people problem more than a process problem.  If nobody
tests it in updates-testing, then how is the maintainer to know that it
is problematic?  Certainly not solvable with even more repos for testing
content...

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mmcgrath at redhat.com  Wed Oct 14 14:56:18 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 09:56:18 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255530711.4148.413.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
Message-ID: 

On Wed, 14 Oct 2009, Jesse Keating wrote:

> On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> >
> > The problem isn't GLODA and smart folders, it's that we have no process in
> > place to identify and deal with problems like this before it's too late.
>
> Aside from updates-testing you mean, where people can test potential
> updates and give feedback as to how they work on their systems?
>

To me it seems very clear that at least some significant portion of our
users want the new thunderbird.  But it should not have been pushed on to
everyone.  I can't imagine someone like steved who keeps all of their
email forever... but instead of knowing what happened like steved did,
now has no idea why their computer has just stopped working.  What do you
think their opinion of Fedora is right now?

Feodra 11 should not have shipped with a beta but the previous stable
version.  The beta should have been in it's on repo where it could have
been maintained and updated outside of the main tree.  Like an
experimental repo.  Not a repo to see if it works and 3 people can speak
for everyone and have it pushed.  But a repo on it's own where we all
acknowledge it's buggy but that's ok because it's not enabled by default.
Stability for all, a little blood for those that acknowledge they can
handle it.

	-Mike



From mmcgrath at redhat.com  Wed Oct 14 15:00:07 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 10:00:07 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255532025.4148.414.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
Message-ID: 

On Wed, 14 Oct 2009, Jesse Keating wrote:

> On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote:
> > On Wed, 14 Oct 2009, Jesse Keating wrote:
> >
> > > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> > > >
> > > > The problem isn't GLODA and smart folders, it's that we have no process in
> > > > place to identify and deal with problems like this before it's too late.
> > >
> > > Aside from updates-testing you mean, where people can test potential
> > > updates and give feedback as to how they work on their systems?
> > >
> >
> > Fat lot of good it's doing.
> >
> > 	-Mike
> >
>
> And that's a people problem more than a process problem.  If nobody
> tests it in updates-testing, then how is the maintainer to know that it
> is problematic?  Certainly not solvable with even more repos for testing
> content...
>

You let me know how three people in Fedora can miss a very subtle Firefox
memory leak.  How many people would need to use updates testing before the
thunderbird indexing problem is caught?  How long would it need to stay
there?  In this case updates-testing theory just does not match reality.

The status quo is broken, doing nothing will keep it that way.

	-Mike



From sundaram at fedoraproject.org  Wed Oct 14 15:01:27 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 20:31:27 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255532025.4148.414.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com>	<4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>	<4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	
	<1255532025.4148.414.camel@localhost.localdomain>
Message-ID: <4AD5E7C7.7080504@fedoraproject.org>

On 10/14/2009 08:23 PM, Jesse Keating wrote:

> And that's a people problem more than a process problem.  If nobody
> tests it in updates-testing, then how is the maintainer to know that it
> is problematic?  Certainly not solvable with even more repos for testing
> content...

3 people give positive feedback and the update is automatically pushed
from updates-testing to updates despite atleast one feedback to the
contrary at

https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615

The UI changes certainly would be visible without any user feedback. The
buttons getting removed from the toolbar as well as smart folders were
immediately visible within minutes. Anyone with significant amount of
email would probably run into the indexing issue soon as well.

Note that the update indicates it is a security issue but doesnt explain
what the security fix is nor does it indicate what other major changes
are there. No notes has been entered to assist the testers. I don't
think the onus can be placed entirely on potential testers to provide
feedback within a week. That is just finger pointing and doesn't help
address such problems or even mitigate it.

Rahul



From jkeating at redhat.com  Wed Oct 14 15:05:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 08:05:55 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
Message-ID: <1255532755.4148.418.camel@localhost.localdomain>

On Wed, 2009-10-14 at 10:00 -0500, Mike McGrath wrote:
> 
> You let me know how three people in Fedora can miss a very subtle Firefox
> memory leak.  How many people would need to use updates testing before the
> thunderbird indexing problem is caught?  How long would it need to stay
> there?  In this case updates-testing theory just does not match reality.
> 
> The status quo is broken, doing nothing will keep it that way.
> 

I'm not advocating "doing nothing".  I'm just not agreeing with your
suggested fix of throwing more repos at the problem.

The thunderbird issue is a unique one, where I don't think there /was/ a
previous stable release that was going to continue getting upstream
bugfixes.  Also, the new thunderbird was supposed to go out of beta at
or shortly after Fedora 11 was released.  In these scenarios the
maintainer's choices are A) go with what should be stable soon, B) go
with the unmaintained code and be responsible for all backports and
security fixes going forward.  Neither is a good choice, but that's what
upstream dumped on us.

I'll agree that in this case, a karma of 3 really wasn't sufficient to
push this out, and that's just a mistake on the person pushing the
update.  They should have opted out of the 3 karma autopush and waited
for more feedback from a larger set of users.  Just like not ever
package is the same, not every update is the same, and some have to be
treated with more care than others.  A people issue, not necessarily a
technical one.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From sundaram at fedoraproject.org  Wed Oct 14 15:04:37 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 20:34:37 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>	
	
Message-ID: <4AD5E885.1080706@fedoraproject.org>

On 10/14/2009 08:18 PM, Nicolas Mailhot wrote:
> 
> 
> Le Mer 14 octobre 2009 16:15, Mike Cloaked a ?crit :
> 
>> I must admit I cannot imagine why the thunderbird developers wanted the global
>> indexing thing in the first place
> 
> Because searching is so ? cool ? you don't need to think about indexing costs.

It would have been nice if desktop environments had settled on a single
search framework for other apps to hook into instead of everyone
reinventing the wheel. Then users can enable/disable it one place and be
done with it.

Rahul



From jgarzik at pobox.com  Wed Oct 14 15:10:19 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 14 Oct 2009 11:10:19 -0400
Subject: thunderbird rel-eng
In-Reply-To: <1255530711.4148.413.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
Message-ID: <4AD5E9DB.7030006@pobox.com>

On 10/14/2009 10:31 AM, Jesse Keating wrote:
> On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
>>
>> The problem isn't GLODA and smart folders, it's that we have no process in
>> place to identify and deal with problems like this before it's too late.
>
> Aside from updates-testing you mean, where people can test potential
> updates and give feedback as to how they work on their systems?

Do you honestly believe this was a testing problem?

Long after F11 release, we had an update billed as a "bug fix" that included

1) a major UI change.

2) additional home directory disk space requirement, several GIGABYTES 
in size.  A non-trivial, on-going CPU usage requirement, as well.

3) global indexing which lumps together, in a single file, distinctly 
separate email accounts.  This potentially creates a LEGAL PROBLEM for 
end users.

These changes in the middle of a stable Fedora release are outside the 
bounds of normal, expected bug fixes.  That is simply not up to Fedora 
standards by any stretch of the imagination.

The above are major problems that should be caught by a release 
engineering process... the maintainer if nobody else.

	Jeff





From rc040203 at freenet.de  Wed Oct 14 15:29:13 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 14 Oct 2009 17:29:13 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
Message-ID: <4AD5EE49.60608@freenet.de>

On 10/14/2009 03:04 PM, Peter Lemenkov wrote:
> Hello All!
>
> Imagine an application, which relies on a specific kernel module. This
> module is not a part of stock Fedora kernel (at least, yet), and we
> don't allow stand-alone kernel modules.
>
> Whether or not this package can be allowed?
>
IMO: no.

Packages in Fedora should "just work" and therefore must not rely on 
anything which is not in Fedora.

Ralf



From jgarzik at pobox.com  Wed Oct 14 15:31:57 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 14 Oct 2009 11:31:57 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD486F9.5040300@redhat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>
Message-ID: <4AD5EEED.2020400@pobox.com>

On 10/13/2009 09:56 AM, Christopher Aillon wrote:
> Not everyone had issues with the indexing so that seemed to slip past
> testing. It was a change, but didn't seem to disrupt things, so we let
> it slide.
>
> We are looking at reverting both in F11.


Global indexing introduces legal issues, disk space requirements and CPU 
requirements that extend beyond F11...

	Jeff





From mike at cchtml.com  Wed Oct 14 15:35:33 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Wed, 14 Oct 2009 10:35:33 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5EEED.2020400@pobox.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5EEED.2020400@pobox.com>
Message-ID: <4AD5EFC5.4070705@cchtml.com>

Jeff Garzik wrote:
> 
> Global indexing introduces legal issues, disk space requirements and CPU
> requirements that extend beyond F11...
> 


Maybe I'm a bit stupid, but what is the significance of how many files
your emails are stored in? Separating them out provides some sort of
security advantage?



From promac at gmail.com  Wed Oct 14 15:39:42 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 14 Oct 2009 12:39:42 -0300
Subject: mingw32 suite
In-Reply-To: <20091014114345.GA23699@amd.home.annexia.org>
References: <68720af30910131721h571c2643pb14c38745342e5b1@mail.gmail.com>
	<20091014081105.GA22532@amd.home.annexia.org>
	<20091014085623.GA22693@amd.home.annexia.org>
	<68720af30910140246t1dc7d6ddm83155ebc5d27c327@mail.gmail.com>
	<20091014114345.GA23699@amd.home.annexia.org>
Message-ID: <68720af30910140839h1834cbge1f175303bcee7e@mail.gmail.com>

On Wed, Oct 14, 2009 at 8:43 AM, Richard W.M. Jones wrote:

> On Wed, Oct 14, 2009 at 06:46:41AM -0300, Paulo Cavalcanti wrote:
> > I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm
> > and compiled cube.c, but it does not run on wine:
> >
> > [cascavel:~/cg/TutorsMin1.0] cube.exe
> > err:module:import_dll Library glut32.dll (which is needed by
> > L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe") not found
> > err:module:LdrInitializeThunk Main exe initialization for
> > L"F:\\roma\\cg\\TutorsMin1.0\\cube.exe" failed, status c0000135
>
> Did you adjust the Wine paths as described in my posting?  Without
> doing that Wine won't be able to find the glut library.
>

Yes:

"PATH"=str(2):"c:\\windows\\system;c:\\windows;Z:\\usr\\i686-pc-mingw32\\sys-root\\mingw\\bin"

The problem is that I do no have a glut32.dll on my system.

I only have a

/usr/i686-pc-mingw32/sys-root/mingw/bin/libglut-0.dll

in mingw\bin

The programs run fine on VirtualBox, but I always get this message:

$ fog.exe
OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your
SPU

I need to investigate the cause.



>
> > Do you want me to review your mingw32-freeglut package?
>
> Sure, if you don't mind.
>
>
>

I'll do it.

I tested glut on F10, and it worked very well.

However, F11 seems not to be finding glut32, but I need to test it better.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fedora at alexhudson.com  Wed Oct 14 15:45:03 2009
From: fedora at alexhudson.com (Alex Hudson)
Date: Wed, 14 Oct 2009 16:45:03 +0100
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <1255530711.4148.413.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com>	<4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>	<4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>		
	<1255530711.4148.413.camel@localhost.localdomain>
Message-ID: <4AD5F1FF.8090404@alexhudson.com>

On 14/10/09 15:31, Jesse Keating wrote:
> On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
>
>> The problem isn't GLODA and smart folders, it's that we have no process in
>> place to identify and deal with problems like this before it's too late.
>>
> Aside from updates-testing you mean, where people can test potential
> updates and give feedback as to how they work on their systems?
>

For me, there is a bit of a problem with updates-testing: the machine I 
work on is my primary desktop, and I'm extremely wary of getting myself 
into a situation I can't easily get out of. Now, you might argue that 
avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has 
shown me that, so I agree), but it is riskier.

What would sell me totally on u-t was if there was something where I can 
roll back bad packages.

I'm pretty sure there are various obscure technical reasons why rolling 
back isn't possible in 100% of cases, but I don't think that's 
necessary. So long as it's in the high 90%s then it's good enough, and 
to be honest I would want to avoid testing updates I can't revert like 
the plague anyway: not being able to roll back to my mind is a good 
indicator of not being suitable for a stable release.

In my ideal world, PackageKit would update my stuff with testing 
updates, and anything which broke could be reverted back to some 
previous date or something - either by package if I can identify it, or 
by actual last-known-good date. I'm sure that's a tonne of work, but 
that's the only way I can see the testing system making sense for people 
who rely on their Fedora desktop.

Cheers

Alex.



From skvidal at fedoraproject.org  Wed Oct 14 15:47:49 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 11:47:49 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <4AD5F1FF.8090404@alexhudson.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
Message-ID: 



On Wed, 14 Oct 2009, Alex Hudson wrote:

> On 14/10/09 15:31, Jesse Keating wrote:
>> On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
>> 
>>> The problem isn't GLODA and smart folders, it's that we have no process in
>>> place to identify and deal with problems like this before it's too late.
>>> 
>> Aside from updates-testing you mean, where people can test potential
>> updates and give feedback as to how they work on their systems?
>> 
>
> For me, there is a bit of a problem with updates-testing: the machine I work 
> on is my primary desktop, and I'm extremely wary of getting myself into a 
> situation I can't easily get out of. Now, you might argue that avoiding u-t 
> is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I 
> agree), but it is riskier.
>
> What would sell me totally on u-t was if there was something where I can roll 
> back bad packages.
>
> I'm pretty sure there are various obscure technical reasons why rolling back 
> isn't possible in 100% of cases, but I don't think that's necessary. So long 
> as it's in the high 90%s then it's good enough, and to be honest I would want 
> to avoid testing updates I can't revert like the plague anyway: not being 
> able to roll back to my mind is a good indicator of not being suitable for a 
> stable release.
>
> In my ideal world, PackageKit would update my stuff with testing updates, and 
> anything which broke could be reverted back to some previous date or 
> something - either by package if I can identify it, or by actual 
> last-known-good date. I'm sure that's a tonne of work, but that's the only 
> way I can see the testing system making sense for people who rely on their 
> Fedora desktop.

yum downgrade pkgname

it works fine for the simple-ish cases.

-sv



From jkeating at redhat.com  Wed Oct 14 15:48:23 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 08:48:23 -0700
Subject: thunderbird rel-eng
In-Reply-To: <4AD5E9DB.7030006@pobox.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5E9DB.7030006@pobox.com>
Message-ID: <1255535303.4148.420.camel@localhost.localdomain>

On Wed, 2009-10-14 at 11:10 -0400, Jeff Garzik wrote:
> On 10/14/2009 10:31 AM, Jesse Keating wrote:
> > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> >>
> >> The problem isn't GLODA and smart folders, it's that we have no process in
> >> place to identify and deal with problems like this before it's too late.
> >
> > Aside from updates-testing you mean, where people can test potential
> > updates and give feedback as to how they work on their systems?
> 
> Do you honestly believe this was a testing problem?
> 
> Long after F11 release, we had an update billed as a "bug fix" that included
> 
> 1) a major UI change.
> 
> 2) additional home directory disk space requirement, several GIGABYTES 
> in size.  A non-trivial, on-going CPU usage requirement, as well.
> 
> 3) global indexing which lumps together, in a single file, distinctly 
> separate email accounts.  This potentially creates a LEGAL PROBLEM for 
> end users.
> 
> These changes in the middle of a stable Fedora release are outside the 
> bounds of normal, expected bug fixes.  That is simply not up to Fedora 
> standards by any stretch of the imagination.
> 
> The above are major problems that should be caught by a release 
> engineering process... the maintainer if nobody else.
> 
> 	Jeff
> 
> 
> 

updates-testing /is/ the release engineering process.  There is simply
too many packages for the one of me to manage.  That none of the testers
thought anything was wrong with this update is the "testing problem".
That the maintainer stuck it with a 3 karma limit is another problem.
That the maintainer thought it was OK to majorly change UI in the middle
of a release is a third problem.  There is no one entity at fault here,
and there is no magic bullet to fix it.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mmcgrath at redhat.com  Wed Oct 14 15:49:05 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 10:49:05 -0500 (CDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <4AD5F1FF.8090404@alexhudson.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
Message-ID: 

On Wed, 14 Oct 2009, Alex Hudson wrote:

> On 14/10/09 15:31, Jesse Keating wrote:
> > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> >
> > > The problem isn't GLODA and smart folders, it's that we have no process in
> > > place to identify and deal with problems like this before it's too late.
> > >
> > Aside from updates-testing you mean, where people can test potential
> > updates and give feedback as to how they work on their systems?
> >
>
> For me, there is a bit of a problem with updates-testing: the machine I work
> on is my primary desktop, and I'm extremely wary of getting myself into a
> situation I can't easily get out of. Now, you might argue that avoiding u-t is
> essentially avoiding the inevitable (and Tbird 3 has shown me that, so I
> agree), but it is riskier.
>
> What would sell me totally on u-t was if there was something where I can roll
> back bad packages.
>

I've suggested this very thing in a F-A-B thread this week.  We,
packagers, have no way to fix a mistake and very few things preventing us
from making them:

https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html

	-Mike



From jkeating at redhat.com  Wed Oct 14 15:50:25 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 08:50:25 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5EEED.2020400@pobox.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5EEED.2020400@pobox.com>
Message-ID: <1255535425.4148.422.camel@localhost.localdomain>

On Wed, 2009-10-14 at 11:31 -0400, Jeff Garzik wrote:
> On 10/13/2009 09:56 AM, Christopher Aillon wrote:
> > Not everyone had issues with the indexing so that seemed to slip past
> > testing. It was a change, but didn't seem to disrupt things, so we let
> > it slide.
> >
> > We are looking at reverting both in F11.
> 
> 
> Global indexing introduces legal issues, disk space requirements and CPU 
> requirements that extend beyond F11...
> 
> 	Jeff
> 
> 
> 

Those are defaults that a user can change.  Granted, existing setups
shouldn't be automatically moved to the new default, but new installs of
a new release should default to the upstream default.  If the user
doesn't find those settings acceptable, they can change them.  The trick
is to not surprise existing users with massive change.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jgarzik at pobox.com  Wed Oct 14 15:52:16 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 14 Oct 2009 11:52:16 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5EFC5.4070705@cchtml.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5EEED.2020400@pobox.com> <4AD5EFC5.4070705@cchtml.com>
Message-ID: <4AD5F3B0.8050306@pobox.com>

On 10/14/2009 11:35 AM, Michael Cronenworth wrote:
> Jeff Garzik wrote:
>>
>> Global indexing introduces legal issues, disk space requirements and CPU
>> requirements that extend beyond F11...
>>
>
>
> Maybe I'm a bit stupid, but what is the significance of how many files
> your emails are stored in? Separating them out provides some sort of
> security advantage?


Legally speaking, it is important, if I am ever called into court, to be 
able to show a distinct separation between my personal email and my 
NDA-heavy Red Hat email.  And, bboth of which must be separate from my 
micro-micro-corporation.

If one does not demonstrate intent at creating "walls" separating legal 
entities, it becomes a whole lot easier for a GarzikMicroCorp-related 
lawsuit to subpoena my personal and Red Hat email.

Separation of data is basic legal CYA.

	Jeff





From skvidal at fedoraproject.org  Wed Oct 14 15:54:45 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 11:54:45 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
Message-ID: 



On Wed, 14 Oct 2009, Mike McGrath wrote:

>
> I've suggested this very thing in a F-A-B thread this week.  We,
> packagers, have no way to fix a mistake and very few things preventing us
> from making them:
>
> https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html


Seriously:

yum downgrade

and in F12 - try out things like the history undo options.

there are lots of potential nasty situations that can happen but I think 
the general consensus was 'screw it, let the user sort it out if it 
breaks, which it often does not'

generally, if the app you updated modifies its data format and cannot 
revert it then the user is SOL - but that's not _THAT_ common and when it 
does happen it's certainly not yum's fault.

-sv



From mike at cchtml.com  Wed Oct 14 16:03:31 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Wed, 14 Oct 2009 11:03:31 -0500
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5F3B0.8050306@pobox.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>	<4AD5EEED.2020400@pobox.com>
	<4AD5EFC5.4070705@cchtml.com> <4AD5F3B0.8050306@pobox.com>
Message-ID: <4AD5F653.3070009@cchtml.com>

Jeff Garzik wrote:
> 
> 
> Legally speaking, it is important, if I am ever called into court, to be
> able to show a distinct separation between my personal email and my
> NDA-heavy Red Hat email.  And, bboth of which must be separate from my
> micro-micro-corporation.
> 
> If one does not demonstrate intent at creating "walls" separating legal
> entities, it becomes a whole lot easier for a GarzikMicroCorp-related
> lawsuit to subpoena my personal and Red Hat email.
> 
> Separation of data is basic legal CYA.
> 


I fully understand the separation of email accounts, but what I'm
getting at is the storage of your binary data on the hard disk. If you
keep any personal email on your hard disk, and the whole disk is
subpoenaed, your personal+RH email will be on it. The only safe way to
prevent that is to not use TB at all. It keeps caches of everything
whether you like it or not. In fact, it might be a cool feature to add
to TB - a "corporate mode" so to speak - that prevents any and all local
storage of email data.



From giallu at gmail.com  Wed Oct 14 16:07:26 2009
From: giallu at gmail.com (Gianluca Sforna)
Date: Wed, 14 Oct 2009 18:07:26 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5EE49.60608@freenet.de>
References: 
	<4AD5EE49.60608@freenet.de>
Message-ID: 

On Wed, Oct 14, 2009 at 5:29 PM, Ralf Corsepius  wrote:
> On 10/14/2009 03:04 PM, Peter Lemenkov wrote:
>> Imagine an application, which relies on a specific kernel module. This
>> module is not a part of stock Fedora kernel (at least, yet), and we
>> don't allow stand-alone kernel modules.
>>
>> Whether or not this package can be allowed?
>>
> IMO: no.
>
> Packages in Fedora should "just work" and therefore must not rely on
> anything which is not in Fedora.

Which is precisely the reason why sysprof was moved to rpmfusion when
kmods were banned from Fedora


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From jgarzik at pobox.com  Wed Oct 14 16:14:47 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 14 Oct 2009 12:14:47 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5F653.3070009@cchtml.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5EEED.2020400@pobox.com> <4AD5EFC5.4070705@cchtml.com>
	<4AD5F3B0.8050306@pobox.com> <4AD5F653.3070009@cchtml.com>
Message-ID: <4AD5F8F7.2030404@pobox.com>

On 10/14/2009 12:03 PM, Michael Cronenworth wrote:
> I fully understand the separation of email accounts, but what I'm
> getting at is the storage of your binary data on the hard disk. If you
> keep any personal email on your hard disk, and the whole disk is
> subpoenaed, your personal+RH email will be on it. The only safe way to
> prevent that is to not use TB at all. It keeps caches of everything
> whether you like it or not. In fact, it might be a cool feature to add
> to TB - a "corporate mode" so to speak - that prevents any and all local
> storage of email data.

That is why my cache points to a tmpfs location...  goes away after each 
reboot.

	Jeff




From rjones at redhat.com  Wed Oct 14 16:16:54 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 17:16:54 +0100
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
Message-ID: <20091014161654.GA26008@amd.home.annexia.org>

On Wed, Oct 14, 2009 at 10:00:07AM -0500, Mike McGrath wrote:
> You let me know how three people in Fedora can miss a very subtle Firefox
> memory leak.  How many people would need to use updates testing before the
> thunderbird indexing problem is caught?  How long would it need to stay
> there?  In this case updates-testing theory just does not match reality.

Maybe 1 in 10 Fedora installs at random should have updates-testing
enabled by default?

(Joke, joke ...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From fedora at alexhudson.com  Wed Oct 14 16:22:39 2009
From: fedora at alexhudson.com (Alex Hudson)
Date: Wed, 14 Oct 2009 17:22:39 +0100
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	<4AD5F1FF.8090404@alexhudson.com>
	
Message-ID: <4AD5FACF.1050901@alexhudson.com>

On 14/10/09 16:49, Mike McGrath wrote:
> I've suggested this very thing in a F-A-B thread this week.  We,
> packagers, have no way to fix a mistake and very few things preventing us
> from making them:
>
> https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html
>

I love this!

I would say having "an" experimental repo wouldn't be as good as having 
per-app repos: for me, there are apps I care about and want to test, and 
others I use infrequently and couldn't contribute much to. However, if 
on the other hand there was some way of marking out which packages I 
wanted to pull from experimental (or updates-testing for that matter), 
then well and good.

I think experimental is needed, though. Some apps really need longer 
baking before getting into Fedora proper: Tbird 3 for me is an excellent 
example, although probably for the maintainer one which is much more 
obvious in hindsight.

The change in mission makes a huge amount of sense (being usable, if not 
bug-free, has to be a top priority in my mind).

For my money, a great proposal though, thanks.

Alex.



From fedora at alexhudson.com  Wed Oct 14 16:22:47 2009
From: fedora at alexhudson.com (Alex Hudson)
Date: Wed, 14 Oct 2009 17:22:47 +0100
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	<4AD5F1FF.8090404@alexhudson.com>
	
Message-ID: <4AD5FAD7.8050500@alexhudson.com>

On 14/10/09 16:47, Seth Vidal wrote:
> yum downgrade pkgname
>
> it works fine for the simple-ish cases.

If that works, then gravy. I can't admit to having tried it in the past 
- although, I'm not really a yum user, I use packagekit, and indeed pk 
whines at me to turn off the legacy software when I run yum ;) Ideally, 
for me, this would be something pk can trigger (and maybe give me a way 
of contributing to the testing karma at the same time - that would rock).

Personally, though, I would think that if that is a feature we're 
advertising then it should be policy that either a. package maintainers 
strive to ensure their packages are mainly downgradable (certainly 
within a stable release) or b. the packages are marked as "don't 
downgrade me" and yum/whatever issues the appropriate expletive when you 
try to do that.

I would say again that any package update which cannot be downgraded 
would be one I would think hard about releasing into a stable Fedora.

Cheers

Alex.



From skvidal at fedoraproject.org  Wed Oct 14 16:26:33 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 12:26:33 -0400 (EDT)
Subject: Updates-testing
In-Reply-To: <4AD5FAD7.8050500@alexhudson.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<4AD5FAD7.8050500@alexhudson.com>
Message-ID: 



On Wed, 14 Oct 2009, Alex Hudson wrote:

> On 14/10/09 16:47, Seth Vidal wrote:
>> yum downgrade pkgname
>> 
>> it works fine for the simple-ish cases.
>
> If that works, then gravy. I can't admit to having tried it in the past - 
> although, I'm not really a yum user, I use packagekit, and indeed pk whines 
> at me to turn off the legacy software when I run yum ;)

That's pretty amusing considering PK cannot do much of anything 
on fedora w/o yum. It can't even fetch repodata.


> Ideally, for me, this  would be something pk can trigger (and maybe give me a way of contributing to 
> the testing karma at the same time - that would rock).

Then file an RFE with the PK folks.


-sv



From rjones at redhat.com  Wed Oct 14 16:30:39 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 17:30:39 +0100
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5EE49.60608@freenet.de>
References: 
	<4AD5EE49.60608@freenet.de>
Message-ID: <20091014163039.GB26008@amd.home.annexia.org>

On Wed, Oct 14, 2009 at 05:29:13PM +0200, Ralf Corsepius wrote:
> On 10/14/2009 03:04 PM, Peter Lemenkov wrote:
>> Hello All!
>>
>> Imagine an application, which relies on a specific kernel module. This
>> module is not a part of stock Fedora kernel (at least, yet), and we
>> don't allow stand-alone kernel modules.
>>
>> Whether or not this package can be allowed?
>>
> IMO: no.
>
> Packages in Fedora should "just work" and therefore must not rely on  
> anything which is not in Fedora.

Well I don't think this should be a hard and fast rule.

If it was something like Firefox that needed a proprietary kernel
extension, then yes that would be really bad.  But a small, obscure
package used to configure a specialized piece of hardware, and that
comes with adequate documentation, why not let it in?

  # config-foo
  Error: This requires a non-free kernel module 'foo.ko' which
  can't be shipped in Fedora.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From mmcgrath at redhat.com  Wed Oct 14 16:30:57 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 11:30:57 -0500 (CDT)
Subject: Updates-testing
In-Reply-To: <4AD5FAD7.8050500@alexhudson.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<4AD5FAD7.8050500@alexhudson.com>
Message-ID: 

On Wed, 14 Oct 2009, Alex Hudson wrote:

> On 14/10/09 16:47, Seth Vidal wrote:
> > yum downgrade pkgname
> >
> > it works fine for the simple-ish cases.
>
> If that works, then gravy. I can't admit to having tried it in the past -
> although, I'm not really a yum user, I use packagekit, and indeed pk whines at
> me to turn off the legacy software when I run yum ;) Ideally, for me, this
> would be something pk can trigger (and maybe give me a way of contributing to
> the testing karma at the same time - that would rock).
>

Even with downgrade, that's a user action.  If the user happens to know
about it they'll be ok.  I'm more interested in what options a packager
has to fix problems like this.

	-Mike



From felix at fetzig.org  Wed Oct 14 16:31:03 2009
From: felix at fetzig.org (Felix Kaechele)
Date: Wed, 14 Oct 2009 18:31:03 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5EE49.60608@freenet.de>
References: 
	<4AD5EE49.60608@freenet.de>
Message-ID: <4AD5FCC7.409@fetzig.org>

-------- Original Message  --------
Subject: Re: Are packages w/o necessary kernel modules allowed?
From: Ralf Corsepius 
To: Development discussions related to Fedora 
Date: 14.10.2009 17:29

> IMO: no.
>
> Packages in Fedora should "just work" and therefore must not rely on
> anything which is not in Fedora.

 From the opposite POV:
Why should we make peoples' lives harder getting the tools they need? 
Example: Somebody without the DAHDI Kernel Modules would probably not 
try to use the DAHDI Tools since he probably won't even know what it's 
good for. However It makes things easier for the people who do know what 
DAHDI is to have tools to use their DAHDI hardware (they compiled/got 
the Kernel modules for) just a yum install away.

Felix



From skvidal at fedoraproject.org  Wed Oct 14 16:32:51 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 12:32:51 -0400 (EDT)
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<4AD5FAD7.8050500@alexhudson.com>
	
Message-ID: 



On Wed, 14 Oct 2009, Mike McGrath wrote:

> On Wed, 14 Oct 2009, Alex Hudson wrote:
>
>> On 14/10/09 16:47, Seth Vidal wrote:
>>> yum downgrade pkgname
>>>
>>> it works fine for the simple-ish cases.
>>
>> If that works, then gravy. I can't admit to having tried it in the past -
>> although, I'm not really a yum user, I use packagekit, and indeed pk whines at
>> me to turn off the legacy software when I run yum ;) Ideally, for me, this
>> would be something pk can trigger (and maybe give me a way of contributing to
>> the testing karma at the same time - that would rock).
>>
>
> Even with downgrade, that's a user action.  If the user happens to know
> about it they'll be ok.  I'm more interested in what options a packager
> has to fix problems like this.
>

The packager can issue a new pkg which is the old pkg with a bumped epoch.

then the user will get that in the next update.

this is one of the reasons why epochs exist, ultimately.

-sv



From sundaram at fedoraproject.org  Wed Oct 14 16:35:50 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 14 Oct 2009 22:05:50 +0530
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	<4AD5F1FF.8090404@alexhudson.com>		<4AD5FAD7.8050500@alexhudson.com>
	
Message-ID: <4AD5FDE6.4040000@fedoraproject.org>

On 10/14/2009 09:56 PM, Seth Vidal wrote:
> 
> 
> On Wed, 14 Oct 2009, Alex Hudson wrote:
> 
>> On 14/10/09 16:47, Seth Vidal wrote:
>>> yum downgrade pkgname
>>>
>>> it works fine for the simple-ish cases.
>>
>> If that works, then gravy. I can't admit to having tried it in the
>> past - although, I'm not really a yum user, I use packagekit, and
>> indeed pk whines at me to turn off the legacy software when I run yum ;)
> 
> That's pretty amusing considering PK cannot do much of anything on
> fedora w/o yum. It can't even fetch repodata.

IIRC the wording has been fixed to not classify yum as "legacy" in
recent PackageKit versions.

Rahul



From craftjml at gmail.com  Wed Oct 14 16:53:28 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 14 Oct 2009 12:53:28 -0400
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD486F9.5040300@redhat.com> 
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com> 
	
	 
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com> 
	
	
Message-ID: <20d6441a0910140953h5a345453mb6ed358d95806634@mail.gmail.com>

What about using LVM to store a pre-update snapshot of your distro?

(Separate root partition from /home and other stuff, of course.  Roll
back root).

Highly inconvenient, but it would theoretically work...

On Wed, Oct 14, 2009 at 11:54 AM, Seth Vidal  wrote:
>
>
> On Wed, 14 Oct 2009, Mike McGrath wrote:
>
>>
>> I've suggested this very thing in a F-A-B thread this week. ?We,
>> packagers, have no way to fix a mistake and very few things preventing us
>> from making them:
>>
>>
>> https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html
>
>
> Seriously:
>
> yum downgrade
>
> and in F12 - try out things like the history undo options.
>
> there are lots of potential nasty situations that can happen but I think the
> general consensus was 'screw it, let the user sort it out if it breaks,
> which it often does not'
>
> generally, if the app you updated modifies its data format and cannot revert
> it then the user is SOL - but that's not _THAT_ common and when it does
> happen it's certainly not yum's fault.
>
> -sv
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From skvidal at fedoraproject.org  Wed Oct 14 16:57:14 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 12:57:14 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20d6441a0910140953h5a345453mb6ed358d95806634@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	 
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	
	<20d6441a0910140953h5a345453mb6ed358d95806634@mail.gmail.com>
Message-ID: 



On Wed, 14 Oct 2009, Jud Craft wrote:

> What about using LVM to store a pre-update snapshot of your distro?
>
> (Separate root partition from /home and other stuff, of course.  Roll
> back root).
>
> Highly inconvenient, but it would theoretically work...
>

It doesn't really help you when your data is modified by the update.
example:

installed: foo-1.0
data format: user:group:data:index:key
update: foo-1.2
data is migrated forward from the old format to the new one, new format is
stored in the same file but is:
user:group,group,group,group:data:data:data:index

(obviously I'm just making up the data format :)


how do you roll back and not lose access to the data in that file?

-sv




From rc040203 at freenet.de  Wed Oct 14 16:57:16 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 14 Oct 2009 18:57:16 +0200
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	<4AD5F1FF.8090404@alexhudson.com>
	
Message-ID: <4AD602EC.8070705@freenet.de>

On 10/14/2009 05:47 PM, Seth Vidal wrote:

> yum downgrade pkgname
>
> it works fine for the simple-ish cases.
Is there a thunderbird-2.0 package for F11?

For me, all thunderbird-3.*'s in FC11 were simply too bugged to be 
usable (The UI changes are not an issue for me - for me, TB3 is simply 
too bugged to be usable).

I already considered to add FC10's or CentOS's TB to a local repository 
and to look into ways to blacklist TB3 in yum.

Ralf



From rc040203 at freenet.de  Wed Oct 14 16:59:28 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 14 Oct 2009 18:59:28 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091014163039.GB26008@amd.home.annexia.org>
References: 	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
Message-ID: <4AD60370.3040302@freenet.de>

On 10/14/2009 06:30 PM, Richard W.M. Jones wrote:
> On Wed, Oct 14, 2009 at 05:29:13PM +0200, Ralf Corsepius wrote:
>> On 10/14/2009 03:04 PM, Peter Lemenkov wrote:
>>> Hello All!
>>>
>>> Imagine an application, which relies on a specific kernel module. This
>>> module is not a part of stock Fedora kernel (at least, yet), and we
>>> don't allow stand-alone kernel modules.
>>>
>>> Whether or not this package can be allowed?
>>>
>> IMO: no.
>>
>> Packages in Fedora should "just work" and therefore must not rely on
>> anything which is not in Fedora.
>
> Well I don't think this should be a hard and fast rule.
Then our opions diverge: I think it should be a hard show stopper criterion.

There should not be any room for any "cripple ware" in Fedora nor should 
Fedora be a stage for "closed source loaders".

Ralf



From skvidal at fedoraproject.org  Wed Oct 14 17:00:21 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 13:00:21 -0400 (EDT)
Subject: Updates-testing
In-Reply-To: <4AD602EC.8070705@freenet.de>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<4AD602EC.8070705@freenet.de>
Message-ID: 



On Wed, 14 Oct 2009, Ralf Corsepius wrote:

> On 10/14/2009 05:47 PM, Seth Vidal wrote:
>
>> yum downgrade pkgname
>> 
>> it works fine for the simple-ish cases.
> Is there a thunderbird-2.0 package for F11?
>
> For me, all thunderbird-3.*'s in FC11 were simply too bugged to be usable 
> (The UI changes are not an issue for me - for me, TB3 is simply too bugged to 
> be usable).
>
> I already considered to add FC10's or CentOS's TB to a local repository and 
> to look into ways to blacklist TB3 in yum.

easy to blacklist it in yum

add:
exclude=thunderbird\*

to fedora, updates and updates-testing repos.

that should keep it out.

might be some deps there too - I haven't  looked closely.
-sv



From skvidal at fedoraproject.org  Wed Oct 14 17:01:40 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 13:01:40 -0400 (EDT)
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD60370.3040302@freenet.de>
References: 
	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
	<4AD60370.3040302@freenet.de>
Message-ID: 



On Wed, 14 Oct 2009, Ralf Corsepius wrote:

> On 10/14/2009 06:30 PM, Richard W.M. Jones wrote:
>> On Wed, Oct 14, 2009 at 05:29:13PM +0200, Ralf Corsepius wrote:
>>> On 10/14/2009 03:04 PM, Peter Lemenkov wrote:
>>>> Hello All!
>>>> 
>>>> Imagine an application, which relies on a specific kernel module. This
>>>> module is not a part of stock Fedora kernel (at least, yet), and we
>>>> don't allow stand-alone kernel modules.
>>>> 
>>>> Whether or not this package can be allowed?
>>>> 
>>> IMO: no.
>>> 
>>> Packages in Fedora should "just work" and therefore must not rely on
>>> anything which is not in Fedora.
>> 
>> Well I don't think this should be a hard and fast rule.
> Then our opions diverge: I think it should be a hard show stopper criterion.
>
> There should not be any room for any "cripple ware" in Fedora nor should 
> Fedora be a stage for "closed source loaders".

I think I agree.


This is just like shipping a package with an intentionally missing 
dependency. We wouldn't allow shipping yum if rpm were missing, 
right?

this sounds the same to me.

-sv



From jkeating at redhat.com  Wed Oct 14 17:06:36 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 10:06:36 -0700
Subject: Updates-testing
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<4AD5FAD7.8050500@alexhudson.com>
	
Message-ID: <1255539996.4148.424.camel@localhost.localdomain>

On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote:
> On Wed, 14 Oct 2009, Alex Hudson wrote:
> 
> > On 14/10/09 16:47, Seth Vidal wrote:
> > > yum downgrade pkgname
> > >
> > > it works fine for the simple-ish cases.
> >
> > If that works, then gravy. I can't admit to having tried it in the past -
> > although, I'm not really a yum user, I use packagekit, and indeed pk whines at
> > me to turn off the legacy software when I run yum ;) Ideally, for me, this
> > would be something pk can trigger (and maybe give me a way of contributing to
> > the testing karma at the same time - that would rock).
> >
> 
> Even with downgrade, that's a user action.  If the user happens to know
> about it they'll be ok.  I'm more interested in what options a packager
> has to fix problems like this.
> 
> 	-Mike
> 

In this specific case, issue a bumped build of thunderbird with the UI
settings defaulted to what they were before the change.  New code, old
UI.  In the general case this could also be done, or a package could be
reverted to older code, but with an epoch to ensure package ordering.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jkeating at redhat.com  Wed Oct 14 17:08:10 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Oct 2009 10:08:10 -0700
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
Message-ID: <1255540090.4148.425.camel@localhost.localdomain>

On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote:
> have no way to fix a mistake

That is complete bullshit.  You have many ways to fix mistakes.  Newer
builds with patches, reverted code with epoch, newer upstream release to
fix the mistake upstream, etc..  To say that there is no way to fix a
mistake is insulting.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mike.cloaked at gmail.com  Wed Oct 14 17:08:28 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Wed, 14 Oct 2009 17:08:28 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
Message-ID: 

Mike McGrath  redhat.com> writes:

> > And that's a people problem more than a process problem.  If nobody
> > tests it in updates-testing, then how is the maintainer to know that it
> > is problematic?  Certainly not solvable with even more repos for testing
> > content...
> >
> 
> You let me know how three people in Fedora can miss a very subtle Firefox
> memory leak.  How many people would need to use updates testing before the
> thunderbird indexing problem is caught?  How long would it need to stay
> there?  In this case updates-testing theory just does not match reality.
> 
> The status quo is broken, doing nothing will keep it that way.
> 
> 	-Mike
> 

Actually I don't think the blame is directly layable at the feet of either the
Fedora maintainer (who pushed an update with reasonable reports in bodhi
according to normal practice), nor the Fedora process which should have worked
if no poor upstream changes were made - but in fact this shows up the
vulnerability of Fedora to packages which have bad decisions made upstream.

In this case the upstream developers made a really bad decision to foist the
GLODA change and the smart folder change on users who installed this beta,
instead of taking the safer, and in my view better, decision to bring in these
new features, but to leave them switched off by default, but to advertise the
availability of these new features big time, and then let this simmer for a
while and wait for any bad user feedback.  Only if the new features were then
shown to be acceptable should they be enabled in a future update by default. In
this case, going that route would have shown that the new features were
certainly not acceptable to all users, and in particular users with large
amounts of stored mail with multiple accounts.





From skvidal at fedoraproject.org  Wed Oct 14 17:11:08 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 13:11:08 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <1255540090.4148.425.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<1255540090.4148.425.camel@localhost.localdomain>
Message-ID: 



On Wed, 14 Oct 2009, Jesse Keating wrote:

> On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote:
>> have no way to fix a mistake
>
> That is complete bullshit.  You have many ways to fix mistakes.  Newer
> builds with patches, reverted code with epoch, newer upstream release to
> fix the mistake upstream, etc..  To say that there is no way to fix a
> mistake is insulting.
>

okay. I think everyone needs to calm down here.


this is me speaking with a hall-monitors hat on.

I don't believe there is any call for offense from this thread.

so a deep breath and no email sending for a bit, for everyone.

-sv





From craftjml at gmail.com  Wed Oct 14 17:11:44 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 14 Oct 2009 13:11:44 -0400
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <1255540090.4148.425.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com> <4AD486F9.5040300@redhat.com> 
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com> 
	
	 
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com> 
	
	<1255540090.4148.425.camel@localhost.localdomain>
Message-ID: <20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>

On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote:
> Newer builds with patches, reverted code with epoch, newer upstream release to
> fix the mistake upstream, etc.. ?To say that there is no way to fix a
> mistake is insulting.

I'd like to logic-link here with the following...


On Wed, Oct 14, 2009 at 12:57 PM, Seth Vidal wrote:
> It doesn't really help you when your data is modified by the update.


So if my "LVM snapshot and revert entire Fedora installed" idea is
dismissed as "still not perfect", why is "just revert one package"
pushed as a legitimate alternative?

They both suffer from the same problem -- new packages may cause
changes in data that are not reversibly compatible with the old
package, and mere package rollback is not useful.



From craftjml at gmail.com  Wed Oct 14 17:13:26 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 14 Oct 2009 13:13:26 -0400
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD5C235.9030608@RedHat.com> 
	<4AD5C867.4080802@pobox.com>  
	
	<1255530711.4148.413.camel@localhost.localdomain> 
	<4AD5F1FF.8090404@alexhudson.com>
	 
	<1255540090.4148.425.camel@localhost.localdomain>
	<20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
Message-ID: <20d6441a0910141013q66c91007t5cace17258f1c7d5@mail.gmail.com>

On Wed, Oct 14, 2009 at 1:11 PM, Jud Craft wrote:
> They both suffer from the same problem -- new packages may cause
> changes in data that are not reversibly compatible with the old
> package, and mere package rollback is not useful.
>

Of course, I imagine that any rollback system that doesn't involve
user data will have the same problem, theoretically.

That includes any backup system that treats system programs separate
from user data, when in fact one DOES change the other.



From skvidal at fedoraproject.org  Wed Oct 14 17:13:59 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 13:13:59 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	 
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<1255540090.4148.425.camel@localhost.localdomain>
	<20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
Message-ID: 



On Wed, 14 Oct 2009, Jud Craft wrote:

> On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote:
>> Newer builds with patches, reverted code with epoch, newer upstream release to
>> fix the mistake upstream, etc.. ?To say that there is no way to fix a
>> mistake is insulting.
>
> I'd like to logic-link here with the following...
>
>
> On Wed, Oct 14, 2009 at 12:57 PM, Seth Vidal wrote:
>> It doesn't really help you when your data is modified by the update.
>
>
> So if my "LVM snapshot and revert entire Fedora installed" idea is
> dismissed as "still not perfect", why is "just revert one package"
> pushed as a legitimate alternative?
>
> They both suffer from the same problem -- new packages may cause
> changes in data that are not reversibly compatible with the old
> package, and mere package rollback is not useful.


Sorry, I didn't say your idea was dismissed. Just more complicated b/c of 
all the space the user has to allocate to it.

There's no perfect.

we're just going for 'good enough', really.

-sv

From caillon at redhat.com  Wed Oct 14 17:18:47 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Oct 2009 10:18:47 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5C235.9030608@RedHat.com>
References: <4AD15A0F.9080708@pobox.com>	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>	<4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
Message-ID: <4AD607F7.4010308@redhat.com>

On 10/14/2009 05:21 AM, Steve Dickson wrote:
> On 10/13/2009 09:56 AM, Christopher Aillon wrote:
>>
>> Not everyone had issues with the indexing so that seemed to slip past
>> testing.  It was a change, but didn't seem to disrupt things, so we let
>> it slide.
> Not to pile on, believe me I know painful change is... 8-) but...


> So for you to say indexing "didn't seem to disrupt things" is simply
> inaccurate... It was a major disruption and a complete waste of time...

I hold by what I said.  "Not everyone had issues."  Specifically, the 
people that were testing didn't have issues.  Thus, "it didn't seem to 
disrupt things".  I realize that you and others have issues/disruptions. 
  That is why we're looking at addressing it now that the problems are 
known.  I can't predict the future, I can only react to things I know about.



From craftjml at gmail.com  Wed Oct 14 17:19:10 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 14 Oct 2009 13:19:10 -0400
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD5C867.4080802@pobox.com> 
	
	 
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com> 
	
	<1255540090.4148.425.camel@localhost.localdomain> 
	<20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com> 
	
Message-ID: <20d6441a0910141019q5e573998i36a87417671c1fb1@mail.gmail.com>

On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote:
> There's no perfect.
>
> we're just going for 'good enough', really.

Ah, so package-rollback is shipped as the "halfway-effective crutch,
but it's so easy to implement we might as well offer it anyway"
solution.

Or, the excellent implementation of an incomplete solution.  [No
offense to the infrastructure design of yum, just stating the obvious
here.]

On the side, I store all of my user data and documents separate from
my own actual home partition, and with every install I just wipe the
home, and then re-link my documents and data to it.

This scheme works decently (application-specific schemas and configs
that are subject to irreversible change are discarded and recreated).
But it's a pain to compensate for an inconvenient reality (that I must
continually reinstall my distribution as a Fedora user, and I'm tired
of having to migrate user data, where even residual /home directories
leave rot).



From opensource at till.name  Wed Oct 14 17:19:58 2009
From: opensource at till.name (Till Maas)
Date: Wed, 14 Oct 2009 19:19:58 +0200
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5FCC7.409@fetzig.org>
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
Message-ID: <20091014171958.GB8823@genius.kawo2.rwth-aachen.de>

On Wed, Oct 14, 2009 at 06:31:03PM +0200, Felix Kaechele wrote:

> From the opposite POV:
> Why should we make peoples' lives harder getting the tools they need?  
> Example: Somebody without the DAHDI Kernel Modules would probably not  
> try to use the DAHDI Tools since he probably won't even know what it's  
> good for. However It makes things easier for the people who do know what  
> DAHDI is to have tools to use their DAHDI hardware (they compiled/got  
> the Kernel modules for) just a yum install away.

IMHO having both in RPMFusion with a proper dependency is the easiest
way to install it. Having some package with a missing kernel module
dependency in Fedora would only make it more complicated for other
repositories that provide the kernel module and can therefore provide a
package with a unbroken dependency.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From bruno at wolff.to  Wed Oct 14 17:25:00 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 14 Oct 2009 12:25:00 -0500
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD5FCC7.409@fetzig.org>
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
Message-ID: <20091014172500.GB16313@wolff.to>

On Wed, Oct 14, 2009 at 18:31:03 +0200,
> Why should we make peoples' lives harder getting the tools they
> need? Example: Somebody without the DAHDI Kernel Modules would
> probably not try to use the DAHDI Tools since he probably won't even
> know what it's good for. However It makes things easier for the
> people who do know what DAHDI is to have tools to use their DAHDI
> hardware (they compiled/got the Kernel modules for) just a yum
> install away.

Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time
without having a version for a specific version Fedora. For example there
is no rawhide version now and there was a long period without one for
F11. There are issues trying to rebuild atrpms src rpms on fedora. Just
grabbing atrms-rpm-config doesn't help with recursion issues that Alex
doesn't see because of his custom environment.

What I had to do for F12 is grab a spec file (that get's updates at the source)
that was proposed for rpmfusion (but never got adopted by them) and then use
an svn version of dahdi that has a fix for a change in the way the kernel
is being built (some compatibility feature that got dropped in 2.6.32).
That box has been extra unstable lately, though I don't know if that is do
to 3D graphics or dahdi-linux.



From skvidal at fedoraproject.org  Wed Oct 14 17:47:58 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 13:47:58 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20d6441a0910141019q5e573998i36a87417671c1fb1@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com> 
	
	<1255540090.4148.425.camel@localhost.localdomain>
	<20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
	
	<20d6441a0910141019q5e573998i36a87417671c1fb1@mail.gmail.com>
Message-ID: 



On Wed, 14 Oct 2009, Jud Craft wrote:

> On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote:
>> There's no perfect.
>>
>> we're just going for 'good enough', really.
>
> Ah, so package-rollback is shipped as the "halfway-effective crutch,
> but it's so easy to implement we might as well offer it anyway"
> solution.

actually it is shipped as an easy win for simple 
update-is-broken-and-downgrading-is-painless cases which we run into all 
the time.

Your suggestion of having an lvm snapshot is absolutely appropriate for 
those too - it just requires more thinking ahead of time when the system 
is being setup which a lot of users are not going to do.


> Or, the excellent implementation of an incomplete solution.  [No
> offense to the infrastructure design of yum, just stating the obvious
> here.]
>

There's no complete solution, really. We'd have to know an enormous amount 
about each update and what data it modifies to completely solve the 
problem and we just don't have that info and I doubt we could reasonably 
compile it for EVERY package we maintain.

So we implement a reasonable partial solution and deal with the edge cases 
as they come.

  > On the side, I store all of my user data and documents separate from
> my own actual home partition, and with every install I just wipe the
> home, and then re-link my documents and data to it.

good choice. That's good planning.


-sv



From nicolas.mailhot at laposte.net  Wed Oct 14 17:51:38 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Oct 2009 19:51:38 +0200
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	<4AD5F1FF.8090404@alexhudson.com>
	
	<1255540090.4148.425.camel@localhost.localdomain>
	<20d6441a0910141011u51a1b59cyb5698d3e30f700c9@mail.gmail.com>
Message-ID: 



Le Mer 14 octobre 2009 19:11, Jud Craft a ?crit :

> So if my "LVM snapshot and revert entire Fedora installed" idea is
> dismissed as "still not perfect", why is "just revert one package"
> pushed as a legitimate alternative?

Revert one package won't eat the data created while you used the new problem
version. That's the problem with full-FS images: they do not distinguish
between the different kinds of files.

-- 
Nicolas Mailhot




From kevin at scrye.com  Wed Oct 14 17:55:52 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 14 Oct 2009 11:55:52 -0600
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: 
References: 
	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
	<4AD60370.3040302@freenet.de>
	
Message-ID: <20091014115552.12bdcb83@ohm.scrye.com>

On Wed, 14 Oct 2009 13:01:40 -0400 (EDT)
Seth Vidal  wrote:
> 
> On Wed, 14 Oct 2009, Ralf Corsepius wrote:
> 
> > Then our opions diverge: I think it should be a hard show stopper
> > criterion.
> >
> > There should not be any room for any "cripple ware" in Fedora nor
> > should Fedora be a stage for "closed source loaders".
> 
> I think I agree.
> 
> 
> This is just like shipping a package with an intentionally missing 
> dependency. We wouldn't allow shipping yum if rpm were missing, 
> right?
> 
> this sounds the same to me.

So, how about some other cases instead of just kmods: 

- Client apps that are free and acceptable for fedora, but a server app
  that is not. 

EXAMPLE: mpd (in rpmfusion) and all the various mpd clients that are
all in fedora. 

- Library app thats free, but only non free things link against it so
  far. 

EXAMPLE: libvdpau

- Package that is free an interfaces with a non free server's data: 

EXAMPLE: dbxml-perl

- Package that is free, but the kernel part of it's currently not
  working (although planned to be back and great work is being done on
  it): 

EXAMPLE: xen 

- Package that is free and acceptable for fedora, but requires a non
  free service to function: 

EXAMPLE: perl-Net-Amazon-EC2 

Where does the black and white line come in here? 
Or is it shades of grey?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

From caillon at redhat.com  Wed Oct 14 18:05:20 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Oct 2009 11:05:20 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>
	
Message-ID: <4AD612E0.7020801@redhat.com>

On 10/14/2009 07:56 AM, Mike McGrath wrote:
> Feodra 11 should not have shipped with a beta but the previous stable
> version.

That's really easy for you to say, considering you don't use 
Thunderbird, and you have no information about the decision making process.

The information I used to make the decision was:

* The upstream release date was going to be within a week of
   F11's release date, from a normally reliable source
* 3.0 had many desirable improvements to performance
* 2.0 would be EOL'd by upstream soon
* Thunderbird users tend to be in the "want upgrade now" camp
* Changing from 2.0 -> 3.0 after F11 was released is not something I
   wanted to do
* Tb3 beta would affect a smaller portion of Fedora users anyway since
   Thunderbird is _not_ the default mail client.
* Given initial testing by my team, and tracking upstream feedback, it
   worked well enough and there were no major regressions over 2.0.


Given the situation and circumstances, with the information I had 
available, I would make the same decision again.



From skvidal at fedoraproject.org  Wed Oct 14 18:06:26 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 14:06:26 -0400 (EDT)
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091014115552.12bdcb83@ohm.scrye.com>
References: 
	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
	<4AD60370.3040302@freenet.de>
	
	<20091014115552.12bdcb83@ohm.scrye.com>
Message-ID: 



On Wed, 14 Oct 2009, Kevin Fenzi wrote:

> On Wed, 14 Oct 2009 13:01:40 -0400 (EDT)
> Seth Vidal  wrote:
>>
>> On Wed, 14 Oct 2009, Ralf Corsepius wrote:
>>
>>> Then our opions diverge: I think it should be a hard show stopper
>>> criterion.
>>>
>>> There should not be any room for any "cripple ware" in Fedora nor
>>> should Fedora be a stage for "closed source loaders".
>>
>> I think I agree.
>>
>>
>> This is just like shipping a package with an intentionally missing
>> dependency. We wouldn't allow shipping yum if rpm were missing,
>> right?
>>
>> this sounds the same to me.
>
> So, how about some other cases instead of just kmods:
>
> - Client apps that are free and acceptable for fedora, but a server app
>  that is not.
>
> EXAMPLE: mpd (in rpmfusion) and all the various mpd clients that are
> all in fedora.
>
> - Library app thats free, but only non free things link against it so
>  far.
>
> EXAMPLE: libvdpau
>
> - Package that is free an interfaces with a non free server's data:
>
> EXAMPLE: dbxml-perl
>
> - Package that is free, but the kernel part of it's currently not
>  working (although planned to be back and great work is being done on
>  it):
>
> EXAMPLE: xen
>
> - Package that is free and acceptable for fedora, but requires a non
>  free service to function:
>
> EXAMPLE: perl-Net-Amazon-EC2
>
> Where does the black and white line come in here?
> Or is it shades of grey?
>

We've allowed pretty much all of the cases where you could communicate 
over the network to something else.

but we're not talking about over-the-network communication here.


-sv



From mmcgrath at redhat.com  Wed Oct 14 18:09:42 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 13:09:42 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD612E0.7020801@redhat.com>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<4AD612E0.7020801@redhat.com>
Message-ID: 

On Wed, 14 Oct 2009, Christopher Aillon wrote:

> On 10/14/2009 07:56 AM, Mike McGrath wrote:
> > Feodra 11 should not have shipped with a beta but the previous stable
> > version.
>
> That's really easy for you to say, considering you don't use Thunderbird, and
> you have no information about the decision making process.
>
> The information I used to make the decision was:
>
> * The upstream release date was going to be within a week of
>   F11's release date, from a normally reliable source
> * 3.0 had many desirable improvements to performance
> * 2.0 would be EOL'd by upstream soon
> * Thunderbird users tend to be in the "want upgrade now" camp
> * Changing from 2.0 -> 3.0 after F11 was released is not something I
>   wanted to do
> * Tb3 beta would affect a smaller portion of Fedora users anyway since
>   Thunderbird is _not_ the default mail client.
> * Given initial testing by my team, and tracking upstream feedback, it
>   worked well enough and there were no major regressions over 2.0.
>
>
> Given the situation and circumstances, with the information I had available, I
> would make the same decision again.
>

I would have made the same decision as you, that doesn't mean it wasn't a
mistake.  We have no policies or procedures in place to guide you, me or
anyone else otherwise.  As such, we run into these issues, cause pain for
the users, etc, etc.

	-Mike



From mmcgrath at redhat.com  Wed Oct 14 18:26:33 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 14 Oct 2009 13:26:33 -0500 (CDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<4AD612E0.7020801@redhat.com>
	
Message-ID: 

On Wed, 14 Oct 2009, Mike McGrath wrote:

> On Wed, 14 Oct 2009, Christopher Aillon wrote:
>
> > On 10/14/2009 07:56 AM, Mike McGrath wrote:
> > > Feodra 11 should not have shipped with a beta but the previous stable
> > > version.
> >
> > That's really easy for you to say, considering you don't use Thunderbird, and
> > you have no information about the decision making process.
> >
> > The information I used to make the decision was:
> >
> > * The upstream release date was going to be within a week of
> >   F11's release date, from a normally reliable source
> > * 3.0 had many desirable improvements to performance
> > * 2.0 would be EOL'd by upstream soon
> > * Thunderbird users tend to be in the "want upgrade now" camp
> > * Changing from 2.0 -> 3.0 after F11 was released is not something I
> >   wanted to do
> > * Tb3 beta would affect a smaller portion of Fedora users anyway since
> >   Thunderbird is _not_ the default mail client.
> > * Given initial testing by my team, and tracking upstream feedback, it
> >   worked well enough and there were no major regressions over 2.0.
> >
> >
> > Given the situation and circumstances, with the information I had available, I
> > would make the same decision again.
> >
>
> I would have made the same decision as you, that doesn't mean it wasn't a
> mistake.  We have no policies or procedures in place to guide you, me or
> anyone else otherwise.  As such, we run into these issues, cause pain for
> the users, etc, etc.
>

Just an additional note to this, Mozilla themselves are still directing
people to download Thunderbird 2.

http://www.mozillamessaging.com/en-US/thunderbird/

	-Mike



From caillon at redhat.com  Wed Oct 14 18:37:05 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Oct 2009 11:37:05 -0700
Subject: Updates-testing
In-Reply-To: <1255539996.4148.424.camel@localhost.localdomain>
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>	<4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com>	<4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com>	<4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com>	<4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>	<4AD5F1FF.8090404@alexhudson.com>		<4AD5FAD7.8050500@alexhudson.com>	
	<1255539996.4148.424.camel@localhost.localdomain>
Message-ID: <4AD61A51.5000309@redhat.com>

On 10/14/2009 10:06 AM, Jesse Keating wrote:
> On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote:
>> On Wed, 14 Oct 2009, Alex Hudson wrote:
>>
>>> On 14/10/09 16:47, Seth Vidal wrote:
>>>> yum downgrade pkgname
>>>>
>>>> it works fine for the simple-ish cases.
>>>
>>> If that works, then gravy. I can't admit to having tried it in the past -
>>> although, I'm not really a yum user, I use packagekit, and indeed pk whines at
>>> me to turn off the legacy software when I run yum ;) Ideally, for me, this
>>> would be something pk can trigger (and maybe give me a way of contributing to
>>> the testing karma at the same time - that would rock).
>>>
>>
>> Even with downgrade, that's a user action.  If the user happens to know
>> about it they'll be ok.  I'm more interested in what options a packager
>> has to fix problems like this.
>>
>> 	-Mike
>>
>
> In this specific case, issue a bumped build of thunderbird with the UI
> settings defaulted to what they were before the change.  New code, old
> UI.

Right.  The defaults have been tweaked in 
https://admin.fedoraproject.org/updates/thunderbird-3.0-2.8.b4.fc11



From chasd at silveroaks.com  Wed Oct 14 18:55:13 2009
From: chasd at silveroaks.com (chasd)
Date: Wed, 14 Oct 2009 13:55:13 -0500
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20091014160006.167D98E013E@hormel.redhat.com>
References: <20091014160006.167D98E013E@hormel.redhat.com>
Message-ID: <644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>


Seth Vidal wrote:

> Seriously:
>
> yum downgrade
>
> and in F12 - try out things like the history undo options.
>
> there are lots of potential nasty situations that can happen but I  
> think the general consensus was 'screw it, let the user sort it out  
> if it breaks, which it often does not'
>
> generally, if the app you updated modifies its data format and  
> cannot revert it then the user is SOL - but that's not _THAT_  
> common and when it does happen it's certainly not yum's fault.

If it isn't that common, could yum have added directives to its  
configuration ( similar to " exclude= " ) ?
This could increase the reliability of " yum downgrade " in the eyes  
of those that use it.

MySQL and PostgreSQL come to mind.
/etc/yum.conf might have " nodowngrade=mysql-server postgresql-server  
" in the default file.
That's easier than carrying that info in the package or repo files.
When additional packages are found to be not downgradable, they can  
be added to the list.
Granted, if there are a lot of packages, that gets unwieldy.
Also, it could break a downgrade transaction.


-- 
Charles Dostale



From skvidal at fedoraproject.org  Wed Oct 14 18:56:10 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 14:56:10 -0400 (EDT)
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>
References: <20091014160006.167D98E013E@hormel.redhat.com>
	<644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>
Message-ID: 



On Wed, 14 Oct 2009, chasd wrote:

>
> Seth Vidal wrote:
>
>> Seriously:
>> 
>> yum downgrade
>> 
>> and in F12 - try out things like the history undo options.
>> 
>> there are lots of potential nasty situations that can happen but I think 
>> the general consensus was 'screw it, let the user sort it out if it breaks, 
>> which it often does not'
>> 
>> generally, if the app you updated modifies its data format and cannot 
>> revert it then the user is SOL - but that's not _THAT_ common and when it 
>> does happen it's certainly not yum's fault.
>
> If it isn't that common, could yum have added directives to its configuration 
> ( similar to " exclude= " ) ?
> This could increase the reliability of " yum downgrade " in the eyes of those 
> that use it.
>
> MySQL and PostgreSQL come to mind.
> /etc/yum.conf might have " nodowngrade=mysql-server postgresql-server " in 
> the default file.
> That's easier than carrying that info in the package or repo files.
> When additional packages are found to be not downgradable, they can be added 
> to the list.
> Granted, if there are a lot of packages, that gets unwieldy.
> Also, it could break a downgrade transaction.
>

I have no idea what that would do? just tell the user "tough noogies"?

-sv



From rjones at redhat.com  Wed Oct 14 18:56:38 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Oct 2009 19:56:38 +0100
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <4AD60370.3040302@freenet.de>
References: 
	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
	<4AD60370.3040302@freenet.de>
Message-ID: <20091014185638.GA26995@amd.home.annexia.org>

On Wed, Oct 14, 2009 at 06:59:28PM +0200, Ralf Corsepius wrote:
> Then our opions diverge: I think it should be a hard show stopper criterion.
>
> There should not be any room for any "cripple ware" in Fedora nor should  
> Fedora be a stage for "closed source loaders".

So it should apply to pretty much all of Fedora, since Fedora depends
on closed source firmware, BIOSes, microcode and even hardware
designs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From skvidal at fedoraproject.org  Wed Oct 14 18:57:59 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 14:57:59 -0400 (EDT)
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091014185638.GA26995@amd.home.annexia.org>
References: 
	<4AD5EE49.60608@freenet.de>
	<20091014163039.GB26008@amd.home.annexia.org>
	<4AD60370.3040302@freenet.de>
	<20091014185638.GA26995@amd.home.annexia.org>
Message-ID: 



On Wed, 14 Oct 2009, Richard W.M. Jones wrote:

> On Wed, Oct 14, 2009 at 06:59:28PM +0200, Ralf Corsepius wrote:
>> Then our opions diverge: I think it should be a hard show stopper criterion.
>>
>> There should not be any room for any "cripple ware" in Fedora nor should
>> Fedora be a stage for "closed source loaders".
>
> So it should apply to pretty much all of Fedora, since Fedora depends
> on closed source firmware, BIOSes, microcode and even hardware
> designs.

eyeroll.


-sv



From Theodore.Papadopoulo at sophia.inria.fr  Wed Oct 14 19:02:18 2009
From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo)
Date: Wed, 14 Oct 2009 21:02:18 +0200
Subject: Rationale behind _cmake_skip_rpath choice in /etc/rpm/macros.cmake
Message-ID: <4AD6203A.9060207@sophia.inria.fr>

I would like to understand why the file macros.cmake as distributed in 
fedora-10 defines:
%_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON

I use cmake to build an rpm for a software that builds several libraries 
and binaries (based
on those libraries). In the spec file of my rpm I decided to add some
make test
into order to check at rpm build time that everything is OK (I agree 
that this is probably an overkill).
Disabling the rpath made all the checks to fail, so I added a:

%define _cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=OFF

at the beginning of my specfile.

But I wonder whether there is any risk in doing so.... Is there a risk 
of library interception if someone
re-creates a library in the ??

I suppose that the choice was made on purpose, I just want to assess the 
risk I'm taking in having
this approach. Otherwise, I'll just remove the test stuff from the spec 
file (as I found no other way
of doing the tests... Setting LD_LIBRARY_PATH before the make test does 
not seem to work
probably because ctest is careful in setting a clean environment for the 
tests....).

The only other solution I can think of would be putting the check in the 
%install section after having
done the make install  and testing with a chroot placed on 
$RPM_BUILD_ROOT (but I fear I need a
subshell for the rpm process to proceed after the test)  ?
Are there any advice on this ?

In advance, thank's a lot.



From awilliam at redhat.com  Wed Oct 14 20:26:53 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 14 Oct 2009 13:26:53 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <20091014112142.5d208c6e@faldor.intranet>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	<20091014112142.5d208c6e@faldor.intranet>
Message-ID: <1255552013.2376.12.camel@adam.local.net>

On Wed, 2009-10-14 at 11:21 +0200, Michael Schwendt wrote:
> On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote:
> 
> > We really need some stricter enforcement against stuff sitting in testing 
> > forever.
> 
> Rather we need some rules against such mindset.
> 
> We don't guarantee anything about updates-testing. It's a place where
> to test potential updates/upgrades. And if a test-update is still without
> sufficient karma points (either positive or negative) for several weeks,
> it may stay in updates-testing for a longer time. IMO, that's a good
> thing.

I agree with this, but by the same token, the use suggested by Matej
seems against the purpose of updates-testing, as does the original idea
in this thread (push some Xorg changes we'd never be happy about putting
in stable into it). I also agree with Kevin - maybe we don't need to
*disallow* updates sitting in -testing for a long time, but updates
sitting there for a long time is an indication of potential issues and
it should be flagged for tracking.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From rdieter at math.unl.edu  Wed Oct 14 20:39:45 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 14 Oct 2009 15:39:45 -0500
Subject: Rationale behind _cmake_skip_rpath choice in
	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr>
Message-ID: 

Theodore Papadopoulo wrote:

> I would like to understand why the file macros.cmake as distributed in
> fedora-10 defines:
> %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON

or just
%define _cmake_skip_rpath %{nil}
to disable (why it was made a macro, so it's easy to change or override).

It's probably not needed anymore, cmake-based builds should omit rpath by
default, and only use it when necessary, and the hammer above will (I
think) disable that as well.

-- Rex



From bruno at wolff.to  Wed Oct 14 21:38:36 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 14 Oct 2009 16:38:36 -0500
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>
References: <20091014160006.167D98E013E@hormel.redhat.com>
	<644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>
Message-ID: <20091014213836.GA29565@wolff.to>

On Wed, Oct 14, 2009 at 13:55:13 -0500,
  chasd  wrote:
> 
> MySQL and PostgreSQL come to mind.

Postgres isn't even updatable. You need to do dumps before doing the upgrade.
So downgrades aren't too much worse than upgrades. (Though the new dumps
might use new features that will need to get modified to make them readable
by old versions.)



From lmacken at redhat.com  Wed Oct 14 22:00:18 2009
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 14 Oct 2009 18:00:18 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
Message-ID: <20091014220018.GK14755@x300.cable.rcn.com>

On Wed, Oct 14, 2009 at 10:00:07AM -0500, Mike McGrath wrote:
> On Wed, 14 Oct 2009, Jesse Keating wrote:
> 
> > On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote:
> > > On Wed, 14 Oct 2009, Jesse Keating wrote:
> > >
> > > > On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote:
> > > > >
> > > > > The problem isn't GLODA and smart folders, it's that we have no process in
> > > > > place to identify and deal with problems like this before it's too late.
> > > >
> > > > Aside from updates-testing you mean, where people can test potential
> > > > updates and give feedback as to how they work on their systems?
> > > >
> > >
> > > Fat lot of good it's doing.
> > >
> > > 	-Mike
> > >
> >
> > And that's a people problem more than a process problem.  If nobody
> > tests it in updates-testing, then how is the maintainer to know that it
> > is problematic?  Certainly not solvable with even more repos for testing
> > content...
> >
> 
> You let me know how three people in Fedora can miss a very subtle Firefox
> memory leak.  How many people would need to use updates testing before the
> thunderbird indexing problem is caught?  How long would it need to stay
> there?  In this case updates-testing theory just does not match reality.
> 
> The status quo is broken, doing nothing will keep it that way.

I think there are many things we can do within Bodhi & Fedora Community
to better facilitate testing updates.  For example, I think we should do
a better job of emphasizing the importance of certain updates in the
queue, especially security updates with little or no karma.

The karma system that I implemented in bodhi hasn't really changed much
over the years, and I think it's probably time to reassess some of the
default options (eg: +3 for marking as stable is probably way too low
for packages like the kernel and thunderbird).

Since there are actually a lot of people who provide feedback in bodhi
(presently 1448 different people have left comments in bodhi since F10),
we obviously are not doing a good enough job of leveraging them.

One way to improve our testing strategy would be to keep adding and
improving the test cases to the wiki:

    https://fedoraproject.org/wiki/Category:Test_Cases

We could then point people directly to the appropriate steps for testing
the application, from within bodhi, fedora community, etc...

luke



From awilliam at redhat.com  Wed Oct 14 22:53:05 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 14 Oct 2009 15:53:05 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD5E7C7.7080504@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org> <4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org> <4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	<4AD5E7C7.7080504@fedoraproject.org>
Message-ID: <1255560785.2314.8.camel@adam.local.net>

On Wed, 2009-10-14 at 20:31 +0530, Rahul Sundaram wrote:
> On 10/14/2009 08:23 PM, Jesse Keating wrote:
> 
> > And that's a people problem more than a process problem.  If nobody
> > tests it in updates-testing, then how is the maintainer to know that it
> > is problematic?  Certainly not solvable with even more repos for testing
> > content...
> 
> 3 people give positive feedback and the update is automatically pushed
> from updates-testing to updates despite atleast one feedback to the
> contrary at
> 
> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615
> 
> The UI changes certainly would be visible without any user feedback. The
> buttons getting removed from the toolbar as well as smart folders were
> immediately visible within minutes. Anyone with significant amount of
> email would probably run into the indexing issue soon as well.
> 
> Note that the update indicates it is a security issue but doesnt explain
> what the security fix is nor does it indicate what other major changes
> are there. No notes has been entered to assist the testers. I don't
> think the onus can be placed entirely on potential testers to provide
> feedback within a week. That is just finger pointing and doesn't help
> address such problems or even mitigate it.

It's worth looking in more detail at exactly what the feedback was.
Here's some of the feedback which was marked positive, i.e. +1:

"loving the new search stuff"

"Works for me, is it intended behaviour that several buttons including
"Delete" disappear off the main (top) toolbar?"

without those two bits of feedback - which noted what were later
identified as problems with the update, but nevertheless rated it
positively - it wouldn't have been pushed. it only ever hit exactly +3,
never higher. without those comments, it would have hit a max of +1.

so I disagree with the notion that bodhi / updates-testing are useless
("fat lot of good"), and agree with Jesse that the evidence doesn't
support the conclusion that the best fix is to throw more repositories
at the problem.

I'd agree with Jesse's point that it would've been best for the
maintainers to disable the +3-automatic-push for this update, though
hindsight is always 20-20. perhaps we (QA / rel-eng) need to give more
specific advice about when to use it. My perspective would be that
automatic-push should only be used when you're making a small-scale
update which fixes one or two specific issues and does not change
behaviour in other ways. It should not be used for a big update like
this which rolls up many 'fixes' and things which can't strictly be
described as fixes, because you're going to get a situation like this
where it's hard for a simple +1 / -1 from individual testers to judge
the update.

We might also look at providing better instructions for people providing
feedback on exactly when to use the +1, -1 and 0 options. I'll try and
find some time to look at that.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From skvidal at fedoraproject.org  Wed Oct 14 22:53:22 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 14 Oct 2009 18:53:22 -0400 (EDT)
Subject: thunderbird upgrade - wtf?
In-Reply-To: <20091014220018.GK14755@x300.cable.rcn.com>
References: <4AD421A1.6060609@pobox.com> <4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
	<20091014220018.GK14755@x300.cable.rcn.com>
Message-ID: 



On Wed, 14 Oct 2009, Luke Macken wrote:

> I think there are many things we can do within Bodhi & Fedora Community
> to better facilitate testing updates.  For example, I think we should do
> a better job of emphasizing the importance of certain updates in the
> queue, especially security updates with little or no karma.
>


Before we go working on the karma system - is it doable to add some fields 
so we can denote critical path pkgs?

If I know there is a place for the data, I can get you quick code to 
produce the list given any set of pkgs as soon as tomorrow. Hell, It is 
already written, iirc.

It seems like critpath is more important in bodhi than karma, to me.

-sv



From orion at cora.nwra.com  Wed Oct 14 22:55:13 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 14 Oct 2009 16:55:13 -0600
Subject: Status of geronimo
Message-ID: <4AD656D1.2080502@cora.nwra.com>

Can someone shed light on the status of geronimo in Fedora?  Seems like 
it hasn't managed to build since F11 - and the F11 build was never 
pushed.  There is a geronimo-spec 1.2 in CVS that doesn't compile 
(missing dependencies among other things).  Apache's site has version 2.1.4.

Mind you, I know nothing about geronimo other than a package I'm trying 
to build depends on geronimo-stax-api.

-- 
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 lmacken at redhat.com  Wed Oct 14 23:33:45 2009
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 14 Oct 2009 19:33:45 -0400
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD5C235.9030608@RedHat.com> <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
	<20091014220018.GK14755@x300.cable.rcn.com>
	
Message-ID: <20091014233345.GM14755@x300.cable.rcn.com>

On Wed, Oct 14, 2009 at 06:53:22PM -0400, Seth Vidal wrote:
>
>
> On Wed, 14 Oct 2009, Luke Macken wrote:
>
>> I think there are many things we can do within Bodhi & Fedora Community
>> to better facilitate testing updates.  For example, I think we should do
>> a better job of emphasizing the importance of certain updates in the
>> queue, especially security updates with little or no karma.
>>
>
>
> Before we go working on the karma system - is it doable to add some 
> fields so we can denote critical path pkgs?
>
> If I know there is a place for the data, I can get you quick code to  
> produce the list given any set of pkgs as soon as tomorrow. Hell, It is  
> already written, iirc.
>
> It seems like critpath is more important in bodhi than karma, to me.

Yeah, I agree critpath is more important at the moment.

So we have a few options for where to throw this data.

 - We could add a new field to the bodhi Package SQLObject model
   This will entail DB schema changes.  I've never altered bodhi's
   model below our DB before, but I think we could maybe just run an
   ALTER TABLE, and be all set.  I'll have to test this first.  bodhi
   v2.0 will use SQLAlchemy, so we'll have much better schema migration
   tools to use.

 - The quick and dirty solution would be to generate the critpath list
   and stuff it in bodhi's config file (like we do with packages that
   require a reboot).  Or, if it's quick to generate,
   we could do it on startup.  I'm not sure how large the list is so
   we'll have to see.

 - We could also have a flag in the pkgdb for critpath packages, which
   would be simple to query.  It feels like the pkgdb should know about
   critpath packages.

There are probably some other ways too, but once I see the code to
generate I'm sure I can figure out how to get bodhi to use it.

luke



From jwboyer at gmail.com  Thu Oct 15 00:41:10 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Oct 2009 20:41:10 -0400
Subject: bodhi changes
In-Reply-To: <20091014233345.GM14755@x300.cable.rcn.com>
References: <4AD5C867.4080802@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
	<20091014220018.GK14755@x300.cable.rcn.com>
	
	<20091014233345.GM14755@x300.cable.rcn.com>
Message-ID: <20091015004110.GR30884@hansolo.jdub.homelinux.org>

On Wed, Oct 14, 2009 at 07:33:45PM -0400, Luke Macken wrote:
>> Before we go working on the karma system - is it doable to add some 
>> fields so we can denote critical path pkgs?
>>
>> If I know there is a place for the data, I can get you quick code to  
>> produce the list given any set of pkgs as soon as tomorrow. Hell, It is  
>> already written, iirc.
>>
>> It seems like critpath is more important in bodhi than karma, to me.
>
>Yeah, I agree critpath is more important at the moment.
>
>So we have a few options for where to throw this data.
>
> - We could add a new field to the bodhi Package SQLObject model
>   This will entail DB schema changes.  I've never altered bodhi's
>   model below our DB before, but I think we could maybe just run an
>   ALTER TABLE, and be all set.  I'll have to test this first.  bodhi
>   v2.0 will use SQLAlchemy, so we'll have much better schema migration
>   tools to use.
>
> - The quick and dirty solution would be to generate the critpath list
>   and stuff it in bodhi's config file (like we do with packages that
>   require a reboot).  Or, if it's quick to generate,
>   we could do it on startup.  I'm not sure how large the list is so
>   we'll have to see.
>
> - We could also have a flag in the pkgdb for critpath packages, which
>   would be simple to query.  It feels like the pkgdb should know about
>   critpath packages.
>
>There are probably some other ways too, but once I see the code to
>generate I'm sure I can figure out how to get bodhi to use it.

I think this would be really beneficial to No-Frozen-Rawhide as well, so that
we could make Bodhi wait for a rel-eng/QA signoff on critpath packages before
allowing them to be promoted during the devel cycle.

Extending that to updates-testing -> updates transition in released versions
would be bonus as well.

josh



From poelstra at redhat.com  Thu Oct 15 00:52:01 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 14 Oct 2009 17:52:01 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>			<1255530711.4148.413.camel@localhost.localdomain>		<4AD612E0.7020801@redhat.com>	
	
Message-ID: <4AD67231.6080909@redhat.com>

Mike McGrath said the following on 10/14/2009 11:26 AM Pacific Time:
> On Wed, 14 Oct 2009, Mike McGrath wrote:
> 
>> On Wed, 14 Oct 2009, Christopher Aillon wrote:
>>
>>> On 10/14/2009 07:56 AM, Mike McGrath wrote:
>>>> Feodra 11 should not have shipped with a beta but the previous stable
>>>> version.
>>> That's really easy for you to say, considering you don't use Thunderbird, and
>>> you have no information about the decision making process.
>>>
>>> The information I used to make the decision was:
>>>
>>> * The upstream release date was going to be within a week of
>>>   F11's release date, from a normally reliable source
>>> * 3.0 had many desirable improvements to performance
>>> * 2.0 would be EOL'd by upstream soon
>>> * Thunderbird users tend to be in the "want upgrade now" camp
>>> * Changing from 2.0 -> 3.0 after F11 was released is not something I
>>>   wanted to do
>>> * Tb3 beta would affect a smaller portion of Fedora users anyway since
>>>   Thunderbird is _not_ the default mail client.
>>> * Given initial testing by my team, and tracking upstream feedback, it
>>>   worked well enough and there were no major regressions over 2.0.
>>>
>>>
>>> Given the situation and circumstances, with the information I had available, I
>>> would make the same decision again.
>>>
>> I would have made the same decision as you, that doesn't mean it wasn't a
>> mistake.  We have no policies or procedures in place to guide you, me or
>> anyone else otherwise.  As such, we run into these issues, cause pain for
>> the users, etc, etc.
>>
> 
> Just an additional note to this, Mozilla themselves are still directing
> people to download Thunderbird 2.
> 
> http://www.mozillamessaging.com/en-US/thunderbird/
> 
> 	-Mike
> 

This has been my work around since the addons I really depend on don't 
work on TB3.  I installed TB2 from the tarball and turned on automatic 
updates.  I also added an exclude to /etc/yum.conf for "thunderbird".

John



From Axel.Thimm at ATrpms.net  Thu Oct 15 05:09:19 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 15 Oct 2009 08:09:19 +0300
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091014172500.GB16313@wolff.to>
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
	<20091014172500.GB16313@wolff.to>
Message-ID: <20091015050919.GA7441@victor.nirvana>

On Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote:
> On Wed, Oct 14, 2009 at 18:31:03 +0200,
> > Why should we make peoples' lives harder getting the tools they
> > need? Example: Somebody without the DAHDI Kernel Modules would
> > probably not try to use the DAHDI Tools since he probably won't even
> > know what it's good for. However It makes things easier for the
> > people who do know what DAHDI is to have tools to use their DAHDI
> > hardware (they compiled/got the Kernel modules for) just a yum
> > install away.
> 
> Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time
> without having a version for a specific version Fedora. For example there
> is no rawhide version now and there was a long period without one for
> F11.

Rawhide support has quite low demand and the kernel changes daily or
more frequently in early rawhide, so any kernel bound support is
outdated before it is released. We usually fire up the rawhide support
about a month or so before the targeted release date (which means
about now). I don't think that F11 was w/o dahdi-linux kmdls for any
long period.

> There are issues trying to rebuild atrpms src rpms on fedora. Just
> grabbing atrms-rpm-config doesn't help with recursion issues that Alex
> doesn't see because of his custom environment.

Who's Alex, and why doesn't atrms-rpm-config work? You may see
`recursion' warnings due to rpm's limitation of macros depth (which
has nothing to do with recursion), which is at 16, but in reality
means about 3-4 nested macros.

> What I had to do for F12 is grab a spec file (that get's updates at
> the source) that was proposed for rpmfusion (but never got adopted
> by them) and then use an svn version of dahdi that has a fix for a
> change in the way the kernel is being built (some compatibility
> feature that got dropped in 2.6.32).  That box has been extra
> unstable lately, though I don't know if that is do to 3D graphics or
> dahdi-linux.

Have you tried the common src.rpm at ATrpms? Maybe you should check
out ATrpms in a couple of days and see whether there is dahdi support
for F12 there.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From bruno at wolff.to  Thu Oct 15 05:51:01 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 15 Oct 2009 00:51:01 -0500
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091015050919.GA7441@victor.nirvana>
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
	<20091014172500.GB16313@wolff.to>
	<20091015050919.GA7441@victor.nirvana>
Message-ID: <20091015055101.GA2274@wolff.to>

On Thu, Oct 15, 2009 at 08:09:19 +0300,
  Axel Thimm  wrote:
> On Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote:
> > On Wed, Oct 14, 2009 at 18:31:03 +0200,
> > > Why should we make peoples' lives harder getting the tools they
> > > need? Example: Somebody without the DAHDI Kernel Modules would
> > > probably not try to use the DAHDI Tools since he probably won't even
> > > know what it's good for. However It makes things easier for the
> > > people who do know what DAHDI is to have tools to use their DAHDI
> > > hardware (they compiled/got the Kernel modules for) just a yum
> > > install away.
> > 
> > Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time
> > without having a version for a specific version Fedora. For example there
> > is no rawhide version now and there was a long period without one for
> > F11.
> 
> Rawhide support has quite low demand and the kernel changes daily or
> more frequently in early rawhide, so any kernel bound support is
> outdated before it is released. We usually fire up the rawhide support

Yes, but usually just rebuilding from the source rpm would work if
I had an environment where I could do that. I am doing that now with
the version based on a spec file from messinet.com.

> about a month or so before the targeted release date (which means
> about now). I don't think that F11 was w/o dahdi-linux kmdls for any
> long period.

Possibly it was during the F11 rawhide period that I looked and I didn't
check back for a while after the release.

Unfortunately my tdm card is in my only machine at home that has 3d graphics at
all working using the drivers in Fedora. And I needed to go to rawhide to
get that working more than I needed to having tdm card working (though in
the end I got both).

> > There are issues trying to rebuild atrpms src rpms on fedora. Just
> > grabbing atrms-rpm-config doesn't help with recursion issues that Alex
> > doesn't see because of his custom environment.
> 
> Who's Alex, and why doesn't atrms-rpm-config work? You may see

Sorry about misspelling your name.

> `recursion' warnings due to rpm's limitation of macros depth (which
> has nothing to do with recursion), which is at 16, but in reality
> means about 3-4 nested macros.

Yes. But I didn't see any clear instructions for how to work around it.
It seems that for some people using --define can work around the problem
if you know what to define. There was also a comment that you don't see
the problem because of something in your environment but I didn't see
any directions on how to set up a similar environment.

> > What I had to do for F12 is grab a spec file (that get's updates at
> > the source) that was proposed for rpmfusion (but never got adopted
> > by them) and then use an svn version of dahdi that has a fix for a
> > change in the way the kernel is being built (some compatibility
> > feature that got dropped in 2.6.32).  That box has been extra
> > unstable lately, though I don't know if that is do to 3D graphics or
> > dahdi-linux.
> 
> Have you tried the common src.rpm at ATrpms? Maybe you should check
> out ATrpms in a couple of days and see whether there is dahdi support
> for F12 there.

I tried using the dahdi-linux src rpm while having atrpms-rpm-config
installed, but hit the recursion problem and got stuck there. I would
still have had the problem with the last released dahdi not working
with 2.6.31 kernels. But fixing that would have taken the same route
as with the path I ended up taking.



From pbrobinson at gmail.com  Thu Oct 15 07:51:28 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 08:51:28 +0100
Subject: tagging of non critical path package into F-12?
Message-ID: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>

Hi All,

I presume that the reason that tagging requests aren't being done is
due to the upcoming beta but is there a reason that non core or
critical path packages can't be tagged in. I have a number of Moblin
packages that fix various issues, in particular a rebuild of
network-manager-netbook to fix networking against the latest NM build
that hit just before the cut off. Given that none of these packages
would be anywhere near any of the official spins is there any
particular reason they can't be tagged in? Or if not when will they be
reviewed?

Peter



From cemeyer at u.washington.edu  Thu Oct 15 07:55:18 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Thu, 15 Oct 2009 00:55:18 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
Message-ID: <200910150055.18568.cemeyer@u.washington.edu>

On Thursday 15 October 2009 12:51:28 am Peter Robinson wrote:
> Hi All,
> 
> I presume that the reason that tagging requests aren't being done is
> due to the upcoming beta but is there a reason that non core or
> critical path packages can't be tagged in. I have a number of Moblin
> packages that fix various issues, in particular a rebuild of
> network-manager-netbook to fix networking against the latest NM build
> that hit just before the cut off. Given that none of these packages
> would be anywhere near any of the official spins is there any
> particular reason they can't be tagged in? Or if not when will they be
> reviewed?
> 
> Peter

Hi,

If they're not on any of the official spins, what benefit does tagging them 
into dist-f12 provide over having them as updates? (Pushing updates is the 
suggested approach unless there's some reason it won't work in your case.)

Regards,
-- 
Conrad Meyer 



From pbrobinson at gmail.com  Thu Oct 15 07:59:13 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 08:59:13 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <200910150055.18568.cemeyer@u.washington.edu>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
Message-ID: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>

On Thu, Oct 15, 2009 at 8:55 AM, Conrad Meyer  wrote:
> On Thursday 15 October 2009 12:51:28 am Peter Robinson wrote:
>> Hi All,
>>
>> I presume that the reason that tagging requests aren't being done is
>> due to the upcoming beta but is there a reason that non core or
>> critical path packages can't be tagged in. I have a number of Moblin
>> packages that fix various issues, in particular a rebuild of
>> network-manager-netbook to fix networking against the latest NM build
>> that hit just before the cut off. Given that none of these packages
>> would be anywhere near any of the official spins is there any
>> particular reason they can't be tagged in? Or if not when will they be
>> reviewed?
>>
>> Peter
>
> Hi,
>
> If they're not on any of the official spins, what benefit does tagging them
> into dist-f12 provide over having them as updates? (Pushing updates is the
> suggested approach unless there's some reason it won't work in your case.)

Because it allows me to test them as part of what will become the F-12
Moblin remix spin and allows others to test them rather than me having
to setup a separate repository so I can test how the interact with the
rest of the Moblin packages in Fedora.

Peter



From markmc at redhat.com  Thu Oct 15 08:03:14 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 15 Oct 2009 09:03:14 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
Message-ID: <1255593794.2726.37.camel@blaa>

Hi Peter,

On Thu, 2009-10-15 at 08:51 +0100, Peter Robinson wrote:
> Hi All,
> 
> I presume that the reason that tagging requests aren't being done is
> due to the upcoming beta but is there a reason that non core or
> critical path packages can't be tagged in. I have a number of Moblin
> packages that fix various issues, in particular a rebuild of
> network-manager-netbook to fix networking against the latest NM build
> that hit just before the cut off. Given that none of these packages
> would be anywhere near any of the official spins is there any
> particular reason they can't be tagged in? Or if not when will they be
> reviewed?

It took me a little while to find your tag request:

  https://fedorahosted.org/rel-eng/ticket/2448

I've found my tag requests have all been acted on quickly, so I'm
guessing it's just a matter of someone in rel-eng finding the time to
get to yours.

Cheers,
Mark.



From xjakub at fi.muni.cz  Thu Oct 15 08:12:22 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Thu, 15 Oct 2009 10:12:22 +0200
Subject: Maintainer MIA: Claudio Tomasoni
In-Reply-To: <1255207413.7848.53.camel@wicktop.localdomain>
References: <1255116851.6035.20.camel@localhost>	<50baabb30910101241u1b0ebed2i2515d5156b2bed77@mail.gmail.com>
	<1255207413.7848.53.camel@wicktop.localdomain>
Message-ID: <4AD6D966.1000602@fi.muni.cz>

On 10/10/2009 10:43 PM, Christoph Wickert wrote:
> Am Samstag, den 10.10.2009, 21:41 +0200 schrieb Chitlesh GOORAH:
>> On Fri, Oct 9, 2009 at 9:34 PM, Christoph Wickert wrote:
>>> I am starting the AWOL procedure [1] for Claudio Tomasoni, because he
>>> didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried
>>> to contact him for more than 7 months [3]. We should prepare for taking
>>> over Claudio's packages [4].
>>
>> I'm willing to take over :
>> https://admin.fedoraproject.org/pkgdb/packages/name/octaviz

I should discourage anybody from taking over octaviz, the package fails 
to build from source as it is not compatible with vtk > 5.0 [1], I spent 
with it several hours when it failed during our F11 mass rebuild in 
February, without any significant success.

IMO it should be just killed for now since it doesn't seem that there 
will be any positive changes soon.

Regards,
Milos


[1] Read more here: http://sourceforge.net/projects/octaviz/develop



From mschwendt at gmail.com  Thu Oct 15 09:26:30 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 15 Oct 2009 11:26:30 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255552013.2376.12.camel@adam.local.net>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
Message-ID: <20091015112630.31b47388@faldor.intranet>

On Wed, 14 Oct 2009 13:26:53 -0700, Adam wrote:

> (push some Xorg changes we'd never be happy about putting
> in stable into it). 

If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relying on karma automatism).

However, it could be that you would need to offer a test-update for two or
more months before you would get essential feedback that helps with
deciding whether it's safe to mark it stable or not.

Especially with regard to version upgrades: if you know the current
package release doesn't suffer from any bugs (as tracked via bugzilla)
and a test-update to a new version may cause regression, why rush and
mark it stable without sufficient feedback? Why force users of stable
updates to become guinea pigs?

> I also agree with Kevin - maybe we don't need to
> *disallow* updates sitting in -testing for a long time, but updates
> sitting there for a long time is an indication of potential issues and
> it should be flagged for tracking.

0 karma points is "an indication of potential issues"? Not at all.
0 or +1 karma points after a month doesn't make it safe either to mark it
stable. It depends on _who_ contributed _what_ sorts of tests. It may be
that another important tester finds a show-stopper issue three weeks
later. Sometimes we only win a new tester, who would normally avoid
updates-testing like the plague, for a specific test-update while
communicating within a bugzilla ticket. Sometimes not even that, and
all you can get is to have a reporter download a build from koji.

Now tell me how to attract more testers to try updates-testing and enable
it by default on one machine, perhaps a personal desktop. If we continue
to offer test-updates which may "eat babies", as some of you call it, you
can't win much. Not a big problem for kernel test-updates, which aren't
booted by default, but a threat nevertheless. More of a problem for any of
the other packages which get replaced - and there's a steady flood of
packages in updates-testing. One can hear again and again from users that
they don't like "more bleeding-edge" than "stable updates" and that they
expect the package maintainers to give certain guarantees for the
"stability" of updates they offer. No guarantees => let the community
contribute testing. No testing => keep the test-update in updates-testing.



From benny+usenet at amorsen.dk  Thu Oct 15 09:53:04 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 15 Oct 2009 11:53:04 +0200
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255532025.4148.414.camel@localhost.localdomain> (Jesse
	Keating's message of "Wed, 14 Oct 2009 07:53:45 -0700")
References: <4AD15A0F.9080708@pobox.com> <4AD17515.4070606@cchtml.com>
	<20091011084154.GA1481@tutu.torimasen.com>
	<4AD20495.1000006@cchtml.com> <4AD20578.4050404@fedoraproject.org>
	<4AD208BF.5040501@cchtml.com> <4AD20BE3.4030709@fedoraproject.org>
	<4AD4170C.40609@redhat.com> <4AD421A1.6060609@pobox.com>
	<4AD486F9.5040300@redhat.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com> 
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
Message-ID: 

Jesse Keating  writes:

> And that's a people problem more than a process problem.  If nobody
> tests it in updates-testing, then how is the maintainer to know that it
> is problematic?  Certainly not solvable with even more repos for testing
> content...

I ran updates-testing for a while, but it didn't result in me writing
any bug reports. I wasn't particularly aware of whether a package came
from updates-testing, so that it was worth spending a little bit of
energy testing that particular package.

Would it be possible to make a little application which pops up on login
or every day (whichever comes first) saying "These applications are new
in updates-testing, would you like to help testing one?". Then you could
pick one and give it a try, and perhaps a few days later there would be
a pop up asking how it went?

Strictly opt-in, of course.


/Benny



From jwboyer at gmail.com  Thu Oct 15 09:54:47 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Oct 2009 05:54:47 -0400
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
Message-ID: <20091015095447.GS30884@hansolo.jdub.homelinux.org>

On Thu, Oct 15, 2009 at 08:59:13AM +0100, Peter Robinson wrote:
>On Thu, Oct 15, 2009 at 8:55 AM, Conrad Meyer  wrote:
>> On Thursday 15 October 2009 12:51:28 am Peter Robinson wrote:
>>> Hi All,
>>>
>>> I presume that the reason that tagging requests aren't being done is
>>> due to the upcoming beta but is there a reason that non core or
>>> critical path packages can't be tagged in. I have a number of Moblin
>>> packages that fix various issues, in particular a rebuild of
>>> network-manager-netbook to fix networking against the latest NM build
>>> that hit just before the cut off. Given that none of these packages
>>> would be anywhere near any of the official spins is there any
>>> particular reason they can't be tagged in? Or if not when will they be
>>> reviewed?
>>>
>>> Peter
>>
>> Hi,
>>
>> If they're not on any of the official spins, what benefit does tagging them
>> into dist-f12 provide over having them as updates? (Pushing updates is the
>> suggested approach unless there's some reason it won't work in your case.)
>
>Because it allows me to test them as part of what will become the F-12
>Moblin remix spin and allows others to test them rather than me having
>to setup a separate repository so I can test how the interact with the
>rest of the Moblin packages in Fedora.

We're at RC2 of the Beta spin and not really tagging anything until Beta is
out the door.  After that, tag requests will pick back up so things can be
included in the final release.

josh



From benny+usenet at amorsen.dk  Thu Oct 15 10:06:30 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 15 Oct 2009 12:06:30 +0200
Subject: Updates-testing
In-Reply-To: <20091014213836.GA29565@wolff.to> (Bruno Wolff, III's message of
	"Wed, 14 Oct 2009 16:38:36 -0500")
References: <20091014160006.167D98E013E@hormel.redhat.com>
	<644D8981-EE04-4A12-880B-EA4F52B04420@silveroaks.com>
	<20091014213836.GA29565@wolff.to>
Message-ID: 

Bruno Wolff III  writes:

> Postgres isn't even updatable. You need to do dumps before doing the upgrade.
> So downgrades aren't too much worse than upgrades. (Though the new dumps
> might use new features that will need to get modified to make them readable
> by old versions.)

Note that there is experimental support for in-place upgrades in
PostgreSQL 8.4.


/Benny



From akurtako at redhat.com  Thu Oct 15 11:47:39 2009
From: akurtako at redhat.com (Alexander Kurtakov)
Date: Thu, 15 Oct 2009 14:47:39 +0300
Subject: Status of geronimo
In-Reply-To: <4AD656D1.2080502@cora.nwra.com>
References: <4AD656D1.2080502@cora.nwra.com>
Message-ID: <200910151447.40018.akurtako@redhat.com>

> Can someone shed light on the status of geronimo in Fedora?  Seems like
> it hasn't managed to build since F11 - and the F11 build was never
> pushed.  There is a geronimo-spec 1.2 in CVS that doesn't compile
> (missing dependencies among other things).  Apache's site has version
>  2.1.4.
> 
> Mind you, I know nothing about geronimo other than a package I'm trying
> to build depends on geronimo-stax-api.
> 

Hi Orion,

If you're using JDK 6.0, the StAX API is included in it. If I was you I would 
try removing the dependency and build with OpenJDK to see if it will work.

Good luck,
Alex



From rawhide at fedoraproject.org  Thu Oct 15 13:04:03 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 15 Oct 2009 13:04:03 +0000
Subject: rawhide report: 20091015 changes
Message-ID: <20091015130403.GA7397@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 15 06:15:06 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.0-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json



Updated Packages:

anaconda-12.38-1.fc12
---------------------
* Tue Oct 13 2009 David Cantrell  - 12.38-1
- Remove extra echo in 'make rpmlog'. (dcantrell)
- Do not traceback if network device doesn't have HwAddress property
  (#506013). (rvykydal)
- Fix liveinst to (1) not unmount /dev/pts, (2) unmount in order (509632).
  (clumens)
- Do not read DASD data from /tmp/install.cfg in booty (#526354). (dcantrell)
- Fix task selection when tasks contain the same group. (#528193) (notting)
- Update drivelist with bootloader --driveorder ks option instead of
  replacing it (#506073). (rvykydal)
- Use ID_SERIAL to write multipath.conf, but ID_SERIAL_SHORT for UI. (pjones)
- Handle Installation Repo (base repo) as any other in repo edit UI.
  (rvykydal)
- Fix methodstr editing dialog. (rvykydal)
- Store methodstr url of repo (#502208, #526022). (rvykydal)
- Show user of which repository he edits the url (methodstr editing).
  (rvykydal)
- Don't traceback with malformed repo= nfs: parameter. (rvykydal)


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1



From opensource at till.name  Thu Oct 15 14:02:20 2009
From: opensource at till.name (Till Maas)
Date: Thu, 15 Oct 2009 16:02:20 +0200
Subject: What to do if a deprecated license is used? nescc java files with
	intel license
Message-ID: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>

Hiyas,

I looked into packaging the nesc compiler
(https://sourceforge.net/projects/nescc) and I noticed that it uses the
deprecated intel license for some java files:
http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-LICENSE?revision=1.1&view=markup

I opened a bug in their bug tracking system for this:
https://sourceforge.net/tracker/?func=detail&aid=2879881&group_id=56288&atid=480036

The Intel license is OSI approved, but deprecated and therefore
currently not allowed for Fedora afaics:
https://fedoraproject.org/wiki/Licensing#Bad_Licenses
Btw. it's a "should not", so maybe it is ok, nevertheless. Or it should
be a "must not" guideline, e.g. because it also affects non OSI approved
liceneses afaics.

Btw. is someone else interested in packaging nescc? I would happily
welcome a co-maintainer or become a co-maintainer, since I do not yet
have experience with it.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From a.badger at gmail.com  Thu Oct 15 15:02:03 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 15 Oct 2009 08:02:03 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
Message-ID: <20091015150203.GC19753@clingman.lan>

On Thu, Oct 15, 2009 at 08:59:13AM +0100, Peter Robinson wrote:
> On Thu, Oct 15, 2009 at 8:55 AM, Conrad Meyer  wrote:
> > If they're not on any of the official spins, what benefit does tagging them
> > into dist-f12 provide over having them as updates? (Pushing updates is the
> > suggested approach unless there's some reason it won't work in your case.)
> 
> Because it allows me to test them as part of what will become the F-12
> Moblin remix spin and allows others to test them rather than me having
> to setup a separate repository so I can test how the interact with the
> rest of the Moblin packages in Fedora.
> 
Does the old network-manager-netbook prevent people from getting onto the
network?  If so, it seems important to make sure the fixed version goes into
the release repositories.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From pbrobinson at gmail.com  Thu Oct 15 15:18:35 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 16:18:35 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <20091015150203.GC19753@clingman.lan>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<20091015150203.GC19753@clingman.lan>
Message-ID: <5256d0b0910150818j3c139fbblc7d234f8c8fd49c7@mail.gmail.com>

On Thu, Oct 15, 2009 at 4:02 PM, Toshio Kuratomi  wrote:
> On Thu, Oct 15, 2009 at 08:59:13AM +0100, Peter Robinson wrote:
>> On Thu, Oct 15, 2009 at 8:55 AM, Conrad Meyer  wrote:
>> > If they're not on any of the official spins, what benefit does tagging them
>> > into dist-f12 provide over having them as updates? (Pushing updates is the
>> > suggested approach unless there's some reason it won't work in your case.)
>>
>> Because it allows me to test them as part of what will become the F-12
>> Moblin remix spin and allows others to test them rather than me having
>> to setup a separate repository so I can test how the interact with the
>> rest of the Moblin packages in Fedora.
>>
> Does the old network-manager-netbook prevent people from getting onto the
> network? ?If so, it seems important to make sure the fixed version goes into
> the release repositories.

Yes, in fact it doesn't even run. That's why it seems that all the
various NM vpn plugins had to be recompiled as well.

Peter



From jkeating at redhat.com  Thu Oct 15 15:22:45 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Oct 2009 08:22:45 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255593794.2726.37.camel@blaa>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255593794.2726.37.camel@blaa>
Message-ID: <1255620165.2894.4.camel@localhost.localdomain>

On Thu, 2009-10-15 at 09:03 +0100, Mark McLoughlin wrote:
> 
> It took me a little while to find your tag request:
> 
>   https://fedorahosted.org/rel-eng/ticket/2448
> 
> I've found my tag requests have all been acted on quickly, so I'm
> guessing it's just a matter of someone in rel-eng finding the time to
> get to yours.
> 

More of what Josh said.  We entered release candidate phase,
so /nothing/ gets changes unless it is a release blocker.  Hopefully we
can sign off on the release candidate today and move on toward final
release (and I'll process all the pending tags for final)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From kevin.kofler at chello.at  Thu Oct 15 15:21:42 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 15 Oct 2009 17:21:42 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
Message-ID: 

Mat?j Cepl wrote:
> This is actually your personal opinion AFAIK, right?

No, it's what updates-testing is for.

> I tend to disagree with this -- one example which seems to me legitimate
> is when I create a new package (I remember I came to this conclusion with
> both PSPP and nimbus-theme) then I sometimes push it into Fedora-[n-1]
> just for updates-testing, because I really don't have enough computers to
> do real testing on older distros.

Who gives a darn? If nobody complains about any issues, just push it! In 99% 
of cases, what works fine on Fedora n will work fine on Fedora n-1, too. If 
I push a test update to multiple Fedora releases, I always push it to stable 
for all affected releases at the same time. The only time it went wrong is 
when I pushed something built by another packager who screwed up the 
%{?fedora} conditionals (he used "%{?fedora}" string comparisons which broke 
for 9 vs. 10, you have to use 0%{?fedora}). That was trivial to fix in the 
next push.

> By that, people who really want it, can take it and they are implicitly
> warned that this is not meant to be stable (generally speaking, I guess,
> people who follow updates-testing has to survive some amount of breakage),
> but it is not thrown on unsuspecting users of stable.

The problem is, this mindset makes it harder to get people to test things 
which ARE headed for stable (which is what updates-testing is for!), because 
enabling updates-testing will include a lot of stuff which is not going 
stable any time soon. (And selective updates are not the answer, they're a 
big can of worms and have caused all sorts of breakage in KDE SIG's 
experience.)

Now OK, new packages are not really going to be a problem there, but as new 
packages have to be explicitly installed anyway, I don't see what pushing 
them to stable can break.

        Kevin Kofler



From markmc at redhat.com  Thu Oct 15 15:26:43 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 15 Oct 2009 16:26:43 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255620165.2894.4.camel@localhost.localdomain>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255593794.2726.37.camel@blaa>
	<1255620165.2894.4.camel@localhost.localdomain>
Message-ID: <1255620403.2726.68.camel@blaa>

On Thu, 2009-10-15 at 08:22 -0700, Jesse Keating wrote:
> On Thu, 2009-10-15 at 09:03 +0100, Mark McLoughlin wrote:
> > 
> > It took me a little while to find your tag request:
> > 
> >   https://fedorahosted.org/rel-eng/ticket/2448
> > 
> > I've found my tag requests have all been acted on quickly, so I'm
> > guessing it's just a matter of someone in rel-eng finding the time to
> > get to yours.
> > 
> 
> More of what Josh said.  We entered release candidate phase,
> so /nothing/ gets changes unless it is a release blocker.  Hopefully we
> can sign off on the release candidate today and move on toward final
> release (and I'll process all the pending tags for final)

Ah, I hadn't realized it was a *beta* tag request; obviously, they
should just get tagged for f12 final at this point

Cheers,
Mark.



From kevin.kofler at chello.at  Thu Oct 15 15:27:33 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 15 Oct 2009 17:27:33 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
	<20091015112630.31b47388@faldor.intranet>
Message-ID: 

Michael Schwendt wrote:
> If you know that you would _never_ be happy with a test-update becoming
> a stable update, then either don't push such a test-update or unpush
> it (manually or by relying on karma automatism).

That was my point!

> However, it could be that you would need to offer a test-update for two or
> more months before you would get essential feedback that helps with
> deciding whether it's safe to mark it stable or not.

So we only disagree about the timelines. IMHO 2 or more months is way too 
long. You should not need that much time to know whether the update is 
broken or not! The big problem is that many months is almost 
indistinguishible from "never" for all practical purposes. If you enabled 
updates from testing, you're still stuck with no upgrade path unless you 
stick with testing forever. The main advantage of putting strong time limits 
on testing is to provide an upgrade path for one-time testers back to the 
stable stream.

> 0 karma points is "an indication of potential issues"? Not at all.

It is indeed quite the opposite. It's an indication that nobody complained 
(unless it's the sum of a "+1 works for me" and a -1 with actual issues), so 
it means the update is good to go.

        Kevin Kofler



From chasd at silveroaks.com  Thu Oct 15 15:36:39 2009
From: chasd at silveroaks.com (chasd)
Date: Thu, 15 Oct 2009 10:36:39 -0500
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20091014225342.9F0A261909B@hormel.redhat.com>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
Message-ID: <137B9261-0E8D-4DB5-9817-5555A61B9070@silveroaks.com>

Charles Dostale wrote:

>> MySQL and PostgreSQL come to mind.
>> /etc/yum.conf might have " nodowngrade=mysql-server postgresql- 
>> server " in the default file.

Seth Vidal wrote:

> I have no idea what that would do? just tell the user "tough noogies"?

"  can't be downgraded because of file format changes "

Essentially, yes, tough noogies.

The alternative is for the downgrade to execute,  and even tougher  
noogies.
I guess the decision is which set of noogies is tougher, or more  
acceptable.
I thought that if there were known corner cases where a downgrade was  
really, really a bad idea, yum could keep someone from shooting  
themselves in the foot.
Maybe the current behavior that doesn't attempt to protect against  
known failures is better.


-- 
Charles Dostale



From kevin.kofler at chello.at  Thu Oct 15 15:28:33 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 15 Oct 2009 17:28:33 +0200
Subject: Maintainer MIA: Claudio Tomasoni
References: <1255116851.6035.20.camel@localhost>
	<50baabb30910101241u1b0ebed2i2515d5156b2bed77@mail.gmail.com>
	<1255207413.7848.53.camel@wicktop.localdomain>
	<4AD6D966.1000602@fi.muni.cz>
Message-ID: 

Milos Jakubicek wrote:
> I should discourage anybody from taking over octaviz, the package fails
> to build from source as it is not compatible with vtk > 5.0 [1], I spent
> with it several hours when it failed during our F11 mass rebuild in
> February, without any significant success.
> 
> IMO it should be just killed for now since it doesn't seem that there
> will be any positive changes soon.

I could try to fix it. But I have a lot of other stuff to do as well.

        Kevin Kofler



From awilliam at redhat.com  Thu Oct 15 15:46:28 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 15 Oct 2009 08:46:28 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
Message-ID: <1255621588.2314.45.camel@adam.local.net>

On Thu, 2009-10-15 at 08:59 +0100, Peter Robinson wrote:
> Because it allows me to test them as part of what will become the F-12
> Moblin remix spin 

You can add custom repositories to spin config files, so you could get
the updated packages in that way. Not ideal, but it ought to work.

As Conrad said, there's no concerted policy here AFAIK, just that no-one
yet reached your ticket for some reason.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From chasd at silveroaks.com  Thu Oct 15 15:51:20 2009
From: chasd at silveroaks.com (chasd)
Date: Thu, 15 Oct 2009 10:51:20 -0500
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <20091014225342.9F0A261909B@hormel.redhat.com>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
Message-ID: <5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>


Bruno Wolff III wrote:

> Postgres isn't even updatable. You need to do dumps before doing  
> the upgrade.

OK, maybe that isn't a good example then.

However, using your comment, and turning my idea around, if  
PostgreSQL isn't upgradable, according to my idea it should be  
excluded by default in yum.conf to protect people from hosing their  
data during an upgrade. That doesn't make a lot of sense. I must not  
be thinking particularly well, so ignore me.


-- 
Charles Dostale



From nicolas.mailhot at laposte.net  Thu Oct 15 15:51:51 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Oct 2009 17:51:51 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora 
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	 
Message-ID: <27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>



Le Jeu 15 octobre 2009 17:21, Kevin Kofler a ?crit :

> Who gives a darn? If nobody complains about any issues, just push it! In 99%
> of cases, what works fine on Fedora n will work fine on Fedora n-1, too.

It is not 99% and it takes just a few bad apples to ruin the experience
provided by the work of many others.

Please do not ever push untested work to stable just because no one
complained. If you want testing on older releases you can push it to testing
but please don't ever promote it.

People who bother to complain when hitting problems are the minority. Others
just decide after a while Fedora is not for them (which is a net loss for us;
just because someone does not have the time to do feedback at some date does
not mean he wouldn't have later)

-- 
Nicolas Mailhot




From pbrobinson at gmail.com  Thu Oct 15 15:53:32 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 16:53:32 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255621588.2314.45.camel@adam.local.net>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
Message-ID: <5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>

On Thu, Oct 15, 2009 at 4:46 PM, Adam Williamson  wrote:
> On Thu, 2009-10-15 at 08:59 +0100, Peter Robinson wrote:
>> Because it allows me to test them as part of what will become the F-12
>> Moblin remix spin
>
> You can add custom repositories to spin config files, so you could get
> the updated packages in that way. Not ideal, but it ought to work.

Already done so, farking painful and the other people that are
actually using it have borked builds because there was no email about
the changes to NetworkManager to fedora-devel to allow me to get a
rebuild done in time. It obviously a "I'm right Jack" situation.

> As Conrad said, there's no concerted policy here AFAIK, just that no-one
> yet reached your ticket for some reason.

Not according to Jesse, even in this thread there seems to be mixed
communications. My understanding was from the last FUDCon would be
that it would be complete lock down for core stuff with more
flexibility for the stuff that obviously isn't mainline and going
affect the core stability but then then I've not seen communication
either way so I honestly would have no idea.

Peter



From jkeating at redhat.com  Thu Oct 15 16:03:07 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Oct 2009 09:03:07 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
Message-ID: <1255622587.2894.10.camel@localhost.localdomain>

On Thu, 2009-10-15 at 16:53 +0100, Peter Robinson wrote:
> Not according to Jesse, even in this thread there seems to be mixed
> communications. My understanding was from the last FUDCon would be
> that it would be complete lock down for core stuff with more
> flexibility for the stuff that obviously isn't mainline and going
> affect the core stability but then then I've not seen communication
> either way so I honestly would have no idea.
> 
> 

Thats true for most of the freeze, but when we hit release candidate
stage we change absolutely nothing.  The problem right now is that there
is only one repo to publish things into, rawhide, but we have multiple
things we'd like to publish; pending F12 Beta tree, pending F12 final
tree, and the F13 tree.  We have to pick one.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From pbrobinson at gmail.com  Thu Oct 15 16:06:49 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 17:06:49 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255622587.2894.10.camel@localhost.localdomain>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
Message-ID: <5256d0b0910150906u13e448a4n3348119d6718b105@mail.gmail.com>

On Thu, Oct 15, 2009 at 5:03 PM, Jesse Keating  wrote:
> On Thu, 2009-10-15 at 16:53 +0100, Peter Robinson wrote:
>> Not according to Jesse, even in this thread there seems to be mixed
>> communications. My understanding was from the last FUDCon would be
>> that it would be complete lock down for core stuff with more
>> flexibility for the stuff that obviously isn't mainline and going
>> affect the core stability but then then I've not seen communication
>> either way so I honestly would have no idea.
>>
>>
>
> Thats true for most of the freeze, but when we hit release candidate
> stage we change absolutely nothing. ?The problem right now is that there
> is only one repo to publish things into, rawhide, but we have multiple
> things we'd like to publish; pending F12 Beta tree, pending F12 final
> tree, and the F13 tree. ?We have to pick one.

RC phase, I thought we were at the beta phase? Or is that RC for the beta phase?

Peter



From awilliam at redhat.com  Thu Oct 15 16:13:34 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 15 Oct 2009 09:13:34 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
Message-ID: <1255623214.2314.46.camel@adam.local.net>

On Thu, 2009-10-15 at 16:53 +0100, Peter Robinson wrote:
> On Thu, Oct 15, 2009 at 4:46 PM, Adam Williamson  wrote:
> > On Thu, 2009-10-15 at 08:59 +0100, Peter Robinson wrote:
> >> Because it allows me to test them as part of what will become the F-12
> >> Moblin remix spin
> >
> > You can add custom repositories to spin config files, so you could get
> > the updated packages in that way. Not ideal, but it ought to work.
> 
> Already done so, farking painful and the other people that are
> actually using it have borked builds because there was no email about
> the changes to NetworkManager to fedora-devel to allow me to get a
> rebuild done in time. It obviously a "I'm right Jack" situation.

Dan, in future can you let Peter know when you make changes to
NetworkManager which require clients to be rebuilt?

> > As Conrad said, there's no concerted policy here AFAIK, just that no-one
> > yet reached your ticket for some reason.
> 
> Not according to Jesse, even in this thread there seems to be mixed
> communications. My understanding was from the last FUDCon would be
> that it would be complete lock down for core stuff with more
> flexibility for the stuff that obviously isn't mainline and going
> affect the core stability but then then I've not seen communication
> either way so I honestly would have no idea.

I should have said that no-one reached your ticket before the
solid-freeze for the Beta release, I'm not disagreeing with Jesse.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 15 16:14:15 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 15 Oct 2009 09:14:15 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150906u13e448a4n3348119d6718b105@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<5256d0b0910150906u13e448a4n3348119d6718b105@mail.gmail.com>
Message-ID: <1255623255.2314.47.camel@adam.local.net>

On Thu, 2009-10-15 at 17:06 +0100, Peter Robinson wrote:

> > Thats true for most of the freeze, but when we hit release candidate
> > stage we change absolutely nothing.  The problem right now is that there
> > is only one repo to publish things into, rawhide, but we have multiple
> > things we'd like to publish; pending F12 Beta tree, pending F12 final
> > tree, and the F13 tree.  We have to pick one.
> 
> RC phase, I thought we were at the beta phase? Or is that RC for the beta phase?

right, the release-candidate-of-the-beta-of-f12, not the
release-candidate-of-f12. or the beta-of-the-release-candidate-of-f12.
=)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From pbrobinson at gmail.com  Thu Oct 15 16:44:31 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 15 Oct 2009 17:44:31 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255623214.2314.46.camel@adam.local.net>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255623214.2314.46.camel@adam.local.net>
Message-ID: <5256d0b0910150944s3914493epcaf0df7cd6d9d2fd@mail.gmail.com>

On Thu, Oct 15, 2009 at 5:13 PM, Adam Williamson  wrote:
> On Thu, 2009-10-15 at 16:53 +0100, Peter Robinson wrote:
>> On Thu, Oct 15, 2009 at 4:46 PM, Adam Williamson  wrote:
>> > On Thu, 2009-10-15 at 08:59 +0100, Peter Robinson wrote:
>> >> Because it allows me to test them as part of what will become the F-12
>> >> Moblin remix spin
>> >
>> > You can add custom repositories to spin config files, so you could get
>> > the updated packages in that way. Not ideal, but it ought to work.
>>
>> Already done so, farking painful and the other people that are
>> actually using it have borked builds because there was no email about
>> the changes to NetworkManager to fedora-devel to allow me to get a
>> rebuild done in time. It obviously a "I'm right Jack" situation.
>
> Dan, in future can you let Peter know when you make changes to
> NetworkManager which require clients to be rebuilt?
>
>> > As Conrad said, there's no concerted policy here AFAIK, just that no-one
>> > yet reached your ticket for some reason.
>>
>> Not according to Jesse, even in this thread there seems to be mixed
>> communications. My understanding was from the last FUDCon would be
>> that it would be complete lock down for core stuff with more
>> flexibility for the stuff that obviously isn't mainline and going
>> affect the core stability but then then I've not seen communication
>> either way so I honestly would have no idea.
>
> I should have said that no-one reached your ticket before the
> solid-freeze for the Beta release, I'm not disagreeing with Jesse.

I would be nice to have a "tomorrow's rawhide will be the last
opportunity to get things tagged into the beta" email. If there was
one I missed it and the amount of extra work it has cost me due to
having to spin up repos and answer people's direct emails of "this is
broken" would have been nice, the time it has taken me is time I don't
exactly have at the moment.

Peter



From jkeating at redhat.com  Thu Oct 15 17:00:50 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Oct 2009 10:00:50 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <5256d0b0910150944s3914493epcaf0df7cd6d9d2fd@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255623214.2314.46.camel@adam.local.net>
	<5256d0b0910150944s3914493epcaf0df7cd6d9d2fd@mail.gmail.com>
Message-ID: <1255626050.2894.11.camel@localhost.localdomain>

On Thu, 2009-10-15 at 17:44 +0100, Peter Robinson wrote:
> I would be nice to have a "tomorrow's rawhide will be the last
> opportunity to get things tagged into the beta" email. If there was
> one I missed it and the amount of extra work it has cost me due to
> having to spin up repos and answer people's direct emails of "this is
> broken" would have been nice, the time it has taken me is time I don't
> exactly have at the moment. 

Problem is we don't know when that will happen.  Every day after the
freeze could be that day, it just depends on the status of the blocker
bug.  Once all the blockers are clear, we enter release candidate phase.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From Jochen at herr-schmitt.de  Thu Oct 15 17:17:13 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 15 Oct 2009 19:17:13 +0200
Subject: Updates-testing
In-Reply-To: <5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
	<5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
Message-ID: <4AD75919.7010209@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 15.10.2009 17:51, schrieb chasd:
>
>> Postgres isn't even updatable. You need to do dumps before doing
>> the upgrade.
>
Yes, but you should make the dump with the dump utility of the new
release to which you want to update.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iJwEAQECAAYFAkrXWQUACgkQZLAIBz9lVu/5HQP+INo/h8BFMrJ9IuQOqhXQEIUn
nTcuB/W4qg7E+rlTt0Ljk5bWOBo4qpEJuxojdP0LXicPawADRlJSuZlEa13rDIPl
oAxdZlPpbehSJBKvrCsS6PugFHIJ4uW+hIX6jexH15+2Gzw+QaO2khxbZoZw0B9Y
lB8hfNl5731p00m4z08=
=VKM0
-----END PGP SIGNATURE-----



From mcepl at redhat.com  Thu Oct 15 18:22:22 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 15 Oct 2009 20:22:22 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>	<1255043946.18105.3.camel@localhost>	<1255060578.9958.11.camel@code.and.org>	
	 
Message-ID: 

Dne 15.10.2009 17:21, Kevin Kofler napsal(a):
> Mat?j Cepl wrote:
>> This is actually your personal opinion AFAIK, right?
> 
> No, it's what updates-testing is for.

Yes, that's your personal opinion about what updates-testing is for.

> Who gives a darn? If nobody complains about any issues, just push it!

Yes, I know, that's opinion of people around KDE that they don't
distinguish between Rawhide and updates-testing (I am very glad I left
KDE world in 3.* timeframe), but I don't agree with this (and that's MY
personal opinion). Unless, I would be (mis-?)using updates-testing as I
described, I wouldn't be pushing new packages into [n-2] distros at all.

Mat?j



From mcepl at redhat.com  Thu Oct 15 18:26:51 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 15 Oct 2009 20:26:51 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255552013.2376.12.camel@adam.local.net>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>	<1255043946.18105.3.camel@localhost>	<1255060578.9958.11.camel@code.and.org>
		<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
Message-ID: 

Dne 14.10.2009 22:26, Adam Williamson napsal(a):
> I agree with this, but by the same token, the use suggested by Matej
> seems against the purpose of updates-testing, as does the original idea
> in this thread (push some Xorg changes we'd never be happy about putting
> in stable into it). I also agree with Kevin - maybe we don't need to
> *disallow* updates sitting in -testing for a long time, but updates
> sitting there for a long time is an indication of potential issues and
> it should be flagged for tracking.

OK, thanks for clearing my internal conflict for me -- now there would
be no n-2 new packages from me. Simple, easy. (BTW, I always have karma
switched on, but usually nobody bothers to push karma up, so none of my
packages got pushed to stable based on its karma).

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

The state is the great fictitious entity by which everyone seeks
to live at the expense of everyone else.
      -- Frederick Bastiat



From awilliam at redhat.com  Thu Oct 15 19:04:09 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 15 Oct 2009 12:04:09 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net> 
Message-ID: <1255633449.2314.53.camel@adam.local.net>

On Thu, 2009-10-15 at 20:26 +0200, Mat?j Cepl wrote:
> Dne 14.10.2009 22:26, Adam Williamson napsal(a):
> > I agree with this, but by the same token, the use suggested by Matej
> > seems against the purpose of updates-testing, as does the original idea
> > in this thread (push some Xorg changes we'd never be happy about putting
> > in stable into it). I also agree with Kevin - maybe we don't need to
> > *disallow* updates sitting in -testing for a long time, but updates
> > sitting there for a long time is an indication of potential issues and
> > it should be flagged for tracking.
> 
> OK, thanks for clearing my internal conflict for me -- now there would
> be no n-2 new packages from me. Simple, easy. (BTW, I always have karma
> switched on, but usually nobody bothers to push karma up, so none of my
> packages got pushed to stable based on its karma).

I should've clarified that as far as new packages go, I don't see a
problem with just pushing them to stable after a few days in -testing as
long as no-one complains. It's quite hard for a new package to *break*
something on a currently-working system without explicit action from the
user, which is the worst thing an update can do.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From airlied at redhat.com  Thu Oct 15 20:48:38 2009
From: airlied at redhat.com (Dave Airlie)
Date: Fri, 16 Oct 2009 06:48:38 +1000
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
	<20091015112630.31b47388@faldor.intranet> 
Message-ID: <1255639718.18175.6.camel@localhost>

On Thu, 2009-10-15 at 17:27 +0200, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > If you know that you would _never_ be happy with a test-update becoming
> > a stable update, then either don't push such a test-update or unpush
> > it (manually or by relying on karma automatism).
> 
> That was my point!
> 
> > However, it could be that you would need to offer a test-update for two or
> > more months before you would get essential feedback that helps with
> > deciding whether it's safe to mark it stable or not.
> 
> So we only disagree about the timelines. IMHO 2 or more months is way too 
> long. You should not need that much time to know whether the update is 
> broken or not! The big problem is that many months is almost 
> indistinguishible from "never" for all practical purposes. If you enabled 
> updates from testing, you're still stuck with no upgrade path unless you 
> stick with testing forever. The main advantage of putting strong time limits 
> on testing is to provide an upgrade path for one-time testers back to the 
> stable stream.

2 months is too long for user apps maybe, for X.org or Mesa from what I
can see for ever probably isn't long enough, its not a matter of how
much time something spends in updates-testing its a matter of how many
people run what is in there and report on it. We get a lot of QA from
the community on the run-in from Beta to GA, however we get nothing at
all even close post-GA, so finding regressions post-GA is close to
impossible without it hitting updates.

you can get lots of +1s easily finding the -1 that matters is hard.

Dave.



From mike at miketc.net  Thu Oct 15 21:20:05 2009
From: mike at miketc.net (Mike Chambers)
Date: Thu, 15 Oct 2009 16:20:05 -0500
Subject: Network not starting during install
Message-ID: <1255641605.5327.3.camel@scrappy.miketc.net>

When trying to install via rawhide the last few days, or at least within
last week or so, the network wouldn't come up, whether via thru
askmethod or normal defaults.  It doesn't matter whether dhcp or static
IP, still doesn't start and you get infinite circle of retry menus after
each attempt.

The hardware that might cause this if its that, is using the forcedeth
driver (built into motherboard).

Anyone else running into this problem?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From jkeating at redhat.com  Thu Oct 15 21:29:18 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Oct 2009 14:29:18 -0700
Subject: Network not starting during install
In-Reply-To: <1255641605.5327.3.camel@scrappy.miketc.net>
References: <1255641605.5327.3.camel@scrappy.miketc.net>
Message-ID: <1255642158.2894.21.camel@localhost.localdomain>

On Thu, 2009-10-15 at 16:20 -0500, Mike Chambers wrote:
> Anyone else running into this problem?

No, in fact I performed many network installs over the past few days, on
i386, x86_64, and ppc, and virt.  A variety of hardware, a variety of
network devices.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From walters at verbum.org  Thu Oct 15 21:56:57 2009
From: walters at verbum.org (Colin Walters)
Date: Thu, 15 Oct 2009 17:56:57 -0400
Subject: Fwd: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
	<20091015112630.31b47388@faldor.intranet> 
	<1255639718.18175.6.camel@localhost>
	
Message-ID: 

On Thu, Oct 15, 2009 at 4:48 PM, Dave Airlie  wrote:
>
> 2 months is too long for user apps maybe, for X.org or Mesa from what I
> can see for ever probably isn't long enough

My guess is that it's relatively easy for a semi-technical person to
be able to map back from a visible problem in a desktop app to a
package name, and finally from a package back into the bodhi comments.

But a lot of issues in the core OS from the kernel up to gnome-desktop
can require extensive knowledge to diagnose, and we just can't expect
as much feedback.

Especially for critpath components that people might be more hesitant
to update. Pages like this one:

https://fedoraproject.org/wiki/How_to_debug_Xorg_problems

are a big step forward, but we may need some way for people to give
feedback about updates without having to debug enough to make a rough
stab at "kernel" or "xorg-x11-drv-intel" or "gnome-power-manager".



From mike at miketc.net  Thu Oct 15 22:37:34 2009
From: mike at miketc.net (Mike Chambers)
Date: Thu, 15 Oct 2009 17:37:34 -0500
Subject: Network not starting during install
In-Reply-To: <1255642158.2894.21.camel@localhost.localdomain>
References: <1255641605.5327.3.camel@scrappy.miketc.net>
	<1255642158.2894.21.camel@localhost.localdomain>
Message-ID: <1255646254.1677.2.camel@scrappy.miketc.net>

On Thu, 2009-10-15 at 14:29 -0700, Jesse Keating wrote:
> On Thu, 2009-10-15 at 16:20 -0500, Mike Chambers wrote:
> > Anyone else running into this problem?
> 
> No, in fact I performed many network installs over the past few days, on
> i386, x86_64, and ppc, and virt.  A variety of hardware, a variety of
> network devices.

Tried a rawhide install few minutes ago and this time tried dhcp from
the get go, and that seemed to work (although if trying static ip from
get go, it fails and so does dhcp afterwards).  But when trying to set
it up via nfs (via askmethod at start of cd), it fails.


-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From dcbw at redhat.com  Thu Oct 15 22:52:18 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 15 Oct 2009 15:52:18 -0700
Subject: Network not starting during install
In-Reply-To: <1255646254.1677.2.camel@scrappy.miketc.net>
References: <1255641605.5327.3.camel@scrappy.miketc.net>
	<1255642158.2894.21.camel@localhost.localdomain>
	<1255646254.1677.2.camel@scrappy.miketc.net>
Message-ID: <1255647138.15031.1.camel@localhost.localdomain>

On Thu, 2009-10-15 at 17:37 -0500, Mike Chambers wrote:
> On Thu, 2009-10-15 at 14:29 -0700, Jesse Keating wrote:
> > On Thu, 2009-10-15 at 16:20 -0500, Mike Chambers wrote:
> > > Anyone else running into this problem?
> > 
> > No, in fact I performed many network installs over the past few days, on
> > i386, x86_64, and ppc, and virt.  A variety of hardware, a variety of
> > network devices.
> 
> Tried a rawhide install few minutes ago and this time tried dhcp from
> the get go, and that seemed to work (although if trying static ip from
> get go, it fails and so does dhcp afterwards).  But when trying to set
> it up via nfs (via askmethod at start of cd), it fails.

Static fails; that's been fixed upstream for about a week but the beta
has been waaaay frozen for longer than that.  It'll drop into rawhide
right after the beta comes out.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c31b3e455414a5a7bf57d9fed1442367e9e4c917

rhbz #528068

Dan




From mmcgrath at redhat.com  Thu Oct 15 22:53:17 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 15 Oct 2009 17:53:17 -0500 (CDT)
Subject: Network not starting during install
In-Reply-To: <1255646254.1677.2.camel@scrappy.miketc.net>
References: <1255641605.5327.3.camel@scrappy.miketc.net>
	<1255642158.2894.21.camel@localhost.localdomain>
	<1255646254.1677.2.camel@scrappy.miketc.net>
Message-ID: 

On Thu, 15 Oct 2009, Mike Chambers wrote:

> On Thu, 2009-10-15 at 14:29 -0700, Jesse Keating wrote:
> > On Thu, 2009-10-15 at 16:20 -0500, Mike Chambers wrote:
> > > Anyone else running into this problem?
> >
> > No, in fact I performed many network installs over the past few days, on
> > i386, x86_64, and ppc, and virt.  A variety of hardware, a variety of
> > network devices.
>
> Tried a rawhide install few minutes ago and this time tried dhcp from
> the get go, and that seemed to work (although if trying static ip from
> get go, it fails and so does dhcp afterwards).  But when trying to set
> it up via nfs (via askmethod at start of cd), it fails.
>

I'm looking at a similar issue now.  Also seeing some strange network
issues with a previously installed rawhide.  In particular puppet throwing
stuff like this:

Oct 15 22:36:29 spin1 puppetd[22440]:
(//Node[spin1]/global/zabbix::agent/File[/usr/local/bin/zabbix]) Failed to
generate additional resources during transaction: Connection Timeout

Seeing similar timeouts to google.com every now and then.

	-Mike



From kevin.kofler at chello.at  Thu Oct 15 23:31:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:31:47 +0200
Subject: Rationale behind _cmake_skip_rpath choice in
	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr>
Message-ID: 

Theodore Papadopoulo wrote:
> I would like to understand why the file macros.cmake as distributed in
> fedora-10 defines:
> %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON

Because otherwise installed binaries would end up with rpaths, even for 
standard library paths. (Probably a bug, I wonder if that got fixed yet.)

It's also quite silly to build the binaries with rpaths first and then edit 
them out when installing, as normally those rpaths shouldn't be needed 
(that's what the .shell wrappers in the uninstalled tree which set 
LD_LIBRARY_PATH are for).

> Disabling the rpath made all the checks to fail, so I added a:
> 
> %define _cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=OFF
> 
> at the beginning of my specfile.

Then the testsuite for that package is broken, they need to run the .shell 
wrappers which CMake creates in the object tree for this purpose, not the 
uninstalled binaries directly. If they use CMake correctly, it'll take care 
of this automatically. But apparently they hardcode the binary to run 
without taking care of this.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 15 23:44:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:44:50 +0200
Subject: Status of geronimo
References: <4AD656D1.2080502@cora.nwra.com>
Message-ID: 

Orion Poplawski wrote:
> Can someone shed light on the status of geronimo in Fedora?  Seems like
> it hasn't managed to build since F11 - and the F11 build was never
> pushed.  There is a geronimo-spec 1.2 in CVS that doesn't compile
> (missing dependencies among other things).  Apache's site has version
> 2.1.4.

I suspect (and the timeline seems to match up) that RH simply stopped caring 
the day they acquired JBoss.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 15 23:49:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:49:36 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	
	<27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>
Message-ID: 

Nicolas Mailhot wrote:
> Please do not ever push untested work to stable just because no one
> complained. If you want testing on older releases you can push it to
> testing but please don't ever promote it.

Sorry, letting updates sit in testing forever is just not an option.

> People who bother to complain when hitting problems are the minority.

It's their loss if they don't report bugs. If it's not in Bugzilla (or Bodhi 
comments), it doesn't exist.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 15 23:54:15 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:54:15 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	 
Message-ID: 

Mat?j Cepl wrote:
> Yes, I know, that's opinion of people around KDE that they don't
> distinguish between Rawhide and updates-testing

That's not true. In KDE SIG:
* we do not push KDE prereleases to updates-testing (nor to the stable 
updates, of course),
* we rarely push application prereleases to updates-testing (and when we do, 
it's with the intention of promoting them to stable, or the final release 
(or a later prerelease) which is just days (not months) away),
* we do not push updates which make major changes (e.g. feature regressions) 
to applications, neither to testing nor stable.

Rawhide does get all that stuff (unless we're in a freeze period), as does 
kde-redhat unstable.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 15 23:56:26 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:56:26 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
	
	<1255633449.2314.53.camel@adam.local.net>
Message-ID: 

Adam Williamson wrote:
> I should've clarified that as far as new packages go, I don't see a
> problem with just pushing them to stable after a few days in -testing as
> long as no-one complains. It's quite hard for a new package to *break*
> something on a currently-working system without explicit action from the
> user, which is the worst thing an update can do.

Right. In fact many packagers just queue new packages directly to stable.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 15 23:45:45 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 01:45:45 +0200
Subject: Are packages w/o necessary kernel modules allowed?
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
	<20091014171958.GB8823@genius.kawo2.rwth-aachen.de>
Message-ID: 

Till Maas wrote:
> IMHO having both in RPMFusion with a proper dependency is the easiest
> way to install it. Having some package with a missing kernel module
> dependency in Fedora would only make it more complicated for other
> repositories that provide the kernel module and can therefore provide a
> package with a unbroken dependency.

I agree.

Putting stuff in without required dependencies is a bad practice, it's 
better to let other repos provide it along with the required dependency.

That said, of course, there's a big can of worms there, in that we ship many 
things without some optional dependencies which most users will want, but 
which we can't legally ship. E.g. xine-lib without xine-lib-extras-
freeworld, libdvdread without libdvdcss, Gnash without the codecs allowing 
it to actually play back Flash videos (not just pure Flash animations) etc. 
But some people will want the apps even without those optional features, so 
pushing them to the third-party repo entirely is probably a bad solution 
(and for libdvdcss in particular, it would mean RPM Fusion would either have 
to reverse its decision not to ship it or a lot of stuff would have to move 
back to Livna, including many programs currently in Fedora). I guess the 
real solution for that particular issue is to use reverse soft dependencies 
("Enhances"), which are being discussed for future versions of RPM.

But if the package does not work at all without the dependency, I really 
don't see what the benefit of shipping it in Fedora, as opposed to the 
repository containing the dependency, is.

Now of course, my personal opinion is that Fedora should just allow external 
kernel modules again, but judging from the feedback about that question 
during the FESCo election campaign, I doubt I'll ever get a majority for 
that in FESCo. And this issue would come up anyway for proprietary kernel 
modules. (E.g. why is libXNVCtrl in Fedora?)

        Kevin Kofler



From bnocera at redhat.com  Fri Oct 16 00:27:27 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Oct 2009 01:27:27 +0100
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255622587.2894.10.camel@localhost.localdomain>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
Message-ID: <1255652847.19029.29.camel@localhost.localdomain>

On Thu, 2009-10-15 at 09:03 -0700, Jesse Keating wrote:
> On Thu, 2009-10-15 at 16:53 +0100, Peter Robinson wrote:
> > Not according to Jesse, even in this thread there seems to be mixed
> > communications. My understanding was from the last FUDCon would be
> > that it would be complete lock down for core stuff with more
> > flexibility for the stuff that obviously isn't mainline and going
> > affect the core stability but then then I've not seen communication
> > either way so I honestly would have no idea.
> > 
> > 
> 
> Thats true for most of the freeze, but when we hit release candidate
> stage we change absolutely nothing.  The problem right now is that there
> is only one repo to publish things into, rawhide, but we have multiple
> things we'd like to publish; pending F12 Beta tree, pending F12 final
> tree, and the F13 tree.  We have to pick one.

FWIW, network-manager-netbook is a release blocker for the moblin spin.
Given how much time we spent with Dan Williams porting
network-manager-netbook to NM 0.8, it would be a great shame if the
moblin spin couldn't get a beta from that...



From jkeating at redhat.com  Fri Oct 16 00:50:44 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Oct 2009 17:50:44 -0700
Subject: tagging of non critical path package into F-12?
In-Reply-To: <1255652847.19029.29.camel@localhost.localdomain>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
Message-ID: <1255654244.2894.98.camel@localhost.localdomain>

On Fri, 2009-10-16 at 01:27 +0100, Bastien Nocera wrote:
> FWIW, network-manager-netbook is a release blocker for the moblin spin.
> Given how much time we spent with Dan Williams porting
> network-manager-netbook to NM 0.8, it would be a great shame if the
> moblin spin couldn't get a beta from that... 

The moblin spin isn't one of the official spins for F12, so there is no
reason why the "beta" for the moblin spin couldn't be made from later
package sets.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jonstanley at gmail.com  Fri Oct 16 00:54:29 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 15 Oct 2009 20:54:29 -0400
Subject: Plan for tomorrow's (20091016) FESCo meeting
Message-ID: 

Sorry for the late agenda - these are the topics for tomorrow's FESCo
meeting at 17:00UTC in #fedora-meeting on irc.freenode.net.

134	Approval needed - zsync needs to ship internal zlib for rsync compatibility
258	Noveau DisplayPort -
https://fedoraproject.org/wiki/Features/NouveauDisplayPort
259	Radeon DisplayPort -
https://fedoraproject.org/wiki/Features/RadeonDisplayPort
260	SIP Witch Domain Telephony -
https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.



From steven at scc.hk  Fri Oct 16 04:58:39 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Fri, 16 Oct 2009 12:58:39 +0800
Subject: Who do I send to  get a package removed because of bad language.
In-Reply-To: <1255654244.2894.98.camel@localhost.localdomain>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
Message-ID: <1255669121.11249.3.camel@mylaptop.myhome>

I recently installed gestikk. And to my horror one of the dialogs said.

(Check Box) F*** off 

No lie, 

So how does one recommend that this be removed.

Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From sundaram at fedoraproject.org  Fri Oct 16 05:18:55 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 10:48:55 +0530
Subject: Status of geronimo
In-Reply-To: 
References: <4AD656D1.2080502@cora.nwra.com> 
Message-ID: <4AD8023F.3040801@fedoraproject.org>

On 10/16/2009 05:14 AM, Kevin Kofler wrote:
> Orion Poplawski wrote:
>> Can someone shed light on the status of geronimo in Fedora?  Seems like
>> it hasn't managed to build since F11 - and the F11 build was never
>> pushed.  There is a geronimo-spec 1.2 in CVS that doesn't compile
>> (missing dependencies among other things).  Apache's site has version
>> 2.1.4.
> 
> I suspect (and the timeline seems to match up) that RH simply stopped caring 
> the day they acquired JBoss.

Red Hat had customers using it long after they acquired JBoss.
Regardless of Red Hat's interests, it doesn't stop anyone else
interested to step in.

Rahul



From karlthered at gmail.com  Fri Oct 16 05:31:03 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Fri, 16 Oct 2009 07:31:03 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255669121.11249.3.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>	<200910150055.18568.cemeyer@u.washington.edu>	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<1255621588.2314.45.camel@adam.local.net>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
Message-ID: <4AD80517.8080907@gmail.com>

Le 16/10/2009 06:58, Steven James Drinnan a ?crit :
> I recently installed gestikk. And to my horror one of the dialogs said.
> 
> (Check Box) F*** off 
> 
> No lie, 
> 
> So how does one recommend that this be removed.
> 
> Steven
> 

File a ticket upstream.
The string itself is in the .glade file, since it's a translatable
string, removing it brutally would not be wise. Anyway, it seems to
entertain most gestikk users. :)

H.



From steven at scc.hk  Fri Oct 16 06:39:21 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Fri, 16 Oct 2009 14:39:21 +0800
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD80517.8080907@gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> <4AD80517.8080907@gmail.com>
Message-ID: <1255675176.11249.6.camel@mylaptop.myhome>

I will file  a ticket.

But my point was the image of Fedora.Does Fedora want be associated with
software vendors that use this type of language?

Steven


On Fri, 2009-10-16 at 07:31 +0200, Ha?kel Gu?mar wrote:
> Le 16/10/2009 06:58, Steven James Drinnan a ?crit :
> > I recently installed gestikk. And to my horror one of the dialogs said.
> > 
> > (Check Box) F*** off 
> > 
> > No lie, 
> > 
> > So how does one recommend that this be removed.
> > 
> > Steven
> > 
> 
> File a ticket upstream.
> The string itself is in the .glade file, since it's a translatable
> string, removing it brutally would not be wise. Anyway, it seems to
> entertain most gestikk users. :)
> 
> H.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From steven at scc.hk  Fri Oct 16 06:39:26 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Fri, 16 Oct 2009 14:39:26 +0800
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD80517.8080907@gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> <4AD80517.8080907@gmail.com>
Message-ID: <1255675191.11249.7.camel@mylaptop.myhome>

I will file  a ticket.

But my point was the image of Fedora.Does Fedora want be associated with
software vendors that use this type of language?

Steven


On Fri, 2009-10-16 at 07:31 +0200, Ha?kel Gu?mar wrote:
> Le 16/10/2009 06:58, Steven James Drinnan a ?crit :
> > I recently installed gestikk. And to my horror one of the dialogs said.
> > 
> > (Check Box) F*** off 
> > 
> > No lie, 
> > 
> > So how does one recommend that this be removed.
> > 
> > Steven
> > 
> 
> File a ticket upstream.
> The string itself is in the .glade file, since it's a translatable
> string, removing it brutally would not be wise. Anyway, it seems to
> entertain most gestikk users. :)
> 
> H.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From sundaram at fedoraproject.org  Fri Oct 16 06:40:29 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 12:10:29 +0530
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255675176.11249.6.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>	<200910150055.18568.cemeyer@u.washington.edu>	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<1255621588.2314.45.camel@adam.local.net>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
Message-ID: <4AD8155D.9080902@fedoraproject.org>

On 10/16/2009 12:09 PM, Steven James Drinnan wrote:
> I will file  a ticket.
> 
> But my point was the image of Fedora.Does Fedora want be associated with
> software vendors that use this type of language?

They aren't usually vendors. They are usually just hobbyists. It would
be good to highlight such issues when they occur however. Thanks for
that.  We have removed some software in the extreme cases (screensavers
scrapping random images off the net which accidentally ends up showing
adult images in office workspaces for example) due to similar problems
but usually it is not necessary.

Rahul



From cemeyer at u.washington.edu  Fri Oct 16 06:44:31 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Thu, 15 Oct 2009 23:44:31 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255675191.11249.7.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<4AD80517.8080907@gmail.com>
	<1255675191.11249.7.camel@mylaptop.myhome>
Message-ID: <200910152344.31909.cemeyer@u.washington.edu>

On Thursday 15 October 2009 11:39:26 pm Steven James Drinnan wrote:
> I will file  a ticket.
> 
> But my point was the image of Fedora.Does Fedora want be associated with
> software vendors that use this type of language?
> 
> Steven

Absolutely! As long as the software is good, I don't care what kind of 
language they use.

Best regards,
-- 
Conrad Meyer 



From lemenkov at gmail.com  Fri Oct 16 06:48:24 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 16 Oct 2009 10:48:24 +0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255675176.11249.6.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
Message-ID: 

2009/10/16 Steven James Drinnan :
> I will file ?a ticket.
>
> But my point was the image of Fedora.Does Fedora want be associated with
> software vendors that use this type of language?

Please, disconnect yourself from the Internet asap, because it's full
of obscene videos, jokes, sexism and so on. And that's great!

-- 
With best regards, Peter Lemenkov.



From nicolas.mailhot at laposte.net  Fri Oct 16 08:27:12 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Oct 2009 10:27:12 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora 
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	 
	<27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>
	
Message-ID: 



Le Ven 16 octobre 2009 01:49, Kevin Kofler a ?crit :
>
> Nicolas Mailhot wrote:
>> Please do not ever push untested work to stable just because no one
>> complained. If you want testing on older releases you can push it to
>> testing but please don't ever promote it.
>
> Sorry, letting updates sit in testing forever is just not an option.

They won't sit in forever, at worst they'll be pushed to users with the next
Fedora release (that will have been tested properly during beta)

>> People who bother to complain when hitting problems are the minority.
>
> It's their loss if they don't report bugs.

No. It's *our* loss if we needlessly frighten of part of our userbase with a
shoot and forget attitude. I know there have been phases in my life when that
kind of release management would have convinced me to never touch Fedora
again. Then I wouldn't have contributed all I did since. And there are also
many cases (in education for example) where someone that do not contribute any
bug reports, will prescribe Fedora to others that will. Except he'll only do
it if he feels the project is solid.

-- 
Nicolas Mailhot




From sundaram at fedoraproject.org  Fri Oct 16 08:33:18 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:03:18 +0530
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <1255633449.2314.53.camel@adam.local.net>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>	<1255043946.18105.3.camel@localhost>	<1255060578.9958.11.camel@code.and.org>
		<20091014112142.5d208c6e@faldor.intranet>	<1255552013.2376.12.camel@adam.local.net>
	
	<1255633449.2314.53.camel@adam.local.net>
Message-ID: <4AD82FCE.2090901@fedoraproject.org>

On 10/16/2009 12:34 AM, Adam Williamson wrote:

> I should've clarified that as far as new packages go, I don't see a
> problem with just pushing them to stable after a few days in -testing as
> long as no-one complains. It's quite hard for a new package to *break*
> something on a currently-working system without explicit action from the
> user, which is the worst thing an update can do.

It is not impossible however and has happened in the past. New packages
can obsolete a existing installed package for example.

Rahul



From nicolas.mailhot at laposte.net  Fri Oct 16 08:37:31 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Oct 2009 10:37:31 +0200
Subject: Status of geronimo
In-Reply-To: <4AD8023F.3040801@fedoraproject.org>
References: <4AD656D1.2080502@cora.nwra.com> 
	<4AD8023F.3040801@fedoraproject.org>
Message-ID: 



Le Ven 16 octobre 2009 07:18, Rahul Sundaram a ?crit :
>
> On 10/16/2009 05:14 AM, Kevin Kofler wrote:
>> Orion Poplawski wrote:
>>> Can someone shed light on the status of geronimo in Fedora?  Seems like
>>> it hasn't managed to build since F11 - and the F11 build was never
>>> pushed.  There is a geronimo-spec 1.2 in CVS that doesn't compile
>>> (missing dependencies among other things).  Apache's site has version
>>> 2.1.4.
>>
>> I suspect (and the timeline seems to match up) that RH simply stopped caring
>> the day they acquired JBoss.
>
> Red Hat had customers using it long after they acquired JBoss.
> Regardless of Red Hat's interests, it doesn't stop anyone else
> interested to step in.

The Geronimo community failed to get involved when Red Hat was here to help
them, I doubt they'll do it now (would be delighted to be proved wrong). In a
few years they'll probably regret it as a major missed opportunity. History
repeats itself there: xen vs kvm, netbeans vs eclipse, geronimo vs jboss... if
you don't jump in the boat while people are ready to help you, they'll find
another partner and you'll be marginalized.

All too often projects think "I'm the only realistic choice, I don't need to
bother, people will have to take me anyway". But with FLOSS, people are free
to vote with their feet (and they do).

-- 
Nicolas Mailhot




From sundaram at fedoraproject.org  Fri Oct 16 08:37:30 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:07:30 +0530
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>	<4AC8B9CC.8050703@bitwagon.com>
	<4ACCA26A.7020808@beam.ltd.uk>	<20091007144410.GA30884@hansolo.jdub.homelinux.org>	<4ACDB6EE.8080606@beam.ltd.uk>
	<20091008125159.GA25579@wolff.to>	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>	<1255043946.18105.3.camel@localhost>	<1255060578.9958.11.camel@code.and.org>	
		
	 
Message-ID: <4AD830CA.3010407@fedoraproject.org>

On 10/16/2009 05:24 AM, Kevin Kofler wrote:
> Mat?j Cepl wrote:
>> Yes, I know, that's opinion of people around KDE that they don't
>> distinguish between Rawhide and updates-testing
> 
> That's not true. In KDE SIG:
> * we do not push KDE prereleases to updates-testing (nor to the stable 
> updates, of course),
> * we rarely push application prereleases to updates-testing (and when we do, 
> it's with the intention of promoting them to stable, or the final release 
> (or a later prerelease) which is just days (not months) away),
> * we do not push updates which make major changes (e.g. feature regressions) 
> to applications, neither to testing nor stable.

Well, I do remember spending hours switching from kmail to thunderbird
in the past because a KDE update in Fedora broke IMAP support and it
stayed broken for quite sometime. Also many of the KDE apps after a
rewrite tend to be quite close to alpha/beta releases for a while rather
than general releases, Amarok being a good example. It is sometimes
pretty tricky to judge.

Rahul



From awilliam at redhat.com  Fri Oct 16 08:42:13 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 16 Oct 2009 01:42:13 -0700
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: <4AD82FCE.2090901@fedoraproject.org>
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net> 
	<1255633449.2314.53.camel@adam.local.net>
	<4AD82FCE.2090901@fedoraproject.org>
Message-ID: <1255682533.2314.58.camel@adam.local.net>

On Fri, 2009-10-16 at 14:03 +0530, Rahul Sundaram wrote:
> On 10/16/2009 12:34 AM, Adam Williamson wrote:
> 
> > I should've clarified that as far as new packages go, I don't see a
> > problem with just pushing them to stable after a few days in -testing as
> > long as no-one complains. It's quite hard for a new package to *break*
> > something on a currently-working system without explicit action from the
> > user, which is the worst thing an update can do.
> 
> It is not impossible however and has happened in the past. New packages
> can obsolete a existing installed package for example.

That's a point, and in the Grand Plan I'd like to have that heavily
flagged up as potentially dangerous by AutoQA...

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From opensource at till.name  Fri Oct 16 08:47:48 2009
From: opensource at till.name (Till Maas)
Date: Fri, 16 Oct 2009 10:47:48 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> <4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
	
Message-ID: <20091016084748.GA8975@genius.kawo2.rwth-aachen.de>

On Fri, Oct 16, 2009 at 10:48:24AM +0400, Peter Lemenkov wrote:

> Please, disconnect yourself from the Internet asap, because it's full
> of obscene videos, jokes, sexism and so on. And that's great!

Even if something is on the internet, this does not meant that it has a
place within the Fedora Community or Collection. Somewhere in the wiki,
there is also some information about this hidden iirc. Especially sexism
or obscenity does not have its place within Fedora, as well as racism
and discrimination against anything at all.

You may also want to think about whether you really find it great that
there's sexism on the internet, because you might have confused it with
sexual content.

From Wikipedia[0], the free encyclopedia:

| Sexism, a term coined in the mid-20th century,[1] is the belief or
| attitude that one gender or sex is inferior to, less competent, or less
| valuable than the other.

I don't think it's great, that there is sexism anywhere.

Regards
Till

[0] http://en.wikipedia.org/wiki/Sexism
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From lemenkov at gmail.com  Fri Oct 16 08:59:41 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 16 Oct 2009 12:59:41 +0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091016084748.GA8975@genius.kawo2.rwth-aachen.de>
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
	
	<20091016084748.GA8975@genius.kawo2.rwth-aachen.de>
Message-ID: 

2009/10/16 Till Maas :

> You may also want to think about whether you really find it great that
> there's sexism on the internet, because you might have confused it with
> sexual content.

No, I meant sexism. I thought, that sexism is modern trend nowadays,
since almost every OSS-related rss-feed is full of "Sexism in OSS"
articles.

And yes, I forgot about racism, also.

You see, I personally prefer to live in the society with some level of
aggressively thinking and speaking minorities, rather than in dark
ages of censorship, brainwashing and hypocrisy.

-- 
With best regards, Peter Lemenkov.



From sundaram at fedoraproject.org  Fri Oct 16 08:59:07 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:29:07 +0530
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>	<4AD80517.8080907@gmail.com>	<1255675176.11249.6.camel@mylaptop.myhome>		<20091016084748.GA8975@genius.kawo2.rwth-aachen.de>
	
Message-ID: <4AD835DB.3090306@fedoraproject.org>

On 10/16/2009 02:29 PM, Peter Lemenkov wrote:

> You see, I personally prefer to live in the society with some level of
> aggressively thinking and speaking minorities, rather than in dark
> ages of censorship, brainwashing and hypocrisy.

You seem to be equating "aggressive thinking" with sexism and racism and
censorship with a requirement for civil and decent behaviour in
communities.

Rahul



From lemenkov at gmail.com  Fri Oct 16 09:10:09 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 16 Oct 2009 13:10:09 +0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD835DB.3090306@fedoraproject.org>
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
	
	<20091016084748.GA8975@genius.kawo2.rwth-aachen.de>
	
	<4AD835DB.3090306@fedoraproject.org>
Message-ID: 

2009/10/16 Rahul Sundaram :
> On 10/16/2009 02:29 PM, Peter Lemenkov wrote:
>
>> You see, I personally prefer to live in the society with some level of
>> aggressively thinking and speaking minorities, rather than in dark
>> ages of censorship, brainwashing and hypocrisy.

> You seem to be equating "aggressive thinking" with sexism and racism and
> censorship with a requirement for civil and decent behaviour in
> communities.

Civil and decent behavior is to be tolerant to others, right? So,
please, be tolerant to sexists/racists/-ists.

-- 
With best regards, Peter Lemenkov.



From sundaram at fedoraproject.org  Fri Oct 16 09:12:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:42:26 +0530
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	
	<1255652847.19029.29.camel@localhost.localdomain>	
	<1255654244.2894.98.camel@localhost.localdomain>	
	<1255669121.11249.3.camel@mylaptop.myhome>	
	<4AD80517.8080907@gmail.com>	
	<1255675176.11249.6.camel@mylaptop.myhome>	
		
	<20091016084748.GA8975@genius.kawo2.rwth-aachen.de>	
		
	<4AD835DB.3090306@fedoraproject.org>
	
Message-ID: <4AD838FA.8060004@fedoraproject.org>

On 10/16/2009 02:40 PM, Peter Lemenkov wrote:

> Civil and decent behavior is to be tolerant to others, right? So,
> please, be tolerant to sexists/racists/-ists.

Quite the opposite. You are really confused about what being civil and
decent actually means. If someone is being sexist or racist towards
others, NOT tolerating it is decent behaviour.

Rahul



From sundaram at fedoraproject.org  Fri Oct 16 09:25:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:55:41 +0530
Subject: What to do if a deprecated license is used? nescc java files
 with	intel license
In-Reply-To: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
Message-ID: <4AD83C15.4020104@fedoraproject.org>

On 10/15/2009 07:32 PM, Till Maas wrote:
> Hiyas,
> 
> I looked into packaging the nesc compiler
> (https://sourceforge.net/projects/nescc) and I noticed that it uses the
> deprecated intel license for some java files:
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-LICENSE?revision=1.1&view=markup
> 
> I opened a bug in their bug tracking system for this:
> https://sourceforge.net/tracker/?func=detail&aid=2879881&group_id=56288&atid=480036
> 
> The Intel license is OSI approved, but deprecated and therefore
> currently not allowed for Fedora afaics:
> https://fedoraproject.org/wiki/Licensing#Bad_Licenses
> Btw. it's a "should not", so maybe it is ok, nevertheless. Or it should
> be a "must not" guideline, e.g. because it also affects non OSI approved
> liceneses afaics.

Wait for upstream to convert into a good license.

Rahul



From sundaram at fedoraproject.org  Fri Oct 16 09:28:51 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 14:58:51 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: 
References: <4AD15A0F.9080708@pobox.com>
	<4AD17515.4070606@cchtml.com>	<20091011084154.GA1481@tutu.torimasen.com>	<4AD20495.1000006@cchtml.com>
	<4AD20578.4050404@fedoraproject.org>	<4AD208BF.5040501@cchtml.com>
	<4AD20BE3.4030709@fedoraproject.org>	<4AD4170C.40609@redhat.com>
	<4AD421A1.6060609@pobox.com>	<4AD486F9.5040300@redhat.com>
	<4AD5C235.9030608@RedHat.com>	<4AD5C867.4080802@pobox.com>
			<1255530711.4148.413.camel@localhost.localdomain>		<1255532025.4148.414.camel@localhost.localdomain>
	
Message-ID: <4AD83CD3.9080005@fedoraproject.org>

On 10/15/2009 03:23 PM, Benny Amorsen wrote:
> Jesse Keating  writes:
> 
>> And that's a people problem more than a process problem.  If nobody
>> tests it in updates-testing, then how is the maintainer to know that it
>> is problematic?  Certainly not solvable with even more repos for testing
>> content...
> 
> I ran updates-testing for a while, but it didn't result in me writing
> any bug reports. I wasn't particularly aware of whether a package came
> from updates-testing, so that it was worth spending a little bit of
> energy testing that particular package.
> 
> Would it be possible to make a little application which pops up on login
> or every day (whichever comes first) saying "These applications are new
> in updates-testing, would you like to help testing one?". Then you could
> pick one and give it a try, and perhaps a few days later there would be
> a pop up asking how it went?
> 
> Strictly opt-in, of course.

It has been suggested before. At one point, Richard Hughes pitched it in
the packagekit list and they didn't like it and so he wanted to write a
separate app but nothing has come out of it so far.

Rahul



From hughsient at gmail.com  Fri Oct 16 09:37:47 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Oct 2009 10:37:47 +0100
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD83CD3.9080005@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com> 
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	 <4AD83CD3.9080005@fedoraproject.org>
Message-ID: <15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>

2009/10/16 Rahul Sundaram :
> It has been suggested before. At one point, Richard Hughes pitched it in
> the packagekit list and they didn't like it and so he wanted to write a
> separate app but nothing has come out of it so far.

Yes, I think it makes a lot of sense to write something like this, but
I fear it would be very Fedora specific and probably not suitable for
"upstream" PackageKit.

It would however, be a great google summer of code project, which I
would be prepared to mentor.

Richard.



From sundaram at fedoraproject.org  Fri Oct 16 09:36:33 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 15:06:33 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD5C235.9030608@RedHat.com>	
	<4AD5C867.4080802@pobox.com>
		
		
	<1255530711.4148.413.camel@localhost.localdomain>	
		
	<1255532025.4148.414.camel@localhost.localdomain>	
	
	<4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
Message-ID: <4AD83EA1.3030505@fedoraproject.org>

On 10/16/2009 03:07 PM, Richard Hughes wrote:

>> It has been suggested before. At one point, Richard Hughes pitched it in
>> the packagekit list and they didn't like it and so he wanted to write a
>> separate app but nothing has come out of it so far.
> 
> Yes, I think it makes a lot of sense to write something like this, but
> I fear it would be very Fedora specific and probably not suitable for
> "upstream" PackageKit.

Couldn't you hook this into PackageKit and leave it disabled by default?

Rahul



From sanjay.ankur at gmail.com  Fri Oct 16 09:47:01 2009
From: sanjay.ankur at gmail.com (Ankur Sinha)
Date: Fri, 16 Oct 2009 15:17:01 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com> <4AD5C235.9030608@RedHat.com>
	<4AD5C867.4080802@pobox.com> 
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	 <4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
Message-ID: <1255686421.2717.2.camel@localhost>



> 
> It would however, be a great google summer of code project, which I
> would be prepared to mentor.
> 
> Richard.
> 

Richard, I'd like to take this up. What do I need to know/learn? 

btw, I'm a sort of a newbie at application development though.

-- 
regards,

Ankur



From opensource at till.name  Fri Oct 16 10:29:07 2009
From: opensource at till.name (Till Maas)
Date: Fri, 16 Oct 2009 12:29:07 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> <4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
	
	<20091016084748.GA8975@genius.kawo2.rwth-aachen.de>
	
	<4AD835DB.3090306@fedoraproject.org>
	
Message-ID: <20091016102907.GB8975@genius.kawo2.rwth-aachen.de>

On Fri, Oct 16, 2009 at 01:10:09PM +0400, Peter Lemenkov wrote:
> 2009/10/16 Rahul Sundaram :
> > On 10/16/2009 02:29 PM, Peter Lemenkov wrote:
> >
> >> You see, I personally prefer to live in the society with some level of
> >> aggressively thinking and speaking minorities, rather than in dark
> >> ages of censorship, brainwashing and hypocrisy.
> 
> > You seem to be equating "aggressive thinking" with sexism and racism and
> > censorship with a requirement for civil and decent behaviour in
> > communities.
> 
> Civil and decent behavior is to be tolerant to others, right? So,
> please, be tolerant to sexists/racists/-ists.

Being tolerant does not mean to support or accept intolerant behaviour,
but not to discriminate against them because of their sex, race or other
characteristics. Nobody here is suggesting that racists or sexists
should be discriminated against because of their sex or race. But it
does not mean that their intolerant behaviour will be accepted.

Also racism and sexism do not contradict to censorship and brainwashing
but they support each other.

Nevertheless, if you prefer a racist and sexist environment, you are
wrong here in the Fedora Project.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From hughsient at gmail.com  Fri Oct 16 10:42:06 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Oct 2009 11:42:06 +0100
Subject: thunderbird upgrade - wtf?
In-Reply-To: <4AD83EA1.3030505@fedoraproject.org>
References: <4AD15A0F.9080708@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	 <4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
	<4AD83EA1.3030505@fedoraproject.org>
Message-ID: <15e53e180910160342o1f9ab61am62492f73f0d72398@mail.gmail.com>

2009/10/16 Rahul Sundaram :
> Couldn't you hook this into PackageKit and leave it disabled by default?

Well, in one sense it's entirely fedora specific (updates testing
repos, bohdi, and koji) and in other ways it's a problem all the
distros are facing, in that test updates get little to no coverage.

Anyway, by PackageKit we really mean kpackagekit and gnome-packagekit,
as the PackageKit bits are already usable, e.g.

* Enable this testing repo
* Get the updates from this repo
* Install them
* Wait a week
* Ask user for feedback, and point them at the bohdi page.

Richard.



From sundaram at fedoraproject.org  Fri Oct 16 10:42:51 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Oct 2009 16:12:51 +0530
Subject: thunderbird upgrade - wtf?
In-Reply-To: <15e53e180910160342o1f9ab61am62492f73f0d72398@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com>	
		
		
	<1255530711.4148.413.camel@localhost.localdomain>	
		
	<1255532025.4148.414.camel@localhost.localdomain>	
	
	<4AD83CD3.9080005@fedoraproject.org>	
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>	
	<4AD83EA1.3030505@fedoraproject.org>
	<15e53e180910160342o1f9ab61am62492f73f0d72398@mail.gmail.com>
Message-ID: <4AD84E2B.4040008@fedoraproject.org>

On 10/16/2009 04:12 PM, Richard Hughes wrote:

>> Couldn't you hook this into PackageKit and leave it disabled by default?
> 
> Well, in one sense it's entirely fedora specific (updates testing
> repos, bohdi, and koji) and in other ways it's a problem all the
> distros are facing, in that test updates get little to no coverage.

Yeah, which is why I suggested to expose this in the frontends by
default in Fedora, leaving it disabled upstream. We need it. Other
distributions can make their own choices.

Rahul



From hughsient at gmail.com  Fri Oct 16 10:53:21 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Oct 2009 11:53:21 +0100
Subject: thunderbird upgrade - wtf?
In-Reply-To: <1255686421.2717.2.camel@localhost>
References: <4AD15A0F.9080708@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	 <4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
	<1255686421.2717.2.camel@localhost>
Message-ID: <15e53e180910160353y1e8ecca8yf9edb91720a2b065@mail.gmail.com>

2009/10/16 Ankur Sinha :
> Richard, I'd like to take this up. What do I need to know/learn?
> btw, I'm a sort of a newbie at application development though.

Well, the application development is perhaps 10% of the problem. 90%
of the problem is identifying the core problem, working out how users
are going to interact with this, and also how to avoid spamming the
user about test-updates they don't care about.

For instance, the way I could see this work is:

* A checkbox in gpk-update-viewer (or gpk-prefs) with [X] Install test
updates, not suitable for general users
* A GObject that is compiled into gpk-update-icon (say,
GpkTestUpdates) that monitors the software log and prompts for
feedback a week or so after updating
* A session database of software we've already prompted for, or
software we are interested in

They'rd also need to be some policy choices:

* How long do we give the user to test the software? Wait until the
software is run for the first time? The third time?
* Where do we direct the user to? NULL would need to be configured in
GConf by default, and then patched by distros. Or we use
/etc/PackageKit/vendor.conf and some clever re-writing to get the
correct URL
* Do we pop up a bubble for every bit of software (would get really
irritating after a while) or allow the user to say "never for this
package"
* Do we exclude some software? -devel? -debuginfo?

So, as soon as you start working on a complete specification, there
are lots of problems. The actual coding part would probably only take
a couple of days (few hours for someone comfortable with the PK
design), but the working-out-how-to-do-it part could take quite a few
weeks.

Join the PackageKit mailing list, and write a proposal or just an
ideas dump. Bear in mind it needs to be clear enough so the KDE guys
can re-implement it using their systems. I can discuss things on the
PK mailing list with whoever wants to contribute.

Richard.



From jmoskovc at redhat.com  Fri Oct 16 11:16:33 2009
From: jmoskovc at redhat.com (Jiri Moskovcak)
Date: Fri, 16 Oct 2009 13:16:33 +0200
Subject: removing icqnd from licq package
Message-ID: <4AD85611.9040800@redhat.com>

Hi,
I'd like to remove icqnd (the gtk gui for licq) from licq package. It's 
unmaintained for a few years and I think there are better gtk clients 
for icq so it doesn't worth the effort of maintaining it and make it 
compile with the latest licq. So if anyone has some arguments why to 
keep it then let me know, otherwise I'll update the licq to latest 
version and drop the icqnd - I'm also willing to give this package to 
another interested developer.

Jirka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmoskovc.vcf
Type: text/x-vcard
Size: 126 bytes
Desc: not available
URL: 

From rawhide at fedoraproject.org  Fri Oct 16 11:49:54 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 16 Oct 2009 11:49:54 +0000
Subject: rawhide report: 20091016 changes
Message-ID: <20091016114954.GA26569@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 16 06:15:07 UTC 2009

Broken deps for i386
----------------------------------------------------------
	sugar-toolkit-0.86.1-1.fc12.i686 requires python-json



Broken deps for x86_64
----------------------------------------------------------
	sugar-toolkit-0.86.1-1.fc12.x86_64 requires python-json



Broken deps for ppc
----------------------------------------------------------
	sugar-toolkit-0.86.1-1.fc12.ppc requires python-json



Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	sugar-toolkit-0.86.1-1.fc12.ppc64 requires python-json



New package mutrace
        Mutex Tracer
New package sks
        Synchronizing Key Server
New package uxlaunch
        A small and quick interface to start the Moblin Desktop
Updated Packages:

DeviceKit-disks-007-5.fc12
--------------------------
* Tue Oct 13 2009 Matthias Clasen  - 007-5.fc12
- Give media players better icons


NetworkManager-openconnect-0.7.996-4.git20090921.fc12
-----------------------------------------------------
* Mon Oct 05 2009 Dan Williams  - 1:0.7.996-4.git20090921
- Rebuild for updated NetworkManager


NetworkManager-pptp-0.7.996-4.git20090921.fc12
----------------------------------------------
* Mon Oct 05 2009 Dan Williams  - 1:0.7.996-4.git20090921
- Rebuild for updated NetworkManager


amanda-2.6.0p2-14.fc12
----------------------
* Thu Oct 15 2009 Daniel Novotny  2.6.0p2-14
- add amanda user to group "tape" (#529159)


anerley-0.1.6-1.fc12
--------------------
* Sun Oct 11 2009 Peter Robinson  0.1.6-1
- New upstream 0.1.6 release

* Sat Oct 10 2009 Peter Robinson  0.1.5-1
- New upstream 0.1.5 release


anjal-0.1.0-0.13.20091012gitbf7a3d2.fc12
----------------------------------------
* Mon Oct 12 2009 Peter Robinson  0.1.0-0.13
- New git snapshot, lots of updated translations, nearing first release


bisho-0.15-1.fc12
-----------------
* Wed Oct 14 2009 Peter Robinson  0.15-1
- New upstream 0.15 release

* Mon Oct 12 2009 Peter Robinson  0.14-1
- New upstream 0.14 release

* Mon Oct 12 2009 Peter Robinson  0.14-2
- Add new nbtk dep


eclipse-3.5.1-1.fc12
--------------------
* Tue Oct 13 2009 Alexander Kurtakov  1:3.5.1-1
- Update to 3.5.1.
- Fixes crash issue with gtk 2.18.


eclipse-photran-5.0.0-0.1.200910081739.fc12
-------------------------------------------
* Wed Oct 14 2009 Orion Poplawski  - 5.0.0-0.1.200910081739
- Update to 5.0.0 pre-release 200910081739
- Drop outline patch fixed upstream


empathy-2.28.0.1-2.fc12
-----------------------
* Tue Oct 13 2009 Brian Pepple  - 2.28.0.1-2
- Require tp-idle and tp-butterfly.


etoys-4.0.2332-1.fc12
---------------------
* Sun Oct 11 2009 Steven M. Parrish  - 4.0.2332-1
- lastest upstream release 4.0.2332


gnome-power-manager-2.28.0-2.fc12
---------------------------------
* Tue Oct 13 2009 Matthias Clasen  - 2.28.0-2
- Fix possible segfault


gstreamer-plugins-base-0.10.25-2.fc12
-------------------------------------
* Tue Oct 13 2009 Bastien Nocera  0.10.25-2
- Add patches to fix some playbin2 bugs (#518880)


gvfs-1.4.0-6.fc12
-----------------
* Wed Oct 14 2009 Bastien Nocera  1.4.0-6
- Fix crasher in ObexFTP (#528181)

* Fri Oct 09 2009 Tomas Bzatek  - 1.4.0-5
- Don't always overwrite on trash restore
- Separate "Safely Remove Drive" from "Eject"
- Don't advertise can_poll for drives not using removable media
- Disallow mounting empty drives
- Disallow ejecting empty drives
- Silently drop eject error messages when detaching drive

* Thu Oct 08 2009 Tomas Bzatek  - 1.4.0-4
- Fix Nautilus not displaying friendly icons for SSH-connected system (#526892)
- Actually apply the logical partitions patch


icecream-0.9.4-5.fc12
---------------------
* Mon Oct 12 2009 Michal Schmidt  0.9.4-5
- Fix failure to build native environment in SELinux enforcing mode.
- 'cvs rm ...' unused patches.


kdesdk-4.3.2-2.fc12
-------------------
* Sun Oct 11 2009 Kevin Kofler  - 4.3.2-2
- Fix Kompare diff parsing regression (due to a typo in a bugfix)


liferea-1.6.0-1.fc12
--------------------
* Sat Oct 10 2009 Steven M. Parrish  - 1.6.0-1
- Add additional functionality #527873


moblin-icon-theme-0.8-1.fc12
----------------------------
* Mon Oct 12 2009 Peter Robinson  0.8-1
- New upstream 0.8 release


moblin-panel-myzone-0.0.8-1.fc12
--------------------------------
* Sat Oct 10 2009 Peter Robinson  0.0.8-1
- New upstream 0.0.8 release


moblin-panel-people-0.0.6-1.fc12
--------------------------------
* Tue Oct 13 2009 Peter Robinson  0.0.6-1
- New upstream 0.0.6 release

* Mon Oct 12 2009 Peter Robinson  0.0.5-1
- New upstream 0.0.5 release

* Sat Oct 10 2009 Peter Robinson  0.0.4-1
- New upstream 0.0.4 release


mod_fcgid-2.3.4-1.fc12
----------------------
* Mon Oct 12 2009 Paul Howarth  2.3.4-1
- Update to 2.3.4 (configuration directives changed again)
- Add fixconf.sed script for config file directives update

* Fri Sep 25 2009 Paul Howarth  2.3.1-2.20090925svn818270
- Update to svn revision 818270
- DESTDIR and header detection patches upstreamed
- Build SELinux policy module for EL-5; support in EL-5.3 is incomplete and
  will be fixed in EL-5.5 (#519369)
- Drop aliases httpd_sys_content_r{a,o,w}_t -> httpd_fastcgi_content_r{a,o,w}_t
  from pre-2.5 SElinux policy module as these types aren't defined there

* Wed Sep 23 2009 Paul Howarth  2.3.1-1.20090923svn817978
- Update to post-2.3.1 svn snapshot
- Upstream moved to apache.org
- License changed to ASL 2.0
- Use FCGID-prefixed config file options (old ones deprecated)
- Lots of documentation changes
- Renumber sources
- Don't defer to mod_fastcgi if both are present
- Drop gawk buildreq
- Add patches fixing RPM build issues (DESTDIR support, header detection)


mojito-0.21.3-1.fc12
--------------------
* Sat Oct 10 2009 Peter Robinson  0.21.3-1
- Update to 0.21.3


nbtk-1.1.7-1.fc12
-----------------
* Sat Oct 10 2009 Peter Robinson  1.1.7-1
- New upstream 1.1.7 release


network-manager-netbook-1.3.1-0.2.fc12
--------------------------------------
* Sun Oct 11 2009 Peter Robinson  1.3.1-0.2
- Rebuild against latest NetworkManager release


paprefs-0.9.9-4.fc12
--------------------
* Wed Oct 14 2009 Lennart Poettering  0.9.9-3
- Rebuild to make sure we look for /usr/lib/pulse-0.9.19/modules/xxx instead of /usr/lib/pulse-0.9.16/modules/xxx

* Wed Oct 14 2009 Lennart Poettering  0.9.9-4
- Fix mistag


pavucontrol-0.9.10-1.fc12
-------------------------
* Wed Oct 14 2009 Lennart Poettering  0.9.10-1
- New upstream 0.9.10


phpMyAdmin-3.2.2.1-1.fc12
-------------------------
* Tue Oct 13 2009 Robert Scheck  3.2.2.1-1
- Upstream released 3.2.2.1 (#528769)
- Require php-mcrypt for cookie authentication (#526979)


python-paramiko-1.7.5-2.fc12
----------------------------
* Tue Oct 13 2009 Jeremy Katz  - 1.7.5-2
- Fix race condition (#526341)


readahead-1.5.4-1.fc12
----------------------
* Tue Oct 13 2009 Harald Hoyer  1.5.4-1
- cleanup readahead-collector audit rules
- translation update


rest-0.6.1-1.fc12
-----------------
* Sat Oct 10 2009 Peter Robinson  0.6.1-1
- New upstream 0.6.1 release


rhythmbox-0.12.5-6.fc12
-----------------------
* Tue Oct 13 2009 Bastien Nocera  0.12.5-6
- Fix DAAP plugin linkage


ruby-1.8.6.369-5.fc12
---------------------
* Wed Oct 14 2009 Mamoru Tasaka  - 1.8.6.369-4
- Fix the search path of ri command for ri manuals installed with gem
  (bug 528787)

* Wed Oct 14 2009 Mamoru Tasaka  - 1.8.6.369-5
- Much better idea for Patch31 provided by Akira TAGOH 


smc-fonts-04.2-2.fc12
---------------------
* Wed Oct 14 2009 Pravin Satpute  04.2-2
- bugfix 523454


sugar-0.86.2-1.fc12
-------------------
* Thu Oct 08 2009 Simon Schampijer  - 0.86.2-1
- Not able to make screenshot #1464
- debug logs for the presence service and connection managers not 
working #927
- Not able to stop activities #1444

* Thu Oct 01 2009 Simon Schampijer  - 0.86.1-1
- Activities tray doesn't reflect well on switching between windows if 
there are non-sugar ones #1444
- sugar-emulator starts sugar out of Xephyr #1432
- Sugar resets gnome's cursor #1433
- Pass timestamp to gdk.Window.focus() on shell startup #1451
- Starting/resuming an entry from Journal shows wrong colours #1421
- Control panel resizing issue (for non en_US languages) #308
- Do not start title editing for non-ds objects #1411
- Shutdown/Reboot fails when multiple users are logged in #246
- Package sugar-desktop icon #1139
- Present windows in non-active process #1423

* Thu Oct 01 2009 Simon Schampijer  - 0.86.1-2
- added sugar-xo.svg icon to the emulator package

* Thu Oct 01 2009 Simon Schampijer  - 0.86.1-3
- typo


sugar-browse-114-1.fc12
-----------------------
* Thu Oct 01 2009 Simon Schampijer  - 113-1
- Better naming when uploading an entry #901 (Aleksey)
- Listen for mouseout event to popdown palette #1314
- Updated translations

* Thu Oct 01 2009 Simon Schampijer  - 114-1
- Updated translations


sugar-datastore-0.86.1-1.fc12
-----------------------------
* Thu Oct 01 2009 Simon Schampijer  - 0.86.1-1
- Screenshot file is not deleted #1445


sugar-imageviewer-14-2.fc12
---------------------------
* Sun Oct 11 2009 Sebastian Dziallas  - 14-1
- Updated Vietnamese translation

* Sun Oct 11 2009 Sebastian Dziallas  - 14-2
- Simple rebuild fixing dependency issue


sugar-read-76-2.fc12
--------------------
* Sun Oct 11 2009 Sebastian Dziallas  - 76-1
- Fix pagination for IA Epubs
- Updated Vietnamese translations

* Sun Oct 11 2009 Simon Schampijer  - 76-2
- rebuild for sugar-toolkit


sugar-terminal-28-1.fc12
------------------------
* Sun Oct 11 2009 Simon Schampijer  - 28-1
* Updated Vietnamese translations

* Thu Oct 01 2009 Simon Schampijer  - 27-1
- Make canvas emit motion-notify-event during pointer motion (dslo#1402) (Aleksey Lim)
- Fix typo (dslo#1356) (Aleksey Lim)
- Updated translations for French, German, Portuguese and Mongolian


sugar-toolkit-0.86.1-1.fc12
---------------------------
* Thu Oct 01 2009 Simon Schampijer  - 0.86.1-1
- Do no use random color if metadata color is not valid #1435
- Shutdown/Reboot fails when multiple users are logged in #246
- Present windows in non-active process #1423


sugar-turtleart-72-1.fc12
-------------------------
* Sun Oct 11 2009 Simon Schampijer  - 72-1
- latest upstream release

* Thu Oct 01 2009 Simon Schampijer  - 69-1
- chmod +x svg factory
- added missing import gettext from talogo.py
- renamed xo-man to xo-child
- caught missing attribute when running from outside of Sugar
- new translations/artwork for de, fr, es, it
- added translator comments
- fixed several bugs in export to Logo code


sugar-write-68-1.fc12
---------------------
* Thu Oct 01 2009 Simon Schampijer  - 68-1
- updated translations


totem-pl-parser-2.28.1-2.fc12
-----------------------------
* Thu Oct 15 2009 Bastien Nocera  2.28.1-2
- Fix crasher when parsing multiple XML-ish playlists in Rhythmbox


xinetd-2.3.14-26.fc12
---------------------
* Mon Oct 12 2009 Jan Zeleny  - 2:2.3.14-26
- correction of init script (LSB compliance - #528154)


Summary:
Added Packages: 3
Removed Packages: 0
Modified Packages: 44



From tcallawa at redhat.com  Fri Oct 16 14:58:16 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Oct 2009 10:58:16 -0400
Subject: What to do if a deprecated license is used? nescc java files
 with	intel license
In-Reply-To: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
Message-ID: <4AD88A08.4000807@redhat.com>

On 10/15/2009 10:02 AM, Till Maas wrote:
> Hiyas,
> 
> I looked into packaging the nesc compiler
> (https://sourceforge.net/projects/nescc) and I noticed that it uses the
> deprecated intel license for some java files:
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-LICENSE?revision=1.1&view=markup
> 
> I opened a bug in their bug tracking system for this:
> https://sourceforge.net/tracker/?func=detail&aid=2879881&group_id=56288&atid=480036
> 
> The Intel license is OSI approved, but deprecated and therefore
> currently not allowed for Fedora afaics:
> https://fedoraproject.org/wiki/Licensing#Bad_Licenses
> Btw. it's a "should not", so maybe it is ok, nevertheless. Or it should
> be a "must not" guideline, e.g. because it also affects non OSI approved
> liceneses afaics.

I've updated the wording there to clarify that no Fedora package may use
anything under a "Bad" License.

~spot



From mike.cloaked at gmail.com  Fri Oct 16 15:16:56 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Fri, 16 Oct 2009 15:16:56 +0000 (UTC)
Subject: thunderbird upgrade - wtf?
References: <4AD15A0F.9080708@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	
	<4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
	<4AD83EA1.3030505@fedoraproject.org>
	<15e53e180910160342o1f9ab61am62492f73f0d72398@mail.gmail.com>
Message-ID: 

Richard Hughes  gmail.com> writes:

> Anyway, by PackageKit we really mean kpackagekit and gnome-packagekit,
> as the PackageKit bits are already usable, e.g.
> 
> * Enable this testing repo
> * Get the updates from this repo
> * Install them
> * Wait a week
> * Ask user for feedback, and point them at the bohdi page.
> 
> Richard.

The basic philosophy here does sound workable and appealing to me as both a user
and tester, and also fits with the "cutting edge" Fedora model, and seems to me
might get a significant number of users more aware of how to test packages
(presumably there would be some warning that 'this is a package still being
tested and may not work as expected' or somesuch (like the 'eats babies' warning
for rawhide)? 






From notting at redhat.com  Fri Oct 16 15:19:46 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Oct 2009 11:19:46 -0400
Subject: rawhide report: 20091016 changes
In-Reply-To: <20091016114954.GA26569@releng2.fedora.phx.redhat.com>
References: <20091016114954.GA26569@releng2.fedora.phx.redhat.com>
Message-ID: <20091016151945.GA16446@nostromo.devel.redhat.com>

Rawhide Report (rawhide at fedoraproject.org) said: 
> 	sugar-toolkit-0.86.1-1.fc12.i686 requires python-json

This was a tagging mixup. It will be fixed.

Bill



From notting at redhat.com  Fri Oct 16 15:24:28 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Oct 2009 11:24:28 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255675191.11249.7.camel@mylaptop.myhome>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675191.11249.7.camel@mylaptop.myhome>
Message-ID: <20091016152427.GB16446@nostromo.devel.redhat.com>

Steven James Drinnan (steven at scc.hk) said: 
> I will file  a ticket.
> 
> But my point was the image of Fedora.Does Fedora want be associated with
> software vendors that use this type of language?

There are worse things in the package collection, alas, depending on your
point of view.

In any case, gestikk is not installed by default, and is not listed in a group
to be selected in the GUI. If upstream maintains this sort of attitude
towards the strings they ship, I'm fairly sure it never will be installed by
default.

Bill



From rjones at redhat.com  Fri Oct 16 15:47:24 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 16 Oct 2009 16:47:24 +0100
Subject: Retiring package: ocaml-camlimages
Message-ID: <20091016154724.GA15920@amd.home.annexia.org>

Just a note to say that I'm going to retire the package
ocaml-camlimages and ask it to be removed from Fedora.

Reasons:

(a) Series of security problems have arisen with the C code
for loading images[1].

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2295
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2660
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3296

(b) Upstream totally unresponsive, despite repeated appeals.

(c) Nothing else in Fedora requires it.

(d) There are alternate ways to do image processing.

Rich.

[1] We fixed one today, then discovered another one which is
still not fixed.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 79 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From awilliam at redhat.com  Fri Oct 16 17:10:51 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 16 Oct 2009 10:10:51 -0700
Subject: thunderbird upgrade - wtf?
In-Reply-To: <15e53e180910160353y1e8ecca8yf9edb91720a2b065@mail.gmail.com>
References: <4AD15A0F.9080708@pobox.com>
	
	
	<1255530711.4148.413.camel@localhost.localdomain>
	
	<1255532025.4148.414.camel@localhost.localdomain>
	 <4AD83CD3.9080005@fedoraproject.org>
	<15e53e180910160237k1a3c6770mfeabfe0e80071fb8@mail.gmail.com>
	<1255686421.2717.2.camel@localhost>
	<15e53e180910160353y1e8ecca8yf9edb91720a2b065@mail.gmail.com>
Message-ID: <1255713051.2314.79.camel@adam.local.net>

On Fri, 2009-10-16 at 11:53 +0100, Richard Hughes wrote:
> * How long do we give the user to test the software? Wait until the
> software is run for the first time? The third time? 

I don't think you can determine that. What if it's not something that
gets 'run' at all, also?

I'm thinking, bizarrely, of something like eBay's feedback interface:
every time you run a package-management app after installing testing
updates, it has an unobtrusive reminder somewhere that you need to leave
feedback on X packages, but it's up to the user to click the reminder
(or whatever) to initiate the feedback-leaving-process.

If you want to pop up bubbles it could just be done every X days, again
with the 'you need to leave feedback for X packages' text. I'm split on
whether it's a good idea at all, though.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From a.badger at gmail.com  Fri Oct 16 17:19:14 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 16 Oct 2009 10:19:14 -0700
Subject: Who do I send to  get a package removed because of bad language.
In-Reply-To: <1255669121.11249.3.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
Message-ID: <20091016171914.GA23555@clingman.lan>

On Fri, Oct 16, 2009 at 12:58:39PM +0800, Steven James Drinnan wrote:
> I recently installed gestikk. And to my horror one of the dialogs said.
> 
> (Check Box) F*** off 
> 
> No lie, 
> 
> So how does one recommend that this be removed.
> 
What we'll probably do is patch the code to have a less obscene and more
helpful dialog.  To get that done, submit a bug on::
  https://bugzilla.redhat.com/

with what to click on to get the offending dialog to pop up.
That will get the maintainer's attention and they'll be able to deal with
it. If you don't get a response for some reason (maintainer on vacation,
etc), feel free to CC my email address and I'll take a look at creating a
patch.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From opensource at till.name  Fri Oct 16 18:20:22 2009
From: opensource at till.name (Till Maas)
Date: Fri, 16 Oct 2009 20:20:22 +0200
Subject: What to do if a deprecated license is used? nescc java
 files	with intel license
In-Reply-To: <4AD88A08.4000807@redhat.com>
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
	<4AD88A08.4000807@redhat.com>
Message-ID: <20091016182022.GA18572@genius.kawo2.rwth-aachen.de>

On Fri, Oct 16, 2009 at 10:58:16AM -0400, Tom spot Callaway wrote:
> On 10/15/2009 10:02 AM, Till Maas wrote:
> > Hiyas,
> > 
> > I looked into packaging the nesc compiler
> > (https://sourceforge.net/projects/nescc) and I noticed that it uses the
> > deprecated intel license for some java files:
> > http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
> > http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-LICENSE?revision=1.1&view=markup
> > 
> > I opened a bug in their bug tracking system for this:
> > https://sourceforge.net/tracker/?func=detail&aid=2879881&group_id=56288&atid=480036
> > 
> > The Intel license is OSI approved, but deprecated and therefore
> > currently not allowed for Fedora afaics:
> > https://fedoraproject.org/wiki/Licensing#Bad_Licenses
> > Btw. it's a "should not", so maybe it is ok, nevertheless. Or it should
> > be a "must not" guideline, e.g. because it also affects non OSI approved
> > liceneses afaics.
> 
> I've updated the wording there to clarify that no Fedora package may use
> anything under a "Bad" License.

Thanks. Can you maybe also give me some arguments, why I should get the
project to change from the Intel license? There is also a huge actively
maintained project using that license and it also states that it is a
BSD-style license:

http://www.tinyos.net/contrib.html

I just checked and the main difference between the New BSD license
(no advertising, 3 clause) is, that it also adds a note about export
regulations. So afaics, if it was not explicitly be banned from Fedora,
then one could use it just with the BSD shortname afaics. This is very
confusing.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From kevin.kofler at chello.at  Fri Oct 16 18:39:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 20:39:52 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	
	<27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>
	
	
Message-ID: 

Nicolas Mailhot wrote:
> They won't sit in forever, at worst they'll be pushed to users with the
> next Fedora release (that will have been tested properly during beta)

That's what I mean by "forever". It's "forever" as far as that one release 
is concerned.

> No. It's *our* loss if we needlessly frighten of part of our userbase with
> a shoot and forget attitude.

Pushing things which have been tested on at least one Fedora release and 
which were in updates-testing for a week or two with no complaints is not 
"shoot and forget", it's "I tested it and it worked for me, and nobody else 
appears to have any issues with it either, so it's silly to withhold it from 
users".

It's the "I'll never update packages in existing/previous releases because I 
can't/won't test them myself" attitude which is really "shoot and forget": 
"shoot" with the one-time release, "forget" because you won't be updating 
it.

For example, I find it sad you switched to fire-and-forget "maintenance" for 
dejavu-fonts. The monthly updates were a good thing, they rarely if ever 
caused any problems and they improved font coverage.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 16 18:47:38 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 20:47:38 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	 
	 <4AD830CA.3010407@fedoraproject.org>
Message-ID: 

Rahul Sundaram wrote:
> Well, I do remember spending hours switching from kmail to thunderbird
> in the past because a KDE update in Fedora broke IMAP support and it
> stayed broken for quite sometime.

There have indeed been a few KMail regressions (especially with IMAP) which 
slipped through, both in 3.5 times and in early 4.x times. I'll also clarify 
that none of those regressions completely "broke IMAP support". What 
happened is that some IMAP-related feature broke, affecting some users (and 
I'm sorry you were hit by it), whereas most had their IMAP working just 
fine. So those bugs weren't trivial to catch. I'm not claiming we're 
perfect, nor that upstream KDE is. That said, we haven't had such issues 
recently, so things seem to have improved there on the upstream side.

> Also many of the KDE apps after a rewrite tend to be quite close to
> alpha/beta releases for a while rather than general releases, Amarok being
> a good example. It is sometimes pretty tricky to judge.

The Amarok rewrite was NOT pushed as an update. Fedora 9 stayed with 1.4.x 
until Fedora 9's EOL. On the other hand, Fedora 10 shipped with a beta of 
2.0 (for similar reasons as why F11 shipped with a Thunderbird beta: we knew 
that the 2.0 release would be close, that upgrading from 1.4 to 2.x in 
updates wasn't really an option and that 1.4 was being EOLed by upstream) 
and tracked 2.0.x, 2.1.x and now 2.2.x, which were all incremental 
improvements, not rewrites.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 16 18:55:26 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 20:55:26 +0200
Subject: What to do if a deprecated license is used? nescc java files
	with	intel license
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
	<4AD88A08.4000807@redhat.com>
Message-ID: 

Tom "spot" Callaway wrote:
> I've updated the wording there to clarify that no Fedora package may use
> anything under a "Bad" License.

Now what's the benefit of banning licenses just for being "deprecated"?

I really don't see what's wrong with:
http://opensource.org/licenses/intel-open-source-license.php
in particular, as as far as a non-lawyer like me can tell, it appears to be 
legally equivalent to a BSD license. The only added paragraph starts with 
"EXPORT LAWS: THIS LICENSE ADDS NO RESTRICTIONS TO THE EXPORT LAWS OF YOUR 
JURISDICTION. It is licensee's responsibility to comply with any export 
regulations applicable in licensee's jurisdiction.", so I don't see how 
that'd influence the freeness of the software at all.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 16 18:57:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 20:57:55 +0200
Subject: What to do if a deprecated license is used? nescc java files
	with intel license
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
Message-ID: 

Till Maas wrote:
> I looked into packaging the nesc compiler
> (https://sourceforge.net/projects/nescc) and I noticed that it uses the
> deprecated intel license for some java files:
> 
http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-
LICENSE?revision=1.1&view=markup

Are you sure it's really using the deprecated license? The INTEL-LICENSE 
file above doesn't have that added "Export Laws" paragraph which the 
deprecated:
http://opensource.org/licenses/intel-open-source-license.php
has, so to me it seems to be just regular BSD.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 16 19:03:42 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Oct 2009 21:03:42 +0200
Subject: Who do I send to get a package removed because of bad language.
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
Message-ID: 

Steven James Drinnan wrote:
> But my point was the image of Fedora.Does Fedora want be associated with
> software vendors that use this type of language?

Why the fuck would we not? Is there something fucking wrong with the word 
"fuck"? Let's just fucking stop this fucking "politically correct" nonsense, 
fuck!

        Kevin Kofler



From skvidal at fedoraproject.org  Fri Oct 16 19:06:52 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Fri, 16 Oct 2009 15:06:52 -0400 (EDT)
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<4AD80517.8080907@gmail.com>
	<1255675176.11249.6.camel@mylaptop.myhome>
	
Message-ID: 



On Fri, 16 Oct 2009, Kevin Kofler wrote:

> Steven James Drinnan wrote:
>> But my point was the image of Fedora.Does Fedora want be associated with
>> software vendors that use this type of language?
>
> Why the fuck would we not? Is there something fucking wrong with the word
> "fuck"? Let's just fucking stop this fucking "politically correct" nonsense,
> fuck!


  Kevin, chill out.



-sv



From nicolas.mailhot at laposte.net  Fri Oct 16 19:55:02 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Oct 2009 21:55:02 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora 
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	 
	<27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>
	
	
	
Message-ID: <7e2889e647ef0271cfe0fab24b8dc9cb.squirrel@arekh.dyndns.org>



Le Ven 16 octobre 2009 20:39, Kevin Kofler a ?crit :

> For example, I find it sad you switched to fire-and-forget "maintenance" for
> dejavu-fonts. The monthly updates were a good thing, they rarely if ever
> caused any problems and they improved font coverage.

Dejavu has matured a lot so new releases are incremental improvements with no
big feature changes. Not worth it pushing updated packages for previous
releases (that will be installed by pretty much everyone, since DejaVu is in
the default set)

Also, you may have liked the monthly churn, but even lwn.net editors
complained of it publicly

Lastly it gives me more time to work on new packages for new releases.

At the risk of repeating myself one Fedora release cycle is not long and if we
didn't waste our users' time by constant gratuituous updates in stable
releases they could allocate more to update when a new Fedora version was
published.

People who want the latest of everything and do not mind unstability should
run rawhide. Stop rawhidizing stable please.

-- 
Nicolas Mailhot




From karlthered at gmail.com  Fri Oct 16 20:29:46 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Fri, 16 Oct 2009 22:29:46 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091016171914.GA23555@clingman.lan>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>	<200910150055.18568.cemeyer@u.washington.edu>	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<1255621588.2314.45.camel@adam.local.net>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan>
Message-ID: <4AD8D7BA.60707@gmail.com>

Le 16/10/2009 19:19, Toshio Kuratomi a ?crit :
> On Fri, Oct 16, 2009 at 12:58:39PM +0800, Steven James Drinnan wrote:
>> I recently installed gestikk. And to my horror one of the dialogs said.
>>
>> (Check Box) F*** off 
>>
>> No lie, 
>>
>> So how does one recommend that this be removed.
>>
> What we'll probably do is patch the code to have a less obscene and more
> helpful dialog.  To get that done, submit a bug on::
>   https://bugzilla.redhat.com/
> 
> with what to click on to get the offending dialog to pop up.
> That will get the maintainer's attention and they'll be able to deal with
> it. If you don't get a response for some reason (maintainer on vacation,
> etc), feel free to CC my email address and I'll take a look at creating a
> patch.
> 
> -Toshio
> 

I recently came accross Gnaughty (aka Fast and Easy Porn Downloader),
I'm seriously thinking to file a ticket against it. It can be used to
download p0rn, yuck !
What sort of content should we provide as replacement ?

Is this a joke ? On the one hand, we provide gnaughty, on the other
hand, we are seriously thinking patching Gestikk for the use of the
F-U-C-K word in an obscure dialog. Non coherent, either throw gnaughty
away and patch Gestikk, or just let it be.

It's not really that offensive (sexist, racist, homophobic etc...), it's
not installed by default so it won't hurt our image. Anyone offended
should go complain to upstream, Fedora maintainers have no time to waste
on such petty issues.
If you don't like it, don't yum it first.

H.





From dr.diesel at gmail.com  Fri Oct 16 20:27:58 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 16 Oct 2009 16:27:58 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD8D7BA.60707@gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
Message-ID: <2a28d2ab0910161327y49a53d1em6bcfa1e21cdb476a@mail.gmail.com>

On Fri, Oct 16, 2009 at 4:29 PM, Ha?kel Gu?mar  wrote:

>
>
> It's not really that offensive (sexist, racist, homophobic etc...), it's
> not installed by default so it won't hurt our image. Anyone offended
> should go complain to upstream, Fedora maintainers have no time to waste
> on such petty issues.
> If you don't like it, don't yum it first.
>
> H.
>

+1, best said yet.


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
"I'd rather have dead offenders than repeat offenders" - Ted Nugent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mefoster at gmail.com  Fri Oct 16 20:34:18 2009
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Fri, 16 Oct 2009 21:34:18 +0100
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD8D7BA.60707@gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com> 
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com> 
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com> 
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain> 
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> 
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
Message-ID: 

2009/10/16 Ha?kel Gu?mar :
> Le 16/10/2009 19:19, Toshio Kuratomi a ?crit :
>> On Fri, Oct 16, 2009 at 12:58:39PM +0800, Steven James Drinnan wrote:
>>> I recently installed gestikk. And to my horror one of the dialogs said.
>>>
>>> (Check Box) F*** off
>
> I recently came accross Gnaughty (aka Fast and Easy Porn Downloader),
> I'm seriously thinking to file a ticket against it. It can be used to
> download p0rn, yuck !
> What sort of content should we provide as replacement ?
>
> Is this a joke ? On the one hand, we provide gnaughty, on the other
> hand, we are seriously thinking patching Gestikk for the use of the
> F-U-C-K word in an obscure dialog. Non coherent, either throw gnaughty
> away and patch Gestikk, or just let it be.
>
> It's not really that offensive (sexist, racist, homophobic etc...), it's
> not installed by default so it won't hurt our image. Anyone offended
> should go complain to upstream, Fedora maintainers have no time to waste
> on such petty issues.
> If you don't like it, don't yum it first.

I disagree with that last line -- on the one hand, people installing
gnaughty presumable know what they're installing, but "if you don't
like it, don't yum it" doesn't really apply to apparently mainstream
apps that unexpectedly swear at you.

I wouldn't advocate the app being removed from Fedora or anything, but
I do think things like this are inappropriate and should be patched by
the maintainer.

MEF

-- 
Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/
Interaction Lab -- http://sites.google.com/site/hwinteractionlab/
School of Mathematical and Computer Sciences, Heriot-Watt University

Heriot-Watt University is a Scottish charity registered under charity
number SC000278



From opensource at till.name  Fri Oct 16 20:51:12 2009
From: opensource at till.name (Till Maas)
Date: Fri, 16 Oct 2009 22:51:12 +0200
Subject: What to do if a deprecated license is used? nescc java
 files	with intel license
In-Reply-To: 
References: <20091015140220.GA30697@genius.kawo2.rwth-aachen.de>
	
Message-ID: <20091016205112.GA2720@genius.kawo2.rwth-aachen.de>

On Fri, Oct 16, 2009 at 08:57:55PM +0200, Kevin Kofler wrote:
> Till Maas wrote:
> > I looked into packaging the nesc compiler
> > (https://sourceforge.net/projects/nescc) and I noticed that it uses the
> > deprecated intel license for some java files:
> > 
> http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2&view=markup
> > http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-
> LICENSE?revision=1.1&view=markup
> 
> Are you sure it's really using the deprecated license? The INTEL-LICENSE 
> file above doesn't have that added "Export Laws" paragraph which the 
> deprecated:
> http://opensource.org/licenses/intel-open-source-license.php
> has, so to me it seems to be just regular BSD.

You are right. I'll try to get them to also mention this explicitly.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From a.badger at gmail.com  Fri Oct 16 21:36:48 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 16 Oct 2009 14:36:48 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD8D7BA.60707@gmail.com>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
Message-ID: <20091016213648.GC23555@clingman.lan>

On Fri, Oct 16, 2009 at 10:29:46PM +0200, Ha?kel Gu?mar wrote:
> Le 16/10/2009 19:19, Toshio Kuratomi a ?crit :
> > On Fri, Oct 16, 2009 at 12:58:39PM +0800, Steven James Drinnan wrote:
> >> I recently installed gestikk. And to my horror one of the dialogs said.
> >>
> >> (Check Box) F*** off 
> >>
> >> No lie, 
> >>
> >> So how does one recommend that this be removed.
> >>
> > What we'll probably do is patch the code to have a less obscene and more
> > helpful dialog.  To get that done, submit a bug on::
> >   https://bugzilla.redhat.com/
> > 
> > with what to click on to get the offending dialog to pop up.
> > That will get the maintainer's attention and they'll be able to deal with
> > it. If you don't get a response for some reason (maintainer on vacation,
> > etc), feel free to CC my email address and I'll take a look at creating a
> > patch.
> > 
> > -Toshio
> > 
> 
> I recently came accross Gnaughty (aka Fast and Easy Porn Downloader),
> I'm seriously thinking to file a ticket against it. It can be used to
> download p0rn, yuck !
> What sort of content should we provide as replacement ?
> 
> Is this a joke ? On the one hand, we provide gnaughty, on the other
> hand, we are seriously thinking patching Gestikk for the use of the
> F-U-C-K word in an obscure dialog. Non coherent, either throw gnaughty
> away and patch Gestikk, or just let it be.
> 
Well -- this is different in two ways:
1) gnaughty's purpose is to download porn.  Getting rid of its ability to
download porn makes it pretty useless.  gestikk's purpose is to enable mouse
gestures on multiple window managers.  If we rid of the "Fuck off" string
it's still able to perform its activities.

2) Removing gnaughty from the distribution prevents people who want to use
it from being able to use the program.  Removing the string in the glade
file of gestikk does not impact their ability to use the program.

3) gnaughty's description reads: "Application to download automatically
adult sex content, i.e. movies and : pictures, from a known internet
directory".  gestikk's description does not inform the user that language
unsafe for making a good impression on the boss to see is held in the
program.

4) if someone installs gnaughty and clicks on the menu entry, they
immediately realize that it's retrieving pornography and they would be wise
not to show that particular program to their parents, kids, or coworkers.
If someone installs gestikk they will get a program that seems inocuous
enough until someone forgets to click on Apply before closing the
configuraiton dialog (and apparently, only with certain values even then).


> It's not really that offensive (sexist, racist, homophobic etc...), it's
> not installed by default so it won't hurt our image. Anyone offended
> should go complain to upstream, Fedora maintainers have no time to waste
> on such petty issues.
> If you don't like it, don't yum it first.

I disagree on several counts.  Most relevant first:

* This is a problem that a Fedora maintainer should hear about.  The Fedora
  maintainer may choose to spend time on it or may choose to send it
  upstream.  This may be related to time or may be related to how they feel
  about non-professional language.  This is a maintainer's choice.
* I volunteered to make the patch if the maintainer didn't want to do it.
  (And then perhaps I can talk the reporter into submitting hte patch
  upstream for me ;-) So this takes part of the time burden away.
* I agree this isn't in the same realm as overt racism, sexism, homophobism,
  etc.  It's more in the realm of unproffessionalism.  If our users can't
  tell that they could be showing a coworker or their parents how to use
  this program and how they use it that particular time shows something
  that gives the viewer a lower opinion of Fedora then we are failing.
* People need to be informed that this language exists in the program if we
  expect them to make the choice to not yum install it.  Rather than
  labeling all of our software safe/not safe for work we should simply make
  it safe when it's an easy change like this.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From tmz at pobox.com  Fri Oct 16 22:09:46 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 16 Oct 2009 18:09:46 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091016213648.GC23555@clingman.lan>
References: <5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091016213648.GC23555@clingman.lan>
Message-ID: <20091016220946.GI19511@inocybe.localdomain>

Toshio Kuratomi wrote:
> * I volunteered to make the patch if the maintainer didn't want to do it.
>   (And then perhaps I can talk the reporter into submitting hte patch
>   upstream for me ;-) So this takes part of the time burden away.

You might not even have to.  I think, from only a little poking, that
the current code in brz has already removed this string.  Of course,
that code might not be stable so updating to a development checkout
might not be an option.  I didn't look much further as a) I don't use
gestikk and b) I don't know bzr well enough to be able to quickly
compare the branches to see how significant the changes are.

The code is at: https://launchpad.net/gestikk if anyone wants to poke
at it.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've had a perfectly wonderful evening.  But this wasn't it.
    -- Groucho Marx

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From karlthered at gmail.com  Fri Oct 16 22:51:02 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Sat, 17 Oct 2009 00:51:02 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091016213648.GC23555@clingman.lan>
References: <200910150055.18568.cemeyer@u.washington.edu>	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<1255621588.2314.45.camel@adam.local.net>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>	<20091016171914.GA23555@clingman.lan>
	<4AD8D7BA.60707@gmail.com> <20091016213648.GC23555@clingman.lan>
Message-ID: <4AD8F8D6.6030001@gmail.com>

Just to make it clear, I just don't care about gnaughty presence or not
in repositories. I'm not a Debian freak, you know :)


I'm just worried that we might burden package maintainers with
additional, boring and mostly useless censorship tasks. First, optional,
then mandatory.
Erm, if we were to take care about rude language, we might need to patch
some Fedora maintainers too, though it would make things much less
entertaining.

To finish with gnaughty, we do have some underaged Fedora users. The
youngest, I ever met at an event was 12 yo (and he did install himself
his Fedora!). I don't think that parents would agree about distributing
such stuff.
My opinion is parents should monitor their kids, not Fedora guys, but
implementing some kind of filter as a yum or a PackageKit plugin might
help them. But this is another discussion.

H.



From guido.grazioli at gmail.com  Fri Oct 16 23:09:44 2009
From: guido.grazioli at gmail.com (Guido Grazioli)
Date: Sat, 17 Oct 2009 01:09:44 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <4AD8F8D6.6030001@gmail.com>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091016213648.GC23555@clingman.lan> <4AD8F8D6.6030001@gmail.com>
Message-ID: <2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>

Is GPL really a way to freely censor a developer work, as in this case?
If it were closed source, you wouldn't had the right to do that.

That string is more stupid than offensive; and the escalation found here,
starting from the word fuck to things like sexism, racism and tolerance
probably was more appropriate on slashdot (or better, nowhere)

Just my honest opinion
-- 
Guido Grazioli 
Linked in: http://www.linkedin.com/in/guidograzioli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bruno at wolff.to  Sat Oct 17 00:29:32 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 16 Oct 2009 19:29:32 -0500
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
In-Reply-To: <1255639718.18175.6.camel@localhost>
References: <4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	
	<20091014112142.5d208c6e@faldor.intranet>
	<1255552013.2376.12.camel@adam.local.net>
	<20091015112630.31b47388@faldor.intranet>
	 <1255639718.18175.6.camel@localhost>
Message-ID: <20091017002932.GA31658@wolff.to>

On Fri, Oct 16, 2009 at 06:48:38 +1000,
  Dave Airlie  wrote:
> 
> 2 months is too long for user apps maybe, for X.org or Mesa from what I
> can see for ever probably isn't long enough, its not a matter of how
> much time something spends in updates-testing its a matter of how many
> people run what is in there and report on it. We get a lot of QA from
> the community on the run-in from Beta to GA, however we get nothing at
> all even close post-GA, so finding regressions post-GA is close to
> impossible without it hitting updates.
> 
> you can get lots of +1s easily finding the -1 that matters is hard.

I can't easily give you feedback on stuff because I usually grab new
xorg/mesa/libdrm/kernel stuff from koji. When they finally make it to
updates-testing I am not likely to notice their appearance there.
Someday when 3d graphics fully works again, I'll probably slow down.



From awilliam at redhat.com  Sat Oct 17 00:36:49 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 16 Oct 2009 17:36:49 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091016213648.GC23555@clingman.lan> <4AD8F8D6.6030001@gmail.com>
	<2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>
Message-ID: <1255739809.2314.177.camel@adam.local.net>

On Sat, 2009-10-17 at 01:09 +0200, Guido Grazioli wrote:
> Is GPL really a way to freely censor a developer work, as in this
> case?
> If it were closed source, you wouldn't had the right to do that.
> 
> That string is more stupid than offensive; and the escalation found 

There are people who find profanity genuinely offensive. Dealing with it
is a matter of balance; it's obviously intolerable to try and ban it
entirely, but I think it's an equally bad idea to try and argue that,
because _you_ find the concept of bad language being offensive absurd,
it's completely okay to use it entirely gratuitously when you have a
reasonable chance of offending people who disagree.

In other words, as others have said, since this use of profanity is
entirely gratuitous - it's not necessary or valuable in any way
whatsoever - it's a perfectly reasonable choice to patch it out.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From bruno at wolff.to  Sat Oct 17 00:49:35 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 16 Oct 2009 19:49:35 -0500
Subject: Updates-testing (was: Re: thunderbird upgrade - wtf?)
In-Reply-To: <5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
	<5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
Message-ID: <20091017004935.GB31658@wolff.to>

On Thu, Oct 15, 2009 at 10:51:20 -0500,
  chasd  wrote:
> 
> Bruno Wolff III wrote:
> 
> >Postgres isn't even updatable. You need to do dumps before doing
> >the upgrade.
> 
> OK, maybe that isn't a good example then.
> 
> However, using your comment, and turning my idea around, if
> PostgreSQL isn't upgradable, according to my idea it should be
> excluded by default in yum.conf to protect people from hosing their
> data during an upgrade. That doesn't make a lot of sense. I must not
> be thinking particularly well, so ignore me.

Well I think that it is controlled by the packager. In a released Fedora
version, you are only going to get bug fix updates, which don't have that
issue. You do need to be careful doing upgrades because the base postgres
version can change between Fedora versions. (You also need to be extra careful
if you care about postgres while running rawhide.) After you have upgraded
postgres it is too late to use the old data (though people are working on
improvements on that front). So you need to be sure to do the dump before the
upgrade.



From bruno at wolff.to  Sat Oct 17 00:52:20 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 16 Oct 2009 19:52:20 -0500
Subject: Updates-testing
In-Reply-To: <4AD75919.7010209@herr-schmitt.de>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
	<5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
	<4AD75919.7010209@herr-schmitt.de>
Message-ID: <20091017005220.GC31658@wolff.to>

On Thu, Oct 15, 2009 at 19:17:13 +0200,
  Jochen Schmitt  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 15.10.2009 17:51, schrieb chasd:
> >
> >> Postgres isn't even updatable. You need to do dumps before doing
> >> the upgrade.
> >
> Yes, but you should make the dump with the dump utility of the new
> release to which you want to update.

Yeah, but that's even harder in Fedora (because you need the new dump utility
but the old server) and depending on what's changed may not buy you anything.



From guido.grazioli at gmail.com  Sat Oct 17 01:28:17 2009
From: guido.grazioli at gmail.com (Guido Grazioli)
Date: Sat, 17 Oct 2009 03:28:17 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255739809.2314.177.camel@adam.local.net>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091016213648.GC23555@clingman.lan> <4AD8F8D6.6030001@gmail.com>
	<2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>
	<1255739809.2314.177.camel@adam.local.net>
Message-ID: <2f984ea00910161828n284cb34tf27dd31159ed44b5@mail.gmail.com>

2009/10/17 Adam Williamson 

> On Sat, 2009-10-17 at 01:09 +0200, Guido Grazioli wrote:
> > Is GPL really a way to freely censor a developer work, as in this
> > case?
> > If it were closed source, you wouldn't had the right to do that.
> >
> > That string is more stupid than offensive; and the escalation found
>
> There are people who find profanity genuinely offensive. Dealing with it
> is a matter of balance; it's obviously intolerable to try and ban it
> entirely, but I think it's an equally bad idea to try and argue that,
> because _you_ find the concept of bad language being offensive absurd,
> it's completely okay to use it entirely gratuitously when you have a
> reasonable chance of offending people who disagree.
>
> In other words, as others have said, since this use of profanity is
> entirely gratuitous - it's not necessary or valuable in any way
> whatsoever - it's a perfectly reasonable choice to patch it out.
>
>
I didnt say i find profanity not offensive; also, i strongly agree with your
point (*when* wouldnt profanity be considered gratuitous?).

My question was, would you call that patch a "bugfix", or  "enhancement"?
Or it is just like the beep over a bad word on tv, and by all means you can
do that thanks to gpl?



> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Guido Grazioli 
Via Parri 11 48011 - Alfonsine (RA)
Mobile: +39 347 1017202 (10-18)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sundaram at fedoraproject.org  Sat Oct 17 01:28:56 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 17 Oct 2009 06:58:56 +0530
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <2f984ea00910161828n284cb34tf27dd31159ed44b5@mail.gmail.com>
References: <200910150055.18568.cemeyer@u.washington.edu>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>	<20091016171914.GA23555@clingman.lan>
	<4AD8D7BA.60707@gmail.com>	<20091016213648.GC23555@clingman.lan>
	<4AD8F8D6.6030001@gmail.com>	<2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>	<1255739809.2314.177.camel@adam.local.net>
	<2f984ea00910161828n284cb34tf27dd31159ed44b5@mail.gmail.com>
Message-ID: <4AD91DD8.8050203@fedoraproject.org>

On 10/17/2009 06:58 AM, Guido Grazioli wrote:

> My question was, would you call that patch a "bugfix", or  "enhancement"?
> Or it is just like the beep over a bad word on tv, and by all means you can
> do that thanks to gpl?

In this case, since the wording has already been fixed upstream, it
would be a backported bug fix and any free and open source license would
allow that freedom. Not just GPL.

Rahul



From awilliam at redhat.com  Sat Oct 17 01:33:39 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 16 Oct 2009 18:33:39 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <2f984ea00910161828n284cb34tf27dd31159ed44b5@mail.gmail.com>
References: <200910150055.18568.cemeyer@u.washington.edu>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091016213648.GC23555@clingman.lan> <4AD8F8D6.6030001@gmail.com>
	<2f984ea00910161609x1393dddvf9089d6331b76e41@mail.gmail.com>
	<1255739809.2314.177.camel@adam.local.net>
	<2f984ea00910161828n284cb34tf27dd31159ed44b5@mail.gmail.com>
Message-ID: <1255743219.2314.178.camel@adam.local.net>

On Sat, 2009-10-17 at 03:28 +0200, Guido Grazioli wrote:

> I didnt say i find profanity not offensive; also, i strongly agree
> with your
> point (*when* wouldnt profanity be considered gratuitous?).
> 
> My question was, would you call that patch a "bugfix", or
> "enhancement"?
> Or it is just like the beep over a bad word on tv, and by all means
> you can
> do that thanks to gpl?

I wouldn't spend any time worrying about terminology when it's clearly a
case of improving the work that Fedora does.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From kevin.kofler at chello.at  Sat Oct 17 01:49:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 17 Oct 2009 03:49:23 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	
	<27f5864beb5289b04a1e1ee2f20afda5.squirrel@arekh.dyndns.org>
	
	
	
	<7e2889e647ef0271cfe0fab24b8dc9cb.squirrel@arekh.dyndns.org>
Message-ID: 

Nicolas Mailhot wrote:
> Dejavu has matured a lot so new releases are incremental improvements with
> no big feature changes.

... i.e. exactly the kind of things which should be pushed as updates!

> Not worth it pushing updated packages for previous releases (that will be
> installed by pretty much everyone, since DejaVu is in the default set)

If there are bugfixes, added glyphs or any other nontrivial change (which 
doesn't break things), it probably IS worth pushing.

> Also, you may have liked the monthly churn, but even lwn.net editors
> complained of it publicly

Journalists have nothing better to do than complaining. If they can't 
complain about updates, they'll find something else to complain about. 
Please listen to actual users, not journalists!

> Lastly it gives me more time to work on new packages for new releases.

Huh? I do updates for stable releases routinely. It's fairly little work: 
just sync the Rawhide changes (by copying the files over the branch ones), 
commit, make tag, make build BUILD_FLAGS=--nowait and at some later point in 
time, queue the update for testing, then a week later for stable (or just go 
directly for stable if there are really just minor changes).

> At the risk of repeating myself one Fedora release cycle is not long

It's still 6 times as long as some projects', like KDE now (when counting 
bugfix releases, the feature cycle is 6 months) or DejaVu in the past! If we 
don't push new versions of those projects with monthly releases as updates, 
our users have to wait up to half a year (also counting the final freeze) to 
get the fixes they've been waiting for, which is completely unnecessary.

> and if we didn't waste our users' time by constant gratuituous updates in
> stable releases they could allocate more to update when a new Fedora
> version was published.

I doubt that. Routine updates get done quickly and you can even do other 
stuff while they're running. Upgrading to a newer Fedora requires more 
planning.

> People who want the latest of everything and do not mind unstability
> should run rawhide.

But what should people who want the latest of everything that doesn't break 
things, but do mind instability or feature regressions run? That's exactly 
the niche Fedora is targeting (there are plenty of other distros which cater 
to the update haters, e.g. RHEL/CentOS, Ubuntu, Debian stable and many 
others) and why we're pushing updates to stable releases. The fact that we 
aren't doing so consistently is a problem, which is why I'm complaining 
about lazy and/or paranoid maintainers like you who aren't participating.

> Stop rawhidizing stable please.

What I'm suggesting is NOT rawhidizing stable. It's pushing new versions to 
stable where they:
* fix bugs,
* possibly add some additional features users have been waiting for,
* DO NOT drop features,
* DO NOT require manual reconfiguration,
* DO NOT break compatibility with existing user data (documents, savegames 
etc.),
* DO NOT cause major UI changes (but I think minor UI changes are fine!),
* DO NOT knowingly introduce new bugs (e.g. in KDE SIG, we make it a high 
priority to fix all known regressions before promoting a KDE update to 
stable; but the important point there is that we can't fix what we don't 
know about).

These criteria are very different from Rawhide or upgrading to the next 
release! But a lot of version upgrades (and dejavu-fonts is part of those) 
fulfill those requirements and should thus be pushed!

        Kevin Kofler



From mschwendt at gmail.com  Sat Oct 17 12:06:41 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 17 Oct 2009 14:06:41 +0200
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <4AD8D7BA.60707@gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
Message-ID: <20091017140641.01c1b360@faldor.intranet>

On Fri, 16 Oct 2009 22:29:46 +0200, Ha?kel wrote:

> I recently came accross Gnaughty (aka Fast and Easy Porn Downloader),
> I'm seriously thinking to file a ticket against it. It can be used to
> download p0rn, yuck !
> What sort of content should we provide as replacement ?
> 
> Is this a joke ?

It seems so. What will be the next step? Fedora bookmarks for Firefox,
which point at the same web sites that gnaughty uses and advertises?
More tools like that? A competing tool for a competitor's adult web site?
A comps group for such software packages?

| Description: Application to download automatically adult sex content, i.e.
|            : movies and pictures, from a known internet directory.

"Known"? Known by whom? It can't be spelled out like in the README?
All what the tool seems to do is to serve as an advertisement. It is
trying to lure people into visiting those web sites with a normal
web browser, isn't it?

> On the one hand, we provide gnaughty, on the other
> hand, we are seriously thinking patching Gestikk 

We shouldn't provide gnaughty with a hardcoded download site and hardcoded
search terms. It is not a versatile downloader like wget/curl, however,
that can be pointed at arbitrary URLs. It is limited to downloading from
that one directory that it tries to advertise.

And we should remove bad language from gestikk and convince gestikk
upstream to remove it, too.

> Fedora maintainers have no time to waste
> on such petty issues.

Why not? It's not much different from spending time on legal issues, such
as verifying the licensing terms applied in source files, removing source
code or content we don't want to ship, or making sure we don't include a
Yum repo definition package for RPM Fusion. Can you tell whether the tool
_by default_ (!) offers illegal content?

> If you don't like it, don't yum it first.

Doesn't fix the image trouble. Doesn't answer whether the Fedora Project
wants to be responsible for offering and redistributing this software and
thereby preselecting the hardcoded adult web sites.

You want to move the adult-check from web sites (which don't belong to the
Fedora Project) into the Fedora Installer or into RPM?



From fedora at camperquake.de  Sat Oct 17 12:16:13 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 17 Oct 2009 14:16:13 +0200
Subject: Updates-testing
In-Reply-To: <4AD75919.7010209@herr-schmitt.de>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
	<5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
	<4AD75919.7010209@herr-schmitt.de>
Message-ID: <20091017141613.549191d4@fred.camperquake.de>

Hi.

On Thu, 15 Oct 2009 19:17:13 +0200, Jochen Schmitt wrote

> Yes, but you should make the dump with the dump utility of the new
> release to which you want to update.

So version x.y+1 is unable to read a dump created by version x.y?



From rawhide at fedoraproject.org  Sat Oct 17 12:35:36 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 17 Oct 2009 12:35:36 +0000
Subject: rawhide report: 20091017 changes
Message-ID: <20091017123536.GA16293@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 17 06:15:14 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Removed package blobAndConquer
Updated Packages:

abrt-0.0.10-1.fc12
------------------
* Thu Oct 15 2009 Jiri Moskovcak  0.0.10-1
- new version
- added more logging (vda.linux at googlemail.com)
- made polkit policy to be more permissive when installing debuginfo (jmoskovc at redhat.com)
- lib/Plugins/CCpp.cpp: add build-ids to backtrace (vda.linux at googlemail.com)
- lib/Plugins/CCpp.cpp: do not use temp file for gdb commands - use -ex CMD instead (vda.linux at googlemail.com)
- GUI: added refresh button, added sanity check to plugin settings (jmoskovc at redhat.com)
- Initial man page for abrt-cli (kklic at redhat.com)
- Added --version, -V, --help, -? options. Fixed crash caused by unknown option. (kklic at redhat.com)
- Date/time honors current system locale (kklic at redhat.com)
- fixed saving/reading user config (jmoskovc at redhat.com)
- SPEC: added gnome-python2-gnomekeyring to requirements (jmoskovc at redhat.com)
- GUI: call Report() with the latest pluginsettings (jmoskovc at redhat.com)
- Fix Bug 526220 -  [abrt] crash detected in abrt-gui-0.0.9-2.fc12 (vda.linux at googlemail.com)
- removed unsecure reading/writting from ~HOME directory rhbz#522878 (jmoskovc at redhat.com)
- error checking added to archive creation (danny at rawhide.localdomain)
- try using pk-debuginfo-install before falling back to debuginfo-install (vda.linux at googlemail.com)
- abrt-gui: make "report" toolbar button work even if abrtd is not running (vda.linux at googlemail.com)
- set LIMIT_MESSAGE to 16k, typo fix and daemon now reads config information from dbus (npajkovs at redhat.com)
- add support for abrtd autostart (vda.linux at googlemail.com)
- GUI: reversed the dumplist, so the latest crashes are at the top (jmoskovc at redhat.com)
- rewrite FileTransfer to use library calls instead of commandline calls for compression (dnovotny at redhat.com)
- and many minor fixes ..


aria2-1.6.2-1.fc12
------------------
* Sat Oct 10 2009 Rahul Sundaram  - 1.6.2-1
- Minor bug fixes and switch XZ compressed source 
- http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1586


binutils-2.19.51.0.14-33.fc12
-----------------------------
* Thu Oct 15 2009 Jakub Jelinek  2.19.51.0.14-33
- Add .cfi_sections support.  (PR debug/40521)


claws-mail-3.7.3-1.fc12
-----------------------
* Mon Oct 12 2009 Andreas Bierfert 
- 3.7.3-1
- version upgrade (including gtk 2.18 fixes #527065)


claws-mail-plugins-3.7.3-1.fc12
-------------------------------
* Mon Oct 12 2009 Andreas Bierfert 
- 3.7.3-1
- version upgrade
- new plugins bsfilter, python


firstboot-1.110-1.fc12
----------------------
* Wed Oct 14 2009 Chris Lumens  1.110-1
- Always attempt to display the Fedora logo, if present (jmccann).
- Fix a bunch of small firstboot UI problems (jmccann).


glibc-2.10.90-25
----------------
* Mon Oct 12 2009 Andreas Schwab  - 2.10.90-25
- Update from master
  - Fix descriptor leak when calling dlopen with RTLD_NOLOAD (#527409).
  - Fix week-1stday in C locale.
  - Check for integer overflows in formatting functions.
  - Fix locale program error handling (#525363).


gnome-panel-2.28.0-6.fc12
-------------------------
* Fri Oct 16 2009 Matthias Clasen  2.28.0-6
- Put status icons in a predictable order

* Wed Oct 14 2009 Matthias Clasen  2.28.0-5
- Tweaks to the default panel configuration


gstreamer-plugins-good-0.10.16-2.fc12
-------------------------------------
* Fri Oct 16 2009 Bastien Nocera  0.10.16-2
- Fix autoconvert caps negotiation


gtk2-2.18.2-3.fc12
------------------
* Tue Oct 13 2009 Matthias Clasen  - 2.18.2-3
- Make gtk-builder-convert use system python


hercstudio-1.0.0-1.fc12
-----------------------
* Fri Oct 16 2009 Dan Hor?k  - 1.0.0-1
- update to 1.0.0


imsettings-0.107.4-2.fc12
-------------------------
* Fri Oct 16 2009 Akira TAGOH  - 0.107.4-2
- Run IM for Mailthili by default. (#529144)


kazehakase-0.5.8-2.fc12
-----------------------
* Sat Oct 17 2009 Mamoru Tasaka  - 0.5.8-2
- Fix crash when trying to view source or cert with no page loaded
  (bug 529334)


kdebase-runtime-4.3.2-4.fc12
----------------------------
* Thu Oct 15 2009 Rex Dieter  4.3.2-4
- Conflicts: kdebase4 < 4.3.0 instead

* Wed Oct 14 2009 Rex Dieter  4.3.2-3
- Conflicts: kdebase < 6:4.3.0
- Requires: oxygen-icon-theme >= %{version}


kdeplasma-addons-4.3.2-3.fc12
-----------------------------
* Fri Oct 16 2009 Rex Dieter  - 4.3.2-3
- rev microblog/twitter patch (kde#200475#c36)

* Sat Oct 10 2009 Rex Dieter  - 4.3.2-2
- microblog/twitter fix (kde#209891)


libasyncns-0.8-1.fc12
---------------------
* Fri Oct 16 2009 Lennart Poettering  0.8-1
- New release


libcanberra-0.21-1.fc12
-----------------------
* Fri Oct 16 2009 Lennart Poettering  0.21-1
- New version 0.21

* Thu Oct 15 2009 Lennart Poettering  0.20-1
- New version 0.20

* Wed Oct 14 2009 Lennart Poettering  0.19-1
- New version 0.19


libdrm-2.4.15-1.fc12
--------------------
* Fri Oct 09 2009 Dave Airlie  2.4.15-1
- rebase to latest upstream release


libgweather-2.28.0-2.fc12
-------------------------
* Thu Oct 15 2009 Matthias Clasen  2.28.0-2
- Pick a better weather station for Montreal


metacity-2.28.0-3.fc12
----------------------
* Thu Oct 15 2009 Matthias Clasen  - 2.28.0-3
- Tweak the default number of workspaces


mysql-5.1.39-3.fc12
-------------------
* Thu Oct 15 2009 Tom Lane  5.1.39-3
- Work around two different compiler bugs on sparc, one by backing off
  optimization from -O2 to -O1, and the other with a klugy patch
Related: #529298, #529299
- Clean up bogosity in multilib stub header support: ia64 should not be
  listed (it's not multilib), sparc and sparc64 should be


notification-daemon-0.4.1-0.20090923.3.fc12
-------------------------------------------
* Thu Oct 15 2009 Matthias Clasen  - 0.4.1-1.20090923.3
- Fix issues with the multi-monitor support
- Make screensaver check work
- Use gvfs-open instead of gnome-open


ocaml-camlimages-3.0.1-12.fc12.1
--------------------------------
* Fri Oct 16 2009 Richard W.M. Jones  - 3.0.1-12.fc12.1
- ocaml-camlimages: TIFF reader multiple integer overflows
  (CVE 2009-3296 / RHBZ#528732).


ocaml-mysql-1.0.4-11.fc12
-------------------------
* Fri Oct 16 2009 Richard W.M. Jones  - 1.0.4-11
- Patch for CVE 2009-2942 Missing escape function (RHBZ#529321).


ocaml-postgresql-1.12.3-1.fc12
------------------------------
* Fri Oct 16 2009 Richard W.M. Jones  - 1.12.3-1
- New upstream version 1.12.3.
- This contains a SECURITY fix for:
  https://bugzilla.redhat.com/show_bug.cgi?id=529325
  CVE-2009-2943 ocaml-postgresql: Missing escape function (DSA-1909-1)
  HOWEVER you are not protected until you change your code to
  use the new connection#escape_string method.


openssl-1.0.0-0.10.beta3.fc12
-----------------------------
* Fri Oct 16 2009 Tomas Mraz  1.0.0-0.10.beta3
- fix use of freed memory if SSL_CTX_free() is called before
  SSL_free() (#521342)


pidgin-2.6.3-1.fc12
-------------------
* Fri Oct 16 2009 Warren Togami  2.6.3-1
- 2.6.3 CVE-2009-3615


plymouth-0.8.0-0.2009.29.09.11.fc12
-----------------------------------
* Tue Oct 13 2009 Ray Strode  0.8.0-0.2009.29.09.10
- Fix more emergency shell horkage (for users without modesetting)
  (bug 528683)

* Tue Oct 13 2009 Ray Strode  0.8.0-0.2009.29.09.11
- Clean up terminal on exit (bug 528683 again)


selinux-policy-3.6.32-27.fc12
-----------------------------
* Tue Oct 13 2009 Dan Walsh  3.6.32-26
- Fix labeling for privoxy config files
- Add devtmpfs file system labeling

* Tue Oct 13 2009 Dan Walsh  3.6.32-27
- Allow plymouthd_t to use frame_buffer

* Mon Oct 12 2009 Dan Walsh  3.6.32-25
- Fix alias for execmem_exec_t
- Dontaudit hal leakage
- Add label for nspluginviewer


setroubleshoot-2.2.40-1.fc12
----------------------------
* Thu Oct 15 2009 Dan Walsh  - 2.2.40-1
- Fix up browser button handling when there are 0, 1 or more alerts

* Tue Oct 13 2009 Dan Walsh  - 2.2.39-1
- Catch additional bugzilla exception

* Thu Oct 08 2009 Dan Walsh  - 2.2.38-1
- Show that the application is starting.
- Fix ignore sealert button


setroubleshoot-plugins-2.1.28-1.fc12
------------------------------------
* Thu Oct 15 2009  - 2.1.28-1
- Update-po

* Tue Oct 13 2009  - 2.1.27-1
- Add vbetool plugin

* Wed Oct 07 2009  - 2.1.26-1
- Add wine plugin

* Tue Oct 06 2009  - 2.1.25-1
- Fix http_can_senmail to look for "sendmail" in command

* Thu Oct 01 2009  - 2.1.24-2
- Add support for Green Plugins


sugar-toolkit-0.86.1-2.fc12
---------------------------
* Fri Oct 09 2009 Luke Macken  - 0.86.1-2
- Remove python-json requirement, which is now provided by Python 2.6


udev-145-11.fc12
----------------
* Tue Oct 13 2009 Harald Hoyer  145-11
- recognize a devtmpfs on /dev (bug #528488)


wxGTK-2.8.10-5.fc12
-------------------
* Fri Oct 16 2009 Dan Hor?k  - 2.8.10-5
- add fix for excessive CPU usage (#494425)


xdg-utils-1.0.2-14.20091016cvs.fc12
-----------------------------------
* Fri Oct 16 2009 Rex Dieter  - 1.0.2-14.20091016cvs
- prefer gvfs-open over gnome-open (#529287)
- DE=gnome, if org.gnome.SessionManager exists on dbus (#529287)

* Mon Sep 28 2009 Rex Dieter  - 1.0.2-13.20090928cvs
- xdg-open: use kde-open


xpdf-3.02-15.fc12
-----------------
* Fri Oct 16 2009 Tom "spot" Callaway  - 1:3.02-15
- apply xpdf-3.02pl4 security patch to fix:
  CVE-2009-3603, CVE-2009-3604, CVE-2009-3605, CVE-2009-3606
  CVE-2009-3608, CVE-2009-3609


yum-3.2.25-1.fc12
-----------------
* Wed Oct 14 2009 Seth Vidal  - 3.2.25-1
- 3.2.25


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 37



From alsadi at gmail.com  Sat Oct 17 13:59:22 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sat, 17 Oct 2009 16:59:22 +0300
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <20091017140641.01c1b360@faldor.intranet>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
Message-ID: <385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>

I asked the fedorians if they can't remove such packages just to
maintain a list of such packages so I would add them to exception list
in yum.conf, they offended me and tried to shoot me, so be warned and
prepared to be Trolled

http://en.wikipedia.org/wiki/Internet_forum#Troll



From bruno at wolff.to  Sat Oct 17 14:45:09 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 17 Oct 2009 09:45:09 -0500
Subject: Updates-testing
In-Reply-To: <20091017141613.549191d4@fred.camperquake.de>
References: <20091014225342.9F0A261909B@hormel.redhat.com>
	<5DF98842-39CF-4BAB-BDF0-0907FBF0A78D@silveroaks.com>
	<4AD75919.7010209@herr-schmitt.de>
	<20091017141613.549191d4@fred.camperquake.de>
Message-ID: <20091017144509.GB9149@wolff.to>

On Sat, Oct 17, 2009 at 14:16:13 +0200,
  Ralf Ertzinger  wrote:
> Hi.
> 
> On Thu, 15 Oct 2009 19:17:13 +0200, Jochen Schmitt wrote
> 
> > Yes, but you should make the dump with the dump utility of the new
> > release to which you want to update.
> 
> So version x.y+1 is unable to read a dump created by version x.y?

They can read them, but sometimes there are new features and you can take
advantage of them better during the dump. So that when you do the load into the
new version, it will end up getting done better. I don't have a for sure
example off hand, but I seem to remember that this was a good idea when
schemas got added. Another possibility was that at some point dependency
handling during dumps was improved (probably more than once) and that these
additions were not backported to every version someone might have been using.
Doing the dump with the later version might have saved you some hand tweaking
of the table definitions (particularly when tables referenced each other)
at some upgrade points.



From john.brown009 at gmail.com  Sat Oct 17 14:44:13 2009
From: john.brown009 at gmail.com (TK009)
Date: Sat, 17 Oct 2009 10:44:13 -0400
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
References: <1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
	<385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
Message-ID: <20091017144412.GA2431@blackhare>

On Sat, Oct 17, 2009 at 04:59:22PM +0300, Muayyad AlSadi wrote:
> I asked the fedorians if they can't remove such packages just to
> maintain a list of such packages so I would add them to exception list
> in yum.conf, they offended me and tried to shoot me, so be warned and
> prepared to be Trolled
> 
> http://en.wikipedia.org/wiki/Internet_forum#Troll
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

You were told to do the work yourself. I see your still looking for someone else to do it for you.

Good luck with that

TK009 



From kwhiskerz at gmail.com  Sat Oct 17 18:09:20 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Sat, 17 Oct 2009 12:09:20 -0600
Subject: USB Keyboard Amok?
Message-ID: 

Hardware:

Logitech USB Keyboard
Asus Motherboard

Problem:

Approximately every 100th cold boot/system restart, the 
BIOS message, as it is displaying memory, hard drives, 
etc., is all scrambled, even in colour, and the beep 
that normally occurs at boot becomes a single long ring 
that never stops, and the system hangs, unresponsive to 
any input.

Solution:

To remedy this, one must unplug the computer, wait 
until the LED on the motherboard extinguishes, remove 
the battery from the motherboard, plug in a spare PS/2 
keyboard, put the battery and power cable back in, and 
reboot.

Then, the BIOS settings must all be set from scratch, 
as they are totally awry - no, not the defaults! If one 
does not use a PS/2 keyboard, no keyboard entry is 
possible. If one does not remove the battery, then some 
mysterious BIOS supervisor password will be set that 
cannot be circumvented (I don't use a BIOS supervisor 
password).

After having performed all of these steps, the system 
works perfectly, like before, until about the 100th 
time (wild guess - a long time - but often the problem 
occurs 2 or 3 times in a row, then not at all for 
weeks). Curiously, the same problem existed with a 
previous Asus motherboard (same USB keyboard, which 
works perfectly, as far I am able to determine from 
regular, daily use).

Is this an Asus problem, since 2 Asus motherboards are 
affected (I upgraded the BIOS, but there have not been 
any new upgrades available for 18 months), a USB 
keyboard problem (the problem occured on the older 
motherboard while kbd, not evdev, was in use), or 
something altogether different? I have been unable to 
replicate the problem or determine any actions/states 
that appear to produce it.



From alsadi at gmail.com  Sat Oct 17 21:14:17 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 18 Oct 2009 00:14:17 +0300
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <20091017144412.GA2431@blackhare>
References: <1255621588.2314.45.camel@adam.local.net>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
	<385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
	<20091017144412.GA2431@blackhare>
Message-ID: <385866f0910171414j2c584f2ei16eace7862ba2ac8@mail.gmail.com>

> You were told to do the work yourself. I see your still looking for someone else to do it for you.

Schwendt! see how they weren't listening, I told them I already
prepared that list even before the original message was posted.

TK009, I do my own homework myself. I did not invite Mr. Schwendt to
do mine nor to help me, I just give him a prediction about the hostile
 community attitude toward him, and you demonstrated that practically
;-)



From alsadi at gmail.com  Sat Oct 17 21:30:12 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 18 Oct 2009 00:30:12 +0300
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <385866f0910171414j2c584f2ei16eace7862ba2ac8@mail.gmail.com>
References: <1255621588.2314.45.camel@adam.local.net>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
	<385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
	<20091017144412.GA2431@blackhare>
	<385866f0910171414j2c584f2ei16eace7862ba2ac8@mail.gmail.com>
Message-ID: <385866f0910171430q1201f857x852cac3bf6aedd3a@mail.gmail.com>

> You were told to do the work yourself. I see your still looking for someone else to do it for you.
>
> Good luck with that

I forget to mention that I was convinced by one of the fedorians that
maintaining such list on a public web site is worse because it would
be like advertising. I'm no longer ask for just list to be made.



From bruno at wolff.to  Sat Oct 17 21:49:25 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 17 Oct 2009 16:49:25 -0500
Subject: Did something happen to blobAndConquer?
Message-ID: <20091017214925.GA8781@wolff.to>

blobAndConquer seems to have dropped out of today's rawhide repo even though
it is still tagged for dist-f12, f12-beta and f12-final.
Are other people seeing this?



From jeff at ocjtech.us  Sat Oct 17 21:54:43 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Sat, 17 Oct 2009 16:54:43 -0500
Subject: Did something happen to blobAndConquer?
In-Reply-To: <20091017214925.GA8781@wolff.to>
References: <20091017214925.GA8781@wolff.to>
Message-ID: <935ead450910171454r3a7cd20aj26feed8281cffa26@mail.gmail.com>

On Sat, Oct 17, 2009 at 4:49 PM, Bruno Wolff III  wrote:
> blobAndConquer seems to have dropped out of today's rawhide repo even though
> it is still tagged for dist-f12, f12-beta and f12-final.
> Are other people seeing this?

https://fedorahosted.org/rel-eng/ticket/2509

-- 
Jeff Ollie



From john.brown009 at gmail.com  Sat Oct 17 21:58:59 2009
From: john.brown009 at gmail.com (TK009)
Date: Sat, 17 Oct 2009 17:58:59 -0400
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <385866f0910171430q1201f857x852cac3bf6aedd3a@mail.gmail.com>
References: <1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
	<385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
	<20091017144412.GA2431@blackhare>
	<385866f0910171414j2c584f2ei16eace7862ba2ac8@mail.gmail.com>
	<385866f0910171430q1201f857x852cac3bf6aedd3a@mail.gmail.com>
Message-ID: <20091017215859.GB11299@blackhare>

On Sun, Oct 18, 2009 at 12:30:12AM +0300, Muayyad AlSadi wrote:
> > You were told to do the work yourself. I see your still looking for someone else to do it for you.
> >
> > Good luck with that
> 
> I forget to mention that I was convinced by one of the fedorians that
> maintaining such list on a public web site is worse because it would
> be like advertising. I'm no longer ask for just list to be made.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


I am glad I was able to live up to your expectations, and that you've resolved 'your' issue.

=)



From bruno at wolff.to  Sat Oct 17 22:25:36 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 17 Oct 2009 17:25:36 -0500
Subject: Did something happen to blobAndConquer?
In-Reply-To: <935ead450910171454r3a7cd20aj26feed8281cffa26@mail.gmail.com>
References: <20091017214925.GA8781@wolff.to>
	<935ead450910171454r3a7cd20aj26feed8281cffa26@mail.gmail.com>
Message-ID: <20091017222536.GA29064@wolff.to>

On Sat, Oct 17, 2009 at 16:54:43 -0500,
  Jeffrey Ollie  wrote:
> On Sat, Oct 17, 2009 at 4:49 PM, Bruno Wolff III  wrote:
> > blobAndConquer seems to have dropped out of today's rawhide repo even though
> > it is still tagged for dist-f12, f12-beta and f12-final.
> > Are other people seeing this?
> 
> https://fedorahosted.org/rel-eng/ticket/2509

Thanks. Not that you remind me I do vaguely remember seeing a message from
Hans about it on some list.



From bruno at wolff.to  Sat Oct 17 22:59:49 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 17 Oct 2009 17:59:49 -0500
Subject: Did something happen to blobAndConquer?
In-Reply-To: <20091017222536.GA29064@wolff.to>
References: <20091017214925.GA8781@wolff.to>
	<935ead450910171454r3a7cd20aj26feed8281cffa26@mail.gmail.com>
	<20091017222536.GA29064@wolff.to>
Message-ID: <20091017225949.GA15098@wolff.to>

On Sat, Oct 17, 2009 at 17:25:36 -0500,
  Bruno Wolff III  wrote:
> On Sat, Oct 17, 2009 at 16:54:43 -0500,
>   Jeffrey Ollie  wrote:
> > On Sat, Oct 17, 2009 at 4:49 PM, Bruno Wolff III  wrote:
> > > blobAndConquer seems to have dropped out of today's rawhide repo even though
> > > it is still tagged for dist-f12, f12-beta and f12-final.
> > > Are other people seeing this?
> > 
> > https://fedorahosted.org/rel-eng/ticket/2509
> 
> Thanks. Not that you remind me I do vaguely remember seeing a message from
> Hans about it on some list.

That 'Not' was supposed to be 'Now'.

I have updated the games spin and added a note to the ticket to ask for
checking for use in spins in addition to normal dependencies for future
cases.



From mike.cloaked at gmail.com  Sun Oct 18 09:14:16 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Sun, 18 Oct 2009 09:14:16 +0000 (UTC)
Subject: Status of touchpad support in F12 for kdm?
Message-ID: 

In F11 every laptop I installed had support for the touchpad under Gnome, but in
order to have touchpad tap action at the greeter stage in kdm I need to put in
place a suitable hal/fdi file.

Is touchpad support in kdm going to be available by default in F12? 



From kevin.kofler at chello.at  Sun Oct 18 10:20:19 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 18 Oct 2009 12:20:19 +0200
Subject: Status of touchpad support in F12 for kdm?
References: 
Message-ID: 

Mike Cloaked wrote:
> In F11 every laptop I installed had support for the touchpad under Gnome,
> but in order to have touchpad tap action at the greeter stage in kdm I
> need to put in place a suitable hal/fdi file.
> 
> Is touchpad support in kdm going to be available by default in F12?

No, tapping is disabled by default distrowide, there's nothing KDM can or 
should do about this. This is an intentional decision by the upstream 
Synaptics driver developers. Most touchpads have dedicated buttons you can 
press, which are much harder to click accidentally than it is to trigger an 
unwanted tapping click.

        Kevin Kofler



From drago01 at gmail.com  Sun Oct 18 11:11:10 2009
From: drago01 at gmail.com (drago01)
Date: Sun, 18 Oct 2009 13:11:10 +0200
Subject: Status of touchpad support in F12 for kdm?
In-Reply-To: 
References: 
	
Message-ID: 

On Sun, Oct 18, 2009 at 12:20 PM, Kevin Kofler  wrote:
> Mike Cloaked wrote:
>> In F11 every laptop I installed had support for the touchpad under Gnome,
>> but in order to have touchpad tap action at the greeter stage in kdm I
>> need to put in place a suitable hal/fdi file.
>>
>> Is touchpad support in kdm going to be available by default in F12?
>
> No, tapping is disabled by default distrowide, there's nothing KDM can or
> should do about this. This is an intentional decision by the upstream

Well it can enable it via input properties (configuration interface
for xorg input drivers).



From rawhide at fedoraproject.org  Sun Oct 18 11:29:06 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 18 Oct 2009 11:29:06 +0000
Subject: rawhide report: 20091018 changes
Message-ID: <20091018112906.GA31434@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 18 06:15:10 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From mike.cloaked at gmail.com  Sun Oct 18 16:30:48 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Sun, 18 Oct 2009 16:30:48 +0000 (UTC)
Subject: Status of touchpad support in F12 for kdm?
References: 
	
	
Message-ID: 

drago01  gmail.com> writes:

> > No, tapping is disabled by default distrowide, there's nothing KDM can or
> > should do about this. This is an intentional decision by the upstream
> 
> Well it can enable it via input properties (configuration interface
> for xorg input drivers).
> 

Using the buttons is often a pain and slower than tapping - in Gnome you can
switch on "tap to click" and also "disable touchpad whilst typing" which I find
convenient.
Exactly which config interface are you referring to that enables this for xorg
for kdm? Many systems do not have xorg.conf once installed, so presumably there
is something else?



From mcepl at redhat.com  Sun Oct 18 18:58:10 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Sun, 18 Oct 2009 20:58:10 +0200
Subject: Status of touchpad support in F12 for kdm?
In-Reply-To: 
References: 
Message-ID: 

Dne 18.10.2009 11:14, Mike Cloaked napsal(a):
> In F11 every laptop I installed had support for the touchpad under Gnome, but in
> order to have touchpad tap action at the greeter stage in kdm I need to put in
> place a suitable hal/fdi file.
> 
> Is touchpad support in kdm going to be available by default in F12? 

I have no experience with KDE, but in Gnome I have it set in the Gnome
configuration (not sure whether it works in gdm). Otherwise /etc/hal/fdi
file is your safest bet.
https://fedoraproject.org/wiki/Input_device_configuration has some more
information about this.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Why should I travel, when I'm already there?
    -- Bostonian lady, when being asked why she never visited
        other places than Boston



From mike.cloaked at gmail.com  Sun Oct 18 19:14:59 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Sun, 18 Oct 2009 19:14:59 +0000 (UTC)
Subject: Status of touchpad support in F12 for kdm?
References: 
	
Message-ID: 

Mat?j Cepl  redhat.com> writes:

> I have no experience with KDE, but in Gnome I have it set in the Gnome
> configuration (not sure whether it works in gdm). Otherwise /etc/hal/fdi
> file is your safest bet.
> https://fedoraproject.org/wiki/Input_device_configuration has some more
> information about this.
> 
> Mat?j

Thanks - yes in Gnome F11 it is settable in System->Preferences->Mouse and then
select the touchpad tab - I have not tried in gdm recently but I have set a file
as /etc/hal/fdi/policy/10-synaptics.fdi which was made by adding the lines:
  1
  3
  2
  1

to the contents of /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi and
then copying to the location /etc/hal/fdi/policy/10-synaptics.fdi

After rebooting then the touchpad works in kdm - maybe this will fix gdm too?

I suppose at least this does work even if upstream policy is not to make this
available - however for a newbie just installing F11 and wanting this available
it is not obvious from install notes or release notes as far as I remember?







From mike.cloaked at gmail.com  Sun Oct 18 20:45:16 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Sun, 18 Oct 2009 20:45:16 +0000 (UTC)
Subject: Thunderbird 3.0rc1
Message-ID: 

Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 when it
is released? 

>From MozillaWiki I note that the plan is: Start build: 3rd November (est 10th
Nov) so this will likely be around 3 weeks away.

Thanks



From erikina at gmail.com  Sun Oct 18 23:35:22 2009
From: erikina at gmail.com (Eric Springer)
Date: Mon, 19 Oct 2009 09:35:22 +1000
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255669121.11249.3.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com> 
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com> 
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com> 
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain> 
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
Message-ID: 

On Fri, Oct 16, 2009 at 2:58 PM, Steven James Drinnan  wrote:
> I recently installed gestikk. And to my horror one of the dialogs said.

Not sure if it's the best road to take, how ever I've created a page
in the wiki (that can be edited mercilessly or deleted if you think
it'll just attract attention):

https://fedoraproject.org/wiki/Offensive_Packages



From steven at scc.hk  Mon Oct 19 00:26:19 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Mon, 19 Oct 2009 08:26:19 +0800
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
Message-ID: <1255911984.3180.5.camel@mylaptop.myhome>

On Mon, 2009-10-19 at 09:35 +1000, Eric Springer wrote:
> On Fri, Oct 16, 2009 at 2:58 PM, Steven James Drinnan  wrote:
> > I recently installed gestikk. And to my horror one of the dialogs said.
> 
> Not sure if it's the best road to take, how ever I've created a page
> in the wiki (that can be edited mercilessly or deleted if you think
> it'll just attract attention):
> 
> https://fedoraproject.org/wiki/Offensive_Packages
> 

A good start, yes I agree that fedora is about freedom and choice. For
me this seems a good option ( having an exclude function for offensive
packages). Making this part of package kit would be good. Almost like a
parental control system for software. 

I do think as distributor it is good to be family friendly as possible.

Maybe this could be added as a feature in future releases -  there may
not be many packages that need to be added but it would give a big group
of users some peace of mind.

Steven Drinnan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From ismael at olea.org  Mon Oct 19 00:39:56 2009
From: ismael at olea.org (Ismael Olea)
Date: Mon, 19 Oct 2009 02:39:56 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255911984.3180.5.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
Message-ID: <22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>

> Maybe this could be added as a feature in future releases -  there may
> not be many packages that need to be added but it would give a big group
> of users some peace of mind.

IMHO if this kind of feature is accepted would be needed to do in other
cases, for example about religion. In a fast search:

bibletime.i586 : BibleTime is an easy to use Bible study tool for KDE
gnomesword.i586 : GNOME-based Bible research tool
kio_sword.i586 : A lightweight frontend for the Sword Bible project for KDE
sword.i586 : Free Bible Software Project
sword-devel.i586 : Development files for the sword project
xiphos.i586 : Bible study and research tool

Maybe some parents would like to keep their children apart of contents like
these.

My 0.02?


-- 

Ismael Olea

http://olea.org/diario/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From erikina at gmail.com  Mon Oct 19 01:47:08 2009
From: erikina at gmail.com (Eric Springer)
Date: Mon, 19 Oct 2009 11:47:08 +1000
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com> 
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com> 
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain> 
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> 
	 
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
Message-ID: 

On Mon, Oct 19, 2009 at 10:39 AM, Ismael Olea  wrote:
> My 0.02?

More like your troll-cents. Despite the absurdity (of this whole
thing, in fact) I've added a category and included it. And people can
make up their own minds.



From cemeyer at u.washington.edu  Mon Oct 19 02:04:56 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Sun, 18 Oct 2009 19:04:56 -0700
Subject: Packaging files that rpmbuild's auto-{requires,provides} trips on
Message-ID: <200910181904.56125.cemeyer@u.washington.edu>

Hi,

I'm packaging some data files for a package and having trouble getting 
rpmbuild to finish. At some point in (I'm guessing) the autorequires/provides 
scripts, file(1) returns a 1 code, and rpmbuild chokes and dies. So, my 
question here is:

1) How do I get these scripts to ignore this file?

and also:

2) Should the autorequires/provides scripts die when they stumble across a 
file file(1) errors on, or should they just assume it doesn't require or 
provide anything?

Thanks,
-- 
Conrad Meyer 



From james at fedoraproject.org  Mon Oct 19 04:04:58 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 19 Oct 2009 00:04:58 -0400
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
 11
In-Reply-To: 
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org> 
	 
	 
	<4AD830CA.3010407@fedoraproject.org>  
Message-ID: <1255925098.9430.9.camel@code.and.org>

On Fri, 2009-10-16 at 20:47 +0200, Kevin Kofler wrote:
> What 
> happened is that some IMAP-related feature broke, affecting some users (and 
> I'm sorry you were hit by it), whereas most had their IMAP working just 
> fine. So those bugs weren't trivial to catch.

 Wow ... it's almost as if we need a place where developers could put
_updates_ for a significant amount of time so that users could do some
_testing_ on them, under each of their particular conditions. We could
maybe use this instead of developers hitting the go button when they
didn't get an avalanche of BZs immediately.

 It'd also be cool if we could have some package management tool to
"downgrade" these updates, so users wouldn't be immediate screwed if
they tried an update for testing purposes ... it might even be possible
to create a history of package management operations, and then the user
could just "undo" the set of things they got from this place for testing
of updates.

 I must meditate on this.

-- 
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell



From msuchy at redhat.com  Mon Oct 19 06:32:56 2009
From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=)
Date: Mon, 19 Oct 2009 08:32:56 +0200
Subject: [Fwd: Junior Jobs]
Message-ID: <4ADC0818.8010705@redhat.com>

May be good idea for Fedora as well...
Mirek


-------- P?vodn? zpr?va --------
P?edm?t: [opensuse-packaging] Junior Jobs
Datum: Tue, 13 Oct 2009 14:46:58 +0200
Od: Michal Hrusecky 
Komu: opensuse-packaging at opensuse.org

Hi,

lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of
openSUSE packages can choose some of theirs easy bugs and mark them as
Junior Jobs. Then anybody from community can volunteer and fix these
issues. These tasks will be easily fixable and their purpose is to let
people learn how to contribute and to create some easy task so anybody
can join and start participating.

[1] http://en.opensuse.org/Junior_Jobs


-- 
Miroslav Suchy
Red Hat Satellite Engineering



From oget.fedora at gmail.com  Mon Oct 19 06:47:38 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Mon, 19 Oct 2009 02:47:38 -0400
Subject: [Fwd: Junior Jobs]
In-Reply-To: <4ADC0818.8010705@redhat.com>
References: <4ADC0818.8010705@redhat.com>
Message-ID: 

2009/10/19 Miroslav Such?
> May be good idea for Fedora as well...
> Mirek
>
>
> -------- P?vodn? zpr?va --------
> P?edm?t: [opensuse-packaging] Junior Jobs
> Datum: Tue, 13 Oct 2009 14:46:58 +0200
> Od: Michal Hrusecky
>
> Hi,
>
> lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of
> openSUSE packages can choose some of theirs easy bugs and mark them as
> Junior Jobs. Then anybody from community can volunteer and fix these
> issues. These tasks will be easily fixable and their purpose is to let
> people learn how to contribute and to create some easy task so anybody
> can join and start participating.
>
> [1] http://en.opensuse.org/Junior_Jobs
>
>

Not a bad idea. I think at least the KDE project does a similar thing.
Maybe other projects do this too.

Implementation of this brings back the question: Shall the packagers
have an option to give commit access to every other packager and not
just to provenpackagers? This question arises because provenpackagers
are by definition not "junior"s.

The last time I talked to cvs folks, they told me that the code is
there for this option but it needs some testing. Any progress there?

Orcan



From yersinia.spiros at gmail.com  Mon Oct 19 06:57:57 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Mon, 19 Oct 2009 08:57:57 +0200
Subject: [Fwd: Junior Jobs]
In-Reply-To: <4ADC0818.8010705@redhat.com>
References: <4ADC0818.8010705@redhat.com>
Message-ID: 

2009/10/19 Miroslav Such? :
> May be good idea for Fedora as well...
Look like similar  to the kernel janitor project initiative
http://janitor.kernelnewbies.org/
> Mirek
>
>
> -------- P?vodn? zpr?va --------
> P?edm?t: [opensuse-packaging] Junior Jobs
> Datum: Tue, 13 Oct 2009 14:46:58 +0200
> Od: Michal Hrusecky 
> Komu: opensuse-packaging at opensuse.org
>
> Hi,
>
> lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of
> openSUSE packages can choose some of theirs easy bugs and mark them as
> Junior Jobs. Then anybody from community can volunteer and fix these
> issues. These tasks will be easily fixable and their purpose is to let
> people learn how to contribute and to create some easy task so anybody
> can join and start participating.
>
> [1] http://en.opensuse.org/Junior_Jobs
>
>
> --
> Miroslav Suchy
> Red Hat Satellite Engineering
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From foss.mailinglists at gmail.com  Mon Oct 19 07:12:56 2009
From: foss.mailinglists at gmail.com (sankarshan)
Date: Mon, 19 Oct 2009 12:42:56 +0530
Subject: [Fwd: Junior Jobs]
In-Reply-To: <4ADC0818.8010705@redhat.com>
References: <4ADC0818.8010705@redhat.com>
Message-ID: <35586fc00910190012i3c5da1a6j438fcf06c63510cb@mail.gmail.com>

2009/10/19 Miroslav Such? :
> May be good idea for Fedora as well...

 : look for the
EasyFix keyword (hat tip to stickster here)

/sankarshan


-- 
sankarshan mukhopadhyay




From ioannis.ganotis at siemens-enterprise.com  Mon Oct 19 07:35:34 2009
From: ioannis.ganotis at siemens-enterprise.com (Ganotis, Ioannis)
Date: Mon, 19 Oct 2009 09:35:34 +0200
Subject: RPM Database issue
Message-ID: <9603789295EDD54D8D16E3B416F3226C0BC8027EF2@DEMCHP99E15MSX.ww902.siemens.net>

Hi All,

While working with package management, installing/uninstalling various RPMs,
I came up with a question regarding the RPM Database where package-related information
is being stored.

The default location of the system's RPM_DB is at /var/lib/rpm. I can then create a second (private)
RPM_DB (e.g. /var/lib/my_rpm) with the 'rpm --dbpath /var/lib/my_rpm --initdb' command.
After that, using the '--dbpath' option I can select at which RPM_DB an RPM is going to be
installed. The problem is when I try to install an RPM in the private RPM_DB which has dependencies
on other packages which exist in the system's default RPM_DB.

Is there any way for the second RPM_DB to somehow extend the default DB while installing a package ?
This means that when installing an RPM in the private RPM_DB it should first check for dependencies in BOTH
RPM databases.
Also is there any way for "synchronizing" two or more RPM Databases ?

Thanks for your time in advance

With best regards,
Ioannis Ganotis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jreznik at redhat.com  Mon Oct 19 08:16:09 2009
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Mon, 19 Oct 2009 10:16:09 +0200
Subject: [Fwd: Junior Jobs]
In-Reply-To: 
References: <4ADC0818.8010705@redhat.com>
	
Message-ID: <200910191016.09202.jreznik@redhat.com>

On Monday 19 October 2009 08:47:38 Orcan Ogetbil wrote:
> 2009/10/19 Miroslav Such?
> 
> > May be good idea for Fedora as well...
> > Mirek
> >
> >
> > -------- P?vodn? zpr?va --------
> > P?edm?t: [opensuse-packaging] Junior Jobs
> > Datum: Tue, 13 Oct 2009 14:46:58 +0200
> > Od: Michal Hrusecky
> >
> > Hi,
> >
> > lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of
> > openSUSE packages can choose some of theirs easy bugs and mark them as
> > Junior Jobs. Then anybody from community can volunteer and fix these
> > issues. These tasks will be easily fixable and their purpose is to let
> > people learn how to contribute and to create some easy task so anybody
> > can join and start participating.
> >
> > [1] http://en.opensuse.org/Junior_Jobs
> 
> Not a bad idea. I think at least the KDE project does a similar thing.
> Maybe other projects do this too.
> 
> Implementation of this brings back the question: Shall the packagers
> have an option to give commit access to every other packager and not
> just to provenpackagers? This question arises because provenpackagers
> are by definition not "junior"s.

For juniors jobs it's better to send patch and maintainers can review it. And 
if you're interested in one package (or group of packages like KDE), you can 
then ask for CVS commit...

Jaroslav
 
> The last time I talked to cvs folks, they told me that the code is
> there for this option but it needs some testing. Any progress there?
> 
> Orcan
> 

-- 
Jaroslav ?ezn?k 
Associate Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.                               http://cz.redhat.com/



From josephine.tannhauser at googlemail.com  Mon Oct 19 09:42:59 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 11:42:59 +0200
Subject: gnaughty (was: Re: Who do I send to get a package removed...)
In-Reply-To: <20091017215859.GB11299@blackhare>
References: <1255652847.19029.29.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<20091016171914.GA23555@clingman.lan> <4AD8D7BA.60707@gmail.com>
	<20091017140641.01c1b360@faldor.intranet>
	<385866f0910170659k63489546n92b099005d404c48@mail.gmail.com>
	<20091017144412.GA2431@blackhare>
	<385866f0910171414j2c584f2ei16eace7862ba2ac8@mail.gmail.com>
	<385866f0910171430q1201f857x852cac3bf6aedd3a@mail.gmail.com>
	<20091017215859.GB11299@blackhare>
Message-ID: <3668e9f50910190242k7cd3025dx323076e9d730857e@mail.gmail.com>

This discussion smells of fish!
<  <  <  <
>  >  >  >
-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mike.cloaked at gmail.com  Mon Oct 19 09:46:12 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Mon, 19 Oct 2009 09:46:12 +0000 (UTC)
Subject: How can I get a response on a specific bz report concerning
	sane-backends?
Message-ID: 

Two weeks ago I reported https://bugzilla.redhat.com/show_bug.cgi?id=527137

Since this could well affect quite a few people with scanners of various
flavours I though that some response to the report might have been seen on the
above link by now. Am I barking up the wrong tree or is my diagnosis that there
is a packaging bug correct?

How does one know if the maintainer concerned has seen the report, and if there
is no action following up on the bz, how does one ask for a second maintainer to
have a look at it?

Thanks.



From mcepl at redhat.com  Mon Oct 19 10:12:10 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Mon, 19 Oct 2009 12:12:10 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>	<1255621588.2314.45.camel@adam.local.net>	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>		<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
Message-ID: 

Dne 19.10.2009 02:39, Ismael Olea napsal(a):
> bibletime.i586 : BibleTime is an easy to use Bible study tool for KDE
> gnomesword.i586 : GNOME-based Bible research tool
> kio_sword.i586 : A lightweight frontend for the Sword Bible project for KDE
> sword.i586 : Free Bible Software Project
> sword-devel.i586 : Development files for the sword project
> xiphos.i586 : Bible study and research tool
> 
> Maybe some parents would like to keep their children apart of contents
> like these.

Let's not go into comparing mental illness with Bibles (and any replies
which will try to do so, go mercilessly to /dev/null). For purposes of
our discussion what's material is that neither sword-derived programs
nor gnaughty bring any content (there are no Bibles in all those
packages, you have to download them from the Sword website), so any
discussion about that are pure loss.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Never ascribe to malice that which is adequately explained by
stupidity.
    -- Napoleon Bonaparte (or many other people to whom this
       quote is ascribed)



From josephine.tannhauser at googlemail.com  Mon Oct 19 10:30:06 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 12:30:06 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1255669121.11249.3.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
Message-ID: <3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>

2009/10/16 Steven James Drinnan 

> I recently installed gestikk. And to my horror one of the dialogs said.
>
> (Check Box) F*** off
>
> No lie,
>
> So how does one recommend that this be removed.
>
> Steven
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

the word fuck is in many sourcecodes. Mostly as comment.
Do you think, that we should remove these comments too?

Btw. It's harder to see the word "fuck" in some spec-files!

-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From loupgaroublond at gmail.com  Mon Oct 19 10:44:30 2009
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Mon, 19 Oct 2009 12:44:30 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
Message-ID: <7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>

2009/10/19 Josephine Tannh?user :
>
>
> 2009/10/16 Steven James Drinnan 
>>
>> I recently installed gestikk. And to my horror one of the dialogs said.
>>
>> (Check Box) F*** off
>>
>> No lie,
>>
>> So how does one recommend that this be removed.
>>
>> Steven
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> the word fuck is in many sourcecodes. Mostly as comment.
> Do you think, that we should remove these comments too?
>
> Btw. It's harder to see the word "fuck" in some spec-files!

I think brainfuck is a fine language, and if you do some swear word
statistics on the Fedora wiki, you can see my appreciation for
brainfuck.

Do we block it because of some trolling?

This is really a stupid thread.

-Yaakov



From josephine.tannhauser at googlemail.com  Mon Oct 19 10:59:36 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 12:59:36 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
Message-ID: <3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>

2009/10/19 Yaakov Nemoy 

> This is really a stupid thread.
>

Of course! But who is the stupid?
The one who started this thread or those  who answered it or those who
wasting so much time to discuss about nonsense?

-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From josephine.tannhauser at googlemail.com  Mon Oct 19 11:03:26 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 13:03:26 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
Message-ID: <3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>

btw. I'm still missing Godwin's Law. It's a must for stupid
nonsense-discussions, but I'm not missing it!
-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ismael at olea.org  Mon Oct 19 11:20:07 2009
From: ismael at olea.org (Ismael Olea)
Date: Mon, 19 Oct 2009 13:20:07 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
Message-ID: <22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>

On Mon, Oct 19, 2009 at 1:03 PM, Josephine Tannh?user <
josephine.tannhauser at googlemail.com> wrote:

> btw. I'm still missing Godwin's Law. It's a must for stupid
> nonsense-discussions, but I'm not missing it!



So, you are acting clearly as a Nazi!


-- 

Ismael Olea

http://olea.org/diario/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From josephine.tannhauser at googlemail.com  Mon Oct 19 11:26:21 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 13:26:21 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
Message-ID: <3668e9f50910190426p36e0c0fbkd23ad4d204a2bb58@mail.gmail.com>

OMG
Even 4chan is funnier than you
-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From thomasj at fedoraproject.org  Mon Oct 19 11:27:22 2009
From: thomasj at fedoraproject.org (Thomas Janssen)
Date: Mon, 19 Oct 2009 13:27:22 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
Message-ID: 

2009/10/19 Ismael Olea :
>
>
> On Mon, Oct 19, 2009 at 1:03 PM, Josephine Tannh?user
>  wrote:
>>
>> btw. I'm still missing Godwin's Law. It's a must for stupid
>> nonsense-discussions, but I'm not missing it!
>
> 
> So, you are acting clearly as a Nazi!
> 

Well, this thread was disputable. But you crossed a line here. Some
idiots on this planet grab the same statement all the time when they
run out of arguments. This is not even acceptable as a "tongue in the
cheek".

-- 
LG Thomas

Dubium sapientiae initium



From josephine.tannhauser at googlemail.com  Mon Oct 19 11:34:05 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 13:34:05 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
Message-ID: <3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>

2009/10/19 Thomas Janssen 

> Well, this thread was disputable. But you crossed a line here. Some
> idiots on this planet grab the same statement all the time when they
> run out of arguments. This is not even acceptable as a "tongue in the
> cheek". 
>

+1

-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From guido.grazioli at gmail.com  Mon Oct 19 11:53:41 2009
From: guido.grazioli at gmail.com (Guido Grazioli)
Date: Mon, 19 Oct 2009 13:53:41 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	<3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>
Message-ID: <2f984ea00910190453o35e6b0d0u681ff13f974e859a@mail.gmail.com>

Come on guys, let this thread die.
In other words, shut the
export YUM_I_LIKE_BAD_WORDS=1 && yum -y install fuck
up  ;-)

-- 
Guido Grazioli 
Via Parri 11 48011 - Alfonsine (RA)
Mobile: +39 347 1017202 (10-18)
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograziol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From josephine.tannhauser at googlemail.com  Mon Oct 19 11:59:50 2009
From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=)
Date: Mon, 19 Oct 2009 13:59:50 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <2f984ea00910190453o35e6b0d0u681ff13f974e859a@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	<3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>
	<2f984ea00910190453o35e6b0d0u681ff13f974e859a@mail.gmail.com>
Message-ID: <3668e9f50910190459h74bb3497seb3c38cec5615786@mail.gmail.com>

2009/10/19 Guido Grazioli 

> Come on guys, let this thread die.
> In other words, shut the
> export YUM_I_LIKE_BAD_WORDS=1 && yum -y install fuck
> up  ;-)


f.u.c.k.u.p. the computer of Hagbard Celine?
My favorite quote about fuck is from southpark - bigger longer uncut:

I think I know the answer Mr. Garison
me mme mme me me mme mme
Shut up fat boy!
Hey! Don't call me fat you fuckin' Jew!
Eric, did you just say the F-word?
Jew?
No. He's talkin' about fuck,  you can't say fuck in school you fuckin' fat
ass.
Kyle!
Why the fuck not?!
Eric!
Dude you just said fuck again!
Stanley!
Fuck!
kenny!
What's the big deal, it doesnt hurt anybaody. Fuck fuckitty fuck fuck fuck.
How would you like to go see the school councilor?
How would you like to suck my balls?
Huh!!! (gasps)
What did you say?!
Oh, I'm sorry, I'm sorry, What I ment to say was, HOW WOULD YOU LIKE TO SUCK
MY BALLS, MR.GARISON?!

Do you remember?
-- 
Josephine "Fine" Tannh?user
2.6.29.6-213.fc11.i586
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From skvidal at fedoraproject.org  Mon Oct 19 12:03:08 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 19 Oct 2009 08:03:08 -0400 (EDT)
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190459h74bb3497seb3c38cec5615786@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	<3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>
	<2f984ea00910190453o35e6b0d0u681ff13f974e859a@mail.gmail.com>
	<3668e9f50910190459h74bb3497seb3c38cec5615786@mail.gmail.com>
Message-ID: 



On Mon, 19 Oct 2009, Josephine Tannh?user wrote:

> 2009/10/19 Guido Grazioli 
>       Come on guys, let this thread die.
>       In other words, shut the
>       export YUM_I_LIKE_BAD_WORDS=1 && yum -y install fuck
>       up? ;-)
> 
> 
> 
> Do you remember?


I think this thread has gone on quite far enough.

please stop.


-sv

From berrange at redhat.com  Mon Oct 19 12:05:06 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 19 Oct 2009 13:05:06 +0100
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190459h74bb3497seb3c38cec5615786@mail.gmail.com>
References: <1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	<3668e9f50910190434m382fe60aj37fad9ee31644133@mail.gmail.com>
	<2f984ea00910190453o35e6b0d0u681ff13f974e859a@mail.gmail.com>
	<3668e9f50910190459h74bb3497seb3c38cec5615786@mail.gmail.com>
Message-ID: <20091019120506.GH27871@redhat.com>

On Mon, Oct 19, 2009 at 01:59:50PM +0200, Josephine Tannh?user wrote:
> 2009/10/19 Guido Grazioli 
> 
> > Come on guys, let this thread die.
> > In other words, shut the
> > export YUM_I_LIKE_BAD_WORDS=1 && yum -y install fuck
> > up  ;-)
> 
> 
> f.u.c.k.u.p. the computer of Hagbard Celine?
> My favorite quote about fuck is from southpark - bigger longer uncut:

[snip]

Please stop this now, it has gone way beyond discussing real technical
issues, and is just being gratuitously offensive & thus off-topic for
this list. There are plenty of places on the internet for this. The 
Fedora development list is not one of them.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From rawhide at fedoraproject.org  Mon Oct 19 12:42:37 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 19 Oct 2009 12:42:37 +0000
Subject: rawhide report: 20091019 changes
Message-ID: <20091019124237.GA21711@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 19 06:15:05 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From mcepl at redhat.com  Mon Oct 19 13:26:05 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Mon, 19 Oct 2009 15:26:05 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>	<1255622587.2894.10.camel@localhost.localdomain>	<1255652847.19029.29.camel@localhost.localdomain>	<1255654244.2894.98.camel@localhost.localdomain>	<1255669121.11249.3.camel@mylaptop.myhome>	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
Message-ID: 

Dne 19.10.2009 13:27, Thomas Janssen napsal(a):
> Well, this thread was disputable. But you crossed a line here. Some
> idiots on this planet grab the same statement all the time when they
> run out of arguments. This is not even acceptable as a "tongue in the
> cheek".

http://en.wikipedia.org/wiki/Godwin%27s_Law -- you apparently don't know
what we are talking about (or, more likely, I got caught).

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Faithful love is what people look for in a person; ...
   -- Proverbs 19:22 (NJB)



From alsadi at gmail.com  Mon Oct 19 14:47:44 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 19 Oct 2009 17:47:44 +0300
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	
Message-ID: <385866f0910190747r1c7ad420n2b521d15913243e9@mail.gmail.com>

> https://fedoraproject.org/wiki/Offensive_Packages

hahaha! what a bad joke!

not only you advertise pornography packages

you give conclusions and according to which things you called
"offensive packages" made a pornography packages equivalent to
glorifying  God (minbar package) how cheap

this listing is more silly that my x-proposal
https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents

and as I said before this is nothing but  advertising pornography packages

note: within one work day, I can make an equivalent to gn*ty but with
that very site replaces with one which shows the propaganda of some
group/organization which you might consider  to be terrorist
organization, and then file a package review ticket I want to see how
would you reject it with something that does not apply to gn*ty

sorry to use this fictitious example but this is the only way you are
programmed to accept censorship.

the only thing gn*ty package do is to advertise a single site the only
thing that the site do is to show videos that are illegal in many
places (merely pornography)

yes there are no guidelines in fedora packaging against advertising
and there are no guidelines in fedora packaging against pornography
but the same can be said Nazi propaganda advertising.
or any similar topic

I guess it's the time to remove gn*ty from fedora's repos
no need for censorship, it's just the community as this is the second
long thread about it is made.

one of the four fundamentals  in fedora is Friends ie. the community
ie. us. You and me.



From skvidal at fedoraproject.org  Mon Oct 19 14:50:30 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 19 Oct 2009 10:50:30 -0400 (EDT)
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <385866f0910190747r1c7ad420n2b521d15913243e9@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
	<7f692fec0910190344v79b945a7ta3788d1de7cf6197@mail.gmail.com>
	<3668e9f50910190359j48532c2t29db3c6490917ba1@mail.gmail.com>
	<3668e9f50910190403h15979276k623d26d4977dd103@mail.gmail.com>
	<22a365930910190420n2a6b8f0epdd2334d2c45b7cfc@mail.gmail.com>
	
	
	<385866f0910190747r1c7ad420n2b521d15913243e9@mail.gmail.com>
Message-ID: 



On Mon, 19 Oct 2009, Muayyad AlSadi wrote:

>> https://fedoraproject.org/wiki/Offensive_Packages
>
> hahaha! what a bad joke!
>

This thread needs to stop, too.

If you wish to continue discussing it - please do so off-list.

Thank You,
-sv



From orion at cora.nwra.com  Mon Oct 19 14:58:42 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 19 Oct 2009 08:58:42 -0600
Subject: koji noarch build errors
Message-ID: <4ADC7EA2.2070204@cora.nwra.com>

This has happened two for two now:

http://koji.fedoraproject.org/koji/getfile?taskID=1754220&name=build.log

ENTER do(['bash', '--login', '-c', 'rpmbuild -bb --target noarch 
--nodeps builddir/build/SPECS/eclipse-ptp.spec'], False, 
'/var/lib/mock/dist-f13-build-624079-90585/root/', None, 86400, True, 0, 
424, 102, None, logger=)
Executing command: ['bash', '--login', '-c', 'rpmbuild -bb --target 
noarch --nodeps builddir/build/SPECS/eclipse-ptp.spec']
error: Architecture is not included: noarch
Building target platforms: noarch
Building for target noarch
Child returncode was: 1

This was on:
  	 xenbuilder4.fedora.phx.redhat.com
previous on:
  	 x86-2.fedora.phx.redhat.com

Any ideas?

-- 
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 mike.cloaked at gmail.com  Mon Oct 19 15:05:26 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Mon, 19 Oct 2009 15:05:26 +0000 (UTC)
Subject: How can I get a response on a specific bz report
	concerning	sane-backends?
References: 
Message-ID: 

Mike Cloaked  gmail.com> writes:

> How does one know if the maintainer concerned has seen the report, 
> and if there is no action following up on the bz, how does one ask
> for a second maintainer to have a look at it?

I was not aware the maintainer was away - this is now answered in the bz.





From mike.cloaked at gmail.com  Mon Oct 19 16:08:10 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Mon, 19 Oct 2009 16:08:10 +0000 (UTC)
Subject: Thunderbird 3.0rc1
References: 
Message-ID: 

Mike Cloaked  gmail.com> writes:

> 
> Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 
> when it is released? 
> 
> >From MozillaWiki I note that the plan is: Start build: 3rd November 
> (est 10th Nov) so this will likely be around 3 weeks away.

I just started using Thunderbird 3.0pre (via the upstream nightly tarball)
 and it is much better than the 3.0b4 version that is in f11...






From ebenes at redhat.com  Mon Oct 19 16:19:18 2009
From: ebenes at redhat.com (Eduard Benes)
Date: Mon, 19 Oct 2009 12:19:18 -0400 (EDT)
Subject: Fwd: [Test-Announce] 2009-10-20 Confined Users Test Day
In-Reply-To: <1329863194.436591255965883798.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <1946183128.749251255969158343.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Hi friends,

I would like to invite you to join Confined Users test day which will be
held tomorrow, 2009-10-20. Please come out to Freenode IRC #fedora-test-day
or #fedora-selinux and help us improve SELinux policy. You will need a machine
with updated Fedora 12 or rawhide (virtualized machines are welcomed too :-)).
Testing is pretty straightforward: all requirements and test cases are described
in details here[1].

SELinux Confined Users is a feature where SELinux role is assigned to each user
and where the SELinux policy controls what the user can do/access on the system.

Dan Walsh and Miroslav Grepl will help us to solve issues.

Thanks to all who come along to help test!

Milos Malik


P.S.: There is no bravery in running Fedora/RHEL with disabled SELinux ;-)

1: https://fedoraproject.org/wiki/Test_Day:2009-10-20

-- 
fedora-test-list mailing list
fedora-test-list at redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list



From belegdol at gmail.com  Mon Oct 19 16:29:31 2009
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 19 Oct 2009 18:29:31 +0200
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 
Message-ID: 

W dniu 18.10.2009 22:45, Mike Cloaked pisze:
> Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 when it
> is released? 
> 
>>From MozillaWiki I note that the plan is: Start build: 3rd November (est 10th
> Nov) so this will likely be around 3 weeks away.
> 
> Thanks
> 
What makes you think it won't?

Julian



From mike.cloaked at gmail.com  Mon Oct 19 16:58:01 2009
From: mike.cloaked at gmail.com (Mike Cloaked)
Date: Mon, 19 Oct 2009 16:58:01 +0000 (UTC)
Subject: Thunderbird 3.0rc1
References: 
	
Message-ID: 

Julian Sikorski  gmail.com> writes:

> > Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 
> when it is released? 

> What makes you think it won't?
> 
> Julian
> 

I did wonder what the process would be after all the kerfuffle with TB3.0b4 

I presume that it will go out with GLODA and smart folders turned OFF?



From mail at marcus-moeller.de  Mon Oct 19 17:14:42 2009
From: mail at marcus-moeller.de (Marcus Moeller)
Date: Mon, 19 Oct 2009 19:14:42 +0200
Subject: buildinstall on Fedora 11
Message-ID: 

Hi all,

I am trying to respin a F11 DVD while I have noticed that anaconda
packages are not part of the DVDs 'Packages' directory, so
buildinstall fails on this package tree.

How is buildinstall used on current Fedora releases? Or has it been
replaced, already?

Best Regards
Marcus



From jkeating at redhat.com  Mon Oct 19 17:34:54 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Oct 2009 10:34:54 -0700
Subject: buildinstall on Fedora 11
In-Reply-To: 
References: 
Message-ID: <1255973694.32487.9.camel@localhost.localdomain>

On Mon, 2009-10-19 at 19:14 +0200, Marcus Moeller wrote:
> Hi all,
> 
> I am trying to respin a F11 DVD while I have noticed that anaconda
> packages are not part of the DVDs 'Packages' directory, so
> buildinstall fails on this package tree.
> 
> How is buildinstall used on current Fedora releases? Or has it been
> replaced, already?
> 

Buildinstall takes multiple repo arguments.  Just ensure that one of
your repos has the anaconda package set in it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From dgboles at gmail.com  Mon Oct 19 17:36:59 2009
From: dgboles at gmail.com (David)
Date: Mon, 19 Oct 2009 13:36:59 -0400
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 	
	
Message-ID: <4ADCA3BB.4080505@gmail.com>

On 10/19/2009 12:58 PM, Mike Cloaked wrote:
> Julian Sikorski  gmail.com> writes:
> 
>>> Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 
>> when it is released? 
> 
>> What makes you think it won't?
>>
>> Julian
>>
> 
> I did wonder what the process would be after all the kerfuffle with TB3.0b4 
> 
> I presume that it will go out with GLODA and smart folders turned OFF?
> 


GLODA  -  Global Search and Indexer  -  is defaulted disabled from
Mozilla. I am forever seeing users talking about having 'emails going
back years' and this feature would help in searching for that question
and answer that might solve a problem. And once indexing is done the
first time it is not a 'machine stopper' to use it enabled.

However you don't need it if you only want to count the emails and never
search them.  ;-)

-- 


  David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: 

From jlaska at redhat.com  Mon Oct 19 18:08:45 2009
From: jlaska at redhat.com (James Laska)
Date: Mon, 19 Oct 2009 14:08:45 -0400
Subject: [Test-Announce] 2009-10-20 Confined Users Test Day
In-Reply-To: <1329863194.436591255965883798.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
References: <1329863194.436591255965883798.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <1255975725.2354.52.camel@localhost.localdomain>

On Mon, 2009-10-19 at 11:24 -0400, Milos Malik wrote:
> Hi friends,
> 
> I would like to invite you to join Confined Users test day which will be
> held tomorrow, 2009-10-20. Please come out to Freenode IRC #fedora-test-day
> or #fedora-selinux and help us improve SELinux policy. You will need a machine
> with updated Fedora 12 or rawhide (virtualized machines are welcomed too :-)).
> Testing is pretty straightforward: all requirements and test cases are described
> in details here[1]. 
> 
> SELinux Confined Users is a feature where SELinux role is assigned to each user
> and where the SELinux policy controls what the user can do/access on the system.
> 
> Dan Walsh and Miroslav Grepl will help us to solve issues.
> 
> Thanks to all who come along to help test!
> 
> Milos Malik
> 
> 
> P.S.: There is no bravery in running Fedora/RHEL with disabled SELinux ;-)
> 
> 1: https://fedoraproject.org/wiki/Test_Day:2009-10-20

I like the challenge! :)  Thanks for taking the time to plan and prepare
this test day.  I've made some minor wiki modifications to the test day
page.  Would it make sense to create individual test case pages for each
of the listed test cases?  We typically recommend using the template:
https://fedoraproject.org/wiki/Template:QA/Test_Case

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mike.cloaked at gmail.com  Mon Oct 19 19:05:24 2009
From: mike.cloaked at gmail.com (mcloaked)
Date: Mon, 19 Oct 2009 19:05:24 +0000 (UTC)
Subject: Thunderbird 3.0rc1
References: 	
	
	<4ADCA3BB.4080505@gmail.com>
Message-ID: 

David  gmail.com> writes:

> > I presume that it will go out with GLODA and smart folders turned OFF?
> > 
> 
> GLODA  -  Global Search and Indexer  -  is defaulted disabled from
> Mozilla. I am forever seeing users talking about having 'emails going
> back years' and this feature would help in searching for that question
> and answer that might solve a problem. And once indexing is done the
> first time it is not a 'machine stopper' to use it enabled.
> 
> However you don't need it if you only want to count the emails and never
> search them.  

I don't know if you saw the rather extended thread recently concerning the 
release of thunderbird 3.0b4 but there were significant problems with GLODA. 
 Having it off by default and make sure users are informed that it is 
available is the better way to do things - however in 3.0b4 it was ON 
by default and caused a huge headache for users with significant volumes 
of mail across multiple accounts.

I'll refer to the thread if you missed it.






From mike.cloaked at gmail.com  Mon Oct 19 19:10:53 2009
From: mike.cloaked at gmail.com (mcloaked)
Date: Mon, 19 Oct 2009 19:10:53 +0000 (UTC)
Subject: Status of touchpad support in F12 for kdm?
References: 
	
Message-ID: 

Kevin Kofler  chello.at> writes:

> No, tapping is disabled by default distrowide, there's nothing KDM can or 
> should do about this. This is an intentional decision by the upstream 
> Synaptics driver developers. Most touchpads have dedicated buttons you can 
> press, which are much harder to click accidentally than it is to trigger an 
> unwanted tapping click.
> 
>         Kevin Kofler

Given the recent long thread concerning upstream decisions about defaults in
Thunderbird 3.0beta4 it seems to me that just because upstream makes a specific
decision does not always mean that is the best decision. What happens
when releasing a package in Fedora can be given a possible better decision
than upstream at times - I wonder what others feel about the defaults in this
 case for touchpad behaviour?




From mike at cchtml.com  Mon Oct 19 19:15:32 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 19 Oct 2009 14:15:32 -0500
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 			<4ADCA3BB.4080505@gmail.com>
	
Message-ID: <4ADCBAD4.9060504@cchtml.com>

mcloaked on 10/19/2009 02:05 PM wrote:
> 
> I don't know if you saw the rather extended thread recently concerning the 
> release of thunderbird 3.0b4 but there were significant problems with GLODA. 
>  Having it off by default and make sure users are informed that it is 
> available is the better way to do things - however in 3.0b4 it was ON 
> by default and caused a huge headache for users with significant volumes 
> of mail across multiple accounts.


I'm not intending to start another long thread on it so any reply after
this will not see a matching one from me.

The total user count of people having issues with GLODA was 2. Two. Dos.

I have multiple accounts and run with GLODA enabled per default across
multiple machines with multiple architectures. Each account alone has at
least 2.5k to 5k emails ranging from about 5 years and at least 20 or so
folders and sub folders. No machine hang-ups.



From pbrobinson at gmail.com  Mon Oct 19 19:20:40 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 19 Oct 2009 20:20:40 +0100
Subject: the mass rebuild and i586 rpms?
Message-ID: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>

Hi All,

I thought with the mass rebuild the i586 rpms were suppose to be gone
but it seems the F-12 repository still has quite a few of them. Are
the old packages that should have been blocked, ones that's that
weren't rebuilt for some reason or something that I've just missed?

Peter



From drago01 at gmail.com  Mon Oct 19 19:43:48 2009
From: drago01 at gmail.com (drago01)
Date: Mon, 19 Oct 2009 21:43:48 +0200
Subject: Status of touchpad support in F12 for kdm?
In-Reply-To: 
References: 
	 
Message-ID: 

On Mon, Oct 19, 2009 at 9:10 PM, mcloaked  wrote:
> Kevin Kofler  chello.at> writes:
>
>> No, tapping is disabled by default distrowide, there's nothing KDM can or
>> should do about this. This is an intentional decision by the upstream
>> Synaptics driver developers. Most touchpads have dedicated buttons you can
>> press, which are much harder to click accidentally than it is to trigger an
>> unwanted tapping click.
>>
>> ? ? ? ? Kevin Kofler
>
> Given the recent long thread concerning upstream decisions about defaults in
> Thunderbird 3.0beta4 it seems to me that just because upstream makes a specific
> decision does not always mean that is the best decision. What happens
> when releasing a package in Fedora can be given a possible better decision
> than upstream at times - I wonder what others feel about the defaults in this
> ?case for touchpad behaviour?

Well that does not quite work if the fedora maintainer is the upstream
maintainer.

He would either change both or none.



From craftjml at gmail.com  Mon Oct 19 20:42:28 2009
From: craftjml at gmail.com (Jud Craft)
Date: Mon, 19 Oct 2009 16:42:28 -0400
Subject: Status of touchpad support in F12 for kdm?
In-Reply-To: 
References: 
	 
	
Message-ID: <20d6441a0910191342r2d72beb8w9df02785eab3e10b@mail.gmail.com>

> I suppose at least this does work even if upstream policy is not to make this
> available - however for a newbie just installing F11 and wanting this available
> it is not obvious from install notes or release notes as far as I remember?

It's important to note...

The reason why you can't configure any of this stuff ISN'T because
upstream wants to stop you from enabling touchpad tapping.

GNOME has never actually supported "global settings" on the login
screen in the first place.  The login screen runs a special account
that doesn't have the same flexibility as a normal user (who can make
his own settings).

Notice how we can't configure the volume at login either?

I'm just glad they finally got global network settings on the login
screen.  (Not sure when that comes to Fedora though...)


And guess what?  Windows doesn't let the average user configure any of
this stuff either.  You've -still- got to go mess with weird registry
settings.  So it's not specifically a GNOME thing.



From mcepl at redhat.com  Mon Oct 19 21:17:23 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Mon, 19 Oct 2009 23:17:23 +0200
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 			<4ADCA3BB.4080505@gmail.com>
	
Message-ID: <4ADCD763.9000403@redhat.com>

Dne 19.10.2009 21:05, mcloaked napsal(a):
> I don't know if you saw the rather extended thread recently concerning the 
> release of thunderbird 3.0b4 but there were significant problems with GLODA. 

Were there any other problems than "OMG, indexing my 2.5GB of emails
takes a lot of CPU and time, so I why is this crap switched on"?

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

And religious texts are a bit like software standards, the
interpretation is always the tricky and complicated bit.
    -- Alan Cox



From mcepl at redhat.com  Mon Oct 19 21:17:23 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Mon, 19 Oct 2009 23:17:23 +0200
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 			<4ADCA3BB.4080505@gmail.com>
	
Message-ID: <4ADCD763.9000403@redhat.com>

Dne 19.10.2009 21:05, mcloaked napsal(a):
> I don't know if you saw the rather extended thread recently concerning the 
> release of thunderbird 3.0b4 but there were significant problems with GLODA. 

Were there any other problems than "OMG, indexing my 2.5GB of emails
takes a lot of CPU and time, so I why is this crap switched on"?

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

And religious texts are a bit like software standards, the
interpretation is always the tricky and complicated bit.
    -- Alan Cox



From sundaram at fedoraproject.org  Mon Oct 19 21:17:34 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 20 Oct 2009 02:47:34 +0530
Subject: Thunderbird 3.0rc1
In-Reply-To: <4ADCBAD4.9060504@cchtml.com>
References: 			<4ADCA3BB.4080505@gmail.com>	
	<4ADCBAD4.9060504@cchtml.com>
Message-ID: <4ADCD76E.7050301@fedoraproject.org>

On 10/20/2009 12:45 AM, Michael Cronenworth wrote:
> mcloaked on 10/19/2009 02:05 PM wrote:
>>
>> I don't know if you saw the rather extended thread recently concerning the 
>> release of thunderbird 3.0b4 but there were significant problems with GLODA. 
>>  Having it off by default and make sure users are informed that it is 
>> available is the better way to do things - however in 3.0b4 it was ON 
>> by default and caused a huge headache for users with significant volumes 
>> of mail across multiple accounts.
> 
> 
> I'm not intending to start another long thread on it so any reply after
> this will not see a matching one from me.
> 
> The total user count of people having issues with GLODA was 2. Two. Dos.

.. Umm. No.  There were more feedback from many others c.f. fedoraforum
for example.

Rahul



From dgboles at gmail.com  Mon Oct 19 21:33:05 2009
From: dgboles at gmail.com (David)
Date: Mon, 19 Oct 2009 17:33:05 -0400
Subject: Thunderbird 3.0rc1
In-Reply-To: 
References: 			<4ADCA3BB.4080505@gmail.com>
	
Message-ID: <4ADCDB11.1050903@gmail.com>

On 10/19/2009 3:05 PM, mcloaked wrote:
> David  gmail.com> writes:
> 
>>> I presume that it will go out with GLODA and smart folders turned OFF?
>>>
>>
>> GLODA  -  Global Search and Indexer  -  is defaulted disabled from
>> Mozilla. I am forever seeing users talking about having 'emails going
>> back years' and this feature would help in searching for that question
>> and answer that might solve a problem. And once indexing is done the
>> first time it is not a 'machine stopper' to use it enabled.
>>
>> However you don't need it if you only want to count the emails and never
>> search them.  
> 
> I don't know if you saw the rather extended thread recently concerning the 
> release of thunderbird 3.0b4 but there were significant problems with GLODA. 
>  Having it off by default and make sure users are informed that it is 
> available is the better way to do things - however in 3.0b4 it was ON 
> by default and caused a huge headache for users with significant volumes 
> of mail across multiple accounts.
> 
> I'll refer to the thread if you missed it.


I had no problems with Thunderbird 3.0b4 or any of the nightly builds
that have lead up to it. Once or twice over the many months I had a
'bad day' but it was corrected by the next night's build. I should say
that these are Mozilla nightly builds and not Fedora's. I currently am
using 3.0pre dated Oct 19, 2009. I turned on GLODA as soon as it was
available. It took some time to complete the first time. From then on it
takes nothing that I can never notice unless I see the information show
up in the activity notification area.

As for the thread you mentioned? I saw that I seem to recall that no one
really had a problem other than the amount of time it took to do the
indexing the first time. But I did not find that a major problem or
experience any others with the 3.0b4 series. And to repeat myself -
these were *not* Fedora supplied packages. They came directly from Mozilla.

I also get my Firefox nightly-build packages directly from Mozilla.
Mozilla does not force all of those language packages on me as Fedora
does.  :-)

But seriously if you think that this is really important you should
write a Bugzilla on it so that the maintainer(s) will know about this.
Writing to a mailing list normally only generates message threads.
-- 


  David



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: 

From jlaska at redhat.com  Tue Oct 20 00:27:07 2009
From: jlaska at redhat.com (James Laska)
Date: Mon, 19 Oct 2009 20:27:07 -0400 (EDT)
Subject: [Test-Announce] 2009-10-20 Confined Users Test Day
In-Reply-To: <1746151923.810551255998353958.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <488234036.810651255998427847.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "James Laska"  wrote:

> On Mon, 2009-10-19 at 11:24 -0400, Milos Malik wrote:
> > Hi friends,
> > 
> > I would like to invite you to join Confined Users test day which
> will be
> > held tomorrow, 2009-10-20. Please come out to Freenode IRC
> #fedora-test-day
> > or #fedora-selinux and help us improve SELinux policy. You will need
> a machine
> > with updated Fedora 12 or rawhide (virtualized machines are welcomed
> too :-)).
> > Testing is pretty straightforward: all requirements and test cases
> are described
> > in details here[1]. 
> > 
> > SELinux Confined Users is a feature where SELinux role is assigned
> to each user
> > and where the SELinux policy controls what the user can do/access on
> the system.
> > 
> > Dan Walsh and Miroslav Grepl will help us to solve issues.
> > 
> > Thanks to all who come along to help test!
> > 
> > Milos Malik
> > 
> > 
> > P.S.: There is no bravery in running Fedora/RHEL with disabled
> SELinux ;-)
> > 
> > 1: https://fedoraproject.org/wiki/Test_Day:2009-10-20
> 
> I like the challenge! :)  Thanks for taking the time to plan and
> prepare
> this test day.  I've made some minor wiki modifications to the test
> day
> page.  Would it make sense to create individual test case pages for
> each
> of the listed test cases?  We typically recommend using the template:
> https://fedoraproject.org/wiki/Template:QA/Test_Case

Just a heads up, at the suggestion of Adam, I posted QA spin [1] images that include the following test day packages:

  selinux-policy-targeted
  policycoreutils-gui
  setroubleshoot
  audit
  xguest

Links to the live images and sha256sum's are on the wiki page.

Thanks,
James

[1] https://fedoraproject.org/wiki/QA_Test_Day_Spin



From steven at scc.hk  Tue Oct 20 02:00:21 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Tue, 20 Oct 2009 10:00:21 +0800
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<200910150055.18568.cemeyer@u.washington.edu>
	<5256d0b0910150059p7d505bf2ue3dea7a618791901@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	<3668e9f50910190330j72ab6609y54551ea0012d51a9@mail.gmail.com>
Message-ID: <1256004022.4785.7.camel@mylaptop.myhome>



 
On Mon, 2009-10-19 at 12:30 +0200, Josephine Tannh?user wrote:
> 
> 
> 2009/10/16 Steven James Drinnan 
>         I recently installed gestikk. And to my horror one of the
>         dialogs said.
>         
>         (Check Box) F*** off
>         
>         No lie,
>         
>         So how does one recommend that this be removed.
>         
>         Steven
>         
>         --
>         fedora-devel-list mailing list
>         fedora-devel-list at redhat.com
>         https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> the word fuck is in many sourcecodes. Mostly as comment.
> Do you think, that we should remove these comments too?

Short answer yes, should we as programmers need to use such language.

> 
> Btw. It's harder to see the word "fuck" in some spec-files!
> 
> -- 
> Josephine "Fine" Tannh?user
> 2.6.29.6-213.fc11.i586
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From steven at scc.hk  Tue Oct 20 02:09:34 2009
From: steven at scc.hk (Steven James Drinnan)
Date: Tue, 20 Oct 2009 10:09:34 +0800
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com>
	<1255621588.2314.45.camel@adam.local.net>
	<5256d0b0910150853u11f8b9fah4873588a8dde515a@mail.gmail.com>
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
Message-ID: <1256004576.4785.17.camel@mylaptop.myhome>

Wow this has really hit sore point, It just goes to show that there pro
and cons on both sides. 

Like or not people want the ability to filter content that that deem
unfit.


Thats why I asked about it in the first place the concern was simple, I
have young children and I installed a screamingly innocent package. That
had foul language. Some of may not be too concerned but it does put
Fedora's rep in question.



A user/parent/employer should be able to restrict what content is
allowed or not allowed. 

And what is the best way to accomplish this. 

Well any ideas, for me Package Kit would be the way to go. Then users
could add the packages or groups to the exclude list. Maybe an extra
password (optional) for parents / supervisors.

Or like was mentioned  a way to create a YUM exclude list. 

Stop this bickering lets try and solve an issue.

Steven


On Mon, 2009-10-19 at 11:47 +1000, Eric Springer wrote: 
> On Mon, Oct 19, 2009 at 10:39 AM, Ismael Olea  wrote:
> > My 0.02?
> 
> More like your troll-cents. Despite the absurdity (of this whole
> thing, in fact) I've added a category and included it. And people can
> make up their own minds.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

From bruno at wolff.to  Tue Oct 20 02:19:34 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 19 Oct 2009 21:19:34 -0500
Subject: [Test-Announce] 2009-10-20 Confined Users Test Day
In-Reply-To: <1255975725.2354.52.camel@localhost.localdomain>
References: <1329863194.436591255965883798.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
	<1255975725.2354.52.camel@localhost.localdomain>
Message-ID: <20091020021934.GB27259@wolff.to>

On Mon, Oct 19, 2009 at 14:08:45 -0400,
  James Laska  wrote:
> 
> I like the challenge! :)  Thanks for taking the time to plan and prepare
> this test day.  I've made some minor wiki modifications to the test day
> page.  Would it make sense to create individual test case pages for each
> of the listed test cases?  We typically recommend using the template:
> https://fedoraproject.org/wiki/Template:QA/Test_Case

I mentioned this to Dan a while back, but one thing I would find nice is
a tool to reset your policy back to the default for (supposedly) installed
policy. When things get stuffed up it's possible that you get to where you
can't update the active policy. Switching to another policy (say minimal)
and back is two full file relabels. I found that nuking the active policy
in an unsupported manner and yum reinstalling the current policy relabels
a much smaller number of files and seems to be a lot quicker.
I don't know exactly what I did that caused problems, but the three machines
I yum updated to f12 all had issues handling updates to the targeted policy.
I do have local modules installed and some local fcontext rules, that may
have been a factor in this.
semanage is limited you can't change everything at once and the result of
a single semanage run needs to be consistant and you can't always do that.
I'll try to go through the test cases eventually, but it probably won't
be tomorrow.



From rakesh.pandit at gmail.com  Tue Oct 20 04:53:41 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 20 Oct 2009 10:23:41 +0530
Subject: Package Review Stats for last 7 days ending 18th Oct
Message-ID: 

Top three FAS account holders who have completed reviewing "Package
review" components on bugzilla for last 7 days ending 18th Oct were
Steve Traylen, Parag AN(????) and Nicolas Mailhot.


Steve Traylen : 8

	https://bugzilla.redhat.com/show_bug.cgi?id=516514
	https://bugzilla.redhat.com/show_bug.cgi?id=516516
	https://bugzilla.redhat.com/show_bug.cgi?id=516519
	https://bugzilla.redhat.com/show_bug.cgi?id=516520
	https://bugzilla.redhat.com/show_bug.cgi?id=516521
	https://bugzilla.redhat.com/show_bug.cgi?id=516533
	https://bugzilla.redhat.com/show_bug.cgi?id=526738
	https://bugzilla.redhat.com/show_bug.cgi?id=527996


Parag AN(????) : 6

	https://bugzilla.redhat.com/show_bug.cgi?id=528220
	https://bugzilla.redhat.com/show_bug.cgi?id=528272
	https://bugzilla.redhat.com/show_bug.cgi?id=528889
	https://bugzilla.redhat.com/show_bug.cgi?id=528893
	https://bugzilla.redhat.com/show_bug.cgi?id=528904
	https://bugzilla.redhat.com/show_bug.cgi?id=528906


Nicolas Mailhot : 4

	https://bugzilla.redhat.com/show_bug.cgi?id=526633
	https://bugzilla.redhat.com/show_bug.cgi?id=528949
	https://bugzilla.redhat.com/show_bug.cgi?id=529494
	https://bugzilla.redhat.com/show_bug.cgi?id=529196


Jason Tibbitts : 3

	https://bugzilla.redhat.com/show_bug.cgi?id=521671
	https://bugzilla.redhat.com/show_bug.cgi?id=524071
	https://bugzilla.redhat.com/show_bug.cgi?id=525005


Dominic Hopf : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=523540
	https://bugzilla.redhat.com/show_bug.cgi?id=524605


Martin Gieseking : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=526746
	https://bugzilla.redhat.com/show_bug.cgi?id=526351


Matt Domsch : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=527049
	https://bugzilla.redhat.com/show_bug.cgi?id=528847


Orion Poplawski : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=226207
	https://bugzilla.redhat.com/show_bug.cgi?id=521895


Peter Robinson : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=513420
	https://bugzilla.redhat.com/show_bug.cgi?id=514351


Rex Dieter : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=525759
	https://bugzilla.redhat.com/show_bug.cgi?id=526115


Alexey Torkhov : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=526855


Christoph Wickert : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528290


Dominik 'Rathann' Mierzejewski : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=496133


Jan Klepek : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=504479


Jarod Wilson : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=459855


Kevin Fenzi : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529465


Mamoru Tasaka : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=515898


Matthew Booth : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=517488


Peter Lemenkov : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527704


Praveen K Paladugu : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=502596


Roman Rakus : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=502843


Tim Lauridsen : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528288


Toshio Ernie Kuratomi : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528841



Total reviews modified: 46
Merge Reviews: 1
Review Requests: 45

This report by generated by bzReviewReport.py.
The source is available at:
https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
Please submit patches or bug reports at: https://fedorahosted.org/triage/

-- 
Rakesh Pandit
https://fedoraproject.org/
freedom, friends, features, first



From lsof at nodata.co.uk  Tue Oct 20 06:08:36 2009
From: lsof at nodata.co.uk (nodata)
Date: Tue, 20 Oct 2009 08:08:36 +0200
Subject: Thunderbird 3.0rc1
In-Reply-To: <4ADCD763.9000403@redhat.com>
References: 			<4ADCA3BB.4080505@gmail.com>	
	<4ADCD763.9000403@redhat.com>
Message-ID: <4ADD53E4.3030308@nodata.co.uk>

Am 2009-10-19 23:17, schrieb Mat?j Cepl:
> Dne 19.10.2009 21:05, mcloaked napsal(a):
>> I don't know if you saw the rather extended thread recently concerning the
>> release of thunderbird 3.0b4 but there were significant problems with GLODA.
>
> Were there any other problems than "OMG, indexing my 2.5GB of emails
> takes a lot of CPU and time, so I why is this crap switched on"?

To stop thunderbird searching through 2.5GB of emails each time you run 
a search?



From fedora at camperquake.de  Tue Oct 20 06:45:40 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 08:45:40 +0200
Subject: Eternal 'good file hashes' list
Message-ID: <20091020084540.622d5d28@dhcp03.addix.net>

Hi.

I was wondering the other day how much space the file information (i.e. the
stuff that rpm -V checks against) takes up in an RPM file. And, going from
there, how much space we would waste over the years if we kept this
information for every RPM ever built by koji.

The idea would be to have a database of known good file information that is
separate from the local RPM database, so one may burn this information to
a bootable CD (or DVD) to be able to verify the integrity of the local
files (as long as the files came from a fedora built RPM file, that is).
Another possibility would be to load the information from the net, on
demand.

How much data are we talking about, roughly?



From tmraz at redhat.com  Tue Oct 20 08:20:17 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 20 Oct 2009 10:20:17 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020084540.622d5d28@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>
Message-ID: <1256026818.31423.11.camel@vespa.frost.loc>

On Tue, 2009-10-20 at 08:45 +0200, Ralf Ertzinger wrote: 
> Hi.
> 
> I was wondering the other day how much space the file information (i.e. the
> stuff that rpm -V checks against) takes up in an RPM file. And, going from
> there, how much space we would waste over the years if we kept this
> information for every RPM ever built by koji.
> 
> The idea would be to have a database of known good file information that is
> separate from the local RPM database, so one may burn this information to
> a bootable CD (or DVD) to be able to verify the integrity of the local
> files (as long as the files came from a fedora built RPM file, that is).
> Another possibility would be to load the information from the net, on
> demand.
> 
> How much data are we talking about, roughly?

What would this be good for? Actually for some files it would be a known
bad file hashes because these files (binaries or scripts) would contain
known vulnerabilities and so knowing that you have a file that was once
included in Fedora does not guarantee you almost anything.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From nicolas.mailhot at laposte.net  Tue Oct 20 08:39:10 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Oct 2009 10:39:10 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <1256026818.31423.11.camel@vespa.frost.loc>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
Message-ID: <3a688e8843cd046ea7b6913c14f06cda.squirrel@arekh.dyndns.org>



Le Mar 20 octobre 2009 10:20, Tomas Mraz a ?crit :

> What would this be good for? Actually for some files it would be a known
> bad file hashes because these files (binaries or scripts) would contain
> known vulnerabilities and so knowing that you have a file that was once
> included in Fedora does not guarantee you almost anything.

It would help a lot tripwire-like apps. When the hash db is generated on-site
it typically can not distinguish between changes done by legit updates and
manual changes.

-- 
Nicolas Mailhot




From fedora at camperquake.de  Tue Oct 20 08:45:34 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 10:45:34 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <1256026818.31423.11.camel@vespa.frost.loc>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
Message-ID: <20091020104534.3a4cc847@dhcp03.addix.net>

Hi.

On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote:

> What would this be good for? Actually for some files it would be a
> known bad file hashes because these files (binaries or scripts) would
> contain known vulnerabilities and so knowing that you have a file
> that was once included in Fedora does not guarantee you almost
> anything.

I'm not sure I follow you here. Containing a known vulnerability in a
binary file has nothing to do with the hash.



From xjakub at fi.muni.cz  Tue Oct 20 09:48:50 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Tue, 20 Oct 2009 11:48:50 +0200
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
Message-ID: <4ADD8782.10801@fi.muni.cz>

Hi,

On 10/19/2009 09:20 PM, Peter Robinson wrote:
> Hi All,
>
> I thought with the mass rebuild the i586 rpms were suppose to be gone
> but it seems the F-12 repository still has quite a few of them. Are
> the old packages that should have been blocked, ones that's that
> weren't rebuilt for some reason or something that I've just missed?
>
> Peter

Most probably those are the packages which failed during the mass 
rebuild...there are still plenty of them:

http://mjakubicek.fedorapeople.org/need-rebuild.html

Regards,
Milos



From xjakub at fi.muni.cz  Tue Oct 20 09:50:55 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Tue, 20 Oct 2009 11:50:55 +0200
Subject: koji noarch build errors
In-Reply-To: <4ADC7EA2.2070204@cora.nwra.com>
References: <4ADC7EA2.2070204@cora.nwra.com>
Message-ID: <4ADD87FF.6080306@fi.muni.cz>

Hi Orion,

- does local mock build fail too?
- could you upload the SRPM somewhere?

Regards,
Milos

On 10/19/2009 04:58 PM, Orion Poplawski wrote:
> This has happened two for two now:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1754220&name=build.log
>
> ENTER do(['bash', '--login', '-c', 'rpmbuild -bb --target noarch
> --nodeps builddir/build/SPECS/eclipse-ptp.spec'], False,
> '/var/lib/mock/dist-f13-build-624079-90585/root/', None, 86400, True, 0,
> 424, 102, None, logger= 0x2b9b7f1f7c10>)
> Executing command: ['bash', '--login', '-c', 'rpmbuild -bb --target
> noarch --nodeps builddir/build/SPECS/eclipse-ptp.spec']
> error: Architecture is not included: noarch
> Building target platforms: noarch
> Building for target noarch
> Child returncode was: 1
>
> This was on:
> xenbuilder4.fedora.phx.redhat.com
> previous on:
> x86-2.fedora.phx.redhat.com
>
> Any ideas?
>



From fedora at camperquake.de  Tue Oct 20 10:00:32 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 12:00:32 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <1256026818.31423.11.camel@vespa.frost.loc>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
Message-ID: <20091020120032.503bb46b@dhcp03.addix.net>

Hi.

On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote:

> What would this be good for?

To expand on the motivation for this:

The idea is to have a list of known good file hashes to test your local
files against, if you have reason not to trust your local RPM database
(which may have been compromised as well). The way I'd do that right now
would involve getting the corrensponding RPM files from a mirror (hoping
there still is a mirror for that) and then... well, then it gets a bit
fuzzy as I don't know how to check the checksum of a file against the
metadata in a RPM file but I'm sure it can be done somehow.

So I thought that there may be an easier way to do this, so I'm asking,
in a first step, for an estimate of the data size we're talking about,
as I have no idea how much metadata each file in an RPM takes up, how
many RPMs/files koji builds each day on average and so on.



From pbrobinson at gmail.com  Tue Oct 20 10:17:14 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 20 Oct 2009 11:17:14 +0100
Subject: F-12 upgrade experience with Dell D630
Message-ID: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>

Hi All,

As the Dell Latitude D630 is one of the more common devices that smolt
reports being used by Fedora I thought I'd mention my upgrade
experience and issues for F-12.

Probably the two usual things that people query are grahics and wifi.
The model I have has the Intel IWL-4965AGN device which as expected
works fine.

I'm having a few issues with the nouveau driver with plymouth in that
it doesn't work at all but if I remove all the options from the kernel
boot line it gets to X and apart from some initial corruption as GDM
comes up its OK from there. I have no idea how to debug this.
Thankfully the issue with detection of my 2nd screen at 1680x1050 is
no longer and it now works great. Laptop screen is 1440x900 and I use
to have to run a manual 'xrandr --auto' to get it to detect both
resolutions properly and configure it.

Probably the most annoying is the breakage of sound. This seems to
have every other kernel/alsa/pulseaudio update and was an issue on and
off right through F-11 as well so its not exactly surprising but also
disappointing that one of the most common devices running Fedora has
sound broken on a semi regular basis. Again some pointers in debugging
this so it can be fixed by F-12 final would be great.

The only other very minor issue I see is that the icon spacing on the
gnome panels is massive!

Peter



From pmatilai at laiskiainen.org  Tue Oct 20 11:18:03 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 20 Oct 2009 14:18:03 +0300 (EEST)
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020120032.503bb46b@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
Message-ID: 

On Tue, 20 Oct 2009, Ralf Ertzinger wrote:

> Hi.
>
> On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote:
>
>> What would this be good for?
>
> To expand on the motivation for this:
>
> The idea is to have a list of known good file hashes to test your local
> files against, if you have reason not to trust your local RPM database
> (which may have been compromised as well). The way I'd do that right now
> would involve getting the corrensponding RPM files from a mirror (hoping
> there still is a mirror for that) and then... well, then it gets a bit
> fuzzy as I don't know how to check the checksum of a file against the
> metadata in a RPM file but I'm sure it can be done somehow.
>
> So I thought that there may be an easier way to do this, so I'm asking,
> in a first step, for an estimate of the data size we're talking about,
> as I have no idea how much metadata each file in an RPM takes up, how
> many RPMs/files koji builds each day on average and so on.

Well, for example the file hashes (which are simply arrays of 
hex-strings in headers) of the 2871 packages on Fedora-11-x86_64-DVD.iso:
[pmatilai at localhost Packages]$ rpm -qap --qf "[%{filedigests}\n]" *.rpm |wc
  430716  373388 24141084

To make any use of that data you'll obviously need the file names too, so:
[pmatilai at localhost Packages]$ rpm -qap --qf "[%{filedigests} %{filenames}\n]" *.rpm |wc
  430716  804104 47467960

...but rpm stores paths indexed by directory, storing flat paths as 
returned by %{filenames} wastes tonnes of space. Also note that 
directories and symlinks dont have associated hashes. And of course 
there's a whole lot more metadata that you need to take into account when 
verifying: user+group, permissions, symlink targets etc.

 	- Panu -



From sgallagh at redhat.com  Tue Oct 20 11:35:11 2009
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Tue, 20 Oct 2009 07:35:11 -0400
Subject: Broken dependencies - thunderbird-3.0-2.8.b4.fc11
Message-ID: <4ADDA06F.2020800@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

$SUBJECT is currently in the stable repositories, but no matching
version of thunderbird-lightning was pushed.

thunderbird < 3.0-2.7.b5 is needed by package
thunderbird-lightning-1.0-0.7.20090715hg.fc11.x86_64

This looks like the problem is due to a broken package-naming format.

Clearly, the dependency check on thunderbird-lightning is meant to say
that it will work until beta 5 of thunderbird is available.
Unfortunately, RPMs version recognition doesn't work the way this
package is expecting.

Can the thunderbird-lightning maintainer push a trivial update to the
package to fix this dependency check, please?

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrdoGsACgkQeiVVYja6o6P9hwCgpXten8bS8/sm1E7Bk62Msd2b
hLEAnjjKNK2UxMngpO7woQodhistcgtK
=E6tZ
-----END PGP SIGNATURE-----



From rawhide at fedoraproject.org  Tue Oct 20 11:37:53 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 20 Oct 2009 11:37:53 +0000
Subject: rawhide report: 20091020 changes
Message-ID: <20091020113753.GA7762@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 20 06:15:06 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package mathgl
        Cross-platform library for making high-quality scientific graphics
Updated Packages:

DeviceKit-disks-008-1.fc12
--------------------------
* Sun Oct 18 2009 Matthias Clasen  - 008-1.fc12
- Update to 008
- See http://lists.freedesktop.org/archives/devkit-devel/2009-October/000513.html


anerley-0.1.7-1.fc12
--------------------
* Fri Oct 16 2009 Peter Robinson  0.1.7-1
- New upstream 0.1.7 release


anjal-0.1-1.fc12
----------------

bisho-0.16-1.fc12
-----------------
* Mon Oct 19 2009 Peter Robinson  0.16-1
- New upstream 0.16 release


bitlbee-1.2.4-1.fc12
--------------------
* Sat Oct 17 2009 Robert Scheck  1.2.4-1
- Upgrade to 1.2.4


btrfs-progs-0.19-9.fc12
-----------------------
* Mon Oct 19 2009 Josef Bacik  0.19-8
- bring btrfs-progs uptodate with upstream, adds destroy ioctl and fixes
  converter

* Mon Oct 19 2009 Josef Bacik  0.19-9
- release bump because I messed up the tagging


cheese-2.28.1-1.fc12
--------------------
* Mon Oct 19 2009 Matthias Clasen   2.28.1-1
- Update to 2.28.1


cups-1.4.1-10.fc12
------------------
* Mon Oct 19 2009 Tim Waugh  1:1.4.1-10
- Fixed German translation (bug #529575, STR #3380).


devhelp-2.28.1-1.fc12
---------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


eog-2.28.1-1.fc12
-----------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


eog-plugins-2.28.1-1.fc12
-------------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


epiphany-2.28.1-1.fc12
----------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1
- See http://mail.gnome.org/archives/ftp-release-list/2009-October/msg00049.html


epiphany-extensions-2.28.1-1.fc12
---------------------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


file-roller-2.28.1-1.fc12
-------------------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


gcalctool-5.28.1-1.fc12
-----------------------
* Mon Oct 19 2009 Matthias Clasen  - 5.28.1-1
- Update to 5.28.1, misc bug fixes


gcc-4.4.2-4.fc12
----------------
* Sun Oct 18 2009 Jakub Jelinek  4.4.2-4
- update from gcc-4_4-branch
  - PRs c++/37204, c++/37766, c++/37875, c++/38798, c++/40092,
	libstdc++/40654, libstdc++/40826
- fix VTA ICE on invalid pointer arithmetics (#529512)

* Sat Oct 17 2009 Jakub Jelinek  4.4.2-3
- fix VTA handling in the scheduler (PR debug/41535)
- fix up %check section to be able to find ecj1

* Fri Oct 16 2009 Jakub Jelinek  4.4.2-2
- update from gcc-4_4-branch
  - PR target/40913
- VTA backports
  - PR debug/41717
- fix Ada .eh_frame generation (PR debug/40521)

* Thu Oct 15 2009 Jakub Jelinek  4.4.2-1
- update from gcc-4_4-branch
  - GCC 4.4.2 release
  - PRs middle-end/22072, target/41665
- don't emit -Wpadded warnings for builtin structures
- don't generate .eh_frame, but generate .debug_frame when -g and none of
  -fasynchronous-unwind-tables/-fexceptions/-funwind-tables is used
  (PR debug/40521)

* Wed Oct 14 2009 Jakub Jelinek  4.4.1-22
- update from gcc-4_4-branch
  - PRs target/26515, target/38948
  - fix s390{,x} BLKmode symbol handling
  - fix i?86 testqi splitter (#528206, PR target/41680)
- VTA backports
  - introduce debug temps (PRs debug/41264, debug/41338, debug/41343,
    debug/41447, target/41693)
  - build debug stmts on updates (PR debug/41616)
  - fix another with/without -save-temps debug info difference
    (#526841, PR preprocessor/41543)
  - fix invalid ranges in .debug_loc section (PR debug/41695)

* Sat Oct 10 2009 Jakub Jelinek  4.4.1-21
- update from gcc-4_4-branch
  - fix s390{,x} prefetch for pre-z10 CPUs (#524552)
- VTA backports
  - fix debug info differences with/without -save-temps
    (PR preprocessor/41445)
- fix ICE with small BLKmode returning call (#516028,
  PR rtl-optimization/41646)


gnome-games-2.28.1-1.fc12
-------------------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


gnome-media-2.28.1-3.fc12
-------------------------
* Sun Oct 18 2009 Matthias Clasen  2.28.1-2
- Cosmetic fixes to the layout of gnome-volume-control
- Fix the --page commandline option

* Sun Oct 18 2009 Matthias Clasen  2.28.1-3
- Fix some visual glitches at startup


gnome-packagekit-2.28.1-1.fc12
------------------------------
* Mon Oct 19 2009 Richard Hughes   - 2.28.1-1
- Update to 2.28.1
- Translation updates
- Simulate removal correctly to fix removing packages
- Ignore cleanup and finished packages when we a simulating remove or install
- If command line contains (deleted) the original binary is invalid. Fixes #524873
- Never show the role text in the GpkWatch tooltip
- Run the helpers with interaction 'hide-finished,hide-warnings' as we are handling failure


gnome-power-manager-2.28.1-1.fc12
---------------------------------
* Mon Oct 19 2009 Richard Hughes   - 2.28.1-1
- Update to 2.28.1
- Translation updates
- Remove upstreamed patch
- Help the kernel through its sleep key confusion
- Correctly set the focus on the last used device in gnome-power-statistics
- Do not hide some radio buttons depending on the current machine state
- Throttle screensaver before suspend/hibernate


gok-2.28.1-1.fc12
-----------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


gstreamer-plugins-good-0.10.16-4.fc12
-------------------------------------
* Mon Oct 19 2009 Bastien Nocera  0.10.16-4
- Fix pulsesink not advertising the StreamVolume interface

* Sat Oct 17 2009 Bastien Nocera  0.10.16-3
- Finally fix pulsesink volume lowering problems (#488532)


gucharmap-2.28.1-1.fc12
-----------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


gwget-1.0.4-1.fc12
------------------
* Tue Oct 20 2009 Christoph Wickert  - 1.0.4-1
- Update to 1.0.4, fixes crash with GTK >= 2.18

* Sun Oct 04 2009 Christoph Wickert  - 1.0.3-1
- Update to 1.0.3
- Remove Vincent's patch as it was upstreamed


lensfun-0.2.4-1.fc12
--------------------
* Sun Oct 18 2009 Rex Dieter  0.2.4-1
- lensfun-0.2.4 (#529506)


libbonoboui-2.24.2-2.fc12
-------------------------
* Sat Oct 17 2009 Matthias Clasen  - 2.24.2-2
- Fix a possible infinite loop


libdaemon-0.14-1.fc12
---------------------
* Sun Oct 18 2009 Lennart Poettering  - 0.14-1
- New release 0.14


libgpod-0.7.2-5.fc12
--------------------
* Mon Oct 19 2009 Bastien Nocera  0.7.2-4
- Update UTF-16 string parsing patch

* Mon Oct 19 2009 Bastien Nocera  0.7.2-5
- Fix UTF-16 string parsing patch again

* Sat Oct 17 2009 Bastien Nocera  0.7.2-3
- Fix crasher when parsing UTF-16 strings with a BOM (#517642)


libtool-2.2.6-15.fc12
---------------------
* Mon Oct 19 2009 Jakub Jelinek  2.2.6-15
- Rebuild for gcc 4.4.2

* Wed Aug 12 2009 Ville Skytt?  - 2.2.6-14
- Use lzma compressed upstream tarball.


libvirt-0.7.1-13.fc12
---------------------
* Mon Oct 19 2009 Mark McLoughlin  - 0.7.1-13
- Misc fixes to qemu machine types handling
- A couple of XML formatting fixes

* Tue Oct 13 2009 Mark McLoughlin  - 0.7.1-12
- Fix restore of qemu guest using raw save format (#523158)


livecd-tools-030-1.fc12
-----------------------
* Mon Oct 19 2009 Warren Togami  - 030-1
- Tell dracut not to ask for LUKS passwords or activate mdraid sets
- Silence the /etc/modprobe.conf deprecation warning


moblin-panel-people-0.0.7-1.fc12
--------------------------------
* Fri Oct 16 2009 Peter Robinson  0.0.7-1
- New upstream 0.0.7 release


mousetweaks-2.28.1-1.fc12
-------------------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


orca-2.28.1-1.fc12
------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


paps-0.6.8-11.fc12
------------------
* Wed Oct 14 2009 Akira TAGOH  - 0.6.9-11
- Fix code that deal with CPI parameter to be accurate. (#524883)


poppler-0.12.1-1.fc12
---------------------
* Mon Oct 19 2009 Rex Dieter  - 0.12.1-1
- poppler-0.12.1
- deprecate xpdf/pdftohtml Conflicts/Obsoletes


qemu-0.11.0-7.fc12
------------------
* Mon Oct 19 2009 Mark McLoughlin  - 2:0.11.0-7
- Fix potential segfault from too small MSR_COUNT (#528901)


seahorse-2.28.1-1.fc12
----------------------
* Mon Oct 19 2009 Tomas Bzatek  2.28.1-1
- Update to 2.28.1


seahorse-plugins-2.28.1-1.fc12
------------------------------
* Mon Oct 19 2009 Tomas Bzatek  2.28.1-1
- Update to 2.28.1


syncevolution-0.9-2.fc12
------------------------
* Fri Oct 16 2009 Peter Robinson  - 0.9-2
- Enable the gtk and moblin guis


system-config-httpd-1.4.6-1.fc12
--------------------------------
* Mon Oct 05 2009 Phil Knirsch  1.4.6-1
- Some more translation updates
- Renamed sr at Latn.po to sr at latin.po (#426593)
- Switched to hashlib from md5

* Fri Oct 02 2009 Phil Knirsch  1.4.5-1
- Lotsa language updates
- Several fixes from Radek Novacek for the S-c-tools cleanup project:
- Resolves: #493830,#493841,#493895,#508068


system-config-kdump-2.0.1-1.fc12
--------------------------------
* Fri Oct 02 2009 Roman Rakus  - 2.0.1-1
- Update to version 2.0.1


tuned-0.2.5-0.1.fc12
--------------------
* Mon Oct 19 2009 Marcela Ma?l??ov?  0.2.5-0.3
- new release


vinagre-2.28.1-1.fc12
---------------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1


vino-2.28.1-1.fc12
------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


webkitgtk-1.1.15.2-1.fc12
-------------------------
* Thu Oct 15 2009 Matthias Clasen  - 1.1.15.2-1
- Update to 1.1.15.2, which has multiple crash and other fixes
- See https://lists.webkit.org/pipermail/webkit-gtk/2009-October/000040.html


yaboot-1.3.14-22.fc12
---------------------
* Mon Oct 19 2009 Tony Breed  - 1.3.14-20
- Only require hfsutils on fedora and rhel <= 5

* Mon Oct 19 2009 Tony Breed  - 1.3.14-21
- Explicitly build a DEBUG=1 version of yaboot to aid in debugging

* Mon Oct 19 2009 Tony Breed  - 1.3.14-22
- Calling of_open() on a LINUX_NATIVE parttions seesm to work but end up with a
  garbage file.  Add check to of_open to skip these parttions (#526021).


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 47



From fedora at camperquake.de  Tue Oct 20 11:44:07 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 13:44:07 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: 
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
Message-ID: <20091020134407.5bfa36ed@dhcp03.addix.net>

Hi.

On Tue, 20 Oct 2009 14:18:03 +0300 (EEST), Panu Matilainen wrote:

> To make any use of that data you'll obviously need the file names
> too, so:
> [pmatilai at localhost Packages]$ rpm -qap --qf "[%{filedigests} %{filenames}\n]" *.rpm |wc
>  430716  804104 47467960

That has to be databased somehow, probably compressed... hm.
Might not turn out all that bad spacewise.


> ...but rpm stores paths indexed by directory, storing flat paths as 
> returned by %{filenames} wastes tonnes of space. Also note that 
> directories and symlinks dont have associated hashes. And of course 
> there's a whole lot more metadata that you need to take into account
> when verifying: user+group, permissions, symlink targets etc.

So basically the RPM file content without the actual file contents,
right?



From skvidal at fedoraproject.org  Tue Oct 20 12:00:50 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 20 Oct 2009 08:00:50 -0400 (EDT)
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020134407.5bfa36ed@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
Message-ID: 



On Tue, 20 Oct 2009, Ralf Ertzinger wrote:

> Hi.
>
> On Tue, 20 Oct 2009 14:18:03 +0300 (EEST), Panu Matilainen wrote:
>
>> To make any use of that data you'll obviously need the file names
>> too, so:
>> [pmatilai at localhost Packages]$ rpm -qap --qf "[%{filedigests} %{filenames}\n]" *.rpm |wc
>>  430716  804104 47467960
>
> That has to be databased somehow, probably compressed... hm.
> Might not turn out all that bad spacewise.
>
>
>> ...but rpm stores paths indexed by directory, storing flat paths as
>> returned by %{filenames} wastes tonnes of space. Also note that
>> directories and symlinks dont have associated hashes. And of course
>> there's a whole lot more metadata that you need to take into account
>> when verifying: user+group, permissions, symlink targets etc.
>
> So basically the RPM file content without the actual file contents,
> right?

You could, of course, just have koji keep the pkgs and then you could use 
the existing metadata to grab the header from the pkgs and access the 
information that way.

-sv



From john.brown009 at gmail.com  Tue Oct 20 12:03:34 2009
From: john.brown009 at gmail.com (TK009)
Date: Tue, 20 Oct 2009 08:03:34 -0400
Subject: Broken dependencies - thunderbird-3.0-2.8.b4.fc11
In-Reply-To: <4ADDA06F.2020800@redhat.com>
References: <4ADDA06F.2020800@redhat.com>
Message-ID: <20091020120334.GA10456@blackhare>

On Tue, Oct 20, 2009 at 07:35:11AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> $SUBJECT is currently in the stable repositories, but no matching
> version of thunderbird-lightning was pushed.
> 
> thunderbird < 3.0-2.7.b5 is needed by package
> thunderbird-lightning-1.0-0.7.20090715hg.fc11.x86_64
> 
> This looks like the problem is due to a broken package-naming format.
> 
> Clearly, the dependency check on thunderbird-lightning is meant to say
> that it will work until beta 5 of thunderbird is available.
> Unfortunately, RPMs version recognition doesn't work the way this
> package is expecting.
> 
> Can the thunderbird-lightning maintainer push a trivial update to the
> package to fix this dependency check, please?
> 
> - -- 
> Stephen Gallagher

https://bugzilla.redhat.com/show_bug.cgi?id=529304
> RHCE 804006346421761
> 
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrdoGsACgkQeiVVYja6o6P9hwCgpXten8bS8/sm1E7Bk62Msd2b
> hLEAnjjKNK2UxMngpO7woQodhistcgtK
> =E6tZ
> -----END PGP SIGNATURE-----
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From fedora at camperquake.de  Tue Oct 20 12:12:38 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 14:12:38 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: 
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
Message-ID: <20091020141238.371d90bb@dhcp03.addix.net>

Hi.

On Tue, 20 Oct 2009 08:00:50 -0400 (EDT), Seth Vidal wrote:

> You could, of course, just have koji keep the pkgs and then you could
> use the existing metadata to grab the header from the pkgs and access
> the information that way.

That would be a solution, of course, but keeping the files forever and a day
would surely be prohibitive in terms of disk space.



From jkeating at redhat.com  Tue Oct 20 13:56:32 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Oct 2009 06:56:32 -0700
Subject: Fedora 12 Beta now available!
Message-ID: <1256046992.4242.24.camel@localhost.localdomain>

Fedora is a leading edge, free and open source operating system that
continues to deliver innovative features to many users, with a new
release every six months. We have reached the Fedora 12 Beta, the last
important development milestone of Fedora 12. Only critical bug fixes
will be pushed as updates leading up to the general release of Fedora
12, scheduled to be released in mid-November. We invite you to join us
and participate in making Fedora 12 a solid release by downloading,
testing, and providing us your valuable feedback.

http://fedoraproject.org/get-prerelease

Of course, this is a beta release, some problems may still be lurking.
Should you trip across one of them, be sure it gets fixed before release
by reporting your discovery at:

https://bugzilla.redhat.com/

Thank you!

What's New in Fedora 12?

* Optimized performance - All software packages on 32-bit (x86_32)
architecture have been compiled for i686 systems with special
optimization for Intel Atom processors used in many netbooks but without
losing compatibility with the overwhelming majority of CPUs. There is a
list of the rare CPUs which will no longer be supported.

* Smaller and faster updates - In Fedora 11, the optional yum-presto
plugin, developed by Fedora contributor Jonathan Dieter, reduced update
size by transmitting only the changes in the updated packages. Now, the
plugin is installed by default. Also, RPMs now use XZ rather than gzip
for compression, providing smaller package sizes without the memory and
CPU penalties associated with bzip2. This lets us fit more software into
each Fedora image, and uses less space on mirrors, making their
administrators' lives a little easier. Thanks to the Fedora
infrastructure team for their work in generating delta RPMs.

* NetworkManager broadband and other enhancements - NetworkManager,
originally developed by Red Hat's Dan Williams, was introduced in Fedora
7 and has become the de facto network configuration solution for
distributions everywhere. Enhancements to NetworkManager make both
system-wide connections and mobile broadband connections easier than
ever. Signal strength and network selection are available for choosing
the best mobile broadband connection when you're on the road. Bluetooth
PAN support offers a simple click through process to access the Internet
from your mobile phone. NetworkManager can now configure always-on and
static address connections directly from the desktop. PolicyKit
integration has been added so configuration management can be done via
central policy where needed. IPv6 support has also been improved.

* Next-generation (Ogg) Theora video - For several years, Theora, the
open and free format not encumbered by known patents has provided a way
for freedom-loving users to share video. Fedora 12 includes the new
Theora 1.1, which achieves near-H.264 quality, meeting the expectations
of demanding users with crisp, vibrant media in both streaming and
downloadable form. Thanks to the work of the Xiph.Org Foundation's
Christopher "Monty" Montgomery, sponsored by Red Hat, other Xiph
developers, and the contribution of Mozilla.org, Firefox 3.5 can deliver
free media on the web out of the box, using the Theora video and Vorbis
audio formats even better than the previous release of Fedora.

* Graphics support improvements - Fedora 12 introduces experimental 3D
support for AMD Radeon HD 2400 and later graphics cards. To try it out,
install the mesa-dri-drivers-experimental package. On many cards, this
support should allow desktop effects to be used. Kernel mode setting
(KMS) support, which was introduced on AMD hardware in Fedora 10 and
extended to Intel hardware in Fedora 11, is now extended to NVIDIA
hardware as well, meaning the great majority of systems now benefit from
the smooth, fully-graphical startup sequence made possible by KMS. The
Fedora graphical startup sequence now works better on systems with
multiple monitors. Also on multiple monitor systems, the desktop will
now automatically be spread across all monitors by default, rather than
having all monitors display the same output, including on NVIDIA chips
(where multiple monitor spanning was not possible without manual
configuration changes in Fedora 11). Systems with NVIDIA graphics chips
also gain initial support for suspend and resume functionality via the
default Nouveau driver. Initial support for the new DisplayPort display
connector has been added for Intel graphics chips. Support for Nvidia
and ATI systems is already under rapid development and will be included
in the next release of Fedora. Thanks to the Red Hat Xorg team including
Adam Jackson (X server), Kristian H?gsberg (Intel driver), Dave Airlie
and Jerome Glisse (Radeon driver for AMD), and Ben Skeggs (Nouveau
driver for NVIDIA).

* Virtualization improvements - Not content with all the improvements in
Fedora 11, we've kicked virtualization based on KVM up another notch in
Fedora 12. There are extensive improvements in performance, management,
resource sharing, and still more security enhancements. A new library
(libguestfs) and an interactive tool (guestfish) are now available for
directly accessing and modifying virtual machine disk images.

* Automatic reporting of crashes and SELinux issues - Abrt, a tool to
help non-power users report crashes to Bugzilla with a few mouse clicks,
is now enabled by default. Abrt collects detailed information
automatically and helps developers identify and resolve issues faster,
improving the quality of individual upstream components and Fedora. The
SELinux alert monitoring tool has also added the ability to report
SELinux issues to Bugzilla quickly and easily with just a couple of
clicks.

* New Dracut initrd generation tool - Up until Fedora 11, the boot
system (initial ram disk or initrd) used to boot Fedora was monolithic,
very distribution specific and didn't provide much flexibility. This has
been replaced with Dracut, an initial ram disk generation tool with an
event-based framework designed to be distribution-independent thanks to
the Dracut team including Harald Hoyer, Jeremy Katz, Dave Jones and many
others. It has been also adopted by OLPC which uses Fedora; OLPC modules
for Dracut are available in the Fedora repository.

* PackageKit plugins - PackageKit now has a plugin which can install an
appropriate package when a user tries to run a command from a missing
package. Another new plugin allows installation of software packages
from a web browser. Thanks to Red Hat's Richard Hughes and the
PackageKit team.

* Bluetooth on-demand - Bluetooth services are automatically started
when needed and stopped 30 seconds after last device use, reducing
initial startup time and resource use when Bluetooth is not in active
use. Thanks to Red Hat's Bastien Nocera.

* Moblin graphical interface for netbooks - The Moblin graphical
interface and applications are fully integrated thanks to Peter
Robinson, a Fedora Project volunteer, and others. To use it, just
install the Moblin Desktop Environment package group using yum or the
graphical software management tools, and choose Moblin from the login
manager. A F12 Moblin Fedora Remix (installable Live CD) will also be
available.

* PulseAudio enhancements - Red Hat's Lennart Poettering and several
others have made significant improvements to the PulseAudio system.
Improved mixer logic makes volume control more fine-grained and
reliable. Integration with the Rygel UPnP media server means you can
stream audio directly from your system to any UPnP / DLNA client, such
as a Playstation 3. Hotplug support has been made more intelligent, so
if you configure a device as the default output for a stream, unplug
that device -- causing the stream(s) to be moved to another output
device -- and later replug it, the stream is moved back to the preferred
device. Finally, Bluetooth audio support means pairing with any
Bluetooth audio device makes it available for use through PulseAudio.

* Lower process privileges - In order to mitigate the impact of security
vulnerabilities, permissions have been hardened for many files and
system directories and process privileges have been lowered for a number
of core components that require super user privileges. Red Hat's Steve
Grubb has developed a new library, libcap-ng, and integrated it into
many core system components to improve the security of Fedora.

* SELinux sandbox - It is now possible to confine applications' access
to the system and run them in a secure sandbox that takes advantage of
the sophisticated capabilities of SELinux. Dan Walsh, SELinux developer
at Red Hat, explains the details at
http://danwalsh.livejournal.com/31146.html

* Open Broadcom firmware - The openfwwf open source Broadcom firmware is
included by default. This means wireless networking will be available
out of the box on some Broadcom chipsets.

* Hybrid live images - The Live images provided in this release can be
directly imaged onto a USB stick using dd (or any equivalent tool) to
create bootable Live USB keys. The Fedora Live USB Creator for Windows
and the livecd-tools for Fedora are still recommended for data
persistence and non-destructive writes. Thanks to Jeremy Katz.

* Better webcam support - While Fedora 11 improved webcam support, in
Fedora 12 you can expect even better video quality, especially for less
expensive webcams. Red Hat's Hans de Goede, developer of the libv4l
library, has more details on his continuous upstream webcam support
enhancements at http://hansdegoede.livejournal.com/6989.html.

* GNOME 2.28 - The latest version of the GNOME desktop includes the
lighter Gnote replacement for Tomboy as the default note application,
and Empathy replaces Pidgin as the default instant messenger. The new
volume control application, first seen in Fedora 11, has been improved
to restore some of the popular functionality from earlier releases
without making the interface too complex.

* GNOME Shell preview - Fedora 12 includes an early version of GNOME
Shell, which will become the default interface for GNOME 3.0 and beyond.
To try it, install the gnome-shell package, and use the Desktop Effects
configuration tool to enable it. It will only work correctly from the
GNOME desktop environment, not others such as KDE or Xfce. This is a
preview technology, and some video cards may not be supported.

* KDE 4.3 - The new KDE features an updated "Air" theme and fully
configurable keyboard shortcuts in Plasma, improved performance and new
desktop effects in the window manager, a new bug reporting tool, and a
configuration tool for the LIRC infra-red remote control system.

* Cool new stuff for developers beginning with Eclipse Galileo, which
includes more plugins than ever before. Perl 6 is now included, along
with PHP 5.3. For Haskell developers, the Haskell Platform now provides
a standardized set of libraries and tools. But one of the biggest
changes for developers is that most of the nice new features of Fedora
12, from Bluetooth to WebCams is implemented through underlying
libraries, and many of the improvements will be included simply by
relinking your application. Also available in this release are SystemTap
1.0 for improved instrumenting and debugging of binaries, complete with
Eclipse integration, and the newest NetBeans IDE for Java development.

* Cool new stuff for sysadmins includes added functionality for
clustered Samba services (including active/active configurations) over
GFS2; and the ability to boot a cluster of Fedora systems from a single,
shared root file system.

* Multi-Pointer X - The update to X.Org server 1.7 introduces the X
Input Extension version 2.0 (XI2), with much work contributed by Red
Hat's Peter Hutterer. This extension provides a new client API for
handling input devices and also Multi-Pointer X (MPX) functionality. MPX
functionality allows X to cope with many inputs of arbitrary types
simultaneously, a prerequisite for (among others) multitouch-based
desktops and multi-user interaction on a single screen. This is
low-level work that applications and desktop environments will
incrementally take advantage of in future releases. More details are
available in the Release Notes and in the XI2 tag of Peter Hutterer's
blog at http://who-t.blogspot.com/search/label/xi2

A full feature list is available on the wiki at

http://fedoraproject.org/wiki/Releases/12/FeatureList

OK, go get it. You know you can't wait.

http://fedoraproject.org/get-prerelease

Draft release notes and guides for several languages are available at

http://docs.fedoraproject.org/drafts.html

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From sandeen at redhat.com  Tue Oct 20 14:12:20 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 20 Oct 2009 09:12:20 -0500
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
Message-ID: <4ADDC544.8000207@redhat.com>

Peter Robinson wrote:
> Hi All,
> 
> As the Dell Latitude D630 is one of the more common devices that smolt
> reports being used by Fedora I thought I'd mention my upgrade
> experience and issues for F-12.

Please do file bugs for any problems you encountered, they -should- get 
more attention from the correct maintainers that way.

Thanks,
-Eric

> Probably the two usual things that people query are grahics and wifi.
> The model I have has the Intel IWL-4965AGN device which as expected
> works fine.
> 
> I'm having a few issues with the nouveau driver with plymouth in that
> it doesn't work at all but if I remove all the options from the kernel
> boot line it gets to X and apart from some initial corruption as GDM
> comes up its OK from there. I have no idea how to debug this.
> Thankfully the issue with detection of my 2nd screen at 1680x1050 is
> no longer and it now works great. Laptop screen is 1440x900 and I use
> to have to run a manual 'xrandr --auto' to get it to detect both
> resolutions properly and configure it.
> 
> Probably the most annoying is the breakage of sound. This seems to
> have every other kernel/alsa/pulseaudio update and was an issue on and
> off right through F-11 as well so its not exactly surprising but also
> disappointing that one of the most common devices running Fedora has
> sound broken on a semi regular basis. Again some pointers in debugging
> this so it can be fixed by F-12 final would be great.
> 
> The only other very minor issue I see is that the icon spacing on the
> gnome panels is massive!
> 
> Peter
> 



From dpierce at redhat.com  Tue Oct 20 15:23:45 2009
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Tue, 20 Oct 2009 11:23:45 -0400
Subject: Passing on ownership for a package...
Message-ID: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>

Is there any process for handing over package ownership? I have a
package that I'm wanting to give to another maintainer. Can I simply
reassign ownership to him, or is there something else needed first?

Thanks.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste n? B?arla cliste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From limb at jcomserv.net  Tue Oct 20 15:38:41 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 20 Oct 2009 10:38:41 -0500
Subject: Passing on ownership for a package...
In-Reply-To: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>
References: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>
Message-ID: <4ADDD981.30603@jcomserv.net>

Darryl L. Pierce wrote:
> Is there any process for handing over package ownership? I have a
> package that I'm wanting to give to another maintainer. Can I simply
> reassign ownership to him, or is there something else needed first?
>
> Thanks.
>
>   
Orphan it in pkgdb, and he can then take ownership.  Might take a little 
bit to update.  If he/she is already comaintainer, I think they just 
automatically move into the maintainer spot.

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie



From orion at cora.nwra.com  Tue Oct 20 15:58:42 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 20 Oct 2009 09:58:42 -0600
Subject: koji noarch build errors
In-Reply-To: <4ADD87FF.6080306@fi.muni.cz>
References: <4ADC7EA2.2070204@cora.nwra.com> <4ADD87FF.6080306@fi.muni.cz>
Message-ID: <4ADDDE32.4010909@cora.nwra.com>

On 10/20/2009 03:50 AM, Milos Jakubicek wrote:
> Hi Orion,
>
> - does local mock build fail too?
> - could you upload the SRPM somewhere?
>
Ah, I ended up with conflicting BuildArch and ExclusiveArch statements 
when I removed gcj conditionals.

-- 
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 Theodore.Papadopoulo at sophia.inria.fr  Tue Oct 20 16:30:08 2009
From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo)
Date: Tue, 20 Oct 2009 18:30:08 +0200
Subject: Rationale behind _cmake_skip_rpath choice
	in	/etc/rpm/macros.cmake
In-Reply-To: 
References: <4AD6203A.9060207@sophia.inria.fr> 
Message-ID: <4ADDE590.5010703@sophia.inria.fr>

Kevin Kofler wrote:
> Theodore Papadopoulo wrote:
>   
>> I would like to understand why the file macros.cmake as distributed in
>> fedora-10 defines:
>> %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON
>>     
>
> Because otherwise installed binaries would end up with rpaths, even for 
> standard library paths. (Probably a bug, I wonder if that got fixed yet.)
>   

According to http://www.itk.org/Wiki/CMake_RPATH_handling this is now 
corrected since almost two years (december 2007).
The %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON is a change dating in 
last january. I cannot explain it as
it was already cmake-2.6 as far as I can tell.
> It's also quite silly to build the binaries with rpaths first and then edit 
> them out when installing, as normally those rpaths shouldn't be needed 
> (that's what the .shell wrappers in the uninstalled tree which set 
> LD_LIBRARY_PATH are for).
>   
Actually, cmake re-links libraries without rpath at installation time 
(according to the previous page).
>> Disabling the rpath made all the checks to fail, so I added a:
>>
>> %define _cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=OFF
>>
>> at the beginning of my specfile.
>>     
>
> Then the testsuite for that package is broken, they need to run the .shell 
> wrappers which CMake creates in the object tree for this purpose, not the 
> uninstalled binaries directly. If they use CMake correctly, it'll take care 
> of this automatically. But apparently they hardcode the binary to run 
> without taking care of this.
>   
The .shell wrappers are a KDE specificity. This is not standard cmake 
stuff. Given the
above page, I believe that the solution above (undefining 
_cmake_skip_rpath with %{nil})
is actually the right thing to do and that the (fedora 10+) standard 
%cmake rpm macro is
overly restrictive in imposing the value of CMAKE_SKIP_RPATH...

I can understand that KDE may not wish to relink everything because of 
its size, but that's not the
general case, so I'd advocate that the line (and its consequences 
basically reverse the commit 1.4 (rdieter  04-Jan-09)):
%_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON
should disappear from /etc/rpm/macros.cmake

Note that I went on the path of adding the .shell wrappers for my 
project (before discovering the above web page :-( ), and
I can tell that it's not so easy...

There might be some other very good reason for keeping those lines, but 
I do not see  it (Rex ? since you added the lines,
maybe you remember what was the motivation ?).

    Thank's a lot...

       Theo.




From deadbabylon at googlemail.com  Tue Oct 20 16:35:50 2009
From: deadbabylon at googlemail.com (Sebastian Vahl)
Date: Tue, 20 Oct 2009 18:35:50 +0200
Subject: KDE-SIG weekly report (43/2009)
Message-ID: <200910201836.04632.deadbabylon@googlemail.com>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 43/2009

Time: 2009-10-30 14:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-20

Meeting minutes: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-20/fedora-meeting.2009-10-20-14.03.html

Meeting log: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-20/fedora-meeting.2009-10-20-14.03.log.html

----------------------------------------------------------------------------------

= Participants =

*  JaroslavReznik
* KevinKofler
* LukasTinkl
* RexDieter
* SebastianVahl
* StevenParrish
* ThanNgo
* ThomasJanssen 

----------------------------------------------------------------------------------

= Agenda =

*  virtuoso/soprano status
* Eigen2 (2.0.x vs. 2.1 snapshots, updating to current)
* NM applet (GNOME nm-applet vs. knetworkmanager)
* bug triage changes coming
* phonon/trunk , PA-integration work/testing 

= Summary =

o virtuoso/soprano status:
* RexDieter is working on new releases of virtuoso and libiodbc.
* Test builds should appear in kde-testing (from kde-redhat) soon. 

o Eigen2 (2.0.x vs. 2.1 snapshots, updating to current):
* F12 is shipping a 4 mounths old snapshot of 2.1 (the final isn't released 
yet).
* F10/F11 are also shipping out-of-date 2.0.3 as updates (current is 2.0.6).
* RexDieter will ask upstream for a recommendation.
* Current plan is to ship 2.0.6 for F10/F11/F12 and 2.0.90 for F13.
* This would mean to downgrade eigen2 in F12 and rebuild depending packages 
(kdeartwork, kdeedu, kdeplasma-addons, avogadro). 

o NM applet (GNOME nm-applet vs. knetworkmanager):
* Results from a vote from KDE-SIG Steering Committee:
- Switch to KNetworkManager for F12 (i.e. now): rejected
- Stay wit nm-applet in F12 and switch to KNetworkManager in F13/Rawhide: 
accepted 

o bug triage changes coming:
* The triage team will be using the keyword Triaged instead of the ASSIGNED 
status to indicate triaged bugs from F13 on.
* The maintainers decide to use ASSIGNED or ON_DEV instead.
* For now there was no result how we should handle this and we will continue 
the discussion later. 

o phonon/trunk , PA-integration work/testing:
* RexDieter imported a Phonon trunk snapshot into the devel branch.
* KevinKofler is going to look into getting PA integration into 
devel/Rawhide++/F13. 

o Open discussion:
* StephenParrish is working on new KPackageKit 0.5 in F12 and F13/Rawhide. 

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-27
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From orion at cora.nwra.com  Tue Oct 20 16:47:50 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 20 Oct 2009 10:47:50 -0600
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4ADD8782.10801@fi.muni.cz>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<4ADD8782.10801@fi.muni.cz>
Message-ID: <4ADDE9B6.5010102@cora.nwra.com>

On 10/20/2009 03:48 AM, Milos Jakubicek wrote:
> Hi,
>
> On 10/19/2009 09:20 PM, Peter Robinson wrote:
>> Hi All,
>>
>> I thought with the mass rebuild the i586 rpms were suppose to be gone
>> but it seems the F-12 repository still has quite a few of them. Are
>> the old packages that should have been blocked, ones that's that
>> weren't rebuilt for some reason or something that I've just missed?
>>
>> Peter
>
> Most probably those are the packages which failed during the mass
> rebuild...there are still plenty of them:
>
> http://mjakubicek.fedorapeople.org/need-rebuild.html

I just rebuilt:

itcl-3.4-5.fc12 - no changes from original failed rebuild
irda-utils-0.9.18-10.fc12 - added a minor patch to fix install issue
xfconf-4.6.1-4.fc12 - added missing BRs

Does it make sense to tag them into F-12 at this point?

-- 
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 jeff at ocjtech.us  Tue Oct 20 16:53:45 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 20 Oct 2009 11:53:45 -0500
Subject: Problem building Asterisk sounds
In-Reply-To: <935ead450910060723k7836e593ma7d0b418e4d2c2af@mail.gmail.com>
References: <935ead450910060723k7836e593ma7d0b418e4d2c2af@mail.gmail.com>
Message-ID: <935ead450910200953p66826cb7t8430b0f7e68ba20d@mail.gmail.com>

On Tue, Oct 6, 2009 at 9:23 AM, Jeffrey Ollie  wrote:
> I'm trying to build the latest Asterisk sounds package, but I'm
> getting the following error:
>
> error: Recognition of file
> "/builddir/build/BUILDROOT/asterisk-sounds-core-1.4.16-1.fc13.noarch/usr/share/asterisk/sounds/fr/digits/1.g729"
> failed: mode 100444 zlib: invalid stored block lengthsempty (gzip
> compressed data, reserved method, encrypted, last modified: Tue Nov ?9
> 20:48:48 2010, max speed)
>
> The full build log is here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1730585
>
> The build fails in mock locally as well but koji actually gives me a
> better error message. ?The file in question isn't gzip compressed,
> it's an audio file compressed with G.729 audio compression. ?Can
> anyone help me out here?

I still haven't figured this out, and it hasn't fixed itself.  Can
anyone take a look and give me a hint?

-- 
Jeff Ollie



From poelstra at redhat.com  Tue Oct 20 17:08:49 2009
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 20 Oct 2009 10:08:49 -0700
Subject: Upcoming Schedule
Message-ID: <4ADDEEA1.90807@redhat.com>

Start       End         Name
Thu 15-Oct  Tue 20-Oct  Stage & Sync Beta to Mirrors
Tue 20-Oct  Tue 20-Oct  Beta Release Public Availability
Tue 20-Oct  Mon 02-Nov  Beta Testing
Fri 23-Oct  Fri 23-Oct  Blocker Bug Day (F12Blocker) #1
Fri 30-Oct  Fri 30-Oct  Blocker Bug Day (F12Blocker) #2
Mon 02-Nov  Mon 02-Nov  End of Beta Testing



From notting at redhat.com  Tue Oct 20 17:15:03 2009
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Oct 2009 13:15:03 -0400
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4ADDE9B6.5010102@cora.nwra.com>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<4ADD8782.10801@fi.muni.cz> <4ADDE9B6.5010102@cora.nwra.com>
Message-ID: <20091020171502.GA2271@nostromo.devel.redhat.com>

Orion Poplawski (orion at cora.nwra.com) said: 
> I just rebuilt:
> 
> itcl-3.4-5.fc12 - no changes from original failed rebuild
> irda-utils-0.9.18-10.fc12 - added a minor patch to fix install issue
> xfconf-4.6.1-4.fc12 - added missing BRs
> 
> Does it make sense to tag them into F-12 at this point?

Wouldn't hurt - send tag requests.

Bill



From lsof at nodata.co.uk  Tue Oct 20 17:37:39 2009
From: lsof at nodata.co.uk (nodata)
Date: Tue, 20 Oct 2009 19:37:39 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020141238.371d90bb@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>	<1256026818.31423.11.camel@vespa.frost.loc>	<20091020120032.503bb46b@dhcp03.addix.net>		<20091020134407.5bfa36ed@dhcp03.addix.net>	
	<20091020141238.371d90bb@dhcp03.addix.net>
Message-ID: <4ADDF563.3050309@nodata.co.uk>

Am 2009-10-20 14:12, schrieb Ralf Ertzinger:
> Hi.
>
> On Tue, 20 Oct 2009 08:00:50 -0400 (EDT), Seth Vidal wrote:
>
>> You could, of course, just have koji keep the pkgs and then you could
>> use the existing metadata to grab the header from the pkgs and access
>> the information that way.
>
> That would be a solution, of course, but keeping the files forever and a day
> would surely be prohibitive in terms of disk space.
>

It sounds like a solution looking for a problem to me.

Here's a better idea:

* Host the config files for each package online, retrievable by rpm name 
and version of the package. This would allow diffs between what is on 
the server and what was in the package.



From kevin at scrye.com  Tue Oct 20 17:36:35 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 20 Oct 2009 11:36:35 -0600
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4ADDE9B6.5010102@cora.nwra.com>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<4ADD8782.10801@fi.muni.cz> <4ADDE9B6.5010102@cora.nwra.com>
Message-ID: <20091020113635.6e50330f@ohm.scrye.com>

On Tue, 20 Oct 2009 10:47:50 -0600
Orion Poplawski  wrote:

...snip...

> I just rebuilt:
> 
...snip...
> xfconf-4.6.1-4.fc12 - added missing BRs

Wow. I didn't know this was still an issue. I thought I fixed this long
ago. ;( 

Thanks very much for fixing it!

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

From fedora at camperquake.de  Tue Oct 20 17:45:53 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 19:45:53 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <4ADDF563.3050309@nodata.co.uk>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
	<20091020141238.371d90bb@dhcp03.addix.net>
	<4ADDF563.3050309@nodata.co.uk>
Message-ID: <20091020194553.747bfff2@fred.camperquake.de>

Hi.

On Tue, 20 Oct 2009 19:37:39 +0200, nodata wrote

> It sounds like a solution looking for a problem to me.

Well, the problem is being able to determine whether the files on
your system have been compromised, which seems like a sensible idea
to me.

> Here's a better idea:
> 
> * Host the config files for each package online, retrievable by rpm
> name and version of the package. This would allow diffs between what
> is on the server and what was in the package.

Or even better: keep the (compressed) config files in the RPM database.
They're usually small and text, so the disk space used would not be
all that great.

Yes, I've wished for that in the past, too.



From belegdol at gmail.com  Tue Oct 20 18:01:54 2009
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 20 Oct 2009 20:01:54 +0200
Subject: SciTech SIG members: EMBOSS is now packaged,
 comaintainership welcome, java skills helpful
Message-ID: 

Hi guys,

the review process for EMBOSS was recently completed. A gcc bug (fixed
but not pushed) prevents it from getting built for F-12 and rawhide, but
other than that package is fine.
Unfortunately, due to the fact that jemboss bundles a load of .jar files
and seems to use some com.sun.net classes, it had to be disabled. I'm
trying to get it in shape, but since I have no experience with java, I'm
afraid that without help things will need to stay the way they are. So,
if someone would like to help make jemboss use system-wide .jar files,
as well as make it buildable with free software, please step up.
Packaging jalview will probably be needed during this process.

Julian



From awilliam at redhat.com  Tue Oct 20 18:22:06 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Tue, 20 Oct 2009 11:22:06 -0700
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
Message-ID: <1256062926.2314.270.camel@adam.local.net>

On Tue, 2009-10-20 at 11:17 +0100, Peter Robinson wrote:
> Hi All,
> 
> As the Dell Latitude D630 is one of the more common devices that smolt
> reports being used by Fedora I thought I'd mention my upgrade
> experience and issues for F-12.
> 
> Probably the two usual things that people query are grahics and wifi.
> The model I have has the Intel IWL-4965AGN device which as expected
> works fine.
> 
> I'm having a few issues with the nouveau driver with plymouth in that
> it doesn't work at all but if I remove all the options from the kernel
> boot line it gets to X and apart from some initial corruption as GDM
> comes up its OK from there. I have no idea how to debug this.

Try adding the parameter 'nomodeset' instead of removing any parameters.
What happens then?

> Probably the most annoying is the breakage of sound. This seems to
> have every other kernel/alsa/pulseaudio update and was an issue on and
> off right through F-11 as well so its not exactly surprising but also
> disappointing that one of the most common devices running Fedora has
> sound broken on a semi regular basis. Again some pointers in debugging
> this so it can be fixed by F-12 final would be great.

https://fedoraproject.org/wiki/Bug_info_kernel_sound

> The only other very minor issue I see is that the icon spacing on the
> gnome panels is massive!

This is currently being 'enthusiastically' discussed on
fedora-desktop-list. :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Oct 20 18:48:32 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 21 Oct 2009 03:48:32 +0900
Subject: Problem building Asterisk sounds
In-Reply-To: <935ead450910200953p66826cb7t8430b0f7e68ba20d@mail.gmail.com>
References: <935ead450910060723k7836e593ma7d0b418e4d2c2af@mail.gmail.com>
	<935ead450910200953p66826cb7t8430b0f7e68ba20d@mail.gmail.com>
Message-ID: <4ADE0600.6080109@ioa.s.u-tokyo.ac.jp>

Jeffrey Ollie wrote, at 10/21/2009 01:53 AM +9:00:
> On Tue, Oct 6, 2009 at 9:23 AM, Jeffrey Ollie  wrote:
>> I'm trying to build the latest Asterisk sounds package, but I'm
>> getting the following error:
>>
>> error: Recognition of file
>> "/builddir/build/BUILDROOT/asterisk-sounds-core-1.4.16-1.fc13.noarch/usr/share/asterisk/sounds/fr/digits/1.g729"
>> failed: mode 100444 zlib: invalid stored block lengthsempty (gzip
>> compressed data, reserved method, encrypted, last modified: Tue Nov  9
>> 20:48:48 2010, max speed)
>>
>> The full build log is here:
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1730585
>>
>> The build fails in mock locally as well but koji actually gives me a
>> better error message.  The file in question isn't gzip compressed,
>> it's an audio file compressed with G.729 audio compression.  Can
>> anyone help me out here?
> 
> I still haven't figured this out, and it hasn't fixed itself.  Can
> anyone take a look and give me a hint?

Well,
$ file ./usr/share/asterisk/sounds/fr/digits/1.g729
./usr/share/asterisk/sounds/fr/digits/1.g729: gzip compressed data, reserved method, encrypted, last modified: Wed Nov 10 10:48:48 2010, max speed

So it seems that this file is actually recognized as gzip compressed data, perhaps
due to magic number, which seems to be causing a problem in rpm.
I don't know currently how to deal with this case as I don't know if we can tell rpmbuild
that this file should not be treated as a gzipped file by some methods or not, but for now
I guess it is better to contact rpm maintainer.

Regards,
Mamoru



From skvidal at fedoraproject.org  Tue Oct 20 19:15:46 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 20 Oct 2009 15:15:46 -0400 (EDT)
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020194553.747bfff2@fred.camperquake.de>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
	<20091020141238.371d90bb@dhcp03.addix.net>
	<4ADDF563.3050309@nodata.co.uk>
	<20091020194553.747bfff2@fred.camperquake.de>
Message-ID: 



On Tue, 20 Oct 2009, Ralf Ertzinger wrote:

> Hi.
>
> On Tue, 20 Oct 2009 19:37:39 +0200, nodata wrote
>
>> It sounds like a solution looking for a problem to me.
>
> Well, the problem is being able to determine whether the files on
> your system have been compromised, which seems like a sensible idea
> to me.
>
>> Here's a better idea:
>>
>> * Host the config files for each package online, retrievable by rpm
>> name and version of the package. This would allow diffs between what
>> is on the server and what was in the package.
>
> Or even better: keep the (compressed) config files in the RPM database.
> They're usually small and text, so the disk space used would not be
> all that great.
>
> Yes, I've wished for that in the past, too.
>

so I have an idea here - and you're welcome to ignore it - you could 
implement a good bit of this system as a yum plugin.

Record original copies of the config files and tuck them away - heck you 
could save off a copy of the pkg hdrs if you wanted to.

-sv



From tmraz at redhat.com  Tue Oct 20 19:22:13 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 20 Oct 2009 21:22:13 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020104534.3a4cc847@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020104534.3a4cc847@dhcp03.addix.net>
Message-ID: <1256066533.4006.64.camel@vespa.frost.loc>

On Tue, 2009-10-20 at 10:45 +0200, Ralf Ertzinger wrote: 
> Hi.
> 
> On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote:
> 
> > What would this be good for? Actually for some files it would be a
> > known bad file hashes because these files (binaries or scripts) would
> > contain known vulnerabilities and so knowing that you have a file
> > that was once included in Fedora does not guarantee you almost
> > anything.
> 
> I'm not sure I follow you here. Containing a known vulnerability in a
> binary file has nothing to do with the hash.

I simply meant that if the attacker wanted to compromise your system he
could just revert some binary or script to a vulnerable version which
was previously included in Fedora. So having the files on your system to
match hashes from older package releases does not provide you any
security. For a real security you need to match the hashes against
current package versions.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From rdieter at math.unl.edu  Tue Oct 20 19:56:46 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 20 Oct 2009 14:56:46 -0500
Subject: Rationale behind _cmake_skip_rpath choice
	in	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr> 
	<4ADDE590.5010703@sophia.inria.fr>
Message-ID: 

Theodore Papadopoulo wrote:

> There might be some other very good reason for keeping those lines, but
> I do not see  it (Rex ? since you added the lines,
> maybe you remember what was the motivation ?).

I'm convinced to revert, I'll run the change by my fellow cmake maintainers 
(I think we have buy-in from everyone though).

-- Rex




From a.badger at gmail.com  Tue Oct 20 20:16:21 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 20 Oct 2009 13:16:21 -0700
Subject: Passing on ownership for a package...
In-Reply-To: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>
References: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>
Message-ID: <20091020201621.GB31378@clingman.lan>

On Tue, Oct 20, 2009 at 11:23:45AM -0400, Darryl L. Pierce wrote:
> Is there any process for handing over package ownership? I have a
> package that I'm wanting to give to another maintainer. Can I simply
> reassign ownership to him, or is there something else needed first?
> 

Note, if you want to make sure that the right person gets ownership, you can
email me and I'll make it happen.  (or put in a cvsadmin request).

The pkgdb currently has a half-implemented feature that escaped to
production before it was ready -- it reassigns ownership of orphaned
packages to the longest comaintainer.  This wasn't supposed to go live
until the current owner had the ability to set the new owner as well so that
either would be possible.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From fedora at camperquake.de  Tue Oct 20 20:20:33 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Oct 2009 22:20:33 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: 
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
	<20091020141238.371d90bb@dhcp03.addix.net>
	<4ADDF563.3050309@nodata.co.uk>
	<20091020194553.747bfff2@fred.camperquake.de>
	
Message-ID: <20091020222033.638e468a@fred.camperquake.de>

Hi.

On Tue, 20 Oct 2009 15:15:46 -0400 (EDT), Seth Vidal wrote

> Record original copies of the config files and tuck them away - heck
> you could save off a copy of the pkg hdrs if you wanted to.

Hm. The config file copy might actually be pretty straigtforward to
do.



From skvidal at fedoraproject.org  Tue Oct 20 20:26:36 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Tue, 20 Oct 2009 16:26:36 -0400 (EDT)
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020222033.638e468a@fred.camperquake.de>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020120032.503bb46b@dhcp03.addix.net>
	
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
	<20091020141238.371d90bb@dhcp03.addix.net>
	<4ADDF563.3050309@nodata.co.uk>
	<20091020194553.747bfff2@fred.camperquake.de>
	
	<20091020222033.638e468a@fred.camperquake.de>
Message-ID: 



On Tue, 20 Oct 2009, Ralf Ertzinger wrote:

> Hi.
>
> On Tue, 20 Oct 2009 15:15:46 -0400 (EDT), Seth Vidal wrote
>
>> Record original copies of the config files and tuck them away - heck
>> you could save off a copy of the pkg hdrs if you wanted to.
>
> Hm. The config file copy might actually be pretty straigtforward to do.

in fact you could even be super-duper cool and check the config files into 
some sort of scm so you could record state...

-sv



From dpierce at redhat.com  Tue Oct 20 20:35:09 2009
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Tue, 20 Oct 2009 16:35:09 -0400
Subject: Passing on ownership for a package...
In-Reply-To: <20091020201621.GB31378@clingman.lan>
References: <20091020152345.GA17805@mcpierce-laptop.rdu.redhat.com>
	<20091020201621.GB31378@clingman.lan>
Message-ID: <20091020203509.GF20809@mcpierce-laptop.rdu.redhat.com>

On Tue, Oct 20, 2009 at 01:16:21PM -0700, Toshio Kuratomi wrote:
> On Tue, Oct 20, 2009 at 11:23:45AM -0400, Darryl L. Pierce wrote:
> > Is there any process for handing over package ownership? I have a
> > package that I'm wanting to give to another maintainer. Can I simply
> > reassign ownership to him, or is there something else needed first?
> > 
> 
> Note, if you want to make sure that the right person gets ownership, you can
> email me and I'll make it happen.  (or put in a cvsadmin request).
> 
> The pkgdb currently has a half-implemented feature that escaped to
> production before it was ready -- it reassigns ownership of orphaned
> packages to the longest comaintainer.  This wasn't supposed to go live
> until the current owner had the ability to set the new owner as well so that
> either would be possible.

Okay, good. I'll confirm things with the new maintainers and then email
you directly. :)

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste n? B?arla cliste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From lsof at nodata.co.uk  Tue Oct 20 20:43:08 2009
From: lsof at nodata.co.uk (nodata)
Date: Tue, 20 Oct 2009 22:43:08 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: 
References: <20091020084540.622d5d28@dhcp03.addix.net>	<1256026818.31423.11.camel@vespa.frost.loc>	<20091020120032.503bb46b@dhcp03.addix.net>		<20091020134407.5bfa36ed@dhcp03.addix.net>		<20091020141238.371d90bb@dhcp03.addix.net>	<4ADDF563.3050309@nodata.co.uk>	<20091020194553.747bfff2@fred.camperquake.de>		<20091020222033.638e468a@fred.camperquake.de>
	
Message-ID: <4ADE20DC.9020904@nodata.co.uk>

Am 2009-10-20 22:26, schrieb Seth Vidal:
>
>
> On Tue, 20 Oct 2009, Ralf Ertzinger wrote:
>
>> Hi.
>>
>> On Tue, 20 Oct 2009 15:15:46 -0400 (EDT), Seth Vidal wrote
>>
>>> Record original copies of the config files and tuck them away - heck
>>> you could save off a copy of the pkg hdrs if you wanted to.
>>
>> Hm. The config file copy might actually be pretty straigtforward to do.
>
> in fact you could even be super-duper cool and check the config files
> into some sort of scm so you could record state...
>
> -sv
>

and in one swipe enterprise configuration file management becomes a 
piece of cake.

bung in a file watcher for noticing and checking in changes and 
everything's pretty much there!



From tmz at pobox.com  Tue Oct 20 20:57:28 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 20 Oct 2009 16:57:28 -0400
Subject: Eternal 'good file hashes' list
In-Reply-To: <4ADE20DC.9020904@nodata.co.uk>
References: 
	<20091020134407.5bfa36ed@dhcp03.addix.net>
	
	<20091020141238.371d90bb@dhcp03.addix.net>
	<4ADDF563.3050309@nodata.co.uk>
	<20091020194553.747bfff2@fred.camperquake.de>
	
	<20091020222033.638e468a@fred.camperquake.de>
	
	<4ADE20DC.9020904@nodata.co.uk>
Message-ID: <20091020205728.GX19511@inocybe.localdomain>

nodata wrote:
> Am 2009-10-20 22:26, schrieb Seth Vidal:
[...]
>>in fact you could even be super-duper cool and check the config
>>files into some sort of scm so you could record state...
>>
>>-sv
>>
>
> and in one swipe enterprise configuration file management becomes a
> piece of cake.
>
> bung in a file watcher for noticing and checking in changes and
> everything's pretty much there!

That doesn't sound too far away from what etckeeper? intends to do.

? http://joey.kitenet.net/code/etckeeper/
  https://admin.fedoraproject.org/pkgdb/packages/name/etckeeper

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nothing is so permanent as a temporary government program.
    -- Dr. Milton Friedman, Nobel-Prize-winning economist.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From wtogami at redhat.com  Tue Oct 20 21:27:45 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Oct 2009 17:27:45 -0400
Subject: Reminder: Tagging Policy for Fedora 12
Message-ID: <4ADE2B51.4080006@redhat.com>

This is just a reminder about the tagging policy for packages built for 
Fedora 12 past the development freeze.

What Qualifies for Tagging?
===========================
* You must have tested the build yourself.  Great shame to be bestowed 
if you break things so close to the release!  Great Shame!
* http://wwoods.fedorapeople.org/files/critical-path/deplist.txt
Anything on the critical path list requires two votes from Fedora 
release engineering.  Critical path is loosely defined as packages that 
can break the ability to install or update.  Typically rel-eng might do 
some sanity tests of your package as well, but don't count on them to 
find non-obvious issues.
* Anything not on the critical path list can be approved by release 
engineering with a single vote.
* You DID test it right?

Many Builds Not Tagged, but Probably Should Be
==============================================
# koji list-tagged --latest dist-f12-updates-candidate
This command shows over 400 packages are built for F-12 but not tagged 
for release.
https://admin.fedoraproject.org/updates/F12/pending
Currently there are 270+ packages in the pending queue to become Fedora 
12 updates.  Many if not all of the packages requested update at this 
point probably belong tagged into rawhide immediately.  Requesting it 
for updates at this point is problematic because you miss out on several 
weeks of testing only for it to show up as an update on day zero when 
Fedora 12 is released.  Tagging policy might tighten up in the coming 
weeks then it might make sense to push as day zero updates at that point.

How to Request Tagging
======================
https://fedorahosted.org/rel-eng
Please file requests to have your post-freeze build included here. 
Please include the full Name-Version-Release of your build in the 
Summary of the ticket.  To save rel-eng's time it might be helpful to 
mention a few other details like:

* How important is this?
* How much have you tested it?
* Is it on the critical path list?

Upcoming Deadlines
==================
https://fedoraproject.org/wiki/Schedule

Warren Togami
wtogami at redhat.com

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From opensource at till.name  Tue Oct 20 21:42:47 2009
From: opensource at till.name (Till Maas)
Date: Tue, 20 Oct 2009 23:42:47 +0200
Subject: [Fwd: Junior Jobs]
In-Reply-To: <4ADC0818.8010705@redhat.com>
References: <4ADC0818.8010705@redhat.com>
Message-ID: <20091020214247.GB25418@genius.kawo2.rwth-aachen.de>

On Mon, Oct 19, 2009 at 08:32:56AM +0200, Miroslav Such? wrote:

> -------- P?vodn? zpr?va --------
> P?edm?t: [opensuse-packaging] Junior Jobs
> Datum: Tue, 13 Oct 2009 14:46:58 +0200
> Od: Michal Hrusecky 
> Komu: opensuse-packaging at opensuse.org

> lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of
> openSUSE packages can choose some of theirs easy bugs and mark them as
> Junior Jobs. Then anybody from community can volunteer and fix these
> issues. These tasks will be easily fixable and their purpose is to let
> people learn how to contribute and to create some easy task so anybody
> can join and start participating.

I would like to have something like this, too. But currently more an
easy way to "ask a provenpackager for help" for anything, even trivial
issues. So that packagers that do not currently have the time to look
into something flag the bug report and there is a list for
provenpackers to go through and fix the issues.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From opensource at till.name  Tue Oct 20 21:48:47 2009
From: opensource at till.name (Till Maas)
Date: Tue, 20 Oct 2009 23:48:47 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <1256026818.31423.11.camel@vespa.frost.loc>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
Message-ID: <20091020214847.GC25418@genius.kawo2.rwth-aachen.de>

On Tue, Oct 20, 2009 at 10:20:17AM +0200, Tomas Mraz wrote:

> What would this be good for? Actually for some files it would be a known
> bad file hashes because these files (binaries or scripts) would contain
> known vulnerabilities and so knowing that you have a file that was once
> included in Fedora does not guarantee you almost anything.

Having a hash list of well known files might also help in forensics
analysis to find suspicious files. Also with determining the correct RPM
NVR one could use the repo metadata to check wether there are known
vulnerabilities for certain files or just to detect that the file is not
from an uptodate RPM.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From lsof at nodata.co.uk  Tue Oct 20 21:49:28 2009
From: lsof at nodata.co.uk (nodata)
Date: Tue, 20 Oct 2009 23:49:28 +0200
Subject: rpmnew files
Message-ID: <4ADE3068.50408@nodata.co.uk>

Hi,

What's with the extra rpmnew files on an upgrade?

Some examples:
# md5sum  /etc/pki/tls/openssl.cnf.rpmnew /etc/pki/tls/openssl.cnf
7c8f8d809c5b618e1604207525161101  /etc/pki/tls/openssl.cnf.rpmnew
7c8f8d809c5b618e1604207525161101  /etc/pki/tls/openssl.cnf
# ls -la  /etc/pki/tls/openssl.cnf.rpmnew /etc/pki/tls/openssl.cnf
-rw-r--r--. 1 root root 10906 30. Jun 13:17 /etc/pki/tls/openssl.cnf
-rw-r--r--. 1 root root 10906 30. Jun 13:17 /etc/pki/tls/openssl.cnf.rpmnew
# rpm -V openssl
(no output)

This seems strange: same times, same checksum, but still an .rpmnew file.

Here are two more:

/var/lib/games/same-gnome.Small.scores.rpmnew
/var/log/mail/statistics.rpmnew

Not sure why we would ever need an rpmnew file for that: should these be 
labelled as something other than config files?

Another one:

# md5sum /usr/share/info/dir.rpmnew /usr/share/info/dir
91ba35a21c163a55982bedaab076bc7f  /usr/share/info/dir.rpmnew
0737290f14a0ce86986de276d1083783  /usr/share/info/dir
# wc -l /usr/share/info/dir.rpmnew /usr/share/info/dir
    22 /usr/share/info/dir.rpmnew
  2127 /usr/share/info/dir
  2149 total

I didn't change this file. That's weird. Same case here:

/usr/lib64/security/classpath.security.rpmnew
/usr/lib64/security/classpath.security

and here:

/etc/sgml/docbook/xmlcatalog.rpmnew
/etc/sgml/docbook/xmlcatalog

I'm not sure where these changes are coming from. Shall I file bugs 
against each package, or is this intended behaviour?



From bruno at wolff.to  Tue Oct 20 21:54:35 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 20 Oct 2009 16:54:35 -0500
Subject: Reminder: Tagging Policy for Fedora 12
In-Reply-To: <4ADE2B51.4080006@redhat.com>
References: <4ADE2B51.4080006@redhat.com>
Message-ID: <20091020215435.GA11982@wolff.to>

On Tue, Oct 20, 2009 at 17:27:45 -0400,
  Warren Togami  wrote:
> This is just a reminder about the tagging policy for packages built
> for Fedora 12 past the development freeze.

So is there some more example guidance with this?
For example I have a new release of the game colossus, that has some rule
bugfixes. One for the balrog variant seems to be important to people playing
that variant. Is this the kind of thing that should get tagged for F12
before release?
I think what I am looking for is if it is worth trying to get minor fixes
into F12 release for a package with is not a dependency for other things.

What if the package is already tagged for F12 updates testing?
In the case I am interested in, I have already requested updates-testing
for the package in F12. If it is still OK to tag it for F12 final, do
I need to do anything extra in bohdi?



From wtogami at redhat.com  Tue Oct 20 22:00:15 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Oct 2009 18:00:15 -0400
Subject: Reminder: Tagging Policy for Fedora 12
In-Reply-To: <20091020215435.GA11982@wolff.to>
References: <4ADE2B51.4080006@redhat.com> <20091020215435.GA11982@wolff.to>
Message-ID: <4ADE32EF.4010404@redhat.com>

On 10/20/2009 05:54 PM, Bruno Wolff III wrote:
> On Tue, Oct 20, 2009 at 17:27:45 -0400,
>    Warren Togami  wrote:
>> This is just a reminder about the tagging policy for packages built
>> for Fedora 12 past the development freeze.
>
> So is there some more example guidance with this?
> For example I have a new release of the game colossus, that has some rule
> bugfixes. One for the balrog variant seems to be important to people playing
> that variant. Is this the kind of thing that should get tagged for F12
> before release?
> I think what I am looking for is if it is worth trying to get minor fixes
> into F12 release for a package with is not a dependency for other things.

If it isn't on the critical path list, just be careful you aren't 
breaking anything.  Sounds like this particular package isn't a risk. 
Might be helpful to mention in your rel-eng ticket.

>
> What if the package is already tagged for F12 updates testing?
> In the case I am interested in, I have already requested updates-testing
> for the package in F12. If it is still OK to tag it for F12 final, do
> I need to do anything extra in bohdi?

Rel-eng is currently discussing what to do about the F12 update bodhi 
requests.  Some of us believe we enabled bodhi far too early and this is 
needlessly confusing people.  My own opinion is that queuing for updates 
at this point is detrimental to testing, because we will have a huge 
flood of packages hitting updates on release day that had almost zero 
testing.

For now don't worry about what you did in Bodhi.  It seems the Bodhi 
update requests are not going anywhere for the next few weeks.

Warren Togami
wtogami at redhat.com



From lsof at nodata.co.uk  Tue Oct 20 22:00:23 2009
From: lsof at nodata.co.uk (nodata)
Date: Wed, 21 Oct 2009 00:00:23 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020214847.GC25418@genius.kawo2.rwth-aachen.de>
References: <20091020084540.622d5d28@dhcp03.addix.net>	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020214847.GC25418@genius.kawo2.rwth-aachen.de>
Message-ID: <4ADE32F7.1030506@nodata.co.uk>

Am 2009-10-20 23:48, schrieb Till Maas:
> On Tue, Oct 20, 2009 at 10:20:17AM +0200, Tomas Mraz wrote:
>
>> What would this be good for? Actually for some files it would be a known
>> bad file hashes because these files (binaries or scripts) would contain
>> known vulnerabilities and so knowing that you have a file that was once
>> included in Fedora does not guarantee you almost anything.
>
> Having a hash list of well known files might also help in forensics
> analysis to find suspicious files. Also with determining the correct RPM
> NVR one could use the repo metadata to check wether there are known
> vulnerabilities for certain files or just to detect that the file is not
> from an uptodate RPM.
>
> Regards
> Till
>

How is this check going to be done?

Is the filesystem going to be mounted in a known clean environment? If 
not, what's the point?

If yes, how do you know the filesystem hasn't been returned to a clean 
state?



From bruno at wolff.to  Tue Oct 20 22:10:50 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 20 Oct 2009 17:10:50 -0500
Subject: rpmnew files
In-Reply-To: <4ADE3068.50408@nodata.co.uk>
References: <4ADE3068.50408@nodata.co.uk>
Message-ID: <20091020221050.GA2526@wolff.to>

On Tue, Oct 20, 2009 at 23:49:28 +0200,
  nodata  wrote:
> Hi,
> 
> What's with the extra rpmnew files on an upgrade?

It could be the hash change, depending on what you upgrading from and to.



From opensource at till.name  Tue Oct 20 22:49:12 2009
From: opensource at till.name (Till Maas)
Date: Wed, 21 Oct 2009 00:49:12 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <4ADE32F7.1030506@nodata.co.uk>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<1256026818.31423.11.camel@vespa.frost.loc>
	<20091020214847.GC25418@genius.kawo2.rwth-aachen.de>
	<4ADE32F7.1030506@nodata.co.uk>
Message-ID: <20091020224912.GA18725@genius.kawo2.rwth-aachen.de>

On Wed, Oct 21, 2009 at 12:00:23AM +0200, nodata wrote:
> Am 2009-10-20 23:48, schrieb Till Maas:

>> Having a hash list of well known files might also help in forensics
>> analysis to find suspicious files. Also with determining the correct RPM
>> NVR one could use the repo metadata to check wether there are known
>> vulnerabilities for certain files or just to detect that the file is not
>> from an uptodate RPM.

> How is this check going to be done?

The hash for each file on a filesystem is computed and then compared
with the list.

> Is the filesystem going to be mounted in a known clean environment? If  
> not, what's the point?

Filesystems can also be accessed without actually mounting it. But a
clean environment should off course be used.

> If yes, how do you know the filesystem hasn't been returned to a clean  
> state?

The process of forensics analysis is more complex than just running one
single command. Nevertheless getting a list of suspicious files can lead
to find the information one is interested in. And if all files match the
hash of a well known file, then this information can also be used to
decide to investigate using other methods.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From christoph.wickert at googlemail.com  Tue Oct 20 23:11:23 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 21 Oct 2009 01:11:23 +0200
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy for
 Fedora 12)
In-Reply-To: <4ADE2B51.4080006@redhat.com>
References: <4ADE2B51.4080006@redhat.com>
Message-ID: <1256080283.16609.277.camel@wicktop.localdomain>

Am Dienstag, den 20.10.2009, 17:27 -0400 schrieb Warren Togami:

> Many Builds Not Tagged, but Probably Should Be
> ==============================================
> # koji list-tagged --latest dist-f12-updates-candidate
> This command shows over 400 packages are built for F-12 but not tagged 
> for release.
> https://admin.fedoraproject.org/updates/F12/pending

What really scares me is that there is a number of security updates in
bodhi that don't have a tag request in trac. Are maintainers that
careless? We don't want F12 released with 6 weeks old security bugs, so
it might be worth to mail their owners if there is no tag request.

Regards,
Christoph



From smooge at gmail.com  Tue Oct 20 23:40:46 2009
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 20 Oct 2009 17:40:46 -0600
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091020084540.622d5d28@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>
Message-ID: <80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>

On Tue, Oct 20, 2009 at 12:45 AM, Ralf Ertzinger  wrote:
> Hi.
>
> I was wondering the other day how much space the file information (i.e. the
> stuff that rpm -V checks against) takes up in an RPM file. And, going from
> there, how much space we would waste over the years if we kept this
> information for every RPM ever built by koji.
>
> The idea would be to have a database of known good file information that is
> separate from the local RPM database, so one may burn this information to
> a bootable CD (or DVD) to be able to verify the integrity of the local
> files (as long as the files came from a fedora built RPM file, that is).
> Another possibility would be to load the information from the net, on
> demand.
>
> How much data are we talking about, roughly?

I have done this in the past for some items.. you need to measure
several things.

1) What do you mean by good. In this case it is not that the program
is secure, but that at one point or another it was built on a system.

2) What are you measuring. Matching a fingerprint between two files is
not exactly enough data as you need to deal with accidental and
intentional collisions. You can lower the chances of this by having
more than one hash AND the size of the file.

3) How are you going to trust that data. The data is going to need to
be stored somewhere and signed off with a key. You will then compare
the two somehow.

In the end, you are going to deal with a lot of data.. every time
someone reformats a README (the 50+ GPL's at one point were around
because someone had put in additional spaces or not) you are going to
have a new set of hashes, some other data (permissions might be nice)
and the signature of that line.

In most cases, you can get that information from the original RPM
compared to the system... if you have the RPM :).

rpm -Vp 

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning



From jlaska at redhat.com  Tue Oct 20 23:42:30 2009
From: jlaska at redhat.com (James Laska)
Date: Tue, 20 Oct 2009 19:42:30 -0400
Subject: [Test-Announce] F-12 Beta Blocker Meeting 2009-10-21 @ 15:00 UTC
	(11 AM EDT)
Message-ID: <1256082150.2148.23.camel@localhost.localdomain>

When: Wednesday, 2009-10-21 @ 15:00 UTC (11 AM EDT)
Where: #fedora-bugzappers on irc.freenode.net

Join us this **Wednesday** for an unscheduled [1] review of the Fedora
12 release blocker bug list [2].  Note, a regularly scheduled review is
planned for this Friday.  However, given that the current list contains
74 unresolved F12Blocker bugs we plan to spend 1 hour cutting that list
down to size.

See the attached file for the current list of Fedora 12 Release blocker
bugs [2].

Have an issue you'd like to propose as an F12 release blocker?  Please
consider the following criteria when escalating an issue:

      * Can this issue be fixed with a future update or is it part of
        the critical path? [3]
      * Is this defect a high (or greater) severity [4] with no, or an
        unreasonable, workaround?
      * Is this an embarrassing bug affecting a large number of users?

See you there!
James

[1]
http://poelstra.fedorapeople.org/schedules/f-12/f-12-quality-tasks.html
[2]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Blocker&hide_resolved=1
[3]
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_how_to_determine_packages_within_the_path
[4]
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity
-------------- next part --------------
= alsa-lib =
514000 - ASSIGNED  - Aureon 5.1 MkII can't do 5.1 anymore
529225 - NEW  - speakers of my notebook doesn't work (headphones are OK)

= alsa-utils =
466377 - NEW  - alsactl segfaults in a boot sequence
523768 - ASSIGNED  - [abrt] crash detected in alsa-utils-1.0.21-2.fc12

= anaconda =
493058 - MODIFIED  - Custom partitioning creation/edit causes traceback
503149 - NEW  - Add features to Anaconda to aid installation on Apple computers
506013 - MODIFIED  - liveinst crash - DBusException ... No such property HwAddress
515441 - MODIFIED  - Can't select local CD/DVD after provide a wrong NFS location during install of F12 alpha
517260 - MODIFIED  - liveinst fails at partitioning screen
517491 - ASSIGNED  - Anaconda fails if filesystem should be shrunk
522609 - MODIFIED  - AttributeError: 'NoneType' object has no attribute 'startswith'
524168 - MODIFIED  - Wrong RAID10 recognition in anaconda while dmraid shows correct values
525924 - NEW  - anaconda 12.30 does not support NFS iso install
526549 - ASSIGNED  - rats_install kickstart fails due to swap device prompt
526697 - MODIFIED  - Trying to change encryption status of partition ends with error message: The mount point "" is in use. Please pick another
527258 - MODIFIED  - When using NFS installation source - Cannot retrieve repository metadata for respository: UIedited_0.
527520 - MODIFIED  - post-install lxde system boots in text mode
527952 - MODIFIED  - AttributeError: 'NoneType' object has no attribute 'disk'
528317 - MODIFIED  - anaconda traceback in getDefaultTimeZone KeyError en_AU
528537 - ASSIGNED  - fails to get kickstart file over nfs.

= DeviceKit-disks =
528909 - NEW  - DevKit 95-devkit-disks.rules should avoid scan all DM devices

= distribution =
distribution - 498968 - NEW  - Fedora 12 Virtualization Target Blocker

= dmraid =
505562 - MODIFIED  - kernel is booted without actived dmraid (ESB2 with lsi firmware)
528097 - MODIFIED  - /sbin/dmraid needs possibly unmounted /usr/lib

= e2fsprogs =
522969 - MODIFIED  - ext3 superblock in future

= empath =
528038 - ASSIGNED  - Where do I enter the IRC server?

= fast-user-switch-applet =
512944 - NEW  - fast-user-switching locks up login screen

= firefox =
513864 - NEW  - Firefox crashes
517879 - NEW  - Java applet kills firefox

= firstaidkit =
519442 - MODIFIED  - serial text-mode firstaidkit does not use same TERM settings as anaconda text-mode
528497 - MODIFIED  - FirstAidKit does not start when using F-12-Beta rescue mode from disc1.iso

= firstboot =
526836 - MODIFIED  - firstboot appears to be confused with multiple monitor setup

= gadmin-squid =
498156 - ASSIGNED  - gadmin-squid does not generate valid squid.conf

= gdm =
527920 - ASSIGNED  - gdm doesn't show user list and crashes - unable to login

= gedit =
521519 - NEW  - gedit 2.27 leaking memory

= gvfs =
509733 - NEW  - Process /usr/libexec/gvfs-gdu-volume-monitor received signal 11

= hsqldb =
517839 - NEW  - bitxor and bitor both mapped to single bitor function
523110 - NEW  - autoincrement bustage on column redefinition

= initscripts =
528222 - NEW  - LiveCD intermittently gets stuck during shutdown

= kde-settings =
520480 - NEW  - F12 KDE blocker

= kernel =
493472 - NEW  - [945GM] KMS: LVDS wrongly detected as connected, DVI monitor resolution incorrectly set
501769 - NEW  - intel hda: snd_pcm_avail/snd_pcm_delay overflows
506075 - ASSIGNED  - snd_intel8x0: snd_pcm_avail()/ snd_pcm_delay() overflow
514600 - ASSIGNED  - Intel 82G965 requires 'nomodeset' workaround to get working text-mode
521512 - ASSIGNED  - KMS: X Window Frozen with Radeon XPRESS 200M

= livecd-tools =
529209 - MODIFIED  - PATCH: Tell dracut not to ask for LUKS passwords or activate mdraid sets

= nautilus =
523815 - NEW  - nautilus hoses vino

= NetworkManager =
529766 - MODIFIED  - applet won't start

= nss =
519766 - MODIFIED  - (nss) FORTIFY_SOURCE buffer overflows and other issues in test suite
520162 - MODIFIED  - nss-devel no longer provides pkgconfig(nss)
527048 - NEW  - nss-sysinit: system-wide nss sql empty key database shouldn't have a password

= PackageKit =
520750 - ASSIGNED  - Software Update windows checks for update does not stop ..

= pango =
522187 - ASSIGNED  - Java (so Eclipse too) crashes

= perl =
510127 - ASSIGNED  - perl taint bug

= plymouth =
527089 - NEW  - repaire console is not accessible
527426 - ASSIGNED  - (plymouth) No text prompt for encryption password (but keyboard input is accepted)

= polkit =
526044 - NEW  - Using invalid subject type crashes polkitd

= redhat-lsb =
523270 - NEW  - /usr/sbin/redhat_lsb_trigger.x86_64 hangs

= setuptool =
529794 - MODIFIED  - cannot modify firewall using 'setup'

= thunderbird =
526154 - ASSIGNED  - localisation breaks sending mail

= unixODBC =
518623 - ON_QA  - busted sizes for SQLBIGINT and ODBCINT64 etc

= webkitgtk =
516057 - ASSIGNED  - gets whacked by selinux execmem check

= xorg-x11-drv-ati =
518962 - NEW  - ATI - Caught signal 11 (Segmentation fault). Server aborting
521322 - ASSIGNED  - no graphics and no console for F12-Snap1-x86_64-Live
522137 - ASSIGNED  - Test_Day:2009-09-09_Radeon: Multiple tests crash X.org
522929 - NEW  - repeated system crashes
522970 - ASSIGNED  - popup messages unreadable

= xorg-x11-drv-intel =
528048 - ASSIGNED  - display black after resume

= xorg-x11-drv-neomagic =
523800 - ASSIGNED  - X.org doesn't work on ThinkPad 600X (NeoMagic MagicGraph256ZX)

= xorg-x11-drv-nouveau =
528005 - NEW  - X server crash

= xorg-x11-server =
514415 - NEW  - X server locks up every time notification is about to be displayed
528312 - ASSIGNED  - udev takes almost 100% CPU on resume from suspend (and Xorg are to be blamed)

= xulrunner =
512845 - ASSIGNED  - setroubleshoot:      SELinux is preventing firefox from changing a writable memory segment executable.

= yaboot =
526021 - ASSIGNED  - f12 beta failed to boot on ppc platform after  autopart and encrypted installation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
-------------- next part --------------
_______________________________________________
test-announce mailing list
test-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

From jkeating at redhat.com  Wed Oct 21 00:01:22 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Oct 2009 17:01:22 -0700
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy
 for Fedora 12)
In-Reply-To: <1256080283.16609.277.camel@wicktop.localdomain>
References: <4ADE2B51.4080006@redhat.com>
	<1256080283.16609.277.camel@wicktop.localdomain>
Message-ID: <1256083282.4242.38.camel@localhost.localdomain>

On Wed, 2009-10-21 at 01:11 +0200, Christoph Wickert wrote:
> 
> What really scares me is that there is a number of security updates in
> bodhi that don't have a tag request in trac. Are maintainers that
> careless? We don't want F12 released with 6 weeks old security bugs, so
> it might be worth to mail their owners if there is no tag request.

"security" is a pretty broad and vague moniker.  Are any of these known
privilege escalations, or could they just be crashers or DoS? 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jwboyer at gmail.com  Wed Oct 21 00:01:30 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Oct 2009 20:01:30 -0400
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy
	for Fedora 12)
In-Reply-To: <1256080283.16609.277.camel@wicktop.localdomain>
References: <4ADE2B51.4080006@redhat.com>
	<1256080283.16609.277.camel@wicktop.localdomain>
Message-ID: <20091021000130.GA3807@hansolo.jdub.homelinux.org>

On Wed, Oct 21, 2009 at 01:11:23AM +0200, Christoph Wickert wrote:
>Am Dienstag, den 20.10.2009, 17:27 -0400 schrieb Warren Togami:
>
>> Many Builds Not Tagged, but Probably Should Be
>> ==============================================
>> # koji list-tagged --latest dist-f12-updates-candidate
>> This command shows over 400 packages are built for F-12 but not tagged 
>> for release.
>> https://admin.fedoraproject.org/updates/F12/pending
>
>What really scares me is that there is a number of security updates in
>bodhi that don't have a tag request in trac. Are maintainers that
>careless? We don't want F12 released with 6 weeks old security bugs, so

Please be careful with your terminology.  There has been very little in the
way of communication when it comes to F12 and updates, so it would not be
a stretch at all if a large majority of maintainers thought the updates
were getting mashed and repos were being published.  Calling people careless
without real cause is overly hostile and unhelpful.

josh



From christoph.wickert at googlemail.com  Wed Oct 21 00:21:40 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 21 Oct 2009 02:21:40 +0200
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy
 for Fedora 12)
In-Reply-To: <20091021000130.GA3807@hansolo.jdub.homelinux.org>
References: <4ADE2B51.4080006@redhat.com>
	<1256080283.16609.277.camel@wicktop.localdomain>
	<20091021000130.GA3807@hansolo.jdub.homelinux.org>
Message-ID: <1256084500.16609.295.camel@wicktop.localdomain>

Am Dienstag, den 20.10.2009, 20:01 -0400 schrieb Josh Boyer:
> On Wed, Oct 21, 2009 at 01:11:23AM +0200, Christoph Wickert wrote:
> >
> >What really scares me is that there is a number of security updates in
> >bodhi that don't have a tag request in trac. Are maintainers that
> >careless? We don't want F12 released with 6 weeks old security bugs, so
> 
> Please be careful with your terminology.  There has been very little in the
> way of communication when it comes to F12 and updates, so it would not be
> a stretch at all if a large majority of maintainers thought the updates
> were getting mashed and repos were being published.  Calling people careless
> without real cause is overly hostile and unhelpful.

It was not my intention to be hostile in anyway, but I don't think that
I need to be careful with the terminology because it's not mine, but
bodhi's and the maintainer's. They declared their updates as security,
not me.

> josh

Regards,
Christoph



From christoph.wickert at googlemail.com  Wed Oct 21 00:27:46 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 21 Oct 2009 02:27:46 +0200
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy
 for Fedora 12)
In-Reply-To: <1256083282.4242.38.camel@localhost.localdomain>
References: <4ADE2B51.4080006@redhat.com>
	<1256080283.16609.277.camel@wicktop.localdomain>
	<1256083282.4242.38.camel@localhost.localdomain>
Message-ID: <1256084866.16609.302.camel@wicktop.localdomain>

Am Dienstag, den 20.10.2009, 17:01 -0700 schrieb Jesse Keating:
> On Wed, 2009-10-21 at 01:11 +0200, Christoph Wickert wrote:
> > 
> > What really scares me is that there is a number of security updates in
> > bodhi that don't have a tag request in trac. Are maintainers that
> > careless? We don't want F12 released with 6 weeks old security bugs, so
> > it might be worth to mail their owners if there is no tag request.
> 
> "security" is a pretty broad and vague moniker.  Are any of these known
> privilege escalations, or could they just be crashers or DoS? 

AFAICS these are privilege escalations and a have CVE assigned:
https://admin.fedoraproject.org/updates/ocaml-mysql-1.0.4-11.fc12
https://admin.fedoraproject.org/updates/ocaml-postgresql-1.12.3-1.fc12
https://admin.fedoraproject.org/updates/ocaml-camlimages-3.0.1-12.fc12.1
But these are already tagged and the submitter forgot to withdraw the
requests.

Others:
https://admin.fedoraproject.org/updates/perl-Net-OAuth-0.19-1.fc12
https://admin.fedoraproject.org/updates/rt3-3.8.4-6.fc12
this one has no details or comments at all :(

Regards,
Christoph



From wtogami at redhat.com  Wed Oct 21 02:15:29 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Oct 2009 22:15:29 -0400
Subject: Tag the F-12 updates?
In-Reply-To: <1256081817.4242.35.camel@localhost.localdomain>
References: <4ADE0EFA.5090707@redhat.com> <4ADE1E96.8040008@redhat.com>
	<1256081817.4242.35.camel@localhost.localdomain>
Message-ID: <4ADE6EC1.7030700@redhat.com>

On 10/20/2009 07:36 PM, Jesse Keating wrote:
> On Tue, 2009-10-20 at 16:33 -0400, Warren Togami wrote:
>> OTOH, people did put effort into filing bodhi tickets and writing update
>> notes there.  Perhaps this means that everything with bodhi tickets is
>> already good enough for tagging.  We should auto-tag everything non-crit
>> path and have two votes on the rest.
>>
>> Opinions?
>
> This seems to me like the best option at this point.  We can treat the
> bodhi ticket as the rel-eng tag request.

Talked with Jesse in IRC.  It seems we are in agreement that for the 
moment we will treat all bodhi update requests as tag requests.  We will 
flush this queue to rawhide allowing immediate testing to all rawhide 
users.  After a package is tagged into f12-final, the corresponding 
bodhi request will be cancelled to mark it as "done".

To avoid confusion, while we in the short-term will process both rel-eng 
tag requests and Bodhi updates-as-tag-requests, know that the latter is 
only a temporary measure until we figure out the ideal future procedure.

Sometime later we will decide to begin staging real updates in Bodhi. 
Jesse wants to discuss this in Monday's rel-eng meeting.

Warren Togami
wtogami at redhat.com



From erikina at gmail.com  Wed Oct 21 02:26:10 2009
From: erikina at gmail.com (Eric Springer)
Date: Wed, 21 Oct 2009 12:26:10 +1000
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1256004576.4785.17.camel@mylaptop.myhome>
References: <5256d0b0910150051u4f3f15e8q7c8213bfbb3bcd5e@mail.gmail.com> 
	<1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain> 
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome> 
	 
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com> 
	 
	<1256004576.4785.17.camel@mylaptop.myhome>
Message-ID: 

On Tue, Oct 20, 2009 at 12:09 PM, Steven James Drinnan wrote:

>
> Well any ideas, for me Package Kit would be the way to go. Then users
> could add the packages or groups to the exclude list. Maybe an extra
> password (optional) for parents / supervisors.
>
> Or like was mentioned  a way to create a YUM exclude list.
>
> Stop this bickering lets try and solve an issue.
>
> Steven
>
>
> It's probably abusing the system and breaks a million guidelines, but what
about making a "no-offensive-packages" package that explicitly conflicts
with a list of offensive packages?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wtogami at redhat.com  Wed Oct 21 03:15:55 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Oct 2009 23:15:55 -0400
Subject: Tag the F-12 updates?
In-Reply-To: <4ADE6EC1.7030700@redhat.com>
References: <4ADE0EFA.5090707@redhat.com>
	<4ADE1E96.8040008@redhat.com>	<1256081817.4242.35.camel@localhost.localdomain>
	<4ADE6EC1.7030700@redhat.com>
Message-ID: <4ADE7CEB.6020609@redhat.com>

sssd-0.6.1-2.fc12 skrooge-0.5.2-2.fc12 translate-toolkit-1.4.1-2.fc12 
vhostmd-0.4-0.2.gitea2f772d.fc12 qtcurve-gtk2-0.69.0-1.fc12 
qtcurve-kde4-0.69.0-1.fc12 gfs-ignacio-fonts-20090923-1.fc12 
adf-tribun-fonts-1.13-1.fc12  gdl-0.9-0.7.rc3.fc12

Tagged these from the oldest bodhi requests.  Need to sleep now.  Will 
tag more tomorrow.

Warren



From tonynelson at georgeanelson.com  Wed Oct 21 03:17:54 2009
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Tue, 20 Oct 2009 23:17:54 -0400
Subject: rpmnew files
In-Reply-To: <4ADE3068.50408@nodata.co.uk> (from lsof@nodata.co.uk on Tue
	Oct 20 17:49:28 2009)
Message-ID: <1256095074.7406.1@localhost.localdomain>

On 09-10-20 17:49:28, nodata wrote:
> Hi,
> 
> What's with the extra rpmnew files on an upgrade?
> 
> Some examples:
> # md5sum  /etc/pki/tls/openssl.cnf.rpmnew /etc/pki/tls/openssl.cnf
> 7c8f8d809c5b618e1604207525161101  /etc/pki/tls/openssl.cnf.rpmnew
> 7c8f8d809c5b618e1604207525161101  /etc/pki/tls/openssl.cnf
 ...

Let me tell you about the `cmp` command.  In my case:

    # cmp /etc/yum.repos.d/rpmfusion-free.repo*
    # cmp /usr/lib/security/classpath.security*
    /usr/lib/security/classpath.security /usr/lib/security/
    classpath.security.rpmnew differ: byte 1874, line 39

:-)


> /var/lib/games/same-gnome.Small.scores.rpmnew
> /var/log/mail/statistics.rpmnew
> 
> Not sure why we would ever need an rpmnew file for that: should these
> be labelled as something other than config files?

Or perhaps not make .rpmnew files for empty config files.


> Another one:
> 
> # md5sum /usr/share/info/dir.rpmnew /usr/share/info/dir
> 91ba35a21c163a55982bedaab076bc7f  /usr/share/info/dir.rpmnew
> 0737290f14a0ce86986de276d1083783  /usr/share/info/dir
> # wc -l /usr/share/info/dir.rpmnew /usr/share/info/dir
>     22 /usr/share/info/dir.rpmnew
>   2127 /usr/share/info/dir
>   2149 total
> 
> I didn't change this file. That's weird. Same case here:
 ...

It's actually a sort of database for the info command.

-- 
____________________________________________________________________
TonyN.:'                       
      '                              



From Axel.Thimm at ATrpms.net  Wed Oct 21 04:13:40 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 21 Oct 2009 07:13:40 +0300
Subject: Are packages w/o necessary kernel modules allowed?
In-Reply-To: <20091015055101.GA2274@wolff.to>
References: 
	<4AD5EE49.60608@freenet.de> <4AD5FCC7.409@fetzig.org>
	<20091014172500.GB16313@wolff.to>
	<20091015050919.GA7441@victor.nirvana>
	<20091015055101.GA2274@wolff.to>
Message-ID: <20091021041340.GA31332@victor.nirvana>

On Thu, Oct 15, 2009 at 12:51:01AM -0500, Bruno Wolff III wrote:
> > > Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time
> > > without having a version for a specific version Fedora. For example there
> > > is no rawhide version now and there was a long period without one for
> > > F11.

I uploaded some F12 builds.

> > about a month or so before the targeted release date (which means
> > about now). I don't think that F11 was w/o dahdi-linux kmdls for any
> > long period.
> 
> Possibly it was during the F11 rawhide period that I looked and I didn't
> check back for a while after the release.
> 
> Unfortunately my tdm card is in my only machine at home that has 3d graphics at
> all working using the drivers in Fedora. And I needed to go to rawhide to
> get that working more than I needed to having tdm card working (though in
> the end I got both).

Give the current packages a try, if there are issues we'll get them fixed.

> > `recursion' warnings due to rpm's limitation of macros depth (which
> > has nothing to do with recursion), which is at 16, but in reality
> > means about 3-4 nested macros.
> 
> Yes. But I didn't see any clear instructions for how to work around it.
> It seems that for some people using --define can work around the problem
> if you know what to define. There was also a comment that you don't see
> the problem because of something in your environment but I didn't see
> any directions on how to set up a similar environment.

I use --define kmdl_kernelsrcdir /.../, that's all. But the error is
still just cosmetic, if I encounter it in a manual build, the build
still succeeds.

> 
> > > What I had to do for F12 is grab a spec file (that get's updates at
> > > the source) that was proposed for rpmfusion (but never got adopted
> > > by them) and then use an svn version of dahdi that has a fix for a
> > > change in the way the kernel is being built (some compatibility
> > > feature that got dropped in 2.6.32).  That box has been extra
> > > unstable lately, though I don't know if that is do to 3D graphics or
> > > dahdi-linux.
> > 
> > Have you tried the common src.rpm at ATrpms? Maybe you should check
> > out ATrpms in a couple of days and see whether there is dahdi support
> > for F12 there.
> 
> I tried using the dahdi-linux src rpm while having atrpms-rpm-config
> installed, but hit the recursion problem and got stuck there. I would
> still have had the problem with the last released dahdi not working
> with 2.6.31 kernels. But fixing that would have taken the same route
> as with the path I ended up taking.
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From hidenori.ishii at avasys.jp  Wed Oct 21 04:54:32 2009
From: hidenori.ishii at avasys.jp (hidenori.ishii at avasys.jp)
Date: Wed, 21 Oct 2009 13:54:32 +0900
Subject: Fix possibility of infinite loop in init scripts in time for Fedora
	12?
Message-ID: 

A colleague of mine submitted a bug report regarding an infinite loop
triggered when calling `lsb_start_daemon` with the `-p` option[1].  This
bug has been around since at least Fedora 9 and is still present in the
beta for Fedora 12.

Considering the fact that `lsb_start_daemon` is supposed to be called
from init scripts, this may hang the boot process.  That's pretty bad.
I know it's a bit late, but seeing that there is a patch, any chance of
getting this in for Fedora 12?

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=485367

Thanks in advance,

--------------------------------------------------------
Hidenori Ishii:                       AVASYS CORPORATION
--------------------------------------------------------



From fedora at camperquake.de  Wed Oct 21 06:47:02 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 21 Oct 2009 08:47:02 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>
Message-ID: <20091021084702.43dcba99@dhcp03.addix.net>

Hi.

On Tue, 20 Oct 2009 17:40:46 -0600, Stephen John Smoogen wrote:

> In most cases, you can get that information from the original RPM
> compared to the system... if you have the RPM :).
> 
> rpm -Vp 

Which is pretty much what I want, just pulling the data from an external
(signed) source instead of the local RPM database.



From kevin.kofler at chello.at  Wed Oct 21 06:49:35 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Oct 2009 08:49:35 +0200
Subject: How about releasing an update of xorg-x11-drv-intel for Fedora
	11
References: <234fa2210910040230m5f70263bm696158c9b9a11883@mail.gmail.com>
	<4AC8B9CC.8050703@bitwagon.com> <4ACCA26A.7020808@beam.ltd.uk>
	<20091007144410.GA30884@hansolo.jdub.homelinux.org>
	<4ACDB6EE.8080606@beam.ltd.uk> <20091008125159.GA25579@wolff.to>
	<4ACDE392.1060208@beam.ltd.uk>
	<1255019839.2291.91.camel@adam.local.net>
	<1255043946.18105.3.camel@localhost>
	<1255060578.9958.11.camel@code.and.org>
	 
	 
	 <4AD830CA.3010407@fedoraproject.org>
	 <1255925098.9430.9.camel@code.and.org>
Message-ID: 

James Antill wrote:
>  Wow ... it's almost as if we need a place where developers could put
> _updates_ for a significant amount of time so that users could do some
> _testing_ on them, under each of their particular conditions. We could
> maybe use this instead of developers hitting the go button when they
> didn't get an avalanche of BZs immediately.

We use updates-testing very carefully in KDE SIG. But many users only start 
trying out updates when they go stable, no matter how long they've been in 
testing. :-( So some bugs will always slip through the cracks (and not just 
in KDE). Any testing repository will by definition only be used by testers, 
i.e. by a rather small subset of our userbase.

But I think that overall, our updates are a good thing. They aren't perfect, 
but no software is! And if you read the complaints about Vi$ta service packs 
rendering some systems unbootable, it's not like our competition is doing 
any better. AFAIK, we haven't had serious breakage like those KMail IMAP 
issues for a while now.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 21 06:53:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Oct 2009 08:53:52 +0200
Subject: Rationale behind _cmake_skip_rpath choice
	in	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr> 
	<4ADDE590.5010703@sophia.inria.fr> 
Message-ID: 

Rex Dieter wrote:
> I'm convinced to revert, I'll run the change by my fellow cmake
> maintainers (I think we have buy-in from everyone though).

Please test that we really don't end up with standard paths like /usr/lib or 
/usr/lib64 in the rpath of installed executables when doing that! Last time 
we tried not using CMAKE_SKIP_RPATH, that's exactly what happened.

(Also note that %cmake_kde4 will probably always need the CMAKE_SKIP_RPATH 
unless we can get CMake to understand that %{_libdir}/kde4/devel contains 
only symlinks. But that's a separate issue from the above.)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 21 06:58:41 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Oct 2009 08:58:41 +0200
Subject: Rationale behind _cmake_skip_rpath choice
	in	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr> 
	<4ADDE590.5010703@sophia.inria.fr>
Message-ID: 

Theodore Papadopoulo wrote:
> According to http://www.itk.org/Wiki/CMake_RPATH_handling this is now
> corrected since almost two years (december 2007).

We tried it in a 2.6.x, which is more recent than that, and it didn't work. 
(We ended up with things like /usr/lib or /usr/lib64 being set as an rpath, 
which is against Fedora guidelines.)

> The %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON is a change dating in
> last january. I cannot explain it as it was already cmake-2.6 as far as I
> can tell.

That's because we had the issue with 2.6.

> Actually, cmake re-links libraries without rpath at installation time
> (according to the previous page).

That information is outdated. 2.4 relinked the binaries, 2.6 uses some 
direct ELF editing hack to edit the rpath out instead (it's faster).

> The .shell wrappers are a KDE specificity. This is not standard cmake
> stuff.

That's interesting. I thought these come from CMake itself.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 21 07:02:58 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Oct 2009 09:02:58 +0200
Subject: Status of touchpad support in F12 for kdm?
References: 
	
	
	
Message-ID: 

Mike Cloaked wrote:
> Exactly which config interface are you referring to that enables this for
> xorg for kdm? Many systems do not have xorg.conf once installed, so
> presumably there is something else?

Well, KDM runs as root, so usually root's KDE settings are relevant, but 
stock KDE doesn't have touchpad settings. We have kcm_touchpad which is 
being packaged, but the way its settings are loaded at startup probably only 
works for real KDE sessions, not KDM's minimal environment. (GDM runs an 
almost complete GNOME these days, they even run a window manager inside GDM! 
KDM has a much less bloated design.)

Systemwide HAL FDI files will definitely work to set touchpad options for 
KDM.

        Kevin Kofler



From liangsuilong at gmail.com  Wed Oct 21 07:16:21 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Wed, 21 Oct 2009 15:16:21 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: 

Today I upgrade my Fedora to Fedora 12 Beta, It looks very well. But I found
ATi display driver does not run well.
My display card is Sapphire HD3650 with 256MB GDDR3 VRAM (RV635). I choose
OSS driver for my card. Glxgears runs so smoothly with xorg-x11-drv-ati
because of KMS by default, nevertheless, rolling up and down in the
gnome-terminal is quite slow. The performance of glxgears is about 210 frams
per second. In addition, Switching to another window in Fedora 12 Beta is
not as fast in Fedora 11. Later, I install xorg-x11-drv-radeonhd and set it
by default in the system-config-display. Then I restart the X. I can not log
into gnome. The screen turns white. I found xorg-x11-drv-radeonhd is too
old, The version is 1.2.5 in the rawhide and the latest version 1.3.0 has
been released for a long time. Now I turn back to xorg-x11-drv-ati. At last,
I do not know which packages causes the  problem, maybe xorg-x11-drv-ati,
maybe xorg-x11-drv-radeonhd, maybe Mesa. So I suggest that packager updates
some packge related to ATi R600/R700 display card.

My Fedora 12 box is Athlon X2 4200+ and 2GB RAM, a 250GB HDD only for
Fedora, a mainborad with MCP55SLI and a Sapphire HD3650.

Another question, Will Fedora 12 provide Opensource 3D acceleration driver
for R600/R700?

-- 
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tomek at pipebreaker.pl  Wed Oct 21 07:20:25 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Wed, 21 Oct 2009 09:20:25 +0200
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
	
Message-ID: <20091021072025.GB23138@mother.pipebreaker.pl>

On Wed, Oct 21, 2009 at 03:16:21PM +0800, Liang Suilong wrote:
> Another question, Will Fedora 12 provide Opensource 3D acceleration driver
> for R600/R700?

  From F12 beta announcment:

* Graphics support improvements - Fedora 12 introduces experimental 3D                                                                         
support for AMD Radeon HD 2400 and later graphics cards. To try it out,                                                                        
install the mesa-dri-drivers-experimental package. 

-- 
Tomasz Torcz                 Morality must always be based on practicality.
xmpp: zdzichubg at chrome.pl                -- Baron Vladimir Harkonnen



From swhiteho at redhat.com  Wed Oct 21 09:11:37 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Wed, 21 Oct 2009 10:11:37 +0100
Subject: Unresponsive maintainer for system-config-cluster
Message-ID: <1256116297.2716.10.camel@localhost.localdomain>

Hi,

Jim Parsons left Red Hat a little while back and the only contact
details I have is his Red Hat email address, which is of course no
longer valid. I've opened a bugzilla #530027 as per the unresponsive
maintainer procedure, but I was hoping to be able to skip the section
regarding sending of messages since there seems little point sending to
an email address which I know (and which other Red Hat employees can
easily verify) will not be answered.

Instead I've emailed the one other person who had access to that package
and that has also gone unanswered (see the bugzilla).

There are a number of outstanding bugs filed against
system-config-cluster (including the fact that it seems that it has not
passed an initial review) which I've listed out in the bugzilla.

I would like to either fix (or preferably just remove) this package as
it creates configs for GFS2 which are incorrect and is thus causing
confusion to all who attempt to use it.

Therefore this is my formal request to become maintainer of this
package,

Steve.




From rjones at redhat.com  Wed Oct 21 09:44:15 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 21 Oct 2009 10:44:15 +0100
Subject: F12 Security Updates not tagged (Re: Reminder: Tagging Policy
	for Fedora 12)
In-Reply-To: <1256084866.16609.302.camel@wicktop.localdomain>
References: <4ADE2B51.4080006@redhat.com>
	<1256080283.16609.277.camel@wicktop.localdomain>
	<1256083282.4242.38.camel@localhost.localdomain>
	<1256084866.16609.302.camel@wicktop.localdomain>
Message-ID: <20091021094415.GA4123@amd.home.annexia.org>

On Wed, Oct 21, 2009 at 02:27:46AM +0200, Christoph Wickert wrote:
> Am Dienstag, den 20.10.2009, 17:01 -0700 schrieb Jesse Keating:
> > On Wed, 2009-10-21 at 01:11 +0200, Christoph Wickert wrote:
> > > 
> > > What really scares me is that there is a number of security updates in
> > > bodhi that don't have a tag request in trac. Are maintainers that
> > > careless? We don't want F12 released with 6 weeks old security bugs, so
> > > it might be worth to mail their owners if there is no tag request.
> > 
> > "security" is a pretty broad and vague moniker.  Are any of these known
> > privilege escalations, or could they just be crashers or DoS? 
> 
> AFAICS these are privilege escalations and a have CVE assigned:
> https://admin.fedoraproject.org/updates/ocaml-mysql-1.0.4-11.fc12
> https://admin.fedoraproject.org/updates/ocaml-postgresql-1.12.3-1.fc12
> https://admin.fedoraproject.org/updates/ocaml-camlimages-3.0.1-12.fc12.1
> But these are already tagged and the submitter forgot to withdraw the
> requests.

... Didn't know I was supposed to.  But as you say, all three
had trac requests and rel-eng have dealt with them already.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From mkkp4x4 at gmail.com  Wed Oct 21 10:31:27 2009
From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=)
Date: Wed, 21 Oct 2009 12:31:27 +0200
Subject: Fedora 12 Beta
Message-ID: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>

Hi,

I just installed F12 Beta. Here are some thoughts

1 - during the first boot smolt panicked - there was an error related
to time zones in python-sitepackages or something like that.
2 - I tried to reboot the system - ctrl + alt + del, but it stopped on
process termination
3 - after reboot system wanted my root password for partition check -
after I pressed each key, the system gave me a communicate about wrong
password
I guess this is a plymouth bug. I disabled it in grub conf and system
works correctly. Is there any chance to completely remove plymouth
from the system? (even from initrd)
4 - F12 boots really slow on my laptop
http://www.stardust.webpages.pl/files/tmp/bootchart.png something
wrong is happening while udev loading
5 - default gnome sound scheme is terrible

The first impression isn't good.

Regards,
Michal



From kparal at redhat.com  Wed Oct 21 10:56:26 2009
From: kparal at redhat.com (Kamil Paral)
Date: Wed, 21 Oct 2009 06:56:26 -0400 (EDT)
Subject: new tool: rpmguard - print important differences between RPMs
In-Reply-To: <54723383.938161256122543756.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Hi,

I have created a simple tool called rpmguard for checking differences 
between RPM packages. It is very similar to rpmdiff, but it prints only
important changes, not all. Therefore it can be used every time a new 
package is built to easily see if something hasn?t went completely wrong.

Read more on:
http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/

Any comments welcome!

Kamil



From rawhide at fedoraproject.org  Wed Oct 21 12:00:22 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 21 Oct 2009 12:00:22 +0000
Subject: rawhide report: 20091021 changes
Message-ID: <20091021120022.GA4144@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct 21 06:15:23 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package adf-tribun-fonts
        A newsprint-like serif typeface
New package gfs-ignacio-fonts
        A majuscule Greek font
New package qtcurve-gtk2
        This is a set of widget styles for Gtk2 based apps
New package qtcurve-kde4
        This is a set of widget styles for Qt4/KDE4 based apps
New package vhostmd
        Virtualization host metrics daemon
Removed package kerneloops
Updated Packages:

OpenEXR_CTL-1.0.1-9.fc12
------------------------
* Tue Oct 20 2009 kwizart < kwizart at gmail.com > - 1.0.1-9
- Rebuild for F-12

* Fri Jul 24 2009 Fedora Release Engineering  - 1.0.1-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


OpenEXR_Viewers-1.0.1-7.fc12
----------------------------
* Tue Oct 20 2009 kwizart < kwizart at gmail.com > - 1.0.1-7
- Rebuild for F-12

* Fri Jul 24 2009 Fedora Release Engineering  - 1.0.1-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PerceptualDiff-1.1.1-1.fc12
---------------------------
* Tue Oct 20 2009 kwizart < kwizart at gmail.com > - 1.1.1-1
- Update to 1.1.1

* Fri Jul 24 2009 Fedora Release Engineering  - 1.0.2-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


Pixie-2.2.6-3.fc12
------------------
* Tue Oct 20 2009 kwizart < kwizart at gmail.com > - 2.2.6-3
- Rebuild for F-12

* Fri Jul 24 2009 Fedora Release Engineering  - 2.2.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


boo-0.9.2.3383-2.fc12
---------------------
* Tue Oct 06 2009 Paul Lange  - 0.9.2.3383-2
- Move Boo.NAnt.Tasks.dll to boo-devel


brasero-2.28.2-1.fc12
---------------------
* Tue Oct 20 2009 Matthias Clasen  2.28.2-1
- Update to 2.28.2


colossus-0.9.3-1.fc12
---------------------
* Fri Oct 16 2009 Bruno Wolff III  - 0.9.3-1
- Rebase to 0.9.3
- Adjust script for grabbing source to be able to grab from branches
- Fixed 2877055: Some GUI preferences don't load on startup
- Fixed: 2864777 Illegal rangestrike over walls
- Do not choose Experimental AI as "A Random AI" because it occasionally crashes
- Fixed: 2859914 Balrog placement ignores score (aka: Balrog every 300 again, not 50)
- Fixed: 2864790 Aborting load game with remote player - No GetPlayers dialog
- Fixed: 2838276 "my Strike Skill" is wrong for nonnatives to bramble (actually, just improved the dialog to make it's meaning clearer)
- Fixed: 2855208 Balrog exception in V0.9.2 (ConcurrentModificationException)
- See: http://colossus.sourceforge.net/docs/RecentChangesDetails.html


control-center-2.28.1-1.fc12
----------------------------
* Mon Oct 19 2009 Matthias Clasen  2.28.1-1
- Update to 2.28.1, just translation updates


dmraid-1.0.0.rc16-4.fc12
------------------------
* Fri Oct 16 2009 Heinz Mauelshagen  - 1.0.0.rc16-4
- bz526157: fix manual pages for dmraid.static and dm_dso_reg_tool
- bz505562: ddf1 metadata format handler LSI persistent name fix
- bz524168: fix pdc metadata format handler to report the correct number
  of devices in a RAID10 subset
- bz528097: move libraries to /lib* in order to avoid catch22
  with unmountable u/usr


evince-2.28.1-1.fc12
--------------------
* Tue Oct 20 2009 Marek Kasik  - 2.28.1-1
- Update to 2.28.1
- Add evince-pdf-print-revert.patch (reverts upstream's change
- of print which revealed the bug #517310)


filezilla-3.2.8.1-1.fc12
------------------------
* Fri Oct 16 2009 kwizart < kwizart at gmail.com > - 3.2.8.1-1
- Update to 3.2.8.1

* Wed Oct 07 2009 kwizart < kwizart at gmail.com > - 3.2.8-1
- Update to 3.2.8

* Sat Oct 03 2009 kwizart < kwizart at gmail.com > - 3.2.8-0.1-rc1
- Update to 3.2.8-rc1


findutils-4.4.2-4.fc12
----------------------
* Tue Oct 20 2009 Kamil Dudka  - 1:4.4.2-4
- make it possible to recognize an autofs filesystem by find
- add a new find's option -xautofs to not descend directories on autofs
  filesystems


gdl-0.9-0.7.rc3.fc12
--------------------
* Thu Oct 15 2009 - Orion Poplawski  - 0.9-0.7.rc3
- Update to 0.9rc3
- Drop gcc43, ppc64, friend patches fixed upstream
- Add source for makecvstarball
- Rebase antlr patch, add automake source version
- Add conditionals for EPEL builds
- Add %check section


gnome-bluetooth-2.28.3-1.fc12
-----------------------------
* Tue Oct 20 2009 Bastien Nocera  2.28.2-1
- Update to 2.28.2

* Tue Oct 20 2009 Bastien Nocera  2.28.3-1
- Update to 2.28.3


gnome-keyring-2.28.1-2.fc12
---------------------------
* Mon Oct 19 2009 Tomas Bzatek  - 2.28.1-1
- Update to 2.28.1

* Mon Oct 19 2009 Ray Strode  2.28.1-2
- Don't start keyring daemon if pam password is empty
  Patch from Dan Walsh. (bug 529709)

* Wed Oct 14 2009 Ray Strode  - 2.28.0-4
- Die on ctrl-alt-backspace and other abrupt exits


gnome-panel-2.28.0-11.fc12
--------------------------
* Tue Oct 20 2009 Matthias Clasen  2.28.0-10
- Reduce the inter-applet padding

* Tue Oct 20 2009 Matthias Clasen  2.28.0-11
- Remove a leftover debugging statement

* Mon Oct 19 2009 Matthias Clasen  2.28.0-9
- Actually set non-zero padding

* Mon Oct 19 2009 Ray Strode  2.28.0-9
- Add explicit libs requires (bug 525600)

* Sat Oct 17 2009 Matthias Clasen  2.28.0-8
- Add padding around status icons


gnome-settings-daemon-2.28.1-1.fc12
-----------------------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


gnome-terminal-2.28.1-1.fc12
----------------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1, translation updates


gnome-themes-2.28.1-2.fc12
--------------------------
* Tue Oct 20 2009 Matthias Clasen  - 2.28.1-2
- Add scalable versions of the xdg folder icons to Mist

* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1

* Sun Oct 18 2009 Matthias Clasen  - 2.28.0-2
- Add xdg folder icons to Mist


gnumeric-1.8.4-5.fc12
---------------------
* Wed Oct 21 2009 Robert Scheck  1:1.8.4-5
- Applied 4 patches from the 1.8 stable branch (#500890, #505001)

* Mon Oct 12 2009 Huzaifa Sidhpurwala  1:1.8.4-4
- Resolve rhbz #500890


gtk2-2.18.3-4.fc12
------------------
* Tue Oct 20 2009 Matthias Clasen  - 2.18.3-4
- Make tooltips look nicer

* Sun Oct 18 2009 Matthias Clasen  - 2.18.3-3
- Fix a size allocation problem uncovered by the previous patch

* Sat Oct 17 2009 Matthias Clasen  - 2.18.3-1
- Update to 2.18.3

* Sat Oct 17 2009 Matthias Clasen  - 2.18.3-2
- Support padding around status icons


gtk2-engines-2.18.4-2.fc12
--------------------------
* Tue Oct 20 2009 Matthias Clasen  - 2.18.4-2
- New tooltip appearance


gvfs-1.4.1-1.fc12
-----------------
* Tue Oct 20 2009 Tomas Bzatek  - 1.4.1-1
- Update to 1.4.1

* Fri Oct 16 2009 Tomas Bzatek  - 1.4.0-7
- HTTP: Support g_file_input_stream_query_info()
- HTTP: Use libsoup header parsing function
- Set correct MIME type for MTP music players


hal-0.5.13-9.fc12
-----------------
* Mon Oct 19 2009 Peter Hutterer  0.5.13-9
- hal-xen-unignore-axes.patch: force evdev to allow rel+abs axes on the Xen
  Virtual Pointer device (#523914)

* Tue Aug 11 2009 Ville Skytt?  - 0.5.13-8
- Use bzipped upstream tarball.


irda-utils-0.9.18-10.fc12
-------------------------
* Tue Oct 20 2009 Orion Poplawski  - 0.9.18-10
- Add patch to fix installing of initscript into buildroot

* Mon Aug 10 2009 Ville Skytt?  - 0.9.18-9
- Convert specfile to UTF-8.

* Fri Jul 24 2009 Fedora Release Engineering  - 0.9.18-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


isdn4k-utils-3.2-66.fc12
------------------------
* Mon Oct 19 2009 Than Ngo  - 3.2-66
- add missing man pages
- add upstream fixes


itcl-3.4-5.fc12
---------------
* Fri Jul 24 2009 Fedora Release Engineering  - 3.4-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


libcanberra-0.22-1.fc12
-----------------------
* Tue Oct 20 2009 Lennart Poettering  0.22-1
- New version 0.22


libcapseo-0.3.0-0.3.20081031git431a293.fc12
-------------------------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.3.0-0.3.20081031git431a293
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


libiodbc-3.52.7-1.fc12
----------------------
* Tue Oct 20 2009 Rex Dieter  3.52.7-1
- libiodbc-3.52.7


libsoup-2.28.1-1.fc12
---------------------
* Mon Oct 19 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1


pari-2.3.4-3.fc12
-----------------
* Sat Jul 25 2009 Fedora Release Engineering  - 2.3.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


perl-XML-Twig-3.33-1.fc12
-------------------------
* Mon Oct 19 2009 Marcela Ma?l??ov?  - 3.33-1
- new development release which should fix various bug reports e.g. 529220


polkit-0.95-0.git20090913.3.fc12
--------------------------------
* Tue Oct 20 2009 Matthias Clasen  - 0.95-0.git20090913.3
- Fix a typo in pklocalauthority(8)


python-cheetah-2.2.2-2.fc12
---------------------------
* Tue Oct 20 2009 Mike Bonnet  - 2.2.2-2
- backport significant improvements to utf-8/unicode handling from upstream


python-kaa-imlib2-0.2.3-8.fc12
------------------------------
* Tue Oct 20 2009 kwizart < kwizart at gmail.com > - 0.2.3-8
- Rebuild for F-12
- Add missing BR

* Sun Jul 26 2009 Fedora Release Engineering  - 0.2.3-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Wed Jul 01 2009 kwizart < kwizart at gmail.com > - 0.2.3-5
- Clean BR
- remove unused import md5
- Move to %global


quota-3.17-8.fc12
-----------------
* Wed Sep 30 2009 Ondrej Vasik  1:3.17-8
- add buildrequires for quota_nld, enable-netlink to build
  quota_nld (#526047)


rhythmbox-0.12.5-7.fc12
-----------------------
* Mon Oct 19 2009 Bastien Nocera  0.12.5-7
- Use bicubic volumes in the UI
- Avoid using HEAD to get podcast mime-types


skrooge-0.5.2-2.fc12
--------------------
* Wed Oct 14 2009 Rex Dieter  0.5.2-2
- (HTML) docs patch, use %find_lang --with-kde
- own %{_kde4_appsdir}/skrooge*/ dirs
- %check
unset DISPLAY
: omit extraneous desktop-file-validate's

* Thu Oct 08 2009 Thomas Janssen  0.5.2-1
- Changed to final 0.5.2 version
- Bugfixes, including a nasty bug where one thinks the data is gone
- added HTML documentation
- added localizations


slim-1.3.1-8.fc12
-----------------
* Sat Oct 10 2009 Lorenzo Villani  - 1.3.1-8
- Fix BZ #518068


sssd-0.6.1-2.fc12
-----------------
* Thu Oct 15 2009 Stephen Gallagher  - 0.6.1-2
- Fix missing file permissions for sssd-clients

* Tue Oct 13 2009 Stephen Gallagher  - 0.6.1-1
- Add SSSDConfig API
- Update polish translation for 0.6.0
- Fix long timeout on ldap operation
- Make dp requests more robust


system-config-date-1.9.53-1.fc12
--------------------------------
* Tue Oct 20 2009 Nils Philippsen  - 1.9.53-1
- make translating time zones more robust (#525921)


translate-toolkit-1.4.1-2.fc12
------------------------------
* Thu Oct 15 2009 Dwayne Bailey  - 1.4.1-1
- Update to 1.4.1
   - Better support for printf (including numbered) variables (bug 1118)
   - Fixes for the upcoming Pootle, including combined searches (bug 1036)
   - subtle bug in tmserver handling of the percent sign (%) (bug 1101)
   - obsolete messages seen as translatable (bug 1114)
- Drop patch bug#1114 - obsolete messages should not be translatable

* Thu Oct 15 2009 Dwayne Bailey  - 1.4.1-2
- Retag

* Mon Aug 24 2009 Dwayne Bailey  - 1.4.0-2
- Upstream bug #1114 - obsolete messages should not be translatable


xfconf-4.6.1-4.fc12
-------------------
* Tue Oct 20 2009 Orion Poplawski  - 4.6.1-4
- Add BR perl(ExtUtils::MakeMaker) and perl(Glib::MakeHelper)

* Mon Jul 27 2009 Fedora Release Engineering  - 4.6.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


xorg-x11-drv-evdev-2.3.0-1.fc12
-------------------------------
* Mon Oct 19 2009 Peter Hutterer  2.3.0-1
- evdev 2.3.0

* Thu Oct 08 2009 Peter Hutterer  2.2.99.2-1
- evdev 2.2.99.2


Summary:
Added Packages: 5
Removed Packages: 1
Modified Packages: 45



From atorkhov at gmail.com  Wed Oct 21 12:26:17 2009
From: atorkhov at gmail.com (Alexey Torkhov)
Date: Wed, 21 Oct 2009 16:26:17 +0400
Subject: new tool: rpmguard - print important differences between RPMs
In-Reply-To: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1256127977.9617.7.camel@localhost>

On Wed, 2009-10-21 at 06:56 -0400, Kamil Paral wrote:
> I have created a simple tool called rpmguard for checking differences 
> between RPM packages. It is very similar to rpmdiff, but it prints only
> important changes, not all. Therefore it can be used every time a new 
> package is built to easily see if something hasn?t went completely wrong.
> 
> Read more on:
> http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/
> 
> Any comments welcome!

One more important difference to check between packages is changes in
library symbols. There is tool exist called rpmsodiff to check it. Would
be nice to see that integrated too.

Alexey



From pbrobinson at gmail.com  Wed Oct 21 12:28:17 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 21 Oct 2009 13:28:17 +0100
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <1256062926.2314.270.camel@adam.local.net>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
Message-ID: <5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>

>> As the Dell Latitude D630 is one of the more common devices that smolt
>> reports being used by Fedora I thought I'd mention my upgrade
>> experience and issues for F-12.
>>
>> Probably the two usual things that people query are grahics and wifi.
>> The model I have has the Intel IWL-4965AGN device which as expected
>> works fine.
>>
>> I'm having a few issues with the nouveau driver with plymouth in that
>> it doesn't work at all but if I remove all the options from the kernel
>> boot line it gets to X and apart from some initial corruption as GDM
>> comes up its OK from there. I have no idea how to debug this.
>
> Try adding the parameter 'nomodeset' instead of removing any parameters.
> What happens then?

It has certainly improved it. I wasn't in front of the machine as it
booted this morning so I'll need to check out plymouth this evening
but the responsiveness of the display is improved and I don't get
duplicate mouse pointers now. The performance seems reduced compared
to F-11 though :-(

>> Probably the most annoying is the breakage of sound. This seems to
>> have every other kernel/alsa/pulseaudio update and was an issue on and
>> off right through F-11 as well so its not exactly surprising but also
>> disappointing that one of the most common devices running Fedora has
>> sound broken on a semi regular basis. Again some pointers in debugging
>> this so it can be fixed by F-12 final would be great.
>
> https://fedoraproject.org/wiki/Bug_info_kernel_sound
>
>> The only other very minor issue I see is that the icon spacing on the
>> gnome panels is massive!
>
> This is currently being 'enthusiastically' discussed on
> fedora-desktop-list. :)

Thanks for the pointer. I noticed its also been tweaked in todays rawhide.

I've also noticed of late that yum performance has gone through the floor too.



From pbrobinson at gmail.com  Wed Oct 21 12:31:39 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 21 Oct 2009 13:31:39 +0100
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
	<5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
Message-ID: <5256d0b0910210531o2c6d4d1fn3be8fdcff096bb7f@mail.gmail.com>

On Wed, Oct 21, 2009 at 1:28 PM, Peter Robinson  wrote:
>>> As the Dell Latitude D630 is one of the more common devices that smolt
>>> reports being used by Fedora I thought I'd mention my upgrade
>>> experience and issues for F-12.
>>>
>>> Probably the two usual things that people query are grahics and wifi.
>>> The model I have has the Intel IWL-4965AGN device which as expected
>>> works fine.
>>>
>>> I'm having a few issues with the nouveau driver with plymouth in that
>>> it doesn't work at all but if I remove all the options from the kernel
>>> boot line it gets to X and apart from some initial corruption as GDM
>>> comes up its OK from there. I have no idea how to debug this.
>>
>> Try adding the parameter 'nomodeset' instead of removing any parameters.
>> What happens then?
>
> It has certainly improved it. I wasn't in front of the machine as it
> booted this morning so I'll need to check out plymouth this evening
> but the responsiveness of the display is improved and I don't get
> duplicate mouse pointers now. The performance seems reduced compared
> to F-11 though :-(
>
>>> Probably the most annoying is the breakage of sound. This seems to
>>> have every other kernel/alsa/pulseaudio update and was an issue on and
>>> off right through F-11 as well so its not exactly surprising but also
>>> disappointing that one of the most common devices running Fedora has
>>> sound broken on a semi regular basis. Again some pointers in debugging
>>> this so it can be fixed by F-12 final would be great.
>>
>> https://fedoraproject.org/wiki/Bug_info_kernel_sound
>>
>>> The only other very minor issue I see is that the icon spacing on the
>>> gnome panels is massive!
>>
>> This is currently being 'enthusiastically' discussed on
>> fedora-desktop-list. :)
>
> Thanks for the pointer. I noticed its also been tweaked in todays rawhide.
>
> I've also noticed of late that yum performance has gone through the floor too.

I never finished that. Its currently necking one core of a 2.5 ghz
penryn and using nearly a gig of RAM. It literally now takes hours to
update my Fit-PC (500mhz geode with 256Mb RAM).

Peter



From xjakub at fi.muni.cz  Wed Oct 21 12:40:50 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Wed, 21 Oct 2009 14:40:50 +0200
Subject: Unresponsive maintainer for system-config-cluster
In-Reply-To: <1256116297.2716.10.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
Message-ID: <4ADF0152.3090509@fi.muni.cz>

Hi,

On 10/21/2009 11:11 AM, Steven Whitehouse wrote:
> Hi,
>
> Jim Parsons left Red Hat a little while back and the only contact
> details I have is his Red Hat email address, which is of course no
> longer valid. I've opened a bugzilla #530027 as per the unresponsive
> maintainer procedure, but I was hoping to be able to skip the section
> regarding sending of messages since there seems little point sending to
> an email address which I know (and which other Red Hat employees can
> easily verify) will not be answered.

+1 from here...I already e-mailed Jim Parson a long long time (for sure 
more than a year) ago because of some trivial outstanding bugs in that 
package (missing requires, incorrect pam configuration, ...), some of 
them I fixed then, some are still left. I tried several times and didn't 
get any response.

>
> I would like to either fix (or preferably just remove) this package as
> it creates configs for GFS2 which are incorrect and is thus causing
> confusion to all who attempt to use it.

Hm...I would appreciate keeping the package (...and could fix the very 
trivial of the remaining bugreports), how complicated would it be to fix 
the GFS2 configs? On the other hand, I've heard from somebody of the RH 
cluster team that the package is deprecated at all, how's that?

Regards,
Milos



From swhiteho at redhat.com  Wed Oct 21 12:57:14 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Wed, 21 Oct 2009 13:57:14 +0100
Subject: Unresponsive maintainer for system-config-cluster
In-Reply-To: <4ADF0152.3090509@fi.muni.cz>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<4ADF0152.3090509@fi.muni.cz>
Message-ID: <1256129834.2716.37.camel@localhost.localdomain>

Hi,

On Wed, 2009-10-21 at 14:40 +0200, Milos Jakubicek wrote:
> Hi,
> 
> On 10/21/2009 11:11 AM, Steven Whitehouse wrote:
> > Hi,
> >
> > Jim Parsons left Red Hat a little while back and the only contact
> > details I have is his Red Hat email address, which is of course no
> > longer valid. I've opened a bugzilla #530027 as per the unresponsive
> > maintainer procedure, but I was hoping to be able to skip the section
> > regarding sending of messages since there seems little point sending to
> > an email address which I know (and which other Red Hat employees can
> > easily verify) will not be answered.
> 
> +1 from here...I already e-mailed Jim Parson a long long time (for sure 
> more than a year) ago because of some trivial outstanding bugs in that 
> package (missing requires, incorrect pam configuration, ...), some of 
> them I fixed then, some are still left. I tried several times and didn't 
> get any response.
> 
I've actually found a few more since I wrote that list in the bz too.

> >
> > I would like to either fix (or preferably just remove) this package as
> > it creates configs for GFS2 which are incorrect and is thus causing
> > confusion to all who attempt to use it.
> 
> Hm...I would appreciate keeping the package (...and could fix the very 
> trivial of the remaining bugreports), how complicated would it be to fix 
> the GFS2 configs? On the other hand, I've heard from somebody of the RH 
> cluster team that the package is deprecated at all, how's that?
> 
> Regards,
> Milos
> 
Well if someone wants to maintain it, then I suppose there is no issue.
My understanding is that Conga is the preferred method for graphical
configuration of clusters. Personally I use vi for cluster
configuration :-)

My main concern is the number of people who have tried to use this and
landed up with incorrect/broken configurations or for whom the tool
simply doesn't work.

So once I've managed to get access to the package, if you or anybody
else is keen to take it on then I'm happy to grant all the required
privs or pass maintainership on to others as required,

Steve.




From berrange at redhat.com  Wed Oct 21 13:13:32 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 21 Oct 2009 14:13:32 +0100
Subject: Unresponsive maintainer for system-config-cluster
In-Reply-To: <1256129834.2716.37.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<4ADF0152.3090509@fi.muni.cz>
	<1256129834.2716.37.camel@localhost.localdomain>
Message-ID: <20091021131331.GF4829@redhat.com>

On Wed, Oct 21, 2009 at 01:57:14PM +0100, Steven Whitehouse wrote:
> Hi,
> 
> On Wed, 2009-10-21 at 14:40 +0200, Milos Jakubicek wrote:
> > Hi,
> > 
> > On 10/21/2009 11:11 AM, Steven Whitehouse wrote:
> > > Hi,
> > >
> > > Jim Parsons left Red Hat a little while back and the only contact
> > > details I have is his Red Hat email address, which is of course no
> > > longer valid. I've opened a bugzilla #530027 as per the unresponsive
> > > maintainer procedure, but I was hoping to be able to skip the section
> > > regarding sending of messages since there seems little point sending to
> > > an email address which I know (and which other Red Hat employees can
> > > easily verify) will not be answered.
> > 
> > +1 from here...I already e-mailed Jim Parson a long long time (for sure 
> > more than a year) ago because of some trivial outstanding bugs in that 
> > package (missing requires, incorrect pam configuration, ...), some of 
> > them I fixed then, some are still left. I tried several times and didn't 
> > get any response.
> > 
> I've actually found a few more since I wrote that list in the bz too.
> 
> > >
> > > I would like to either fix (or preferably just remove) this package as
> > > it creates configs for GFS2 which are incorrect and is thus causing
> > > confusion to all who attempt to use it.
> > 
> > Hm...I would appreciate keeping the package (...and could fix the very 
> > trivial of the remaining bugreports), how complicated would it be to fix 
> > the GFS2 configs? On the other hand, I've heard from somebody of the RH 
> > cluster team that the package is deprecated at all, how's that?
>
> Well if someone wants to maintain it, then I suppose there is no issue.
> My understanding is that Conga is the preferred method for graphical
> configuration of clusters. Personally I use vi for cluster
> configuration :-)

I don't think its really viable to suggest that Conga is a replacement
for system-config-cluster. One is a simple desktop UI for editing
cluster config files. The other is a large web based management
infrastructure. Certainly alot of people may want to use Conga, but
I can well imagine people using s-c-c , wouldn't want to deploy a
webapp just to get a tool to edit cluster config files

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From jwboyer at gmail.com  Wed Oct 21 13:13:31 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 21 Oct 2009 09:13:31 -0400
Subject: Tag the F-12 updates?
In-Reply-To: <4ADE7CEB.6020609@redhat.com>
References: <4ADE0EFA.5090707@redhat.com> <4ADE1E96.8040008@redhat.com>
	<1256081817.4242.35.camel@localhost.localdomain>
	<4ADE6EC1.7030700@redhat.com> <4ADE7CEB.6020609@redhat.com>
Message-ID: <20091021131331.GC3807@hansolo.jdub.homelinux.org>

On Tue, Oct 20, 2009 at 11:15:55PM -0400, Warren Togami wrote:
> sssd-0.6.1-2.fc12 skrooge-0.5.2-2.fc12 translate-toolkit-1.4.1-2.fc12  
> vhostmd-0.4-0.2.gitea2f772d.fc12 qtcurve-gtk2-0.69.0-1.fc12  
> qtcurve-kde4-0.69.0-1.fc12 gfs-ignacio-fonts-20090923-1.fc12  
> adf-tribun-fonts-1.13-1.fc12  gdl-0.9-0.7.rc3.fc12
>
> Tagged these from the oldest bodhi requests.  Need to sleep now.  Will  
> tag more tomorrow.

I did quite a few more today and did some duplicate update cleanup.  Will
poke at this as I get time.

For anyone else doing this work, please make sure to delete the updates
after things are in f12-final.

josh



From swhiteho at redhat.com  Wed Oct 21 13:21:22 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Wed, 21 Oct 2009 14:21:22 +0100
Subject: Unresponsive maintainer for system-config-cluster
In-Reply-To: <20091021131331.GF4829@redhat.com>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<4ADF0152.3090509@fi.muni.cz>
	<1256129834.2716.37.camel@localhost.localdomain>
	<20091021131331.GF4829@redhat.com>
Message-ID: <1256131282.2716.42.camel@localhost.localdomain>

Hi,

On Wed, 2009-10-21 at 14:13 +0100, Daniel P. Berrange wrote:
> On Wed, Oct 21, 2009 at 01:57:14PM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Wed, 2009-10-21 at 14:40 +0200, Milos Jakubicek wrote:
> > > Hi,
> > > 
> > > On 10/21/2009 11:11 AM, Steven Whitehouse wrote:
> > > > Hi,
> > > >
> > > > Jim Parsons left Red Hat a little while back and the only contact
> > > > details I have is his Red Hat email address, which is of course no
> > > > longer valid. I've opened a bugzilla #530027 as per the unresponsive
> > > > maintainer procedure, but I was hoping to be able to skip the section
> > > > regarding sending of messages since there seems little point sending to
> > > > an email address which I know (and which other Red Hat employees can
> > > > easily verify) will not be answered.
> > > 
> > > +1 from here...I already e-mailed Jim Parson a long long time (for sure 
> > > more than a year) ago because of some trivial outstanding bugs in that 
> > > package (missing requires, incorrect pam configuration, ...), some of 
> > > them I fixed then, some are still left. I tried several times and didn't 
> > > get any response.
> > > 
> > I've actually found a few more since I wrote that list in the bz too.
> > 
> > > >
> > > > I would like to either fix (or preferably just remove) this package as
> > > > it creates configs for GFS2 which are incorrect and is thus causing
> > > > confusion to all who attempt to use it.
> > > 
> > > Hm...I would appreciate keeping the package (...and could fix the very 
> > > trivial of the remaining bugreports), how complicated would it be to fix 
> > > the GFS2 configs? On the other hand, I've heard from somebody of the RH 
> > > cluster team that the package is deprecated at all, how's that?
> >
> > Well if someone wants to maintain it, then I suppose there is no issue.
> > My understanding is that Conga is the preferred method for graphical
> > configuration of clusters. Personally I use vi for cluster
> > configuration :-)
> 
> I don't think its really viable to suggest that Conga is a replacement
> for system-config-cluster. One is a simple desktop UI for editing
> cluster config files. The other is a large web based management
> infrastructure. Certainly alot of people may want to use Conga, but
> I can well imagine people using s-c-c , wouldn't want to deploy a
> webapp just to get a tool to edit cluster config files
> 
> Daniel

I'm willing to accept that argument, and indeed just the same discussion
is currently going on, on one of our internal lists too. The issue is
who will do the work to get s-c-c back working again? Conga is actively
maintained, and s-c-c is not at the moment. Every time I've asked people
about it (and about fixing bugs) I've been told that its obsolete and
will not be fixed.

I figured it was better to remove it than to leave it broken and thus
confuse people. If by sending this request I've started a discussion
which ends with a new maintainer being selected and the bugs being
fixed, then thats just as good a result I think :-)

So I'll certainly not send any remove requests until the current
discussion has concluded, but in the mean time my request for the
transfer or maintainership still stands,

Steve.




From rdieter at math.unl.edu  Wed Oct 21 13:33:32 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 21 Oct 2009 08:33:32 -0500
Subject: Rationale behind _cmake_skip_rpath choice in
	/etc/rpm/macros.cmake
References: <4AD6203A.9060207@sophia.inria.fr> 
	<4ADDE590.5010703@sophia.inria.fr> 
	
Message-ID: 

Kevin Kofler wrote:

> Rex Dieter wrote:
>> I'm convinced to revert, I'll run the change by my fellow cmake
>> maintainers (I think we have buy-in from everyone though).
> 
> Please test that we really don't end up with standard paths like /usr/lib
> or /usr/lib64 in the rpath of installed executables when doing that! Last
> time we tried not using CMAKE_SKIP_RPATH, that's exactly what happened.

Yuck, First trial, rebuilding kdeplasma-addons without skip_rpath, yielded 
/usr/lib64 rpaths all over (as well as 1 instance of /usr/lib64/kde4/devel, 
as you alluded).

-- Rex



From mschmidt at redhat.com  Wed Oct 21 14:24:55 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Wed, 21 Oct 2009 16:24:55 +0200
Subject: Fedora 12 Beta
In-Reply-To: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
Message-ID: <4ADF19B7.3010703@redhat.com>

Dne 21.10.2009 12:31, Micha? Piotrowski napsal:
> I just installed F12 Beta. Here are some thoughts

Hello,
Thank you for testing the Beta.

> 1 - during the first boot smolt panicked - there was an error related
> to time zones in python-sitepackages or something like that.
> 2 - I tried to reboot the system - ctrl + alt + del, but it stopped on
> process termination
> 3 - after reboot system wanted my root password for partition check -
> after I pressed each key, the system gave me a communicate about wrong
> password
> I guess this is a plymouth bug. I disabled it in grub conf and system
> works correctly. Is there any chance to completely remove plymouth
> from the system? (even from initrd)
> 4 - F12 boots really slow on my laptop
> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
> wrong is happening while udev loading
> 5 - default gnome sound scheme is terrible

Have you file Bugzilla tickets for any of these issues? If not yet, 
please do so and provide more detailed information if possible.

Thanks,
Michal



From xjakub at fi.muni.cz  Wed Oct 21 14:46:04 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Wed, 21 Oct 2009 16:46:04 +0200
Subject: Unresponsive maintainer for system-config-cluster
In-Reply-To: <1256131282.2716.42.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>	<4ADF0152.3090509@fi.muni.cz>	<1256129834.2716.37.camel@localhost.localdomain>	<20091021131331.GF4829@redhat.com>
	<1256131282.2716.42.camel@localhost.localdomain>
Message-ID: <4ADF1EAC.5060308@fi.muni.cz>

On 10/21/2009 03:21 PM, Steven Whitehouse wrote:

> I'm willing to accept that argument, and indeed just the same discussion
> is currently going on, on one of our internal lists too. The issue is
> who will do the work to get s-c-c back working again? Conga is actively
> maintained, and s-c-c is not at the moment. Every time I've asked people
> about it (and about fixing bugs) I've been told that its obsolete and
> will not be fixed.

Well if they say that, then s-c-c should be really removed. I'd agree to 
comaintain it, but definitely don't have the capabilities (and time) to 
be the primary maintainer, that would need to be somebody from the RH 
cluster team or active in the cluster development (so that s-c-c would 
stay close to it).

Regards,
Milos



From fedora at matbooth.co.uk  Wed Oct 21 15:12:49 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 21 Oct 2009 15:12:49 +0000
Subject: new tool: rpmguard - print important differences between RPMs
In-Reply-To: <238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <54723383.938161256122543756.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <9497e9990910210812p60386bf3jfdd1e2de69db8e62@mail.gmail.com>

2009/10/21 Kamil Paral :
> Hi,
>
> I have created a simple tool called rpmguard for checking differences
> between RPM packages. It is very similar to rpmdiff, but it prints only
> important changes, not all. Therefore it can be used every time a new
> package is built to easily see if something hasn?t went completely wrong.
>

Was it not easier to just add a "less verbose" mode to rpmdiff?


-- 
Mat Booth

A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?



From tcallawa at redhat.com  Wed Oct 21 15:46:19 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 21 Oct 2009 11:46:19 -0400
Subject: Fix possibility of infinite loop in init scripts in time for
 Fedora	12?
In-Reply-To: 
References: 
Message-ID: <4ADF2CCB.3000304@redhat.com>

On 10/21/2009 12:54 AM, hidenori.ishii at avasys.jp wrote:
> A colleague of mine submitted a bug report regarding an infinite loop
> triggered when calling `lsb_start_daemon` with the `-p` option[1].  This
> bug has been around since at least Fedora 9 and is still present in the
> beta for Fedora 12.
> 
> Considering the fact that `lsb_start_daemon` is supposed to be called
> from init scripts, this may hang the boot process.  That's pretty bad.
> I know it's a bit late, but seeing that there is a patch, any chance of
> getting this in for Fedora 12?
> 
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=485367
> 
> Thanks in advance,

I'll take care of this.

~spot



From notting at redhat.com  Wed Oct 21 16:52:49 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 21 Oct 2009 12:52:49 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: 
References: <1255622587.2894.10.camel@localhost.localdomain>
	<1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
Message-ID: <20091021165248.GD792@nostromo.devel.redhat.com>

Eric Springer (erikina at gmail.com) said: 
> > It's probably abusing the system and breaks a million guidelines, but what
> about making a "no-offensive-packages" package that explicitly conflicts
> with a list of offensive packages?

I suspect the problem with that is attempting to determine a universal
concept of 'offensive'. Heck, we might have no-offensive-packages-kde
that conflicts with 'gnome-*', and no-offensive-packages-gnome...

Bill



From dpierce at redhat.com  Wed Oct 21 16:58:05 2009
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 21 Oct 2009 12:58:05 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021165248.GD792@nostromo.devel.redhat.com>
References: <1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
Message-ID: <20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>

On Wed, Oct 21, 2009 at 12:52:49PM -0400, Bill Nottingham wrote:
> I suspect the problem with that is attempting to determine a universal
> concept of 'offensive'. Heck, we might have no-offensive-packages-kde
> that conflicts with 'gnome-*', and no-offensive-packages-gnome...

And you can't uninstall KDE without killing gnome since
NetworkManager-gnome has a dependency on KDE...

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste n? B?arla cliste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From jkeating at redhat.com  Wed Oct 21 17:00:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Oct 2009 10:00:13 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
References: <1255652847.19029.29.camel@localhost.localdomain>
	<1255654244.2894.98.camel@localhost.localdomain>
	<1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
Message-ID: <1256144413.4242.49.camel@localhost.localdomain>

On Wed, 2009-10-21 at 12:58 -0400, Darryl L. Pierce wrote:
> 
> And you can't uninstall KDE without killing gnome since
> NetworkManager-gnome has a dependency on KDE... 

Um, what?  Care to elaborate? 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From dpierce at redhat.com  Wed Oct 21 17:08:43 2009
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 21 Oct 2009 13:08:43 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1256144413.4242.49.camel@localhost.localdomain>
References: <1255669121.11249.3.camel@mylaptop.myhome>
	
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
Message-ID: <20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>

On Wed, Oct 21, 2009 at 10:00:13AM -0700, Jesse Keating wrote:
> On Wed, 2009-10-21 at 12:58 -0400, Darryl L. Pierce wrote:
> > 
> > And you can't uninstall KDE without killing gnome since
> > NetworkManager-gnome has a dependency on KDE... 
> 
> Um, what?  Care to elaborate? 

http://www.pastebin.org/46726

If you try to uninstall the "KDE (K Desktop Environment)" group then
NetworkManager-gnome is marked for deletion as well.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste n? B?arla cliste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From berrange at redhat.com  Wed Oct 21 17:22:04 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 21 Oct 2009 18:22:04 +0100
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
References: 
	<1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
Message-ID: <20091021172204.GG4829@redhat.com>

On Wed, Oct 21, 2009 at 01:08:43PM -0400, Darryl L. Pierce wrote:
> On Wed, Oct 21, 2009 at 10:00:13AM -0700, Jesse Keating wrote:
> > On Wed, 2009-10-21 at 12:58 -0400, Darryl L. Pierce wrote:
> > > 
> > > And you can't uninstall KDE without killing gnome since
> > > NetworkManager-gnome has a dependency on KDE... 
> > 
> > Um, what?  Care to elaborate? 
> 
> http://www.pastebin.org/46726
> 
> If you try to uninstall the "KDE (K Desktop Environment)" group then
> NetworkManager-gnome is marked for deletion as well.

IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome
doesn't have a dependancy on KDE, rather it happens to be part of the 
"KDE (K Desktop Environment)"  group. ie in doing a 'groupremove'
you explicitly asked YUM to remove 'NetworkManager-gnome' since its
in that group. If you had just done an package level remove, eg 
'yum remove kde*' then NetworkManager-gnome would not have been removed

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From dpierce at redhat.com  Wed Oct 21 17:28:36 2009
From: dpierce at redhat.com (Darryl L. Pierce)
Date: Wed, 21 Oct 2009 13:28:36 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021172204.GG4829@redhat.com>
References: <1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
	<20091021172204.GG4829@redhat.com>
Message-ID: <20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>

On Wed, Oct 21, 2009 at 06:22:04PM +0100, Daniel P. Berrange wrote:
> IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome
> doesn't have a dependancy on KDE, rather it happens to be part of the 
> "KDE (K Desktop Environment)"  group. ie in doing a 'groupremove'
> you explicitly asked YUM to remove 'NetworkManager-gnome' since its
> in that group. If you had just done an package level remove, eg 
> 'yum remove kde*' then NetworkManager-gnome would not have been removed

You're correct in that removing the KDE group attempts to remove the
NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
NetworkManager-gnome which borked my laptop until I re-installed the
RPM. That's something that should be fixed.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste n? B?arla cliste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From notting at redhat.com  Wed Oct 21 17:37:01 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 21 Oct 2009 13:37:01 -0400
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
References: <22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
	<20091021172204.GG4829@redhat.com>
	<20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
Message-ID: <20091021173701.GC1815@nostromo.devel.redhat.com>

Darryl L. Pierce (dpierce at redhat.com) said: 
> You're correct in that removing the KDE group attempts to remove the
> NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
> NetworkManager-gnome which borked my laptop until I re-installed the
> RPM. That's something that should be fixed.

I believe the documented solution is 'groupremove is bad and does not
usually do what you want', FWIW.

Bill



From jkeating at redhat.com  Wed Oct 21 17:35:15 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Oct 2009 10:35:15 -0700
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
References: <1255911984.3180.5.camel@mylaptop.myhome>
	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
	<20091021172204.GG4829@redhat.com>
	<20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
Message-ID: <1256146515.4242.52.camel@localhost.localdomain>

On Wed, 2009-10-21 at 13:28 -0400, Darryl L. Pierce wrote:
> On Wed, Oct 21, 2009 at 06:22:04PM +0100, Daniel P. Berrange wrote:
> > IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome
> > doesn't have a dependancy on KDE, rather it happens to be part of the 
> > "KDE (K Desktop Environment)"  group. ie in doing a 'groupremove'
> > you explicitly asked YUM to remove 'NetworkManager-gnome' since its
> > in that group. If you had just done an package level remove, eg 
> > 'yum remove kde*' then NetworkManager-gnome would not have been removed
> 
> You're correct in that removing the KDE group attempts to remove the
> NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
> NetworkManager-gnome which borked my laptop until I re-installed the
> RPM. That's something that should be fixed.


Group removals are dangerous.  Groups can share packages between them.
Perhaps somebody should submit a patch to yum that gives groupremove a
flag that says don't remove any package that is listed in any other
group.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From dcbw at redhat.com  Wed Oct 21 17:47:28 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 21 Oct 2009 10:47:28 -0700
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <5256d0b0910210531o2c6d4d1fn3be8fdcff096bb7f@mail.gmail.com>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
	<5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
	<5256d0b0910210531o2c6d4d1fn3be8fdcff096bb7f@mail.gmail.com>
Message-ID: <1256147248.5010.18.camel@localhost.localdomain>

On Wed, 2009-10-21 at 13:31 +0100, Peter Robinson wrote:
> On Wed, Oct 21, 2009 at 1:28 PM, Peter Robinson  wrote:
> >>> As the Dell Latitude D630 is one of the more common devices that smolt
> >>> reports being used by Fedora I thought I'd mention my upgrade
> >>> experience and issues for F-12.
> >>>
> >>> Probably the two usual things that people query are grahics and wifi.
> >>> The model I have has the Intel IWL-4965AGN device which as expected
> >>> works fine.
> >>>
> >>> I'm having a few issues with the nouveau driver with plymouth in that
> >>> it doesn't work at all but if I remove all the options from the kernel
> >>> boot line it gets to X and apart from some initial corruption as GDM
> >>> comes up its OK from there. I have no idea how to debug this.
> >>
> >> Try adding the parameter 'nomodeset' instead of removing any parameters.
> >> What happens then?
> >
> > It has certainly improved it. I wasn't in front of the machine as it
> > booted this morning so I'll need to check out plymouth this evening
> > but the responsiveness of the display is improved and I don't get
> > duplicate mouse pointers now. The performance seems reduced compared
> > to F-11 though :-(
> >
> >>> Probably the most annoying is the breakage of sound. This seems to
> >>> have every other kernel/alsa/pulseaudio update and was an issue on and
> >>> off right through F-11 as well so its not exactly surprising but also
> >>> disappointing that one of the most common devices running Fedora has
> >>> sound broken on a semi regular basis. Again some pointers in debugging
> >>> this so it can be fixed by F-12 final would be great.
> >>
> >> https://fedoraproject.org/wiki/Bug_info_kernel_sound
> >>
> >>> The only other very minor issue I see is that the icon spacing on the
> >>> gnome panels is massive!
> >>
> >> This is currently being 'enthusiastically' discussed on
> >> fedora-desktop-list. :)
> >
> > Thanks for the pointer. I noticed its also been tweaked in todays rawhide.
> >
> > I've also noticed of late that yum performance has gone through the floor too.
> 
> I never finished that. Its currently necking one core of a 2.5 ghz
> penryn and using nearly a gig of RAM. It literally now takes hours to
> update my Fit-PC (500mhz geode with 256Mb RAM).

Geode GX2/500 has basically zero cache (either L1 or L2), and 256MB is
really the bare minimum for the install/upgrade process.  You'll be
swapping to disk a lot during the upgrade while the depsolving goes on,
and yeah, it'll take quite a while.

Dan




From chwang at redhat.com  Wed Oct 21 17:53:27 2009
From: chwang at redhat.com (Charley Wang)
Date: Wed, 21 Oct 2009 13:53:27 -0400 (EDT)
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1256146515.4242.52.camel@localhost.localdomain>
Message-ID: <897474206.38811256147607019.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>


----- "Jesse Keating"  wrote:

> On Wed, 2009-10-21 at 13:28 -0400, Darryl L. Pierce wrote:
> > On Wed, Oct 21, 2009 at 06:22:04PM +0100, Daniel P. Berrange wrote:
> > > IIUC, you're mis-interpreting the YUM output there.
> NetworkManager-gnome
> > > doesn't have a dependancy on KDE, rather it happens to be part of
> the 
> > > "KDE (K Desktop Environment)"  group. ie in doing a 'groupremove'
> > > you explicitly asked YUM to remove 'NetworkManager-gnome' since
> its
> > > in that group. If you had just done an package level remove, eg 
> > > 'yum remove kde*' then NetworkManager-gnome would not have been
> removed
> > 
> > You're correct in that removing the KDE group attempts to remove
> the
> > NetworkManager-gnome rpm. I remembered uninstalling KDE also
> removed
> > NetworkManager-gnome which borked my laptop until I re-installed
> the
> > RPM. That's something that should be fixed.
> 
> 
> Group removals are dangerous.  Groups can share packages between
> them.
> Perhaps somebody should submit a patch to yum that gives groupremove
> a
> flag that says don't remove any package that is listed in any other
> group.
> 

Maybe just a confirmation (i.e: 
"The following packages are also listed in other groups:
superpackage     -- awesomegroup, importantgroup
uselesspackage   -- evilgroup
Are you sure you want to remove them? (Y/N)"

?

-Charley


> 
> -- 
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From sundaram at fedoraproject.org  Wed Oct 21 17:52:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Oct 2009 23:22:26 +0530
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
References: <1255911984.3180.5.camel@mylaptop.myhome>	<22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>		<1256004576.4785.17.camel@mylaptop.myhome>		<20091021165248.GD792@nostromo.devel.redhat.com>	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>	<1256144413.4242.49.camel@localhost.localdomain>	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>	<20091021172204.GG4829@redhat.com>
	<20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
Message-ID: <4ADF4A5A.10805@fedoraproject.org>

On 10/21/2009 10:58 PM, Darryl L. Pierce wrote:
> On Wed, Oct 21, 2009 at 06:22:04PM +0100, Daniel P. Berrange wrote:
>> IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome
>> doesn't have a dependancy on KDE, rather it happens to be part of the 
>> "KDE (K Desktop Environment)"  group. ie in doing a 'groupremove'
>> you explicitly asked YUM to remove 'NetworkManager-gnome' since its
>> in that group. If you had just done an package level remove, eg 
>> 'yum remove kde*' then NetworkManager-gnome would not have been removed
> 
> You're correct in that removing the KDE group attempts to remove the
> NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
> NetworkManager-gnome which borked my laptop until I re-installed the
> RPM. That's something that should be fixed.

KDE SIG put that package in their own group since the KDE alternative
isn't working well yet. They can perhaps remove it from the group and
add it the ks file but you wouldn't get NetworkManager goodness in KDE
if you group install or use the DVD to select KDE.

Rahul



From skvidal at fedoraproject.org  Wed Oct 21 17:59:12 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 21 Oct 2009 13:59:12 -0400 (EDT)
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <20091021173701.GC1815@nostromo.devel.redhat.com>
References: <22a365930910181739g43279803ic3577c1bad7cf132@mail.gmail.com>
	
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
	<20091021172204.GG4829@redhat.com>
	<20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
	<20091021173701.GC1815@nostromo.devel.redhat.com>
Message-ID: 



On Wed, 21 Oct 2009, Bill Nottingham wrote:

> Darryl L. Pierce (dpierce at redhat.com) said:
>> You're correct in that removing the KDE group attempts to remove the
>> NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
>> NetworkManager-gnome which borked my laptop until I re-installed the
>> RPM. That's something that should be fixed.
>
> I believe the documented solution is 'groupremove is bad and does not
> usually do what you want', FWIW.
>

groupremove does exactly what it says it will do - if we need to revisit 
then it'd be nice if we did it in such a way that we don't break everyone 
else.

-sv



From a.badger at gmail.com  Wed Oct 21 18:10:22 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 21 Oct 2009 11:10:22 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256116297.2716.10.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
Message-ID: <20091021181022.GA7460@clingman.lan>

On Wed, Oct 21, 2009 at 10:11:37AM +0100, Steven Whitehouse wrote:
> Hi,
> 
> Jim Parsons left Red Hat a little while back and the only contact
> details I have is his Red Hat email address, which is of course no
> longer valid. I've opened a bugzilla #530027 as per the unresponsive
> maintainer procedure, but I was hoping to be able to skip the section
> regarding sending of messages since there seems little point sending to
> an email address which I know (and which other Red Hat employees can
> easily verify) will not be answered.
> 
> Instead I've emailed the one other person who had access to that package
> and that has also gone unanswered (see the bugzilla).
> 
> There are a number of outstanding bugs filed against
> system-config-cluster (including the fact that it seems that it has not
> passed an initial review) which I've listed out in the bugzilla.
> 
> I would like to either fix (or preferably just remove) this package as
> it creates configs for GFS2 which are incorrect and is thus causing
> confusion to all who attempt to use it.
> 
> Therefore this is my formal request to become maintainer of this
> package,
> 
I've talked to FESCo people on IRC and after some discussion I've gone ahead
and reassigned ownership.  Since people seem to like this, if you don't want
to maintain and fix this package, please go through the orphan process
rather than just retiring it.

I went ahead and made the change this time for two reasons:
1) The email address for the current maintainer is not valid.
2) We have in the past had an unwritten policy about reassigning packages
   between a former Red Hat maintainer and a new Red Hat maintainer when the
   maintainer leaves the company and is no longer interested in Fedora.

However, it was pointed out that this does tread in the area of the
fast-track for non-responsive maintainers decided on in this FESCo ticket:
  https://fedorahosted.org/fesco/ticket/251

(not yet written up in the wiki.  See
https://fedorahosted.org/fesco/ticket/261 for getting policies written up
quicker)

So let's discuss --

* Should we expedite these requests in the future if the email address for
  the maintainer is no longer in existence?
* Should we formalize the unwritten policy for Red Hat maintainers who leave
  the company and don't want to maintain their packages anymore?
  * Do we need sanity checks to be sure maintainers who do want to keep
    their packages do so?
  * Do we want something more generic that covers other compaines that pay
    their employees to package for Fedora?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From thomasj at fedoraproject.org  Wed Oct 21 18:34:00 2009
From: thomasj at fedoraproject.org (Thomas Janssen)
Date: Wed, 21 Oct 2009 20:34:00 +0200
Subject: Who do I send to get a package removed because of bad language.
In-Reply-To: <1256146515.4242.52.camel@localhost.localdomain>
References: <1255911984.3180.5.camel@mylaptop.myhome>
	<1256004576.4785.17.camel@mylaptop.myhome>
	
	<20091021165248.GD792@nostromo.devel.redhat.com>
	<20091021165805.GM3430@mcpierce-laptop.rdu.redhat.com>
	<1256144413.4242.49.camel@localhost.localdomain>
	<20091021170843.GN3430@mcpierce-laptop.rdu.redhat.com>
	<20091021172204.GG4829@redhat.com>
	<20091021172836.GO3430@mcpierce-laptop.rdu.redhat.com>
	<1256146515.4242.52.camel@localhost.localdomain>
Message-ID: 

2009/10/21 Jesse Keating :
> On Wed, 2009-10-21 at 13:28 -0400, Darryl L. Pierce wrote:
>> On Wed, Oct 21, 2009 at 06:22:04PM +0100, Daniel P. Berrange wrote:
>> > IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome
>> > doesn't have a dependancy on KDE, rather it happens to be part of the
>> > "KDE (K Desktop Environment)" ?group. ie in doing a 'groupremove'
>> > you explicitly asked YUM to remove 'NetworkManager-gnome' since its
>> > in that group. If you had just done an package level remove, eg
>> > 'yum remove kde*' then NetworkManager-gnome would not have been removed
>>
>> You're correct in that removing the KDE group attempts to remove the
>> NetworkManager-gnome rpm. I remembered uninstalling KDE also removed
>> NetworkManager-gnome which borked my laptop until I re-installed the
>> RPM. That's something that should be fixed.
>
>
> Group removals are dangerous. ?Groups can share packages between them.
> Perhaps somebody should submit a patch to yum that gives groupremove a
> flag that says don't remove any package that is listed in any other
> group.

That is the perfect idea/solution. Sadly i can't volunteer.

-- 
LG Thomas

Dubium sapientiae initium



From lyos.gemininorezel at gmail.com  Wed Oct 21 18:45:28 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Wed, 21 Oct 2009 14:45:28 -0400
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091021181022.GA7460@clingman.lan>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
Message-ID: <4ADF56C8.3060602@gmail.com>

On 10/21/2009 02:10 PM, Toshio Kuratomi wrote:
> I've talked to FESCo people on IRC and after some discussion I've gone 
> ahead
> and reassigned ownership.  Since people seem to like this, if you don't want
> to maintain and fix this package, please go through the orphan process
> rather than just retiring it.
>
> I went ahead and made the change this time for two reasons:
> 1) The email address for the current maintainer is not valid.
> 2) We have in the past had an unwritten policy about reassigning packages
>     between a former Red Hat maintainer and a new Red Hat maintainer when the
>     maintainer leaves the company and is no longer interested in Fedora.
>
> However, it was pointed out that this does tread in the area of the
> fast-track for non-responsive maintainers decided on in this FESCo ticket:
>    https://fedorahosted.org/fesco/ticket/251
>
> (not yet written up in the wiki.  See
> https://fedorahosted.org/fesco/ticket/261 for getting policies written up
> quicker)
>
> So let's discuss --
>
> * Should we expedite these requests in the future if the email address for
>    the maintainer is no longer in existence?
> * Should we formalize the unwritten policy for Red Hat maintainers who leave
>    the company and don't want to maintain their packages anymore?
>    * Do we need sanity checks to be sure maintainers who do want to keep
>      their packages do so?
>    * Do we want something more generic that covers other compaines that pay
>      their employees to package for Fedora?
>
> -Toshio
>    

Why not just require a secondary email address?

This would solve most of the problems... no?

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From pbrobinson at gmail.com  Wed Oct 21 19:20:40 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 21 Oct 2009 20:20:40 +0100
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <1256147248.5010.18.camel@localhost.localdomain>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
	<5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
	<5256d0b0910210531o2c6d4d1fn3be8fdcff096bb7f@mail.gmail.com>
	<1256147248.5010.18.camel@localhost.localdomain>
Message-ID: <5256d0b0910211220u86731abk41f179a14bdfa417@mail.gmail.com>

On Wed, Oct 21, 2009 at 6:47 PM, Dan Williams  wrote:
> On Wed, 2009-10-21 at 13:31 +0100, Peter Robinson wrote:
>> On Wed, Oct 21, 2009 at 1:28 PM, Peter Robinson  wrote:
>> >>> As the Dell Latitude D630 is one of the more common devices that smolt
>> >>> reports being used by Fedora I thought I'd mention my upgrade
>> >>> experience and issues for F-12.
>> >>>
>> >>> Probably the two usual things that people query are grahics and wifi.
>> >>> The model I have has the Intel IWL-4965AGN device which as expected
>> >>> works fine.
>> >>>
>> >>> I'm having a few issues with the nouveau driver with plymouth in that
>> >>> it doesn't work at all but if I remove all the options from the kernel
>> >>> boot line it gets to X and apart from some initial corruption as GDM
>> >>> comes up its OK from there. I have no idea how to debug this.
>> >>
>> >> Try adding the parameter 'nomodeset' instead of removing any parameters.
>> >> What happens then?
>> >
>> > It has certainly improved it. I wasn't in front of the machine as it
>> > booted this morning so I'll need to check out plymouth this evening
>> > but the responsiveness of the display is improved and I don't get
>> > duplicate mouse pointers now. The performance seems reduced compared
>> > to F-11 though :-(
>> >
>> >>> Probably the most annoying is the breakage of sound. This seems to
>> >>> have every other kernel/alsa/pulseaudio update and was an issue on and
>> >>> off right through F-11 as well so its not exactly surprising but also
>> >>> disappointing that one of the most common devices running Fedora has
>> >>> sound broken on a semi regular basis. Again some pointers in debugging
>> >>> this so it can be fixed by F-12 final would be great.
>> >>
>> >> https://fedoraproject.org/wiki/Bug_info_kernel_sound
>> >>
>> >>> The only other very minor issue I see is that the icon spacing on the
>> >>> gnome panels is massive!
>> >>
>> >> This is currently being 'enthusiastically' discussed on
>> >> fedora-desktop-list. :)
>> >
>> > Thanks for the pointer. I noticed its also been tweaked in todays rawhide.
>> >
>> > I've also noticed of late that yum performance has gone through the floor too.
>>
>> I never finished that. Its currently necking one core of a 2.5 ghz
>> penryn and using nearly a gig of RAM. It literally now takes hours to
>> update my Fit-PC (500mhz geode with 256Mb RAM).
>
> Geode GX2/500 has basically zero cache (either L1 or L2), and 256MB is
> really the bare minimum for the install/upgrade process. ?You'll be
> swapping to disk a lot during the upgrade while the depsolving goes on,
> and yeah, it'll take quite a while.

Yea, but my Dell with a Centrino penryn processor with 6 meg of cache
and 4 gig of RAM was horrific and earlier in F-12 it wasn't that bad
even on the Geode. I couldn't use my Dell for over 20 mins while doing
a single days worth of the current rawhide pushes.

Peter



From pbrobinson at gmail.com  Wed Oct 21 19:58:00 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 21 Oct 2009 20:58:00 +0100
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <1256062926.2314.270.camel@adam.local.net>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
Message-ID: <5256d0b0910211258uf03478bw5c732af43cac1ca1@mail.gmail.com>

On Tue, Oct 20, 2009 at 7:22 PM, Adam Williamson  wrote:
> On Tue, 2009-10-20 at 11:17 +0100, Peter Robinson wrote:
>> Hi All,
>>
>> As the Dell Latitude D630 is one of the more common devices that smolt
>> reports being used by Fedora I thought I'd mention my upgrade
>> experience and issues for F-12.
>>
>> Probably the two usual things that people query are grahics and wifi.
>> The model I have has the Intel IWL-4965AGN device which as expected
>> works fine.
>>
>> I'm having a few issues with the nouveau driver with plymouth in that
>> it doesn't work at all but if I remove all the options from the kernel
>> boot line it gets to X and apart from some initial corruption as GDM
>> comes up its OK from there. I have no idea how to debug this.
>
> Try adding the parameter 'nomodeset' instead of removing any parameters.
> What happens then?

It all works just fine with modesetting off.

Peter



From wtogami at redhat.com  Wed Oct 21 20:18:30 2009
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Oct 2009 16:18:30 -0400
Subject: Notice: Fedora 12 Tagging Status Update
Message-ID: <4ADF6C96.3000006@redhat.com>

Fedora Release Engineering decided to deal with the 250+ backlog of 
Bodhi update requests by tagging them all into f12-final.  Bodhi is now 
disabled for Fedora 12 updates.

Questions
=========
1) Why tag all Update requests into f12-final?

At this point of the schedule we realized that there were updates 
sitting in the queue from since October.  They were sitting there.  Not 
getting pushed to any repository.  Rawhide gives these packages several 
more weeks of testing exposure.  This was decided to be better than a 
flood of day zero updates that are poorly tested.

2) When will we be able to submit Updates again?

Rel-eng will decide when to begin accepting Updates for Fedora 12 again 
during Monday's rel-eng meeting.  Meanwhile please use the rel-eng 
ticketing system to request tagging into f12-final.

3) How do I file a tag request to include my package into Fedora 12?

https://fedorahosted.org/rel-eng/
Please file tag request tickets here if you want your package build to 
be included in Fedora 12.  Please include details like:
* Full Name-Version-Release of your package(s)
* What changed?
* How risky is this change?
* How important is this change?
* How well tested is this package build?
* Is this package in the critical-path list?

4) Which packages are critical-path?

https://fedorahosted.org/pipermail/autoqa-results/2009-October/001714.html
Unfortunately we do not yet have a permanent URL with the critical-path 
list.  This page contains an auto-generated list of critical-path 
packages as of today.

If your package is not critical-path and not a risk to others to update, 
then it is highly likely proper to tag at this point of the schedule.

5) How many untagged packages are there?

koji list-tagged --latest dist-f12-updates-candidate

This command lists all packages that are not tagged for f12-final.  In 
some cases these are false positives because a newer package is instead 
tagged into f12-final.  After you have tested your package and verified 
it doesn't make things worse, please file rel-eng tickets to have it 
included.

Please direct questions to fedora-devel-list.

Warren Togami
wtogami at redhat.com

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From ajax at redhat.com  Wed Oct 21 20:28:20 2009
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 21 Oct 2009 16:28:20 -0400
Subject: On updates to stable releases
Message-ID: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>

I don't really want to revive the thread about automake 1.11, but I do
want to point out that it did break actual buildability:

http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log

Please, people.  Don't update things in stable releases just for fun.
Particularly if your package is part of the build environment for
something else.  I don't care if it bills itself as "just a bugfix
release"; that's how you know it's lying.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From skvidal at fedoraproject.org  Wed Oct 21 20:30:50 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 21 Oct 2009 16:30:50 -0400 (EDT)
Subject: On updates to stable releases
In-Reply-To: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
Message-ID: 



On Wed, 21 Oct 2009, Adam Jackson wrote:

> I don't really want to revive the thread about automake 1.11, but I do
> want to point out that it did break actual buildability:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log
>
> Please, people.  Don't update things in stable releases just for fun.
> Particularly if your package is part of the build environment for
> something else.  I don't care if it bills itself as "just a bugfix
> release"; that's how you know it's lying.
>

Except when it is just a bugfix release and it maintains api compat.

Yum has been, on the whole, pretty good about maintaining compatibility 
while fixing bugs.

-sv



From ajax at redhat.com  Wed Oct 21 20:39:18 2009
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 21 Oct 2009 16:39:18 -0400
Subject: On updates to stable releases
In-Reply-To: 
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
	
Message-ID: <1256157558.15835.6811.camel@atropine.boston.devel.redhat.com>

On Wed, 2009-10-21 at 16:30 -0400, Seth Vidal wrote:
> On Wed, 21 Oct 2009, Adam Jackson wrote:
> > I don't really want to revive the thread about automake 1.11, but I do
> > want to point out that it did break actual buildability:
> >
> > http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log
> >
> > Please, people.  Don't update things in stable releases just for fun.
> > Particularly if your package is part of the build environment for
> > something else.  I don't care if it bills itself as "just a bugfix
> > release"; that's how you know it's lying.
> 
> Except when it is just a bugfix release and it maintains api compat.
> 
> Yum has been, on the whole, pretty good about maintaining compatibility 
> while fixing bugs.

I was being hyperbolic, yes.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mmcgrath at redhat.com  Wed Oct 21 20:42:55 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 21 Oct 2009 15:42:55 -0500 (CDT)
Subject: On updates to stable releases
In-Reply-To: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
Message-ID: 

On Wed, 21 Oct 2009, Adam Jackson wrote:

> I don't really want to revive the thread about automake 1.11, but I do
> want to point out that it did break actual buildability:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log
>
> Please, people.  Don't update things in stable releases just for fun.
> Particularly if your package is part of the build environment for
> something else.  I don't care if it bills itself as "just a bugfix
> release"; that's how you know it's lying.
>

It's getting to the point where we need something more than "please".

	-Mike



From skvidal at fedoraproject.org  Wed Oct 21 20:43:18 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Wed, 21 Oct 2009 16:43:18 -0400 (EDT)
Subject: On updates to stable releases
In-Reply-To: <1256157558.15835.6811.camel@atropine.boston.devel.redhat.com>
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
	
	<1256157558.15835.6811.camel@atropine.boston.devel.redhat.com>
Message-ID: 



On Wed, 21 Oct 2009, Adam Jackson wrote:

> On Wed, 2009-10-21 at 16:30 -0400, Seth Vidal wrote:
>> On Wed, 21 Oct 2009, Adam Jackson wrote:
>>> I don't really want to revive the thread about automake 1.11, but I do
>>> want to point out that it did break actual buildability:
>>>
>>> http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log
>>>
>>> Please, people.  Don't update things in stable releases just for fun.
>>> Particularly if your package is part of the build environment for
>>> something else.  I don't care if it bills itself as "just a bugfix
>>> release"; that's how you know it's lying.
>>
>> Except when it is just a bugfix release and it maintains api compat.
>>
>> Yum has been, on the whole, pretty good about maintaining compatibility
>> while fixing bugs.
>
> I was being hyperbolic, yes.
>

Something I've discovered in the not-so-distant past is that hyperbole is 
not always grokked by non-native speakers and tends to cause drama 
escalation.

Your main point, though - that people in the build  and critpath should be 
careful with upgrades is completely correct.

-sv



From lsof at nodata.co.uk  Wed Oct 21 20:50:42 2009
From: lsof at nodata.co.uk (nodata)
Date: Wed, 21 Oct 2009 22:50:42 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091021084702.43dcba99@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>	<80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>
	<20091021084702.43dcba99@dhcp03.addix.net>
Message-ID: <4ADF7422.8040901@nodata.co.uk>

Am 2009-10-21 08:47, schrieb Ralf Ertzinger:
> Hi.
>
> On Tue, 20 Oct 2009 17:40:46 -0600, Stephen John Smoogen wrote:
>
>> In most cases, you can get that information from the original RPM
>> compared to the system... if you have the RPM :).
>>
>> rpm -Vp
>
> Which is pretty much what I want, just pulling the data from an external
> (signed) source instead of the local RPM database.
>

Running on the compromised system, or running somewhere else?
Where are you running rpm from?



From awilliam at redhat.com  Wed Oct 21 21:27:31 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 14:27:31 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
	
Message-ID: <1256160451.2314.421.camel@adam.local.net>

On Wed, 2009-10-21 at 15:16 +0800, Liang Suilong wrote:
> Today I upgrade my Fedora to Fedora 12 Beta, It looks very well. But I
> found ATi display driver does not run well. 
> 
> 
> My display card is Sapphire HD3650 with 256MB GDDR3 VRAM (RV635). I
> choose OSS driver for my card. Glxgears runs so smoothly with
> xorg-x11-drv-ati because of KMS by default, nevertheless, rolling up
> and down in the gnome-terminal is quite slow. The performance of
> glxgears is about 210 frams per second. In addition, Switching to
> another window in Fedora 12 Beta is not as fast in Fedora 11. Later, I
> install xorg-x11-drv-radeonhd and set it by default in the
> system-config-display. Then I restart the X. I can not log into gnome.
> The screen turns white. I found xorg-x11-drv-radeonhd is too old, The
> version is 1.2.5 in the rawhide and the latest version 1.3.0 has been
> released for a long time. Now I turn back to xorg-x11-drv-ati. At
> last, I do not know which packages causes the  problem, maybe
> xorg-x11-drv-ati, maybe xorg-x11-drv-radeonhd, maybe Mesa. So I
> suggest that packager updates some packge related to ATi R600/R700
> display card. 

Fedora doesn't really care about the radeonhd driver. We may well even
remove it at some point soon. The ati driver is the one you should use
on Fedora, that's why it's the default.

You do not get 3D acceleration out of the box on that card, r600 3D
acceleration is too early to be enabled by default. If you want to try
it out, install the mesa-dri-drivers-experimental package.

For the slow 2D performance - _how_ slow is it, really? gnome-terminal
has never been much of a speed demon. Does it get any faster if you boot
with 'nomodeset' as a kernel parameter?


-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Wed Oct 21 21:35:00 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 14:35:00 -0700
Subject: Fedora 12 Beta
In-Reply-To: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
Message-ID: <1256160900.2314.427.camel@adam.local.net>

On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
> Hi,
> 
> I just installed F12 Beta. Here are some thoughts
> 
> 1 - during the first boot smolt panicked - there was an error related
> to time zones in python-sitepackages or something like that.

Could you try to reproduce and provide more precise details on the
error? There's not a lot we can do with that level of detail.

> 2 - I tried to reboot the system - ctrl + alt + del, but it stopped on
> process termination

It _may_ not actually have stopped, rebooting from firstboot can be
quite sluggish I've noticed, but goes through eventually.

> 3 - after reboot system wanted my root password for partition check -
> after I pressed each key, the system gave me a communicate about wrong
> password

The fact that it wanted to do fsck at all may be
https://bugzilla.redhat.com/show_bug.cgi?id=522969 , which is fixed in
tomorrow's Rawhide.

> I guess this is a plymouth bug. I disabled it in grub conf and system
> works correctly. Is there any chance to completely remove plymouth
> from the system? (even from initrd)

>From a quick look, we don't have a bug filed for the fact that entering
the root password at this point doesn't work with Plymouth. Could you
please file one with a full description, and mark it as blocking
F12Blocker? Thanks.

> 4 - F12 boots really slow on my laptop
> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
> wrong is happening while udev loading

Please file a bug for this, on 'udev' component for now, and CC Harald
Hoyer (hhoyer at redhat). Thanks!

> 5 - default gnome sound scheme is terrible

This is a pretty subjective topic.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From opensource at till.name  Wed Oct 21 21:36:36 2009
From: opensource at till.name (Till Maas)
Date: Wed, 21 Oct 2009 23:36:36 +0200
Subject: Status of touchpad support in F12 for kdm?
In-Reply-To: 
References: 
	 
Message-ID: <200910212336.42183.opensource@till.name>

On Mon October 19 2009, mcloaked wrote:

> Given the recent long thread concerning upstream decisions about defaults
>  in Thunderbird 3.0beta4 it seems to me that just because upstream makes a
>  specific decision does not always mean that is the best decision. What

That discussion was not about the default in general, but about changing the 
default in an update for a stable Fedora release. I guess the default for 
Rawhide/F12 will be the same that upstream has.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

From awilliam at redhat.com  Wed Oct 21 21:42:13 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 14:42:13 -0700
Subject: F-12 upgrade experience with Dell D630
In-Reply-To: <5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
References: <5256d0b0910200317g2c783322qb0722f1e3bcfa28c@mail.gmail.com>
	<1256062926.2314.270.camel@adam.local.net>
	<5256d0b0910210528gd87916bv4fde933233b397d4@mail.gmail.com>
Message-ID: <1256161333.2314.433.camel@adam.local.net>

On Wed, 2009-10-21 at 13:28 +0100, Peter Robinson wrote:

> > Try adding the parameter 'nomodeset' instead of removing any parameters.
> > What happens then?
> 
> It has certainly improved it. I wasn't in front of the machine as it
> booted this morning so I'll need to check out plymouth this evening
> but the responsiveness of the display is improved and I don't get
> duplicate mouse pointers now. The performance seems reduced compared
> to F-11 though :-(

In that case, could you file a bug, with appropriate information
attached - see https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
- on the xorg-x11-drv-nouveau component, describing the symptoms, how
'nomodeset' changes them, and including the output of 'lspci -nn' to
identify your card? Thanks!

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Wed Oct 21 21:44:14 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 14:44:14 -0700
Subject: new tool: rpmguard - print important differences between RPMs
In-Reply-To: <9497e9990910210812p60386bf3jfdd1e2de69db8e62@mail.gmail.com>
References: <54723383.938161256122543756.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<238111468.938181256122586110.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<9497e9990910210812p60386bf3jfdd1e2de69db8e62@mail.gmail.com>
Message-ID: <1256161454.2314.434.camel@adam.local.net>

On Wed, 2009-10-21 at 15:12 +0000, Mat Booth wrote:
> 2009/10/21 Kamil Paral :
> > Hi,
> >
> > I have created a simple tool called rpmguard for checking differences
> > between RPM packages. It is very similar to rpmdiff, but it prints only
> > important changes, not all. Therefore it can be used every time a new
> > package is built to easily see if something hasn?t went completely wrong.

> Was it not easier to just add a "less verbose" mode to rpmdiff?

As we discussed in the QA meeting this week, that may well be ultimately
what this becomes, but for now it's a separate tool while Kamil works on
it. He may well end up submitting it as a patch for rpmdiff in the end.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From email.ahmedkamal at googlemail.com  Wed Oct 21 21:55:35 2009
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Wed, 21 Oct 2009 23:55:35 +0200
Subject: F12 media-less installer totally broken
Message-ID: <3da3b5b40910211455y721b1e77h9bfa9682e1a507d5@mail.gmail.com>

Hi folks,
I tried installing F12 fresh today without burning media. I had F11 on a
lvm, and was installing F12 on another. Here's what happened:
- Put the iso on a ntfs partition
- Put the vmlinuz+initrd.img in F11's grub .. and boot into the installer,
pointing it to install from HDD
- The installer cannot pickup the iso
- As an alternate I copied the iso to a server, and NFS shared its folder
- I reboot the installer, point it to nfs .. again it fails to start
anaconda
- Third trial .. on that server I loop mount the iso on /opt and NFS share
that
- Boot installer, it tried to mount server:/opt/images (which fails!) (only
/opt is shared)
- Fourth trial: I expand the iso image completely on disk into a new
directory, boot into the installer pointing it at that
- Installer finally picks up, anaconda starts .. I click next a few times,
partition and format my disk, then an error message mentions "cannot load
image #1, please insert the CD and try again" ... arrgh
- I give up, burn a DVD, and install from it just fine

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From poelstra at redhat.com  Wed Oct 21 22:00:04 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 21 Oct 2009 15:00:04 -0700
Subject: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11 AM
 EDT)
Message-ID: <4ADF8464.2070200@redhat.com>

When: Friday, 2009-10-23 @ 15:00 UTC (11 AM EDT)
Where: #fedora-bugzappers on irc.freenode.net

We will be doing a follow-up to the meeting that was held today.  Below 
is the list bugs still blocking the release of Fedora 12.

527048 - nss - NEW  - nss-sysinit: system-wide nss sql empty key 
database shouldn't have a password
528005 - xorg-x11-drv-nouveau - NEW  - X server crash
528222 - initscripts - NEW  - LiveCD intermittently gets stuck during 
shutdown
509733 - gvfs - NEW  - Process /usr/libexec/gvfs-gdu-volume-monitor 
received signal 11
528909 - DeviceKit-disks - NEW  - DevKit 95-devkit-disks.rules should 
avoid scan all DM devices
517839 - hsqldb - NEW  - bitxor and bitor both mapped to single bitor 
function
523110 - hsqldb - NEW  - autoincrement bustage on column redefinition
513864 - firefox - NEW  - Firefox crashes
501769 - kernel - NEW  - intel hda: snd_pcm_avail/snd_pcm_delay overflows
523378 - kernel - NEW  - [kernel] file system errors for recent 2.6.31 
kernels
530169 - kernel - NEW  - nouveau + gdm crashes
493472 - kernel - NEW  - [945GM] KMS: LVDS wrongly detected as 
connected, DVI monitor resolution incorrectly set
514760 - redhat-lsb - NEW  - cleanup script segfaults during yum upgrade
498968 - distribution - NEW  - Fedora 12 Virtualization Target Blocker
521519 - gedit - NEW  - gedit 2.27 leaking memory
527089 - plymouth - NEW  - repaire console is not accessible
520480 - kde-settings - NEW  - F12 KDE blocker
523815 - nautilus - NEW  - nautilus hoses vino
514415 - xorg-x11-server - NEW  - X server locks up every time 
notification is about to be displayed
518962 - xorg-x11-drv-ati - NEW  - ATI - Caught signal 11 (Segmentation 
fault). Server aborting
522929 - xorg-x11-drv-ati - NEW  - repeated system crashes
521512 - kernel - ASSIGNED  - KMS: X Window Frozen with Radeon XPRESS 200M
526154 - thunderbird - ASSIGNED  - localisation breaks sending mail
512845 - xulrunner - ASSIGNED  - setroubleshoot:      SELinux is 
preventing firefox from changing a writable memory segment executable.
526699 - anaconda - ASSIGNED  - CryptoError: luks_format failed for 
'/dev/mapper/VolGroup-LogVol00'
517491 - anaconda - ASSIGNED  - Anaconda fails if filesystem should be 
shrunk
528312 - xorg-x11-server - ASSIGNED  - udev takes almost 100% CPU on 
resume from suspend (and Xorg are to be blamed)
522187 - pango - ASSIGNED  - Java (so Eclipse too) crashes
521322 - xorg-x11-drv-ati - ASSIGNED  - no graphics and no console for 
F12-Snap1-x86_64-Live
522137 - xorg-x11-drv-ati - ASSIGNED  - Test_Day:2009-09-09_Radeon: 
Multiple tests crash X.org
522970 - xorg-x11-drv-ati - ASSIGNED  - popup messages unreadable
493058 - anaconda - ASSIGNED  - Custom partitioning creation/edit causes 
traceback
526549 - anaconda - ASSIGNED  - rats_install kickstart fails due to swap 
device prompt
526021 - yaboot - ASSIGNED  - f12 beta failed to boot on ppc platform 
after  autopart and encrypted installation
506075 - kernel - ASSIGNED  - snd_intel8x0: snd_pcm_avail()/ 
snd_pcm_delay() overflow
514000 - alsa-lib - ASSIGNED  - Aureon 5.1 MkII can't do 5.1 anymore
523768 - alsa-utils - ASSIGNED  - [abrt] crash detected in 
alsa-utils-1.0.21-2.fc12
514600 - kernel - ASSIGNED  - Intel 82G965 requires 'nomodeset' 
workaround to get working text-mode
528537 - kernel - ASSIGNED  - fails to get kickstart file over nfs.
528048 - xorg-x11-drv-intel - ASSIGNED  - display black after resume
516057 - webkitgtk - ASSIGNED  - gets whacked by selinux execmem check
527426 - plymouth - ASSIGNED  - (plymouth) No text prompt for encryption 
password (but keyboard input is accepted)
520750 - PackageKit - ASSIGNED  - Software Update windows checks for 
update does not stop ..
512944 - fast-user-switch-applet - ASSIGNED  - fast-user-switching locks 
up login screen
527920 - gdm - ASSIGNED  - gdm doesn't show user list and crashes - 
unable to login
523800 - xorg-x11-drv-neomagic - ASSIGNED  - X.org doesn't work on 
ThinkPad 600X (NeoMagic MagicGraph256ZX)
527520 - anaconda - MODIFIED  - post-install lxde system boots in text mode
526697 - anaconda - MODIFIED  - Trying to change encryption status of 
partition ends with error message: The mount point "" is in use. Please 
pick another
527952 - anaconda - MODIFIED  - AttributeError: 'NoneType' object has no 
attribute 'disk'
528317 - anaconda - MODIFIED  - anaconda traceback in getDefaultTimeZone 
KeyError en_AU
529766 - NetworkManager - MODIFIED  - applet won't start
517260 - anaconda - MODIFIED  - liveinst fails at partitioning screen
519766 - nss - MODIFIED  - (nss) FORTIFY_SOURCE buffer overflows and 
other issues in test suite
520162 - nss - MODIFIED  - nss-devel no longer provides pkgconfig(nss)
524168 - anaconda - MODIFIED  - Wrong RAID10 recognition in anaconda 
while dmraid shows correct values
529209 - livecd-tools - MODIFIED  - PATCH: Tell dracut not to ask for 
LUKS passwords or activate mdraid sets
528097 - dmraid - MODIFIED  - /sbin/dmraid needs possibly unmounted /usr/lib
528497 - firstaidkit - MODIFIED  - FirstAidKit does not start when using 
F-12-Beta rescue mode from disc1.iso
529794 - setuptool - MODIFIED  - cannot modify firewall using 'setup'
506013 - anaconda - MODIFIED  - liveinst crash - DBusException ... No 
such property HwAddress
515441 - anaconda - MODIFIED  - Can't select local CD/DVD after provide 
a wrong NFS location during install of F12 alpha
527258 - anaconda - MODIFIED  - When using NFS installation source - 
Cannot retrieve repository metadata for respository: UIedited_0.
518623 - unixODBC - ON_QA  - busted sizes for SQLBIGINT and ODBCINT64 etc

Thanks for your help and time,
John



From awilliam at redhat.com  Wed Oct 21 22:05:07 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 15:05:07 -0700
Subject: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11
 AM EDT)
In-Reply-To: <4ADF8464.2070200@redhat.com>
References: <4ADF8464.2070200@redhat.com>
Message-ID: <1256162707.2314.435.camel@adam.local.net>

On Wed, 2009-10-21 at 15:00 -0700, John Poelstra wrote:
> When: Friday, 2009-10-23 @ 15:00 UTC (11 AM EDT)
> Where: #fedora-bugzappers on irc.freenode.net
> 
> We will be doing a follow-up to the meeting that was held today.  Below 
> is the list bugs still blocking the release of Fedora 12.

Bring snacks, this will be a long one :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From tgl at redhat.com  Wed Oct 21 22:07:09 2009
From: tgl at redhat.com (Tom Lane)
Date: Wed, 21 Oct 2009 18:07:09 -0400
Subject: Simplify non-responsive maintainers policy Part 2 
In-Reply-To: <4ADF56C8.3060602@gmail.com> 
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan> <4ADF56C8.3060602@gmail.com>
Message-ID: <19965.1256162829@sss.pgh.pa.us>

Lyos Gemini Norezel  writes:
> Why not just require a secondary email address?

"Require" a secondary email address?  Not everyone has one, or wants
to hand it over if they do.  That sounds more like a recipe for driving
maintainers away than making sure you can contact them.

			regards, tom lane



From mmcgrath at redhat.com  Wed Oct 21 22:08:27 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 21 Oct 2009 17:08:27 -0500 (CDT)
Subject: Fedora 12 Beta
In-Reply-To: <1256160900.2314.427.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
Message-ID: 

On Wed, 21 Oct 2009, Adam Williamson wrote:

> On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
> > Hi,
> >
> > I just installed F12 Beta. Here are some thoughts
> >
> > 1 - during the first boot smolt panicked - there was an error related
> > to time zones in python-sitepackages or something like that.
>
> Could you try to reproduce and provide more precise details on the
> error? There's not a lot we can do with that level of detail.
>

The smolt firstboot thing is already fixed, just didn't make it in time
for the beta, my bad.

	-Mike

From awilliam at redhat.com  Wed Oct 21 22:15:11 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 15:15:11 -0700
Subject: Fedora 12 Beta
In-Reply-To: 
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
	
Message-ID: <1256163311.2314.439.camel@adam.local.net>

On Wed, 2009-10-21 at 17:08 -0500, Mike McGrath wrote:
> On Wed, 21 Oct 2009, Adam Williamson wrote:
> 
> > On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
> > > Hi,
> > >
> > > I just installed F12 Beta. Here are some thoughts
> > >
> > > 1 - during the first boot smolt panicked - there was an error related
> > > to time zones in python-sitepackages or something like that.
> >
> > Could you try to reproduce and provide more precise details on the
> > error? There's not a lot we can do with that level of detail.
> >
> 
> The smolt firstboot thing is already fixed, just didn't make it in time
> for the beta, my bad.

Is there a bug report I can reference so I can add this to the Common
Bugs page with a reasonable level of detail?

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mkkp4x4 at gmail.com  Wed Oct 21 22:29:01 2009
From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=)
Date: Thu, 22 Oct 2009 00:29:01 +0200
Subject: Fedora 12 Beta
In-Reply-To: <1256163311.2314.439.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
	
	<1256163311.2314.439.camel@adam.local.net>
Message-ID: <596b53e0910211529g3cf7e0d3v210cb770712e61ee@mail.gmail.com>

2009/10/22 Adam Williamson :
> On Wed, 2009-10-21 at 17:08 -0500, Mike McGrath wrote:
>> On Wed, 21 Oct 2009, Adam Williamson wrote:
>>
>> > On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
>> > > Hi,
>> > >
>> > > I just installed F12 Beta. Here are some thoughts
>> > >
>> > > 1 - during the first boot smolt panicked - there was an error related
>> > > to time zones in python-sitepackages or something like that.
>> >
>> > Could you try to reproduce and provide more precise details on the
>> > error? There's not a lot we can do with that level of detail.
>> >
>>
>> The smolt firstboot thing is already fixed, just didn't make it in time
>> for the beta, my bad.
>
> Is there a bug report I can reference so I can add this to the Common
> Bugs page with a reasonable level of detail?
>

I made two photos
http://www.stardust.webpages.pl/files/tmp/Zdj%eacie0029.jpg
http://www.stardust.webpages.pl/files/tmp/Zdj%eacie0030.jpg

Just to be sure Mike, do you think about this problem?



From mkkp4x4 at gmail.com  Wed Oct 21 22:49:05 2009
From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=)
Date: Thu, 22 Oct 2009 00:49:05 +0200
Subject: Fedora 12 Beta
In-Reply-To: <1256160900.2314.427.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
Message-ID: <596b53e0910211549t1c31d532w32bfed895b8b5d08@mail.gmail.com>

2009/10/21 Adam Williamson :
> On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
>> I guess this is a plymouth bug. I disabled it in grub conf and system
>> works correctly. Is there any chance to completely remove plymouth
>> from the system? (even from initrd)
>
> >From a quick look, we don't have a bug filed for the fact that entering
> the root password at this point doesn't work with Plymouth. Could you
> please file one with a full description, and mark it as blocking
> F12Blocker? Thanks.

Here is a bug report
https://bugzilla.redhat.com/show_bug.cgi?id=530224

I don't know how to mark it as a blocker.

>
>> 4 - F12 boots really slow on my laptop
>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
>> wrong is happening while udev loading
>
> Please file a bug for this, on 'udev' component for now, and CC Harald
> Hoyer (hhoyer at redhat). Thanks!
>

Done
https://bugzilla.redhat.com/show_bug.cgi?id=530226

>> 5 - default gnome sound scheme is terrible
>
> This is a pretty subjective topic.

Yes, I know :)

Regards,
Michal



From mkkp4x4 at gmail.com  Wed Oct 21 23:33:28 2009
From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=)
Date: Thu, 22 Oct 2009 01:33:28 +0200
Subject: problem with dns
Message-ID: <596b53e0910211633h7ad0b918q4628f53fdbdef25c@mail.gmail.com>

Hi,

This is a problem that touches some of Fedora services.

I've got a network

192.168.101.0

192.168.101.1 - this is my router
192.168.101.200 - ozzy - my F11 server
192.168.101.100 - dio - my Windows 6 workstation

I use two DNS servers

nameserver 192.168.1.1
nameserver 194.204.159.1

The problem shows up when my network 192.168.101.0 lose a connection
with 192.168.1.0 and my primary DNS server is not available.

Every time when I try to use samba I get no response from ozzy. Here
is what is happening for mc

connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("192.168.1.1")}, 28) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "Z\253\1\0\0\1\0\0\0\0\0\0\4ozzy\2pl\0\0\1\0\1"..., 25,
MSG_NOSIGNAL, NULL, 0) = 25
poll([{fd=3, events=POLLIN}], 1, 5000)  = 0 (Timeout)
socket(PF_INET, 0x802 /* SOCK_??? */, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("194.204.159.1")}, 28) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "Z\253\1\0\0\1\0\0\0\0\0\0\4ozzy\2pl\0\0\1\0\1"..., 25,
MSG_NOSIGNAL, NULL, 0) = 25
poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
sendto(3, "Z\253\1\0\0\1\0\0\0\0\0\0\4ozzy\2pl\0\0\1\0\1"..., 25,
MSG_NOSIGNAL, NULL, 0) = 25
poll([{fd=3, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "Z\253\1\0\0\1\0\0\0\0\0\0\4ozzy\2pl\0\0\1\0\1"..., 25,
MSG_NOSIGNAL, NULL, 0) = 25
poll([{fd=4, events=POLLIN}], 1, 5000^C 

Program tries to reach an unreachable server. I have found a
workaround - temporary comment all nameservers in resolv.conf. But
it's not a solution for a long term.

Another instance of this problem is ssh logging
- I enter an user name
- about a 60 second delay
- password prompt appear

Yet another problem (when name servers are commented out in resolv.conf)
[root at ozzy ~]# yum --enablerepo=updates-testing upgrade
Wczytane wtyczki: presto, remove-with-leaves
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in 
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 311, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 180, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 349, in doCommands
    self._getTs(needTsRemove)
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 100, in _getTs
    self._getTsInfo(remove_only)
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 111,
in _getTsInfo
    pkgSack = self.pkgSack
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 702, in 
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 538,
in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 277, in
populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 164, in populate
    if self._check_db_version(repo, mydbtype):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 222, in
_check_db_version
    return repo._check_db_version(mdtype)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1222,
in _check_db_version
    repoXML = self.repoXML
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1386, in 
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1378,
in _getRepoXML
    self._loadRepoXML(text=self)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1368,
in _loadRepoXML
    return self._groupLoadRepoXML(text, ["primary"])
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1351,
in _groupLoadRepoXML
    if self._commonLoadRepoXML(text):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1192,
in _commonLoadRepoXML
    if self._latestRepoXML(local):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1170,
in _latestRepoXML
    repomd = self.metalink_data.repomd
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 699, in 
    metalink_data = property(fget=lambda self: self._getMetalink(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 681, in
_getMetalink
    print "Could not get metalink %s error was \n%s" %(url, e)
  File "/usr/lib64/python2.6/codecs.py", line 351, in write
    data, consumed = self.encode(object, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position
197: ordinal not in range(128)

I think that such behavior is clearly wrong. But it's a long term
issue. So maybe I'm wrong and this is a correct behavior?

Regards,
Michal



From tirloni at gmail.com  Thu Oct 22 00:20:14 2009
From: tirloni at gmail.com (Giovanni Tirloni)
Date: Wed, 21 Oct 2009 22:20:14 -0200
Subject: problem with dns
In-Reply-To: <596b53e0910211633h7ad0b918q4628f53fdbdef25c@mail.gmail.com>
References: <596b53e0910211633h7ad0b918q4628f53fdbdef25c@mail.gmail.com>
Message-ID: 

2009/10/21 Micha? Piotrowski :
> Hi,
>
> This is a problem that touches some of Fedora services.
>
> I've got a network
>
> 192.168.101.0
>
> 192.168.101.1 - this is my router
> 192.168.101.200 - ozzy - my F11 server
> 192.168.101.100 - dio - my Windows 6 workstation
>
> I use two DNS servers
>
> nameserver 192.168.1.1
> nameserver 194.204.159.1
>
> The problem shows up when my network 192.168.101.0 lose a connection
> with 192.168.1.0 and my primary DNS server is not available.

[...]

> Every time when I try to use samba I get no response from ozzy. Here
> is what is happening for mc
>
> I think that such behavior is clearly wrong. But it's a long term
> issue. So maybe I'm wrong and this is a correct behavior?

The daemons are doing reverse DNS lookups on the IP addresses and not
getting any answers.

You can either tweak that in the resolv.conf file so it doesn't take
so long to give up (see the man page for options) or configure your
services to ignore it.

For sshd you just need to uncomment the following line in sshd.conf:

#UseDns no

 But I don't see anything wrong with how things are happening in this situation.

-- 
Giovanni.



From hedayat at grad.com  Thu Oct 22 00:25:15 2009
From: hedayat at grad.com (Hedayat Vatankhah)
Date: Thu, 22 Oct 2009 03:55:15 +0330
Subject: Unable to download Fedora 12 beta using jigdo
Message-ID: <4ADFA66B.3020006@grad.com>

Hi,
I'm trying to download F12 beta DVD x86_64 iso using jigdo (I've used 
jigdo to download previous versions too). It successfully downloaded all 
files, but it doesn't accept downloaded install.img file and tries to 
download it again and again. I've tried downloading install.img several 
times (also using stand alone download applications) but jigdo doesn't 
accept any of them. As a result, jigdo doesn't compose the final .iso 
image because of 1 missing file. Does anybody have any ideas about the 
reason of failure? Has anybody downloaded F12 beta x86_64 using jigdo 
successfully?

Thanks,
Hedayat



From liangsuilong at gmail.com  Thu Oct 22 00:36:46 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Thu, 22 Oct 2009 08:36:46 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
Message-ID: 

To Tomasz,
Thank you! I have enabled compiz with ati oss drivers.

To Adam Williamson

Oh..So I need to remove radeonhd driver in my box. RadeonHD seems to be one
part of xorg-x11-drv-ati. They provides the same things to ati users. But
radeonhd only stand for R500/R600 later.

Yes, When rolling up and down in the gnome-terminal. I move up my mouse but
the scroll bar still stay at there for about 0.5 seconds to 1 seconds. You
can feel delay obviously. But I do not try to disable KMS. Let me try it and
report the problem to here.

-- 
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin.kofler at chello.at  Thu Oct 22 01:39:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Oct 2009 03:39:52 +0200
Subject: the mass rebuild and i586 rpms?
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<4ADD8782.10801@fi.muni.cz>
Message-ID: 

Milos Jakubicek wrote:
> Most probably those are the packages which failed during the mass
> rebuild...there are still plenty of them:
> 
> http://mjakubicek.fedorapeople.org/need-rebuild.html

That list is out of date. I fixed clutter-gtkmm to build a while ago because 
it had broken dependencies, and the fixed build got tagged into dist-f12 
already (and dist-f13 inherits it from there too).

        Kevin Kofler



From awilliam at redhat.com  Thu Oct 22 02:15:53 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 21 Oct 2009 19:15:53 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: <1256177753.2314.452.camel@adam.local.net>

On Thu, 2009-10-22 at 08:36 +0800, Liang Suilong wrote:

> Oh..So I need to remove radeonhd driver in my box. RadeonHD seems to
> be one part of xorg-x11-drv-ati. They provides the same things to ati
> users. But radeonhd only stand for R500/R600 later. 

radeonhd is not part of ati, they are effectively in competition.
They're two different drivers for the same hardware. ati is the one that
Fedora supports.

> Yes, When rolling up and down in the gnome-terminal. I move up my
> mouse but the scroll bar still stay at there for about 0.5 seconds to
> 1 seconds. You can feel delay obviously. But I do not try to disable
> KMS. Let me try it and report the problem to here. 

Thanks, please let us know how it goes.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From kevin.kofler at chello.at  Thu Oct 22 02:42:45 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Oct 2009 04:42:45 +0200
Subject: On updates to stable releases
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
Message-ID: 

Adam Jackson wrote:
> I don't really want to revive the thread about automake 1.11, but I do
> want to point out that it did break actual buildability:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log

So xorg-x11-server needs a one-line patch to build again? I fail to see the 
big issue there.

> Please, people.  Don't update things in stable releases just for fun.
> Particularly if your package is part of the build environment for
> something else.

That also means something else may need the updated package to even build at 
all, and in fact this is the reason the automake update was requested and 
pushed.

        Kevin Kofler



From oget.fedora at gmail.com  Thu Oct 22 03:24:57 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Wed, 21 Oct 2009 23:24:57 -0400
Subject: On updates to stable releases
In-Reply-To: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
References: <1256156900.15835.6788.camel@atropine.boston.devel.redhat.com>
Message-ID: 

On Wed, Oct 21, 2009 at 4:28 PM, Adam Jackson wrote:
> I don't really want to revive the thread about automake 1.11, but I do
> want to point out that it did break actual buildability:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1761549&name=build.log
>
> Please, people. ?Don't update things in stable releases just for fun.
> Particularly if your package is part of the build environment for
> something else. ?I don't care if it bills itself as "just a bugfix
> release"; that's how you know it's lying.
>

You missed the whole point of the previous discussion. It didn't go
unnoticed, did it?

I mean, a build failure is hard to miss. As soon as it fails to build
you know that it failed to build. You can't be happy as if your
package has been built successfully when it actually failed. If you
are happy that your package failed to build, then either there is a
problem with you or a problem with the rest of us. In either case the
outcome is the same: The package *failed* to build.

Please come up with an example where there are no warnings in the
build logs and the package builds and installs fine, but it is broken.

Orcan



From fedora at camperquake.de  Thu Oct 22 06:27:27 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 22 Oct 2009 08:27:27 +0200
Subject: Eternal 'good file hashes' list
In-Reply-To: <4ADF7422.8040901@nodata.co.uk>
References: <20091020084540.622d5d28@dhcp03.addix.net>
	<80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>
	<20091021084702.43dcba99@dhcp03.addix.net>
	<4ADF7422.8040901@nodata.co.uk>
Message-ID: <20091022082727.68d1be3b@dhcp03.addix.net>

Hi.

On Wed, 21 Oct 2009 22:50:42 +0200, nodata wrote:

> Running on the compromised system, or running somewhere else?
> Where are you running rpm from?

Running from an external boot medium (CD/DVD/USB stick/whatever), not
from within the (possibly compromised) system itself. The known good
signatures could be included on the boot media, or pulled from the
network (if available) on demand.



From mmaslano at redhat.com  Thu Oct 22 07:07:59 2009
From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=)
Date: Thu, 22 Oct 2009 09:07:59 +0200
Subject: Fwd: Power Managemet Testday 22. Oct 2009
Message-ID: <4AE004CF.5080403@redhat.com>



-------- Original Message --------
Subject: 	Power Managemet Testday 22. Oct 2009
Date: 	Thu, 22 Oct 2009 03:04:12 -0400 (EDT)
From: 	Jan Scotka 
To: 	Marcela Maslanova 



Hi folks,
Today 2009-10-22 is planned next Power Management Test Day.
We will be glad to see you all there.
For more info:
https://fedoraproject.org/wiki/Features/PowerManagementF12
 
and link to today testday:
https://fedoraproject.org/wiki/Test_Day:2009-10-22

please join #fedora-test-day on freenode irc From 12:00 to 21:00 UTC (8am -> 5pm EDT) and append your results.

Regards
  Honza

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mhlavink at redhat.com  Thu Oct 22 07:17:12 2009
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Thu, 22 Oct 2009 09:17:12 +0200
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: <1256160451.2314.421.camel@adam.local.net>
References: 
	
	<1256160451.2314.421.camel@adam.local.net>
Message-ID: <200910220917.12776.mhlavink@redhat.com>

On Wednesday 21 October 2009 23:27:31 Adam Williamson wrote:
> On Wed, 2009-10-21 at 15:16 +0800, Liang Suilong wrote:
> > Today I upgrade my Fedora to Fedora 12 Beta, It looks very well. But I
> > found ATi display driver does not run well.
> >
> >
> > My display card is Sapphire HD3650 with 256MB GDDR3 VRAM (RV635). I
> > choose OSS driver for my card. Glxgears runs so smoothly with
> > xorg-x11-drv-ati because of KMS by default, nevertheless, rolling up
> > and down in the gnome-terminal is quite slow. The performance of
> > glxgears is about 210 frams per second. In addition, Switching to
> > another window in Fedora 12 Beta is not as fast in Fedora 11. Later, I
> > install xorg-x11-drv-radeonhd and set it by default in the
> > system-config-display. Then I restart the X. I can not log into gnome.
> > The screen turns white. I found xorg-x11-drv-radeonhd is too old, The
> > version is 1.2.5 in the rawhide and the latest version 1.3.0 has been
> > released for a long time. Now I turn back to xorg-x11-drv-ati. At
> > last, I do not know which packages causes the  problem, maybe
> > xorg-x11-drv-ati, maybe xorg-x11-drv-radeonhd, maybe Mesa. So I
> > suggest that packager updates some packge related to ATi R600/R700
> > display card.
> 
> Fedora doesn't really care about the radeonhd driver. We may well even
> remove it at some point soon. The ati driver is the one you should use
> on Fedora, that's why it's the default.
> 
> You do not get 3D acceleration out of the box on that card, r600 3D
> acceleration is too early to be enabled by default. If you want to try
> it out, install the mesa-dri-drivers-experimental package.
> 
> For the slow 2D performance - _how_ slow is it, really? gnome-terminal
> has never been much of a speed demon. Does it get any faster if you boot
> with 'nomodeset' as a kernel parameter?
> 

Hi, 
I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic 
card, I was going to file new bug. With kms enabled, everything is really 
sloooow, with 'nomodeset' it's much faster. I can't say exactly "how" slow it 
is, is there anything I can use for measuring?

Michal

btw, mesa-dri-drivers-experimental does not work at all for me (glx apps 
segfault)



From mcepl at redhat.com  Thu Oct 22 07:40:19 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 22 Oct 2009 09:40:19 +0200
Subject: Fedora 12 Beta
In-Reply-To: <1256160900.2314.427.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
Message-ID: <4AE00C63.8070000@redhat.com>

Dne 21.10.2009 23:35, Adam Williamson napsal(a):
>> 4 - F12 boots really slow on my laptop
>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
>> wrong is happening while udev loading

I have filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=528312
... if you run udevadm monitor --env while udev is eating your CPU (yes,
I know it is tough, I tried many times before I succeeded), who is to blame?

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Don't anthropomorphize computers.  They don't like it.



From mail at marcus-moeller.de  Thu Oct 22 07:46:37 2009
From: mail at marcus-moeller.de (Marcus Moeller)
Date: Thu, 22 Oct 2009 09:46:37 +0200
Subject: extracting multiple sources in %setup
Message-ID: 

Hi,

is there a way to extract multiple sources in a spec files %setup section?

Something like:

for i in {1..10}; do tar xfz %(SOURCE$i}; done

Best Regards
Marcus



From mcepl at redhat.com  Thu Oct 22 07:40:19 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Thu, 22 Oct 2009 09:40:19 +0200
Subject: Fedora 12 Beta
In-Reply-To: <1256160900.2314.427.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
Message-ID: <4AE00C63.8070000@redhat.com>

Dne 21.10.2009 23:35, Adam Williamson napsal(a):
>> 4 - F12 boots really slow on my laptop
>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
>> wrong is happening while udev loading

I have filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=528312
... if you run udevadm monitor --env while udev is eating your CPU (yes,
I know it is tough, I tried many times before I succeeded), who is to blame?

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Don't anthropomorphize computers.  They don't like it.



From hughsient at gmail.com  Thu Oct 22 07:47:24 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 22 Oct 2009 08:47:24 +0100
Subject: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11
	AM EDT)
In-Reply-To: <4ADF8464.2070200@redhat.com>
References: <4ADF8464.2070200@redhat.com>
Message-ID: <15e53e180910220047x774c8590sdea66e9ad332d4fb@mail.gmail.com>

2009/10/21 John Poelstra :
> 520750 - PackageKit - ASSIGNED ?- Software Update windows checks for update
> does not stop ..

This has been reported by one person (no dupes), and I'm still waiting
for more information. I suspect it's actually a hardware problem or
file-system corruption on the reporters computer. Basically, I don't
think this should be a blocker.

Richard.



From nicolas.mailhot at laposte.net  Thu Oct 22 07:55:02 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Oct 2009 09:55:02 +0200
Subject: extracting multiple sources in %setup
In-Reply-To: 
References: 
Message-ID: <2fcb0a1cbc3f554f0b510f48f1f1072e.squirrel@arekh.dyndns.org>



Le Jeu 22 octobre 2009 09:46, Marcus Moeller a ?crit :

> is there a way to extract multiple sources in a spec files %setup section?
>
> Something like:
>
> for i in {1..10}; do tar xfz %(SOURCE$i}; done

If you have multiple sources that's usually a sign you're doing something
wrong. It is very dangerous to aggregate sources from different upstreams in a
single rpm (release cycle and legal problems), or to group sources upstream
split (usually for ease of maintenance reasons)

-- 
Nicolas Mailhot




From oget.fedora at gmail.com  Thu Oct 22 07:55:51 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Thu, 22 Oct 2009 03:55:51 -0400
Subject: extracting multiple sources in %setup
In-Reply-To: 
References: 
Message-ID: 

On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
> Hi,
>
> is there a way to extract multiple sources in a spec files %setup section?
>
> Something like:
>
> for i in {1..10}; do tar xfz %(SOURCE$i}; done
>
> Best Regards
> Marcus
>

%setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9 -a 10

should work. I don't if there's any nicer way.

Orcan



From rjones at redhat.com  Thu Oct 22 08:26:06 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Oct 2009 09:26:06 +0100
Subject: What does it mean " not tagged as an update candidate"?
Message-ID: <20091022082606.GA15608@amd.home.annexia.org>


I'm trying to create an update for a new package (mingw32-freeglut,
https://bugzilla.redhat.com/show_bug.cgi?id=528892) in F-12, but I get
the error below:

  $ make update
  [...]
  Creating a new update for  mingw32-freeglut-2.6.0-0.1.rc1.fc12 
  mingw32-freeglut-2.6.0-0.1.rc1.fc12 not tagged as an update candidate

What does it mean?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From dominik at greysector.net  Thu Oct 22 08:33:23 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 22 Oct 2009 10:33:23 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <19965.1256162829@sss.pgh.pa.us>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<4ADF56C8.3060602@gmail.com> <19965.1256162829@sss.pgh.pa.us>
Message-ID: <20091022083322.GA19702@mokona.greysector.net>

On Thursday, 22 October 2009 at 00:07, Tom Lane wrote:
> Lyos Gemini Norezel  writes:
> > Why not just require a secondary email address?
> 
> "Require" a secondary email address?  Not everyone has one, or wants
> to hand it over if they do.  That sounds more like a recipe for driving
> maintainers away than making sure you can contact them.

How about: Maintainers should provide a secondary e-mail address if their
primary address is supplied by their current employer.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From hedayat at grad.com  Thu Oct 22 08:30:26 2009
From: hedayat at grad.com (Hedayat Vatankhah)
Date: Thu, 22 Oct 2009 12:00:26 +0330
Subject: Unable to download Fedora 12 beta using jigdo
In-Reply-To: <4ADFA66B.3020006@grad.com>
References: <4ADFA66B.3020006@grad.com>
Message-ID: <4AE01822.9080803@grad.com>

Hi again,
I finally managed to create the image by downloading net install .iso 
image and providing its install.img to jigdo!

Good luck,
Hedayat

On ??/??/??  03:55, Hedayat Vatankhah wrote:
> Hi,
> I'm trying to download F12 beta DVD x86_64 iso using jigdo (I've used 
> jigdo to download previous versions too). It successfully downloaded 
> all files, but it doesn't accept downloaded install.img file and tries 
> to download it again and again. I've tried downloading install.img 
> several times (also using stand alone download applications) but jigdo 
> doesn't accept any of them. As a result, jigdo doesn't compose the 
> final .iso image because of 1 missing file. Does anybody have any 
> ideas about the reason of failure? Has anybody downloaded F12 beta 
> x86_64 using jigdo successfully?
>
> Thanks,
> Hedayat




From xjakub at fi.muni.cz  Thu Oct 22 09:07:22 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Thu, 22 Oct 2009 11:07:22 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091021181022.GA7460@clingman.lan>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
Message-ID: <4AE020CA.5080703@fi.muni.cz>

Hi,

On 21.10.2009 20:10, Toshio Kuratomi wrote:
> * Should we formalize the unwritten policy for Red Hat maintainers who leave
>    the company and don't want to maintain their packages anymore?
>    * Do we need sanity checks to be sure maintainers who do want to keep
>      their packages do so?

I don't think so: in past it was always clear who wants to maintain the 
package further (at least because the maintainer changed his contact 
from @redhat.com to some private address).

>    * Do we want something more generic that covers other compaines that pay
>      their employees to package for Fedora?

I'd rather set now this policy for RH employees (which will cover 99 % 
of cases) than discuss anything like secondary mail addresses and 
various situations which can raise up with other companies for the next 
month. The RH environment is clear to us and easy for manage to you (I 
mean there are no actual problems with handling this within RH), am I right?

Regards,
Milos



From opensource at till.name  Thu Oct 22 09:16:08 2009
From: opensource at till.name (Till Maas)
Date: Thu, 22 Oct 2009 11:16:08 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091021181022.GA7460@clingman.lan>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
Message-ID: <20091022091608.GA4663@genius.kawo2.rwth-aachen.de>

On Wed, Oct 21, 2009 at 11:10:22AM -0700, Toshio Kuratomi wrote:

> * Should we expedite these requests in the future if the email address for
>   the maintainer is no longer in existence?

Yes, please. If the mail address of a maintainers do not work anymore,
then their packages should be orphaned, so that others can maintain
them. If the mail address does not work, then all bug report
notifications would get lost and also communication attempts using the
package-owner aliases. Therefore it should be made sure there is always
someone caring about these messages for each package.

> * Should we formalize the unwritten policy for Red Hat maintainers who leave
>   the company and don't want to maintain their packages anymore?

Yes, unwritten policies are always bad.

>   * Do we need sanity checks to be sure maintainers who do want to keep
>     their packages do so?

What kind of checks do you mean? If maintainers want to keep their
packages, they can just change the owner of the package to their new
private account before leaving Red Hat.

>   * Do we want something more generic that covers other compaines that pay
>     their employees to package for Fedora?

Does it need to be different than the currently unwritted Red Hat
policy? If not, then it could just be the same policy Red Hat can be
used as an example, if needed.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

From rjones at redhat.com  Thu Oct 22 10:04:36 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Oct 2009 11:04:36 +0100
Subject: Unreadable binaries
Message-ID: <20091022100436.GA16025@amd.home.annexia.org>


$ ll /usr/libexec/pt_chown 
-rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown
$ ll /usr/bin/chsh 
-rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh

What is the purpose of making binaries like these unreadable?

Originally I thought it was something to do with them being setuid,
but there are counterexamples:

$ ll /usr/bin/passwd 
-rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd

Surely there is no possible secret in those binaries, since an
attacker could just as easily download the binary RPMs on another
machine in order to find out what is inside them.

There's a genuine reason for me asking about this.  When we build the
libguestfs supermin appliance[1] we would like to be able to read
these binaries as non-root.

Rich.

[1] http://libguestfs.org/README.txt section "Supermin appliance"

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From bruno at wolff.to  Thu Oct 22 10:07:01 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Oct 2009 05:07:01 -0500
Subject: What does it mean " not tagged as an update candidate"?
In-Reply-To: <20091022082606.GA15608@amd.home.annexia.org>
References: <20091022082606.GA15608@amd.home.annexia.org>
Message-ID: <20091022100701.GA1506@wolff.to>

On Thu, Oct 22, 2009 at 09:26:06 +0100,
  "Richard W.M. Jones"  wrote:
> 
> I'm trying to create an update for a new package (mingw32-freeglut,
> https://bugzilla.redhat.com/show_bug.cgi?id=528892) in F-12, but I get
> the error below:
> 
>   $ make update
>   [...]
>   Creating a new update for  mingw32-freeglut-2.6.0-0.1.rc1.fc12 
>   mingw32-freeglut-2.6.0-0.1.rc1.fc12 not tagged as an update candidate
> 
> What does it mean?

Probably that has to do with using bodhi for F12 being delayed for a while.
You should open a release engineering ticket instead. There was an
announcement from Warren about this within the last 24 hours.



From jnovy at redhat.com  Thu Oct 22 11:17:04 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Thu, 22 Oct 2009 13:17:04 +0200
Subject: Major reorganization of TeX Live packages
Message-ID: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>

Hi,

I would like to announce couple of major changes in the TeX Live 2009
repository.

The main improvements are:

* TL2009 now contains virtual provides to resolve dependencies among
.sty files. This assures you have a complete set of other styles
installed in order to use one. To install a particular style you can
do e.g. "yum install 'tex(upref.sty)'" and you needn't to know it comes
from texlive-amscls package. The exception are dependencies to styles
which are either commercial (such as mathtime.sty) or not available from
CTAN. These styles were blacklisted and dependency generator ignores
them.

* Upgradability from older TeX Live 2007 is now improved. You may
remember that the biggest problem with upgrading TL is not in TeX Live
itself but in utilities around it, like xdvipdfm, psutils, etc. that
needs older kpathsea library than shipped with TL2009. I've done some
modifications so that starting with texlive-2007-45 and higher, both
newer and older libraries can coexist. So you should be able to run
your F11 apps linked against old kpathsea together with new TL2009.

* a version string was added to noarch packages to allow to upgrade
all of the noarch packages even if upstream hasn't done any
modifications. This allows me to not to break upgrade path if some
major packaging changes are made and these packages need to be rebuilt.

* TL packages released under GFSL license are now added.

In case you have an older TL2009 installed on your system from the
testing repository, please consider removing it and installing again.

Thanks,
Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From j.w.r.degoede at hhs.nl  Thu Oct 22 11:46:55 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 22 Oct 2009 13:46:55 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <1254803372.2291.20.camel@adam.local.net>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>	
	<4ACA0239.3010000@hhs.nl> <1254803372.2291.20.camel@adam.local.net>
Message-ID: <4AE0462F.90100@hhs.nl>

On 10/06/2009 06:29 AM, Adam Williamson wrote:
> On Mon, 2009-10-05 at 16:27 +0200, Hans de Goede wrote:
>
>> Thanks for bringing this up. I'll create a patch for the scripts
>> generating the livecd to add rd_NO_LUKS to the normal livecd
>> syslinux.cfg entry. I already was planning on doing this, but I forgot.
>
> can you file a tag request to get this into the beta? it's the kind of
> thing that shouldn't show up in the beta, and we can't fix it with
> updates. and it's a pretty safe change (just switching a behaviour
> choice when we know both choices do what they're supposed to). CCing
> Jesse to accept the request.
>

Hi,

This is in rawhide now, must the beta though.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Thu Oct 22 11:47:38 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 22 Oct 2009 13:47:38 +0200
Subject: dracut, or should booting a LiveCD touch the hard disk?
In-Reply-To: <4AE0462F.90100@hhs.nl>
References: <20091004213552.GC28455@angus.ind.WPI.EDU>		<4ACA0239.3010000@hhs.nl>
	<1254803372.2291.20.camel@adam.local.net> <4AE0462F.90100@hhs.nl>
Message-ID: <4AE0465A.2080700@hhs.nl>

On 10/22/2009 01:46 PM, Hans de Goede wrote:
> On 10/06/2009 06:29 AM, Adam Williamson wrote:
>> On Mon, 2009-10-05 at 16:27 +0200, Hans de Goede wrote:
>>
>>> Thanks for bringing this up. I'll create a patch for the scripts
>>> generating the livecd to add rd_NO_LUKS to the normal livecd
>>> syslinux.cfg entry. I already was planning on doing this, but I forgot.
>>
>> can you file a tag request to get this into the beta? it's the kind of
>> thing that shouldn't show up in the beta, and we can't fix it with
>> updates. and it's a pretty safe change (just switching a behaviour
>> choice when we know both choices do what they're supposed to). CCing
>> Jesse to accept the request.
>>
>
> Hi,
>
> This is in rawhide now, must the beta though.
>

That should read *missed* the beta though.

Regards,

Hans



From liangsuilong at gmail.com  Thu Oct 22 11:56:59 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Thu, 22 Oct 2009 19:56:59 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
Message-ID: 

To Adam Williamson

I try to add kernel parameter nomodeset to turn off KMS. After logging in
Gnome and run gnome-terminal, I can scroll up and down my mouse so smoothly.
I do not feel scrolling in the terminal is slow.

Before doing that, I installed Fedora 12 Beta and upgrade to the latest
packages in VirtualBox 3.0.8. The situation is the same with the host which
is turned off KMS.

We can sure that KMS for R600 cause the problem. But KMS in the mainline
kernel is experimental. I believe that the bug will be fixed. Thanks to
Fedora developers, I can enjoy compiz with  opensource drivers.

Another things, xorg-x11-drv-ati with mesa-dri-drivers-experimental seems
not to ru gnome-shell. Does it mean that ATi opensource need more OpenGL
extensions to stand for gnome-shell?

Plymouth is so beautiful and smooth when I start up my Fedora 12,
nevertheless, it does not work when I shutdown or reboot my box. I just can
see a black screen or console status. How can I make plymouth run again?

ATi should learn Intel how to develop opensource drivers for their graphic
card. The relationship between ati and radeonhd should be cooperation not
competition. This is just my opinon.

-- 
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liangsuilong at gmail.com  Thu Oct 22 12:08:20 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Thu, 22 Oct 2009 20:08:20 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
Message-ID: 

Hi,
I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic
card, I was going to file new bug. With kms enabled, everything is really
sloooow, with 'nomodeset' it's much faster. I can't say exactly "how" slow
it
is, is there anything I can use for measuring?
Michal
btw, mesa-dri-drivers-experimental does not work at all for me (glx apps
segfault)


To Michal Hlavinka,
Hi, in Fedora 12, KMS for R600/R700 is an experimental features. The next
mainline kernel, 2.6.32 will official support KMS of R600/R700.

Xorg still does not release opensource drivers for R600/R700 to run 3D
program. Mesa-dri-drivers-experimental is just a testing package. It can run
compiz. But compiz is easy to crash with this dri-drivers. Believe that,
Fedora developers still work hard for opensource ati driver. Please wait a
moment. 3D acceleration is coming soon.


   --
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mschmidt at redhat.com  Thu Oct 22 12:23:01 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 22 Oct 2009 14:23:01 +0200
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: <4AE04EA5.2050901@redhat.com>

On 10/22/2009 01:56 PM, Liang Suilong wrote:
> I try to add kernel parameter nomodeset to turn off KMS. After logging
> in Gnome and run gnome-terminal, I can scroll up and down my mouse so
> smoothly. I do not feel scrolling in the terminal is slow.

I noticed that performance with KMS is more affected than non-KMS by the 
debugging options which are enabled in Rawhide kernel. The final release 
will have most of them disabled, so there's a chance the performance 
with KMS will improve.
You could try rebuilding the kernel without debugging to confirm it.

Michal



From ndbecker2 at gmail.com  Thu Oct 22 12:30:37 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 22 Oct 2009 08:30:37 -0400
Subject: Major reorganization of TeX Live packages
References: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: 

Jindrich Novy wrote:

> Hi,
> 
> I would like to announce couple of major changes in the TeX Live 2009
> repository.
> 

Where?



From jnovy at redhat.com  Thu Oct 22 12:42:41 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Thu, 22 Oct 2009 14:42:41 +0200
Subject: Major reorganization of TeX Live packages
In-Reply-To: 
References: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>
	
Message-ID: <20091022124241.GA5996@dhcp-lab-133.englab.brq.redhat.com>

On Thu, Oct 22, 2009 at 08:30:37AM -0400, Neal Becker wrote:
> Jindrich Novy wrote:
> 
> > Hi,
> > 
> > I would like to announce couple of major changes in the TeX Live 2009
> > repository.
> > 
> 
> Where?
> 

In the Fedora TeX Live 2009 testing repository, for more info:

http://fedoraproject.org/wiki/Features/TeXLive

Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From sds at tycho.nsa.gov  Thu Oct 22 12:48:03 2009
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Thu, 22 Oct 2009 08:48:03 -0400
Subject: Should installkernel be passing --dracut to new-kernel-pkg?
Message-ID: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>

Hi,

/sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a
make install from a kernel.org kernel tree tries to
invoke /sbin/mkinitrd rather than dracut.  Is that intentional?

Also, any ideas on why a dracut-generated initramfs image generated for
a kernel.org kernel tree would be so much larger than the Fedora kernel
one (same .config)?

12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img
82M /boot/initramfs-2.6.32-rc2.img

-- 
Stephen Smalley
National Security Agency



From jlaska at redhat.com  Thu Oct 22 12:48:59 2009
From: jlaska at redhat.com (James Laska)
Date: Thu, 22 Oct 2009 08:48:59 -0400
Subject: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11
 AM EDT)
In-Reply-To: <15e53e180910220047x774c8590sdea66e9ad332d4fb@mail.gmail.com>
References: <4ADF8464.2070200@redhat.com>
	<15e53e180910220047x774c8590sdea66e9ad332d4fb@mail.gmail.com>
Message-ID: <1256215739.2398.62.camel@localhost.localdomain>

On Thu, 2009-10-22 at 08:47 +0100, Richard Hughes wrote:
> 2009/10/21 John Poelstra :
> > 520750 - PackageKit - ASSIGNED  - Software Update windows checks for update
> > does not stop ..
> 
> This has been reported by one person (no dupes), and I'm still waiting
> for more information. I suspect it's actually a hardware problem or
> file-system corruption on the reporters computer. Basically, I don't
> think this should be a blocker.

Richard: Btw ... thanks for this feedback ahead of the meeting.  With
such a large list to review, it's extremely helpful when folks review
their bugs ahead of time.  We do our best to collaboratively review the
bugs real-time.  But having feedback from the maintainers and/or people
experiencing the bug helps speed up the process.  

If you've got a spare minute waiting on a build ... take a look at the
list of bugs:

     1. Respond to the announcement with your $0.02 as Richard has done
     2. Alternatively, update the bz with your thoughts
              * Is the severity appropriate?
              * Is there a workaround?
              * What impact does the presence of this failure have on
                users?
              * What is your favorite color?
     3. As always, in a constructive manner, tell us how we can improve
        this process -
        https://fedoraproject.org/wiki/User_talk:Poelstra/blocker_bug_meeting_sop
 
Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From fedora at matbooth.co.uk  Thu Oct 22 13:07:14 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Thu, 22 Oct 2009 13:07:14 +0000
Subject: extracting multiple sources in %setup
In-Reply-To: 
References: 
	
Message-ID: <9497e9990910220607m6ff4cd32q558eb6f260ade22d@mail.gmail.com>

2009/10/22 Orcan Ogetbil :
> On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
>> Hi,
>>
>> is there a way to extract multiple sources in a spec files %setup section?
>>
>> Something like:
>>
>> for i in {1..10}; do tar xfz %(SOURCE$i}; done
>>
>> Best Regards
>> Marcus
>>
>
> %setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9 -a 10
>
> should work. I don't if there's any nicer way.
>
> Orcan
>

It's also perfectly acceptable to call the %setup macro more than
once, if you need to.

There is some stuff in Max RPM about it:

http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-MULTI-SOURCE

-- 
Mat Booth

A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?



From rawhide at fedoraproject.org  Thu Oct 22 13:06:12 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 22 Oct 2009 13:06:12 +0000
Subject: rawhide report: 20091022 changes
Message-ID: <20091022130612.GA12194@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 22 06:15:12 UTC 2009

Broken deps for i386
----------------------------------------------------------
	openscada-visStation-0.6.4-3.fc12.i686 requires openscada-Special-FlibSYS



Broken deps for x86_64
----------------------------------------------------------
	openscada-visStation-0.6.4-3.fc12.x86_64 requires openscada-Special-FlibSYS






Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package EMBOSS
        The European Molecular Biology Open Software Suite
New package MySQL-zrm
        MySQL backup manager
New package NetPIPE
        Protocol independent performance tool
New package TurboGears2
        Next generation Front-to-back web development megaframework built on Pylons
New package afraid-dyndns
        A dynamic DNS client for the free service afraid.org
New package alure
        Audio Library Tools REloaded
New package ayttm
        Universal Instant Messaging Client
New package bauble
        Biodiversity collection manager
New package chronojump
        A measurement, management and statistics sport testing tool
New package cmospwd
        BIOS password cracker utility
New package drehatlas-warender-bibliothek-fonts
        A Latin typeface that is decorative, surreal, and hairy
New package drehatlas-widelands-fonts
        A Latin typeface inspired by feudal calligraphy
New package dualscreen-mouse-utils
        Utilities for use with dual head setups using independent screens
New package fapg
        Fast Audio Playlist Generator
New package fedora-gnat-project-common
        Files shared by Ada libraries
New package gargi-fonts
        A Devanagari font
New package garmintools
        Communication tools for Garmin devices
New package globus-authz
        Globus Toolkit - Globus authz library
New package globus-authz-callout-error
        Globus Toolkit - Globus authz error library
New package globus-data-conversion
        Globus Toolkit - Data Conversion
New package globus-gass-cache
        Globus Toolkit - Globus Gass Cache
New package globus-gatekeeper
        Globus Toolkit - Globus Gatekeeper
New package globus-gram-client
        Globus Toolkit - GRAM Client Library
New package globus-gram-protocol
        Globus Toolkit - GRAM Protocol Library
New package globus-gridftp-server-control
        Globus Toolkit - Globus GridFTP Server Library
New package globus-mp
        Globus Toolkit - Message Passing Library
New package gnustep-gui
        The GNUstep GUI library
New package gpx-viewer
        A simple gpx viewer
New package gtrayicon
        Generic tray icon for GNOME
New package jempbox
        Java library for working with XMP metadata
New package json_simple
        Simple Java toolkit for JSON
New package libgtkhotkey
        Platform independent hotkey handling for Gtk+ applications
New package libnetdevname
        A library that provides network name mappings
New package linbox
        C++ Library for High-Performance Linear Algebra
New package madwimax
        Driver for mobile WiMAX devices based on Samsung CMC-730 chip
New package mingw32-proj
        Cartographic projection software (PROJ.4)
New package mod_gnutls
        GnuTLS module for the Apache HTTP server
New package myproxy
        Manage X.509 Public Key Infrastructure (PKI) security credentials
New package ncid
        Network Caller ID server, client, and gateways
New package ncrack
        High-speed network auth cracking tool
New package ocaml-react
        OCaml framework for Functional Reactive Programming (FRP)
New package oflb-prociono-fonts
        A text roman with standard and discretionary ligatures, class-based kerning
New package parole
        Media player for the Xfce desktop
New package pdf2svg
        Small tool to convert PDF files into SVG
New package perl-Tk-ProgressBar-Mac
        Mac ProgressBar for Perl::Tk
New package piccolo2d
        Structured 2D graphics toolkit
New package popfile
        Automatic Email Classification
New package py-radix
        Radix tree data structure for Python
New package python-catwalk
        A way to view your models using TurboGears
New package python-guppy
        A Python Programming Environment
New package rubygem-cucumber
        Tool to execute plain-text documents as functional tests
New package rubygem-ditz
        A command-line issue tracker
New package rubygem-extlib
        Support library for DataMapper and Merb
New package rubygem-mixlib-cli
        Simple ruby mixin for CLI interfaces
New package rubygem-mixlib-config
        Simple ruby config mixin
New package rubygem-mixlib-log
        Ruby mixin for log functionality
New package rubygem-systemu
        Multi-platform command execution and capture
New package rubygem-trollop
        A command-line option parsing library for ruby
New package sblim-cim-client
        Java CIM Client library
New package sblim-cmpi-network
        SBLIM Network Instrumentation
New package sblim-cmpi-nfsv3
        SBLIM nfsv3 instrumentation
New package sil-lateef-fonts
        An Arabic script unicode font
New package sil-padauk-fonts
        A font for Burmese and the Myanmar script
New package sil-scheherazade-fonts
        An Arabic script unicode font
New package stomppy
        Python stomp client for messaging
New package tcl-mysqltcl
        MySQL interface for Tcl
New package thunar-vcs-plugin
        SVN integration for the Thunar filemanager
New package tito
        A tool for managing rpm based git projects
New package torium
        A minimalistic, easily configurable torrent client for Linux
New package umlgraph
        Automated Drawing of UML Diagrams
New package vim-perl-tt2
        Syntax highlighting for the Template-Toolkit
New package wb_builder
        Wishbone Bus Builder
New package webacula
        Web interface of a Bacula backup system
New package whaawmp
        Lightweight Media Player
New package winwrangler
        Small desktop daemon to perform advanced window manipulations
New package x11vnc
        VNC server for the current X11 session
New package xfce4-stopwatch-plugin
        Stopwatch plugin for the Xfce panel
New package xmltooling
        XML signing and encrytion library
New package yaml-cpp
        A YAML parser and emitter for C++
New package yapet
        Curses based password encryption tool
New package zikula-module-advanced_polls
        Advanced voting system for Zikula
Removed package gadmin-squid
Updated Packages:

389-admin-1.1.9-1.fc12
----------------------
* Mon Sep 14 2009 Rich Megginson  - 1.1.9-1
- the 1.1.9 release


389-console-1.1.3-5.fc12
------------------------
* Wed Sep 30 2009 Rich Megginson  1.1.3-5
- bug 521523 - add the "which" package to the Requires


389-ds-base-1.2.3-1.fc12
------------------------
* Mon Sep 14 2009 Rich Megginson  - 1.2.3-1
- 1.2.3 release
- added template-initconfig to %files
- %posttrans now runs update to update the server instances
- servers are shutdown, then restarted if running before install
- scriptlets mostly use lua now to pass data among scriptlet phases


GMT-4.5.1-1.fc12
----------------
* Mon Oct 19 2009 Orion Poplawski  4.5.1-1
- Update to 4.5.1
- Enable gdal support


GMT-coastlines-2.0.1-1.fc12
---------------------------
* Fri Oct 16 2009 Orion Poplawski  2.0.1-1
- Update to 2.0.1


NetworkManager-0.7.996-5.git20091021.fc12
-----------------------------------------
* Wed Oct 21 2009 Dan Williams  - 0.7.996-5.git20091021
- install: better fix for (rh #526519)
- install: don't build Bluetooth bits on s390 (rh #529854)
- nm: wired 802.1x connection activation fixes
- nm: fix crash after modifying default wired connections like "Auto eth0"
- nm: ensure VPN secrets are requested again after connection failure
- nm: reset 'accept_ra' to previous value after deactivating IPv6 connections
- nm: ensure random netlink events don't interfere with IPv6 connection activation
- ifcfg-rh: fix writing out LEAP connections
- ifcfg-rh: recognize 'static' as a valid BOOTPROTO (rh #528068)
- applet: fix "could not find required resources" error (rh #529766)


R-qtl-1.14.2-1.fc12
-------------------
* Wed Oct 07 2009 Mattias Ellert  - 1.14.2-1
- New upstream release
- Disable the check since it trips on a missing suggested package
- Change license tag to GPLv3 to reflect an upstream license change


anjal-0.1.0-1.fc12
------------------
* Wed Oct 21 2009 Peter Robinson  0.1.0-1
- Fix versioning

* Mon Oct 19 2009 Peter Robinson  0.1-1
- Official upstream 0.1 release


arora-0.10.1-1.fc12
-------------------
* Tue Oct 06 2009 Jaroslav Reznik  - 0.10.1-1
- Update to 0.10.1

* Fri Oct 02 2009 Jaroslav Reznik  - 0.10.0-1
- Update to 0.10.0

* Fri Oct 02 2009 Jaroslav Reznik  - 0.10.0-2
- Fedorahome patch rebased


astyle-1.23-1.fc12
------------------
* Tue Oct 13 2009 Thomas Spura  - 1.23-1
- Update to new version
- patch from Sep 24 2008 not needed anymore for gcc-4.4


at-3.1.10-39.fc12
-----------------
* Tue Oct 13 2009 Marcela Ma?l??ov?  - 3.1.10-39
- 528582 add noreplace option into files section


audacious-plugins-2.1-6.fc12
----------------------------
* Wed Oct 21 2009 Michael Schwendt  - 2.1-6
- Rediff the underruns patch and set buffer_time_min.

* Mon Oct 19 2009 Michael Schwendt  - 2.1-5
- Patch pulseaudio plugin to not get confused by volume values passed
  in via callback.


aumix-2.8-21.fc12
-----------------
* Wed Oct 14 2009 Gabriel L. Somlo  - 2.8-21
- convert language files and fix ncurses setup for utf-8, (bugzilla # 528279)


autotrust-0.3.1-2.fc12
----------------------
* Wed Oct 14 2009 Paul Wouters  - 0.3.1-1
- Updated to autotrust 0.3.1
- Try restarting running nameservers from the autotrust cron job
- Use the "named" version generated by dnssec-configure as trust anchor includes

* Wed Oct 14 2009 Paul Wouters  - 0.3.1-2
- bump for tag


avogadro-0.9.8-3.fc12
---------------------
* Tue Oct 20 2009 Rex Dieter  0.9.8-3
- rebuild (eigen2)


beanstalkd-1.4.2-1.fc12
-----------------------
* Sat Oct 17 2009 Jeremy Hinegardner  - 1.4.2-1
- update to upstream 1.4.2

* Sun Oct 11 2009 Jeremy Hinegardner  - 1.4-0
- update to upstream 1.4


bibletime-2.2-1.fc12
--------------------
* Wed Sep 30 2009 Deji Akingunola  - 2.2-1
- Update to 2.2


bibtex2html-1.94-1.fc12
-----------------------
* Fri Oct 02 2009 Guido Grazioli  - 1.94-1
- Upstream 1.94


boost-1.39.0-8.fc12
-------------------
* Thu Oct 15 2009 Petr Machata  - 1.39.0-8
- Package index.html in the -doc subpackage
- Resolves: #529030

* Wed Oct 14 2009 Petr Machata  - 1.39.0-7
- Several fixes to support PySide
- Resolves: #520087
- GCC 4.4 name resolution fixes for GIL
- Resolves: #526834


bullet-2.75-1.fc12
------------------
* Sat Oct 03 2009 Thomas Kowaliczek  - 2.75-1
- Updatet to new upstream version 2.75
- Updatet the patch file to work agian


cclive-0.5.2-1.fc12
-------------------
* Thu Oct 01 2009 Nicoleau Fabien  0.5.2-1
- Update to 0.5.2


chmsee-1.0.7-1.fc12
-------------------
* Wed Oct 07 2009 bbbush  - 1.0.7-1
- upstream release, fixed crash


classads-1.0.4-1.fc12
---------------------
* Thu Oct 08 2009  - 1.0.4-1
- Upgraded to 1.0.4 release


clive-2.2.7-1.fc12
------------------
* Thu Oct 01 2009 Nicoleau Fabien  2.2.7-1
- Update to 2.2.7


cluster-3.0.4-1.fc12
--------------------
* Wed Oct 21 2009 Fabio M. Di Nitto  - 3.0.4-1
- New upstream release
- spec file update:
  * explicitly Requires newer version of fence-agents

* Fri Oct 02 2009 Fabio M. Di Nitto  - 3.0.3-2
- spec file update:
  * gfs-pcmk now Requires dlm-pcmk


cluster-glue-1.0-0.11.b79635605337.hg.fc12
------------------------------------------
* Mon Oct 12 2009 Andrew Beekhof  - 1.0-0.10.b79635605337.hg
- Add install dependancy on perl-TimeDate for hb_report
- Update to upstream version b79635605337
  + Build: fix defines for pacemaker-pygui compatibility.
  + High: Tools: hb_report: log/events combining
  + High: doc: new README for wti_mpc
  + High: hb_report: add man page hb_report.8
  + High: hb_report: extract important events from the logs
  + High: stonith: external/ibmrsa-telnet: add support for later RSA cards
  + High: stonith: wti_mpc: support for MIB versions 1 and 3
  + Logd: Start/stop priorities are not created by configure
  + Med: sbd: Fix definition of size_t.
  + Med: sbd: Nodename comparison should be case insensitive (bnc#534445)
  + Med: wti_nps: add support for internet power switch model (bnc#539912)
  + Medium (LF 2194): LRM: fix return code on RA exec failure
  + Medium: Tools: hb_report: add -v option (debugging)
  + Medium: Tools: hb_report: options -C and -D are obsoleted
  + ha_logd: Fix a compile error/warning.
  + hb_report: report corosync packages too.
  + sbd: Accept -h (bnc#529574)
  + sbd: really fix the sector_size type.

* Mon Oct 12 2009 Andrew Beekhof  - 1.0-0.11.b79635605337.hg
- Fix botched tag


corosync-1.1.1-1.fc12
---------------------
* Wed Oct 21 2009 Fabio M. Di Nitto  - 1.1.1-1
- New upstream release


couchdb-0.10.0-2.fc12
---------------------
* Thu Oct 15 2009 Allisson Azevedo  0.10.0-1
- Update to 0.10.0.

* Thu Oct 15 2009 Allisson Azevedo  0.10.0-2
- Added patch to force init_enabled=true in configure.ac.

* Sun Oct 04 2009 Rahul Sundaram  0.9.1-2
- Change url. Fixes rhbz#525949


csound-5.10.1-13.fc12
---------------------
* Tue Oct 20 2009 Peter Robinson  - 5.10.1-13
- Fix use of multiple midi devices, fix segfault (RHBZ 529293)


cvs-1.11.23-8.fc12
------------------
* Fri Oct 16 2009 Jiri Moskovcak  1.11.13-8
- fixed install with --excludedocs rhbz#515981


cyphesis-0.5.21-1.fc12
----------------------
* Mon Oct 05 2009 Alexey Torkhov  - 0.5.21-1
- Update to 0.5.21


cyrus-imapd-2.3.15-3.fc12
-------------------------
* Fri Oct 09 2009 Michal Hlavinka  - 2.3.15-3
- fix cyrus user shell for db import (#528126)


dalston-0.1.10-2.fc12
---------------------
* Wed Oct 21 2009 Peter Robinson  0.1.10-1
- new upstream 0.1.10 release

* Wed Oct 21 2009 Peter Robinson  0.1.10-2
- update files list for new release


dbmail-2.2.11-10.fc12
---------------------
* Wed Oct 07 2009 Bernard Johnson  - 2.2.11-10
- add patch to keep from mangling mime parts (bz #527690)


dejagnu-1.4.4-16.fc12
---------------------
* Fri Oct 16 2009 Jiri Moskovcak  - 1.4.4-16
- fixed installation with --excludedocs rhbz#515949


dhcp-4.1.0p1-12.fc12
--------------------
* Tue Oct 13 2009 Jiri Popelka  - 12:4.1.0p1-12
- Fix 56dhclient so network comes back after suspend/hibernate (#527641)


docbook-utils-0.6.14-21.fc12
----------------------------
* Wed Oct 07 2009 Ondrej Vasik  0.6.14-21
- fix locale-based papersize selection (#527395)


dogtail-0.7.0-1.fc12
--------------------
* Thu Oct 08 2009 Zack Cerza  - 0.7.0-1
- New upstream release.
- Drop Requires on xorg-x11-server-Xvfb.
- Update URL and Source0.
- Ship NEWS file.


dovecot-1.2.6-4.fc12
--------------------
* Wed Oct 21 2009 Michal Hlavinka  - 1:1.2.6-4
- imap-login: If imap_capability is set, show it in the banner 
  instead of the default (#524485)

* Mon Oct 19 2009 Michal Hlavinka  - 1:1.2.6-3
- sieve updated to 0.1.13 which brings these changes:
- Body extension: implemented proper handling of the :raw transform
  and added various new tests to the test suite. However, :content
  "multipart" and :content "message/rfc822" are still not working.
- Fixed race condition occuring when multiple instances are saving the
  same binary (patch by Timo Sirainen).
- Body extension: don't give SKIP_BODY_BLOCK flag to message parser,
  we want the body!
- Fixed bugs in multiscript support; subsequent keep actions were not
  always merged correctly and implicit side effects were not always
  handled correctly.
- Fixed a segfault bug in the sieve-test tool occuring when compile
  fails.
- Fixed segfault bug in action procesing. It was triggered while
  merging side effects in duplicate actions.
- Fixed bug in the Sieve plugin that caused it to try to stat() a NULL
  path, yielding a 'Bad address' error.

* Fri Oct 09 2009 Michal Hlavinka  - 1:1.2.6-2
- fix init script for case when no action was specified

* Tue Oct 06 2009 Michal Hlavinka  - 1:1.2.6-1
- dovecot updated to 1.2.6
- Added authtest utility for doing passdb and userdb lookups.
- login: ssl_security string now also shows the used compression.
- quota: Don't crash with non-Maildir++ quota backend.
- imap proxy: Fixed crashing with some specific password characters.
- fixed broken dovecot --exec-mail.
- Avoid assert-crashing when two processes try to create index at the
  same time.


dvisvgm-0.8.6-1.fc12
--------------------
* Tue Oct 13 2009 Martin Gieseking  - 0.8.6-1
- updated to latest upstream release 0.8.6


e2fsprogs-1.41.9-5.fc12
-----------------------
* Mon Oct 19 2009 Eric Sandeen  1.41.9-5
- Allow superblock timestamp differences up to 24h (#522969)


easymock2-2.5-4.fc12
--------------------
* Wed Oct 21 2009 Alexander Kurtakov  2.5-4
- Fix empty jar. Bug #530110.


efte-1.1-1.fc12
---------------
* Sun Oct 11 2009 Jussi Lehtola  - 1.1-1
- Update to 1.1 which fixes a buffer overflow.


eigen2-2.0.6-1.fc12
-------------------
* Tue Oct 20 2009 Rex Dieter  1:2.0.6-1
- eigen-2.0.6


emesene-1.5.1-1.fc12
--------------------
* Fri Oct 16 2009 Allisson Azevedo  - 1.5.1-1
- Update to 1.5.1.


empathy-2.28.1-1.fc12
---------------------
* Mon Oct 19 2009 Brian Pepple  - 2.28.1-1
- Update to 2.28.1.
- Drop no-settings patch.  Fixed upstream.

* Sat Oct 17 2009 Matthias Clasen  - 2.28.0.1-3
- Include an upstream fix for a possible crash in the accounts dialog


environment-modules-3.2.7b-3.fc12
---------------------------------
* Mon Oct 19 2009 Orion Poplawski  - 3.2.7b-3
- Support different flavors of "sh" (bug #529493)


exaile-0.3.0.1-1.fc12
---------------------
* Wed Sep 30 2009 Deji Akingunola  - 0.3.0.1-1
- Update to 0.3.0.1


expendable-0.0.9-1.fc12
-----------------------
* Mon Oct 12 2009 Tim Waugh  0.0.9-1
- 0.0.9.


fedora-logos-12.0.1-1.fc12
--------------------------
* Wed Oct 21 2009 Tom "spot" Callaway  - 12.0.1-1
- Update to 12.0.1, switch to generic version of firstboot-left.png


fence-agents-3.0.4-1.fc12
-------------------------
* Wed Oct 21 2009 Fabio M. Di Nitto  - 3.0.4-1
- New upstream release
- BuildRequire libxslt and pexpect for automatic man page generation


findbugs-contrib-4.0.0-1.fc12
-----------------------------
* Mon Oct 05 2009 Jerry James  - 4.0.0-1
- Update to 4.0.0


fontpackages-1.28-1.fc12
------------------------
* Mon Oct 19 2009 Nicolas Mailhot 
- 1.28-1
? Rework repo-font-audit to also generate individual packager nagmails


fuse-encfs-1.5-10.fc12
----------------------
* Sat Oct 17 2009 Peter Lemenkov  1.5-10
- Added version in Requires for boost-devel


gcl-2.6.8-0.6.20090701cvs.fc12
------------------------------
* Tue Oct 20 2009 Jerry James  - 2.6.8-0.6.20090701cvs
- Update SELinux policy for confined users (bz 529757)

* Sun Sep 06 2009 Jerry James  - 2.6.8-0.5.20090701cvs
- Update SELinux files to give compiled maxima files the right context
- Drop SELinux compatibility kludge for early F-11 selinux-policy packages


gdb-7.0-2.fc12
--------------
* Mon Oct 19 2009 Jan Kratochvil  - 7.0-2
- Sync the .spec with RHEL/CentOS without EPEL, do not BuildRequires: fpc there.

* Wed Oct 07 2009 Jan Kratochvil  - 7.0-1
- Formal upgrade to the final FSF GDB release gdb-7.0.
- Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.
- archer-jankratochvil-fedora12 commit: ce4ead356654b951a49ca78d81ebfff95e758bf5


givaro-3.3.0-2.fc12
-------------------
* Fri Oct 09 2009 D Haley  - 3.3.0-1
- Update to 3.3.0
- Relicence per CeCILL-B

* Fri Oct 09 2009 D Haley  - 3.3.0-2
- Tag bump


gloox-1.0-0.9.rc3.SVNr4204.fc12
-------------------------------
* Mon Oct 19 2009 Pavel Alexeev  - 1.0-0.9.rc3.SVNr4204
- As right mentioned by Peter Lemenkov, my naming cheme is incorrect, fixing.
- Expand "beta" define and magick to more common "prerel".

* Sun Oct 18 2009 Pavel Alexeev  - 1.0rc3-0.7.SVNr4203
- rc3.
- Euroelessar (one of qutIM developer, thank you) submit patches:
	http://bugs.camaya.net/horde/whups/ticket/?id=110
	http://bugs.camaya.net/horde/whups/ticket/?id=155
	http://bugs.camaya.net/horde/whups/ticket/?id=154
	http://bugs.camaya.net/horde/whups/ticket/?id=153
	http://bugs.camaya.net/horde/whups/ticket/?id=152
	http://bugs.camaya.net/horde/whups/ticket/?id=151
	http://bugs.camaya.net/horde/whups/ticket/?id=150
	http://bugs.camaya.net/horde/whups/ticket/?id=149
	all is important and rev 4200 at least required.
- Include UPGRADING to %doc

* Sun Oct 18 2009 Pavel Alexeev  - 1.0rc3-0.8.SVNr4204
- New build due resolve my bugreport https://mail.camaya.net/horde/whups/ticket/?id=157


gmusicbrowser-1.0.2-1.fc12
--------------------------
* Sat Oct 03 2009 Remi Collet  - 1.0.2-1
- new upstream version


gnumeric-1.8.4-4.fc12
---------------------

goffice-0.6.6-4.fc12
--------------------
* Wed Oct 21 2009 Robert Scheck  - 0.6.6-4
- Applied 3 patches from the 0.6 branch (#503068, #505001)


gtk-vnc-0.3.10-1.fc12
---------------------
* Tue Oct 20 2009 Matthias Clasen  - 0.3.10-1
- Update to 0.3.10


gtk2-2.18.3-7.fc12
------------------
* Wed Oct 21 2009 Matthias Clasen  - 2.18.3-5
- Tweak tooltip appearance

* Wed Oct 21 2009 Matthias Clasen  - 2.18.3-6
- Hack around metacity compositor limitations

* Wed Oct 21 2009 Matthias Clasen  - 2.18.3-7
- Try to catch some nm-applet problems by rejecting requests to
  load icons at size 0


hamster-applet-2.28.1-1.fc12
----------------------------
* Tue Oct 20 2009 Mads Villadsen  - 2.28.1-1
- Update to latest upstream release


haproxy-1.3.22-1.fc12
---------------------
* Sat Oct 17 2009 Jeremy Hinegardner  - 1.3.22-2
- update to 1.3.22
- add logrotate configuration

* Mon Oct 12 2009 Jeremy Hinegardner  - 1.3.21-1
- update to 1.3.21

* Sun Oct 11 2009 Jeremy Hinegardner  - 1.3.20-1
- update to 1.3.20

* Sun Oct 11 2009 Jeremy Hinegardner  - 1.3.20-2
- relase bump


heartbeat-3.0.0-0.5.0daab7da36a8.hg.fc12
----------------------------------------
* Thu Oct 15 2009 Andrew Beekhof  - 3.0.0-0.5.0daab7da36a8.hg
- Resolve file conflict, shellfuncs is provided by resource-agents


highlight-2.13-1.fc12
---------------------
* Wed Oct 14 2009 Jochen Schmitt  2.13-1
- New upstream release


hugin-2009.2.0-1.fc12
---------------------
* Tue Oct 20 2009 Bruno Postle  2009.2.0-1
- 2009.2.0 release


ibus-1.2.0.20091014-2.fc12
--------------------------
* Wed Oct 14 2009 Peng Huang  - 1.2.0.2001014-2
- Update to 1.2.0.20091014
- Change ICON in ibus.conf


ibus-chewing-1.2.0.20091002-1.fc12
----------------------------------
* Mon Oct 05 2009 Ding-Yi Chen  - 1.2.0.20091002-1
- Bug 518901 - ibus-chewing would not work with locale zh_TW.Big
- Fix Google issue 501: ibus-chewing buffer doesn't get cleared when
toggling ibus on/off
- Fix Google issue 502: ibus-chewing: character selection window stays
behind when toggling ibus off- Use WM's revised ibus-chewing icon.
- Debug output now marked with levels.

* Wed Sep 30 2009 Peng Huang  - 1.2.0.20090917-2
- Rebuild with ibus-1.2.0


ibus-m17n-1.2.0.20090617-4.fc12
-------------------------------
* Wed Oct 14 2009 Peng Huang  - 1.2.0.20090617-4
- Update iok patch to fix build error.

* Tue Oct 13 2009 Parag  - 1.2.0.20090617-3
- Re-enable iok support to ibus-m17n.


ibus-qt-1.2.0.20091014-1.fc12
-----------------------------
* Wed Oct 14 2009 Peng Huang  - 1.2.0.20091014-1
- Update to 1.2.0.20091014.


ikiwiki-3.14159265-1.fc12
-------------------------
* Thu Oct 08 2009 Thomas Moschny  - 3.14159265-1
- Update to 3.14159265.


imake-1.0.2-11.fc12
-------------------
* Tue Oct 13 2009 Adam Jackson  1.0.2-11
- makedepend 1.0.2


inkscape-0.47-0.16.pre3.20091017svn.fc12
----------------------------------------

iptux-0.5.0-1.fc12
------------------
* Thu Oct 08 2009 Liang Suilong  0.5.0-1
- Upstream to 0.5.0


jakarta-commons-compress-1.0-1.fc12
-----------------------------------
* Fri Oct 16 2009 Sandro Mathys  - 1.0-1
- New version


kdeartwork-4.3.2-2.fc12
-----------------------
* Tue Oct 20 2009 Rex Dieter  - 4.3.2-2
- rebuild (eigen2)


kdeedu-4.3.2-2.fc12
-------------------
* Tue Oct 20 2009 Rex Dieter  - 4.3.2-2
- rebuild (eigen2)


kdeplasma-addons-4.3.2-4.fc12
-----------------------------
* Tue Oct 20 2009 Rex Dieter  - 4.3.2-4
- rebuild (eigen2)


kdesvn-1.4.1-1.fc12
-------------------
* Thu Oct 01 2009 Jaroslav Reznik  - 1.4.1-1
- Update to 1.4.1


klavaro-1.3.4-1.fc12
--------------------
* Sun Oct 18 2009 Fabian Affolter  - 1.3.4-1
- Updated to new upstream version 1.3.4

* Mon Oct 05 2009 Fabian Affolter  - 1.3.3-1
- Updated to new upstream version 1.3.3


krb5-auth-dialog-0.13-1.fc12
----------------------------
* Wed Oct 21 2009 Mat?j Cepl  - 0.13-1
- New upstream release (fixes #530001)


libX11-1.3-1.fc12
-----------------
* Tue Oct 06 2009 Peter Hutterer  1.3-1
- libX11 1.3


libXcomposite-0.4.1-2.fc12
--------------------------
* Tue Oct 13 2009 Adam Jackson  0.4.1-1
- libXcomposite 0.4.1

* Tue Oct 13 2009 Adam Jackson  0.4.1-2
- build fix


libXdamage-1.1.2-1.fc12
-----------------------
* Wed Oct 07 2009 Adam Jackson  1.1.2-1
- libXdamage 1.1.2


libXext-1.1-1.fc12
------------------
* Tue Oct 06 2009 Adam Jackson  1.1-1
- libXext 1.1


libXfixes-4.0.4-1.fc12
----------------------
* Tue Oct 13 2009 Adam Jackson  4.0.4-1
- libXfixes 4.0.4

* Thu Oct 08 2009 Parag  - 4.0.3-9
- Merge-Review #226071
- Removed XFree86-libs, xorg-x11-libs, XFree86-devel, xorg-x11-devel as Obsoletes
- Removed BR:pkgconfig
- spec cleanups


libXfont-1.4.1-1.fc12
---------------------
* Tue Oct 13 2009 Adam Jackson  1.4.1-1
- libXfont 1.4.1


libXi-1.3-1.fc12
----------------
* Tue Oct 06 2009 Peter Hutterer  1.3-1
- libXi 1.3


libXinerama-1.1-1.fc12
----------------------
* Tue Oct 06 2009 Adam Jackson  1.1-1
- libXinerama 1.1


libXpm-3.5.8-2.fc12
-------------------
* Tue Oct 13 2009 Adam Jackson  3.5.8-2
- libXpm 3.5.8


libXrender-0.9.5-1.fc12
-----------------------
* Tue Oct 06 2009 Adam Jackson  0.9.5-1
- libXrender 0.9.5


libXres-1.0.4-1.fc12
--------------------
* Tue Oct 13 2009 Adam Jackson  1.0.4-1
- libXres 1.0.4


libXt-1.0.7-1.fc12
------------------
* Tue Oct 13 2009 Adam Jackson  1.0.7-1
- libXt 1.0.7


libXv-1.0.5-1.fc12
------------------
* Wed Oct 07 2009 Adam Jackson  1.0.5-1
- libXv 1.0.5


libXxf86misc-1.0.2-1.fc12
-------------------------
* Tue Oct 13 2009 Adam Jackson  1.0.2-1
- libXxf86misc 1.0.2


libXxf86vm-1.1.0-1.fc12
-----------------------
* Wed Oct 07 2009 Adam Jackson  1.1.0-1
- libXxf86vm 1.1.0


libdmx-1.1.0-1.fc12
-------------------
* Wed Oct 07 2009 Adam Jackson  1.1.0-1
- libdmx 1.1.0


libguestfs-1.0.74-1.fc12
------------------------
* Tue Oct 20 2009 Richard W.M. Jones  - 1.0.74-1
- New upstream release 1.0.74.
- New API call: guestfs_find0.
- New tools: virt-ls, virt-tar.

* Wed Oct 14 2009 Richard W.M. Jones  - 1.0.73-1
- New upstream release 1.0.73.
- OCaml library now depends on xml-light.
- Deal with installed documentation.


libhugetlbfs-2.6-3.fc12
-----------------------
* Fri Oct 02 2009 Jarod Wilson  2.6-3
- Add hopefully-about-to-be-merged-upstream hugeadm enhancements
- Add huge pages setup helper script, using new hugeadm enhancements


libvirt-cim-0.5.7-1.fc12
------------------------
* Mon Oct 05 2009 Kaitlin Rupert  - 0.5.7-1
- Updated to latest upstream source


libxkbfile-1.0.6-1.1.fc12
-------------------------
* Wed Oct 07 2009 Adam Jackson  1.0.6-1
- libxkbfile 1.0.6


libxml2-2.7.6-1.fc12
--------------------
* Tue Oct 06 2009 Daniel Veillard  - 2.7.6-1
- Upstream release of 2.7.6
- restore thread support off by default in 2.7.5


mcpp-2.7.2-4.fc12
-----------------
* Tue Oct 13 2009 Mary Ellen Foster  2.7.2-4
- Incorporate patch from Ice upstream project


md5deep-3.4-1.fc12
------------------
* Sun Oct 18 2009 Paul P. Komkoff Jr  - 3.4-1
- new upstream version


memtest86+-4.00-2.fc12
----------------------
* Tue Oct 13 2009 Jarod Wilson  - 4.00-2
- Fix memtest-setup on systems without a separate /boot
  filesystem (#528651)


meshmagick-0.6.0-1.20090529svn2698.fc12
---------------------------------------
* Mon Oct 12 2009 Alexey Torkhov  - 0.6.0-1.20090529svn2698
- Update


midori-0.2.0-1.fc12
-------------------
* Tue Oct 20 2009 Peter Gordon  - 0.2.0-1
- Update to new upstream release (0.2.0): Drag-scroll on touchscreen devices,
  Speed Dial fixes, faster AdBlock (for all WebKitGTK+ versions), updated DNS
  and IDN handling, new form history extension, various bookmark and history
  fixes.


mkbootdisk-1.5.4-1.fc12
-----------------------
* Thu Oct 01 2009 Stepan Kasal  - 1.5.4-1
- syslinux image changed (#506181)


mod_fcgid-2.3.4-2.fc12
----------------------
* Wed Oct 21 2009 Paul Howarth  2.3.4-2
- Add fixes from upstream svn for a number of issues, most notably that the
  fixconf script had an error in the regexp, which resulted in a prefix of
  "FcgidFcgid" on the updated directives


mod_perlite-0.10-1.fc12
-----------------------
* Wed Oct 14 2009 Chris Weyl  0.10
- update to 0.10


module-init-tools-3.9-4.fc12
----------------------------
* Wed Oct 21 2009 Jon Masters  -3.9-4
- Update support for the sequencer interface.
- Resolves: #505421.

* Wed Sep 16 2009 Jon Masters  -3.9-3
- Sync weak-modules with RHEL.


mojito-0.21.4-2.fc12
--------------------
* Wed Oct 21 2009 Peter Robinson  0.21.4-1
- Update to 0.21.4

* Wed Oct 21 2009 Peter Robinson  0.21.4-2
- enable digg support


monitor-edid-2.4-1.fc12
-----------------------
* Sat Oct 17 2009 Remi Collet  2.4-1
- new version


mpop-1.0.18-1.fc12
------------------
* Mon Oct 12 2009 Fabian Affolter  - 1.0.18-1
- Updated to new upstream version 1.0.18


mrepo-0.8.6-5.fc12
------------------
* Sun Oct 18 2009 Jussi Lehtola  - 0.8.6-5
- Generalize webserver requirement.


nautilus-2.28.1-1.fc12
----------------------
* Wed Oct 21 2009 Tomas Bzatek  - 2.28.1-1
- Update to 2.28.1


netpbm-10.47.04-1.fc12
----------------------
* Wed Oct 21 2009 Jindrich Novy  10.47.04-1
- update to 10.47.04 (it is now stable) (#529525)
- fixes #502917, #482850, #482847


nfoview-1.8-1.fc12
------------------
* Sun Oct 18 2009 Fabian Affolter  - 1.8-1
- The icons need now hicolor-icon-theme
- Updated to new upstream version 1.8


ntp-4.2.4p7-7.fc12
------------------
* Wed Oct 21 2009 Miroslav Lichvar  4.2.4p7-7
- add ntp-wait man page (#526161)
- fix init scripts (#527987)


ocaml-curses-1.0.3-6.fc12.1
---------------------------
* Tue Oct 06 2009 Richard W.M. Jones  - 1.0.3-6.fc12.1
- Use ncursesw for wide character support.


ocfs2-tools-1.4.3-3.fc12
------------------------
* Fri Oct 09 2009 Fabio M. Di Nitto  - 1.4.3-3
- Explicitly BuildRequires: corosynclib-devel

* Wed Sep 30 2009 Fabio M. Di Nitto  - 1.4.3-1
- New upstream release.

* Wed Sep 30 2009 Fabio M. Di Nitto  - 1.4.3-2
- Fix -pcmk Requires.


octave-3.2.3-1.fc12
-------------------
* Tue Sep 29 2009 Orion Poplawski  - 6:3.2.3-1
- Update to 3.2.3
- Re-add make check


openscada-0.6.4-3.fc12
----------------------
* Wed Oct 21 2009 Peter Lemenkov  - 0.6.4-3
- Fixed the rest of broken deps introduced with new sub-packages.

* Fri Oct 16 2009 Aleksey Popkov  - 0.6.4-2
- Added of Obsoletes directive by Peter Lemenkov .

* Sun Oct 11 2009 Aleksey Popkov  - 0.6.4-1
- The change version for release 0.6.4
- Moved Ui-VCAEngine module to the self package
- Removed QTStarter module from the main package
- Added the virtual plc, server, visStation packages
- Some cosmetics
- Fixed somes bugs Peter Lemenkov .

* Sun Oct 04 2009 Aleksey Popkov  - 0.6.3.4-1
- Adding self module ICP_DAS
- Fixed Germany Language translations by Popkova Irina
- Delete openscada-0.6.3.3-openssl.patch from previouns version
- Adding the next version of the package.

* Tue Sep 01 2009 Aleksey Popkov  - 0.6.3.3-13
- Adding Requires for webcfg, webcfgd, webvision, http and snmp
- Some cosmetics.


openttd-0.7.3-1.fc12
--------------------
* Sat Oct 10 2009 Alexey Torkhov  - 0.7.3-1
- New upstream release 0.7.3


openttd-opengfx-0.1.1-2.fc12
----------------------------
* Sat Oct 10 2009 Alexey Torkhov  - 0.1.1-1
- New upstream release 0.1.1
- Check md5sums of resulting files

* Sat Oct 10 2009 Alexey Torkhov  - 0.1.1-2
- Correct generation of grfs, using nforenum


openwsman-2.2.0-1.fc12
----------------------
* Thu Oct 01 2009 Praveen K Paladugu  - 2.2.0-1
- Updated the sources to 2.2.0. Couple of major changes are as follows:
- Major changes:
- 	Adapt IANA ports of 5985 (http) and 5986 (https)
- 	Change the Ruby bindings module name to 'Openwsman'
- 	Change the Ruby plugin module name to 'Openwsman'
- 	IPv6 support (A_Venkatachalam at Dell.com)
- 	preliminary support for wbem intrinsic operations
-           'EnumerateClassNames' and 'GetClass' (kkaempf at suse.de)
-            (needs fixed sblim-sfcc, see www.openwsman.org for details)
-


pacemaker-1.0.5-3.fc12
----------------------
* Tue Oct 13 2009 Andrew Beekhof  - 1.0.5-3
- Update the tarball from upstream to version 38cd629e5c3c
  + High: Core: Bug lf#2169 - Allow dtd/schema validation to be disabled
  + High: PE: Bug lf#2106 - Not all anonymous clone children are restarted after configuration change
  + High: PE: Bug lf#2170 - stop-all-resources option had no effect
  + High: PE: Bug lf#2171 - Prevent groups from starting if they depend on a complex resource which can't
  + High: PE: Disable resource management if stonith-enabled=true and no stonith resources are defined
  + High: PE: Don't include master score if it would prevent allocation
  + High: ais: Avoid excessive load by checking for dead children every 1s (instead of 100ms)
  + High: ais: Bug rh#525589 - Prevent shutdown deadlocks when running on CoroSync
  + High: ais: Gracefully handle changes to the AIS nodeid
  + High: crmd: Bug bnc#527530 - Wait for the transition to complete before leaving S_TRANSITION_ENGINE
  + High: crmd: Prevent use-after-free with LOG_DEBUG_3
  + Medium: xml: Mask the "symmetrical" attribute on rsc_colocation constraints (bnc#540672)
  + Medium (bnc#520707): Tools: crm: new templates ocfs2 and clvm
  + Medium: Build: Invert the disable ais/heartbeat logic so that --without (ais|heartbeat) is available to rpmbuild
  + Medium: PE: Bug lf#2178 - Indicate unmanaged clones
  + Medium: PE: Bug lf#2180 - Include node information for all failed ops
  + Medium: PE: Bug lf#2189 - Incorrect error message when unpacking simple ordering constraint
  + Medium: PE: Correctly log resources that would like to start but can't
  + Medium: PE: Stop ptest from logging to syslog
  + Medium: ais: Include version details in plugin name
  + Medium: crmd: Requery the resource metadata after every start operation


perl-Data-Report-0.10-3.fc12
----------------------------
* Sun Oct 11 2009 Johan Vromans  0.10-3
- Remove Text::CSV_XS kludge now Text::CVS is packaged as well.


perl-HTTP-Server-Simple-0.41-1.fc12
-----------------------------------
* Tue Oct 13 2009 Ralf Cors?pius  - 0.41-1
- Upstream update.


perl-HTTP-Server-Simple-Mason-0.13-1.fc12
-----------------------------------------
* Tue Oct 13 2009 Ralf Cors?pius  - 0.13-1
- Upstream update.


perl-Net-OAuth-0.19-1.fc12
--------------------------
* Tue Oct 13 2009 Lubomir Rintel (Good Data)  - 0.19-1
- Update to 0.19, fixes security issue (2009.1)


php-Smarty-2.6.26-1.fc12
------------------------
* Sun Oct 11 2009 Christopher Stone  2.6.26-1
- Upstream sync
- Update %source0 and %URL


php-ezc-Archive-1.3.4-1.fc12
----------------------------
* Mon Oct 12 2009 Guillaume Kulakowski  - 1.3.4-1
- Update to 1.3.4


php-ezc-Authentication-1.3.1-1.fc12
-----------------------------------
* Mon Oct 12 2009 Guillaume Kulakowski  - 1.3.1-1
- Update to 1.3.1


php-ezc-Configuration-1.3.4-1.fc12
----------------------------------
* Mon Oct 12 2009 Guillaume Kulakowski  - 1.3.4-1
- Update to 1.3.4


php-ezc-SystemInformation-1.0.8-1.fc12
--------------------------------------
* Mon Oct 12 2009 Fedora Release Engineering  - 1.0.8-1
- Update to 1.0.8


php-ezc-Template-1.4.1-1.fc12
-----------------------------
* Mon Oct 12 2009 Guillaume Kulakowski  - 1.4.1-1
- Update to 1.4.1


php-ezc-Webdav-1.1.2-1.fc12
---------------------------
* Mon Oct 12 2009 Guillaume Kulakowski  - 1.1.2-1
- Update to 1.1.2


pidgin-2.6.3-2.fc12
-------------------
* Mon Oct 19 2009 Warren Togami  2.6.3-2
- Upstream backport:
    3abad7606f4a2dfd1903df796f33924b12509a56 msn_servconn_disconnect-crash


pidgin-musictracker-0.4.20-3.fc12
---------------------------------
* Tue Oct 13 2009 Jan Klepek  - 0.4.20-3
- fix for #528450

* Mon Oct 12 2009 Jan Klepek  0.4.20-2
- enabled debug package and honored RPM_OPT_FLAGS


pipestat-0.3.0-2.fc12
---------------------
* Wed Oct 21 2009 Steve 'Ashcrow' Milner  - 0.3.0-2
- Added setuptools as a requirement.


poker-engine-1.3.4-1.fc12
-------------------------
* Sun Oct 11 2009 Christopher Stone  1.3.4-1
- Upstream sync


poker-eval-136.0-1.fc12
-----------------------
* Sun Oct 11 2009 Christopher Stone  136.0-1
- Upstream sync
- Remove no longer needed exit patch
- Remove no longer needed gcc44 patch


postgresql-pgpool-II-2.2.5-1.fc12
---------------------------------
* Sun Oct 04 2009 Devrim Gunduz  2.2.5-1
- Update to 2.2.5, for various fixes described at 
  http://lists.pgfoundry.org/pipermail/pgpool-general/2009-October/002188.html

* Sat Oct 03 2009 Devrim Gunduz  2.2.4-1
- Update to 2.2.4
- Re-apply a fix for #442372


postgresql_autodoc-1.40-2.fc12
------------------------------
* Tue Oct 13 2009 - Devrim GUNDUZ  1.40-2
- Update to 1.40


powerman-2.3.5-2.fc12
---------------------
* Sat Oct 10 2009 Steven M. Parrish  - 2.3.5-2
- Fix multilib issue #509691


proftpd-1.3.2b-1.fc12
---------------------
* Wed Oct 21 2009 Paul Howarth  1.3.2b-1
- Update to 1.3.2b
  - Fixed regression causing command-line define options not to work (bug 3221)
  - Fixed improper SSL/TLS certificate subjectAltName verification (bug 3275)
  - Use correct cached user values with "SQLNegativeCache on" (bug 3282)
  - Fix slower transfers of multiple small files (bug 3284)
  - Support MaxTransfersPerHost, MaxTransfersPerUser properly (bug 3287)
  - Handle symlinks to directories with trailing slashes properly (bug 3297)
- Drop upstreamed defines patch (bug 3221)


protobuf-2.2.0-2.fc12
---------------------
* Wed Sep 30 2009 Lev Shamardin  - 2.2.0-2
- added export PTHREAD_LIBS="-lpthread"


pspp-0.6.2-1.fc12
-----------------
* Fri Oct 16 2009 Peter Lemenkov  0.6.2-1
- Ver. 0.6.2

* Sun Jul 26 2009 Fedora Release Engineering  - 0.6.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


publican-fedora-0.19-3.fc12
---------------------------
* Wed Oct 07 2009 R?diger Landmann  0.19-2
- Fix languages missing from 0.19-1 Makefile -- he-IL, nb-NO, nl-NL, sv-SE
- Tue Oct 6 2009 Maxim V. Dziumanenko 
- Update Fedora Feedback in Ukrainian

* Wed Oct 07 2009 R?diger Landmann  0.19-3
- Fix date in 0.19-2 changelog
- Update Fedora Feedback in Polish Piotr Dr?g 

* Mon Oct 05 2009 R?diger Landmann  0.19-1
- Update Legal Notice for CC-BY-SA-3.0 Unported, plus other tweaks per Red Hat legal
- Add Fedora logos with correct trademarks. BZ #492041
- Sat Oct 3 2009 Maxim V. Dziumanenko 
- Translate Fedora Feedback into Ukrainian
- Fri Sep 4 2009 Ville-Pekka Vainio 
- Translate Fedora Feedback into Finnish
- Sun Aug 9 2009 Josip ?ume?ki 
- Translate Fedora Feedback into Croatian
- Sun Aug 9 2009 Robert Buj 
- Translate Fedora Feedback into Catalan
- Sun Jun 15 2009 Sindre Wetjen 
- Translate Fedora Feedback into Norwegian (Bokm?l)
- Fri Jun 05 2009 Oron Peled 
- Translate Fedora Feedback into Hebrew
- Thu Jun 04 2009 Jurijs Kolomijecs 
- Translate Fedora Feedback into Latvian
- Mon May 25 2009 Nikola ?tohanzl 
- Translate Fedora Feedback into Czech
- Sun May 10 2009 Pavol ?imo 
- Translate Fedora Feedback into Slovak 
- Fri May 08 2009 Arnes Arnautovi? 
- Translate Fedora Feedback into Bosnian
- Sun Apr 19 2009 Manatsawin Hanmongkolchai 
- Translate Fedora Feedback into Thai
- Thu Apr 16 2009 Sveinn ? Felli 
- Translate Fedora Feedback into Icelandic
- Wed Apr 08 2009 Sulyok Peti 
- Translate Fedora Feedback into Hungarian
- Mon Mar 23 2009 G?ran Uddeborg 
- Translate Fedora Feedback into Swedish
- Fri Mar 20 2009  Noriko Mizumoto  
- Update Fedora Feedback in Japanese
- Thu Mar 19 2009 Kris Thomsen 
- Translate Fedora Feedback into Danish
- Fri Mar 13 2009  Jeff Fearn  
- Fix right to left fo ar-AR. BZ #486162
- Patches and translations by Muayyad Alsadi  
- Tue Mar 10 2009 Alexey Vasyukov 
- Translate Fedora Feedback into Russian


purple-microblog-0.2.4-3.fc12
-----------------------------
* Mon Oct 19 2009 Rahul Sundaram  - 0.2.4-2
- Change the description to be more readable. Fixes rhbz#529558
- Clean up the spec a bit

* Mon Oct 19 2009 Ismael Olea  - 0.2.4-3
- removing useless electric-fence BR


pypoker-eval-137.0-1.fc12
-------------------------
* Sun Oct 11 2009 Christopher Stone  137.0-1
- Upstream sync


pyserial-2.4-1.fc12
-------------------
* Sun Oct 18 2009 Paul P Komkoff Jr  - 2.4-1
- new upstream version


python-biopython-1.52-1.fc12
----------------------------
* Thu Oct 15 2009 Alex Lancaster  - 1.52-1
- Update to latest upstream (1.52)


python-epdb-0.11-4.fc12
-----------------------
* Wed Oct 21 2009 Justin M. Forbes  - 0.11-4
- Allow the number of frames to be passed for telnet sessions.


python-fedora-0.3.16-1.fc12.1
-----------------------------
* Wed Oct 21 2009 Toshio Kuratomi  - 0.3.16-1
- New release 0.3.16.

* Wed Oct 21 2009 Toshio Kuratomi  - 0.3.16-1.1
- Forgot to refresh the common dir.


python-psycopg2-2.0.13-1.fc12
-----------------------------
* Sun Oct 18 2009 Devrim GUNDUZ  - 2.0.13-1
- Update to 2.0.13

* Fri Aug 14 2009 Devrim GUNDUZ  - 2.0.12-1
- Update to 2.0.12


python-toscawidgets-0.9.8-1.fc12
--------------------------------
* Thu Oct 01 2009 Luke Macken  - 0.9.8-1
- 0.9.8 release
- Remove js patch which is now upstream

* Thu Aug 27 2009 Luke Macken  - 0.9.8-0.4.dev20090825
- Apply a patch from http://toscawidgets.org/trac/tw/ticket/30
  to fix problems with encoding javascript methods.

* Tue Aug 25 2009 Luke Macken  - 0.9.8-0.3.dev20090825
- Update to the latest mercurial snapshot, which fixes the python 2.4
  incompatibilites.

* Mon Aug 24 2009 Luke Macken  - 0.9.8-0.2.dev20090822
- Add a couple of patches to get things working on Python2.4

* Sat Aug 22 2009 Luke Macken  - 0.9.8-0.1.dev20090822
- Update to a 0.9.8 development snapshot

* Wed Aug 12 2009 Luke Macken  - 0.9.7.2-1
- 0.9.7.2


redhat-lsb-3.2-6.fc12
---------------------
* Wed Oct 21 2009 Tom "spot" Callaway  - 3.2-6
- apply fix from bz485367 (thanks to Jon Thomas)


resource-agents-3.0.4-1.fc12
----------------------------
* Wed Oct 21 2009 Fabio M. Di Nitto  - 3.0.4-1
- New rgmanager resource agents upstream release

* Mon Oct 12 2009 Andrew Beekhof  - 3.0.3-3
- Update Pacameker agents to upstream version: 099c0e5d80db
  + Add the ha_parameter function back into .ocf-shellfuncs.
  + Bug bnc#534803 - Provide a default for MAILCMD
  + Fix use of undefined macro @HA_NOARCHDATAHBDIR@
  + High (LF 2138): IPsrcaddr: replace 0/0 with proper ip prefix (thanks to Michael Ricordeau and Michael Schwartzkopff)
  + Import shellfuncs from heartbeat as badly written RAs use it
  + Medium (LF 2173): nfsserver: exit properly in nfsserver_validate
  + Medium: RA: Filesystem: implement monitor operation
  + Medium: RA: VirtualDomain: loop on status if libvirtd is unreachable
  + Medium: RA: VirtualDomain: loop on status if libvirtd is unreachable (addendum)
  + Medium: RA: iSCSILogicalUnit: use a 16-byte default SCSI ID
  + Medium: RA: iSCSITarget: be more persistent deleting targets on stop
  + Medium: RA: portblock: add per-IP filtering capability
  + Medium: mysql-proxy: log_level and keepalive parameters
  + Medium: oracle: drop spurious output from sqlplus
  + RA: Filesystem: allow configuring smbfs mounts as clones


rgmanager-3.0.4-1.fc12
----------------------
* Wed Oct 21 2009 Fabio M. Di Nitto  - 3.0.4-1
- New upstream release


rhn-client-tools-0.7.4-1.fc12
-----------------------------
* Mon Oct 05 2009 Miroslav Such?  0.7.4-1
- add versioned conflict to up2date


roundup-1.4.10-1.fc12
---------------------
* Sun Oct 18 2009 Paul P. Komkoff Jr  - 1.4.10-1
- new upstream version


rt3-3.8.4-6.fc12
----------------
* Tue Oct 13 2009 Ralf Cors?pius  - 3.8.4-6
- Update rt-3.8.4-rh-bz526870.diff.

* Mon Oct 12 2009 Ralf Cors?pius  - 3.8.4-4
- Add rt-3.8.4-rh-bz526870.diff (BZ #526870).

* Mon Oct 12 2009 Ralf Cors?pius  - 3.8.4-5
- Bump Release:.


sahana-0.6.2.2-6.fc12
---------------------
* Wed Oct 21 2009 David Nalley  0.6.2.2-6
- fixed security issue noted in bz 530255


sblim-cmpi-devel-2.0.0-2.fc12
-----------------------------
* Wed Oct 07 2009 Praveen K Paladugu  - 2.0.0-2
- CmpiData_constructor_4_CmpiString: This patch allows providers to convert
-   CMPIData to String. The conversion of retrieving string info from CMPIData was wrong.
-   This patch fixes the conversion.


sblim-sfcb-1.3.4-9.fc12
-----------------------
* Wed Sep 30 2009 - 1.3.4-9
- LocalInterfaceInvokeMethodFix: CHARS and string were handled the same.
-  They are differentiated in this patch.
- destroyThreadKey: Local sfcb connect was creating thread specific data
-  associating a key to it. This won't get deleted resulting in crash
-  of opwsman, sfcc and sfcb. This patch deletes that data.


sblim-sfcc-2.1.0-3.fc12
-----------------------
* Fri Oct 02 2009 Praveen K Paladugu  - 2.1.0-3
- Added a patch to prevent crash because of uninitialized structrues.


sdparm-1.04-1.fc12
------------------
* Wed Oct 14 2009 Dan Hor?k  - 1.04-1
- 1.04


seamonkey-2.0-6.fc12
--------------------
* Wed Oct 21 2009 Martin Stransky  2.0-6
- Fixed launcher script

* Mon Oct 19 2009 Martin Stransky  2.0-5
- Update to 2.0 RC2

* Tue Oct 13 2009 Martin Stransky  2.0-4
- Update to 2.0 RC1


sec-2.5.2-1.fc12
----------------
* Tue Sep 29 2009 Stefan Schulze Frielinghaus  - 2.5.2-1
- New upstream release
- SPEC file cleanup
- Init script cleanup
- Removed some examples because of licensing issues. Upstream has clarified
  and changed most of the license tags to GPLv2. Additionally, upstream
  will include the examples in the next release.
- Removed a provide statement since a period was in the name and no other
  package required that special name.


sed-4.2.1-4.fc12
----------------
* Fri Oct 16 2009 Jiri Moskovcak  4.2.1-4
- added libselinux-devel to buildrequires rhbz#514182
- fixed problem with --excludedocs rhbz#515913

* Tue Aug 11 2009 Ville Skytt?  - 4.2.1-3
- Use bzipped upstream tarball.


setuptool-1.19.9-1.fc12
-----------------------
* Wed Oct 21 2009 Michal Hlavinka  1.19.9-1
- update path of firewall configuration tool (#529794)
- update translations

* Mon Oct 12 2009 Michal Hlavinka  1.19.8-1
- add setup.1 man page
- update translations

* Mon Sep 14 2009 Michal Hlavinka  - 1.19.7-1
- relase with updated translations


smartmontools-5.38-21.fc12
--------------------------
* Mon Oct 12 2009 Michal Hlavinka  - 1:5.38-21
- warn about disabled mail only if capabilities are enabled

* Fri Oct 09 2009 Michal Hlavinka  - 1:5.38-19
- make init script lsb compliant (#528016)

* Fri Oct 09 2009 Michal Hlavinka  - 1:5.38-20
- fix init script for case when no action was specified

* Fri Oct 09 2009 Michal Hlavinka  - 1:5.38-20.1
- fix apostrophes around shell variable

* Mon Oct 05 2009 Michal Hlaivnka  - 1:5.38-17
- make capabilities optional
- fix capabilities for 3ware contollers (#526626)

* Mon Oct 05 2009 Michal Hlavinka  - 1:5.38-18
- bump release for rebuild


snownews-1.5.12-1.fc12
----------------------
* Wed Oct 07 2009 Zing  - 1.5.12-1
- Bug fixes + openssl added as a requirement
- Corrected two crashes when using mark unread and open URL on
  non-existent items.
- Use OpenSSL for MD5 calculations and remove all old MD5 code.
- Fix 64bit digest calc. Readstatus wasn't remembered on 64bit versions.


sparse-0.4.2-1.fc12
-------------------
* Sun Oct 18 2009 Jeff Layton  - 0.4.2
- Update to 0.4.2

* Tue Sep 29 2009 Jeff Layton  - 0.4.2rc1-1
- Update to 0.4.2rc1


springlobby-0.27-1.fc12
-----------------------
* Sun Oct 11 2009 Aurelien Bompard  -  0.27-1
- version 0.27


systemtap-1.0-2.fc12
--------------------
* Wed Oct 21 2009 Josh Stone  - 1.0-2
- Fix three --unprivileged DOS issues (CVE-2009-2911)


tesseract-2.04-1.fc12
---------------------
* Wed Oct 21 2009 Karol Trzcionka  - 2.04-1
- Update to v2.04
- Add static libraries to -devel subpackage


texlive-2007-45.fc12
--------------------
* Thu Oct 15 2009 Jindrich Novy  2007-45
- make kpathsea not dependent on texlive
- fix lacheck again (#451513)
- fix dvips configuration (#467542)
- update kpathsea description and summary (#519257)
- use upstream patch to fix pool overflow CVE-2009-1284 (#492136)
- don't complain if the pdvipsk hunks touching config.ps don't apply


texlive-texmf-2007-31.fc12
--------------------------
* Tue Oct 20 2009 Jindrich Novy  2007-31
- do not conflict with dvipdfm
- update perl requires filter
- update latin.ldf (#469948)
- do not provide any perl dependencies (#516350)


tgif-4.2.1-1.fc12
-----------------
* Thu Oct 15 2009 Mamoru Tasaka  - 4.2.1-1
- Bug fix release 4.2.1

* Thu Oct 08 2009 Mamoru Tasaka  - 4.2-1
- Update to 4.2
  * Almost all patches/sources/etc in Fedora rpms (actually borrowed
    from Vine Project) were applied upstream
  * Stop to apply 1 left patch for now
  * 1 patch does not apply, check later


tinyproxy-1.6.5-1.fc12
----------------------
* Sun Oct 11 2009 Jeremy Hinegardner  - 1.6.5-1
- update to upstream 1.6.5


tokyocabinet-1.4.33-1.fc12
--------------------------
* Wed Sep 30 2009 Deji Akingunola  - 1.4.33-1
- Update to 1.4.33


tucan-0.3.9-0.1.alpha.fc12
--------------------------
* Sat Oct 17 2009 Simon Wesp  - 0.3.9-0.1.alpha
- New upstream release


tzdata-2009o-2.fc12
-------------------
* Wed Oct 21 2009 Petr Machata  - 2009o-2
- San Luis (Argentina) entered DST on October 11 (tzdata-2009o-argentinas.patch)

* Mon Oct 19 2009 Petr Machata  - 2009o-1
- Upstream 2009o
  - Bangladesh won't go back to Standard Time from October 1, 2009
  - Pakistan leaves DST on October 1, 2009
- Dropped tzdata-2009m-karachi.patch
- Argentina does not enter DST on October 18 (tzdata-2009o-argentinas.patch)


uget-1.5.0-1.fc12
-----------------
* Fri Oct 02 2009 Mamoru Tasaka  - 1.5.0
- 1.5.0


unbound-1.3.4-2.fc12
--------------------
* Thu Oct 08 2009 Paul Wouters  - 1.3.4-2
- Security update to 1.3.4 fixes NSEC3 processing


uncrustify-0.54-1.fc12
----------------------
* Sat Oct 17 2009 Neal Becker  - 0.54-1
- Update to 0.54


unuran-1.4.1-1.fc12
-------------------
* Sat Oct 17 2009 Neal Becker  - 1.4.1-1
- Update to 1.4.1


urlwatch-1.9-1.fc12
-------------------
* Sat Oct 10 2009 Fabian Affolter  - 1.9-1
- Added patch for xmpp functionality
- Updated to new upstream version 1.9


valide-0.5.1-0.20.20091019svn425.fc12
-------------------------------------
* Mon Oct 19 2009 Jonathan MERCIER  0.5.1-0.18.20091019svn425
- Update valide to revision 425
- Some bug fix

* Mon Oct 19 2009 Jonathan MERCIER  0.5.1-0.19.20091019svn425
- Bug fix

* Mon Oct 19 2009 Jonathan MERCIER  0.5.1-0.20.20091019svn425
- Bug fix

* Tue Sep 01 2009 Jonathan MERCIER  0.5.1-0.17.20090825svn385
- Update valide to revision 385
- Some bug fix


vhostmd-0.4-0.5.gite9db007b.fc12
--------------------------------
* Fri Oct 16 2009 Richard W.M. Jones  - 0.4-0.5.gite9db007b
- New upstream based on git e9db007b.
- Fix segfault in vm-dump-metrics (RHBZ#529348).
- On error, vm-dump-metrics now exits with status code 1.


virt-top-1.0.4-1.fc12.1
-----------------------
* Tue Oct 06 2009 Richard W.M. Jones  - 1.0.4-1.fc12.1
- New upstream release 1.0.4.
- Includes new translations (RHBZ#493799).
- Overall hardware memory is now displayed in CSV file (RHBZ#521785).
- Several fixes to Japanese support (RHBZ#508197).
- Japanese PO file also has bogus plural forms.
- Additional BR on gettext (for msgfmt).


voms-1.9.14.2-1.fc12
--------------------
* Tue Oct 20 2009 Mattias Ellert  - 1.9.14.2-1
- Upstream 1.9.14.2 (CVS tag glite-security-voms_R_1_9_14_2)


vrq-1.0.62-1.fc12
-----------------
* Thu Oct 15 2009 Shakthi Kannan  - 1.0.62-1
- Updated to upstream package 1.0.62

* Sat Oct 10 2009 Shakthi Kannan  - 1.0.61-1
- Updated to upstream package 1.0.61


wordpress-2.8.5-1.fc12
----------------------
* Wed Oct 21 2009 Adrian Reber  - 2.8.5-1
- updated to 2.8.5 (Hardening Release)


xfce4-panel-4.6.2-1.fc12
------------------------
* Fri Oct 16 2009 Christoph Wickert  - 4.6.2-1
- Update to 4.6.2
- Drop explicit requires on Terminal and mousepad


xorg-x11-apps-7.4-8.fc12
------------------------
* Tue Oct 13 2009 Peter Hutterer  7.4-8
- xinput 1.5.0
- xwud 1.0.2
- xkill 1.0.2
- xmag 1.0.3

* Wed Oct 07 2009 Adam Jackson  7.4-7
- xeyes 1.0.991

* Tue Oct 06 2009 Adam Jackson  7.4-6
- luit 1.0.4


xorg-x11-drv-openchrome-0.2.904-1.fc12
--------------------------------------
* Tue Oct 13 2009 Adam Jackson  0.2.904-1
- openchrome 0.2.904


xorg-x11-font-utils-7.2-10.fc12
-------------------------------
* Tue Oct 13 2009 Adam Jackson  7.2-10
- mkfontscale 1.0.7
- mkfontdir 1.0.5


xorg-x11-proto-devel-7.4-34.fc12
--------------------------------
* Tue Oct 13 2009 Adam Jackson  7.4-34
- kbproto 1.0.4
- xf86miscproto 0.9.3
- xproxymanagementprotocol 1.0.3

* Tue Oct 06 2009 Peter Hutterer  7.4-32
- compositeproto 0.4.1
- xf86dgaproto 2.1
- dmxproto 2.3
- inputproto 2.0
- fixesproto 4.1.1
- randrproto 1.3.1
- recordproto 1.14
- xf86vidmodeproto 2.3
- xineramaproto 1.2
- xproto 7.0.16

* Tue Oct 06 2009 Peter Hutterer  7.4-33
- Upload xf86dgaproto 2.1 tarball, this time for real.


xorg-x11-server-utils-7.4-13.fc12
---------------------------------
* Tue Oct 13 2009 Adam Jackson  7.4-13
- iceauth 1.0.3
- sessreg 1.0.5
- xmodmap 1.0.4
- xrdb 1.0.6


xorg-x11-utils-7.4-7.fc12
-------------------------
* Tue Oct 13 2009 Adam Jackson  7.4-7
- xev 1.0.4
- xlsatoms 1.0.2
- xprop 1.1.0
- xwininfo 1.0.5


xorg-x11-xkb-utils-7.4-6.fc12
-----------------------------
* Wed Oct 07 2009 Adam Jackson  7.4-6
- xkbcomp 1.1.1


xournal-0.4.5-1.fc12
--------------------
* Mon Oct 05 2009 Rick L Vinyard Jr  0.4.5-1
- New upstream release
- Removed xournal.xml, xournal.desktop and x-xoj.desktop sources as they are now in upstream source
- Updated gtk2 devel requirements to 2.10
- Added poppler-glib-devel to BR
- Added gettext BR
- Updated summary


yaz-3.0.49-1.fc12
-----------------
* Thu Oct 01 2009 Guido Grazioli  - 3.0.49-1
- Upstream 3.0.49 (bugfixes and feature enhancements)
- Require pkgconfig for libyaz-devel (guidelines MUST)


youtube-dl-2009.09.13-2.fc12
----------------------------
* Fri Oct 09 2009 Rafa? Psota  - 2009.09.13-2
- Small fix in %prep

* Sun Sep 27 2009 Rafa? Psota  - 2009.09.13-1
- Update to 2009.09.13
- License change to Public Domain


ytree-1.93-1.fc12
-----------------
* Sun Aug 30 2009 Minto Joseph  - 1.93-1
- Rebased to 1.93


yum-cron-0.9.1-1.fc12
---------------------
* Fri Oct 09 2009 Alec Habig  - 0.9.1-1
- Fixed CLEANDAY default in script
- changed the /etc/yum/ scripts to not be marked as a config file in
  the .spec - we always want them updated, they're code not config.  
  rpmlint used to complain about them not being marked as config files,
  but seems to have grown out of this weirdness in the meantime .

* Tue Oct 06 2009 Alec Habig  - 0.9.0-1
- Change cron file to 0yum.cron, so yum updates things before the other daily jobs
  such as makewhatis, prelink, updatedb, etc run.  That way updated files get picked up
  properly.  Cost - those jobs will run later.  Resolves bug 445894.  Changed default
  random delay to 60 minutes from 120 to reduce the cost.
- Eliminate the weekly package cleaning script.  Replace with logic in the daily script 
  to clean the packages and the metadata once per week (otherwise corrupted metadata messes 
  things up indefinitely).  Resolves bug 526452.  Removal of seperate weekly script resolves
  bug 524461. 
- Use find to clear stale locks at start of run, so add findutils req.


yumex-2.9.3-1.fc12
------------------
* Wed Sep 30 2009 Tim Lauridsen  - 2.9.2-1
- bumped version to 2.9.2-1


zyx-liveinstaller-0.1.14-1.fc12
-------------------------------
* Sun Oct 18 2009 Sebastian Dziallas  - 0.1.14-1
- update to new upstream release
- adjust source url

* Sat Oct 10 2009 Sebastian Dziallas  - 0.1.13-1
- update to new upstream release


Summary:
Added Packages: 81
Removed Packages: 1
Modified Packages: 214



From swhiteho at redhat.com  Thu Oct 22 13:14:37 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Thu, 22 Oct 2009 14:14:37 +0100
Subject: Orphan Package: system-config-cluster (was Re: Simplify
 non-responsive maintainers policy Part 2)
In-Reply-To: <20091021181022.GA7460@clingman.lan>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
Message-ID: <1256217277.6052.668.camel@localhost.localdomain>

Hi,

On Wed, 2009-10-21 at 11:10 -0700, Toshio Kuratomi wrote:
> On Wed, Oct 21, 2009 at 10:11:37AM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > Jim Parsons left Red Hat a little while back and the only contact
> > details I have is his Red Hat email address, which is of course no
> > longer valid. I've opened a bugzilla #530027 as per the unresponsive
> > maintainer procedure, but I was hoping to be able to skip the section
> > regarding sending of messages since there seems little point sending to
> > an email address which I know (and which other Red Hat employees can
> > easily verify) will not be answered.
> > 
> > Instead I've emailed the one other person who had access to that package
> > and that has also gone unanswered (see the bugzilla).
> > 
> > There are a number of outstanding bugs filed against
> > system-config-cluster (including the fact that it seems that it has not
> > passed an initial review) which I've listed out in the bugzilla.
> > 
> > I would like to either fix (or preferably just remove) this package as
> > it creates configs for GFS2 which are incorrect and is thus causing
> > confusion to all who attempt to use it.
> > 
> > Therefore this is my formal request to become maintainer of this
> > package,
> > 
> I've talked to FESCo people on IRC and after some discussion I've gone ahead
> and reassigned ownership.  Since people seem to like this, if you don't want
> to maintain and fix this package, please go through the orphan process
> rather than just retiring it.
> 
Ok. Thanks, I'll do my best to do the right thing here...

To clarify some issues which came up during the discussions here, which
have also been discussed by the cluster team, here are a few more notes
on the topic.

system-config-cluster is currently dead as an upstream project. If
someone wants to take over the fedora package, then they will first have
to take over the upstream side of things too.

According to the instructions on the wiki, the correct procedure for
such packages is to retire them rather than orphan them (as per
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers) although confusingly that page doesn't either point to or describe the retiring process (it seems to be only mentioned here: https://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife so far as I can see).

Now taking into account the comments above, what I propose is to have a
period of time in which we see if someone else will take on the package,
and if not, I'll retire it.

So here, for the first time of asking, is a request to see if anybody
will take on the upstream maintenance of system-config-cluster.

I have also discovered some further information about Conga (the
preferred solution to GUI cluster configuration) and why it is now
preferred. Some time ago an investigation was undertaken to try and
gauge the usage of s-c-c and Conga and it was found that Conga had a
larger user base. It also seemed that maintaining two tools to perform
(largely) the same job was not a sensible use of development & test
time.

Now there were also some comments about Conga relating to the more
complicated set up, however the Conga team have actively been working on
solving some of those issues and the latest versions are (I understand)
improved in this area. The team however are actively looking for further
suggestions, so if anybody has any ideas, please open a bugzilla against
Conga and let them know.

So I hope that goes some way towards addressing the concerns of people
who are worried about the loss of this system-config-cluster package.

Lastly, thanks for helping me sort out all the issues surrounding this
package. It is very much appreciated,

Steve.




From clumens at redhat.com  Thu Oct 22 13:20:49 2009
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 22 Oct 2009 09:20:49 -0400
Subject: F12 media-less installer totally broken
In-Reply-To: <3da3b5b40910211455y721b1e77h9bfa9682e1a507d5@mail.gmail.com>
References: <3da3b5b40910211455y721b1e77h9bfa9682e1a507d5@mail.gmail.com>
Message-ID: <20091022132049.GL30518@localhost.localdomain>

> - Put the iso on a ntfs partition
> - Put the vmlinuz+initrd.img in F11's grub .. and boot into the installer,
> pointing it to install from HDD
> - The installer cannot pickup the iso

Yeah this probably won't work because of the NTFSness, but what's the
exact error message?  What does the log on tty3 look like?

> - As an alternate I copied the iso to a server, and NFS shared its folder
> - I reboot the installer, point it to nfs .. again it fails to start
> anaconda

What's the exact error message?  What's the log on tty3 look like?

> - Third trial .. on that server I loop mount the iso on /opt and NFS share
> that
> - Boot installer, it tried to mount server:/opt/images (which fails!) (only
> /opt is shared)

What, like you're not exporting the subtree?  You need to do that -
anaconda needs to access /images/install.img to be able to
proceed.  Again, what's the log on tty3 look like?

> - Fourth trial: I expand the iso image completely on disk into a new
> directory, boot into the installer pointing it at that
> - Installer finally picks up, anaconda starts .. I click next a few times,
> partition and format my disk, then an error message mentions "cannot load
> image #1, please insert the CD and try again" ... arrgh

Yet again, what do the log files look like?  Show me /tmp/anaconda.log,
/tmp/storage.log, and /tmp/syslog.

- Chris



From jhorak at redhat.com  Thu Oct 22 13:21:19 2009
From: jhorak at redhat.com (Jan Horak)
Date: Thu, 22 Oct 2009 15:21:19 +0200
Subject: Upload debug-like-info to Mozilla servers every update
In-Reply-To: 
References: <4AB3862F.4040207@redhat.com>		<4AD5CC6D.3070104@redhat.com>
	
Message-ID: <4AE05C4F.7000500@redhat.com>

On 10/14/2009 03:40 PM, Colin Walters wrote:
> On Wed, Oct 14, 2009 at 9:04 AM, Jan Horak  wrote:
>    
>>
>> Mozilla prefers using their own system in this case. It has some pros, like
>> user don't have to download debug packages (which is approx 80MB for each
>> package). Building the symbols for Mozilla is also quite easy. They have
>> everything prepared in their makefiles and their debug info is just one zip
>> file. All we need is to put this zip file somewhere that mozilla could pull
>> it (or we push it after package is released). This zip file should be left
>> aside from regular rpm package (read unpublished).
>>      
> In that case I'd just make the mozilla spec file to put the .zip in
> the -debuginfo package.  Then their crash handling code just needs to
> get the built RPM NVRA (it should probably be compiled in, but forking
> a "rpm -q" could work I guess), and their server side can fairly
> easily script a "wget
> http://download.fedoraproject.org/.../mozilla-debuginfo-12345.rpm".
>
>    
After more discussion on Mozilla bugzilla the Mozilla would prefer to 
give us an account to their crash-stat system and let us upload the 
mentioned zip file after each released update. The scp is used to upload 
debug symbols. However this require storage of private key which 
shouldn't be exposed to public. Is there any way to launch such 
operation and also keep the private key unpublished? I can provide 
complete script which will extract zip file from rpm files and upload 
them to Mozilla by using scp.
-- 
Jan



From lyos.gemininorezel at gmail.com  Thu Oct 22 13:25:06 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Thu, 22 Oct 2009 09:25:06 -0400
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <19965.1256162829@sss.pgh.pa.us>
References: <1256116297.2716.10.camel@localhost.localdomain>	<20091021181022.GA7460@clingman.lan>
	<4ADF56C8.3060602@gmail.com> <19965.1256162829@sss.pgh.pa.us>
Message-ID: <4AE05D32.8090504@gmail.com>

On 10/21/2009 06:07 PM, Tom Lane wrote:
> Lyos Gemini Norezel  writes:
>    
>> Why not just require a secondary email address?
>>      
> "Require" a secondary email address?  Not everyone has one, or wants
> to hand it over if they do.

In this day and age? It's highly unusual for people to only have one.
However, for those few who don't/don't want to 'hand it over'... we can 
require a
phone number, street address, or other such contact info. This would 
guarantee
one avenue of contact.

Another alternative... would be to include a 'waiver' of sorts... for 
those who really
insist... that would allow fedora/fedora volunteers to immediately 
orphan any and all
packages maintained by said packager *THE INSTANT* an email is declared 
defunct,
and/or the maintainer is unresponsive for more than a month or so.



>    That sounds more like a recipe for driving
> maintainers away than making sure you can contact them.
>
>    

Those that value privacy/invisibility over Fedora's goal/values/etc... sure.

If a maintainer is not willing to give an alternative means of contact, 
then why should
Fedora care whether or not a maintainer will lose their packages if 
corporate goes 'belly up'?

By 'corporate' I refer, in this case, to those who work for a company 
and have a company email,
and refuse to give alternate contact details.

The subtext here should be obvious... "No alternate means of contact? 
Must not have had much
interest. Who else wishes to maintain these packages?"

Sorry... but I fail to see your argument as a valid point while the rest 
of us are being charged with
the responsibility of ensuring Fedora's future.

Lyos Gemini Norezel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lyos_GeminiNorezel.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: not available
URL: 

From mkkp4x4 at gmail.com  Thu Oct 22 13:45:27 2009
From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=)
Date: Thu, 22 Oct 2009 15:45:27 +0200
Subject: problem with dns
In-Reply-To: 
References: <596b53e0910211633h7ad0b918q4628f53fdbdef25c@mail.gmail.com>
	
Message-ID: <596b53e0910220645v4ba43942g6d4079b9d9799bfd@mail.gmail.com>

2009/10/22 Giovanni Tirloni :
> 2009/10/21 Micha? Piotrowski :
>> Hi,
>>
>> This is a problem that touches some of Fedora services.
>>
>> I've got a network
>>
>> 192.168.101.0
>>
>> 192.168.101.1 - this is my router
>> 192.168.101.200 - ozzy - my F11 server
>> 192.168.101.100 - dio - my Windows 6 workstation
>>
>> I use two DNS servers
>>
>> nameserver 192.168.1.1
>> nameserver 194.204.159.1
>>
>> The problem shows up when my network 192.168.101.0 lose a connection
>> with 192.168.1.0 and my primary DNS server is not available.
>
> [...]
>
>> Every time when I try to use samba I get no response from ozzy. Here
>> is what is happening for mc
>>
>> I think that such behavior is clearly wrong. But it's a long term
>> issue. So maybe I'm wrong and this is a correct behavior?
>
> The daemons are doing reverse DNS lookups on the IP addresses and not
> getting any answers.
>
> You can either tweak that in the resolv.conf file so it doesn't take
> so long to give up (see the man page for options) or configure your
> services to ignore it.

I added
options timeout:5 attempts:1 no-check-names
and it doesn't solve problems. I still can't use samba, mc, sudo.

>
> For sshd you just need to uncomment the following line in sshd.conf:
>
> #UseDns no

Thanks, that's done the trick.

>
> ?But I don't see anything wrong with how things are happening in this situation.

Some programs like apache, postgresql, mysql doesn't have any problems
with dns - it's great :) But some programs doesn't want to run without
dns - sudo, samba, mc (and probably many, many other) - from my point
of view this is a big problem.

Regards,
Michal



From ajax at redhat.com  Thu Oct 22 13:48:43 2009
From: ajax at redhat.com (Adam Jackson)
Date: Thu, 22 Oct 2009 09:48:43 -0400
Subject: Unreadable binaries
In-Reply-To: <20091022100436.GA16025@amd.home.annexia.org>
References: <20091022100436.GA16025@amd.home.annexia.org>
Message-ID: <1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>

On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote:
> $ ll /usr/libexec/pt_chown 
> -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown
> $ ll /usr/bin/chsh 
> -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh
> 
> What is the purpose of making binaries like these unreadable?
> 
> Originally I thought it was something to do with them being setuid,
> but there are counterexamples:
> 
> $ ll /usr/bin/passwd 
> -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd

Historically, the kernel considers read permission on a binary to be a
prerequisite for generating core dumps on fatal signal; which you
typically want to prevent, since that becomes a way to read /etc/shadow.

Pretty sure that's still the case, which means any u+s binaries with
group/other read permission are bugs.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From sds at tycho.nsa.gov  Thu Oct 22 13:59:00 2009
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Thu, 22 Oct 2009 09:59:00 -0400
Subject: Unreadable binaries
In-Reply-To: <1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>
References: <20091022100436.GA16025@amd.home.annexia.org>
	<1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>
Message-ID: <1256219940.2191.47.camel@moss-pluto.epoch.ncsc.mil>

On Thu, 2009-10-22 at 09:48 -0400, Adam Jackson wrote:
> On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote:
> > $ ll /usr/libexec/pt_chown 
> > -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown
> > $ ll /usr/bin/chsh 
> > -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh
> > 
> > What is the purpose of making binaries like these unreadable?
> > 
> > Originally I thought it was something to do with them being setuid,
> > but there are counterexamples:
> > 
> > $ ll /usr/bin/passwd 
> > -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd
> 
> Historically, the kernel considers read permission on a binary to be a
> prerequisite for generating core dumps on fatal signal; which you
> typically want to prevent, since that becomes a way to read /etc/shadow.
> 
> Pretty sure that's still the case, which means any u+s binaries with
> group/other read permission are bugs.

dumpable flag gets cleared for suid/sgid binaries (as well as for
non-readable binaries).

-- 
Stephen Smalley
National Security Agency



From jlaska at redhat.com  Thu Oct 22 13:57:49 2009
From: jlaska at redhat.com (James Laska)
Date: Thu, 22 Oct 2009 09:57:49 -0400
Subject: F-12 Beta Blocker Meeting 2009-10-21 @ 15:00 UTC (11 AM EDT) - Recap
In-Reply-To: <1256082150.2148.23.camel@localhost.localdomain>
References: <1256082150.2148.23.camel@localhost.localdomain>
Message-ID: <1256219869.2398.70.camel@localhost.localdomain>

====================================================
#fedora-bugzappers: F-12-Blocker bug review (part#1)
====================================================


Meeting started by jlaska at 15:01:09 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-21/fedora-bugzappers.2009-10-21-15.01.log.html
.

Meeting summary
---------------
* gathering  (jlaska, 15:01:27)
  * Walking through a sorted by-component list of F12Blocker bugs --
    http://tinyurl.com/yk9wehr  (jlaska, 15:05:14)

* https://bugzilla.redhat.com/show_bug.cgi?id=514000  (jlaska, 15:07:53)
  * AGREED: Reported problem in 514000 is now resolved.  This can be
    remove from blocker list.  Any other issues should be filed as new
    bugs  (jlaska, 15:13:53)

* https://bugzilla.redhat.com/show_bug.cgi?id=529225  (jlaska, 15:14:07)
  * HELP: Can smolt provide a list of systems when searching by
    sybsystem PCI ID's (i.e. 17aa:20f2)  (jlaska, 15:20:47)
  * AGREED: 529225 needs triage or devel review before we can add as a
    F12Blocker  (jlaska, 15:21:16)

* https://bugzilla.redhat.com/show_bug.cgi?id=466377  (jlaska, 15:21:48)
  * possibly further isolate the segfault to obtain a backtrace
    (jlaska, 15:27:29)
  * needs clarification as to whether the boot volume is low ... or
    sound doesn't work at all  (jlaska, 15:29:08)
  * AGREED: 466377 not a blocker bug  (jlaska, 15:29:51)

* https://bugzilla.redhat.com/show_bug.cgi?id=523768  (jlaska, 15:29:57)
  * no indications that this affects a *lot* of users  (jlaska,
    15:33:03)
  * AGREED: remove 523768 from the blocker list  (jlaska, 15:33:20)

* https://bugzilla.redhat.com/show_bug.cgi?id=493058  (jlaska, 15:33:52)
  * AGREED: keep 493058 on the blocker list  (jlaska, 15:38:05)
  * AGREED: move 493058 back to ASSIGNED and request retesting against
    Beta  (jlaska, 15:38:16)

* https://bugzilla.redhat.com/show_bug.cgi?id=503149  (jlaska, 15:38:36)
  * AGREED: 503149 not a release blocker ... workaround exists  (jlaska,
    15:40:26)
  * workaround noted in
    https://bugzilla.redhat.com/show_bug.cgi?id=503149#c11  (jlaska,
    15:40:42)

* https://bugzilla.redhat.com/show_bug.cgi?id=506013  (jlaska, 15:40:55)
  * AGREED: 506013 remains on the blocker list.  (jlaska, 15:46:07)
  * AGREED: 506013 patches are included in F-12-Beta ... needs retesting
    (jlaska, 15:46:17)
  * if Connor's issue remains, it will be filed as a new bug  (jlaska,
    15:46:37)

* https://bugzilla.redhat.com/show_bug.cgi?id=515441  (jlaska, 15:46:45)
  * triggered by providing incorrect NFS server:/path, and attempting to
    recover  (jlaska, 15:50:06)
  * AGREED: 515441 remains on the blocker list.  Needs retesting to
    confirm problem is resolved.  (jlaska, 15:51:03)

* https://bugzilla.redhat.com/show_bug.cgi?id=517260  (jlaska, 15:51:10)
  * this is specific to any USB live install's where the USB stick has
    more than 1 partition  (jlaska, 15:52:12)
  * AGREED: 517260 remains on the list.  Verification of fix against
    anaconda-12.39 needed.  (jlaska, 15:53:21)

* https://bugzilla.redhat.com/show_bug.cgi?id=517491  (jlaska, 15:53:28)
  * Current shrink test case -
    https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(shrink)_install
    (jlaska, 15:58:20)
  * AGREED: 517491 remains on the list.  Awaiting additional
    clarification as to whether reported failure match the assessment of
    the problem.  (jlaska, 16:00:48)

* https://bugzilla.redhat.com/show_bug.cgi?id=524168  (jlaska, 16:00:53)
  * AGREED: 524168 remains on the list ... awaiting verification from
    reporter  (jlaska, 16:04:26)

* https://bugzilla.redhat.com/show_bug.cgi?id=525924  (jlaska, 16:04:43)
  * Liam tested this issue overnight and confirmed that the reported
    problem is fixed  (jlaska, 16:06:00)

* https://bugzilla.redhat.com/show_bug.cgi?id=526549  (jlaska, 16:06:52)
  * AGREED: 526549 remains on the list ... awaiting retest and a patch
    against autoqa/rats_install.py  (jlaska, 16:09:53)

* https://bugzilla.redhat.com/show_bug.cgi?id=526697  (jlaska, 16:10:11)
  * LINK: http://bugzilla.laska.org/   (adamw, 16:12:42)
  * AGREED: 526697 makes edits on existing partitions really unpleasant
    ... remains on the blocker list, awaiting retesting by jlaska
    (jlaska, 16:13:38)

* https://bugzilla.redhat.com/show_bug.cgi?id=526699  (jlaska, 16:14:52)
  * AGREED: 526699 remains on the blocker list ... additional patch
    work/review in progress on anaconda-devel-list  (jlaska, 16:18:34)
  * LINK: http://tinyurl.com/yk9wehr   (cwickert, 16:21:05)

* https://bugzilla.redhat.com/show_bug.cgi?id=527258  (adamw, 16:21:27)
  * ACTION: jlaska needs to retest several bugs  (jlaska, 16:22:26)
  * AGREED: 527258 stays as blocker, needs retesting from jlaska
    (adamw, 16:24:03)

* https://bugzilla.redhat.com/show_bug.cgi?id=527520  (adamw, 16:24:14)
  * having one of our official spins boot to text mode on a default
    install is Not Good :)  (jlaska, 16:25:42)
  * AGREED: 527520 is a blocker and fix should be tagged into F12
    (adamw, 16:29:49)

* https://bugzilla.redhat.com/show_bug.cgi?id=527952  (adamw, 16:30:00)
  * AGREED: 527952 stays a blocker, fix confirmation testing requested
    from reporter  (adamw, 16:33:36)

* https://bugzilla.redhat.com/show_bug.cgi?id=528317  (adamw, 16:33:39)
  * ACTION: adamw to test impact of 528317 to see whether it should be a
    blocker  (adamw, 16:42:00)
  * ACTION: chris campbell will also test  (adamw, 16:43:25)

* https://bugzilla.redhat.com/show_bug.cgi?id=528537  (adamw, 16:43:58)
  * AGREED: 528537 stays as a blocker, re-assign to appropriate
    component (kernel)  (adamw, 16:48:53)

* https://bugzilla.redhat.com/show_bug.cgi?id=530015  (adamw, 16:50:31)

* https://bugzilla.redhat.com/show_bug.cgi?id=528909  (adamw, 16:55:44)
  * AGREED: 530015 stayed as blocker, jforbes to fix  (adamw, 16:56:10)
  * AGREED: 528909 stays as blocker, no action needed at present time
    (adamw, 16:58:43)

* https://bugzilla.redhat.com/show_bug.cgi?id=480593  (adamw, 16:58:56)
  * AGREED: 480593 is an f11 tracker bug, closing  (adamw, 17:00:59)

* https://bugzilla.redhat.com/show_bug.cgi?id=498968  (adamw, 17:01:11)
  * AGREED: 498968 is f12 virt tracker bug, no need to talk about it
    itself  (adamw, 17:01:47)

* https://bugzilla.redhat.com/show_bug.cgi?id=505562  (adamw, 17:01:54)
  * AGREED: 505562 can be closed, the fixed dmraid package is already
    tagged into final  (adamw, 17:05:21)

* https://bugzilla.redhat.com/show_bug.cgi?id=528097  (adamw, 17:06:27)
  * AGREED: 528097 stays on the list, fixed dmraid has been tagged into
    stable, need confirmation from reporter  (adamw, 17:08:40)

* https://bugzilla.redhat.com/show_bug.cgi?id=522969  (adamw, 17:10:08)
  * LINK: http://koji.fedoraproject.org/koji/buildinfo?buildID=137342 is
    the build that fixes it  (adamw, 17:13:08)
  * LINK: https://fedorahosted.org/rel-eng/ticket/2547 is a tag request
    (adamw, 17:13:49)
  * AGREED: 522969 has been fixed and tagged, bug closed  (adamw,
    17:16:43)

* https://bugzilla.redhat.com/show_bug.cgi?id=528038  (adamw, 17:16:43)
  * AGREED: 528038 is not important enough to block release, dropped to
    f12targert  (adamw, 17:19:19)

* https://bugzilla.redhat.com/show_bug.cgi?id=512944  (adamw, 17:19:40)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=493492   (adamw,
    17:27:51)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=522182   (adamw,
    17:28:10)
  * LINK:
    https://bugzilla.redhat.com/buglist.cgi?bug_id=527520%2C498156%2C529209%2C517879%2C526699%2C506013%2C513864%2C529794%2C524168%2C509733%2C516057%2C523110%2C517491%2C514600%2C523768%2C520480%2C517839%2C522137%2C525924%2C520162%2C519766%2C528097%2C526697%2C519442%2C515441%2C506075%2C528005%2C528312%2C526154%2C520750%2C514000%2C521512%2C526836%2C522187%2C518962%2C527920%2C530015%2C493472%2C529363%2C518623%2C527426%2C498968%2C528038%2C527952%2C523270%2C
    (adamw, 17:39:37)
  * LINK: http://tinyurl.com/yk9wehr :)  (adamw, 17:40:08)

Meeting ended at 21:09:09 UTC.




Action Items
------------
* jlaska needs to retest several bugs
* adamw to test impact of 528317 to see whether it should be a blocker
* chris campbell will also test




Action Items, by person
-----------------------
* adamw
  * adamw to test impact of 528317 to see whether it should be a blocker
* jlaska
  * jlaska needs to retest several bugs
* **UNASSIGNED**
  * chris campbell will also test




People Present (lines said)
---------------------------
* adamw (262)
* jlaska (217)
* Oxf13 (53)
* buggbot (37)
* ddumas (28)
* cwickert (12)
* Tech33 (7)
* jforbes (6)
* rjune (4)
* yaneti_ (3)
* thomasj (3)
* zodbot (3)
* cebbert (3)
* zcat (2)
* tk009-12 (2)
* poelcat (1)
* mejla (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From ebenes at redhat.com  Thu Oct 22 14:10:51 2009
From: ebenes at redhat.com (Eduard Benes)
Date: Thu, 22 Oct 2009 10:10:51 -0400 (EDT)
Subject: Fedora Test Day Summary - Confined Users
In-Reply-To: <1581075305.1084411256220577018.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1597275399.1084641256220651432.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Greetings!

This Tuesday was the "Confined Users" Test Day / Fit&Finish [1] (TD/F&F).
Though we expected higher attendance, the results are really valuable.
The most valuable outcome of a test day could be a fact that we should 
bring more attention/people to using/testing SELinux policy and related
tools.

Thanks to all who participated and helped with the organization, 
especially to Dan Walsh who promptly started to resolve reported bugs 
and already fixed some important issues.

Following bugs were reported during the TD/F&F by the participants:

ID  	 Summary
529873 	Openswan/pluto - AVC denials when starting the ipsec service
529870 	SELinux is preventing /usr/bin/python "getattr" access on /home/jlaska/.gvfs.
529871 	SELinux is preventing /usr/bin/python "connectto" access on /var/run/nscd/socket.
529758 	SELinux is preventing /usr/sbin/sendmail.sendmail "module_request" access.
529803 	Your system may be seriously compromised! /usr/sbin/nscd attempted to mmap low kernel memory.
529606 	SELinux is preventing /usr/sbin/modem-manager "read write" access to device noz0.
529738 	SELinux is preventing /lib64/dbus-1/dbus-daemon-launch-helper "execute" access on /usr/sbin/abrtd.
529827 	guest_u user not able to run ps
529830 	SELinux failed to limit the authority of execute of user_u
529903 	SELinux is preventing bash "create" access.
529911 	SELinux is preventing nautilus "read write" access on sr0.
529916 	AVCs with confined "mailuser" sending e-mail
529933 	SELinux is preventing /usr/sbin/abrtd "setattr" access on .abrt.
529934 	SELinux is preventing /usr/sbin/abrtd "write" access on /root.
529951 	SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents).
529953 	hp cups selinux denial
529961 	SELinux is preventing /usr/sbin/abrtd "read" access on Bugzilla.conf. 

Have a nice day, 

/Eduard 


[1] - https://fedoraproject.org/wiki/Test_Day:2009-10-20
[2] - http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/sect-Security-Enhanced_Linux-Targeted_Policy-Confined_and_Unconfined_Users.html
[3] - http://magazine.redhat.com/2008/07/02/writing-policy-for-confined-selinux-users/



From mmcgrath at redhat.com  Thu Oct 22 15:26:05 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 22 Oct 2009 10:26:05 -0500 (CDT)
Subject: Fedora 12 Beta
In-Reply-To: <1256163311.2314.439.camel@adam.local.net>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
	
	<1256163311.2314.439.camel@adam.local.net>
Message-ID: 

On Wed, 21 Oct 2009, Adam Williamson wrote:

> On Wed, 2009-10-21 at 17:08 -0500, Mike McGrath wrote:
> > On Wed, 21 Oct 2009, Adam Williamson wrote:
> >
> > > On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
> > > > Hi,
> > > >
> > > > I just installed F12 Beta. Here are some thoughts
> > > >
> > > > 1 - during the first boot smolt panicked - there was an error related
> > > > to time zones in python-sitepackages or something like that.
> > >
> > > Could you try to reproduce and provide more precise details on the
> > > error? There's not a lot we can do with that level of detail.
> > >
> >
> > The smolt firstboot thing is already fixed, just didn't make it in time
> > for the beta, my bad.
>
> Is there a bug report I can reference so I can add this to the Common
> Bugs page with a reasonable level of detail?
>

I don't remember if a bug got opened for that one or not, basically when
firstboot loads the smolt module fails so it doesn't load.  It's
attempting to import a deprecated library that doesn't exist.  It doesn't
actually prevent any functionality other then users don't get prompted to
enable smolt.  Firstboot continues as normal with license, create user,
date time, etc.

	-Mike

From linus.ml.walleij at gmail.com  Thu Oct 22 16:20:52 2009
From: linus.ml.walleij at gmail.com (Linus Walleij)
Date: Thu, 22 Oct 2009 18:20:52 +0200
Subject: Status of multiseat feature
Message-ID: <63386a3d0910220920p3c8927den3b084e12d0cf3472@mail.gmail.com>

Is anyone actively working on multiseat?
https://fedoraproject.org/wiki/Features/Multiseat

Linus Walleij



From jkeating at redhat.com  Thu Oct 22 16:43:46 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 09:43:46 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
Message-ID: <1256229826.9182.3.camel@localhost.localdomain>

On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
> What kind of checks do you mean? If maintainers want to keep their
> packages, they can just change the owner of the package to their new
> private account before leaving Red Hat. 

That assumes the maintainer knows they're leaving Red Hat ahead of time.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jkeating at redhat.com  Thu Oct 22 16:50:54 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 09:50:54 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
Message-ID: <1256230254.9182.5.camel@localhost.localdomain>

Hi all.  It has been brought to my attention that my description of my
future vision of rawhide as explained here is much clearer than previous
attempts (including the current "no frozen rawhide" wiki page).  So I
felt it prudent to forward it along to the devel list for more eyes to
look upon it and comment if desired.

Thanks!

-------- Forwarded Message --------
From: Jesse Keating 
Reply-to: fedora-advisory-board at redhat.com
To: fedora-advisory-board at redhat.com
Subject: Re: "What is the Fedora Project?"
Date: Wed, 21 Oct 2009 18:58:08 -0700

On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote:
> > >I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a
> > >way for developers to have trees that move at their pace, and are
> > >possibly quite broken from time to time in ways that differ from each
> > >other.  If we were able to develop such a scenario, why not also
> > >provide the flipside of this idea -- make the One True Rawhide the
> > >place where we take in changes that don't break the world, while
> > >they're cobbled on in the other trees?  Whether this is an extension
> > >of the "KoPeR" idea or something entirely difficult, it merits serious
> > >consideration.
> > 
> > I very much like the aspect of the more stable rawhide here.
> 
> Jesse Keating brought up some concerns about integration, but aren't
> those concerns something that people would be interested in solving?
> (I'm assuming those people are the wide variety of engineers working
> in the Fedora community who are smarter than I.)
> 
> 

So my plans are really funny.  I plan to make rawhide more unstable more
of the time, and I plan to make "rawhide" more stable more of the time.
Crazy eh?  How can I do this?  By splitting "rawhide" in two.

Rawhide as we know it, /pub/fedora/linux/releases/development/ will
remain "rawhide".  We may even change the path to say rawhide, just to
catch things up and well I like keeping mirrors on their toes.  Rawhide
will be a repository of developmental and experimental packages.  Things
being worked on for the future.  It will /not/ be an installable tree,
rather it will just be a repository of packages, to be added on to an
already stable "base", eg you'd install F12, and enable rawhide to test
rawhide.  This will significantly lower the complaints that "rawhide
isn't installable".

The second face of rawhide, will be the "pending release", that is when
it comes time to feature freeze a release, we'll split it away from
rawhide.  We'll publish to /pub/fedora/linux/releases/test/13-pending/
or some such.  THIS tree will be installable.  It will be composed each
night, and we'll use bodhi to manage updates to this tree.  That means
this tree will have it's own "updates testing" where potential freeze
breaks can be tested and commented on by all, but won't risk the base
tree.  If testing pans out, it'll get tagged for the release, if not
it'll get thrown away.  This tree will spawn 13-Alpha, 13-Beta, the
snapshots in between, and eventually pub/fedora/linux/releases/13.

Remember that first rawhide?  Yeah, it kept going, unfrozen, leaping
toward Fedora 14.  You could still install 13-Alpha, or 13-pending, and
enable/update to rawhide to start testing Fedora 14 stuff.

What does this accomplish?  It provides a very easy release valve.
Instead of closing the valve and building up pressure while we freeze,
and tempting people to push things into our pending release that really
don't belong, we'll provide them a normal, never ending release of
pressure, called rawhide.  You can always find the latest stuff in
rawhide, there is nothing newer (unless we make KoPeRs happen).  We
don't have to worry about "rawhide" being installable.  We don't have to
worry about people dumping highly experimental or developmental stuff in
our pending release.  We don't have to worry about the giant pile of
builds for the next release building up while we polish the pending
release.  We don't have to worry about the giant pile of 0-day updates
building up while we polish the pending release, as we'll be pushing
these updates as we go.

This is my vision on how to accomplish both a always active development
stream, and a more stable pending release stream, keeping everybody
happy.  Want to help?  I'll be at FUDCon Toronto discussing roadblocks
to this vision and discussing why this vision sucks if anybody thinks
that it does.  Or just find me on IRC/email if you want to chat about
it.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From mclasen at redhat.com  Thu Oct 22 16:57:51 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 22 Oct 2009 12:57:51 -0400
Subject: Status of multiseat feature
In-Reply-To: <63386a3d0910220920p3c8927den3b084e12d0cf3472@mail.gmail.com>
References: <63386a3d0910220920p3c8927den3b084e12d0cf3472@mail.gmail.com>
Message-ID: <1256230671.1777.1.camel@planemask>

On Thu, 2009-10-22 at 18:20 +0200, Linus Walleij wrote:
> Is anyone actively working on multiseat?
> https://fedoraproject.org/wiki/Features/Multiseat

The necessary infrastructure for multiseat is (slowly) being developed
in ConsoleKit and gdm branches upstream.




From jcm at redhat.com  Thu Oct 22 17:05:13 2009
From: jcm at redhat.com (Jon Masters)
Date: Thu, 22 Oct 2009 18:05:13 +0100
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256230254.9182.5.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
Message-ID: <1256231113.3687.24.camel@tonnant>

On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:

> This is my vision on how to accomplish both a always active development
> stream, and a more stable pending release stream, keeping everybody
> happy.  Want to help?  I'll be at FUDCon Toronto discussing roadblocks
> to this vision and discussing why this vision sucks if anybody thinks
> that it does.  Or just find me on IRC/email if you want to chat about
> it.

Not a bad idea. In all honesty, I find rawhide is rarely fully
installable out of the "box" anyway...this isn't a grumble! I think it's
better to embrace reality and have multiple trees, though I am
interested in whether that pending release couldn't also one day have a
counterpart that had more longevity - a "testing" release (not the same
as the "testing" that we currently have through updates) :)

Jon.




From rjones at redhat.com  Thu Oct 22 17:13:21 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Oct 2009 18:13:21 +0100
Subject: Unreadable binaries
In-Reply-To: <1256219940.2191.47.camel@moss-pluto.epoch.ncsc.mil>
References: <20091022100436.GA16025@amd.home.annexia.org>
	<1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>
	<1256219940.2191.47.camel@moss-pluto.epoch.ncsc.mil>
Message-ID: <20091022171321.GA18852@amd.home.annexia.org>

On Thu, Oct 22, 2009 at 09:59:00AM -0400, Stephen Smalley wrote:
> On Thu, 2009-10-22 at 09:48 -0400, Adam Jackson wrote:
> > On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote:
> > > $ ll /usr/libexec/pt_chown 
> > > -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown
> > > $ ll /usr/bin/chsh 
> > > -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh
> > > 
> > > What is the purpose of making binaries like these unreadable?
> > > 
> > > Originally I thought it was something to do with them being setuid,
> > > but there are counterexamples:
> > > 
> > > $ ll /usr/bin/passwd 
> > > -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd
> > 
> > Historically, the kernel considers read permission on a binary to be a
> > prerequisite for generating core dumps on fatal signal; which you
> > typically want to prevent, since that becomes a way to read /etc/shadow.
> > 
> > Pretty sure that's still the case, which means any u+s binaries with
> > group/other read permission are bugs.
> 
> dumpable flag gets cleared for suid/sgid binaries (as well as for
> non-readable binaries).

Stephen, what would be your advice if I asked for these binaries to
become readable by non-root users?

[It's not crucial at the moment, however, just reduces the
effectiveness of febootstrap a little]

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html



From ngompa13 at gmail.com  Thu Oct 22 17:28:36 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 22 Oct 2009 12:28:36 -0500
Subject: Fedora with Universal Binaries?
Message-ID: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>

Hello,
I just saw this article about an effort to create Universal binary style ELF
binaries for Linux, and I thought that this would be something to watch, so
that Fedora could integrate both x86-32 and x86-64 into single DVD sets.

http://icculus.org/fatelf/

There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit and
64-bit kernels and all the apps compiled as FatELF binaries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jcm at redhat.com  Thu Oct 22 17:38:28 2009
From: jcm at redhat.com (Jon Masters)
Date: Thu, 22 Oct 2009 18:38:28 +0100
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <1256233108.3687.38.camel@tonnant>

On Thu, 2009-10-22 at 12:28 -0500, King InuYasha wrote:


> http://icculus.org/fatelf/
> 
> 
> There is even a proof of concept VM of Ubuntu 9.04 that has both
> 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries

Except, they're not really ELF binaries. ELF doesn't allow you to do
both at the same time in the headers, so this adds a new header and is
essentially an encapsulation for other ELF files. Thus, a kernel patch
is required and it would be some time before all kernels supported it.
I'm not against the notion of this...but I think some of the usual
suspects need to get involved in standardizing such an ELF hack.

(You might be able to do something with binfmt_misc as a hack)

Jon.




From Quentin at Armitage.org.uk  Thu Oct 22 17:16:20 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Thu, 22 Oct 2009 18:16:20 +0100
Subject: rawhide report: 20091022 changes
In-Reply-To: <20091022130612.GA12194@releng2.fedora.phx.redhat.com>
References: <20091022130612.GA12194@releng2.fedora.phx.redhat.com>
Message-ID: <1256231780.2497.33.camel@samson.armitage.org.uk>

On Thu, 2009-10-22 at 13:06 +0000, Rawhide Report wrote:

> Compose started at Thu Oct 22 06:15:12 UTC 2009
> 
> Broken deps for i386
> ----------------------------------------------------------
> 	openscada-visStation-0.6.4-3.fc12.i686 requires openscada-Special-FlibSYS
> 
> 
> Updated Packages:
> 
> xorg-x11-proto-devel-7.4-34.fc12
> --------------------------------
> * Tue Oct 13 2009 Adam Jackson  7.4-34
> - kbproto 1.0.4
> - xf86miscproto 0.9.3
> - xproxymanagementprotocol 1.0.3
> 
> * Tue Oct 06 2009 Peter Hutterer  7.4-32
> - compositeproto 0.4.1
> - xf86dgaproto 2.1
> - dmxproto 2.3
> - inputproto 2.0
> - fixesproto 4.1.1
> - randrproto 1.3.1
> - recordproto 1.14
> - xf86vidmodeproto 2.3
> - xineramaproto 1.2
> - xproto 7.0.16
> 
> * Tue Oct 06 2009 Peter Hutterer  7.4-33
> - Upload xf86dgaproto 2.1 tarball, this time for real.
> 
> 

but yum update xorg-x11-proto-devel reports:
[root at samson yum-update]# yum update
Loaded plugins: dellsysidplugin, dellsysidplugin2, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package xorg-x11-proto-devel.noarch 0:7.4-34.fc12 set to be updated
--> Processing Conflict: xorg-x11-proto-devel-7.4-34.fc12.noarch
conflicts libXxf86dga-devel < 1.1
--> Finished Dependency Resolution
xorg-x11-proto-devel-7.4-34.fc12.noarch from rawhide has depsolving
problems
  --> xorg-x11-proto-devel conflicts with libXxf86dga-devel
Error: xorg-x11-proto-devel conflicts with libXxf86dga-devel
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

Should the Rawhide report have identified this as a broken dependency?



From Quentin at Armitage.org.uk  Thu Oct 22 17:29:37 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Thu, 22 Oct 2009 18:29:37 +0100
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
Message-ID: <1256232577.2497.43.camel@samson.armitage.org.uk>

On Mon, 2009-10-19 at 20:20 +0100, Peter Robinson wrote:
> Hi All,
> 
> I thought with the mass rebuild the i586 rpms were suppose to be gone
> but it seems the F-12 repository still has quite a few of them. Are
> the old packages that should have been blocked, ones that's that
> weren't rebuilt for some reason or something that I've just missed?
> 
> Peter
> 

I did some work a week or two ago to see what was behind some of the
packages a couple of weeks ago, and it is summarised below. Not only is
there an issue with the i586 packages, but also a number of noarch
packages.

Point 5 below categories the apparent reason for the packages not having
been rebuilt, and it appears possible that out of the 185 packages that
have not been rebuilt, 95 might build successfully if just submitted for
rebuilding.

I was looking at the need-rebuild.py script, and have a few
comments/questions (apologies if my terminology is incorrect - this area
is new to me).

1. Is the script that is run and produces the output at
http://jkeating.fedorapeople.org/needed-f12-rebuilds.html actually the
script referred to at the bottom of that page
(https://fedorahosted.org/rel-eng/browser/scripts) ? The reason I ask is
that when I run the script, I get 

Included Koji instances:
http://koji.fedoraproject.org/kojihub
http://sparc.koji.fedoraproject.org/kojihub
http://s390.koji.fedoraproject.org/kojihub
http://arm.koji.fedoraproject.org/kojihub

whereas the posted output only has
Included Koji instances:
http://koji.fedoraproject.org/kojihub
http://sparc.koji.fedoraproject.org/kojihub

2. If the script is run against just koji.fedoraproject,org/kojihub
(i.e. without the sub arches), it says 185 packages need
rebuilding (instead of the 175 listed in the report); the following
10 packages are omitted when the sparc koji hub is also included:
gmpc
HippoDraw
itcl
latex2rtf
prtconf
PyKDE 
python-igraph
silo
spicebird
xorg-x11-drv-sunffb

This is caused by line 117 of the script:
        unbuilt = unbuilt & unbuiltnew
so if a package needs to be rebuilt on the primary arch, but not on the
(in this case sparc) secondary arch, then it is dropped from needing to
be rebuilt (it appears that a package will only be listed if it needs
to be rebuild on every arch). There are several circumstances where this
can happen (with the 10 missing packages listed):

Built on sub arch but failed on primary arch
============================================
gmpc - 0.18.0-1 build on sparc after epoch but 0.18.0-2 failed on koji
HippoDraw
itcl
latex2rtf
python-igraph

Not a primary arch package (should the package be blocked in the primary
arch kojihub?)
==========================
prtconf
silo
xorg-x11-drv-sunffb

Blocked on secondary arch (so not included in unbuiltnew)
=========================
spicebird

Built on sub arch but not submitted for rebuild on primary arch
================================================================
PyKDE

Package does not exist in secondary arch (no example)
=====================================================

Would it be more relevant to list what needs to be rebuild separately
for each arch (but see point 3 below)?

3. So far as I can see, there have not been mass rebuilds on the
secondary arches, so is it relevant to search them for successful builds
since the epoch? If it is relevant, they would appear to have different
epochs in any case.

4. On the sparc (and other sub arches) kojihubs, there can be builds
without a task, but the build itself can have a tag dist-f12 (see 
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=19567 for
example). Can that tag be safely used for checking if the build had a
particular tag, rather than having to look at a task? Currrently the
script can call getTaskInfo with a taskID of None, which is the cause of
getTaskInfo returning a request with len > 1, since that response is an
error message for requesting TaskInfo with a task id of None.

5. I have looked at the 185 packages that have not been rebuilt, and the
reasons fall into the following categories (details for each package are
listed later):
1. Not submitted for rebuild (65)
2. Mock exited with status 10 (7)
3. Mock exited with status 30 (23)
4. No build on dist-12/dist-f12-rebuild/dist-f12-updates-candidate (6)
5. Build cancelled (1)
6. Mock exited with status 1 (83)

I'm wondering if (re)submitting the packages in categories 1, 3, 4 and 5
might result in the majority being successfully built, possibly halving
the number of packages that would then still need to be rebuilt.

I have made some changes to need-rebuild.py to produce some of the
information above, and am happy to provide them if they are of any
interest.



Not submitted for rebuild (65)
==============================
OpenEXR_CTL 
OpenEXR_Viewers
PerceptualDiff
Perlbal
Pixie
Pound
PyAmanith
PyKDE
PyQuante
PySBIG
PySolFC
PySolFC-cardsets
aboot
ccss
django-typepad
eclipse-setools
education-bookmarks
elilo
eqntott
fonts-hebrew-fancy
gdata-sharp
gnome-globalmenu
icoutils
libgtk-java
libica
libnetdevname
luci
netplug
olpc-kbdshim
openssl-ibmca
perl-Perl-Critic
perl-Tk-ProgressBar-Mac
piggyback
prctl
prtconf
pyhton-utmp
python-decorator3
python-psyco
python-typepad
python-utmp
rubygem-extlib
rubygem-mixlib-cli
rubygem-mixlib-config
rubygem-mixlib-log
rubygem-systemu
sblim-cim-client2
silo
snake
ssmtp
tomcatjss
trac-tickettemplate-plugin
unetbootin
vanessa_logger
volpack
x11vnc
xorg-x11-drv-sunbw2
xorg-x11-drv-suncg14
xorg-x11-drv-suncg3
xorg-x11-drv-suncg6
xorg-x11-drv-sunffb
xorg-x11-drv-sunleo
xorg-x11-drv-suntcx
yum-plugin-download-order
zikula-module-filterutil
zikula-module-pagemaster


Mock exited with status 10 (7)
==============================
HippoDraw
geronimo-specs
perl-POE-Component-Client-HTTP
perl-POE-Component-Server-SOAP
perl-POE-Component-Server-SimpleHTTP
python-tg-devtools
vanessa_adt

Mock exited with status 30 (23)
===============================
gcompris
gdesklets
gds2pov
gedit-plugins
gg2
giggle
gl-117
glabels
glade2
glglobe
glitz
gliv
glob2
gnome-applet-bubblemon
gnome-applet-grandr
klibido
ladspa-swh-plugins
libbtctl
libcapseo
petitboot
pfqueue
pfscalibration
pfstools

No build on dist-12/dist-f12-rebuild/dist-f12-updates-candidate (6)
===================================================================
TurboGears2 
fife
mathgl
pysvn           (this hasbeen built with tag dist-f12-openssl)
python-catwalk
sblim-cmpi-dhcp

Build cancelled (1)
===================
python-polybori

Mock exited with status 1 (83)
==============================
389-dsgw
E
Io-language
Macaulay2
ScientificPython
WritRecogn
almanah
artwiz-aleczapka-fonts
asylum
awn-extras-applets
baekmuk-bdf-fonts
chktex
compat-db
eris
evolution-brutus
geda-gattrib
gengetopt
gmfsk
gmp-ecm
gmpc
gmrun
gnome-scan
gnubversion
gpxviewer
gromacs
iksemel
inadyn-mt
irda-utils
itcl
k3d
knm_new-fonts
latex2rtf
libFoundation
libfakekey
libgnomedb
libpreludedb
matchbox-keyboard
mikmod
mod_dnssd
nickle
octaviz
ohm
pari
perl-AnyEvent-XMPP
perl-Apache2-SOAP
perl-Class-InsideOut
perl-DBIx-Simple
perl-Jemplate
perl-MooseX-Daemonize
perl-MooseX-GlobRef-Object
perl-MooseX-POE
perl-MooseX-Traits-Attribute-CascadeClear
perl-RRD-Simple
perl-SVN-Mirror
perl-SVN-Simple
perl-Test-WWW-Mechanize-Catalyst
postgis
pspp
python-igraph
python-kaa-imlib2
python-openhpi
python-xkit
qtiplot
ratbox-services
recordmydesktop
safekeep
sblim-cmpi-rpm
schroedinger
skychart
smarteiffel
spicebird
synce-kde
tcltls
towhee
tuxpaint
unifdef
verbiste
widelands
xfconf
xorg-x11-drv-ivtv
xpilot-ng
xqilla
xqilla10



From Jochen at herr-schmitt.de  Thu Oct 22 17:43:47 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 22 Oct 2009 19:43:47 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <1256233108.3687.38.camel@tonnant>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<1256233108.3687.38.camel@tonnant>
Message-ID: <4AE099D3.1050908@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 22.10.2009 19:38, schrieb Jon Masters:
> Except, they're not really ELF binaries. ELF doesn't allow you to do
> both at the same time in the headers, so this adds a new header and is
> essentially an encapsulation for other ELF files. Thus, a kernel patch
> is required and it would be some time before all kernels supported it.
> I'm not against the notion of this...but I think some of the usual
> suspects need to get involved in standardizing such an ELF hack.
>
> (You might be able to do something with binfmt_misc as a hack)
>
> Jon.
>
Creating FatELF binaries doesn't solve any x86_64 related issues.

For example:

Old releases of blender was not able to creates proper .blend files
when the
binary was compiled for x86_64. In this case the created files was not
usable
on the x86_32 release.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iJwEAQECAAYFAkrgmcEACgkQZLAIBz9lVu++FgP/br8KeMY5vp8V88xv4hoH9pyV
2vuJJyhszaWl/qFN9Iax7Q5p1A3muC/BFHhUu6VWphB2xIj9EXkMhubgVtX7OBBc
J+v/wv0bWU2kBVFsYDUcfoiTkxluI4uuttTRoqZm7TUuc9/EMBVwzWGeqsBYoFej
xV9jjWk4dGJ/sFlFC3I=
=uZBp
-----END PGP SIGNATURE-----



From dcbw at redhat.com  Thu Oct 22 17:49:48 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 22 Oct 2009 10:49:48 -0700
Subject: Fedora with Universal Binaries?
In-Reply-To: <4AE099D3.1050908@herr-schmitt.de>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<1256233108.3687.38.camel@tonnant> <4AE099D3.1050908@herr-schmitt.de>
Message-ID: <1256233788.3871.4.camel@localhost.localdomain>

On Thu, 2009-10-22 at 19:43 +0200, Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 22.10.2009 19:38, schrieb Jon Masters:
> > Except, they're not really ELF binaries. ELF doesn't allow you to do
> > both at the same time in the headers, so this adds a new header and is
> > essentially an encapsulation for other ELF files. Thus, a kernel patch
> > is required and it would be some time before all kernels supported it.
> > I'm not against the notion of this...but I think some of the usual
> > suspects need to get involved in standardizing such an ELF hack.
> >
> > (You might be able to do something with binfmt_misc as a hack)
> >
> > Jon.
> >
> Creating FatELF binaries doesn't solve any x86_64 related issues.
> 
> For example:
> 
> Old releases of blender was not able to creates proper .blend files
> when the
> binary was compiled for x86_64. In this case the created files was not
> usable
> on the x86_32 release.

That's just a cross-platform compat issue.  People had issues like that
for years porting between Mac and Windows with different type sizes and
endianness.  Without and direct knowledge of the problem, that sounds
like somebody forgot to either (a) use an inherently cross-platform file
format like XML, or (b) forgot to write sane file format encode/decode
routines that were cross-platform clean, or (c) included executable code
in the file format specification (which is pretty stupid).  Or?

We'd expect a program built on any platform to save/load a specific file
format written by that same program built on any other platform.
Otherwise that program is just broken.

Dan
 



From dcbw at redhat.com  Thu Oct 22 17:55:09 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 22 Oct 2009 10:55:09 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256230254.9182.5.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
Message-ID: <1256234109.3871.8.camel@localhost.localdomain>

On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:
> Hi all.  It has been brought to my attention that my description of my
> future vision of rawhide as explained here is much clearer than previous
> attempts (including the current "no frozen rawhide" wiki page).  So I
> felt it prudent to forward it along to the devel list for more eyes to
> look upon it and comment if desired.
> 
> Thanks!
> 
> -------- Forwarded Message --------
> From: Jesse Keating 
> Reply-to: fedora-advisory-board at redhat.com
> To: fedora-advisory-board at redhat.com
> Subject: Re: "What is the Fedora Project?"
> Date: Wed, 21 Oct 2009 18:58:08 -0700
> 
> On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote:
> > > >I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a
> > > >way for developers to have trees that move at their pace, and are
> > > >possibly quite broken from time to time in ways that differ from each
> > > >other.  If we were able to develop such a scenario, why not also
> > > >provide the flipside of this idea -- make the One True Rawhide the
> > > >place where we take in changes that don't break the world, while
> > > >they're cobbled on in the other trees?  Whether this is an extension
> > > >of the "KoPeR" idea or something entirely difficult, it merits serious
> > > >consideration.
> > > 
> > > I very much like the aspect of the more stable rawhide here.
> > 
> > Jesse Keating brought up some concerns about integration, but aren't
> > those concerns something that people would be interested in solving?
> > (I'm assuming those people are the wide variety of engineers working
> > in the Fedora community who are smarter than I.)
> > 
> > 
> 
> So my plans are really funny.  I plan to make rawhide more unstable more
> of the time, and I plan to make "rawhide" more stable more of the time.
> Crazy eh?  How can I do this?  By splitting "rawhide" in two.
> 
> Rawhide as we know it, /pub/fedora/linux/releases/development/ will
> remain "rawhide".  We may even change the path to say rawhide, just to
> catch things up and well I like keeping mirrors on their toes.  Rawhide
> will be a repository of developmental and experimental packages.  Things
> being worked on for the future.  It will /not/ be an installable tree,
> rather it will just be a repository of packages, to be added on to an
> already stable "base", eg you'd install F12, and enable rawhide to test
> rawhide.  This will significantly lower the complaints that "rawhide
> isn't installable".
> 
> The second face of rawhide, will be the "pending release", that is when
> it comes time to feature freeze a release, we'll split it away from
> rawhide.  We'll publish to /pub/fedora/linux/releases/test/13-pending/
> or some such.  THIS tree will be installable.  It will be composed each
> night, and we'll use bodhi to manage updates to this tree.  That means
> this tree will have it's own "updates testing" where potential freeze
> breaks can be tested and commented on by all, but won't risk the base
> tree.  If testing pans out, it'll get tagged for the release, if not
> it'll get thrown away.  This tree will spawn 13-Alpha, 13-Beta, the
> snapshots in between, and eventually pub/fedora/linux/releases/13.
> 
> Remember that first rawhide?  Yeah, it kept going, unfrozen, leaping
> toward Fedora 14.  You could still install 13-Alpha, or 13-pending, and
> enable/update to rawhide to start testing Fedora 14 stuff.

So to make this a reality, we need to ensure that whatever is in rawhide
has a *>=* ENVR than anything in the other trees.  So I assume that when
submitting a bodhi update, bodhi would check rawhide and ensure that
whatever you were about to submit to 13-pending was <= whatever was in
rawhide.  Otherwise we'd get into a great big mess of not being able to
update to rawhide packages because whatever was in 13-pending was
'newer' than rawhide.  Right?

We should have this anyway just to help upgradability between distros;
bodhi should not allow a package to be added to an update if it's a
"newer" ENVR than that same package in any of the "newer" distros.

Dan




From kevin.kofler at chello.at  Thu Oct 22 17:57:34 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Oct 2009 19:57:34 +0200
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: 

King InuYasha wrote:
> I just saw this article about an effort to create Universal binary style
> ELF binaries for Linux, and I thought that this would be something to
> watch, so that Fedora could integrate both x86-32 and x86-64 into single
> DVD sets.
> 
> http://icculus.org/fatelf/

Yuck!!! Please don't infect GNU/Linux with this completely braindead crap! 
This wastes a lot of disk space and download bandwidth and probably also 
increases loading times for NO reason whatsoever. It also doubles the build 
times for any and all software. Just figure out what arch your machine is 
and install the correct package for your arch! Fat binaries are a method to 
make crappy binary-only software distribution easier, they have no room on a 
Free Software system. Let the Mac folks keep their fat crap and leave our 
binaries as native for the appropriate arch!

        Kevin Kofler



From jkeating at redhat.com  Thu Oct 22 18:02:42 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 11:02:42 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256234109.3871.8.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
Message-ID: <1256234562.9182.9.camel@localhost.localdomain>

On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
> So to make this a reality, we need to ensure that whatever is in rawhide
> has a *>=* ENVR than anything in the other trees.  So I assume that when
> submitting a bodhi update, bodhi would check rawhide and ensure that
> whatever you were about to submit to 13-pending was <= whatever was in
> rawhide.  Otherwise we'd get into a great big mess of not being able to
> update to rawhide packages because whatever was in 13-pending was
> 'newer' than rawhide.  Right?
> 
> We should have this anyway just to help upgradability between distros;
> bodhi should not allow a package to be added to an update if it's a
> "newer" ENVR than that same package in any of the "newer" distros. 

Yes, but it may happen before the bodhi stage, when we get autoqa
working on post-build tests.  This kind of check could happen at SCM
commit time, package build time, or finally bodhi push time.  Seems
reasonable that we'd want to catch it as early as possible, but that
does force people to work on rawhide first, then work on the pending
release which may be under critical time pressure.  Certainly something
to discuss.  Catching it at bodhi time seems too late.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From kevin.kofler at chello.at  Thu Oct 22 18:02:32 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Oct 2009 20:02:32 +0200
Subject: rawhide report: 20091022 changes
References: <20091022130612.GA12194@releng2.fedora.phx.redhat.com>
	<1256231780.2497.33.camel@samson.armitage.org.uk>
Message-ID: 

Quentin Armitage wrote:
> Error: xorg-x11-proto-devel conflicts with libXxf86dga-devel
[snip]
> Should the Rawhide report have identified this as a broken dependency?

No. The Rawhide report only lists unresolvable dependencies, not conflicts.

        Kevin Kofler



From ngompa13 at gmail.com  Thu Oct 22 18:19:12 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 22 Oct 2009 13:19:12 -0500
Subject: Fedora with Universal Binaries?
In-Reply-To: 
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	
Message-ID: <8278b1b0910221119h66172ec6r1d595c193b2352ee@mail.gmail.com>

On Thu, Oct 22, 2009 at 12:57 PM, Kevin Kofler wrote:

> King InuYasha wrote:
> > I just saw this article about an effort to create Universal binary style
> > ELF binaries for Linux, and I thought that this would be something to
> > watch, so that Fedora could integrate both x86-32 and x86-64 into single
> > DVD sets.
> >
> > http://icculus.org/fatelf/
>
> Yuck!!! Please don't infect GNU/Linux with this completely braindead crap!
> This wastes a lot of disk space and download bandwidth and probably also
> increases loading times for NO reason whatsoever. It also doubles the build
> times for any and all software. Just figure out what arch your machine is
> and install the correct package for your arch! Fat binaries are a method to
> make crappy binary-only software distribution easier, they have no room on
> a
> Free Software system. Let the Mac folks keep their fat crap and leave our
> binaries as native for the appropriate arch!
>
>        Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I dunno, it could be useful for Live CDs/USBs. It would let you pack
multiple arches onto a single LiveCD/USB.

You sound like one of those crazy people that disregard everything that may
slightly help proprietary software. It's probably possible to strip out
arches when they become unneeded, if so desired. I know it is possible under
Mac OS X to do that. If you had a system that had extra arches you didn't
need, you probably could just go and strip them out to save disk space.

There isn't much proof to your statement about loading fat binaries. I don't
notice a slow down in load times of Universal binaries on my Mac, but I do
notice the disk space. As it is, Snow Leopard now uses Universal binaries to
pack x86_32 and x86_64 into a single application container and can strip out
PowerPC binary code.

Don't knock it till you try it...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tmraz at redhat.com  Thu Oct 22 18:19:49 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 22 Oct 2009 20:19:49 +0200
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256234562.9182.9.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
Message-ID: <1256235589.14074.2.camel@vespa.frost.loc>

On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote: 
> On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
> > So to make this a reality, we need to ensure that whatever is in rawhide
> > has a *>=* ENVR than anything in the other trees.  So I assume that when
> > submitting a bodhi update, bodhi would check rawhide and ensure that
> > whatever you were about to submit to 13-pending was <= whatever was in
> > rawhide.  Otherwise we'd get into a great big mess of not being able to
> > update to rawhide packages because whatever was in 13-pending was
> > 'newer' than rawhide.  Right?
> > 
> > We should have this anyway just to help upgradability between distros;
> > bodhi should not allow a package to be added to an update if it's a
> > "newer" ENVR than that same package in any of the "newer" distros. 
> 
> Yes, but it may happen before the bodhi stage, when we get autoqa
> working on post-build tests.  This kind of check could happen at SCM
> commit time, package build time, or finally bodhi push time.  Seems
> reasonable that we'd want to catch it as early as possible, but that
> does force people to work on rawhide first, then work on the pending
> release which may be under critical time pressure.  Certainly something
> to discuss.  Catching it at bodhi time seems too late.
We could allow adding numbers after the dist tag in release for this
purpose. And if the fixed package would upgrade to a newer upstream
version it should not be too big hassle to build it in the rawhide tree
first.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From limb at jcomserv.net  Thu Oct 22 18:30:59 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 22 Oct 2009 13:30:59 -0500
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221119h66172ec6r1d595c193b2352ee@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>	
	<8278b1b0910221119h66172ec6r1d595c193b2352ee@mail.gmail.com>
Message-ID: <4AE0A4E3.7090101@jcomserv.net>

King InuYasha wrote:
>
> On Thu, Oct 22, 2009 at 12:57 PM, Kevin Kofler  > wrote:
>
>     King InuYasha wrote:
>     > I just saw this article about an effort to create Universal
>     binary style
>     > ELF binaries for Linux, and I thought that this would be
>     something to
>     > watch, so that Fedora could integrate both x86-32 and x86-64
>     into single
>     > DVD sets.
>     >
>     > http://icculus.org/fatelf/
>
>     Yuck!!! Please don't infect GNU/Linux with this completely
>     braindead crap!
>     This wastes a lot of disk space and download bandwidth and
>     probably also
>     increases loading times for NO reason whatsoever. It also doubles
>     the build
>     times for any and all software. Just figure out what arch your
>     machine is
>     and install the correct package for your arch! Fat binaries are a
>     method to
>     make crappy binary-only software distribution easier, they have no
>     room on a
>     Free Software system. Let the Mac folks keep their fat crap and
>     leave our
>     binaries as native for the appropriate arch!
>
>            Kevin Kofler
>
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com 
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>
> I dunno, it could be useful for Live CDs/USBs. It would let you pack 
> multiple arches onto a single LiveCD/USB.
>
Yeah, but they'd be larger, forcing removal of software from the images.
> You sound like one of those crazy people that disregard everything 
> that may slightly help proprietary software. It's probably possible to 
> strip out arches when they become unneeded, if so desired. I know it 
> is possible under Mac OS X to do that. If you had a system that had 
> extra arches you didn't need, you probably could just go and strip 
> them out to save disk space.
>
So. . .then why do it?  There are practical considerations here.
> There isn't much proof to your statement about loading fat binaries. I 
> don't notice a slow down in load times of Universal binaries on my 
> Mac, but I do notice the disk space. As it is, Snow Leopard now uses 
> Universal binaries to pack x86_32 and x86_64 into a single application 
> container and can strip out PowerPC binary code.
>
> Don't knock it till you try it...
Strip out where?  Build time, install time, or run time?

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie



From dcbw at redhat.com  Thu Oct 22 18:33:13 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 22 Oct 2009 11:33:13 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256234562.9182.9.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
Message-ID: <1256236393.3871.9.camel@localhost.localdomain>

On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote:
> On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
> > So to make this a reality, we need to ensure that whatever is in rawhide
> > has a *>=* ENVR than anything in the other trees.  So I assume that when
> > submitting a bodhi update, bodhi would check rawhide and ensure that
> > whatever you were about to submit to 13-pending was <= whatever was in
> > rawhide.  Otherwise we'd get into a great big mess of not being able to
> > update to rawhide packages because whatever was in 13-pending was
> > 'newer' than rawhide.  Right?
> > 
> > We should have this anyway just to help upgradability between distros;
> > bodhi should not allow a package to be added to an update if it's a
> > "newer" ENVR than that same package in any of the "newer" distros. 
> 
> Yes, but it may happen before the bodhi stage, when we get autoqa
> working on post-build tests.  This kind of check could happen at SCM
> commit time, package build time, or finally bodhi push time.  Seems
> reasonable that we'd want to catch it as early as possible, but that
> does force people to work on rawhide first, then work on the pending
> release which may be under critical time pressure.  Certainly something
> to discuss.  Catching it at bodhi time seems too late.

Good point.  SCM commit time (or tag time) with a CVS hook would be
awesome as long as the hook was fast enough.

Dan




From rdieter at math.unl.edu  Thu Oct 22 18:39:08 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 22 Oct 2009 13:39:08 -0500
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
	Project?"])
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
	<1256235589.14074.2.camel@vespa.frost.loc>
Message-ID: 

Tomas Mraz wrote:


> We could allow adding numbers after the dist tag in release for this
> purpose.

That is already allowed, and encouraged, for branch-specific modfications,
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches

-- Rex 




From ji.cerny at gmail.com  Thu Oct 22 18:46:29 2009
From: ji.cerny at gmail.com (Jiri Cerny)
Date: Thu, 22 Oct 2009 20:46:29 +0200
Subject: Major reorganization of TeX Live packages
Message-ID: <7ca14f9d0910221146h2394e584g89bfa455e93dee35@mail.gmail.com>

Hi Jindrich,

(sorry for not replaying to the original message, I was reading the
list through archives)

I was using TeXLive 2009 repository before, without any problem. After
seeing your message,
I followed the instruction

> In case you have an older TL2009 installed on your system from the
> testing repository, please consider removing it and installing again.

and after 'yum install texlive' I get  a lot of missing dependencies.
Installing texlive requires
dvipdfm from the F12/rawhide repository, which requires kpathsea from
the same repository and which in turn
requires texlive-2007. Will it be fixed with texlive-2007-45 build?

Another, probably related issue: Why there is not a xdvi (and also
dvipdfm) binary in the Texlive 2009 repository. Should one use the
one from F12? This seems strange to me to have such mixture of 2007
and 2009 versions.

Jiri



From abo at root.snowtree.se  Thu Oct 22 18:47:18 2009
From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Thu, 22 Oct 2009 20:47:18 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <1256237238.24658.837.camel@tempo.alexander.bostrom.net>

tor 2009-10-22 klockan 12:28 -0500 skrev King InuYasha:

> I just saw this article about an effort to create Universal binary
> style ELF binaries for Linux, and I thought that this would be
> something to watch, so that Fedora could integrate both x86-32 and
> x86-64 into single DVD sets.

There's already lib / lib64 for parallell-installation of libraries,
though granted it's limited to only two arches, but yes, something that
covers bin too would be useful. But I doubt fat binaries are the answer.
You'd probably end up with having rpm merge /usr/bin/xxx from different
packages into a single fatelf file upon installation, rather than
putting the fat elves in the RPM file. Instead, I think it would be
better to extend FHS to support parallell install of binaries in a way
that gives each arch its own file.

But still, regardless if you go with a new binary format or with "fat
filesystems", you end up blurring the line between native compilation
and cross-compilation. An extended FHS would probably have to deal with
that. (Fedora doesn't guarantee parallell install of -devel packages,
for example.)

/abo




From jamatos at fc.up.pt  Thu Oct 22 19:00:04 2009
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Thu, 22 Oct 2009 20:00:04 +0100
Subject: Major reorganization of TeX Live packages
In-Reply-To: <7ca14f9d0910221146h2394e584g89bfa455e93dee35@mail.gmail.com>
References: <7ca14f9d0910221146h2394e584g89bfa455e93dee35@mail.gmail.com>
Message-ID: <200910222000.04951.jamatos@fc.up.pt>

On Thursday 22 October 2009 19:46:29 Jiri Cerny wrote:
> Hi Jindrich,
> 
> (sorry for not replaying to the original message, I was reading the
> list through archives)
> 
> I was using TeXLive 2009 repository before, without any problem. After
> seeing your message,
> I followed the instruction
> 
> > In case you have an older TL2009 installed on your system from the
> > testing repository, please consider removing it and installing again.
> 
> and after 'yum install texlive' I get  a lot of missing dependencies.
> Installing texlive requires
> dvipdfm from the F12/rawhide repository, which requires kpathsea from
> the same repository and which in turn
> requires texlive-2007. Will it be fixed with texlive-2007-45 build?

You can get the texlive-2007-45 build  meanwhile with

koji download-build --arch=i686 137706

in this case arch=i686 refers to the architecture of the machine where I am 
testing texlive and 137706 refers to the id of the build for texlive-2007-45 
in f12 (it has been done for f10-13).

With this update of the selected packages the update for the new texlive 
works. :-)

> Jiri

-- 
Jos? Ab?lio



From tmraz at redhat.com  Thu Oct 22 19:19:35 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 22 Oct 2009 21:19:35 +0200
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
	<1256235589.14074.2.camel@vespa.frost.loc> 
Message-ID: <1256239175.14074.4.camel@vespa.frost.loc>

On Thu, 2009-10-22 at 13:39 -0500, Rex Dieter wrote: 
> Tomas Mraz wrote:
> 
> 
> > We could allow adding numbers after the dist tag in release for this
> > purpose.
> 
> That is already allowed, and encouraged, for branch-specific modfications,
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches

Heh, dunno why I thought it is disallowed. Then I don't see any problem
with enforcing n-v-r ordering during cvs tagging.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From awilliam at redhat.com  Thu Oct 22 19:30:59 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 12:30:59 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: <200910220917.12776.mhlavink@redhat.com>
References: 
	
	<1256160451.2314.421.camel@adam.local.net>
	<200910220917.12776.mhlavink@redhat.com>
Message-ID: <1256239859.2314.472.camel@adam.local.net>

On Thu, 2009-10-22 at 09:17 +0200, Michal Hlavinka wrote:

> > For the slow 2D performance - _how_ slow is it, really? gnome-terminal
> > has never been much of a speed demon. Does it get any faster if you boot
> > with 'nomodeset' as a kernel parameter?
> > 
> 
> Hi, 
> I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic 
> card, I was going to file new bug. With kms enabled, everything is really 
> sloooow, with 'nomodeset' it's much faster. I can't say exactly "how" slow it 
> is, is there anything I can use for measuring?

cairo-perf-trace is, afaik, the best we have:
http://cworth.org/intel/performance_measurement/

I'm not sure if bug reports on this are useful. To some extent, slow
performance with KMS on some chips is a known issue. Jerome, do you want
bug reports from people who have this problem, or would more reports not
provide any new information?

> btw, mesa-dri-drivers-experimental does not work at all for me (glx apps 
> segfault)

Your card's r700, not r600, so that's kind of expected; the current code
isn't expected to work well on r700 (possibly not at all, I'm not 100%
clear). r700 and r800 support should follow r600 relatively quickly,
though.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 19:32:50 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 12:32:50 -0700
Subject: extracting multiple sources in %setup
In-Reply-To: <9497e9990910220607m6ff4cd32q558eb6f260ade22d@mail.gmail.com>
References: 
	
	<9497e9990910220607m6ff4cd32q558eb6f260ade22d@mail.gmail.com>
Message-ID: <1256239970.2314.473.camel@adam.local.net>

On Thu, 2009-10-22 at 13:07 +0000, Mat Booth wrote:
> 2009/10/22 Orcan Ogetbil :
> > On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
> >> Hi,
> >>
> >> is there a way to extract multiple sources in a spec files %setup section?
> >>
> >> Something like:
> >>
> >> for i in {1..10}; do tar xfz %(SOURCE$i}; done
> >>
> >> Best Regards
> >> Marcus
> >>
> >
> > %setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9 -a 10
> >
> > should work. I don't if there's any nicer way.
> >
> > Orcan
> >
> 
> It's also perfectly acceptable to call the %setup macro more than
> once, if you need to.
> 
> There is some stuff in Max RPM about it:
> 
> http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-MULTI-SOURCE

Just a +1 for this as a general reference; I use it all the time. It's
the first Google result for 'rpm setup macro', if you ever lose the
bookmark. :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From jkeating at redhat.com  Thu Oct 22 19:47:45 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 12:47:45 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256236393.3871.9.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
	<1256236393.3871.9.camel@localhost.localdomain>
Message-ID: <1256240865.9182.12.camel@localhost.localdomain>

On Thu, 2009-10-22 at 11:33 -0700, Dan Williams wrote:
> 
> Good point.  SCM commit time (or tag time) with a CVS hook would be
> awesome as long as the hook was fast enough. 

Note, I didn't say "CVS", I said "SCM"  (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From zaitcev at redhat.com  Thu Oct 22 20:47:25 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 22 Oct 2009 14:47:25 -0600
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256230254.9182.5.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
Message-ID: <20091022144725.3973cf8b@redhat.com>

On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating  wrote:

> Hi all.  It has been brought to my attention that my description of my
> future vision of rawhide as explained here is much clearer than previous
> attempts (including the current "no frozen rawhide" wiki page). []

Actually, the "no frozen rawhide" was very clear and this message
just boggles the mind.

> What does this accomplish?  It provides a very easy release valve.
> Instead of closing the valve and building up pressure while we freeze,
> and tempting people to push things into our pending release that really
> don't belong, we'll provide them a normal, never ending release of
> pressure, called rawhide. []

Great, you made life of lazy developers easy. What about users of
Rawhide? I had Rawide installed on my main desktop since RHL 6.
What am I supposed to do now? What tree to run? Your proposal
has no guidelines for me (unlike the proposal to stop freezing
Rawhide, which IMHO had a lot of merit).

Note, I'm not interested in testing things "sometimes". If I did,
I would've been using RHEL WS or something. I want an always-useable
development tip tree.

The problem here is that Rawhide was a useful distribution for years.
We were Gentoo before Gentoo, minus meaningless recompiles. And now?

-- Pete



From dave at davidstark.name  Thu Oct 22 20:47:34 2009
From: dave at davidstark.name (David Stark)
Date: Thu, 22 Oct 2009 21:47:34 +0100
Subject: Eternal 'good file hashes' list
In-Reply-To: <20091021084702.43dcba99@dhcp03.addix.net>
References: <20091020084540.622d5d28@dhcp03.addix.net>	<80d7e4090910201640y6ecff107xb8c6a83c255df28b@mail.gmail.com>
	<20091021084702.43dcba99@dhcp03.addix.net>
Message-ID: <4AE0C4E6.7020001@davidstark.name>

On 10/21/2009 07:47 AM, Ralf Ertzinger wrote:
> Hi.
>
> On Tue, 20 Oct 2009 17:40:46 -0600, Stephen John Smoogen wrote:
>
>> In most cases, you can get that information from the original RPM
>> compared to the system... if you have the RPM :).
>>
>> rpm -Vp
>
> Which is pretty much what I want, just pulling the data from an external
> (signed) source instead of the local RPM database.
>

Sounds familiar. Solaris Fingerprint DB, anyone?

http://sunsolve.sun.com/fileFingerprints.do

Dave



From zaitcev at redhat.com  Thu Oct 22 20:48:51 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 22 Oct 2009 14:48:51 -0600
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <20091022144851.07b07f7f@redhat.com>

On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha  wrote:

> I just saw this article about an effort to create Universal binary style ELF
> binaries for Linux, and I thought that this would be something to watch, so
> that Fedora could integrate both x86-32 and x86-64 into single DVD sets.

Sounds like a kludge to work around limitations of dpkg.

-- Pete



From awilliam at redhat.com  Thu Oct 22 20:50:42 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 13:50:42 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: <1256244642.2314.491.camel@adam.local.net>

On Thu, 2009-10-22 at 19:56 +0800, Liang Suilong wrote:
> To Adam Williamson
> 
> I try to add kernel parameter nomodeset to turn off KMS. After logging
> in Gnome and run gnome-terminal, I can scroll up and down my mouse so
> smoothly. I do not feel scrolling in the terminal is slow. 

Thanks for testing. See my reply to Michal for the next steps: I'm
checking with Jerome Glisse whether it's necessary for you to file a bug
report in this case.

> We can sure that KMS for R600 cause the problem. But KMS in the
> mainline kernel is experimental. I believe that the bug will be fixed.
> Thanks to Fedora developers, I can enjoy compiz with  opensource
> drivers. 

Yes, this is something the developers are working on for sure.

> Another things, xorg-x11-drv-ati with mesa-dri-drivers-experimental
> seems not to ru gnome-shell. Does it mean that ATi opensource need
> more OpenGL extensions to stand for gnome-shell?

Well, on my test system it runs, but doesn't really work: there's a
known bug which stops any input to gnome-shell working (so basically you
can't _do_ anything with it, trying to click on any gnome-shell element
doesn't work). As I said, this is a known bug in the Mesa stuff which
should get fixed at some point. I imagine any other problem you're
seeing with gnome-shell is similar in nature. As mentioned, this code is
known to be pretty alpha :)

> Plymouth is so beautiful and smooth when I start up my Fedora 12,
> nevertheless, it does not work when I shutdown or reboot my box. I
> just can see a black screen or console status. How can I make plymouth
> run again?

This could be related to disabling KMS, I suppose, but I don't know any
more than that I'm afraid.

> ATi should learn Intel how to develop opensource drivers for their
> graphic card. The relationship between ati and radeonhd should be
> cooperation not competition. This is just my opinon. 

That's not quite the situation. The 'ati' driver is not written entirely
by ATI/AMD, it is a proper communally-developed driver to which our Red
Hat staff and others contribute significantly, based on information and
specifications provided by ATI/AMD.

'radeonhd' is essentially a competing driver. The history is that the
radeonhd driver came out before the ati/radeon driver (technically the
driver in question is called 'radeon', the "driver" called 'ati' is
really just a wrapper which loads either 'radeon', 'r128' or 'mach64'
depending on the hardware that's detected) gained any support for r500+
chips at all. (Actually, a driver called 'avivo' came before either of
those, but never mind that). After a while, the 'radeon' driver added
support for r500+ chips, so there are now two different open source
drivers, both officially part of the X.org project, which support r500+
devices. 'radeonhd' is supported by Novell and gets contributions from
Novell's paid developers, 'radeon' is more supported by Red Hat.

Obviously this isn't sustainable and eventually the two will merge
somehow, but for now there's two drivers, and Fedora supports 'radeon'.
'radeonhd' is really only available from the Fedora repositories for
research purposes.

The fact that there are two open source drivers is not the fault of
ATI/AMD in any way, they shouldn't take any blame for it. They have in
fact been moving in a very good direction lately, and their relationship
with the X development community is pretty much as good as Intel's now.
Neither 'radeon' nor 'radeonhd' would have developed to the point they
have without the help and support of ATI/AMD.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 20:56:20 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 13:56:20 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <4AE05D32.8090504@gmail.com>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan> <4ADF56C8.3060602@gmail.com>
	<19965.1256162829@sss.pgh.pa.us>  <4AE05D32.8090504@gmail.com>
Message-ID: <1256244980.2314.493.camel@adam.local.net>

On Thu, 2009-10-22 at 09:25 -0400, Lyos Gemini Norezel wrote:

> In this day and age? It's highly unusual for people to only have one.

I'd say it's rather more common than it used to be; many people don't
use ISP email any more, they just use a gmail or Yahoo! or whatever
account for everything.

Even when people have more than one, it's often the case they only have
one personal email and the other is a business address they can't use
for non-work-related purposes.

Those of us who've been collecting addresses from different ISPs and so
on for years are probably in the minority these days :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 21:05:20 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 14:05:20 -0700
Subject: Fedora Test Day Summary - Confined Users
In-Reply-To: <1597275399.1084641256220651432.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1597275399.1084641256220651432.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1256245520.2314.494.camel@adam.local.net>

On Thu, 2009-10-22 at 10:10 -0400, Eduard Benes wrote:
> Greetings!
> 
> This Tuesday was the "Confined Users" Test Day / Fit&Finish [1] (TD/F&F).
> Though we expected higher attendance, the results are really valuable.

I'm sorry I wasn't able to help publicise this test day much, it's been
a crazy week around here :( thanks for running it, though!

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 21:11:24 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 14:11:24 -0700
Subject: Fedora 12 Beta
In-Reply-To: 
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
	
	<1256163311.2314.439.camel@adam.local.net>
	
Message-ID: <1256245884.2314.495.camel@adam.local.net>

On Thu, 2009-10-22 at 10:26 -0500, Mike McGrath wrote:

> I don't remember if a bug got opened for that one or not, basically when
> firstboot loads the smolt module fails so it doesn't load.  It's
> attempting to import a deprecated library that doesn't exist.  It doesn't
> actually prevent any functionality other then users don't get prompted to
> enable smolt.  Firstboot continues as normal with license, create user,
> date time, etc.

Thanks - I added a note.
https://fedoraproject.org/wiki/Common_F12_bugs#firstboot-no-smolt

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 21:14:02 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 14:14:02 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256229826.9182.3.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
Message-ID: <1256246042.2314.497.camel@adam.local.net>

On Thu, 2009-10-22 at 09:43 -0700, Jesse Keating wrote:
> On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
> > What kind of checks do you mean? If maintainers want to keep their
> > packages, they can just change the owner of the package to their new
> > private account before leaving Red Hat. 
> 
> That assumes the maintainer knows they're leaving Red Hat ahead of time.

/me looks around nervously :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 22 21:18:23 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 14:18:23 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256230254.9182.5.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
Message-ID: <1256246303.2314.501.camel@adam.local.net>

On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:
> Hi all.  It has been brought to my attention that my description of my
> future vision of rawhide as explained here is much clearer than previous
> attempts (including the current "no frozen rawhide" wiki page).  So I
> felt it prudent to forward it along to the devel list for more eyes to
> look upon it and comment if desired.

I have two particular nits with it. One, it's pretty unwieldy,
especially for part time maintainers (thinking how many hoops we'll have
to jump through just to keep our packages up to date). Having to jump
through the Bodhi hoops every time we just want to put a trivial update
into a release that won't be coming out for five months feels like a
pain. I'd worry about a lot of stuff going stale and smelly in the
middle of the Bodhi process somewhere as maintainers lose track of where
the hell they're up to with the four releases they have to cope with
(the last two already-released releases, the upcoming release, and
"rawhide").

Two, it makes testing things a bit more complex. Those of us who like to
test upcoming stuff in real use - i.e. on our main machines - will have
to choose whether to test "rawhide", in which case we'll have more pain
to deal with ourselves and won't be contributing as much to testing of
the next stable release, or test the next stable release, in which case
we aren't helping maintainers by making sure the stuff they're putting
in "rawhide" isn't totally broken.

But overall, the positives could certainly outweigh the negatives. Just
thought I'd flag up the two major concerns I have in case anything could
be done about them.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From jkeating at redhat.com  Thu Oct 22 21:20:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 14:20:13 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <20091022144725.3973cf8b@redhat.com>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<20091022144725.3973cf8b@redhat.com>
Message-ID: <1256246413.9182.16.camel@localhost.localdomain>

On Thu, 2009-10-22 at 14:47 -0600, Pete Zaitcev wrote:
> On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating  wrote:
> 
> > Hi all.  It has been brought to my attention that my description of my
> > future vision of rawhide as explained here is much clearer than previous
> > attempts (including the current "no frozen rawhide" wiki page). []
> 
> Actually, the "no frozen rawhide" was very clear and this message
> just boggles the mind.
> 
> > What does this accomplish?  It provides a very easy release valve.
> > Instead of closing the valve and building up pressure while we freeze,
> > and tempting people to push things into our pending release that really
> > don't belong, we'll provide them a normal, never ending release of
> > pressure, called rawhide. []
> 
> Great, you made life of lazy developers easy. What about users of
> Rawhide? I had Rawide installed on my main desktop since RHL 6.
> What am I supposed to do now? What tree to run? Your proposal
> has no guidelines for me (unlike the proposal to stop freezing
> Rawhide, which IMHO had a lot of merit).
> 
> Note, I'm not interested in testing things "sometimes". If I did,
> I would've been using RHEL WS or something. I want an always-useable
> development tip tree.
> 
> The problem here is that Rawhide was a useful distribution for years.
> We were Gentoo before Gentoo, minus meaningless recompiles. And now?
> 
> -- Pete
> 

I wonder where your confusion comes from.  With this rewording of the
proposal, the proposal doesn't change.  Rawhide the path on the mirror
(pub/fedora/linux/releases/development/) never freezes, never stops.
It's always developmental and testing packages.  It is always there.  It
never freezes.  You can turn on that repo and just run with it from now
until you decide you don't want to use computers anymore.

The proposal, both wordings, say that we'll stop slowing down rawhide,
stop trying to use that path as a testing/polish point for a release.
We'll do that somewhere else and let rawhide keep flowing.

So you can continue to run rawhide all you want.  Your entry point to
rawhide may change slightly, you may have to start with the current
Fedora release or the current testing release for the next Fedora, and
then upgrade to the rawhide package set, but once you've done that you
just stick on rawhide and never look back.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From cra at WPI.EDU  Thu Oct 22 21:34:17 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 22 Oct 2009 17:34:17 -0400
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256229826.9182.3.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
Message-ID: <20091022213417.GC4199@angus.ind.WPI.EDU>

On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote:
> On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
> > What kind of checks do you mean? If maintainers want to keep their
> > packages, they can just change the owner of the package to their new
> > private account before leaving Red Hat. 
> 
> That assumes the maintainer knows they're leaving Red Hat ahead of time.

Perhaps no one should be using their @redhat.com address for Fedora 
work :-/



From mmcgrath at redhat.com  Thu Oct 22 21:42:16 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 22 Oct 2009 16:42:16 -0500 (CDT)
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091022213417.GC4199@angus.ind.WPI.EDU>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
Message-ID: 

On Thu, 22 Oct 2009, Chuck Anderson wrote:

> On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote:
> > On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
> > > What kind of checks do you mean? If maintainers want to keep their
> > > packages, they can just change the owner of the package to their new
> > > private account before leaving Red Hat.
> >
> > That assumes the maintainer knows they're leaving Red Hat ahead of time.
>
> Perhaps no one should be using their @redhat.com address for Fedora
> work :-/
>

We generally discourage it but several still do it.

	-Mike



From mrsam at courier-mta.com  Thu Oct 22 21:42:10 2009
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Thu, 22 Oct 2009 17:42:10 -0400
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<20091022144851.07b07f7f@redhat.com>
Message-ID: 

Pete Zaitcev writes:

> On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha  wrote:
> 
>> I just saw this article about an effort to create Universal binary style ELF
>> binaries for Linux, and I thought that this would be something to watch, so
>> that Fedora could integrate both x86-32 and x86-64 into single DVD sets.
> 
> Sounds like a kludge to work around limitations of dpkg.

Not really. Something like this would allow you to have a single boot image 
for both 32 and 64 bit hosts.

32 bits will be here for a long, long time, of course, but its days are 
numbered, so I don't think it makes practical sense to invest the effort in 
implementing "FAT" ELF format. There might be some practical benefit if its 
scope was expanded to support arbitrary binary ABIs, i.e. a single ELF image 
containing x86_64 and sparc64, perhaps.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From nicolas.mailhot at laposte.net  Thu Oct 22 21:42:22 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Oct 2009 23:42:22 +0200
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
 Project?"])
In-Reply-To: <1256246413.9182.16.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<20091022144725.3973cf8b@redhat.com>
	<1256246413.9182.16.camel@localhost.localdomain>
Message-ID: 



Le Jeu 22 octobre 2009 23:20, Jesse Keating a ?crit :

> So you can continue to run rawhide all you want.  Your entry point to
> rawhide may change slightly, you may have to start with the current
> Fedora release or the current testing release for the next Fedora, and
> then upgrade to the rawhide package set, but once you've done that you
> just stick on rawhide and never look back.

IMHO you should be honest and call your F-next rawhide, and find some other
name for the "experimental stuff" sandbox. Because your F-next is effectively
what rawhide has been since before Fedora, and your rawhide is what people who
do not care about releng have been trying to turn rawhide into in the past
years. Well they can get their no-rules playground but I don't see why we
should also give them the rawhide name. It has a fine history, much better
than the eating babies ogre caricature.

-- 
Nicolas Mailhot




From awilliam at redhat.com  Thu Oct 22 21:45:02 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 22 Oct 2009 14:45:02 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: 
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
Message-ID: <1256247902.2314.504.camel@adam.local.net>

On Thu, 2009-10-22 at 16:42 -0500, Mike McGrath wrote:

> > Perhaps no one should be using their @redhat.com address for Fedora
> > work :-/
> 
> We generally discourage it but several still do it.

Uh, we do? No-one's ever indicated that to me. Why would it be
discouraged? Doesn't RH like its contributions to Fedora to be clear?

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From berrange at redhat.com  Thu Oct 22 21:47:29 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 22 Oct 2009 22:47:29 +0100
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: 
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
Message-ID: <20091022214729.GA4286@redhat.com>

On Thu, Oct 22, 2009 at 04:42:16PM -0500, Mike McGrath wrote:
> On Thu, 22 Oct 2009, Chuck Anderson wrote:
> 
> > On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote:
> > > On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
> > > > What kind of checks do you mean? If maintainers want to keep their
> > > > packages, they can just change the owner of the package to their new
> > > > private account before leaving Red Hat.
> > >
> > > That assumes the maintainer knows they're leaving Red Hat ahead of time.
> >
> > Perhaps no one should be using their @redhat.com address for Fedora
> > work :-/
> >
> 
> We generally discourage it but several still do it.

Err surely just the opposite. At least anyone who works on both RHEL and
Fedora will use their @redhat.com address because they need this to be
able to see private BZ comments & most people don't want to constantly
be switching between 2 BZ account logins just to use alternate addr for
Fedora.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From nicolas.mailhot at laposte.net  Thu Oct 22 21:52:38 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Oct 2009 23:52:38 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256247902.2314.504.camel@adam.local.net>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<1256247902.2314.504.camel@adam.local.net>
Message-ID: <360daf16d5a4dbec16ae9624e8d942b3.squirrel@arekh.dyndns.org>



Le Jeu 22 octobre 2009 23:45, Adam Williamson a ?crit :
>
> On Thu, 2009-10-22 at 16:42 -0500, Mike McGrath wrote:
>
>> > Perhaps no one should be using their @redhat.com address for Fedora
>> > work :-/
>>
>> We generally discourage it but several still do it.
>
> Uh, we do? No-one's ever indicated that to me. Why would it be
> discouraged? Doesn't RH like its contributions to Fedora to be clear?

The right solution is just to have some manager as fallback address. Telling
people to use a non-rh address when their Fedora activity is linked to their
@rh work is ridiculous.

-- 
Nicolas Mailhot




From bruno at wolff.to  Thu Oct 22 21:55:22 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Oct 2009 16:55:22 -0500
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256234562.9182.9.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256234109.3871.8.camel@localhost.localdomain>
	<1256234562.9182.9.camel@localhost.localdomain>
Message-ID: <20091022215522.GA15763@wolff.to>

On Thu, Oct 22, 2009 at 11:02:42 -0700,
  Jesse Keating  wrote:
> 
> Yes, but it may happen before the bodhi stage, when we get autoqa
> working on post-build tests.  This kind of check could happen at SCM
> commit time, package build time, or finally bodhi push time.  Seems
> reasonable that we'd want to catch it as early as possible, but that
> does force people to work on rawhide first, then work on the pending
> release which may be under critical time pressure.  Certainly something
> to discuss.  Catching it at bodhi time seems too late.

The *.fcxx.1 trick can be used to work around that if necessary. That
may not be desirable though, as it seems to catch people by surprise.



From skvidal at fedoraproject.org  Thu Oct 22 22:26:54 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 22 Oct 2009 18:26:54 -0400 (EDT)
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <20091022214729.GA4286@redhat.com>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
Message-ID: 



On Thu, 22 Oct 2009, Daniel P. Berrange wrote:

> On Thu, Oct 22, 2009 at 04:42:16PM -0500, Mike McGrath wrote:
>> On Thu, 22 Oct 2009, Chuck Anderson wrote:
>>
>>> On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote:
>>>> On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote:
>>>>> What kind of checks do you mean? If maintainers want to keep their
>>>>> packages, they can just change the owner of the package to their new
>>>>> private account before leaving Red Hat.
>>>>
>>>> That assumes the maintainer knows they're leaving Red Hat ahead of time.
>>>
>>> Perhaps no one should be using their @redhat.com address for Fedora
>>> work :-/
>>>
>>
>> We generally discourage it but several still do it.
>
> Err surely just the opposite. At least anyone who works on both RHEL and
> Fedora will use their @redhat.com address because they need this to be
> able to see private BZ comments & most people don't want to constantly
> be switching between 2 BZ account logins just to use alternate addr for
> Fedora.
>

I actually have both.

rhel bugs get assigned to svidal at redhat.com
fedora bugs go to skvidal at sethdot.org

-sv





From eswierk at aristanetworks.com  Thu Oct 22 23:11:32 2009
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Thu, 22 Oct 2009 16:11:32 -0700
Subject: pxe-kexec
Message-ID: <9ae48b020910221611s5509ea3u50a42bd316d78f9d@mail.gmail.com>

A few months ago I put together a package for pxe-kexec, a tool that
uses kexec to boot already-running machine from a PXE server, which is
handy for kicking off OS installs remotely. The package has been
reviewed and is ready to go, except I'm not sponsored and haven't
found the time to become one.

Given my priorities I don't think I'd make a very responsive
maintainer for pxe-kexec, but if anyone is interested in stepping in,
please be my guest.

https://bugzilla.redhat.com/show_bug.cgi?id=508352

--Ed



From jonstanley at gmail.com  Thu Oct 22 23:14:56 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 22 Oct 2009 19:14:56 -0400
Subject: Plan for tomorrow's (20091023) FESCo meeting
Message-ID: 

Sorry for the late agenda.  Here's the plan for tomorrow's FESCo
meeting happening at 17:0UTC on irc.freenode.net

261	Followup on documenting FESCo decisions on wiki

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.



From jkeating at redhat.com  Thu Oct 22 23:19:19 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 16:19:19 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: 
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
Message-ID: <1256253559.9182.139.camel@localhost.localdomain>

On Thu, 2009-10-22 at 18:26 -0400, Seth Vidal wrote:
> I actually have both.
> 
> rhel bugs get assigned to svidal at redhat.com
> fedora bugs go to skvidal at sethdot.org 

Many people aren't willing to jump through the hoops necessary to manage
that separation.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jkeating at redhat.com  Thu Oct 22 23:41:03 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Oct 2009 16:41:03 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256246303.2314.501.camel@adam.local.net>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
Message-ID: <1256254863.9182.162.camel@localhost.localdomain>

On Thu, 2009-10-22 at 14:18 -0700, Adam Williamson wrote:
> 
> I have two particular nits with it. One, it's pretty unwieldy,
> especially for part time maintainers (thinking how many hoops we'll have
> to jump through just to keep our packages up to date). Having to jump
> through the Bodhi hoops every time we just want to put a trivial update
> into a release that won't be coming out for five months feels like a
> pain. 

Who said anything about 5 months.  3 months max, which is just slightly
longer than the amount of time they spend now doing Trac tickets to get
something in.

> I'd worry about a lot of stuff going stale and smelly in the
> middle of the Bodhi process somewhere as maintainers lose track of where
> the hell they're up to with the four releases they have to cope with
> (the last two already-released releases, the upcoming release, and
> "rawhide").

"rawhide" would never use bodhi.  If you build in devel/ it shows up in
rawhide the next day.  End of story.  Bodhi would only be used for the
pending and already done releases.

> 
> Two, it makes testing things a bit more complex. Those of us who like to
> test upcoming stuff in real use - i.e. on our main machines - will have
> to choose whether to test "rawhide", in which case we'll have more pain
> to deal with ourselves and won't be contributing as much to testing of
> the next stable release, or test the next stable release, in which case
> we aren't helping maintainers by making sure the stuff they're putting
> in "rawhide" isn't totally broken.

For people like you, you'd just keep jumping when we branch off the next
release.  Like it or not, this is happening /already/.  dist-f13 already
has 953 packages with updates, and it isn't published /anywhere/
for /anybody/ to test it.  We can only make that better, not worse.

> 
> But overall, the positives could certainly outweigh the negatives. Just
> thought I'd flag up the two major concerns I have in case anything could
> be done about them.
> 


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From maxamillion at gmail.com  Fri Oct 23 00:18:26 2009
From: maxamillion at gmail.com (Adam Miller)
Date: Thu, 22 Oct 2009 19:18:26 -0500
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
	Project?"])
In-Reply-To: <1256254863.9182.162.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
	<1256254863.9182.162.camel@localhost.localdomain>
Message-ID: 

I think this is an awesome idea, and yes I think this "version" of the
verbage is more clear. Kudos to Jesse (and all those involved in the
development of the idea of the "split rawhide") and I hope to see this
come to fruition.

-Adam

-- 
http://maxamillion.googlepages.com
---------------------------------------------------------
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From xjakub at fi.muni.cz  Fri Oct 23 00:29:49 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Fri, 23 Oct 2009 02:29:49 +0200
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <1256232577.2497.43.camel@samson.armitage.org.uk>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
Message-ID: <4AE0F8FD.9040801@fi.muni.cz>

Hi,

On 22.10.2009 19:29, Quentin Armitage wrote:
> 1. Is the script that is run and produces the output at
> http://jkeating.fedorapeople.org/needed-f12-rebuilds.html actually the
> script referred to at the bottom of that page
> (https://fedorahosted.org/rel-eng/browser/scripts) ? The reason I ask is
> that when I run the script, I get
>
> Included Koji instances:
> http://koji.fedoraproject.org/kojihub
> http://sparc.koji.fedoraproject.org/kojihub
> http://s390.koji.fedoraproject.org/kojihub
> http://arm.koji.fedoraproject.org/kojihub
>
> whereas the posted output only has
> Included Koji instances:
> http://koji.fedoraproject.org/kojihub
> http://sparc.koji.fedoraproject.org/kojihub

It is, but Jesse has disabled the other Koji hubs because sometimes they 
just time out, unfortunately.

> 2. If the script is run against just koji.fedoraproject,org/kojihub
> (i.e. without the sub arches), it says 185 packages need
> rebuilding (instead of the 175 listed in the report); the following
> 10 packages are omitted when the sparc koji hub is also included:
> gmpc
> HippoDraw
> itcl
> latex2rtf
> prtconf
> PyKDE
> python-igraph
> silo
> spicebird
> xorg-x11-drv-sunffb
>
> This is caused by line 117 of the script:
>          unbuilt = unbuilt&  unbuiltnew
> so if a package needs to be rebuilt on the primary arch, but not on the
> (in this case sparc) secondary arch, then it is dropped from needing to
> be rebuilt

Yes, that's how I did it -- my primary goal was to clear the list off 
secondary-arch-only stuff. There might be of course some cases like if 
somebody rebuilds a package only for a secondary arch but not for the 
primary one, but I don't think this is much a problem (there won't be 
many compared to the -- increasing -- number of secondary-arch-only 
stuff which we won't need).

  (it appears that a package will only be listed if it needs
> to be rebuild on every arch).

No, the package appears if there is no build after the specified date in 
any of the archs (to be clear: as soon as the package is built in at 
least one arch, it will get off the list).

  There are several circumstances where this
> can happen (with the 10 missing packages listed):
>
> Built on sub arch but failed on primary arch
> ============================================
> gmpc - 0.18.0-1 build on sparc after epoch but 0.18.0-2 failed on koji
> HippoDraw
> itcl
> latex2rtf
> python-igraph

Yes, those are not caught by this script now and should be rebuilt in 
primary arch as well of course.

> Not a primary arch package (should the package be blocked in the primary
> arch kojihub?)
> ==========================
> prtconf
> silo
> xorg-x11-drv-sunffb

There are much more of them! I don't know whether it is possible to 
block a package in a single Koji hub and if our infrastructure team is 
willing to go in this way -- Jesse?

> Blocked on secondary arch (so not included in unbuiltnew)
> =========================
> spicebird

Should be probably blocked in all hubs too. The blocking mechanism 
definitely doesn't serve instead of ExcludeArch, am I right?

> Built on sub arch but not submitted for rebuild on primary arch
> ================================================================
> PyKDE

Should be rebuilt (I just started the build).

> Package does not exist in secondary arch (no example)
> =====================================================
>
> Would it be more relevant to list what needs to be rebuild separately
> for each arch (but see point 3 below)?
> 3. So far as I can see, there have not been mass rebuilds on the
> secondary arches, so is it relevant to search them for successful builds
> since the epoch? If it is relevant, they would appear to have different
> epochs in any case.

Well, when I got to modifying the script (about half a year ago), the 
main problem was that there was too much noise consisting in 
secondary-arch-only packages. At that time there were more than 100 of 
such builds which is quite a lot.

Also, secondary archs (re)builds are completely in the hands of 
secondary arch maintainers, they're not bound to the primary archs mass 
rebuilds.

> 5. I have looked at the 185 packages that have not been rebuilt, and the
> reasons fall into the following categories (details for each package are
> listed later):
> 1. Not submitted for rebuild (65)

Yeah, there were some problems during the mass rebuild, IIRC (esp. with 
packages starting with o*, p* and maybe others). They should be 
definitely rebuilt. Looking at your lists, when rebuilding packages you 
should be aware of:

1) secondary-arch-only packages (xorg-x11-drv-sun*)
2) dead packages not blocked in Koji (a package is dead iff there is a 
dead.package file in the CVS; if it is then not blocked in Koji, please 
report to Jesse).
3) packages not built yet because they've just passed the review.

> I have made some changes to need-rebuild.py to produce some of the
> information above, and am happy to provide them if they are of any
> interest.

Great! The more people get involved, the better:)

Regards,
Milos



From Scott_Collier at Dell.com  Fri Oct 23 01:30:25 2009
From: Scott_Collier at Dell.com (Scott_Collier at Dell.com)
Date: Thu, 22 Oct 2009 20:30:25 -0500
Subject: pxe-kexec
In-Reply-To: <9ae48b020910221611s5509ea3u50a42bd316d78f9d@mail.gmail.com>
References: <9ae48b020910221611s5509ea3u50a42bd316d78f9d@mail.gmail.com>
Message-ID: <2CF37B2A81883A44953060200A4507D701270710@ausx3mps335.aus.amer.dell.com>

I'll take it if that's ok.  I'm new to packaging and looking for more
experience.

-Scott



>-----Original Message-----
>From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
>bounces at redhat.com] On Behalf Of Ed Swierk
>Sent: Thursday, October 22, 2009 6:12 PM
>To: Development discussions related to Fedora
>Subject: pxe-kexec
>
>A few months ago I put together a package for pxe-kexec, a tool that
>uses kexec to boot already-running machine from a PXE server, which is
>handy for kicking off OS installs remotely. The package has been
>reviewed and is ready to go, except I'm not sponsored and haven't
>found the time to become one.
>
>Given my priorities I don't think I'd make a very responsive
>maintainer for pxe-kexec, but if anyone is interested in stepping in,
>please be my guest.
>
>https://bugzilla.redhat.com/show_bug.cgi?id=508352
>
>--Ed
>
>--
>fedora-devel-list mailing list
>fedora-devel-list at redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-devel-list



From mmcgrath at redhat.com  Fri Oct 23 02:05:47 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 22 Oct 2009 21:05:47 -0500 (CDT)
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
 Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
	<1256254863.9182.162.camel@localhost.localdomain>
	
Message-ID: 

On Thu, 22 Oct 2009, Adam Miller wrote:

> I think this is an awesome idea, and yes I think this "version" of the
> verbage is more clear. Kudos to Jesse (and all those involved in the
> development of the idea of the "split rawhide") and I hope to see this
> come to fruition.
>

I agree, how can I help?

	-Mike



From skvidal at fedoraproject.org  Fri Oct 23 02:10:50 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Thu, 22 Oct 2009 22:10:50 -0400 (EDT)
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256253559.9182.139.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
	<1256253559.9182.139.camel@localhost.localdomain>
Message-ID: 



On Thu, 22 Oct 2009, Jesse Keating wrote:

> On Thu, 2009-10-22 at 18:26 -0400, Seth Vidal wrote:
>> I actually have both.
>>
>> rhel bugs get assigned to svidal at redhat.com
>> fedora bugs go to skvidal at sethdot.org
>
> Many people aren't willing to jump through the hoops necessary to manage
> that separation.

I comment on all bugs from .redhat.com so there is less hoop jumping.

but I get your point.

-sv



From kevin.kofler at chello.at  Fri Oct 23 02:17:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Oct 2009 04:17:52 +0200
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	
	<8278b1b0910221119h66172ec6r1d595c193b2352ee@mail.gmail.com>
Message-ID: 

King InuYasha wrote:
> I dunno, it could be useful for Live CDs/USBs. It would let you pack
> multiple arches onto a single LiveCD/USB.

The Live CDs are already full without supporting this completely useless 
"feature".

Surely, the real solution is to position the 64-bit version more prominently 
(instead of driving everyone to the obsolescent 32-bit version), not to 
bloat the CDs with double-size binaries.

> You sound like one of those crazy people that disregard everything that
> may slightly help proprietary software.

I don't see why we should ship our own binaries in a format which ONLY helps 
proprietary software. They can ship whatever they want if they can get the 
kernel to accept their nonstandard ELF.

(That said, it's true that I also do think supporting anything which only 
helps proprietary software is counterproductive. This also includes some 
stuff we're currently doing, like shipping ancient compat-libstdc++ 
versions. We need to encourage third-party developers to ship Free Software, 
not proprietary software! But that wasn't even the point here, supporting 
Fat ELF isn't what I primarily object to, using it is!)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 23 02:22:14 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Oct 2009 04:22:14 +0200
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<20091022144851.07b07f7f@redhat.com>
	
Message-ID: 

Sam Varshavchik wrote:
> 32 bits will be here for a long, long time, of course

At most 29 years. 32-bit GNU/Linux doesn't support dates beyond 2038.

        Kevin Kofler



From maxamillion at gmail.com  Fri Oct 23 02:29:32 2009
From: maxamillion at gmail.com (Adam Miller)
Date: Thu, 22 Oct 2009 21:29:32 -0500
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
	Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
	<1256254863.9182.162.camel@localhost.localdomain>
	
	
Message-ID: 

I would also like to jump on the help train if there is anything I am able
to lend a hand with.

-Adam (From Android)

On Oct 22, 2009 9:05 PM, "Mike McGrath"  wrote:

On Thu, 22 Oct 2009, Adam Miller wrote: > I think this is an awesome idea,
and yes I think this "ve...
I agree, how can I help?

       -Mike

-- fedora-devel-list mailing list fedora-devel-list at redhat.com
https://www.redhat.com/mailman/list...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin.kofler at chello.at  Fri Oct 23 02:20:18 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Oct 2009 04:20:18 +0200
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<1256237238.24658.837.camel@tempo.alexander.bostrom.net>
Message-ID: 

Alexander Bostr?m wrote:
> There's already lib / lib64 for parallell-installation of libraries,
> though granted it's limited to only two arches, but yes, something that
> covers bin too would be useful.

bin is not multilib for a reason. You don't need 32-bit binaries on a 64-bit 
machine unless there's no 64-bit version.

        Kevin Kofler



From greno at verizon.net  Fri Oct 23 03:49:59 2009
From: greno at verizon.net (Gerry Reno)
Date: Thu, 22 Oct 2009 23:49:59 -0400
Subject: Packaging Survey - May 2009
In-Reply-To: <604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
References: <4A1D24AC.4090802@fedoraproject.org>
	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
Message-ID: <4AE127E7.8080805@verizon.net>

Jeff Spaleta wrote:
> On Wed, May 27, 2009 at 3:31 AM, Rahul Sundaram
>  wrote:
>   
>> Hi
>>
>> I did a quick survey from Fedora on what software Fedora users are using
>> that is not available in the repo. Here are the results. If you find
>> anything interesting, feel free to pick it up.
>>
>> https://fedoraproject.org/wiki/Packaging_Survey_May_2009
>>     
>
>
> eucalyptus has a non-trivial list of java deps that we don't have
> packaged yet. I looked at the 1.5 pre-release tarballs in launchpad
> before ecualyptus opened up its bzr trees to the public.  Ubuntu seems
> to have initially solved this problem in a way that our packaging
> review process would definitely not allow. They lumped a lot of
> individual java codebased together into a single package in order to
> streamline the effort to get eucalyptus into universe.
> http://packages.ubuntu.com/jaunty/eucalyptus-javadeps
>
> It would take a concerted effort of a number of contributors with
> reasonable java packaging experience to work together and coordinate
> package reviews to build up the complete set of java packages needed
> for full eucalyptus functionality. I would definitely not be among
> them.  If people are serious about it. I really suggest they start
> forming up a team and start working on it now with F12 as a target
> release for the first full set of packages.
>
> -jef
>
>   

Did eucalyptus ever get packaged for F12 ?

I didn't find anything in rawhide today when I checked it.




From bruno at wolff.to  Fri Oct 23 06:22:35 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 23 Oct 2009 01:22:35 -0500
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256246303.2314.501.camel@adam.local.net>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
Message-ID: <20091023062235.GA27104@wolff.to>

On Thu, Oct 22, 2009 at 14:18:23 -0700,
  Adam Williamson  wrote:
> 
> Two, it makes testing things a bit more complex. Those of us who like to
> test upcoming stuff in real use - i.e. on our main machines - will have
> to choose whether to test "rawhide", in which case we'll have more pain
> to deal with ourselves and won't be contributing as much to testing of
> the next stable release, or test the next stable release, in which case
> we aren't helping maintainers by making sure the stuff they're putting
> in "rawhide" isn't totally broken.

The impression I got (which might be wrong), is that it was expected that
people would test specific packages from rawhide and not be expected to
be running it all at once. Porbably the best equvialent to current rawhide
would be enabling updates-testing for the pending release. People that
needed some that wouldn't break unexpectedly, but still wanted to try out
the new stuff could run the pending release without updates-testing.



From mcepl at redhat.com  Fri Oct 23 07:24:06 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:24:06 +0200
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora  
 Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>	<1256246303.2314.501.camel@adam.local.net>	<1256254863.9182.162.camel@localhost.localdomain>
	
Message-ID: 

Dne 23.10.2009 02:18, Adam Miller napsal(a):
> I think this is an awesome idea, and yes I think this "version" of the
> verbage is more clear. Kudos to Jesse (and all those involved in the
> development of the idea of the "split rawhide") and I hope to see this
> come to fruition.

Just wanted to add my +1 and this is as good place as any other.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Experience is what you get when you don't get what you want.
   -- Dan Stanford



From mcepl at redhat.com  Fri Oct 23 07:27:16 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:27:16 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <4AE15AD4.9030907@redhat.com>

Dne 22.10.2009 19:28, King InuYasha napsal(a):
> I just saw this article about an effort to create Universal binary style
> ELF binaries for Linux, and I thought that this would be something to
> watch, so that Fedora could integrate both x86-32 and x86-64 into single
> DVD sets.
> 
> http://icculus.org/fatelf/
> 
> There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit
> and 64-bit kernels and all the apps compiled as FatELF binaries

Wandering minds ask what is it good for? I hoped that with Snow Leopard
being intel-only Apple Universal Binaries will finally wither to bad
memories of past (somewhere around the Berlin Wall and Third Reich :)),
and that whole concept of multilib will follow in due course after them.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
    -- Tim Hansel



From mcepl at redhat.com  Fri Oct 23 07:27:16 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:27:16 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <4AE15AD4.9030907@redhat.com>

Dne 22.10.2009 19:28, King InuYasha napsal(a):
> I just saw this article about an effort to create Universal binary style
> ELF binaries for Linux, and I thought that this would be something to
> watch, so that Fedora could integrate both x86-32 and x86-64 into single
> DVD sets.
> 
> http://icculus.org/fatelf/
> 
> There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit
> and 64-bit kernels and all the apps compiled as FatELF binaries

Wandering minds ask what is it good for? I hoped that with Snow Leopard
being intel-only Apple Universal Binaries will finally wither to bad
memories of past (somewhere around the Berlin Wall and Third Reich :)),
and that whole concept of multilib will follow in due course after them.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
    -- Tim Hansel



From mcepl at redhat.com  Fri Oct 23 07:32:27 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:32:27 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256253559.9182.139.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>	<20091021181022.GA7460@clingman.lan>	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>	<1256229826.9182.3.camel@localhost.localdomain>	<20091022213417.GC4199@angus.ind.WPI.EDU>		<20091022214729.GA4286@redhat.com>	
	<1256253559.9182.139.camel@localhost.localdomain>
Message-ID: <4AE15C0B.80901@redhat.com>

Dne 23.10.2009 01:19, Jesse Keating napsal(a):
> Many people aren't willing to jump through the hoops necessary to manage
> that separation.

And there is surely nothing wrong with giving a little bit of PR to our
dear employer :).

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

This conversation can serve no purpose anymore. Good bye.
    -- HAL9000 in 2001: Space Odyssea



From mcepl at redhat.com  Fri Oct 23 07:31:13 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:31:13 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: 
References: <1256116297.2716.10.camel@localhost.localdomain>	<20091021181022.GA7460@clingman.lan>	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>	<1256229826.9182.3.camel@localhost.localdomain>	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
Message-ID: 

Dne 22.10.2009 23:42, Mike McGrath napsal(a):
> We generally discourage it but several still do it.

Who are "we" you are talking about? I was given exactly opposite
information.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Always make new mistakes
   -- Esther Dyson



From mcepl at redhat.com  Fri Oct 23 07:32:27 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 23 Oct 2009 09:32:27 +0200
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256253559.9182.139.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>	<20091021181022.GA7460@clingman.lan>	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>	<1256229826.9182.3.camel@localhost.localdomain>	<20091022213417.GC4199@angus.ind.WPI.EDU>		<20091022214729.GA4286@redhat.com>	
	<1256253559.9182.139.camel@localhost.localdomain>
Message-ID: <4AE15C0B.80901@redhat.com>

Dne 23.10.2009 01:19, Jesse Keating napsal(a):
> Many people aren't willing to jump through the hoops necessary to manage
> that separation.

And there is surely nothing wrong with giving a little bit of PR to our
dear employer :).

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

This conversation can serve no purpose anymore. Good bye.
    -- HAL9000 in 2001: Space Odyssea



From sundaram at fedoraproject.org  Fri Oct 23 07:43:49 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 23 Oct 2009 13:13:49 +0530
Subject: Packaging Survey - May 2009
In-Reply-To: <4AE127E7.8080805@verizon.net>
References: <4A1D24AC.4090802@fedoraproject.org>	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
	<4AE127E7.8080805@verizon.net>
Message-ID: <4AE15EB5.6050503@fedoraproject.org>

On 10/23/2009 09:19 AM, Gerry Reno wrote:

> Did eucalyptus ever get packaged for F12 ?
> 
> I didn't find anything in rawhide today when I checked it.

Nobody volunteered yet.

Rahul



From zaitcev at redhat.com  Fri Oct 23 08:07:31 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 23 Oct 2009 02:07:31 -0600
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
 Project?"])
In-Reply-To: <1256246413.9182.16.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	<20091022144725.3973cf8b@redhat.com>
	<1256246413.9182.16.camel@localhost.localdomain>
Message-ID: <20091023020731.1555c6c8@redhat.com>

On Thu, 22 Oct 2009 14:20:13 -0700, Jesse Keating  wrote:

> I wonder where your confusion comes from.  With this rewording of the
> proposal, the proposal doesn't change. []

> So you can continue to run rawhide all you want.  Your entry point to
> rawhide may change slightly, you may have to start with the current
> Fedora release or the current testing release for the next Fedora, and
> then upgrade to the rawhide package set, but once you've done that you
> just stick on rawhide and never look back.

That works for me, thanks a lot.

-- Pete



From swhiteho at redhat.com  Fri Oct 23 08:28:29 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Fri, 23 Oct 2009 09:28:29 +0100
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <4AE15C0B.80901@redhat.com>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
	<1256253559.9182.139.camel@localhost.localdomain>
	<4AE15C0B.80901@redhat.com>
Message-ID: <1256286509.2726.3.camel@localhost.localdomain>

Hi,

On Fri, 2009-10-23 at 09:32 +0200, Mat?j Cepl wrote:
> Dne 23.10.2009 01:19, Jesse Keating napsal(a):
> > Many people aren't willing to jump through the hoops necessary to manage
> > that separation.
> 
> And there is surely nothing wrong with giving a little bit of PR to our
> dear employer :).
> 
> Mat?j

Indeed, I think thats a good plan. Also, as a suggestion of a suitable
way to deal with this issue, the simplest solution would be to have a
word with someone in HC and ask them to add to their standard list of
questions for those leaving the company. They can then pass on the
information regarding who wants to continue or give up their fedora
maintainerships at that point in time. It would also serve as a reminder
to those involved to change the email address to which their FAS account
is attached before they lose the ability to access it.

Does that sound like a reasonable solution?

Steve.




From jnovy at redhat.com  Fri Oct 23 10:04:15 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Fri, 23 Oct 2009 12:04:15 +0200
Subject: Major reorganization of TeX Live packages
In-Reply-To: <7ca14f9d0910221146h2394e584g89bfa455e93dee35@mail.gmail.com>
References: <7ca14f9d0910221146h2394e584g89bfa455e93dee35@mail.gmail.com>
Message-ID: <20091023100414.GA24724@dhcp-lab-133.englab.brq.redhat.com>

Hi Jiri,

On Thu, Oct 22, 2009 at 08:46:29PM +0200, Jiri Cerny wrote:
> Hi Jindrich,
> 
> (sorry for not replaying to the original message, I was reading the
> list through archives)
> 
> I was using TeXLive 2009 repository before, without any problem. After
> seeing your message,
> I followed the instruction
> 
> > In case you have an older TL2009 installed on your system from the
> > testing repository, please consider removing it and installing again.
> 
> and after 'yum install texlive' I get  a lot of missing dependencies.

This is likely caused by the not up-to-date yum cache, please clean it
with "yum clean all" and try again.

> Installing texlive requires
> dvipdfm from the F12/rawhide repository, which requires kpathsea from
> the same repository and which in turn
> requires texlive-2007. Will it be fixed with texlive-2007-45 build?

Yes, it is fixed since texlive-2007-45 and on. Just upgrading the
kpathsea library itself to 2007-45 should suffice in most cases. You
can use packages from here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=137908

directly or by installing the new kpathsea via yum from updates-testing.
(You needn't to install the main TL2007 packages)

> Another, probably related issue: Why there is not a xdvi (and also
> dvipdfm) binary in the Texlive 2009 repository. Should one use the
> one from F12? This seems strange to me to have such mixture of 2007
> and 2009 versions.

It is intentional, because you can now use old applications (not yet
rebuilt against new kpathsea) together with TL2009. Up to now you
needed to remove all applications dependent on kpathsea because of its
dependency on TL2007 which is removed now.

> 
> Jiri
> 

Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From rawhide at fedoraproject.org  Fri Oct 23 11:54:20 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 23 Oct 2009 11:54:20 +0000
Subject: rawhide report: 20091023 changes
Message-ID: <20091023115420.GA27708@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 23 06:15:16 UTC 2009

Broken deps for i386
----------------------------------------------------------
	openscada-visStation-0.6.4-3.fc12.i686 requires openscada-Special-FlibSYS



Broken deps for x86_64
----------------------------------------------------------
	openscada-visStation-0.6.4-3.fc12.x86_64 requires openscada-Special-FlibSYS






Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package cvc3
        Validity checker of many-sorted first-order formulas with theories
New package django-flash
        A Django extension to provide support for Rails-like flash
New package django-typepad
        A helper Django app for making TypePad applications
New package evolution-couchdb
        An evolution backend to CouchDBs for PIM information
New package mingw32-freeglut
        Fedora MinGW alternative to the OpenGL Utility Toolkit (GLUT)
New package python-batchhttp
        Parallel fetching of HTTP resources through MIME multipart
New package python-oauth
        Library for OAuth version 1.0a
New package python-remoteobjects
        An Object RESTational Model
New package python-tg-devtools
        Development tools and templates for TurboGears2
New package python-typepad
        Connectivity to the TypePad API through remote objects
New package typepad-motion
        A microblogging application for building online communities
Updated Packages:

blazeblogger-1.0.0-1.fc12
-------------------------
* Wed Oct 21 2009 Sebastian Dziallas  1.0.0-1
- update to new upstream release


evince-2.28.1-3.fc12
--------------------
* Thu Oct 22 2009 Matthias Clasen  - 2.28.1-2
- Provide some hint if search is not available

* Thu Oct 22 2009 Marek Kasik  - 2.28.1-3
- Add evince-thumbnail-allocation.patch (checks whether
- GdkPixbuf was allocated correctly)


f-spot-0.6.1.3-1.fc12
---------------------
* Sun Oct 04 2009 Christian Krause  - 0.6.1.3-1
- Update to 0.6.1.3 (BZ 526217)
- Remove two upstreamed patches
- Use a slightly different fix for the cairo-devel dependency 
  (suggested by upstream)

* Wed Sep 30 2009 Christian Krause  - 0.6.1.2-3
- Add patch to fix f-spot crash when using "soft focus" and cairo-devel
  was not installed (BZ 526563)
- Minor spec file beautification


febootstrap-2.5-2.fc12
----------------------
* Thu Oct 22 2009 Richard Jones  - 2.5-2
- New upstream release 2.5.
- Remove BR upx (not needed by upstream).
- Two more scripts / manpages.


gstreamer-plugins-flumpegdemux-0.10.15-8.fc12
---------------------------------------------
* Thu Oct 22 2009 Bastien Nocera  0.10.15-8
- Update code from gst-plugins-bad


gstreamer-plugins-good-0.10.16-5.fc12
-------------------------------------
* Thu Oct 22 2009 Bastien Nocera  0.10.16-5
- Update farsight plugins from -bad
- Drop copy/pasted rtpmanager plugin, it's now in -good


gtk2-2.18.3-8.fc12
------------------
* Thu Oct 22 2009 Peter Hutterer  - 2.18.3-8
- compose-sequences.patch: update compose sequences to what's currently in
  libX11 git.


kdelibs-4.3.2-4.fc12
--------------------
* Mon Oct 12 2009 Luk?? Tinkl  - 4.3.2-4
- khtml kpart crasher nr. 2 (rev.1033984)


parole-0.1.90-3.fc12
--------------------

python-tw-forms-0.9.8-1.fc12
----------------------------
* Thu Oct 01 2009 Luke Macken  - 0.9.8-1
- 0.9.8

* Wed Aug 12 2009 Luke Macken  - 0.9.7.2-1
- 0.9.7.2


roundcubemail-0.3-2.fc12
------------------------
* Thu Oct 22 2009 Jon Ciesla  = 0.3-2
- Macro fix, BZ530037.


smolt-1.4-4.fc12
----------------
* Tue Oct 13 2009 Mike McGrath  1.4-4
- Fixing firstboot for F-12


sugar-0.86.3-1.fc12
-------------------
* Wed Oct 21 2009 Sebastian Dziallas  - 0.86.3-1
- Sporadic freezes while scrolling journal #1506
- Suppress race condition with Journal appearing on sugar startup #1373
- Alt+Space not working to show/hide the tray #1476


sugar-toolkit-0.86.2-1.fc12
---------------------------
* Wed Oct 21 2009 Sebastian Dziallas  - 0.86.2-1
- Do not stop processing motion-notify-event #1507


telepathy-gabble-0.8.7-1.fc12
-----------------------------
* Wed Oct 14 2009 Brian Pepple  - 0.8.7-1
- Update to 0.8.7.

* Fri Oct 09 2009 Brian Pepple  - 0.8.6-1
- Update to 0.8.6.


virtaal-0.4.1-1.fc12
--------------------
* Fri Oct 16 2009 Dwayne Bailey  - 0.4.1-1
- Update to 0.4.1
   - New translations: Turkish, Finnish, Vietnamese
   - Updated translations: Russian, Dutch and Zulu
   - More complete handling of "recent files" (bug 1120)
   - Better alignment with the GNOME human interface guidelines (bug 1095)
   - More reliable ways of obtaining the default font settings (bug 1092)
   - Better handling of HTML tags in the Apertium MT module
   - Small layout improvements (bug 1045, 1138)
- Depend on Translate Toolkit 1.4.1 for fixes to XLIFF, placeable and tmserver


Summary:
Added Packages: 11
Removed Packages: 0
Modified Packages: 16



From terry1 at beam.ltd.uk  Fri Oct 23 13:08:23 2009
From: terry1 at beam.ltd.uk (Terry Barnaby)
Date: Fri, 23 Oct 2009 14:08:23 +0100
Subject: Fedora 12 Beta
In-Reply-To: <596b53e0910211549t1c31d532w32bfed895b8b5d08@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>	<1256160900.2314.427.camel@adam.local.net>
	<596b53e0910211549t1c31d532w32bfed895b8b5d08@mail.gmail.com>
Message-ID: <4AE1AAC7.5030601@beam.ltd.uk>

On 10/21/2009 11:49 PM, Micha? Piotrowski wrote:
> 2009/10/21 Adam Williamson:
>> On Wed, 2009-10-21 at 12:31 +0200, Micha? Piotrowski wrote:
>>> I guess this is a plymouth bug. I disabled it in grub conf and system
>>> works correctly. Is there any chance to completely remove plymouth
>>> from the system? (even from initrd)
>>
>> > From a quick look, we don't have a bug filed for the fact that entering
>> the root password at this point doesn't work with Plymouth. Could you
>> please file one with a full description, and mark it as blocking
>> F12Blocker? Thanks.
>
> Here is a bug report
> https://bugzilla.redhat.com/show_bug.cgi?id=530224
>
> I don't know how to mark it as a blocker.
>
>>
>>> 4 - F12 boots really slow on my laptop
>>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
>>> wrong is happening while udev loading
>>
>> Please file a bug for this, on 'udev' component for now, and CC Harald
>> Hoyer (hhoyer at redhat). Thanks!
>>
Note that on my Thinkpad R52 Laptop F11 started doing this after
a udev RPM update. It turned out to be the fact that there was no
floppy drive in my system but the BIOS was configured with one
enabled. I suspect this is default in some laptops so that
docking stations etc work ??
I think this bug is in Bugzilla, but I suspect it has not
been fixed ...

>
> Done
> https://bugzilla.redhat.com/show_bug.cgi?id=530226
>
>>> 5 - default gnome sound scheme is terrible
>>
>> This is a pretty subjective topic.
>
> Yes, I know :)
>
> Regards,
> Michal
>



From mbacovsk at redhat.com  Fri Oct 23 14:28:33 2009
From: mbacovsk at redhat.com (Martin Bacovsky)
Date: Fri, 23 Oct 2009 16:28:33 +0200
Subject: Action Tags concept for Fedora PkgDB
Message-ID: <200910231628.33254.mbacovsk@redhat.com>

Hi,

I am working on online application database which is becoming part of Fedora PkgDB.

Online Application Database was separate project called Amber in the past, but as there had been 
similar features developed in the Fedora PkgDB, we decided to merge our efforts. 

In Amber definition there is suggested different concept of apps organization. I like the rasoning 
there and would like to implement it in pkgdb. I'd like to know your opinion on this. 

In Online Application Database definition, there are defined two primary use cases I am trying to 
address:

1/ I want to do 'X' with my computer.
    Where 'X' might be quite complex task like 'Import videos from my camera and put them on 
YouTube'

2/ I can already do 'X' with my computer, but maybe I can do it better with different software.

There are also some suggestions how to achieve this there. 
For more information look at Amber definition - 
https://fedorahosted.org/amber/wiki/Definition.


I followed some of the suggestions and this is how I would like to implement it in Fedora PkgDB:

Task
-----
- Task is container that will allow us to break complex task into more 'atomic' parts. This should 
allow us to create toolsets needed for completition of complex tasks.
- Task consits of one or more Actions.
- Actions shall be added by creating new Action or by choosing from the list of the existing ones.
- Task shall be defined by pkgdb users .

Example:
Task: Import videos from my camera and put them on YouTube
Actions: [Capture video, Edit video, Encode video, Upload video to YouTube]

Action
--------
- Action is atomic task
- Action shall be defined by PkgDB user either as part of Task definition process or as standalone 
entity. 
- Actions should be used instead of current tags. (I believe replacing current tags would help to 
avoid confusion from two kinds of tags.)

Application tagging
-----------------------
There is not much difference against current tagging system.
Users shall be tempted to input verbs instead of nouns:
    "I use this application to ________________ and give it ***** stars."
Input box shall feature AJAX search for existing actions to reduce duplication.
User ratings (http://mbacovsk.fedorapeople.org/Amber/mockups/Fedora_app_page.png) shall be updated 
accordingly.

Note: I am thinking of keeping categories imported from .desktop file as read only information

Search
---------
Both Tasks and Actions shall be included among other targets for search (app names, descriptions, 
comments, etc)


Does it make sense? 
Do you think it would be acceptable/ understandable for common users?.
Any comments and ideas will be appreciated.


Regards,
Martin



From ndbecker2 at gmail.com  Fri Oct 23 14:31:08 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 23 Oct 2009 10:31:08 -0400
Subject: Major reorganization of TeX Live packages
References: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091022124241.GA5996@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: 

On F11 I get:

kpathsea-2007-42.fc11.x86_64 from installed has depsolving problems
  --> Missing Dependency: texlive = 2007-42.fc11 is needed by package 
kpathsea-2007-42.fc11.x86_64 (installed)
Error: Missing Dependency: texlive = 2007-42.fc11 is needed by package 
kpathsea-2007-42.fc11.x86_64 (installed)




From jussilehtola at fedoraproject.org  Fri Oct 23 14:56:02 2009
From: jussilehtola at fedoraproject.org (Jussi Lehtola)
Date: Fri, 23 Oct 2009 17:56:02 +0300
Subject: Major reorganization of TeX Live packages
In-Reply-To: 
References: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091022124241.GA5996@dhcp-lab-133.englab.brq.redhat.com>
	
Message-ID: <1256309762.5269.2.camel@politzer.theorphys.helsinki.fi>

On Fri, 2009-10-23 at 10:31 -0400, Neal Becker wrote:
> On F11 I get:
> 
> kpathsea-2007-42.fc11.x86_64 from installed has depsolving problems
>   --> Missing Dependency: texlive = 2007-42.fc11 is needed by package 
> kpathsea-2007-42.fc11.x86_64 (installed)
> Error: Missing Dependency: texlive = 2007-42.fc11 is needed by package 
> kpathsea-2007-42.fc11.x86_64 (installed)
> 


First, you need to enable enable the updates-testing repository. Then,
you need to wait until the new kpathsea package hits the updates-testing
repository:
https://admin.fedoraproject.org/updates/texlive-2007-46.fc11

Or, you can fetch the new build of kpathsea manually from
http://koji.fedoraproject.org/koji/buildinfo?buildID=137909
-- 
Jussi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org



From rdieter at math.unl.edu  Fri Oct 23 15:22:33 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Oct 2009 10:22:33 -0500
Subject: orphaning (eol) gtk-qt-engine
Message-ID: 

This is to announce my intentions to orphan (and hopefully eol) gtk-qt-
engine in fedora.

For F-12+, my plan is to allow the new kcm-gtk package to Obsoletes it.  It 
will provide a systemsettings/kcm module to configure gtk theming, but 
without the problematic "Qt" gtk engine.  See also:
https://bugzilla.redhat.com/show_bug.cgi?id=kcm-gtk

-- Rex



From greno at verizon.net  Fri Oct 23 15:54:54 2009
From: greno at verizon.net (Gerry Reno)
Date: Fri, 23 Oct 2009 11:54:54 -0400
Subject: Packaging Survey - May 2009
In-Reply-To: <4AE15EB5.6050503@fedoraproject.org>
References: <4A1D24AC.4090802@fedoraproject.org>
	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
	<4AE127E7.8080805@verizon.net> <4AE15EB5.6050503@fedoraproject.org>
Message-ID: <4AE1D1CE.4020607@verizon.net>

Rahul Sundaram wrote:
> On 10/23/2009 09:19 AM, Gerry Reno wrote:
>
>   
>> Did eucalyptus ever get packaged for F12 ?
>>
>> I didn't find anything in rawhide today when I checked it.
>>     
>
> Nobody volunteered yet.
>
> Rahul
>
>   
I see on the eucalyptus site that they now have rpms available for 
CentOS 5.3.  Maybe that would make it easier now to create packages for 
Fedora.

http://open.eucalyptus.com/downloads




From a.badger at gmail.com  Fri Oct 23 15:51:16 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 23 Oct 2009 08:51:16 -0700
Subject: Action Tags concept
In-Reply-To: <200910231646.36429.mbacovsk@redhat.com>
References: <200910211426.55849.mbacovsk@redhat.com>
	<20091022143306.GF7460@clingman.lan>
	<200910231646.36429.mbacovsk@redhat.com>
Message-ID: <20091023155116.GH7460@clingman.lan>

On Fri, Oct 23, 2009 at 04:46:36PM +0200, Martin Bacovsky wrote:
> On Thursday 22 October 2009 16:33:06 you wrote:
> > 
> > I like this concept.  How does it relate to tagging?
> > * As a replacement for tagging
> > * As a separate feature from tagging
> > * In addition to tagging where some output utilizes both tags and actions
> I was thinking of replacing current tags, because I'm affraid users will be confused by two kinds of 
> tags. On the other hand I would keep categories imported from .desktop files (readonly/searchonly).
> 
So I think we might be committed to having freeform tags for its use as a
comps replacement and grouping mechanism. I'm not 100% sure though. There is
overlap::

python-openssl

tags: python, module, ssl, encryption, hashing, binding, MIT

Tasks: Use this to write programs in python that can communicate with
network services over SSL
Use this to write python programs that encrypt, decrypt, and hash data.

Actions: python programming, network programming, encryption programming?,
decryption programming? hash programming?

So there's some things that aren't captured (for instance that this is
licensed MIT (which may not be an issue, we can grab that from the license
tag) and that this is a binding (which I don't see how to capture in an
action).

There's also some things that I wonder about a bit -- hash programming
and encryption progamming are awkward phrases -- makes me wonder if that's
trying to shoehorn a concept into the wrong tool.  How will user's know to
find the action encryption programming, hash programming, python
programming?  How will we compose the actions into tasks?

Also, how do we get the users to only enter actions(verbs) and not nouns
when supplying new actions for a package?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From greno at verizon.net  Fri Oct 23 16:08:34 2009
From: greno at verizon.net (Gerry Reno)
Date: Fri, 23 Oct 2009 12:08:34 -0400
Subject: Packaging Survey - May 2009
In-Reply-To: <4AE1D1CE.4020607@verizon.net>
References: <4A1D24AC.4090802@fedoraproject.org>
	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
	<4AE127E7.8080805@verizon.net> <4AE15EB5.6050503@fedoraproject.org>
	<4AE1D1CE.4020607@verizon.net>
Message-ID: <4AE1D502.1090407@verizon.net>

Gerry Reno wrote:
> Rahul Sundaram wrote:
>> On 10/23/2009 09:19 AM, Gerry Reno wrote:
>>
>>  
>>> Did eucalyptus ever get packaged for F12 ?
>>>
>>> I didn't find anything in rawhide today when I checked it.
>>>     
>>
>> Nobody volunteered yet.
>>
>> Rahul
>>
>>   
> I see on the eucalyptus site that they now have rpms available for 
> CentOS 5.3.  Maybe that would make it easier now to create packages 
> for Fedora.
>
> http://open.eucalyptus.com/downloads
>
>
Oops.  I take that back.  There are rpms in the download lists for other 
Linux versions but looks like only .tar.gz for CentOS.

Anyway, I trying to install eucalyptus on Fedora 11 and here is what I 
think the prerequisites are when installing all controllers on one node:

yum install  java-1.6.0-openjdk-devel ant ant-nodeps libvirt 
libvirt-devel   curl libcurl-devel httpd httpd-devel apr apr-devel 
openssl openssl-devel dhcp m2crypto

I'll see if I can get it installed.





From orion at cora.nwra.com  Fri Oct 23 16:29:21 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 23 Oct 2009 10:29:21 -0600
Subject: Packaging Survey - May 2009
In-Reply-To: <4AE1D502.1090407@verizon.net>
References: <4A1D24AC.4090802@fedoraproject.org>	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>	<4AE127E7.8080805@verizon.net>
	<4AE15EB5.6050503@fedoraproject.org>	<4AE1D1CE.4020607@verizon.net>
	<4AE1D502.1090407@verizon.net>
Message-ID: <4AE1D9E1.7060601@cora.nwra.com>

On 10/23/2009 10:08 AM, Gerry Reno wrote:
> Oops. I take that back. There are rpms in the download lists for other
> Linux versions but looks like only .tar.gz for CentOS.
>
> Anyway, I trying to install eucalyptus on Fedora 11 and here is what I
> think the prerequisites are when installing all controllers on one node:
>
> yum install java-1.6.0-openjdk-devel ant ant-nodeps libvirt
> libvirt-devel curl libcurl-devel httpd httpd-devel apr apr-devel openssl
> openssl-devel dhcp m2crypto
>
> I'll see if I can get it installed.

Looks like building from source may use customized versions of axis2/c 
rampart/c and libvirt.  Doesn't look like axis2/c or rampart/c are in 
Fedora.

-- 
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 ngompa13 at gmail.com  Fri Oct 23 16:36:15 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Fri, 23 Oct 2009 11:36:15 -0500
Subject: Fedora with Universal Binaries?
In-Reply-To: <4AE15AD4.9030907@redhat.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<4AE15AD4.9030907@redhat.com>
Message-ID: <8278b1b0910230936w476ad81bh601b1ee5b34e4a5b@mail.gmail.com>

Universal binary technology is still used in Snow Leopard, it just is used
for supporting both x86_32 and x86_64 arches instead of PPC and x86.

On Fri, Oct 23, 2009 at 2:27 AM, Mat?j Cepl  wrote:

> Dne 22.10.2009 19:28, King InuYasha napsal(a):
> > I just saw this article about an effort to create Universal binary style
> > ELF binaries for Linux, and I thought that this would be something to
> > watch, so that Fedora could integrate both x86-32 and x86-64 into single
> > DVD sets.
> >
> > http://icculus.org/fatelf/
> >
> > There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit
> > and 64-bit kernels and all the apps compiled as FatELF binaries
>
> Wandering minds ask what is it good for? I hoped that with Snow Leopard
> being intel-only Apple Universal Binaries will finally wither to bad
> memories of past (somewhere around the Berlin Wall and Third Reich :)),
> and that whole concept of multilib will follow in due course after them.
>
> Mat?j
>
> --
> http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
> Pain is inevitable, but misery is optional. We cannot avoid pain,
> but we can avoid joy.
>    -- Tim Hansel
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From xjakub at fi.muni.cz  Fri Oct 23 17:05:59 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Fri, 23 Oct 2009 19:05:59 +0200
Subject: the mass rebuild and i586 rpms?
In-Reply-To: 
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>	<4ADD8782.10801@fi.muni.cz>
	
Message-ID: <4AE1E277.6050408@fi.muni.cz>

On 22.10.2009 03:39, Kevin Kofler wrote:
> Milos Jakubicek wrote:
>> Most probably those are the packages which failed during the mass
>> rebuild...there are still plenty of them:
>>
>> http://mjakubicek.fedorapeople.org/need-rebuild.html
>
> That list is out of date. I fixed clutter-gtkmm to build a while ago because
> it had broken dependencies, and the fixed build got tagged into dist-f12
> already (and dist-f13 inherits it from there too).

Strange, I added dist-f12-updates-candidate (instead of 
dist-f12-openssl) to the list and the package got off the list...

Milos



From jan.kratochvil at redhat.com  Fri Oct 23 17:35:25 2009
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Fri, 23 Oct 2009 19:35:25 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
Message-ID: <20091023173525.GA9400@host0.dyn.jankratochvil.net>

On Thu, 22 Oct 2009 19:28:36 +0200, King InuYasha wrote:
> I just saw this article about an effort to create Universal binary style ELF
> binaries for Linux, and I thought that this would be something to watch, so
> that Fedora could integrate both x86-32 and x86-64 into single DVD sets.

While I do not find useful "fat-elf" I did post an implementation of auto-biarch
Fedora LiveDVD but it was ignored.  Still keep it around personally myself.

Attached the post, former followups to it at:
https://www.redhat.com/archives/fedora-livecd-list/2009-June/msg00018.html


Regards,
Jan
-------------- next part --------------
An embedded message was scrubbed...
From: Jan Kratochvil 
Subject: [Fedora-livecd-list] auto-biarch (x86_64 + i686) LiveDVD patch + ISO
Date: Sun, 21 Jun 2009 12:05:13 +0200
Size: 15585
URL: 

From greno at verizon.net  Fri Oct 23 17:46:59 2009
From: greno at verizon.net (Gerry Reno)
Date: Fri, 23 Oct 2009 13:46:59 -0400
Subject: Packaging Survey - May 2009
In-Reply-To: <4AE1D9E1.7060601@cora.nwra.com>
References: <4A1D24AC.4090802@fedoraproject.org>
	<604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com>
	<4AE127E7.8080805@verizon.net>	<4AE15EB5.6050503@fedoraproject.org>
	<4AE1D1CE.4020607@verizon.net>	<4AE1D502.1090407@verizon.net>
	<4AE1D9E1.7060601@cora.nwra.com>
Message-ID: <4AE1EC13.9000606@verizon.net>

Orion Poplawski wrote:
> On 10/23/2009 10:08 AM, Gerry Reno wrote:
>> Oops. I take that back. There are rpms in the download lists for other
>> Linux versions but looks like only .tar.gz for CentOS.
>>
>> Anyway, I trying to install eucalyptus on Fedora 11 and here is what I
>> think the prerequisites are when installing all controllers on one node:
>>
>> yum install java-1.6.0-openjdk-devel ant ant-nodeps libvirt
>> libvirt-devel curl libcurl-devel httpd httpd-devel apr apr-devel openssl
>> openssl-devel dhcp m2crypto
>>
>> I'll see if I can get it installed.
>
> Looks like building from source may use customized versions of axis2/c 
> rampart/c and libvirt.  Doesn't look like axis2/c or rampart/c are in 
> Fedora.
>

Ok, there are rpms for CentOS 5.3.  They packaged them inside the 
.tar.gz download file.  In the deps directory there are rpms for axis2 
and rampart.  I don't see any srpms yet.




From kwhiskerz at gmail.com  Fri Oct 23 17:55:52 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 11:55:52 -0600
Subject: orphaning (eol) gtk-qt-engine
References: 
Message-ID: 

Rex Dieter wrote:

> For F-12+, my plan is to allow the new kcm-gtk package
> to... provide a systemsettings/kcm module to configure
> gtk theming

When will it be available, even as a testing rpm? I 
looked in koji and it is not there and yum knows nothing 
about it.



From jonstanley at gmail.com  Fri Oct 23 18:48:23 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 23 Oct 2009 14:48:23 -0400
Subject: FESCo meeting summary for 20091023
Message-ID: 

=======================================
#fedora-meeting: FESCo meeting 20091023
=======================================


Meeting started by jds2001 at 17:00:33 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-23/fedora-meeting.2009-10-23-17.00.log.html
.



Meeting summary
---------------
* Documentation  (jds2001, 17:03:23)
  * AGREED: when a policy decision is made not applicable to FPC, then
    the meeting chair will change the keyword of the  ticket from
    "meeting" to "writeup", and assign it to a specific person
    (jds2001, 17:13:17)

* open floor  (jds2001, 17:13:32)
  * there's a beta. it has blocker bugs. fesco encourages people to fix
    them.  (jds2001, 17:14:58)
  * AGREED: non-trivial wallpaper changes after Tuesday will be
    rejected. The KDE SIG will work with that schedule  (jds2001,
    18:46:31)

Meeting ended at 18:47:22 UTC.




Action Items
------------





Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* mizmo (110)
* Kevin_Kofler (97)
* jds2001 (72)
* skvidal (44)
* notting (44)
* mccann (24)
* dgilmore (15)
* halfline (14)
* stickster (11)
* j-rod (10)
* Oxf13 (10)
* sharkcz (6)
* rdieter (5)
* zodbot (4)
* Southern_Gentlem (2)
* drago01 (2)
* nirik (0)
* dwmw2 (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



From rdieter at math.unl.edu  Fri Oct 23 19:38:18 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Oct 2009 14:38:18 -0500
Subject: orphaning (eol) gtk-qt-engine
References:  
Message-ID: 

Petrus de Calguarium wrote:

> Rex Dieter wrote:
> 
>> For F-12+, my plan is to allow the new kcm-gtk package
>> to... provide a systemsettings/kcm module to configure
>> gtk theming
> 
> When will it be available, even as a testing rpm? I
> looked in koji and it is not there and yum knows nothing
> about it.

pending cvsadmin processing, will get it imported and built properly, asap.

In the meantime, there's a scratch build: (from the review):
http://koji.fedoraproject.org/koji/taskinfo?taskID=1762877

-- Rex



From kwhiskerz at gmail.com  Fri Oct 23 20:24:05 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 14:24:05 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	
Message-ID: 

Rex Dieter wrote:

> there's a scratch build

Vielen Dank!!! I will give it a try.



From walters at verbum.org  Fri Oct 23 20:56:14 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 23 Oct 2009 20:56:14 +0000
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
	Project?"])
In-Reply-To: <1256230254.9182.5.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
Message-ID: 

On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating  wrote:
>
> Rawhide as we know it, /pub/fedora/linux/releases/development/ will
> remain "rawhide". ?We may even change the path to say rawhide, just to
> catch things up and well I like keeping mirrors on their toes. ?Rawhide
> will be a repository of developmental and experimental packages. ?Things
> being worked on for the future. ?It will /not/ be an installable tree,
> rather it will just be a repository of packages, to be added on to an
> already stable "base", eg you'd install F12, and enable rawhide to test
> rawhide. ?This will significantly lower the complaints that "rawhide
> isn't installable".

So as I understand it there are a number of reasons why rawhide might
not be installable, but broadly they fall into two major categories:

* Anaconda
* Critpath packages
  - Dependency/rebuild issues
  - Bugs in %posts (like the user/group one we ran into with dbus)
  - Core bugs (graphics drivers)

It seems like we're basically just skipping Anaconda, since you won't
be able to yum if there are depsolving issues (ok, modulo
--skip-broken), and for the latter two you don't end up with a
"working" system.

Let me do a counter-proposal:

We simply do not let showstopper regressions in the critpath stay in
rawhide.  If something in critpath has a showstopper, it halts all
further commits to the entire critpath until it's resolved (either
fixed, or reverted).  The definition of "showstopper" might be "AutoQA
fails".  And since AutoQA will have been doing some basic smoketesting
of the installer, we have to be producing installer images as a side
effect.



From jkeating at redhat.com  Fri Oct 23 21:11:04 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Oct 2009 14:11:04 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
 Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	
Message-ID: <1256332264.15887.13.camel@localhost.localdomain>

On Fri, 2009-10-23 at 20:56 +0000, Colin Walters wrote:
> On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating  wrote:
> >
> > Rawhide as we know it, /pub/fedora/linux/releases/development/ will
> > remain "rawhide".  We may even change the path to say rawhide, just to
> > catch things up and well I like keeping mirrors on their toes.  Rawhide
> > will be a repository of developmental and experimental packages.  Things
> > being worked on for the future.  It will /not/ be an installable tree,
> > rather it will just be a repository of packages, to be added on to an
> > already stable "base", eg you'd install F12, and enable rawhide to test
> > rawhide.  This will significantly lower the complaints that "rawhide
> > isn't installable".
> 
> So as I understand it there are a number of reasons why rawhide might
> not be installable, but broadly they fall into two major categories:
> 
> * Anaconda
> * Critpath packages
>   - Dependency/rebuild issues
>   - Bugs in %posts (like the user/group one we ran into with dbus)
>   - Core bugs (graphics drivers)
> 
> It seems like we're basically just skipping Anaconda, since you won't
> be able to yum if there are depsolving issues (ok, modulo
> --skip-broken), and for the latter two you don't end up with a
> "working" system.
> 
> Let me do a counter-proposal:
> 
> We simply do not let showstopper regressions in the critpath stay in
> rawhide.  If something in critpath has a showstopper, it halts all
> further commits to the entire critpath until it's resolved (either
> fixed, or reverted).  The definition of "showstopper" might be "AutoQA
> fails".  And since AutoQA will have been doing some basic smoketesting
> of the installer, we have to be producing installer images as a side
> effect.
> 

I... don't see how this helps, other than piss off the rest of the
crit-path maintainers while one thing is broken.

AutoQA will be running at some point, and it can be doing the
qa /before/ things get tagged for rawhide, so if you break deps with
your build, it doesn't get in, unless you force it and then you face the
wrath of releng/qa.  To catch core bugs, we'll need a bit more advanced
autoqa, doing more than just repo level testing but doing actual package
testing.  That will grow over time and again can be done pre-tag.

Your counter proposal also does nothing to help the dual or sometimes
triple role we try to put on "rawhide" the path.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From walters at verbum.org  Fri Oct 23 21:15:47 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 23 Oct 2009 21:15:47 +0000
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
	Project?"])
In-Reply-To: <1256332264.15887.13.camel@localhost.localdomain>
References: <1256230254.9182.5.camel@localhost.localdomain>
	
	<1256332264.15887.13.camel@localhost.localdomain>
Message-ID: 

On Fri, Oct 23, 2009 at 9:11 PM, Jesse Keating  wrote:
>
> AutoQA will be running at some point, and it can be doing the
> qa /before/ things get tagged for rawhide,

Oh, I didn't realize there would be a distinction between "built in
koji" and "rawhide" now.  If that's the case, than this sounds fine to
me!  The point is basically that we need some sort of stable, defined
baseline for what you get when you try to install "rawhide".  Testing
before tagging sounds good.



From jkeating at redhat.com  Fri Oct 23 21:42:33 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Oct 2009 14:42:33 -0700
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
 Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	
	<1256332264.15887.13.camel@localhost.localdomain>
	
Message-ID: <1256334153.15887.14.camel@localhost.localdomain>

On Fri, 2009-10-23 at 21:15 +0000, Colin Walters wrote:
> Oh, I didn't realize there would be a distinction between "built in
> koji" and "rawhide" now.  If that's the case, than this sounds fine to
> me!  The point is basically that we need some sort of stable, defined
> baseline for what you get when you try to install "rawhide".  Testing
> before tagging sounds good. 

Yeah, there are multiple prongs to our attack to make Fedora development
better.  In this thread I was mostly talking about what types of changes
go into the repos and which repos get produced each night.  Autoqa has
other plans to help, one of which being testing before tagging.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From xjakub at fi.muni.cz  Sat Oct 24 00:37:57 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Sat, 24 Oct 2009 02:37:57 +0200
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <1256232577.2497.43.camel@samson.armitage.org.uk>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
Message-ID: <4AE24C65.1070901@fi.muni.cz>

OK, I took the 3 hours today and went through the packages which have 
not been submitted at all for building:

On 22.10.2009 19:29, Quentin Armitage wrote:

> Not submitted for rebuild (65)
> ==============================

I've successfully rebuilt (and requested tagging for dist-f12):

- at first try:

Perlbal
PyAmanith
PyKDE
PyQuante
PySBIG
PySolFC
PySolFC-cardsets

- after some torturing (some packages had quite damaged F-12 and devel 
branches due to some weird errors during the mass rebuild, spec files 
and/or sources were not copied and/or not cvsadded and/or not tagged + 
trivial build failures):

eclipse-setools
eqntott
icoutils
olpc-kbdshim
python-psyco
snake
unetbootin

Rebuilt recently by sb else:
OpenEXR_CTL
OpenEXR_Viewers
PerceptualDiff
Pixie
Pound
django-typepad

Newpackage (some of them even for months!):
ccss
education-bookmarks
gdata-sharp
gnome-globalmenu
luci
netplug
perl-Tk-ProgressBar-Mac
pyhton-utmp
python-decorator3
python-typepad
rubygem-extlib
rubygem-mixlib-cli
rubygem-mixlib-config
rubygem-mixlib-log
rubygem-systemu
sblim-cim-client2
tomcatjss
trac-tickettemplate-plugin
vanessa_logger
volpack
x11vnc
yum-plugin-download-order
zikula-module-filterutil

Alpha-only:
aboot

IA64-only:
elilo
prctl

s390-only:
libica
openssl-ibmca

sparc-only:
piggyback
prtconf
silo
xorg-x11-drv-sunbw2
xorg-x11-drv-suncg14
xorg-x11-drv-suncg3
xorg-x11-drv-suncg6
xorg-x11-drv-sunffb
xorg-x11-drv-sunleo
xorg-x11-drv-suntcx

Failing:
fonts-hebrew-fancy
(https://fedorahosted.org/rel-eng/ticket/2680)
libgtk-java
(seems like skasal forgot to cvsadd his patch)
perl-Perl-Critic
(waiting for tagging perl-PPI)
ssmtp
(don't know why it is on the list, need to consult)

Milos



From kwhiskerz at gmail.com  Sat Oct 24 00:51:29 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 18:51:29 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
Message-ID: 

Petrus de Calguarium wrote:

> I will give it a try.

After a few hours of testing, I see that the font 
selection works well, but the widget style does not work. 
I know this is a new program and this is the very first 
step.



From rdieter at math.unl.edu  Sat Oct 24 00:56:47 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Oct 2009 19:56:47 -0500
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	
Message-ID: 

Petrus de Calguarium wrote:

> Petrus de Calguarium wrote:
> 
>> I will give it a try.
> 
> After a few hours of testing, I see that the font
> selection works well, but the widget style does not work.
> I know this is a new program and this is the very first
> step.

Works for me (though you'll have to uninstall gtk-qt-engine first, if that's 
in stalled, it will override things set here).

Alternatively, manually remove ~/.kde/env/gtk-qt-engine.sh and logout/login

-- Rex



From rdieter at math.unl.edu  Sat Oct 24 01:25:38 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Oct 2009 20:25:38 -0500
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
Message-ID: 

Rex Dieter wrote:

> Petrus de Calguarium wrote:
> 
>> Petrus de Calguarium wrote:
>> 
>>> I will give it a try.
>> 
>> After a few hours of testing, I see that the font
>> selection works well, but the widget style does not work.
>> I know this is a new program and this is the very first
>> step.
> 
> Works for me 

Oh, and make sure to have at least gtk2-2.18.3-9.fc12 (if on f12/rawhide)

-- Rex



From kevin.kofler at chello.at  Sat Oct 24 01:58:39 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 24 Oct 2009 03:58:39 +0200
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora
	Project?"])
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
	<20091023062235.GA27104@wolff.to>
Message-ID: 

Bruno Wolff III wrote:
> The impression I got (which might be wrong), is that it was expected that
> people would test specific packages from rawhide and not be expected to
> be running it all at once.

That just doesn't work. The network of dependencies and reverse dependencies 
generally ends up dragging in half of the distro after the first core 
library soname bump (e.g. OpenSSL, OpenLDAP or the like).

        Kevin Kofler



From kevin.kofler at chello.at  Sat Oct 24 02:01:38 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 24 Oct 2009 04:01:38 +0200
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<20091023173525.GA9400@host0.dyn.jankratochvil.net>
Message-ID: 

Jan Kratochvil wrote:
> While I do not find useful "fat-elf" I did post an implementation of
> auto-biarch Fedora LiveDVD but it was ignored.

It was (mostly) ignored because it doubles the download size and makes the 
image no longer fit on a CD, for little benefit.

Again, the right solution is to point people to the 64-bit version by 
default.

        Kevin Kofler



From kwhiskerz at gmail.com  Sat Oct 24 02:31:37 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 20:31:37 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
Message-ID: 

Rex Dieter wrote:

> manually remove ~/.kde/env/gtk-qt-engine.sh

I uninstalled gtk-qt-engine first, but the script was 
still there. Gone now.

I have gtk2-2.18.3-8.fc12.x86_64, which is the most 
recent to be released for rawhide. I guess 2.18.3-9 is on 
koji? I will try without first, hoping that the manual 
removal of the gtk-qt script did it.



From kwhiskerz at gmail.com  Sat Oct 24 02:38:03 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 20:38:03 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
	
Message-ID: 

Rex Dieter wrote:

> make sure to have at least gtk2-2.18.3-9.fc12

Ok. I guess removing the script wasn't enough. I will 
look for 2.18.3-9 on koji.




From kwhiskerz at gmail.com  Sat Oct 24 02:44:43 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 20:44:43 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
	 
Message-ID: 

Petrus de Calguarium wrote:

> 2.18.3-9

Well, I got 2.18.3-11. Now, I do get the nodoka theme, 
but the colours are not carried over. I think another 
logout/login should cure that.

Looks pretty good. Nice that themes will start working 
for gtk :-)



From awilliam at redhat.com  Sat Oct 24 03:18:17 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 23 Oct 2009 20:18:17 -0700
Subject: Fedora 12 Beta
In-Reply-To: <4AE1AAC7.5030601@beam.ltd.uk>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<1256160900.2314.427.camel@adam.local.net>
	<596b53e0910211549t1c31d532w32bfed895b8b5d08@mail.gmail.com>
	<4AE1AAC7.5030601@beam.ltd.uk>
Message-ID: <1256354297.2314.523.camel@adam.local.net>

On Fri, 2009-10-23 at 14:08 +0100, Terry Barnaby wrote:

> >>> 4 - F12 boots really slow on my laptop
> >>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
> >>> wrong is happening while udev loading
> >>
> >> Please file a bug for this, on 'udev' component for now, and CC Harald
> >> Hoyer (hhoyer at redhat). Thanks!
> >>
> Note that on my Thinkpad R52 Laptop F11 started doing this after
> a udev RPM update. It turned out to be the fact that there was no
> floppy drive in my system but the BIOS was configured with one
> enabled. I suspect this is default in some laptops so that
> docking stations etc work ??
> I think this bug is in Bugzilla, but I suspect it has not
> been fixed ...

That one's known, but is different from what the OP was seeing. With the
floppy-enabled thing, the system pauses entirely for pretty much exactly
a minute. The OP's case is different as bootchart shows.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From kwhiskerz at gmail.com  Sat Oct 24 03:50:56 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Fri, 23 Oct 2009 21:50:56 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
	 
	
Message-ID: 

Petrus de Calguarium wrote:

> Now, I do get the nodoka theme, but the colours
> are not carried over. I think another
> logout/login should cure that.

It turns out... It didn't! I have nodoka and my kde 
fonts, but not the colour scheme.




From Quentin at Armitage.org.uk  Sat Oct 24 08:43:33 2009
From: Quentin at Armitage.org.uk (Quentin Armitage)
Date: Sat, 24 Oct 2009 09:43:33 +0100
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4AE24C65.1070901@fi.muni.cz>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
	<4AE24C65.1070901@fi.muni.cz>
Message-ID: <1256373813.2539.4.camel@samson.armitage.org.uk>

On Sat, 2009-10-24 at 02:37 +0200, Milos Jakubicek wrote:

> ssmtp
> (don't know why it is on the list, need to consult)
> 
ssmtp is on the list because the build target of the task in koji (
http://koji.fedoraproject.org/koji/taskinfo?taskID=1634633 ) is
dist-f12-openssl, which is not one of the targets that need-rebuild.py
looks for.

Quentin



From ilyes.gouta at gmail.com  Sat Oct 24 10:57:42 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 24 Oct 2009 11:57:42 +0100
Subject: Fedora 12 Beta
In-Reply-To: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
Message-ID: <234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>

Hi Michal,

I just installed Fedora 12 Beta into a VirtualBox VM and I'm
experiencing the same symptoms. How did you disable plymouth from
grub? The whole boot process is really slow.

Regards,
Ilyes Gouta.

2009/10/21 Micha? Piotrowski :
> Hi,
>
> I just installed F12 Beta. Here are some thoughts
>
> 1 - during the first boot smolt panicked - there was an error related
> to time zones in python-sitepackages or something like that.
> 2 - I tried to reboot the system - ctrl + alt + del, but it stopped on
> process termination
> 3 - after reboot system wanted my root password for partition check -
> after I pressed each key, the system gave me a communicate about wrong
> password
> I guess this is a plymouth bug. I disabled it in grub conf and system
> works correctly. Is there any chance to completely remove plymouth
> from the system? (even from initrd)
> 4 - F12 boots really slow on my laptop
> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
> wrong is happening while udev loading
> 5 - default gnome sound scheme is terrible
>
> The first impression isn't good.
>
> Regards,
> Michal
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From rawhide at fedoraproject.org  Sat Oct 24 12:40:05 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 24 Oct 2009 12:40:05 +0000
Subject: rawhide report: 20091024 changes
Message-ID: <20091024124005.GA17105@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 24 06:15:18 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package sblim-cim-client2
        Java CIM Client library
New package sblim-cmpi-fsvol
        SBLIM fsvol instrumentation
New package sblim-cmpi-nfsv4
        SBLIM nfsv4 instrumentation
New package sblim-cmpi-sysfs
        SBLIM sysfs instrumentation
New package sblim-gather
        SBLIM Gatherer
New package sblim-tools-libra
        SBLIM Common Resource Access Library for WBEM-SMT tasks
Updated Packages:

DeviceKit-power-012-1.fc12
--------------------------
* Mon Oct 19 2009 Richard Hughes  - 012-1
- Update to 012
- Detect encrypted swap and prevent hibernate in this case.
- When we do a delayed refresh, actually do 5 x 1 second apart rather
  than 1 x 3 seconds which should fix some slow battery devices.


Perlbal-1.70-4.fc12
-------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.70-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PyAmanith-0.3.35-8.fc12
-----------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.3.35-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PyKDE-3.16.3-2.fc12
-------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 3.16.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PyQuante-1.6.3-2.fc12
---------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.6.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PySBIG-0.04-5.fc12
------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.04-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PySolFC-1.1-9.fc12
------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.1-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


PySolFC-cardsets-1.1-5.2
------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.1-5.2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


anaconda-12.39-1.fc12
---------------------
* Fri Oct 23 2009 Peter Jones  - 12.39-1
- More udev fixups for device-mapper and cryptsetup temp devices. (dlehman)
  (#526699)
- Use rpm to determine how to set bootloader args and default runlevel
  (clumens) (#527520)
- Handle more than x.y version numbers in 'make bumpver'. (dcantrell)
- Mark live device as protected instead of ignoring it. (dlehman) (#517260)
- Don't force logical with a free primary slot and an extended. (dlehman)
  (#527952)
- Write LAYER2 and PORTNO correctly as parts of OPTIONS to ifcfg for s390x
  (Steffen Maier)
- liveinst: deactivate mdraid arrays before running liveinst (hansg)
  (#528235)


corosync-1.1.2-1.fc12
---------------------
* Fri Oct 23 2009 Fabio M. Di Nitto  - 1.1.2-1
- New upstream release fixes major regression on specific loads


eclipse-findbugs-1.3.9-2.fc12
-----------------------------
* Fri Oct 23 2009 Jerry James  - 1.3.9-2
- Remove explicit versions from the manifest to match the symlinks (bz 530512)


eclipse-setools-3.3.5.1-3.fc12
------------------------------
* Fri Oct 23 2009 Dennis Gilmore  - 3.3.5.1-3
- bump and tag to get the correct sources file in place

* Fri Jul 24 2009 Fedora Release Engineering  - 3.3.5.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Thu Mar 05 2009 Dave Sugar  - 3.3.5.1-1
- Update to setools 3.3.5 release


environment-modules-3.2.7b-4.fc12
---------------------------------
* Fri Oct 23 2009 Orion Poplawski  - 3.2.7b-4
- Don't load bash init script when bash is running as "sh" (bug #529745)


eqntott-9.0-2.fc12
------------------

evolution-rss-0.1.4-5.fc12
--------------------------
* Fri Oct 23 2009 Lucian Langa  - 0.1.4-5
- add patch2 to fix loading of icons (gtk refuses to load icons with size 0)


farsight2-0.0.16-1.fc12
-----------------------
* Tue Oct 06 2009 Brian Pepple  - 0.0.16-1
- Update to 0.0.16.


fbreader-0.10.7-4.fc12
----------------------
* Sat Oct 17 2009 Michel Salim  - 0.10.7-4
- Provide virtual packages for each available interface
- Use alternatives to select the user interface (see README.Fedora)


gdb-7.0-3.fc12
--------------
* Thu Oct 22 2009 Jan Kratochvil  - 7.0-3
- Support multiple directories for `set debug-file-directory' (BZ 528668).


gdm-2.28.1-5.fc12
-----------------
* Fri Oct 23 2009 Ray Strode  2.28.1-5
- Remove tool tip from login button

* Thu Oct 22 2009 Ray Strode  2.28.1-4
- Fix autologin window spasms
- Fix autologin timer animation
- Make autologin and multistack play better together
- Add padding to notification tray

* Wed Oct 21 2009 Ray Strode  2.28.1-3
- Move date from panel to clock tooltip

* Tue Oct 20 2009 Ray Strode  2.28.1-1
- Update to 2.28.1

* Tue Oct 20 2009 Ray Strode  2.28.1-2
- Move shutdown functions to panel from login window


git-1.6.5.1-1.fc12
------------------
* Sat Oct 17 2009 Todd Zullinger  - 1.6.5.1-1
- git-1.6.5.1

* Sun Oct 11 2009 Todd Zullinger  - 1.6.5-1
- git-1.6.5


gnome-desktop-2.28.1-2.fc12
---------------------------
* Thu Oct 22 2009 Matthias Clasen  - 2.28.1-1
- Update to 2.28.1, translation updates

* Thu Oct 22 2009 Matthias Clasen  - 2.28.1-2
- Support proper gamma setting in multihead setups


gnome-screensaver-2.28.0-5.fc12
-------------------------------
* Fri Oct 23 2009 Matthias Clasen  2.28.0-4
- Fix crashes and malfunctions in dynamic multihead situations

* Fri Oct 23 2009 Matthias Clasen  2.28.0-5
- Make the dialog ask to be killed after 5 attempts

* Thu Oct 22 2009 Matthias Clasen  2.28.0-2
- Use xrandr for gamma fading, if available, to fix fading in
  multihead setups

* Thu Oct 22 2009 Matthias Clasen  2.28.0-3
- Fix an oversight in the previous patch


gnome-session-2.28.0-2.fc12
---------------------------
* Fri Oct 23 2009 Matthias Clasen   - 2.28.0-2
- Avoid a crash on certain xsmp error conditions


gnome-utils-2.28.1-2.fc12
-------------------------
* Fri Oct 23 2009 Matthias Clasen  - 1:2.28.1-1
- Update to 2.28.1

* Fri Oct 23 2009 Matthias Clasen  - 1:2.28.1-2
- Fix the gsearchtool spinner


gtk2-2.18.3-11.fc12
-------------------
* Fri Oct 23 2009 Matthias Clasen  - 2.18.3-10
- Tweak tooltip positioning
- Make new tooltip style an opt-in theme choice

* Fri Oct 23 2009 Matthew Barnes  - 2.18.3-11
- Fix a GtkIconView hang


gtk2-engines-2.18.4-4.fc12
--------------------------
* Fri Oct 23 2009 Matthias Clasen  - 2.18.4-4
- Make Clearlooks opt-in to new tooltips style

* Wed Oct 21 2009 Matthias Clasen  - 2.18.4-3
- Tweak tooltip appearance


ibus-anthy-1.2.0.20090917-2.fc12
--------------------------------
* Fri Oct 23 2009 Takao Fujiwara  - 1.2.0.20090917-2
- Fix bug 526881 - ibus-anthy backtrace is reported by the latest abrt


icoutils-0.28.0-1.fc12
----------------------

iksemel-1.4-1.fc12
------------------
* Thu Oct 22 2009 Jeffrey C. Ollie  - 1.4-1
- Update to 1.4
- Apply patch from upstream so that gnutls autoconf works.
- Update gcrypt-sha patch so that it applies.

* Fri Jul 24 2009 Fedora Release Engineering  - 1.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


kernel-2.6.31.5-96.fc12
-----------------------
* Fri Oct 23 2009 Chuck Ebbert 
- Linux 2.6.31.5

* Fri Oct 23 2009 Dave Airlie  2.6.31.5-94
- disable debug + stackprotector

* Fri Oct 23 2009 Dave Airlie  2.6.31.5-95
- re enable MSI

* Fri Oct 23 2009 Kyle McMartin  2.6.31.5-96
- Bump NR_CPUS to 256 on x86_64.
- Add two backports (ugh, just had to go renaming perf counters to events...)
  for fixing sysprof with perf.

* Thu Oct 22 2009 Dave Airlie   2.6.31.5-91.rc1
- kms: fix palette

* Thu Oct 22 2009 Chuck Ebbert 
- Fix exploitable OOPS in keyring code. (CVE-2009-3624)
- Fix kernel memory leak to userspace. (CVE-2009-3612)

* Wed Oct 21 2009 Chuck Ebbert 
- Linux 2.6.31.5-rc1
- Remove the merged HP DC7900 workaround from iommu-updates patch.
- Drop merged patch:
  linux-2.6-raidlockdep.patch

* Wed Oct 21 2009 Chuck Ebbert 
- Disable powersave by default for AC97 audio devices. (#524414)

* Mon Oct 19 2009 Kyle McMartin 
- af_unix-fix-deadlock-connecting-to-shutdown-socket.patch: fix for
  rhbz#529626.

* Sat Oct 17 2009 Chuck Ebbert 
- Replace linux-2.6-bluetooth-autosuspend.diff with upstream version.


kpackagekit-0.5.0.1-1.fc12
--------------------------
* Tue Oct 20 2009 Steven M. Parrish  - 0.5.0.1-1
- Official 0.5.0.1 release
- Includes patch to fix (#469375) default/none issue


nfs-utils-1.2.0-17.fc12
-----------------------
* Thu Oct 22 2009 Steve Dickson  1.2.0-17
- Updated to the latest pseudo root release (rel7).
- Added upstream 1.2.1-rc7 patch which fixes:
   - Stop ignoring the -o v4 option (bz 529407)
   - Allow network protocol roll backs when proto is set
      in the config file (bz 529864)


nickle-2.69-2.fc12
------------------
* Fri Oct 23 2009 Michel Salim  - 2.69-2
- Lower FORTIFY setting; level 2 does not work with gcc 4.4.2

* Fri Sep 18 2009 Michel Salim  - 2.69-1
- Update to 2.69

* Sat Jul 25 2009 Fedora Release Engineering  - 2.68-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


notification-daemon-0.4.1-0.20090923.4.fc12
-------------------------------------------
* Fri Oct 23 2009 Matthias Clasen  - 0.4.1-1.20090923.4
- Don't abort if gnome-screensaver is not running (#529592)


olpc-kbdshim-7-2.fc12
---------------------
* Fri Oct 23 2009 Milos Jakubicek  - 7.2
- Fix FTBFS: use %{ix86} instead of i586 as ExclusiveArch

* Mon Jul 27 2009 Paul Fox 
- 7-1
- fix touchpad rotation for F-11, which includes X11 amd/geode
  driver that fixes the earlier rotation direction issue. 
  (2.11.x and later are fixed.)
- revise Makefile for easier pre-release management

* Sat Jul 25 2009 Fedora Release Engineering  - 6-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


openscada-0.6.4-4.fc12
----------------------
* Thu Oct 22 2009 Peter Lemenkov  - 0.6.4-4
- Fixed the last broken dep


perl-HTML-Parser-3.63-2.fc12
----------------------------
* Fri Oct 23 2009 Warren Togami  - 3.63-2
- 3.63 CVE-2009-3627


perl-PPI-1.206-1.fc12
---------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.206-1
- new upstream version
- update build requires


python-psyco-1.6-4.fc12
-----------------------
* Fri Oct 23 2009 Milos Jakubicek  - 1.6-4
- Fix FTBFS: Use %{ix86} instead of i586 in ExclusiveArch

* Sun Jul 26 2009 Fedora Release Engineering  - 1.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


sabayon-2.28.0-2.fc12
---------------------
* Fri Oct 23 2009 Dan Walsh  - 2.28.0-2
- Move errors to sabayon-apply package
- Only trap Exception on sabayon-apply error


sane-backends-1.0.20-10.fc12
----------------------------
* Thu Oct 22 2009 Nils Philippsen  - 1.0.20-8
- ship adapted udev rules from F-12 on (#512516)
- don't require pam anymore

* Thu Oct 22 2009 Nils Philippsen  - 1.0.20-9
- fix device file ownership and mode

* Thu Oct 22 2009 Nils Philippsen  - 1.0.20-10
- don't set owner, group or mode as this may interfere with setting ACLs


snake-0.11-0.18.fc12
--------------------
* Fri Oct 23 2009 Milos Jakubicek  - 0.11-0.18
- Fix FTBFS: bump release to be able to tag in new branch

* Sun Jul 26 2009 Fedora Release Engineering  - 0.11-0.17
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


sssd-0.7.0-1.fc12
-----------------
* Fri Oct 23 2009 Stephen Gallagher  - 0.7.0-1
- New upstream release 0.7.0


telepathy-farsight-0.0.12-1.fc12
--------------------------------
* Mon Oct 19 2009 Brian Pepple  - 0.0.12-1
- Update to 0.0.12.


towhee-6.2.6-4.fc12
-------------------
* Fri Oct 23 2009 Jussi Lehtola  - 6.2.6-4
- Fix FTBFS problem caused by behaviour change of openmpi.

* Sun Jul 26 2009 Fedora Release Engineering  - 6.2.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


unetbootin-0-6.358bzr.fc12
--------------------------
* Fri Oct 23 2009 Milos Jakubicek  0-6.358bzr
- Fix FTBFS: bump release to be able to tag in new branch and sync source name

* Sun Jul 26 2009 Fedora Release Engineering  - 0-6.357bzr
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


valgrind-3.5.0-6
----------------
* Fri Oct 23 2009 Jakub Jelinek  3.5.0-6
- ppc and ppc64 fixes

* Thu Oct 22 2009 Jakub Jelinek  3.5.0-5
- add emulation of 0x67 prefixed loop* insns on x86_64 (#530165)

* Wed Oct 21 2009 Jakub Jelinek  3.5.0-4
- handle reading of .debug_frame in addition to .eh_frame
- ignore unknown DWARF3 expressions in evaluate_trivial_GX
- suppress helgrind race errors in helgrind's own mythread_wrapper
- fix compilation of x86 tests on x86_64 and ppc tests

* Wed Oct 14 2009 Jakub Jelinek  3.5.0-3
- handle many more DW_OP_* ops that GCC now uses
- handle the more compact form of DW_AT_data_member_location
- don't strip .debug_loc etc. from valgrind binaries

* Mon Oct 12 2009 Jakub Jelinek  3.5.0-2
- add STT_GNU_IFUNC support (Dodji Seketeli, #518247)
- wrap inotify_init1 syscall (Dodji Seketeli, #527198)
- fix mmap/mprotect handling in memcheck (KDE#210268)


Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 47



From ilyes.gouta at gmail.com  Sat Oct 24 12:47:42 2009
From: ilyes.gouta at gmail.com (Ilyes Gouta)
Date: Sat, 24 Oct 2009 13:47:42 +0100
Subject: Fedora 12 Beta
In-Reply-To: <234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com> 
	<234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>
Message-ID: <234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com>

Hi,

Was Fedora 12 Beta released with all sort of debugging info. compiled in?
I just want to find the cause of the general slowness ..

-Ilyes

On Sat, Oct 24, 2009 at 11:57 AM, Ilyes Gouta  wrote:
> Hi Michal,
>
> I just installed Fedora 12 Beta into a VirtualBox VM and I'm
> experiencing the same symptoms. How did you disable plymouth from
> grub? The whole boot process is really slow.
>
> Regards,
> Ilyes Gouta.
>
> 2009/10/21 Micha? Piotrowski :
>> Hi,
>>
>> I just installed F12 Beta. Here are some thoughts
>>
>> 1 - during the first boot smolt panicked - there was an error related
>> to time zones in python-sitepackages or something like that.
>> 2 - I tried to reboot the system - ctrl + alt + del, but it stopped on
>> process termination
>> 3 - after reboot system wanted my root password for partition check -
>> after I pressed each key, the system gave me a communicate about wrong
>> password
>> I guess this is a plymouth bug. I disabled it in grub conf and system
>> works correctly. Is there any chance to completely remove plymouth
>> from the system? (even from initrd)
>> 4 - F12 boots really slow on my laptop
>> http://www.stardust.webpages.pl/files/tmp/bootchart.png something
>> wrong is happening while udev loading
>> 5 - default gnome sound scheme is terrible
>>
>> The first impression isn't good.
>>
>> Regards,
>> Michal
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>



From drepper at redhat.com  Sat Oct 24 14:14:39 2009
From: drepper at redhat.com (Ulrich Drepper)
Date: Sat, 24 Oct 2009 07:14:39 -0700
Subject: Fedora with Universal Binaries?
In-Reply-To: 
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>	<20091023173525.GA9400@host0.dyn.jankratochvil.net>
	
Message-ID: <4AE30BCF.7030304@redhat.com>

On 10/23/2009 07:01 PM, Kevin Kofler wrote:
> It was (mostly) ignored because it doubles the download size and makes the
> image no longer fit on a CD, for little benefit.

Yes.  It is a "solution" which adds costs in many, many places for a 
problem that doesn't exist.  I don't see why people even spend a second 
thinking about this.

-- 
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?



From opensource at till.name  Sat Oct 24 14:57:54 2009
From: opensource at till.name (Till Maas)
Date: Sat, 24 Oct 2009 16:57:54 +0200
Subject: Fedora with Universal Binaries?
In-Reply-To: <4AE30BCF.7030304@redhat.com>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<20091023173525.GA9400@host0.dyn.jankratochvil.net>
	 <4AE30BCF.7030304@redhat.com>
Message-ID: <20091024145754.GA1446@genius.kawo2.rwth-aachen.de>

On Sat, Oct 24, 2009 at 07:14:39AM -0700, Ulrich Drepper wrote:
> On 10/23/2009 07:01 PM, Kevin Kofler wrote:
>> It was (mostly) ignored because it doubles the download size and makes the
>> image no longer fit on a CD, for little benefit.
>
> Yes.  It is a "solution" which adds costs in many, many places for a  
> problem that doesn't exist.  I don't see why people even spend a second  
> thinking about this.

For me it would be useful to have a simple way to make a USB
installation device for both my 32bit and 64bit machines. Also a single
rescue system for both 64bit and 32bit machines would be nice.

Regards
Till



From ndbecker2 at gmail.com  Sat Oct 24 15:30:08 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sat, 24 Oct 2009 11:30:08 -0400
Subject: Major reorganization of TeX Live packages
References: <20091022111704.GA5276@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091022124241.GA5996@dhcp-lab-133.englab.brq.redhat.com>
	
	<1256309762.5269.2.camel@politzer.theorphys.helsinki.fi>
Message-ID: 

xelatex issue?

I don't know much about xelatex, so maybe user error, but:

 xelatex python-intro.tex 
.....
warning: Configuration file texmf.cnf not found! Searched these directories:
/usr/bin:/usr:/:/usr/bin/share/texmf-local/web2c:/usr/share/texmf-
local/web2c://share/texmf-local/web2c:/usr/bin/texmf-local/web2c:/usr/texmf-
local/web2c://texmf-
local/web2c:/etc/texmf/web2c:/usr/local/share/texmf/web2c:/usr/share/texmf/web2c:/usr/share/texmf/web2c
Trying to proceed...
[2] [3] (./python-intro.aux)
Output file removed.

Why is it looking everywhere except the right place?
I tried removing all .aux, .toc, etc.



From cmadams at hiwaay.net  Sat Oct 24 16:50:32 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 24 Oct 2009 11:50:32 -0500
Subject: Fedora with Universal Binaries?
In-Reply-To: <20091024145754.GA1446@genius.kawo2.rwth-aachen.de>
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	<20091023173525.GA9400@host0.dyn.jankratochvil.net>
	 <4AE30BCF.7030304@redhat.com>
	<20091024145754.GA1446@genius.kawo2.rwth-aachen.de>
Message-ID: <20091024165032.GA1566238@hiwaay.net>

Once upon a time, Till Maas  said:
> For me it would be useful to have a simple way to make a USB
> installation device for both my 32bit and 64bit machines. Also a single
> rescue system for both 64bit and 32bit machines would be nice.

A much better approach would be to get the image tools (both install and
LiveCD) to support more than one image on a device (DVD or USB).
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From mike at miketc.net  Sat Oct 24 18:15:12 2009
From: mike at miketc.net (Mike Chambers)
Date: Sat, 24 Oct 2009 13:15:12 -0500
Subject: Rawhide install nfs fails
Message-ID: <1256408112.1632.20.camel@localhost>

I mirror rawhide on a F11 box, that I normally nfs mount from a rawhide
running system.  Tried to do an nfs based install from rawhide 2 days
ago and it failed, but installing via http from outside source (I don't
have http setup on the box) worked. So I guess I am asking is if nfs
based installs currently work, or at least do they work if the host is
an F11 box and the client will be a new rawhide box?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From kwhiskerz at gmail.com  Sat Oct 24 19:33:19 2009
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Sat, 24 Oct 2009 13:33:19 -0600
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
	 
	 
Message-ID: 

I should add that, for the first time ever, the slider 
bars work! They don't flicker and disappear and reappear. 
This is looking very good. Colours are a minor touch, 
icing on the cake.

By the way, colours on old kde3 apps doesn't work, 
either, despite enabling for non-kde4 applications in 
system settings (kftpgrabber) - I can see it already: 
file a bug report :-)



From orion at cora.nwra.com  Sat Oct 24 19:37:05 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Sat, 24 Oct 2009 13:37:05 -0600
Subject: Rawhide install nfs fails
In-Reply-To: <1256408112.1632.20.camel@localhost>
References: <1256408112.1632.20.camel@localhost>
Message-ID: <4AE35761.9000801@cora.nwra.com>

On 10/24/2009 12:15 PM, Mike Chambers wrote:
> I mirror rawhide on a F11 box, that I normally nfs mount from a rawhide
> running system.  Tried to do an nfs based install from rawhide 2 days
> ago and it failed, but installing via http from outside source (I don't
> have http setup on the box) worked. So I guess I am asking is if nfs
> based installs currently work, or at least do they work if the host is
> an F11 box and the client will be a new rawhide box?
>

There are some issues:

https://bugzilla.redhat.com/show_bug.cgi?id=528537

-- 
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 pbrobinson at gmail.com  Sat Oct 24 21:35:09 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 24 Oct 2009 22:35:09 +0100
Subject: Fedora 12 Beta now available!
In-Reply-To: <1256046992.4242.24.camel@localhost.localdomain>
References: <1256046992.4242.24.camel@localhost.localdomain>
Message-ID: <5256d0b0910241435n58409b4fx5c1266218b41ba8c@mail.gmail.com>

Hi All,

> * Moblin graphical interface for netbooks - The Moblin graphical
> interface and applications are fully integrated thanks to Peter
> Robinson, a Fedora Project volunteer, and others. To use it, just
> install the Moblin Desktop Environment package group using yum or the
> graphical software management tools, and choose Moblin from the login
> manager. A F12 Moblin Fedora Remix (installable Live CD) will also be
> available.

I'm a little late to the Fedora 12 beta party (thanks to life for
getting in the way) as I was hoping to get a test LiveCD out right
after the beta but fashionably late here is the first cut of the
"Fedora Mini - Moblin" livecd based on todays rawhide. It has been
tested on a eee PC 901 and should work fine on Intel Atom based
netbooks. You mileage may vary on other platforms especially on non
Intel graphics cards.

Please let me know of feedback on the live cd and report bugs against
specific packages.

Enjoy....
http://fedora.roving-it.com/FedoraMoblin12-LiveCD.iso

I plan to do at least weekly test releases of the livecd in the lead
up to Fedora 12.

Cheers,
Peter



From che666 at gmail.com  Sun Oct 25 02:06:48 2009
From: che666 at gmail.com (Rudolf Kastl)
Date: Sun, 25 Oct 2009 03:06:48 +0100
Subject: idea: abrt plugin for yum rpm scriptlets output
Message-ID: 

Hello!

While doing some tests and installing a large part of the rawhide
repository content i see that there are various packages that have a
broken %post scriptlet or it is outputting some warnings. maybe it
would be an idea for a abrt-yum plugin to submit those "warnings" and
errors to bugzilla. unfortunately yum.log doesent record them either.

that could definitely help in keeping the house clean i guess.

kind regards,
Rudolf Kastl



From dtimms at iinet.net.au  Sun Oct 25 07:18:50 2009
From: dtimms at iinet.net.au (David Timms)
Date: Sun, 25 Oct 2009 18:18:50 +1100
Subject: mass rebuild and i586 rpms - glglobe
In-Reply-To: <4ADD8782.10801@fi.muni.cz>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<4ADD8782.10801@fi.muni.cz>
Message-ID: <4AE3FBDA.60003@iinet.net.au>

On 10/20/2009 08:48 PM, Milos Jakubicek wrote:
> http://mjakubicek.fedorapeople.org/need-rebuild.html
hmmn, glglobe is mine, wonder what went wrong.

It seems that the build logs are no longer available ?
https://koji.fedoraproject.org/koji/taskinfo?taskID=1504772
eg for: x86_64  (red)
https://koji.fedoraproject.org/koji/taskinfo?taskID=1516629

And the other 3x orange ones appear to mean cancelled, is that correct ?
Wonder whether they were cancelled manually (ie the whole rebuild) ?
Or did the fail on one arch trigger the cancels ?

Anyway, a scratch build (without change) succeeds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1766626

Should I bump and rebuild, or just re-request the same build ?
Should I request it to be in F-12 ? (the i586.f11 one that is in f-12 
beta (rawhide) works OK).

DaveT.



From sundaram at fedoraproject.org  Sun Oct 25 07:19:16 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 25 Oct 2009 12:49:16 +0530
Subject: Fedora 12 Beta
In-Reply-To: <234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>
	<234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com>
Message-ID: <4AE3FBF4.7060707@fedoraproject.org>

On 10/24/2009 06:17 PM, Ilyes Gouta wrote:
> Hi,
> 
> Was Fedora 12 Beta released with all sort of debugging info. compiled in?
> I just want to find the cause of the general slowness ..

Yes. Development releases of Fedora have a large number of debugging
stuff enabled.

Rahul



From a.badger at gmail.com  Sun Oct 25 08:09:19 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 25 Oct 2009 01:09:19 -0700
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4AE24C65.1070901@fi.muni.cz>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
	<4AE24C65.1070901@fi.muni.cz>
Message-ID: <20091025080919.GD3204@clingman.lan>

On Sat, Oct 24, 2009 at 02:37:57AM +0200, Milos Jakubicek wrote:
>
> Newpackage (some of them even for months!):
> python-decorator3

Please do not rebuild this one.  It's currently just a forwards compat
package for EL-5.  I'll dead.package the devel package soon.

> zikula-module-filterutil
>
Please do not rebuild this one either.  I imported and built it for EL-5 for
someone I'm mentoring on packaging because we need it for Fedora Insight.
I'll be using building of the package for F-12 as part of mentoring when we
can both clear up some time.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From kevin.kofler at chello.at  Sun Oct 25 08:46:26 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 09:46:26 +0100
Subject: orphaning (eol) gtk-qt-engine
References:  
	 
	 
	 
	 
	
Message-ID: 

Petrus de Calguarium wrote:
> By the way, colours on old kde3 apps doesn't work,
> either, despite enabling for non-kde4 applications in
> system settings (kftpgrabber) - I can see it already:
> file a bug report :-)

There's already an ages-old bug report, the upstream KDE developers don't 
care. :-( You have to set up the colors separately for KDE 3 apps, using 
"kcmshell colors" (but it's a PITA as it doesn't support KDE 4 color 
schemes). I might try to fix this somehow.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 25 08:49:57 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 09:49:57 +0100
Subject: rawhide report: 20091024 changes
References: <20091024124005.GA17105@releng2.fedora.phx.redhat.com>
Message-ID: 

Rawhide Report wrote:
> nickle-2.69-2.fc12
> ------------------
> * Fri Oct 23 2009 Michel Salim  - 2.69-2
> - Lower FORTIFY setting; level 2 does not work with gcc 4.4.2

That's a completely WRONG fix!!! You MUST fix the application instead. 
Disabling security flags can't be the right approach to fix compilation, 
they're being used for a reason!

        Kevin Kofler



From denis at poolshark.org  Sun Oct 25 09:26:53 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 25 Oct 2009 10:26:53 +0100
Subject: rawhide report: 20091024 changes
In-Reply-To: 
References: <20091024124005.GA17105@releng2.fedora.phx.redhat.com>
	
Message-ID: <4AE419DD.2090804@poolshark.org>

On 10/25/2009 09:49 AM, Kevin Kofler wrote:
> Rawhide Report wrote:
>> nickle-2.69-2.fc12
>> ------------------
>> * Fri Oct 23 2009 Michel Salim  - 2.69-2
>> - Lower FORTIFY setting; level 2 does not work with gcc 4.4.2
>
> That's a completely WRONG fix!!! You MUST fix the application instead.
> Disabling security flags can't be the right approach to fix compilation,
> they're being used for a reason!

Calm down son, calm down.



From felix at fetzig.org  Sun Oct 25 11:17:27 2009
From: felix at fetzig.org (Felix Kaechele)
Date: Sun, 25 Oct 2009 12:17:27 +0100
Subject: OpenSER / Kamailio
Message-ID: <4AE433C7.2030503@fetzig.org>

Hi there,
I'm just starting to play with my SIP Phones using OpenSER.
I was wondering why there have been no updates to the OpenSER package
since it was renamed to Kamailio in version 1.4.0?
I did however notice that version 1.4.0 in fact is of an earlier date
than version 1.3.4 (which still is named OpenSER and is in Fedora).

So is there an actual difference between OpenSER and Kamailio - other
than the name - that prevents us from replacing the OpenSER package with
a Kamailio package. Or is it just that nobody has submitted a review
request for Kamailio yet?

Felix



From rawhide at fedoraproject.org  Sun Oct 25 11:38:56 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 25 Oct 2009 11:38:56 +0000
Subject: rawhide report: 20091025 changes
Message-ID: <20091025113856.GA2498@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 25 06:15:11 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From lemenkov at gmail.com  Sun Oct 25 12:46:35 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 25 Oct 2009 15:46:35 +0300
Subject: OpenSER / Kamailio
In-Reply-To: <4AE433C7.2030503@fetzig.org>
References: <4AE433C7.2030503@fetzig.org>
Message-ID: 

Hello All!

2009/10/25 Felix Kaechele :
> Hi there,
> I'm just starting to play with my SIP Phones using OpenSER.
> I was wondering why there have been no updates to the OpenSER package
> since it was renamed to Kamailio in version 1.4.0?

There are plans to package sip-router, when it will reach some level
of quality, since it's a merge of SER and OpenSER/Kamailio. Also,
there is an attempt to package OpenSIPs (another one fork of
SER/OpenSER codebase) - take a look here:

https://bugzilla.redhat.com/show_bug.cgi?id=529831

> I did however notice that version 1.4.0 in fact is of an earlier date
> than version 1.3.4 (which still is named OpenSER and is in Fedora).

1.3.4 is the last stable version of OpenSER. Since ver. 1.4.0 it was
rebranded as Kamailio.

> So is there an actual difference between OpenSER and Kamailio - other
> than the name - that prevents us from replacing the OpenSER package with
> a Kamailio package.

A lots, actually. There are some changes in config-file syntax, in
plugins and so on. Every version of OpenSER/Kamailio
(1.3.x/1.4.x/1.5.x) is incompatible to some degree with previous one.
Fortunately, they can be installed in parallel due to different naming
scheme.

The curse of this project is the team/features management issues,
which led project to the number of consequent forks (and one merge),
which confuses end users a lot. One of popular questions from
customers, is "which one from these routers should we choose -
SER/OpenSER/OpenSIPs/Kamailio/SIP-Router?". I'm voting for OpenSER
1.3.4 right now - it's stable and it was proved to work reliably.
Perhaps, at 2010, we may consider switching to SIP Router.

-- 
With best regards, Peter Lemenkov.



From sundaram at fedoraproject.org  Sun Oct 25 12:45:24 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 25 Oct 2009 18:15:24 +0530
Subject: Should installkernel be passing --dracut to new-kernel-pkg?
In-Reply-To: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
References: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
Message-ID: <4AE44864.3010306@fedoraproject.org>

On 10/22/2009 06:18 PM, Stephen Smalley wrote:
> Hi,
> 
> /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a
> make install from a kernel.org kernel tree tries to
> invoke /sbin/mkinitrd rather than dracut.  Is that intentional?
> 
> Also, any ideas on why a dracut-generated initramfs image generated for
> a kernel.org kernel tree would be so much larger than the Fedora kernel
> one (same .config)?
> 
> 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img
> 82M /boot/initramfs-2.6.32-rc2.img

If you want to reduce the size, set hostonly in /etc/dracut.conf

https://fedoraproject.org/wiki/Dracut/Options#-H.2C_--hostonly

Rahul



From sundaram at fedoraproject.org  Sun Oct 25 15:35:35 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 25 Oct 2009 21:05:35 +0530
Subject: Looking into LLVM
Message-ID: <4AE47047.9000401@fedoraproject.org>

Hi

LLVM 2.6 has been announced with Clang declared as production quality in
this release

http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html

Has anyone been looking into building Fedora with it to see how the
performance impact is?

Rahul



From m.a.young at durham.ac.uk  Sun Oct 25 16:12:05 2009
From: m.a.young at durham.ac.uk (M A Young)
Date: Sun, 25 Oct 2009 16:12:05 +0000 (GMT)
Subject: Rawhide install nfs fails
In-Reply-To: <1256408112.1632.20.camel@localhost>
References: <1256408112.1632.20.camel@localhost>
Message-ID: 

On Sat, 24 Oct 2009, Mike Chambers wrote:

> I mirror rawhide on a F11 box, that I normally nfs mount from a rawhide
> running system.  Tried to do an nfs based install from rawhide 2 days
> ago and it failed, but installing via http from outside source (I don't
> have http setup on the box) worked. So I guess I am asking is if nfs
> based installs currently work, or at least do they work if the host is
> an F11 box and the client will be a new rawhide box?

I tried installing the F12 beta a couple of days ago, and couldn't get 
that to work over nfs even with some of the suggested workarounds, so 
switched to http.

 	Michael Young



From tmz at pobox.com  Sun Oct 25 16:47:00 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 25 Oct 2009 12:47:00 -0400
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
Message-ID: <20091025164700.GC5289@inocybe.localdomain>

Hi Ha?kel,

Ha?kel Gu?mar wrote:
> Author: hguemar
>
> Update of /cvs/extras/rpms/python-mpd/F-10
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27941
>
> Modified Files:
> 	python-mpd.spec sources
> Log Message:
> Updated to 0.2.1

Any reason to update this for F-10 (or any Fedora branches really), as
the only change upstream from 0.2.0 was to fix a minor bug on Windows?
The 0.2.1 release was made in June 2008 and we've lived without it
until now. ;)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, now my good man, this is no time for making enemies.
    -- Voltaire, on his deathbed in response to a priest asking that
    he renounce Satan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From tmz at pobox.com  Sun Oct 25 16:53:58 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 25 Oct 2009 12:53:58 -0400
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <20091025164700.GC5289@inocybe.localdomain>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
Message-ID: <20091025165358.GD5289@inocybe.localdomain>

I wrote:
> Hi Ha?kel,
>
> Ha?kel Gu?mar wrote:
>> Author: hguemar
>>
>> Update of /cvs/extras/rpms/python-mpd/F-10
>> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27941
>>
>> Modified Files:
>> 	python-mpd.spec sources
>> Log Message:
>> Updated to 0.2.1
>
> Any reason to update this for F-10 (or any Fedora branches really), as
> the only change upstream from 0.2.0 was to fix a minor bug on Windows?
> The 0.2.1 release was made in June 2008 and we've lived without it
> until now. ;)

BTW, your email address has a typo in the %changelog. :/

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A facility for quotation covers the absence of original thought.
    -- Peter Wimsey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From kevin.kofler at chello.at  Sun Oct 25 17:21:22 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 18:21:22 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org>
Message-ID: 

Rahul Sundaram wrote:
> LLVM 2.6 has been announced with Clang declared as production quality in
> this release
> 
> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
> 
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?

A lot of upstream software on GNU/Linux only supports GCC. Clang tries to 
support GCC extensions, but I strongly doubt it'll compile all upstream code 
unchanged, and upstream projects might even reject patches to fix the build 
with Clang because they only support GCC.

        Kevin Kofler



From ngompa13 at gmail.com  Sun Oct 25 17:35:59 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Sun, 25 Oct 2009 12:35:59 -0500
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org> 
Message-ID: <8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>

On Sun, Oct 25, 2009 at 12:21 PM, Kevin Kofler wrote:

> Rahul Sundaram wrote:
> > LLVM 2.6 has been announced with Clang declared as production quality in
> > this release
> >
> >
> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
> >
> > Has anyone been looking into building Fedora with it to see how the
> > performance impact is?
>
> A lot of upstream software on GNU/Linux only supports GCC. Clang tries to
> support GCC extensions, but I strongly doubt it'll compile all upstream
> code
> unchanged, and upstream projects might even reject patches to fix the build
> with Clang because they only support GCC.
>
>        Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Also, clang's support with C++ ABI is still very broken. It's listed under
known issues. While most applications are made with C or Python, there are
still a fair number of C++ applications...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sundaram at fedoraproject.org  Sun Oct 25 17:38:33 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 25 Oct 2009 23:08:33 +0530
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org> 
Message-ID: <4AE48D19.7090907@fedoraproject.org>

On 10/25/2009 10:51 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> LLVM 2.6 has been announced with Clang declared as production quality in
>> this release
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
>>
>> Has anyone been looking into building Fedora with it to see how the
>> performance impact is?
> 
> A lot of upstream software on GNU/Linux only supports GCC. Clang tries to 
> support GCC extensions, but I strongly doubt it'll compile all upstream code 
> unchanged, and upstream projects might even reject patches to fix the build 
> with Clang because they only support GCC.

We wouldn't know unless we try. Guess work doesn't lead to much. Hence
my question. Has anyone actually tried to do compile say a large C
codebase with LLVM?

Rahul



From xjakub at fi.muni.cz  Sun Oct 25 18:11:15 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Sun, 25 Oct 2009 19:11:15 +0100
Subject: mass rebuild and i586 rpms - glglobe
In-Reply-To: <4AE3FBDA.60003@iinet.net.au>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>	<4ADD8782.10801@fi.muni.cz>
	<4AE3FBDA.60003@iinet.net.au>
Message-ID: <4AE494C3.3040903@fi.muni.cz>

On 25.10.2009 08:18, David Timms wrote:
> On 10/20/2009 08:48 PM, Milos Jakubicek wrote:
>> http://mjakubicek.fedorapeople.org/need-rebuild.html
> hmmn, glglobe is mine, wonder what went wrong.
> It seems that the build logs are no longer available ?

No, they are kept only for 14(?) days or so.

> Should I bump and rebuild, or just re-request the same build ?
> Should I request it to be in F-12 ? (the i586.f11 one that is in f-12
> beta (rawhide) works OK).

I've rebuilt and will request tagging together with some other packages.

Milos



From ndbecker2 at gmail.com  Sun Oct 25 19:05:34 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 25 Oct 2009 15:05:34 -0400
Subject: texlive 2009 - should set TEXMFCNF?
Message-ID: 

I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, 
so that other packages, such as xdvipdfmx will work?  Or, should texlive 
just obsolete xdvipdfmx and include it's own version?



From karlthered at gmail.com  Sun Oct 25 19:56:06 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Sun, 25 Oct 2009 20:56:06 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <20091025165358.GD5289@inocybe.localdomain>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
Message-ID: <4AE4AD56.90705@gmail.com>

Le 25/10/2009 17:53, Todd Zullinger a ?crit :
> I wrote:
>> Hi Ha?kel,
>>
>> Ha?kel Gu?mar wrote:
>>> Author: hguemar
>>>
>>> Update of /cvs/extras/rpms/python-mpd/F-10
>>> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27941
>>>
>>> Modified Files:
>>> 	python-mpd.spec sources
>>> Log Message:
>>> Updated to 0.2.1
>>
>> Any reason to update this for F-10 (or any Fedora branches really), as
>> the only change upstream from 0.2.0 was to fix a minor bug on Windows?
>> The 0.2.1 release was made in June 2008 and we've lived without it
>> until now. ;)
> 
> BTW, your email address has a typo in the %changelog. :/
> 

Thank you, i'll fix this.
This is personal policy to always push latest stable unless it's broken,
since it wasn't critical, i had always delayed it.
Why i pushed the update on older branches ? Maintainers are asked to
support branches until EOL and it worked on my test VM.
Maybe, i'm just a bit maniacal. ;)

Did it break anything ? For the moment, updates are staging in testing,
i can unpush them if you think it's more appropriate. :)

H.



From jonathan.underwood at gmail.com  Sun Oct 25 20:14:57 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 25 Oct 2009 20:14:57 +0000
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: 
References: 
Message-ID: <645d17210910251314i4260718ci2c62414feaa94388@mail.gmail.com>

2009/10/25 Neal Becker :
> I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF,
> so that other packages, such as xdvipdfmx will work? ?Or, should texlive
> just obsolete xdvipdfmx and include it's own version?

IMO the latter.



From tmz at pobox.com  Sun Oct 25 21:16:32 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 25 Oct 2009 17:16:32 -0400
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <4AE4AD56.90705@gmail.com>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain> <4AE4AD56.90705@gmail.com>
Message-ID: <20091025211632.GE5289@inocybe.localdomain>

Ha?kel Gu?mar wrote:
> This is personal policy to always push latest stable unless it's broken,
> since it wasn't critical, i had always delayed it.
> Why i pushed the update on older branches ? Maintainers are asked to
> support branches until EOL and it worked on my test VM.
> Maybe, i'm just a bit maniacal. ;)
>
> Did it break anything ? For the moment, updates are staging in testing,
> i can unpush them if you think it's more appropriate. :)

Nope, nothing breaks AFAIK (mostly because nothing relevant to a
non-windows system changed, other than the version number).  I was
just curious to know the reason for the update.  Thanks.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Man was made at the end of the week's work when God was tired.
    -- Mark Twain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: 

From christoph.wickert at googlemail.com  Sun Oct 25 21:20:59 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 25 Oct 2009 22:20:59 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <4AE4AD56.90705@gmail.com>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain> <4AE4AD56.90705@gmail.com>
Message-ID: <1256505660.3007.63.camel@wicktop.localdomain>

Am Sonntag, den 25.10.2009, 20:56 +0100 schrieb Ha?kel Gu?mar:

> This is personal policy to always push latest stable unless it's broken,
> since it wasn't critical, i had always delayed it.
> Why i pushed the update on older branches ? Maintainers are asked to
> support branches until EOL and it worked on my test VM.
> Maybe, i'm just a bit maniacal. ;)

Definitely. ;) To "support" does not mean to drown users in useless
updates. We had this discussions over and over again, please look for
the thread called "The updates firehose" back in June 2007.

> Did it break anything ? For the moment, updates are staging in testing,
> i can unpush them if you think it's more appropriate. :)

In this case I think you really should unpush it. Not only for F-11 but
for F-11 as well, possibly F12 to. If this update doesn't fix anything
on Linux, then don't push it.

> H.

Regards,
Christoph



From pingou at pingoured.fr  Sun Oct 25 21:28:58 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Sun, 25 Oct 2009 22:28:58 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <1256505660.3007.63.camel@wicktop.localdomain>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain> <4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
Message-ID: <1256506138.2632.6.camel@red.pingoured.fr>

On Sun, 2009-10-25 at 22:20 +0100, Christoph Wickert wrote: 
> Am Sonntag, den 25.10.2009, 20:56 +0100 schrieb Ha?kel Gu?mar:
> 
> > This is personal policy to always push latest stable unless it's broken,
> > since it wasn't critical, i had always delayed it.
> > Why i pushed the update on older branches ? Maintainers are asked to
> > support branches until EOL and it worked on my test VM.
> > Maybe, i'm just a bit maniacal. ;)
> 
> Definitely. ;) To "support" does not mean to drown users in useless
> updates. We had this discussions over and over again, please look for
> the thread called "The updates firehose" back in June 2007.
> 
> > Did it break anything ? For the moment, updates are staging in testing,
> > i can unpush them if you think it's more appropriate. :)
> 
> In this case I think you really should unpush it. Not only for F-11 but
> for F-11 as well, possibly F12 to. If this update doesn't fix anything
> on Linux, then don't push it.

Then you get bug from people expecting the latest version because you're
not up to date...

Come-on this is maintainer decision and as long as it doesn't break
anyone, leave it that way.

Pierre



From pingou at pingoured.fr  Sun Oct 25 21:31:15 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Sun, 25 Oct 2009 22:31:15 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <1256506138.2632.6.camel@red.pingoured.fr>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain> <4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<1256506138.2632.6.camel@red.pingoured.fr>
Message-ID: <1256506275.2632.7.camel@red.pingoured.fr>

On Sun, 2009-10-25 at 22:28 +0100, Pierre-Yves wrote: 
> On Sun, 2009-10-25 at 22:20 +0100, Christoph Wickert wrote: 
> > Am Sonntag, den 25.10.2009, 20:56 +0100 schrieb Ha?kel Gu?mar:
> > 
> > > This is personal policy to always push latest stable unless it's broken,
> > > since it wasn't critical, i had always delayed it.
> > > Why i pushed the update on older branches ? Maintainers are asked to
> > > support branches until EOL and it worked on my test VM.
> > > Maybe, i'm just a bit maniacal. ;)
> > 
> > Definitely. ;) To "support" does not mean to drown users in useless
> > updates. We had this discussions over and over again, please look for
> > the thread called "The updates firehose" back in June 2007.
> > 
> > > Did it break anything ? For the moment, updates are staging in testing,
> > > i can unpush them if you think it's more appropriate. :)
> > 
> > In this case I think you really should unpush it. Not only for F-11 but
> > for F-11 as well, possibly F12 to. If this update doesn't fix anything
> > on Linux, then don't push it.
> 
> Then you get bug from people expecting the latest version because you're
> not up to date...
> 
> Come-on this is maintainer decision and as long as it doesn't break
> anyone, leave it that way.
err s/anyone/anything/, sorry

Pierre



From mschwendt at gmail.com  Sun Oct 25 21:32:44 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 25 Oct 2009 22:32:44 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <1256505660.3007.63.camel@wicktop.localdomain>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
Message-ID: <20091025223244.16b2bdca@faldor.intranet>

On Sun, 25 Oct 2009 22:20:59 +0100, Christoph wrote:

> Am Sonntag, den 25.10.2009, 20:56 +0100 schrieb Ha?kel Gu?mar:
> 
> > This is personal policy to always push latest stable unless it's broken,
> > since it wasn't critical, i had always delayed it.
> > Why i pushed the update on older branches ? Maintainers are asked to
> > support branches until EOL and it worked on my test VM.
> > Maybe, i'm just a bit maniacal. ;)
> 
> Definitely. ;) To "support" does not mean to drown users in useless
> updates. We had this discussions over and over again, please look for
> the thread called "The updates firehose" back in June 2007.
> 
> > Did it break anything ? For the moment, updates are staging in testing,
> > i can unpush them if you think it's more appropriate. :)
> 
> In this case I think you really should unpush it. Not only for F-11 but
> for F-11 as well, possibly F12 to. If this update doesn't fix anything
> on Linux, then don't push it.

And once again, the bodhi update requests for these updates don't try to
explain what changes come with these updates. They are only marked as "bug
fix" updates with no notes that give details.



From mschwendt at gmail.com  Sun Oct 25 21:38:43 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 25 Oct 2009 22:38:43 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <1256506138.2632.6.camel@red.pingoured.fr>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<1256506138.2632.6.camel@red.pingoured.fr>
Message-ID: <20091025223843.37181961@faldor.intranet>

On Sun, 25 Oct 2009 22:28:58 +0100, Pierre-Yves wrote:

> Then you get bug from people expecting the latest version because you're
> not up to date...

Ridiculous. It's easy to close such tickets as NOTABUG and explain to such
people why an update doesn't make sense.



From karlthered at gmail.com  Sun Oct 25 21:39:56 2009
From: karlthered at gmail.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=)
Date: Sun, 25 Oct 2009 22:39:56 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <1256505660.3007.63.camel@wicktop.localdomain>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>	<20091025164700.GC5289@inocybe.localdomain>	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
Message-ID: <4AE4C5AC.3090608@gmail.com>

Le 25/10/2009 22:20, Christoph Wickert a ?crit :
> Am Sonntag, den 25.10.2009, 20:56 +0100 schrieb Ha?kel Gu?mar:
> 
>> This is personal policy to always push latest stable unless it's broken,
>> since it wasn't critical, i had always delayed it.
>> Why i pushed the update on older branches ? Maintainers are asked to
>> support branches until EOL and it worked on my test VM.
>> Maybe, i'm just a bit maniacal. ;)
> 
> Definitely. ;) To "support" does not mean to drown users in useless
> updates. We had this discussions over and over again, please look for
> the thread called "The updates firehose" back in June 2007.
> 
>> Did it break anything ? For the moment, updates are staging in testing,
>> i can unpush them if you think it's more appropriate. :)
> 
> In this case I think you really should unpush it. Not only for F-11 but
> for F-11 as well, possibly F12 to. If this update doesn't fix anything
> on Linux, then don't push it.
> 
>> H.
> 
> Regards,
> Christoph
> 


This was a very very low priority task for me, python-mpd is roughly one
python file mpd.py. There was only one use-case, i could think about :
an unexperienced developer including it in his "multiplatform" project.
Then, he shares it with his friend under windows (nobody is perfect) and
bang it fails!
Since, this is so controversial, i'll just let them rot on testing, then
end of discussion.


Best regards,
H.



From kevin.kofler at chello.at  Sun Oct 25 21:52:14 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 22:52:14 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
Message-ID: 

King InuYasha wrote:
> Also, clang's support with C++ ABI is still very broken. It's listed under
> known issues.

Actually, the ABI issue is only if you use the C code generator, not the 
native ones.

The real problem is that C++ support in Clang is just not complete. You may 
have more luck with llvm-g++, but that one always has trouble keeping up 
with current GCC and it probably doesn't bring all that many benefits over 
just using GCC.

> While most applications are made with C or Python, there are still a fair
> number of C++ applications...

(Nearly) all of KDE is C++!

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 25 21:52:59 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 22:52:59 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<1256506138.2632.6.camel@red.pingoured.fr>
Message-ID: 

Pierre-Yves wrote:
> Then you get bug from people expecting the latest version because you're
> not up to date...

That's what NOTABUG is for.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 25 21:55:45 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 22:55:45 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<20091025223244.16b2bdca@faldor.intranet>
Message-ID: 

Michael Schwendt wrote:
> And once again, the bodhi update requests for these updates don't try to
> explain what changes come with these updates. They are only marked as "bug
> fix" updates with no notes that give details.

Right, we really need some enforcement against this practice.

I have no issues with updates getting pushed (unless they're as useless as 
this one), but I do want to know what changed!

And a hint: if you don't know what to fill in, ask yourself whether the 
update is worth pushing at all. (But don't refuse to push something just 
because you're too lazy to fill in the update details, either!)

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 25 21:59:01 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 22:59:01 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
Message-ID: 

Ha?kel Gu?mar wrote:
> This is personal policy to always push latest stable unless it's broken,

This makes sense in principle, but not if nothing (of relevance to Fedora) 
actually changed.

> Why i pushed the update on older branches ? Maintainers are asked to
> support branches until EOL and it worked on my test VM.

It's also a good reflex to support all branches with updates, especially 
bugfix updates (and I wish more people would do it), but again, only if 
there's a reason to push the update in the first place. :-)

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 25 21:57:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Oct 2009 22:57:07 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<4AE4C5AC.3090608@gmail.com>
Message-ID: 

Ha?kel Gu?mar wrote:
> This was a very very low priority task for me, python-mpd is roughly one
> python file mpd.py. There was only one use-case, i could think about :
> an unexperienced developer including it in his "multiplatform" project.

People bundling system libraries deserve whatever they get. We definitely 
don't support this usecase.

> Since, this is so controversial, i'll just let them rot on testing, then
> end of discussion.

It's better to unpush them. Updates should not be sitting in testing 
forever.

        Kevin Kofler



From mschwendt at gmail.com  Sun Oct 25 22:25:41 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 25 Oct 2009 23:25:41 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: <4AE4C5AC.3090608@gmail.com>
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>
	<20091025164700.GC5289@inocybe.localdomain>
	<20091025165358.GD5289@inocybe.localdomain>
	<4AE4AD56.90705@gmail.com>
	<1256505660.3007.63.camel@wicktop.localdomain>
	<4AE4C5AC.3090608@gmail.com>
Message-ID: <20091025232541.00b90a21@faldor.intranet>

On Sun, 25 Oct 2009 22:39:56 +0100, Ha?kel wrote:

> This was a very very low priority task for me, python-mpd is roughly one
> python file mpd.py. There was only one use-case, i could think about :
> an unexperienced developer including it in his "multiplatform" project.
> Then, he shares it with his friend under windows (nobody is perfect) and
> bang it fails!

Expand that scenario a little bit [1]: Imagine that mpd.py suffers from
further bugs specific to that other OS. Would the "unexperienced
developer" or "his friend" request bug-fix updates _from you_?

-- 
[1] And as another step, one could map it to the source archives we
redistribute in src.rpm packages.



From karlthered at gmail.com  Sun Oct 25 22:51:46 2009
From: karlthered at gmail.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=)
Date: Sun, 25 Oct 2009 23:51:46 +0100
Subject: rpms/python-mpd/F-10 python-mpd.spec,1.2,1.3 sources,1.2,1.3
In-Reply-To: 
References: <20091025163551.BCDCC11C00E5@cvs1.fedora.phx.redhat.com>	<20091025164700.GC5289@inocybe.localdomain>	<20091025165358.GD5289@inocybe.localdomain>	<4AE4AD56.90705@gmail.com>
	
Message-ID: <4AE4D682.3010905@gmail.com>

Le 25/10/2009 22:59, Kevin Kofler a ?crit :
> 
> It's also a good reflex to support all branches with updates, especially 
> bugfix updates (and I wish more people would do it), but again, only if 
> there's a reason to push the update in the first place. :-)
> 
>         Kevin Kofler
> 

they were unpushed, good package monkeys should listen their peers.

H.



From Matt_Domsch at dell.com  Sun Oct 25 23:36:32 2009
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 25 Oct 2009 18:36:32 -0500
Subject: Should installkernel be passing --dracut to new-kernel-pkg?
In-Reply-To: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
References: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
Message-ID: <20091025233632.GB15785@auslistsprd01.us.dell.com>

On Thu, Oct 22, 2009 at 08:48:03AM -0400, Stephen Smalley wrote:
> Hi,
> 
> /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a
> make install from a kernel.org kernel tree tries to
> invoke /sbin/mkinitrd rather than dracut.  Is that intentional?

Don't know if it's intentional, probably an oversite, but I did get
bitten by this last week myself.

-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From awilliam at redhat.com  Mon Oct 26 00:38:16 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sun, 25 Oct 2009 17:38:16 -0700
Subject: Recap: blocker bug review meeting 2009-10-23
Message-ID: <1256517496.2314.544.camel@adam.local.net>

We held the first official blocker bug review meeting for Fedora 12
final release on Friday, 2009-10-23. Many thanks to James Laska, Jesse
Keating, Ray Strode, Matej Cepl, Denise Dumas, Justin Forbes, Bill
Nottingham, Edward Kirk, and Matthias Clasen for their contributions.

We ran through all 51 bugs on the blocker list at the time of the
meeting, accepting or dropping them as blockers and working to ensure
all remaining blockers are in the process of being fixed.

You can see a summary of the entire meeting, with the final decision on
each bug, at:

http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-23/fedora-bugzappers.2009-10-23-15.00.html

a full log of the meeting (warning: extremely long) is available at:

http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-23/fedora-bugzappers.2009-10-23-15.00.log.html

The next blocker review meeting will be next Friday, 2009-10-30, at
15:00 UTC in #fedora-bugzappers. Thanks again to all who contributed.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From xjakub at fi.muni.cz  Mon Oct 26 01:05:37 2009
From: xjakub at fi.muni.cz (Milos Jakubicek)
Date: Mon, 26 Oct 2009 02:05:37 +0100
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <1256232577.2497.43.camel@samson.armitage.org.uk>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
Message-ID: <4AE4F5E1.1060308@fi.muni.cz>

Next bunch built, it's a complete set of those with mock exit status 30 
(I'm curious what does this exit status mean, missing prerequisity is 
denoted by 10) and some others too:

piggyback-2.6.26-4.fc12 (on sparc)
perl-Perl-Critic-1.105-1.fc12
glglobe-0.2-8.fc12
libica-2.0.2-1.fc12 (on s390)
openssl-ibmca-1.0.0-2.fc12 (on s390)
python-polybori-0.5-6.fc12
python-igraph-0.5.2-4.fc12
perl-POE-Component-Client-Keepalive-0.2600-3.fc12
mathgl-1.9-7.fc12
artwiz-aleczapka-fonts-1.3-8.fc12
python-xkit-0.4.2-4.fc12
389-dsgw-1.1.4-1.fc12
perl-Apache2-SOAP-0.73-3.fc12
gds2pov-0.20080229-3.fc12
gdesklets-0.36.1-6.fc12
gedit-plugins-2.26.1-3.fc12
giggle-0.4.91-3.fc12
glabels-2.2.5-2.fc12
gl-117-1.3.2-9.fc12
glade2-2.12.2-7.fc12
glitz-0.5.6-8.fc12
gliv-1.9.6-5.fc12
glob2-0.9.4.1-2.fc12
gnome-applet-grandr-0.4.1-2.fc12
gnome-applet-bubblemon-2.0.14-2.fc12
ladspa-swh-plugins-0.4.15-16.fc12
libbtctl-0.11.1-3.fc12
pfscalibration-1.4-7.fc12
pfstools-1.7.0-8.fc12
klibido-0.2.5-12.fc12
pfqueue-0.5.6-10.fc12
petitboot-0.2-4.fc12
baekmuk-bdf-fonts-2.2-8.fc12

We're slowly narrowing to reasonable count of packages (which are really 
either "going to be dead" or need fixing, though a few false positives 
are still in the list), everybody is encouraged to take anything from 
http://mjakubicek.fedorapeople.org/need-rebuild.html and try to fix it!;)

Regards,
Milos



From davej at redhat.com  Mon Oct 26 01:06:54 2009
From: davej at redhat.com (Dave Jones)
Date: Sun, 25 Oct 2009 21:06:54 -0400
Subject: Should installkernel be passing --dracut to new-kernel-pkg?
In-Reply-To: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
References: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
Message-ID: <20091026010654.GA12557@redhat.com>

On Thu, Oct 22, 2009 at 08:48:03AM -0400, Stephen Smalley wrote:
 > Hi,
 > 
 > /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a
 > make install from a kernel.org kernel tree tries to
 > invoke /sbin/mkinitrd rather than dracut.  Is that intentional?
 > 
 > Also, any ideas on why a dracut-generated initramfs image generated for
 > a kernel.org kernel tree would be so much larger than the Fedora kernel
 > one (same .config)?
 > 
 > 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img
 > 82M /boot/initramfs-2.6.32-rc2.img
 
Do you have CONFIG_DEBUG_INFO set ? The kernel specfile strips the debug info
out to separate debuginfo packages.  If you build it by hand, that doesn't happen,
so you get all the symbols etc attached to every module in your initramfs.

	Dave



From skvidal at fedoraproject.org  Mon Oct 26 01:33:17 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Sun, 25 Oct 2009 21:33:17 -0400 (EDT)
Subject: idea: abrt plugin for yum rpm scriptlets output
In-Reply-To: 
References: 
Message-ID: 



On Sun, 25 Oct 2009, Rudolf Kastl wrote:

> Hello!
>
> While doing some tests and installing a large part of the rawhide
> repository content i see that there are various packages that have a
> broken %post scriptlet or it is outputting some warnings. maybe it
> would be an idea for a abrt-yum plugin to submit those "warnings" and
> errors to bugzilla. unfortunately yum.log doesent record them either.
>
> that could definitely help in keeping the house clean i guess.
>

try running:

yum history

which will give you a list of yum transaction events.

Then taking whichever history id number from the left-most column and 
running:

yum history info $history_id_number -


see if that shows you some info about the scriptlets.

-sv



From craftjml at gmail.com  Mon Oct 26 03:38:31 2009
From: craftjml at gmail.com (Jud Craft)
Date: Sun, 25 Oct 2009 23:38:31 -0400
Subject: Fedora 12 Beta
In-Reply-To: <4AE3FBF4.7060707@fedoraproject.org>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com> 
	<234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com> 
	<234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com> 
	<4AE3FBF4.7060707@fedoraproject.org>
Message-ID: <20d6441a0910252038ge3aa6cdo9c89c8a55941ae02@mail.gmail.com>

On Sun, Oct 25, 2009 at 3:19 AM, Rahul Sundaram
 wrote:
> Yes. Development releases of Fedora have a large number of debugging
> stuff enabled.

I really can't tell if you're joking.



From craftjml at gmail.com  Mon Oct 26 03:40:58 2009
From: craftjml at gmail.com (Jud Craft)
Date: Sun, 25 Oct 2009 23:40:58 -0400
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org>  
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com> 
	
Message-ID: <20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>

On Sun, Oct 25, 2009 at 5:52 PM, Kevin Kofler  wrote:
> Actually, the ABI issue is only if you use the C code generator, not the
> native ones.

I'm not sure I understand.  How can LLVM-C be ABI-incompatible with plain GCC-C?

I thought that C doesn't have any crazy name or symbol or virtual
table mangling.  The stuff should just work, right?

Does that mean that I can't write a GTK program and compile with
LLVM-C, since I can't link to the GTK libraries?



From bruno at wolff.to  Mon Oct 26 03:50:47 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sun, 25 Oct 2009 22:50:47 -0500
Subject: Fedora 12 Beta
In-Reply-To: <20d6441a0910252038ge3aa6cdo9c89c8a55941ae02@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>
	<234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com>
	<4AE3FBF4.7060707@fedoraproject.org>
	<20d6441a0910252038ge3aa6cdo9c89c8a55941ae02@mail.gmail.com>
Message-ID: <20091026035047.GA30929@wolff.to>

On Sun, Oct 25, 2009 at 23:38:31 -0400,
  Jud Craft  wrote:
> On Sun, Oct 25, 2009 at 3:19 AM, Rahul Sundaram
>  wrote:
> > Yes. Development releases of Fedora have a large number of debugging
> > stuff enabled.
> 
> I really can't tell if you're joking.

I think that is an exageration. But at various times in the development
cycle debugging is often turned on in the kernel. This can impact performance
or just make the kernel downloads larger. There are separate debuginfo
packages you can get, but you don't get those by default.



From jreiser at bitwagon.com  Mon Oct 26 03:55:54 2009
From: jreiser at bitwagon.com (John Reiser)
Date: Sun, 25 Oct 2009 20:55:54 -0700
Subject: Looking into LLVM
In-Reply-To: <20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
	
	<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
Message-ID: <4AE51DCA.4090801@bitwagon.com>

> I'm not sure I understand.  How can LLVM-C be ABI-incompatible with plain GCC-C?

See /lib/libgcc_s.so.1 and its symbols, such as stack unwinding, uncommon or messy
conversions between data formats, expensive operations on 'long long', etc.

-- 



From sundaram at fedoraproject.org  Mon Oct 26 08:40:02 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 14:10:02 +0530
Subject: Fedora 12 Beta
In-Reply-To: <20d6441a0910252038ge3aa6cdo9c89c8a55941ae02@mail.gmail.com>
References: <596b53e0910210331l17f32f8bj4460d060b9cff459@mail.gmail.com>
	<234fa2210910240357g18f1f9a1yc20d30e6f2bb7474@mail.gmail.com>
	<234fa2210910240547u4ad90bddi672105db32790ef@mail.gmail.com>
	<4AE3FBF4.7060707@fedoraproject.org>
	<20d6441a0910252038ge3aa6cdo9c89c8a55941ae02@mail.gmail.com>
Message-ID: <4AE56062.7040102@fedoraproject.org>

On 10/26/2009 09:08 AM, Jud Craft wrote:
> On Sun, Oct 25, 2009 at 3:19 AM, Rahul Sundaram
wrote:
>> Yes. Development releases of Fedora have a large number of debugging
>> stuff enabled.
> 
> I really can't tell if you're joking.

No joke.

http://fedoraproject.org/wiki/KernelDebugStrategy

Rahul



From ismael at olea.org  Mon Oct 26 11:08:45 2009
From: ismael at olea.org (Ismael Olea)
Date: Mon, 26 Oct 2009 12:08:45 +0100
Subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora 
	Project?"])
In-Reply-To: 
References: <1256230254.9182.5.camel@localhost.localdomain>
	<1256246303.2314.501.camel@adam.local.net>
	<1256254863.9182.162.camel@localhost.localdomain>
	
	
Message-ID: <22a365930910260408t7c545c5bk49bc7828c506fa1@mail.gmail.com>

On Fri, Oct 23, 2009 at 8:24 AM, Mat?j Cepl  wrote:

>
> Just wanted to add my +1 and this is as good place as any other.
>

+1

-- 

Ismael Olea

http://olea.org/diario/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rawhide at fedoraproject.org  Mon Oct 26 12:42:43 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 26 Oct 2009 12:42:43 +0000
Subject: rawhide report: 20091026 changes
Message-ID: <20091026124243.GA22455@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 26 06:15:07 UTC 2009










Broken deps for ppc64
----------------------------------------------------------
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0



From ajax at redhat.com  Mon Oct 26 13:33:47 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 26 Oct 2009 09:33:47 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE47047.9000401@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
Message-ID: <1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>

On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:

> LLVM 2.6 has been announced with Clang declared as production quality in
> this release
> 
> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
> 
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?

I'm going to go out on a limb here and say that the dominating factor in
our performance is the code itself.

Also, last time I checked, llvm's dwarf support was even worse than
gcc's.  No thanks.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From sundaram at fedoraproject.org  Mon Oct 26 13:37:19 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 19:07:19 +0530
Subject: Looking into LLVM
In-Reply-To: <1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5A60F.9090802@fedoraproject.org>

On 10/26/2009 07:03 PM, Adam Jackson wrote:
> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
> 
>> LLVM 2.6 has been announced with Clang declared as production quality in
>> this release
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/000033.html
>>
>> Has anyone been looking into building Fedora with it to see how the
>> performance impact is?
> 
> I'm going to go out on a limb here and say that the dominating factor in
> our performance is the code itself.

I meant performance, primarily in terms of speed of compilation. Not the
code itself.

Rahul



From SteveD at redhat.com  Mon Oct 26 14:18:56 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 10:18:56 -0400
Subject: Rawhide install nfs fails
In-Reply-To: <1256408112.1632.20.camel@localhost>
References: <1256408112.1632.20.camel@localhost>
Message-ID: <4AE5AFD0.3010307@RedHat.com>

On 10/24/2009 02:15 PM, Mike Chambers wrote:
> I mirror rawhide on a F11 box, that I normally nfs mount from a rawhide
> running system.  Tried to do an nfs based install from rawhide 2 days
> ago and it failed, but installing via http from outside source (I don't
> have http setup on the box) worked. So I guess I am asking is if nfs
> based installs currently work, or at least do they work if the host is
> an F11 box and the client will be a new rawhide box?
> 
Is there any type of error code/message that is being logged??

steved.



From kevinverma at fedoraproject.org  Mon Oct 26 09:26:18 2009
From: kevinverma at fedoraproject.org (Kevin Verma)
Date: Mon, 26 Oct 2009 09:26:18 +0000 (UTC)
Subject: Howto build a static apcupsd package ?
Message-ID: 

Hi All, 

I am trying to build a static rpm of apcupsd but its failing with errors
on pastebin (http://pastebin.com/f101eee52) 

Can someone please suggest if something more needs to be done to
successfully compile apcupd as static ? 

SRPM of patch of makefile is on
http://fedorapeople.org/~kevinverma/apcupsd/apcupsd-3.14.7-1.fc11.src.rpm

ref: https://bugzilla.redhat.com/show_bug.cgi?id=346271#c16 

Thanks for reading ! 

~kevinverma 



From SteveD at redhat.com  Mon Oct 26 14:34:32 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 10:34:32 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
Message-ID: <4AE5B378.1000507@RedHat.com>

[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[At the bottom of this email has the workarounds if this change does ]
[indeed cause pain ]

As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
I am one commit away from changing the default protocol version NFS will 
be using (or at least trying to use).

What does this means to you? Hopefully nothing! In theory this should 
be a very seamless transition but with all new technology there
will be (and are) some rough spots. 

Why are make the change? See the NFSv4Default wiki for details,
but in a nutshell:
    * Better performance - V4 is now a stateful protocol. Meaning the server keeps 
      state on all the clients access a particular file or directory. This
      allows the server to give out delegations (or leases) which in turn
      allows the client to aggressive cache both data and meta data locally

    * Firewall Friendly- With v4 only one port is used 2049 for all traffic
      including mounting and file locking.

    * Finally it enables us use upcoming minor releases of the the protocol. 
      NFS version 4.1 and pNFS are two example of upcoming minor releases.


FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I 
personally have been using it for my home directory for a couple years now..
For more of the nitty gritty details see  
    http://www.iaps.com/NFSv4-new-features.html 

That's the good news... Here is the bad....

Because the mount command will try NFS v4 first, mounts to older Linux servers
will start failing like:

 # mount linux-server:/export /mnt
 mount.nfs: mounting linux-server:/export failed, reason given by server:
    No such file or directory

This is due to a defect in the Linux server exporting code, which is fixed 
in F-12, *but* there are a number of workarounds

On the server (Which is suggested):
   * Add the following entry to the /etc/exports file:
     / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.

On the client, go back to v3 mounts by doing one of the following:

   * Add -o v3 to command line, similar to:
        mount linux-server:/export /mnt

   * Change the default mount version in the new /etc/nfsmount.conf file by 
     uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
     See nfsmount.conf(5) man page for details. The diff would look like:

    --- /etc/nfsmount.conf.orig	2009-10-26 09:30:21.000000000 -0400
    +++ /etc/nfsmount.conf	2009-10-26 10:31:30.227443686 -0400
    @@ -31,7 +31,7 @@
    # Protocol Version [2,3,4]
    # This defines the default protocol version which will
    # be used to start the negotiation with the server.
   -# Defaultvers=4
   +Defaultvers=3
    #
    # Setting this option makes it mandatory the server supports the
    # given version. The mount will fail if the given version is 


steved.



From ajax at redhat.com  Mon Oct 26 14:45:37 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 26 Oct 2009 10:45:37 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5A60F.9090802@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
Message-ID: <1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
> On 10/26/2009 07:03 PM, Adam Jackson wrote:
> > On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
> >> Has anyone been looking into building Fedora with it to see how the
> >> performance impact is?
> > 
> > I'm going to go out on a limb here and say that the dominating factor in
> > our performance is the code itself.
> 
> I meant performance, primarily in terms of speed of compilation. Not the
> code itself.

Suppose it's faster.  Say even by a factor of 100.  So what?  What
problem would that solve?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From sundaram at fedoraproject.org  Mon Oct 26 14:43:00 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 20:13:00 +0530
Subject: Looking into LLVM
In-Reply-To: <1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>	
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>	
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5B574.2030503@fedoraproject.org>

On 10/26/2009 08:15 PM, Adam Jackson wrote:
> On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
>> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>>> Has anyone been looking into building Fedora with it to see how the
>>>> performance impact is?
>>>
>>> I'm going to go out on a limb here and say that the dominating factor in
>>> our performance is the code itself.
>>
>> I meant performance, primarily in terms of speed of compilation. Not the
>> code itself.
> 
> Suppose it's faster.  Say even by a factor of 100.  So what?  What
> problem would that solve?

The problem of slow compilation? :-)

Rahul



From ajax at redhat.com  Mon Oct 26 14:51:35 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 26 Oct 2009 10:51:35 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5B574.2030503@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
Message-ID: <1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote:
> On 10/26/2009 08:15 PM, Adam Jackson wrote:
> > On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
> >> On 10/26/2009 07:03 PM, Adam Jackson wrote:
> >>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
> >> I meant performance, primarily in terms of speed of compilation. Not the
> >> code itself.
> > 
> > Suppose it's faster.  Say even by a factor of 100.  So what?  What
> > problem would that solve?
> 
> The problem of slow compilation? :-)

Which affects who?  koji certainly seems to be keeping up with the load.

What I'm trying to pry out of you is what you'd be hoping to accomplish
by using it.  The answer so far seems to be "I'd spend less time
building things, at the cost of some unknown amount of time invested in
fixing everything to build again".  That doesn't sound like progress.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From pjones at redhat.com  Mon Oct 26 14:54:46 2009
From: pjones at redhat.com (Peter Jones)
Date: Mon, 26 Oct 2009 10:54:46 -0400
Subject: Looking into LLVM
In-Reply-To: <1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>	<4AE5A60F.9090802@fedoraproject.org>	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5B836.9040607@redhat.com>

On 10/26/2009 10:51 AM, Adam Jackson wrote:
> On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote:
>> On 10/26/2009 08:15 PM, Adam Jackson wrote:
>>> On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
>>>> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>>>>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>>> I meant performance, primarily in terms of speed of compilation. Not the
>>>> code itself.
>>>
>>> Suppose it's faster.  Say even by a factor of 100.  So what?  What
>>> problem would that solve?
>>
>> The problem of slow compilation? :-)
> 
> Which affects who?  koji certainly seems to be keeping up with the load.
> 
> What I'm trying to pry out of you is what you'd be hoping to accomplish
> by using it.  The answer so far seems to be "I'd spend less time
> building things, at the cost of some unknown amount of time invested in
> fixing everything to build again".  That doesn't sound like progress.

Well, that plus your already voiced complaint about its dwarf generation,
which is to say that any fairly immediate adoption would also make normal
development and debugging more painful.

-- 
        Peter

Gravity is a habit that is hard to shake off.
		-- Pratchett



From sundaram at fedoraproject.org  Mon Oct 26 14:51:09 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 20:21:09 +0530
Subject: Looking into LLVM
In-Reply-To: <1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>	
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>	
	<4AE5A60F.9090802@fedoraproject.org>	
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>	
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5B75D.1050200@fedoraproject.org>

On 10/26/2009 08:21 PM, Adam Jackson wrote:

> 
> Which affects who?  koji certainly seems to be keeping up with the load.
> 
> What I'm trying to pry out of you is what you'd be hoping to accomplish
> by using it.  The answer so far seems to be "I'd spend less time
> building things, at the cost of some unknown amount of time invested in
> fixing everything to build again".  That doesn't sound like progress.

Certainly status quo is easier.  Less time building things is a obvious
benefit. We don't know the cost unless we try. Doing a scratch build
similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
that we should never try at all doesn't seem appealing to me.

Rahul



From mbacovsk at redhat.com  Mon Oct 26 15:02:28 2009
From: mbacovsk at redhat.com (Martin Bacovsky)
Date: Mon, 26 Oct 2009 16:02:28 +0100
Subject: Action Tags concept
In-Reply-To: <20091023181712.GC13128@clingman.lan>
References: <200910211426.55849.mbacovsk@redhat.com>
	<200910232003.03083.mbacovsk@redhat.com>
	<20091023181712.GC13128@clingman.lan>
Message-ID: <200910261602.28875.mbacovsk@redhat.com>

On Friday 23 October 2009 20:17:12 Toshio Kuratomi wrote:
> On Fri, Oct 23, 2009 at 08:03:02PM +0200, Martin Bacovsky wrote:
> > On Friday 23 October 2009 17:51:16 you wrote:
> > > On Fri, Oct 23, 2009 at 04:46:36PM +0200, Martin Bacovsky wrote:
> > > > On Thursday 22 October 2009 16:33:06 you wrote:
> > > > > I like this concept.  How does it relate to tagging?
> > > > > * As a replacement for tagging
> > > > > * As a separate feature from tagging
> > > > > * In addition to tagging where some output utilizes both tags and
> > > > > actions
> > > >
> > > > I was thinking of replacing current tags, because I'm affraid users
> > > > will be confused by two kinds of tags. On the other hand I would keep
> > > > categories imported from .desktop files (readonly/searchonly).
> > >
> > > So I think we might be committed to having freeform tags for its use as
> > > a comps replacement and grouping mechanism. I'm not 100% sure though.
> > > There is overlap::
> > >
> > > python-openssl
> >
> > As python-openssl is not an application, this is rather hypothetical, but
> > I get your point.
> 
> Well, that could be part of the issue -- actions may be a great mapping for
> applications.  But tags are also for non-applications.
> 
> > > Also, how do we get the users to only enter actions(verbs) and not
> > > nouns when supplying new actions for a package?
> >
> > I'll start from here.  The form for action tag input should look like
> > this: "I use this application to ________________ and give it *****
> > stars." I hope it makes majority of users to fill it properly. I would
> > also expect users to fill actions like "secure connection" or "encrypt
> > data".
> >
> > Whole Application Database is targeted mainly to common users. This
> > concept was designed with that in mind. So Action is something I use my
> > computer (application) for i.e. write document, edit photos, play music
> > etc. Task is the same thing with the difference that I need more steps to
> > get it done. In other words Task is just container for Actions and is not
> > connected with application.
> >
> > The other way around, if I had such Task "Write programs in python that
> > can communicate with network services over SSL" I would it rather expect
> > to contain actions such as "edit sourcecode", "run commandline
> > application" and so on.
> >
> > Also if didn't choose the right names for entities I'm talking about
> > (Action, Task, ActionTag,..), feel free to suggest better ones.
> >
> > Anyway, the example with tags would apply for any application too, and it
> > seems we would loose usefull information  by removing freeform tags. The
> > question is how to effectively combine these two. Don't you think it may
> > be confusing/contarproductive to have two types of tags?
> 
> Yeah I agree we might be better off having both and figuring out UI that
> makes it less confusing.
> 
> I think that tagging is a superset of actions in some ways.  If I operate
>  on tags, I can't see a time where I wouldn't want to include actions when
>  figuring out the results.  OTOH, when I'm looking for actions, I probably
>  wouldn't be interested in the non-action tags.
> 
> Do actions and tasks seem like a mostly browse functionality?  Or a mostly
> search functionality to you?
> 
> -Toshio
> 

I would like to have actions visible on application page. Tasks are rather search functionality.
I'll  try to update the mockup and let you know.

Martin



From kparal at redhat.com  Mon Oct 26 15:09:02 2009
From: kparal at redhat.com (Kamil Paral)
Date: Mon, 26 Oct 2009 11:09:02 -0400 (EDT)
Subject: new tool: rpmguard - print important differences between RPMs
In-Reply-To: <1256127977.9617.7.camel@localhost>
Message-ID: <360474804.94321256569742360.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Alexey Torkhov"  wrote:

> On Wed, 2009-10-21 at 06:56 -0400, Kamil Paral wrote:
> > I have created a simple tool called rpmguard for checking
> differences 
> > between RPM packages. It is very similar to rpmdiff, but it prints
> only
> > important changes, not all. Therefore it can be used every time a
> new 
> > package is built to easily see if something hasn?t went completely
> wrong.
> > 
> > Read more on:
> >
> http://kparal.wordpress.com/2009/10/21/rpmguard-print-important-differences-between-rpms/
> > 
> > Any comments welcome!
> 
> One more important difference to check between packages is changes in
> library symbols. There is tool exist called rpmsodiff to check it.
> Would
> be nice to see that integrated too.
> 
> Alexey

Thanks for an idea, I have created a ticket for it:
https://fedorahosted.org/autoqa/ticket/75

Kamil



From pjones at redhat.com  Mon Oct 26 15:09:02 2009
From: pjones at redhat.com (Peter Jones)
Date: Mon, 26 Oct 2009 11:09:02 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5B75D.1050200@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>		<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>		<4AE5A60F.9090802@fedoraproject.org>		<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>		<4AE5B574.2030503@fedoraproject.org>	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B75D.1050200@fedoraproject.org>
Message-ID: <4AE5BB8E.4010203@redhat.com>

On 10/26/2009 10:51 AM, Rahul Sundaram wrote:
> On 10/26/2009 08:21 PM, Adam Jackson wrote:
> 
>>
>> Which affects who?  koji certainly seems to be keeping up with the load.
>>
>> What I'm trying to pry out of you is what you'd be hoping to accomplish
>> by using it.  The answer so far seems to be "I'd spend less time
>> building things, at the cost of some unknown amount of time invested in
>> fixing everything to build again".  That doesn't sound like progress.
> 
> Certainly status quo is easier.  Less time building things is a obvious
> benefit.

This is just myopia, though.  In isolation, yes, faster builds are nice.  But
if the faster builds result in poorer quality, then no, they're not a benefit.

> We don't know the cost unless we try. Doing a scratch build
> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
> that we should never try at all doesn't seem appealing to me.

Go ahead and set that up.  Report the result back to us.

-- 
        Peter

Gravity is a habit that is hard to shake off.
		-- Pratchett



From sundaram at fedoraproject.org  Mon Oct 26 15:07:29 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 20:37:29 +0530
Subject: Looking into LLVM
In-Reply-To: <4AE5BB8E.4010203@redhat.com>
References: <4AE47047.9000401@fedoraproject.org>		<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>		<4AE5A60F.9090802@fedoraproject.org>		<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>		<4AE5B574.2030503@fedoraproject.org>	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B75D.1050200@fedoraproject.org> <4AE5BB8E.4010203@redhat.com>
Message-ID: <4AE5BB31.1060908@fedoraproject.org>

On 10/26/2009 08:39 PM, Peter Jones wrote:

> This is just myopia, though.  In isolation, yes, faster builds are nice.  But
> if the faster builds result in poorer quality, then no, they're not a benefit.

Sure. Nobody claimed otherwise.

>> We don't know the cost unless we try. Doing a scratch build
>> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
>> that we should never try at all doesn't seem appealing to me.
> 
> Go ahead and set that up.  Report the result back to us.

I was asking if anybody has already tried that. Don't understand the
argument against it yet.

Rahul



From jgarzik at pobox.com  Mon Oct 26 15:11:48 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Mon, 26 Oct 2009 11:11:48 -0400
Subject: Looking into LLVM
In-Reply-To: <1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5BC34.9030605@pobox.com>

On 10/26/2009 10:45 AM, Adam Jackson wrote:
> On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote:
>> On 10/26/2009 07:03 PM, Adam Jackson wrote:
>>> On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote:
>>>> Has anyone been looking into building Fedora with it to see how the
>>>> performance impact is?
>>>
>>> I'm going to go out on a limb here and say that the dominating factor in
>>> our performance is the code itself.
>>
>> I meant performance, primarily in terms of speed of compilation. Not the
>> code itself.
>
> Suppose it's faster.  Say even by a factor of 100.  So what?  What
> problem would that solve?

Personally I don't that compile speed is as interesting as new bugs the 
compiler is able to highlight, either through the compilation process or 
through the use of LLVM as a static analyzer.

But LLVM/clang is quite far away from building Fedora, so I do not think 
there's a need for people to get anxious.

I worked for a couple weeks on fixing LLVM, clang and Linux kernel bugs 
so that the kernel would build under clang.

	Jeff









From ajax at redhat.com  Mon Oct 26 15:15:51 2009
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 26 Oct 2009 11:15:51 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5B75D.1050200@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B75D.1050200@fedoraproject.org>
Message-ID: <1256570151.15835.9601.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-10-26 at 20:21 +0530, Rahul Sundaram wrote:
> On 10/26/2009 08:21 PM, Adam Jackson wrote:
> > Which affects who?  koji certainly seems to be keeping up with the load.
> > 
> > What I'm trying to pry out of you is what you'd be hoping to accomplish
> > by using it.  The answer so far seems to be "I'd spend less time
> > building things, at the cost of some unknown amount of time invested in
> > fixing everything to build again".  That doesn't sound like progress.
> 
> Certainly status quo is easier.  Less time building things is a obvious
> benefit. We don't know the cost unless we try. Doing a scratch build
> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
> that we should never try at all doesn't seem appealing to me.

Please don't put words in my mouth, I did not say "never try at all".  I
said that spending less time building things is only an obvious benefit
if we don't lose real functionality, and don't waste time placating the
compiler to get things to build.

But hey, if you're volunteering to run the experiment, go wild.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jwboyer at gmail.com  Mon Oct 26 15:15:30 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 26 Oct 2009 11:15:30 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5B75D.1050200@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B75D.1050200@fedoraproject.org>
Message-ID: <20091026151530.GH3807@hansolo.jdub.homelinux.org>

On Mon, Oct 26, 2009 at 08:21:09PM +0530, Rahul Sundaram wrote:
>On 10/26/2009 08:21 PM, Adam Jackson wrote:
>
>> 
>> Which affects who?  koji certainly seems to be keeping up with the load.
>> 
>> What I'm trying to pry out of you is what you'd be hoping to accomplish
>> by using it.  The answer so far seems to be "I'd spend less time
>> building things, at the cost of some unknown amount of time invested in
>> fixing everything to build again".  That doesn't sound like progress.
>
>Certainly status quo is easier.  Less time building things is a obvious
>benefit. We don't know the cost unless we try. Doing a scratch build
>similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
>that we should never try at all doesn't seem appealing to me.

Sounds like something you should start trying then.

josh



From sundaram at fedoraproject.org  Mon Oct 26 15:22:44 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 20:52:44 +0530
Subject: Looking into LLVM
In-Reply-To: <1256570151.15835.9601.camel@atropine.boston.devel.redhat.com>
References: <4AE47047.9000401@fedoraproject.org>	
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>	
	<4AE5A60F.9090802@fedoraproject.org>	
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>	
	<4AE5B574.2030503@fedoraproject.org>	
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>	
	<4AE5B75D.1050200@fedoraproject.org>
	<1256570151.15835.9601.camel@atropine.boston.devel.redhat.com>
Message-ID: <4AE5BEC4.9060707@fedoraproject.org>

On 10/26/2009 08:45 PM, Adam Jackson wrote:

> 
> Please don't put words in my mouth, I did not say "never try at all".  I
> said that spending less time building things is only an obvious benefit
> if we don't lose real functionality, and don't waste time placating the
> compiler to get things to build.

Yes, I understand that. Note that benefit is not just speed.  From a
earlier discussion,

http://www.linux-archive.org/fedora-development/362915-clang-static-analyzer-use.html

> But hey, if you're volunteering to run the experiment, go wild.

I am not volunteering. I just wanted to know if anyone else has already
tried it.  If you read my original post, that's what I asked.

Rahul



From riel at redhat.com  Mon Oct 26 15:36:02 2009
From: riel at redhat.com (Rik van Riel)
Date: Mon, 26 Oct 2009 11:36:02 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5BB31.1060908@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>		<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>		<4AE5A60F.9090802@fedoraproject.org>		<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>		<4AE5B574.2030503@fedoraproject.org>	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>	<4AE5B75D.1050200@fedoraproject.org>
	<4AE5BB8E.4010203@redhat.com> <4AE5BB31.1060908@fedoraproject.org>
Message-ID: <4AE5C1E2.50302@redhat.com>

On 10/26/2009 11:07 AM, Rahul Sundaram wrote:
> On 10/26/2009 08:39 PM, Peter Jones wrote:
>
>> This is just myopia, though.  In isolation, yes, faster builds are nice.  But
>> if the faster builds result in poorer quality, then no, they're not a benefit.
>
> Sure. Nobody claimed otherwise.
>
>>> We don't know the cost unless we try. Doing a scratch build
>>> similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing
>>> that we should never try at all doesn't seem appealing to me.
>>
>> Go ahead and set that up.  Report the result back to us.
>
> I was asking if anybody has already tried that. Don't understand the
> argument against it yet.

If you had tried a project like this in the past, you would
understand the reasons against it.

If you do not understand those reasons from email, the only
cure would be to try it yourself.  Then you will understand.

-- 
All rights reversed.



From pjones at redhat.com  Mon Oct 26 15:37:53 2009
From: pjones at redhat.com (Peter Jones)
Date: Mon, 26 Oct 2009 11:37:53 -0400
Subject: Looking into LLVM
In-Reply-To: <4AE5BEC4.9060707@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>		<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>		<4AE5A60F.9090802@fedoraproject.org>		<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>		<4AE5B574.2030503@fedoraproject.org>		<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>		<4AE5B75D.1050200@fedoraproject.org>	<1256570151.15835.9601.camel@atropine.boston.devel.redhat.com>
	<4AE5BEC4.9060707@fedoraproject.org>
Message-ID: <4AE5C251.7010309@redhat.com>

On 10/26/2009 11:22 AM, Rahul Sundaram wrote:
> On 10/26/2009 08:45 PM, Adam Jackson wrote:
> 
>>
>> Please don't put words in my mouth, I did not say "never try at all".  I
>> said that spending less time building things is only an obvious benefit
>> if we don't lose real functionality, and don't waste time placating the
>> compiler to get things to build.
> 
> Yes, I understand that. Note that benefit is not just speed.  From a
> earlier discussion,
> 
> http://www.linux-archive.org/fedora-development/362915-clang-static-analyzer-use.html
> 
>> But hey, if you're volunteering to run the experiment, go wild.
> 
> I am not volunteering. I just wanted to know if anyone else has already
> tried it.  If you read my original post, that's what I asked.

Well, why not?

-- 
        Peter

Gravity is a habit that is hard to shake off.
		-- Pratchett



From sundaram at fedoraproject.org  Mon Oct 26 15:37:44 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Oct 2009 21:07:44 +0530
Subject: Looking into LLVM
In-Reply-To: <4AE5C251.7010309@redhat.com>
References: <4AE47047.9000401@fedoraproject.org>		<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>		<4AE5A60F.9090802@fedoraproject.org>		<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>		<4AE5B574.2030503@fedoraproject.org>		<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>		<4AE5B75D.1050200@fedoraproject.org>	<1256570151.15835.9601.camel@atropine.boston.devel.redhat.com>
	<4AE5BEC4.9060707@fedoraproject.org> <4AE5C251.7010309@redhat.com>
Message-ID: <4AE5C248.5000106@fedoraproject.org>

On 10/26/2009 09:07 PM, Peter Jones wrote:

> Well, why not?

I am not curious enough to volunteer to do anything with it myself but
would be interested in hearing about the experiences of anyone who has
already done so. If you haven't, feel free to ignore my mail. Pretty
simple, really.

Rahul



From jakub at redhat.com  Mon Oct 26 15:52:48 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Oct 2009 16:52:48 +0100
Subject: Looking into LLVM
In-Reply-To: <4AE5B836.9040607@redhat.com>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B836.9040607@redhat.com>
Message-ID: <20091026155248.GD14664@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Oct 26, 2009 at 10:54:46AM -0400, Peter Jones wrote:
> Well, that plus your already voiced complaint about its dwarf generation,
> which is to say that any fairly immediate adoption would also make normal
> development and debugging more painful.

It is not just about horrible dwarf generation, the performance of LLVM
generated code is worse than GCC, you can forget about all the
security enhancements GCC has added in the last 10 years (say
__builtin_object_size is parsed by clang/llvm, but always says it doesn't
know the size, I'm not aware of LLVM supporting something like
-fstack-protector), etc.  A lot of stuff is just stubbed in LLVM, look at
e.g. its __builtin_expect implementation.  You need to look through the hype
at what disadvantages it has.

While there are places where compile time speed is most important (in some
JITing cases), the distro isn't one of those places.

	Jakub



From fche at redhat.com  Mon Oct 26 16:06:37 2009
From: fche at redhat.com (Frank Ch. Eigler)
Date: Mon, 26 Oct 2009 12:06:37 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: <4AE5B378.1000507@RedHat.com> (Steve Dickson's message of "Mon,
	26 Oct 2009 10:34:32 -0400")
References: <4AE5B378.1000507@RedHat.com>
Message-ID: 

Steve Dickson  writes:

> [With the next nfs-utils rawhide build, I will be flipping the ]
> [switch that will cause all NFS client mounts to try NFS v4 first ]
> [...]

Is this really "first" or rather "only"?  Was there a conclusion about
whether the nfs client code would be changed to fall back from v4 to
v3 automatically?

- FChE



From ikem.krueger at googlemail.com  Mon Oct 26 16:23:32 2009
From: ikem.krueger at googlemail.com (Ikem Krueger)
Date: Mon, 26 Oct 2009 16:23:32 +0000
Subject: Unreadable binaries
In-Reply-To: <20091022171321.GA18852@amd.home.annexia.org>
References: <20091022100436.GA16025@amd.home.annexia.org>
	<1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>
	<1256219940.2191.47.camel@moss-pluto.epoch.ncsc.mil>
	<20091022171321.GA18852@amd.home.annexia.org>
Message-ID: 

> I just saw this article about an effort to create Universal binary style ELF
> binaries for Linux, and I thought that this would be something to watch, so
> that Fedora could integrate both x86-32 and x86-64 into single DVD sets.
I don't suggest to do that. As already mentioned, that would double
the size of the distro/iso. I would use this technic only, if
neccessary.

About "fat-elf" in general: As long as it is optional, I am fine with
it. May it at compile time or after compiling by stripping binaries.
(I'd like to see both options.)



From ikem.krueger at googlemail.com  Mon Oct 26 16:26:43 2009
From: ikem.krueger at googlemail.com (Ikem Krueger)
Date: Mon, 26 Oct 2009 16:26:43 +0000
Subject: Unreadable binaries
In-Reply-To: 
References: <20091022100436.GA16025@amd.home.annexia.org>
	<1256219323.15835.8874.camel@atropine.boston.devel.redhat.com>
	<1256219940.2191.47.camel@moss-pluto.epoch.ncsc.mil>
	<20091022171321.GA18852@amd.home.annexia.org>
	
Message-ID: 

Sorry. Wrong mail. ^^'



From ikem.krueger at googlemail.com  Mon Oct 26 16:28:05 2009
From: ikem.krueger at googlemail.com (Ikem Krueger)
Date: Mon, 26 Oct 2009 16:28:05 +0000
Subject: Fedora with Universal Binaries?
In-Reply-To: 
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	
Message-ID: 

> I just saw this article about an effort to create Universal binary style ELF
> binaries for Linux, and I thought that this would be something to watch, so
> that Fedora could integrate both x86-32 and x86-64 into single DVD sets.
I don't suggest to do that. As already mentioned, that would double
the size of the distro/iso. I would use this technic only, if
neccessary.

About "fat-elf" in general: As long as it is optional, I am fine with
it. May it at compile time or after compiling by stripping binaries.
(I'd like to see both options.)



From kevin.kofler at chello.at  Mon Oct 26 16:31:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Oct 2009 17:31:44 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
	
	<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
Message-ID: 

Jud Craft wrote:
> I'm not sure I understand.  How can LLVM-C be ABI-incompatible with plain
> GCC-C?

It's the ABI of:
llvm-g++ ? LLVM ? LLVM C backend ? gcc
or:
Clang (C++) ? LLVM ? LLVM C backend ? gcc
which is incompatible with the ABI of plain g++.

AFAICT, the native LLVM backends don't have that problem. The real problem 
with C++ is that Clang's C++ support is experimental and incomplete, so 
you're stuck with llvm-g++.

> I thought that C doesn't have any crazy name or symbol or virtual
> table mangling.  The stuff should just work, right?

But this is about C++.

        Kevin Kofler



From tgl at redhat.com  Mon Oct 26 16:39:07 2009
From: tgl at redhat.com (Tom Lane)
Date: Mon, 26 Oct 2009 12:39:07 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen 
In-Reply-To: <4AE5B378.1000507@RedHat.com> 
References: <4AE5B378.1000507@RedHat.com>
Message-ID: <7059.1256575147@sss.pgh.pa.us>

Steve Dickson  writes:
> Because the mount command will try NFS v4 first, mounts to older Linux servers
> will start failing like:

What happens with a mount to a UDP-only server?  (or actually /net
automount is what I care about...)

			regards, tom lane



From kevin.kofler at chello.at  Mon Oct 26 16:40:04 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Oct 2009 17:40:04 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B836.9040607@redhat.com>
	<20091026155248.GD14664@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: 

Jakub Jelinek wrote:
> It is not just about horrible dwarf generation, the performance of LLVM
> generated code is worse than GCC, you can forget about all the
> security enhancements GCC has added in the last 10 years (say
> __builtin_object_size is parsed by clang/llvm, but always says it doesn't
> know the size, I'm not aware of LLVM supporting something like
> -fstack-protector), etc.  A lot of stuff is just stubbed in LLVM, look at
> e.g. its __builtin_expect implementation.  You need to look through the
> hype at what disadvantages it has.

And I don't think that's going to change as long as LLVM stays BSD-licensed. 
Most people are unwilling to contribute to a project of which proprietary 
software companies can make "improved" proprietary versions of, which even 
they as the original author aren't allowed to use without paying the 
company, let alone modify or redistribute. Contributing to the GPLed GCC is 
much more attractive. So LLVM is always going to lag behind in some areas.

Just look at how many contributions the Linux kernel gets vs. how many the 
BSD kernels get.

        Kevin Kofler



From fedora at camperquake.de  Mon Oct 26 16:52:56 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Oct 2009 17:52:56 +0100
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <7059.1256575147@sss.pgh.pa.us>
References: <4AE5B378.1000507@RedHat.com>
	<7059.1256575147@sss.pgh.pa.us>
Message-ID: <20091026175256.4506fb41@dhcp03.addix.net>

Hi.

On Mon, 26 Oct 2009 12:39:07 -0400, Tom Lane wrote:

> Steve Dickson  writes:
> > Because the mount command will try NFS v4 first, mounts to older
> > Linux servers will start failing like:
> 
> What happens with a mount to a UDP-only server?  (or actually /net
> automount is what I care about...)

automount does not care one way or another, I think. At least it mounts
my solaris server just fine in 3/udp and 4/tcp.



From SteveD at redhat.com  Mon Oct 26 17:13:14 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 13:13:14 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: 
References: <4AE5B378.1000507@RedHat.com> 
Message-ID: <4AE5D8AA.2050503@RedHat.com>

On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
> Steve Dickson  writes:
> 
>> [With the next nfs-utils rawhide build, I will be flipping the ]
>> [switch that will cause all NFS client mounts to try NFS v4 first ]
>> [...]
> 
> Is this really "first" or rather "only"?  Was there a conclusion about
> whether the nfs client code would be changed to fall back from v4 to
> v3 automatically?
It meant "first"... If the server does not support V4, the mount will
automatically roll back to v3/tcp,v3/udp,v2/tcp,v2/udp... 

The problem comes in when the server does support v4 but the exports are 
not configured correctly (like pre F-12 Linux servers). In that case the 
mount will fail with ENOENT which will look like:

mount.nfs: mounting laptop:/home failed, reason given by server:
  No such file or directory

The there are a couple fixes to this problem:
   1) Upgrade to an F-12 server
On a pre F-12 Server:
   2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and 
      reset the exports with 'exportfs -arv' (see exports(5) for details).
   3) Set the 'RPCNFSDARGS="-N 4"' shell variable in the /etc/sysconfig/nfs
      file and restart the server via 'service nfs restart'
On a Rawhide Client:
   4) Set the Defaultvers=3 in the /etc/nfsmount.conf file
   5) Explicitly set the version (meaning don't do any server negotiation)
      by either using the '-o v4' mount option on the command line or 
      set  Nfsvers=3 in the /etc/nfsmount.conf file.

The first fixes two are preferred...

steved.



From SteveD at redhat.com  Mon Oct 26 17:18:29 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 13:18:29 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <7059.1256575147@sss.pgh.pa.us>
References: <4AE5B378.1000507@RedHat.com> <7059.1256575147@sss.pgh.pa.us>
Message-ID: <4AE5D9E5.5010002@RedHat.com>

On 10/26/2009 12:39 PM, Tom Lane wrote:
> Steve Dickson  writes:
>> Because the mount command will try NFS v4 first, mounts to older Linux servers
>> will start failing like:
> 
> What happens with a mount to a UDP-only server?  (or actually /net
> automount is what I care about...)
Well since TCP is needed for NFS v4 support, I can assume the server
does not support V4. In this case the mount/automount will 
automatically roll back to v3/udp or v2/udp as it does today... 

steved.



From fche at redhat.com  Mon Oct 26 17:34:23 2009
From: fche at redhat.com (Frank Ch. Eigler)
Date: Mon, 26 Oct 2009 13:34:23 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: <4AE5D8AA.2050503@RedHat.com> (Steve Dickson's message of "Mon,
	26 Oct 2009 13:13:14 -0400")
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com>
Message-ID: 

Steve Dickson  writes:

> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>> Is this really "first" or rather "only"?  Was there a conclusion about
>> whether the nfs client code would be changed to fall back from v4 to
>> v3 automatically?
> It meant "first"... [...]
> The problem comes in when the server does support v4 but the exports are 
> not configured correctly (like pre F-12 Linux servers). [...]
> mount.nfs: mounting laptop:/home failed, reason given by server:
>   No such file or directory

Unfortunately, this sounds like "only".  Is it out of the question to
make the client look for this case (an upgraded client in an existing
unupgraded, unchanged network) and handle it?

- FChE



From roland at redhat.com  Mon Oct 26 17:40:26 2009
From: roland at redhat.com (Roland McGrath)
Date: Mon, 26 Oct 2009 10:40:26 -0700 (PDT)
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: Frank Ch. Eigler's message of  Monday,
	26 October 2009 13:34:23 -0400 
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
Message-ID: <20091026174027.06B257B3E@magilla.sf.frob.com>

At the least, there ought to be an F-11 update of whatever server-side
stuff needs to change (in the minimal way not touching non-v4 uses) to
make v4 exports work without temporary configuration hacks.  IMHO if you
can't do anything better, you should make F-11 default to not registering
as a v4 server at all.


Thanks,
Roland



From joost at cnoc.nl  Mon Oct 26 17:58:16 2009
From: joost at cnoc.nl (Joost van der Sluis)
Date: Mon, 26 Oct 2009 18:58:16 +0100
Subject: Including windows-binary files for cross compiling into package
Message-ID: <1256579896.23821.186.camel@wsjoost.cnoc.lan>

Hi all, 

fpc is a pascal-compiler which is able to cross-compile to other
architectures. Nothing really special, but it is also able to
cross-compile to windows, without any dependencies.

I've created a sub-package of the fpc package to make cross-compiling to
windows possible. This package only consist of the run-time-library
compiled for windows. But this means that if I commit this package, I
add windows binary files (in /usr/lib64/fpc/units/x86_64-win64/)

What are the opinions on this? Rpmlint and strip don't like these files
as they are not elf files, but there's no real danger in this?

It would be nice if this sub-package could be added to Fedora, making it
possible to compile with fpc for windows directly.

The srpm and the -win64 package can be found here:
http://menora.cnoc.nl/extern/fpc/fpc-win64-2.2.4-5.fc11.x86_64.rpm
http://menora.cnoc.nl/extern/fpc/fpc-2.2.4-5.fc11.src.rpm

Joost van der Sluis.



From SteveD at redhat.com  Mon Oct 26 18:06:45 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 14:06:45 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: 
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
	
Message-ID: <4AE5E535.2040107@RedHat.com>

On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
> Steve Dickson  writes:
> 
>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>>> Is this really "first" or rather "only"?  Was there a conclusion about
>>> whether the nfs client code would be changed to fall back from v4 to
>>> v3 automatically?
>> It meant "first"... [...]
>> The problem comes in when the server does support v4 but the exports are 
>> not configured correctly (like pre F-12 Linux servers). [...]
>> mount.nfs: mounting laptop:/home failed, reason given by server:
>>   No such file or directory
> 
> Unfortunately, this sounds like "only".  Is it out of the question to
> make the client look for this case (an upgraded client in an existing
> unupgraded, unchanged network) and handle it?
We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html

But in the end, I decided not to do this since its not clear how the change
would interact with other NFS servers...

steved.



From SteveD at redhat.com  Mon Oct 26 18:08:59 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 14:08:59 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091026174027.06B257B3E@magilla.sf.frob.com>
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
	
	<20091026174027.06B257B3E@magilla.sf.frob.com>
Message-ID: <4AE5E5BB.90109@RedHat.com>

On 10/26/2009 01:40 PM, Roland McGrath wrote:
> At the least, there ought to be an F-11 update of whatever server-side
> stuff needs to change (in the minimal way not touching non-v4 uses) to
> make v4 exports work without temporary configuration hacks.  IMHO if you
> can't do anything better, you should make F-11 default to not registering
> as a v4 server at all.
That is one of the valid options, but I would think it would better if
the server owner did that tweak, than an nfs-utils update, no?

steved.



From roland at redhat.com  Mon Oct 26 18:11:37 2009
From: roland at redhat.com (Roland McGrath)
Date: Mon, 26 Oct 2009 11:11:37 -0700 (PDT)
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: Steve Dickson's message of  Monday,
	26 October 2009 14:08:59 -0400 <4AE5E5BB.90109@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
	<20091026174027.06B257B3E@magilla.sf.frob.com>
	<4AE5E5BB.90109@RedHat.com>
Message-ID: <20091026181137.B0A857B3E@magilla.sf.frob.com>

> That is one of the valid options, but I would think it would better if
> the server owner did that tweak, than an nfs-utils update, no?

I'm not suggesting that you do an update that just tweaks config files in
%post or anything like that.  I'm suggesting you make the out-of-the-box
behavior with configs people use today do something useful.  Claiming to
support v4 is not useful if it doesn't really work.



From roland at redhat.com  Mon Oct 26 18:15:02 2009
From: roland at redhat.com (Roland McGrath)
Date: Mon, 26 Oct 2009 11:15:02 -0700 (PDT)
Subject: Including windows-binary files for cross compiling into package
In-Reply-To: Joost van der Sluis's message of  Monday,
	26 October 2009 18:58:16 +0100
	<1256579896.23821.186.camel@wsjoost.cnoc.lan>
References: <1256579896.23821.186.camel@wsjoost.cnoc.lan>
Message-ID: <20091026181502.919B02747@magilla.sf.frob.com>

If it's true cross support, then that should be a noarch package and the
file names it uses should not depend on %{_lib} that way.  
Arguably it even belongs in %{_sharedir}, since it is fixed binary content
across all host machines.



From joost at cnoc.nl  Mon Oct 26 18:42:56 2009
From: joost at cnoc.nl (Joost van der Sluis)
Date: Mon, 26 Oct 2009 19:42:56 +0100
Subject: Including windows-binary files for cross compiling into package
In-Reply-To: <20091026181502.919B02747@magilla.sf.frob.com>
References: <1256579896.23821.186.camel@wsjoost.cnoc.lan>
	<20091026181502.919B02747@magilla.sf.frob.com>
Message-ID: <1256582576.23821.193.camel@wsjoost.cnoc.lan>

On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
> If it's true cross support, then that should be a noarch package and the
> file names it uses should not depend on %{_lib} that way.  
> Arguably it even belongs in %{_sharedir}, since it is fixed binary content
> across all host machines.

Those files are not architecture independent. They are somewhat similar
to .o files. They contain the run time library for the language,
compiled to native windows object files. If you want to compile your own
program with them afterwards, they are linked together into a windows
executable.

You could argue that they should belong in a -devel package. But since
this package is a compiler, we decided not to split it up into a devel
package and a non-devel package. As that would be pointless, as one will
not work without the other.

Joost



From SteveD at redhat.com  Mon Oct 26 18:49:46 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 26 Oct 2009 14:49:46 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091026181137.B0A857B3E@magilla.sf.frob.com>
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
		<20091026174027.06B257B3E@magilla.sf.frob.com>	<4AE5E5BB.90109@RedHat.com>
	<20091026181137.B0A857B3E@magilla.sf.frob.com>
Message-ID: <4AE5EF4A.9050606@RedHat.com>



On 10/26/2009 02:11 PM, Roland McGrath wrote:
>> That is one of the valid options, but I would think it would better if
>> the server owner did that tweak, than an nfs-utils update, no?
> 
> I'm not suggesting that you do an update that just tweaks config files in
> %post or anything like that.  I'm suggesting you make the out-of-the-box
> behavior with configs people use today do something useful.  Claiming to
> support v4 is not useful if it doesn't really work.
Right... I'm assuming the later... which is exactly how the set the default 
version to v3 in F-12. I install a /etc/nfsmount.conf with Defaultvers=3 set.

But with with older releases I don't messing with people configuration 
files since I would not want to break an existing configuration... 
Note, there is a number of people who are currently running with 
correctly configured v4 server... I would hate to mess those people up.. 

steved.
 



From jkeating at redhat.com  Mon Oct 26 18:49:29 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Oct 2009 11:49:29 -0700
Subject: Fedora Release Engineering meeting summary for 2009-10-26
Message-ID: <1256582969.3463.4.camel@localhost.localdomain>

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-26/fedora-releng.2009-10-26-18.04.html

Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-26/fedora-releng.2009-10-26-18.04.txt

Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-10-26/fedora-releng.2009-10-26-18.04.log.html


Meeting summary
---------------
* roll call  (Oxf13, 18:04:43)

* Fedora 12  (Oxf13, 18:06:19)

* Fedora 12 Updates  (Oxf13, 18:09:33)
  * IDEA: Enable submission of and pushing of Fedora 12 updates when
    Fedora 12 enters RC phase  (Oxf13, 18:17:04)
  * ACTION: f13 to provide jwb (and notting?) with F12 key access
    (Oxf13, 18:20:34)
  * AGREED: We'll enable updates submission and pushing at RC phase
    (Oxf13, 18:22:50)

* FUDCon Toronto  (Oxf13, 18:29:44)

* Hardware  (Oxf13, 18:35:01)

* open floor  (Oxf13, 18:37:28)

Meeting ended at 18:48:02 UTC.




Action Items
------------
* f13 to provide jwb (and notting?) with F12 key access

People Present (lines said)
---------------------------
* Oxf13 (72)
* jwb (29)
* skvidal (11)
* rdieter (10)
* dgilmore (8)
* notting (7)
* wwoods (5)
* spot (3)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From ngompa13 at gmail.com  Mon Oct 26 19:02:59 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Mon, 26 Oct 2009 14:02:59 -0500
Subject: Fedora with Universal Binaries?
In-Reply-To: 
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	
	
Message-ID: <8278b1b0910261202u554f2192k1ccf779b25d5616a@mail.gmail.com>

Well, possibly the only thing fatELF would be needed for would be to rid
ourselves of multilib. Applications don't even need to be FatELF to link to
FatELF libraries.

On Mon, Oct 26, 2009 at 11:28 AM, Ikem Krueger
wrote:

> > I just saw this article about an effort to create Universal binary style
> ELF
> > binaries for Linux, and I thought that this would be something to watch,
> so
> > that Fedora could integrate both x86-32 and x86-64 into single DVD sets.
> I don't suggest to do that. As already mentioned, that would double
> the size of the distro/iso. I would use this technic only, if
> neccessary.
>
> About "fat-elf" in general: As long as it is optional, I am fine with
> it. May it at compile time or after compiling by stripping binaries.
> (I'd like to see both options.)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pjones at redhat.com  Mon Oct 26 19:30:09 2009
From: pjones at redhat.com (Peter Jones)
Date: Mon, 26 Oct 2009 15:30:09 -0400
Subject: Fedora with Universal Binaries?
In-Reply-To: 
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>	<20091022144851.07b07f7f@redhat.com>	
	
Message-ID: <4AE5F8C1.8080907@redhat.com>

On 10/22/2009 10:22 PM, Kevin Kofler wrote:
> Sam Varshavchik wrote:
>> 32 bits will be here for a long, long time, of course
> 
> At most 29 years. 32-bit GNU/Linux doesn't support dates beyond 2038.

This only actually means we've got 29 years to extend time_t .

-- 
        Peter

All parts should go together without forcing. You must remember that
the parts you are  reassembling were disassembled by you.  Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer.
		-- IBM maintenance manual, 1925



From mike at cchtml.com  Mon Oct 26 19:35:26 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 26 Oct 2009 14:35:26 -0500
Subject: Including windows-binary files for cross compiling into package
In-Reply-To: <1256582576.23821.193.camel@wsjoost.cnoc.lan>
References: <1256579896.23821.186.camel@wsjoost.cnoc.lan>	<20091026181502.919B02747@magilla.sf.frob.com>
	<1256582576.23821.193.camel@wsjoost.cnoc.lan>
Message-ID: <4AE5F9FE.9090506@cchtml.com>

Joost van der Sluis on 10/26/2009 01:42 PM wrote:
> 
> Those files are not architecture independent. They are somewhat similar
> to .o files. They contain the run time library for the language,
> compiled to native windows object files. If you want to compile your own
> program with them afterwards, they are linked together into a windows
> executable.
> 
> You could argue that they should belong in a -devel package. But since
> this package is a compiler, we decided not to split it up into a devel
> package and a non-devel package. As that would be pointless, as one will
> not work without the other.
> 


They should follow mingw's footsteps, shouldn't they?

/usr/i686-pc-mingw32/sys-root/mingw/lib
equals
/usr/x86_64-pc-fpc/sys-root/fpc/lib

??



From ewan at macmahon.me.uk  Mon Oct 26 19:53:20 2009
From: ewan at macmahon.me.uk (Ewan Mac Mahon)
Date: Mon, 26 Oct 2009 19:53:20 +0000
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: <4AE5E535.2040107@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
	<4AE5E535.2040107@RedHat.com>
Message-ID: <20091026195320.GD3591@macmahon.me.uk>

On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote:
> On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
> > Steve Dickson  writes:
> > 
> >> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
> >
> > Unfortunately, this sounds like "only".  Is it out of the question to
> > make the client look for this case (an upgraded client in an existing
> > unupgraded, unchanged network) and handle it?
> We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
> 
> But in the end, I decided not to do this since its not clear how the change
> would interact with other NFS servers...
>
It's not clear to me how falling back to NFSv3 if v4 fails (and the
version wasn't explicitly set to v4) could ever cause a problem - it
might not help, but under what circumstances could it possibly be
harmful? I had a look at the linked thread from linux-nfs and no-one
there seemed to come up with anything concrete.

Ewan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From fche at redhat.com  Mon Oct 26 20:06:40 2009
From: fche at redhat.com (Frank Ch. Eigler)
Date: Mon, 26 Oct 2009 16:06:40 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: <4AE5E535.2040107@RedHat.com> (Steve Dickson's message of "Mon,
	26 Oct 2009 14:06:45 -0400")
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
	<4AE5E535.2040107@RedHat.com>
Message-ID: 

Steve Dickson  writes:

> [...]
>> Unfortunately, this sounds like "only".  Is it out of the question to
>> make the client look for this case (an upgraded client in an existing
>> unupgraded, unchanged network) and handle it?
> We talked about it... See [...]
>
> But in the end, I decided not to do this since its not clear how the change
> would interact with other NFS servers...

It's a bit odd that we're about to push a backward-incompatible
change into Fedora, just in case non-Fedora servers are around.


- FChE



From kevin.kofler at chello.at  Mon Oct 26 22:27:18 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Oct 2009 23:27:18 +0100
Subject: Fedora with Universal Binaries?
References: <8278b1b0910221028l66f83786pf870039a557b18e9@mail.gmail.com>
	
	
	<8278b1b0910261202u554f2192k1ccf779b25d5616a@mail.gmail.com>
Message-ID: 

King InuYasha wrote:
> Well, possibly the only thing fatELF would be needed for would be to rid
> ourselves of multilib. Applications don't even need to be FatELF to link
> to FatELF libraries.

Multilib is the better solution there, as it allows you to only install the 
multilibs you actually need. To rid yourself of multilibs, just don't 
install them!

        Kevin Kofler



From craftjml at gmail.com  Mon Oct 26 22:30:46 2009
From: craftjml at gmail.com (Jud Craft)
Date: Mon, 26 Oct 2009 18:30:46 -0400
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org>  
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com> 
	
	<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com> 
	
Message-ID: <20d6441a0910261530r2814b7a8s82c51e99717675ad@mail.gmail.com>

On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
>
> AFAICT, the native LLVM backends don't have that problem. The real problem
> with C++ is that Clang's C++ support is experimental and incomplete, so
> you're stuck with llvm-g++.
>
>> I thought that C doesn't have any crazy name or symbol or virtual
>> table mangling. ?The stuff should just work, right?
>
> But this is about C++.

I don't mean to misunderstand, but if I recall from your very first
post in this thread...

> Actually, the ABI issue is only if you use the C code generator, not the
> native ones.

Hence I thought you were talking about ABI issues with C.

I'm not up on how LLVM frontend integration works, so I actually don't
understand the distinction between "the LLVM C Backend" and "the
native LLVM backends".

Simply, can I write and compile a GTK program with LLVM?

I'd love to use it for the intuitive error reporting, honestly.



From kevin.kofler at chello.at  Mon Oct 26 22:29:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Oct 2009 23:29:07 +0100
Subject: Including windows-binary files for cross compiling into package
References: <1256579896.23821.186.camel@wsjoost.cnoc.lan>
	<20091026181502.919B02747@magilla.sf.frob.com>
	<1256582576.23821.193.camel@wsjoost.cnoc.lan>
Message-ID: 

Joost van der Sluis wrote:
> Those files are not architecture independent.

They are independent of the host architecture, they only depend on the 
target architecture.

        Kevin Kofler



From awilliam at redhat.com  Tue Oct 27 01:52:05 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Mon, 26 Oct 2009 18:52:05 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: <1256283570.2169.1.camel@localhost>
References: 
	
	<1256160451.2314.421.camel@adam.local.net>
	<200910220917.12776.mhlavink@redhat.com>
	<1256239859.2314.472.camel@adam.local.net>
	<1256283570.2169.1.camel@localhost>
Message-ID: <1256608325.2314.568.camel@adam.local.net>

On Fri, 2009-10-23 at 09:39 +0200, Jerome Glisse wrote:

> > > I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic 
> > > card, I was going to file new bug. With kms enabled, everything is really 
> > > sloooow, with 'nomodeset' it's much faster. I can't say exactly "how" slow it 
> > > is, is there anything I can use for measuring?
> > 
> > cairo-perf-trace is, afaik, the best we have:
> > http://cworth.org/intel/performance_measurement/
> > 
> > I'm not sure if bug reports on this are useful. To some extent, slow
> > performance with KMS on some chips is a known issue. Jerome, do you want
> > bug reports from people who have this problem, or would more reports not
> > provide any new information?

> I think we already have bug open for slowness with KMS, r600/r700 is
> missing few pieces. We will work on performance latter, likely not in
> time for F12. We are mostly focusing on fixing bugs which makes GPU
> unusable first.

Thanks, Jerome. So, Michal H, there's no need to file a bug for this.
Thanks for reporting it, though.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Tue Oct 27 01:53:22 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Mon, 26 Oct 2009 18:53:22 -0700
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256286509.2726.3.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
	<1256253559.9182.139.camel@localhost.localdomain>
	<4AE15C0B.80901@redhat.com>
	<1256286509.2726.3.camel@localhost.localdomain>
Message-ID: <1256608402.2314.569.camel@adam.local.net>

On Fri, 2009-10-23 at 09:28 +0100, Steven Whitehouse wrote:
> way to deal with this issue, the simplest solution would be to have a
> word with someone in HC and ask them to add to their standard list of

Note for non-RH'ers: HC = Human Capital, what most places call Human
Resources.

(personally I'm not sure which one sounds more like Soylent Green,
they're both pretty bad :>)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From skvidal at fedoraproject.org  Tue Oct 27 02:00:19 2009
From: skvidal at fedoraproject.org (Seth Vidal)
Date: Mon, 26 Oct 2009 22:00:19 -0400 (EDT)
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: <1256608402.2314.569.camel@adam.local.net>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
	<1256253559.9182.139.camel@localhost.localdomain>
	<4AE15C0B.80901@redhat.com>
	<1256286509.2726.3.camel@localhost.localdomain>
	<1256608402.2314.569.camel@adam.local.net>
Message-ID: 



On Mon, 26 Oct 2009, Adam Williamson wrote:

> On Fri, 2009-10-23 at 09:28 +0100, Steven Whitehouse wrote:
>> way to deal with this issue, the simplest solution would be to have a
>> word with someone in HC and ask them to add to their standard list of
>
> Note for non-RH'ers: HC = Human Capital, what most places call Human
> Resources.
>
> (personally I'm not sure which one sounds more like Soylent Green,
> they're both pretty bad :>)

I'm pretty sure they are called People and Brand. Not Human Capital 
anymore.

-sv



From awilliam at redhat.com  Tue Oct 27 02:14:41 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Mon, 26 Oct 2009 19:14:41 -0700
Subject: Looking into LLVM
In-Reply-To: <4AE5C1E2.50302@redhat.com>
References: <4AE47047.9000401@fedoraproject.org>
	<1256564027.15835.9563.camel@atropine.boston.devel.redhat.com>
	<4AE5A60F.9090802@fedoraproject.org>
	<1256568337.15835.9583.camel@atropine.boston.devel.redhat.com>
	<4AE5B574.2030503@fedoraproject.org>
	<1256568695.15835.9587.camel@atropine.boston.devel.redhat.com>
	<4AE5B75D.1050200@fedoraproject.org> <4AE5BB8E.4010203@redhat.com>
	<4AE5BB31.1060908@fedoraproject.org>  <4AE5C1E2.50302@redhat.com>
Message-ID: <1256609681.2314.573.camel@adam.local.net>

On Mon, 2009-10-26 at 11:36 -0400, Rik van Riel wrote:

> > I was asking if anybody has already tried that. Don't understand the
> > argument against it yet.
> 
> If you had tried a project like this in the past, you would
> understand the reasons against it.
> 
> If you do not understand those reasons from email, the only
> cure would be to try it yourself.  Then you will understand.

As Rahul already said, multiple times, he was not asking people to give
him their valuable opinion on whether it was a good idea or not. He was
just asking if anyone else had already tried it.

Personally I find it a bit presumptuous of all the people who jumped in
to tell him what a terrible idea it would be, as if he were proposing
that we do it in the official repos and make everyone use it or
something. He just asked a simple question, there was no need to spray
stop energy all over the place.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From maxamillion at gmail.com  Tue Oct 27 04:13:30 2009
From: maxamillion at gmail.com (Adam Miller)
Date: Mon, 26 Oct 2009 23:13:30 -0500
Subject: Test please disregard
Message-ID: 

Setup my fp.org email recently and now testing sending to the list  from my
myTouch.

-Adam (From Android)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From erikina at gmail.com  Tue Oct 27 04:26:05 2009
From: erikina at gmail.com (Eric Springer)
Date: Tue, 27 Oct 2009 14:26:05 +1000
Subject: Looking into LLVM
In-Reply-To: <4AE47047.9000401@fedoraproject.org>
References: <4AE47047.9000401@fedoraproject.org>
Message-ID: 

On Mon, Oct 26, 2009 at 1:35 AM, Rahul Sundaram
 wrote:
> Has anyone been looking into building Fedora with it to see how the
> performance impact is?

I built about 5 or 6 of the C programs from
http://shootout.alioth.debian.org/  with clang and gcc, and
unfortunately (or perhaps fortunately) all the gcc programs ran
faster. Perhaps in a source distro you'd have different priorityies
but for Fedora I think the compile-time / run-time trade off is
clearly worth it.

As for C++, I couldn't get some of my programs to compile as it seemed
to spew at some of the template usage. Anyway it looks very promising
and I look forward to using it in the future (especially with its
non-nonsense licensing).


Also I'm sure the freebsd folks would have a tonne of insight to offer
( http://wiki.freebsd.org/BuildingFreeBSDWithClang )



From karlthered at gmail.com  Tue Oct 27 07:05:23 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Tue, 27 Oct 2009 08:05:23 +0100
Subject: Looking into LLVM
In-Reply-To: <20d6441a0910261530r2814b7a8s82c51e99717675ad@mail.gmail.com>
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
		<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
	
	<20d6441a0910261530r2814b7a8s82c51e99717675ad@mail.gmail.com>
Message-ID: <4AE69BB3.6090008@gmail.com>

Le 26/10/2009 23:30, Jud Craft a ?crit :
> 
> Hence I thought you were talking about ABI issues with C.
> 
> I'm not up on how LLVM frontend integration works, so I actually don't
> understand the distinction between "the LLVM C Backend" and "the
> native LLVM backends".
> 
> Simply, can I write and compile a GTK program with LLVM?
> 
> I'd love to use it for the intuitive error reporting, honestly.
> 

the static analyzer works also with gcc, check scan-build.

H.



From mhlavink at redhat.com  Tue Oct 27 08:24:49 2009
From: mhlavink at redhat.com (Michal Hlavinka)
Date: Tue, 27 Oct 2009 09:24:49 +0100
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: <1256608325.2314.568.camel@adam.local.net>
References: 
	<1256283570.2169.1.camel@localhost>
	<1256608325.2314.568.camel@adam.local.net>
Message-ID: <200910270924.49544.mhlavink@redhat.com>

On Tuesday 27 October 2009 02:52:05 you wrote:
> On Fri, 2009-10-23 at 09:39 +0200, Jerome Glisse wrote:
> > > > I've installed F-12 beta on my new laptop with ati radeon hd 4570
> > > > graphic card, I was going to file new bug. With kms enabled,
> > > > everything is really sloooow, with 'nomodeset' it's much faster. I
> > > > can't say exactly "how" slow it is, is there anything I can use for
> > > > measuring?
> > >
> > > cairo-perf-trace is, afaik, the best we have:
> > > http://cworth.org/intel/performance_measurement/
> > >
> > > I'm not sure if bug reports on this are useful. To some extent, slow
> > > performance with KMS on some chips is a known issue. Jerome, do you
> > > want bug reports from people who have this problem, or would more
> > > reports not provide any new information?
> >
> > I think we already have bug open for slowness with KMS, r600/r700 is
> > missing few pieces. We will work on performance latter, likely not in
> > time for F12. We are mostly focusing on fixing bugs which makes GPU
> > unusable first.
> 
> Thanks, Jerome. So, Michal H, there's no need to file a bug for this.
> Thanks for reporting it, though.

I'm using these packages now and it's much better (speed is much better, 
rendering is (still) not at 100 % ) :
kernel, libdrm, mesa from koji
xorg-x11-drv-ati with sources updated to radeon's git snapshot


feel free to ask if you need some testing, logs, ...

Michal



From choeger at cs.tu-berlin.de  Tue Oct 27 09:30:08 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 27 Oct 2009 10:30:08 +0100
Subject: ld ignoring parts of LD_LIBRARY_PATH?
Message-ID: <1256635808.2837.3.camel@choeger6>

Hi,

this is slightly off topic, but may be relevant for fedora developing,
too:

I have set up a small test bed for an application I am converting to a
autotools build system. In this testbed I have:

./lib/libfoo.so
./lib/bar/libbar.so

When I add the lib/ entry to LD_LIBRARY_PATH it is recognized and
scanned for libraries. The same for the lib/bar entry. But when I add
both, the lib/ entry is ignored completely. Is this normal?

regards

Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From swhiteho at redhat.com  Tue Oct 27 10:03:02 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Tue, 27 Oct 2009 10:03:02 +0000
Subject: Simplify non-responsive maintainers policy Part 2
In-Reply-To: 
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<20091022091608.GA4663@genius.kawo2.rwth-aachen.de>
	<1256229826.9182.3.camel@localhost.localdomain>
	<20091022213417.GC4199@angus.ind.WPI.EDU>
	
	<20091022214729.GA4286@redhat.com>
	
	<1256253559.9182.139.camel@localhost.localdomain>
	<4AE15C0B.80901@redhat.com>
	<1256286509.2726.3.camel@localhost.localdomain>
	<1256608402.2314.569.camel@adam.local.net>
	
Message-ID: <1256637782.2669.28.camel@localhost.localdomain>

Hi,

On Mon, 2009-10-26 at 22:00 -0400, Seth Vidal wrote:
> 
> On Mon, 26 Oct 2009, Adam Williamson wrote:
> 
> > On Fri, 2009-10-23 at 09:28 +0100, Steven Whitehouse wrote:
> >> way to deal with this issue, the simplest solution would be to have a
> >> word with someone in HC and ask them to add to their standard list of
> >
> > Note for non-RH'ers: HC = Human Capital, what most places call Human
> > Resources.
> >
> > (personally I'm not sure which one sounds more like Soylent Green,
> > they're both pretty bad :>)
> 
> I'm pretty sure they are called People and Brand. Not Human Capital 
> anymore.
> 
> -sv
> 
Yes, thats true, but you know what I mean :-) Its the general principle
that I was trying to get across,

Steve.




From choeger at cs.tu-berlin.de  Tue Oct 27 10:39:37 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 27 Oct 2009 11:39:37 +0100
Subject: ld ignoring parts of LD_LIBRARY_PATH?
In-Reply-To: <1256635808.2837.3.camel@choeger6>
References: <1256635808.2837.3.camel@choeger6>
Message-ID: <1256639977.2837.8.camel@choeger6>

Am Dienstag, den 27.10.2009, 10:30 +0100 schrieb Christoph H?ger:
> Hi,
> 
> this is slightly off topic, but may be relevant for fedora developing,
> too:
> 
> I have set up a small test bed for an application I am converting to a
> autotools build system. In this testbed I have:
> 
> ./lib/libfoo.so
> ./lib/bar/libbar.so
> 
> When I add the lib/ entry to LD_LIBRARY_PATH it is recognized and
> scanned for libraries. The same for the lib/bar entry. But when I add
> both, the lib/ entry is ignored completely. Is this normal?
> 
> regards

Please forget this crap - I was confused by my headache this morning and
did not see that the error occured during _compile time_

sry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From aph at redhat.com  Tue Oct 27 11:03:38 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 27 Oct 2009 11:03:38 +0000
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091026195320.GD3591@macmahon.me.uk>
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
		<4AE5E535.2040107@RedHat.com>
	<20091026195320.GD3591@macmahon.me.uk>
Message-ID: <4AE6D38A.2070305@redhat.com>

Ewan Mac Mahon wrote:
 > On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote:
 >> On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
 >>> Steve Dickson  writes:
 >>>
 >>>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
 >>> Unfortunately, this sounds like "only".  Is it out of the question to
 >>> make the client look for this case (an upgraded client in an existing
 >>> unupgraded, unchanged network) and handle it?
 >> We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
 >>
 >> But in the end, I decided not to do this since its not clear how the change
 >> would interact with other NFS servers...
 >>
 > It's not clear to me how falling back to NFSv3 if v4 fails (and the
 > version wasn't explicitly set to v4) could ever cause a problem - it
 > might not help, but under what circumstances could it possibly be
 > harmful? I had a look at the linked thread from linux-nfs and no-one
 > there seemed to come up with anything concrete.

The strongest objection I found was

 > Older versions of ONTAP (like 6.0 through 6.2?), for example, have the
 > same problem as the Linux NFSv4 server does currently, iirc.
 >
 > It's also worth noting that modern Solaris clients do not have this
 > ENOENT workaround.  So, if automounter maps are shared with Linux
 > clients _with_ the workaround, mounting a Linux NFSv4 server, there
 > may be some issues.
 >
 > In the long term, I think we are much better off living with a few
 > months of complaints about the new version negotiation behavior,
 > rather than having this mount.nfs workaround.  I'm not going to object
 > to it outright, though...
(chuck[dot]lever[at]oracle[dot]com)

"I'm not going to object outright" sounds to me like we can fall back
to V3.  I think this is the best plan for us: we should not break things
for users of Fedora clients with RHEL servers or Fedora clients with
Fedora servers.

Further,

 > On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote:
 > > On 10/22/2009 12:21 PM, Chuck Lever wrote:
 > >> This would be mitigated instantly by leaving the version negotiation
 > >> default set to v3/v2.  Then no workaround would be needed.
 > > Right... Or defining the negotiation in the configuration file
 > > would also cause the workaround not to be needed...
 >
 > That's what I meant: set defaultvers: 3 in the config file, and allow
 > early adopters to change it.  After a while, we can bump the default
 > setting.  I think this is roughly what Sun did during their transition.
(chuck[dot]lever[at]oracle[dot]com)

Leaving the default at Version 3 for the next year or two would mostly
solve the problem.

Andrew.



From mschwendt at gmail.com  Tue Oct 27 11:08:46 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 27 Oct 2009 12:08:46 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>
Message-ID: <20091027120846.322a5edf@faldor.intranet>

On Tue, 27 Oct 2009 10:51:14 +0000 (UTC), Fabio wrote:

> Author: fabbione
> 
> Update of /cvs/pkgs/rpms/fence-agents/F-11
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
> 
> Modified Files:
> 	fence-agents.spec 
> Log Message:
> Fix Requires: on libvirt/libvirt-client

> +%if 0%{?fedora} >= 12
> +Requires: libvirt-client
> +%else
> +Requires: libvirt
> +%endif
> +

What is this explicit dependency on a package name supposed to achieve?
There is the automatic arch-specific dependency on the libvirt SONAME
already, and it is tons better than a non-arch-specific and version-less
dependency on a package name.

https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires



From fdinitto at redhat.com  Tue Oct 27 11:17:30 2009
From: fdinitto at redhat.com (Fabio M. Di Nitto)
Date: Tue, 27 Oct 2009 12:17:30 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <20091027120846.322a5edf@faldor.intranet>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>
	<20091027120846.322a5edf@faldor.intranet>
Message-ID: <4AE6D6CA.3040201@redhat.com>

Michael Schwendt wrote:
> On Tue, 27 Oct 2009 10:51:14 +0000 (UTC), Fabio wrote:
> 
>> Author: fabbione
>>
>> Update of /cvs/pkgs/rpms/fence-agents/F-11
>> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
>>
>> Modified Files:
>> 	fence-agents.spec 
>> Log Message:
>> Fix Requires: on libvirt/libvirt-client
> 
>> +%if 0%{?fedora} >= 12
>> +Requires: libvirt-client
>> +%else
>> +Requires: libvirt
>> +%endif
>> +
> 
> What is this explicit dependency on a package name supposed to achieve?

> There is the automatic arch-specific dependency on the libvirt SONAME
> already, and it is tons better than a non-arch-specific and version-less
> dependency on a package name.

The dependency on the library is pulled in via fence_xvmd that might or
might be not build (depending on ./configure invocation).

virsh used to be part of libvirt in any release before F12. It?s now
moved to libvirt-client.

So while rpm resolver does the right thing for fence_xvmd and pulls in
the right soname Requires, it cannot detect the usage of virsh within
fence_virsh.

If there are better ways to handle it, I am absolutely happy to change
the spec file but I don?t think it is correct either to break
fence_virsh because somebody is not building fence_xvmd* (that is going
to be deprecated upstream btw in not too long future).

I also considered a specific file Requires: /usr/bin/virsh, but policy
suggests to avoid that for different reasons.

Fabio




From mschwendt at gmail.com  Tue Oct 27 11:25:55 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 27 Oct 2009 12:25:55 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <4AE6D6CA.3040201@redhat.com>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>
	<20091027120846.322a5edf@faldor.intranet>
	<4AE6D6CA.3040201@redhat.com>
Message-ID: <20091027122555.14c0c973@faldor.intranet>

On Tue, 27 Oct 2009 12:17:30 +0100, Fabio wrote:

> >> +%if 0%{?fedora} >= 12
> >> +Requires: libvirt-client
> >> +%else
> >> +Requires: libvirt
> >> +%endif
> >> +
> > 
> > What is this explicit dependency on a package name supposed to achieve?
> 
> > There is the automatic arch-specific dependency on the libvirt SONAME
> > already, and it is tons better than a non-arch-specific and version-less
> > dependency on a package name.
> 
> The dependency on the library is pulled in via fence_xvmd that might or
> might be not build (depending on ./configure invocation).
> 
> virsh used to be part of libvirt in any release before F12. It?s now
> moved to libvirt-client.
> 
> So while rpm resolver does the right thing for fence_xvmd and pulls in
> the right soname Requires, it cannot detect the usage of virsh within
> fence_virsh.

It's good practise to add a comment to the .spec file that explains
this explicit dependency.
 
> If there are better ways to handle it, I am absolutely happy to change
> the spec file but I don?t think it is correct either to break
> fence_virsh because somebody is not building fence_xvmd* (that is going
> to be deprecated upstream btw in not too long future).
 
> I also considered a specific file Requires: /usr/bin/virsh, but policy
> suggests to avoid that for different reasons.

Really? What policy is that? Programs in bin paths are covered by the
primary metadata. Such a dependency would be more accurate.



From fdinitto at redhat.com  Tue Oct 27 11:37:28 2009
From: fdinitto at redhat.com (Fabio M. Di Nitto)
Date: Tue, 27 Oct 2009 12:37:28 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <20091027122555.14c0c973@faldor.intranet>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>	<20091027120846.322a5edf@faldor.intranet>	<4AE6D6CA.3040201@redhat.com>
	<20091027122555.14c0c973@faldor.intranet>
Message-ID: <4AE6DB78.3000004@redhat.com>

Michael Schwendt wrote:
> On Tue, 27 Oct 2009 12:17:30 +0100, Fabio wrote:
> 
>>>> +%if 0%{?fedora} >= 12
>>>> +Requires: libvirt-client
>>>> +%else
>>>> +Requires: libvirt
>>>> +%endif
>>>> +
>>> What is this explicit dependency on a package name supposed to achieve?
>>> There is the automatic arch-specific dependency on the libvirt SONAME
>>> already, and it is tons better than a non-arch-specific and version-less
>>> dependency on a package name.
>> The dependency on the library is pulled in via fence_xvmd that might or
>> might be not build (depending on ./configure invocation).
>>
>> virsh used to be part of libvirt in any release before F12. It?s now
>> moved to libvirt-client.
>>
>> So while rpm resolver does the right thing for fence_xvmd and pulls in
>> the right soname Requires, it cannot detect the usage of virsh within
>> fence_virsh.
> 
> It's good practise to add a comment to the .spec file that explains
> this explicit dependency.

Ok, this is a no brainer. I?ll push the comment with the next series of
updates.

>  
>> If there are better ways to handle it, I am absolutely happy to change
>> the spec file but I don?t think it is correct either to break
>> fence_virsh because somebody is not building fence_xvmd* (that is going
>> to be deprecated upstream btw in not too long future).
>  
>> I also considered a specific file Requires: /usr/bin/virsh, but policy
>> suggests to avoid that for different reasons.
> 
> Really? What policy is that? Programs in bin paths are covered by the
> primary metadata. Such a dependency would be more accurate.

https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies

I understand that files in bin paths are already covered by primary
data, but the way it is formulated there, it sounds (to me) that there
is still extra processing involved from the different depsolver.

As I mentioned before, I am OK to change the spec file as long as
somebody else will not complain later that I should use the package (and
start playing ping-pong).

Fabio



From mschwendt at gmail.com  Tue Oct 27 11:50:35 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 27 Oct 2009 12:50:35 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <4AE6DB78.3000004@redhat.com>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>
	<20091027120846.322a5edf@faldor.intranet>
	<4AE6D6CA.3040201@redhat.com>
	<20091027122555.14c0c973@faldor.intranet>
	<4AE6DB78.3000004@redhat.com>
Message-ID: <20091027125035.0fc7ddcb@faldor.intranet>

On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote:

> >> I also considered a specific file Requires: /usr/bin/virsh, but policy
> >> suggests to avoid that for different reasons.
> > 
> > Really? What policy is that? Programs in bin paths are covered by the
> > primary metadata. Such a dependency would be more accurate.
> 
> https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies
> 
> I understand that files in bin paths are already covered by primary
> data, but the way it is formulated there, it sounds (to me) that there
> is still extra processing involved from the different depsolver.

You've misread that section. Most of it comments on file dependencies
_outside_ (!) /etc and bin paths. Those are the ones you ought to avoid,
as the depsolvers would need to download and parse additional metadata
archives.



From fdinitto at redhat.com  Tue Oct 27 11:54:25 2009
From: fdinitto at redhat.com (Fabio M. Di Nitto)
Date: Tue, 27 Oct 2009 12:54:25 +0100
Subject: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
In-Reply-To: <20091027125035.0fc7ddcb@faldor.intranet>
References: <20091027105114.AF55611C00E6@cvs1.fedora.phx.redhat.com>	<20091027120846.322a5edf@faldor.intranet>	<4AE6D6CA.3040201@redhat.com>	<20091027122555.14c0c973@faldor.intranet>	<4AE6DB78.3000004@redhat.com>
	<20091027125035.0fc7ddcb@faldor.intranet>
Message-ID: <4AE6DF71.1060201@redhat.com>

Michael Schwendt wrote:
> On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote:
> 
>>>> I also considered a specific file Requires: /usr/bin/virsh, but policy
>>>> suggests to avoid that for different reasons.
>>> Really? What policy is that? Programs in bin paths are covered by the
>>> primary metadata. Such a dependency would be more accurate.
>> https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies
>>
>> I understand that files in bin paths are already covered by primary
>> data, but the way it is formulated there, it sounds (to me) that there
>> is still extra processing involved from the different depsolver.
> 
> You've misread that section. Most of it comments on file dependencies
> _outside_ (!) /etc and bin paths. Those are the ones you ought to avoid,
> as the depsolvers would need to download and parse additional metadata
> archives.

Ok, thanks for the clarification.

Update spec files are on the way.

Fabio



From jnovy at redhat.com  Tue Oct 27 11:59:46 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 27 Oct 2009 12:59:46 +0100
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: 
References: 
Message-ID: <20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>

On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
> I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, 
> so that other packages, such as xdvipdfmx will work?  Or, should texlive 
> just obsolete xdvipdfmx and include it's own version?

I will try to fix it in the texmf.cnf kpathsea configuration file
directly in the new TL2009 update.

Jindrich

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From rawhide at fedoraproject.org  Tue Oct 27 12:11:10 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 27 Oct 2009 12:11:10 +0000
Subject: rawhide report: 20091027 changes
Message-ID: <20091027121110.GA20529@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 27 06:15:09 UTC 2009

Broken deps for i386
----------------------------------------------------------
	blacs-lam-1.1-33.fc12.i686 requires liblamf77mpi.so.0
	blacs-lam-1.1-33.fc12.i686 requires liblam.so.0
	orsa-lam-0.7.0-11.fc12.i686 requires lam
	scalapack-lam-1.7.5-7.fc12.i686 requires liblam.so.0
	scalapack-lam-1.7.5-7.fc12.i686 requires liblamf77mpi.so.0
	tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0
	tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0
	tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0
	tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0



Broken deps for x86_64
----------------------------------------------------------
	blacs-lam-1.1-33.fc12.i686 requires liblamf77mpi.so.0
	blacs-lam-1.1-33.fc12.i686 requires liblam.so.0
	blacs-lam-1.1-33.fc12.x86_64 requires liblam.so.0()(64bit)
	blacs-lam-1.1-33.fc12.x86_64 requires liblamf77mpi.so.0()(64bit)
	orsa-lam-0.7.0-11.fc12.x86_64 requires lam
	scalapack-lam-1.7.5-7.fc12.i686 requires liblam.so.0
	scalapack-lam-1.7.5-7.fc12.i686 requires liblamf77mpi.so.0
	scalapack-lam-1.7.5-7.fc12.x86_64 requires liblam.so.0()(64bit)
	scalapack-lam-1.7.5-7.fc12.x86_64 requires liblamf77mpi.so.0()(64bit)
	tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit)
	tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit)
	tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit)
	tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	blacs-lam-1.1-33.fc12.ppc requires liblamf77mpi.so.0
	blacs-lam-1.1-33.fc12.ppc requires liblam.so.0
	blacs-lam-1.1-33.fc12.ppc64 requires liblam.so.0()(64bit)
	blacs-lam-1.1-33.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)
	orsa-lam-0.7.0-11.fc12.ppc requires lam
	scalapack-lam-1.7.5-7.fc12.ppc requires liblam.so.0
	scalapack-lam-1.7.5-7.fc12.ppc requires liblamf77mpi.so.0
	scalapack-lam-1.7.5-7.fc12.ppc64 requires liblam.so.0()(64bit)
	scalapack-lam-1.7.5-7.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)
	tachyon-lam-0.98.7-1.fc12.ppc requires liblam.so.0
	tachyon-lam-0.98.7-1.fc12.ppc requires liblamf77mpi.so.0
	tachyon-lam-gl-0.98.7-1.fc12.ppc requires liblam.so.0
	tachyon-lam-gl-0.98.7-1.fc12.ppc requires liblamf77mpi.so.0



Broken deps for ppc64
----------------------------------------------------------
	blacs-lam-1.1-33.fc12.ppc64 requires liblam.so.0()(64bit)
	blacs-lam-1.1-33.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)
	orsa-lam-0.7.0-11.fc12.ppc64 requires lam
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
	scalapack-lam-1.7.5-7.fc12.ppc64 requires liblam.so.0()(64bit)
	scalapack-lam-1.7.5-7.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)
	tachyon-lam-0.98.7-1.fc12.ppc64 requires liblam.so.0()(64bit)
	tachyon-lam-0.98.7-1.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)
	tachyon-lam-gl-0.98.7-1.fc12.ppc64 requires liblam.so.0()(64bit)
	tachyon-lam-gl-0.98.7-1.fc12.ppc64 requires liblamf77mpi.so.0()(64bit)



New package kcm-gtk
        Configure the appearance of GTK apps in KDE
New package python-xkit
        A simple, transparent and easy to extend xorg parser
Removed package lam
Updated Packages:

389-dsgw-1.1.4-1.fc12
---------------------
* Wed Aug 12 2009 Rich Megginson  - 1.1.4-1
- bump version to 1.1.4
- fix remaining licensing problems
- fix adminutil.m4

* Fri Jul 24 2009 Fedora Release Engineering  - 1.1.3-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Tue Jul 21 2009 Rich Megginson  - 1.1.3-2
- use 389-adminutil instead of adminutil


artwiz-aleczapka-fonts-1.3-8.fc12
---------------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


asterisk-1.6.1.7-0.4.rc2.fc12
-----------------------------
* Sat Oct 24 2009 Jeffrey C. Ollie  - 1.6.1.7-0.3.rc2
- Compile against gmime 2.2 instead of gmime 2.4 because the patch to convert the API calls from 2.2 to 2.4 caused crashes.

* Sat Oct 24 2009 Jeffrey C. Ollie  - 1.6.1.7-0.4.rc2
- Add an AST_EXTRA_ARGS option to the init script
- have the init script to cd to /var/spool/asterisk to prevent annoying message

* Fri Oct 09 2009 Jeffrey C. Ollie  - 1.6.1.7-0.2.rc2
- Require latex2html used in static-http documents

* Thu Oct 08 2009 Jeffrey C. Ollie  - 1.6.1.7-0.1.rc2
- Update to 1.6.1.7-rc2
- Merge firmware subpackage back into main package
- No longer need to strip tarball since it no longer contains any non-free items
- Tighten up permissions/ownership of config files.
- Fix up some more paths
- Drop unneeded patch


audacious-plugin-fc-0.4-1.fc12
------------------------------
* Sat Oct 24 2009 Michael Schwendt  - 0.4-1
- Patch temporarily to backport to Audacious 2.1 API.

* Fri Oct 23 2009 Michael Schwendt  - 0.4-1
- Upgrade to 0.4 for Audacious 2.2 InputPlugin API changes.


baekmuk-bdf-fonts-2.2-8.fc12
----------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 2.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


brasero-2.28.2-2.fc12
---------------------
* Mon Oct 26 2009 Matthias Clasen  2.28.2-2
- Avoid a stray underline in a button label


checkgmail-1.13-7.20091022svn.fc12
----------------------------------
* Thu Oct 22 2009 Rahul Sundaram  - 1.13-6.20091022svn
- Pull svn snapshot to fix authentication issue
- Fix post release snapshot naming and remove redundant requires

* Thu Oct 22 2009 Rahul Sundaram  - 1.13-7.20091022svn
- Add a desktop file
- Add it to session autostart


compiz-0.8.2-18.fc12
--------------------
* Mon Oct 26 2009 Adel Gadllah  - 0.8.2-16
- Don't ship broken keybindings files RH #530603

* Mon Oct 26 2009 Adel Gadllah  - 0.8.2-17
- Fix was wrong - revert it

* Mon Oct 26 2009 Matthias Clasen  - 0.8.2-18
- Better fix for keybindings


comps-extras-17-1
-----------------
* Mon Oct 26 2009 Bill Nottingham  - 17-1
- add LXDE logo (#529792)
- add books, font-design icon symlinks


control-center-2.28.1-3.fc12
----------------------------
* Mon Oct 26 2009 Matthias Clasen  2.28.1-2
- Fix missing fingerprint icons

* Mon Oct 26 2009 Matthias Clasen  2.28.1-3
- Change 'Best shapes' to mean grayscale+slight


empathy-2.28.1.1-2.fc12
-----------------------
* Mon Oct 26 2009 Matthias Clasen  - 2.28.1-3
- Another upstream crash fix

* Mon Oct 26 2009 Brian Pepple  - 2.28.1.1-1
- Update to 2.28.1.1.
- See http://download.gnome.org/sources/empathy/2.28/empathy-2.28.1.1.news

* Mon Oct 26 2009 Brian Pepple  - 2.28.1.1-2
- Disable panel applets, since they are unmaintained and being dropped from Empathy.

* Sun Oct 25 2009 Matthias Clasen  - 2.28.1-2
- Include a number of crash fixes from the stable branch


environment-modules-3.2.7b-5.fc12
---------------------------------
* Mon Oct 26 2009 Orion Poplawski  - 3.2.7b-5
- Don't assume different shell init scripts exist (bug #530770)


fpc-2.2.4-4.fc12.2
------------------
* Fri Oct 16 2009 Joost van der Sluis  2.2.4-4.2
- Fixed compilation on ppc

* Thu Oct 08 2009 Joost van der Sluis  2.2.4-4.1
- Restored accidentally removed ppc64 compiler name

* Tue Oct 06 2009 Joost van der Sluis  2.2.4-4
- fixed procvar parameter passing on ppc/sysv (by value instead of by
  reference -- except for method procvars, for tmethod record compatibility)


gdesklets-0.36.1-6.fc12
-----------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.36.1-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gds2pov-0.20080229-3.fc12
-------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.20080229-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gedit-plugins-2.26.1-3.fc12
---------------------------
* Mon Aug 10 2009 Ville Skytt?  - 2.26.1-3
- Use bzipped upstream tarball.

* Fri Jul 24 2009 Fedora Release Engineering  - 2.26.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


geoclue-0.11.1.1-0.9.20091026git73b6729.fc12
--------------------------------------------
* Sat Oct 24 2009 Peter Robinson  0.11.1.1-0.9
- New git snapshit, enable NetworkManager support for WiFi location, gsmloc and new Skyhook plugin


giggle-0.4.91-3.fc12
--------------------
* Tue Aug 11 2009 Ville Skytt?  - 0.4.91-3
- Use bzipped upstream tarball.

* Fri Jul 24 2009 Fedora Release Engineering  - 0.4.91-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gl-117-1.3.2-9.fc12
-------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.3.2-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glabels-2.2.5-2.fc12
--------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 2.2.5-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glade2-2.12.2-7.fc12
--------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 2.12.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glglobe-0.2-8.fc12
------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glib2-2.22.2-2.fc12
-------------------
* Sun Oct 25 2009 Matthias Clasen  - 2.22.2-2
- Fix two problems with mime type detection in GIO


glitz-0.5.6-8.fc12
------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.5.6-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gliv-1.9.6-5.fc12
-----------------
* Fri Jul 24 2009 Fedora Release Engineering  - 1.9.6-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glob2-0.9.4.1-2.fc12
--------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.9.4.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


glom-1.12.2-1.fc12
------------------
* Sun Oct 25 2009 Denis Leroy  - 1.12.2-1
- Update to upstream 1.12.2
- Fixed gnome-python2-gda run-time Require (#530656)


gnome-applet-bubblemon-2.0.14-2.fc12
------------------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 2.0.14-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gnome-applet-grandr-0.4.1-2.fc12
--------------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.4.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


gnome-power-manager-2.28.1-2.fc12
---------------------------------
* Thu Oct 22 2009 Richard Hughes   - 2.28.1-2
- Backport two patches from git master to polish the UI for F12.


gnome-settings-daemon-2.28.1-3.fc12
-----------------------------------
* Mon Oct 26 2009 Peter Hutterer  2.28.1-2
- left-handed-touchpad.patch: change physical touchpad buttons to
  left-handed, not tapping though (#498249)

* Mon Oct 26 2009 Matthias Clasen  - 2.28.1-3
- Change default font rendering to use slight hinting


gnome-user-share-2.28.1-1.fc12
------------------------------
* Mon Oct 26 2009 Bastien Nocera  2.28.1-1
- Update to 2.28.1


html-xml-utils-5.5-2.fc12
-------------------------
* Sun Oct 25 2009 Milos Jakubicek  - 5.5-2
- Added html-xml-utils-5.5-hxpipe-man.patch, resolves BZ#527655


ibus-m17n-1.2.0.20090617-5.fc12
-------------------------------
* Fri Oct 23 2009 Peng Huang  - 1.2.0.20090617-5
- Update iok patch to fix bug 530493.


iok-1.3.8-1.fc12
----------------
* Mon Oct 26 2009 Parag Nemade - 1.3.8-1
- Update to Next release 1.3.8


jasper-1.900.1-13.fc12
----------------------
* Tue Oct 13 2009 Rex Dieter  - 1.900.1-13
- CVE-2008-3520 jasper: multiple integer overflows in jas_alloc calls (#461476)
- CVE-2008-3522 jasper: possible buffer overflow in 
  jas_stream_printf() (#461478)


kdeartwork-4.3.2-3.fc12
-----------------------
* Mon Oct 26 2009 Than Ngo  - 4.3.2-3
- rhel cleanup


kdenetwork-4.3.2-4.fc12
-----------------------
* Mon Oct 26 2009 Than Ngo  - 4.3.2-4
- rhel cleanup


kdeplasma-addons-4.3.2-5.fc12
-----------------------------
* Mon Oct 26 2009 Than Ngo  - 4.3.2-5
- remove duplicate BR on eigen2-devel


klibido-0.2.5-12.fc12
---------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.2.5-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


konq-plugins-4.3.1-3.fc12
-------------------------
* Mon Oct 26 2009 Than Ngo  - 4.3.1-3
- rhel cleanup


kpackagekit-0.5.0.2-1.fc12
--------------------------
* Sun Oct 25 2009 Steven M. Parrish  - 0.5.0.2-1
- Official 0.5.0.2 release


ktorrent-3.2.5-1.fc12
---------------------
* Sat Oct 24 2009 Rex Dieter  - 3.2.5-1
- ktorrent-3.2.5


ladspa-swh-plugins-0.4.15-16.fc12
---------------------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.4.15-16
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


libXxf86dga-1.1.1-1.fc12
------------------------
* Mon Oct 26 2009 Peter Hutterer  1.1.1-1
- libXxf86dga 1.1.1
  Requires xorg-x11-proto-devel for new xf86dgaproto.


libbtctl-0.11.1-3.fc12
----------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.11.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


libfakekey-0.1-3.fc12
---------------------
* Fri Jul 24 2009 Fedora Release Engineering  - 0.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


libgtk-java-2.8.7-13.fc12
-------------------------
* Fri Oct 23 2009 Milos Jakubicek  - 2.8.7-13
- Bump release to able to tag on different branch

* Fri Jul 24 2009 Fedora Release Engineering  - 2.8.7-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Mon Apr 27 2009 Stepan Kasal  - 2.8.7-11
- fix multilib problem with an example script (#342171)


libv4l-0.6.3-1.fc12
-------------------
* Sun Oct 25 2009 Hans de Goede  0.6.3-1
- New upstream release 0.6.3


lxde-common-0.4.2-2.fc12
------------------------
* Tue Oct 27 2009 Christoph Wickert  - 0.4.2-2
- Final tweaks for the LXDE Spin


mathgl-1.9-7.fc12
-----------------
* Sun Oct 25 2009 Milos Jakubicek  - 1.9-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


moblin-panel-people-0.0.8-1.fc12
--------------------------------
* Mon Oct 26 2009 Peter Robinson  0.0.8-1
- New upstream 0.0.8 release


mojito-0.21.5-1.fc12
--------------------
* Mon Oct 26 2009 Peter Robinson  0.21.5-1
- Update to 0.21.5


nbtk-1.1.9-1.fc12
-----------------
* Mon Oct 26 2009 Peter Robinson  1.1.9-1
- New upstream 1.1.9 release


openvpn-2.1-0.37.rc20.fc12
--------------------------
* Sun Oct 25 2009 Robert Scheck  2.1-0.37.rc20
- Added script_security initialisation in initscript (#458594 #c20)

* Fri Oct 02 2009 Steven Pritchard  2.1-0.36.rc20
- Update to 2.1_rc20.


perl-Apache2-SOAP-0.73-3.fc12
-----------------------------
* Sat Jul 25 2009 Fedora Release Engineering  - 0.73-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


perl-DBD-MySQL-4.013-2.fc12
---------------------------
* Mon Oct 26 2009 Stepan Kasal  - 4.013-2
- new upstream version


perl-POE-Component-Client-Keepalive-0.2600-3.fc12
-------------------------------------------------
* Wed Sep 30 2009 Stepan Kasal  0.2600-3
- keep the version aligned to 0.xxxx to maintain upgrade path

* Tue Sep 29 2009 Chris Weyl  0.260-2
- fix provides version (for perl-POE-Component-Client-HTTP)

* Sun Sep 27 2009 Chris Weyl  0.260-1
- update filtering
- auto-update to 0.260 (by cpan-spec-update 0.01)
- added a new br on perl(Net::IP) (version 1.25)
- altered br on perl(POE) (0.31 => 1.007)
- altered br on perl(POE::Component::Client::DNS) (1.01 => 1.04)
- added a new req on perl(Net::IP) (version 1.25)
- added a new req on perl(POE) (version 1.007)
- added a new req on perl(POE::Component::Client::DNS) (version 1.04)


perl-Perl-Critic-1.105-1.fc12
-----------------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.105-1
- new upstream version
- update build requires

* Sun Jul 26 2009 Fedora Release Engineering  - 1.098-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Sun May 17 2009 Chris Weyl  1.098-1
- "neaten" filtering
- auto-update to 1.098 (by cpan-spec-update 0.01)
- added a new br on perl(strict) (version 0)
- added a new br on perl(Scalar::Util) (version 0)
- added a new br on perl(File::Temp) (version 0)
- added a new br on perl(Pod::Usage) (version 0)
- added a new br on perl(File::Find) (version 0)
- added a new br on perl(PPI::Token::Whitespace) (version 1.203)
- added a new br on perl(charnames) (version 0)
- added a new br on perl(PPI::Document::File) (version 1.203)
- added a new br on perl(File::Spec::Unix) (version 0)
- added a new br on perl(List::Util) (version 0)
- added a new br on perl(lib) (version 0)
- added a new br on perl(Getopt::Long) (version 0)
- added a new br on perl(Exporter) (version 0)
- added a new br on perl(Test::More) (version 0)
- added a new br on perl(overload) (version 0)
- added a new br on perl(base) (version 0)
- added a new br on perl(version) (version 0)
- added a new br on perl(Carp) (version 0)
- added a new br on perl(warnings) (version 0)
- added a new br on perl(PPI::Document) (version 1.203)
- added a new br on perl(File::Basename) (version 0)
- added a new br on perl(PPI::Token::Quote::Single) (version 1.203)
- added a new br on perl(File::Spec) (version 0)
- added a new br on perl(File::Path) (version 0)
- added a new br on perl(Pod::PlainText) (version 0)
- added a new br on perl(Pod::Select) (version 0)
- added a new br on perl(PPI::Node) (version 1.203)
- added a new br on perl(English) (version 0)


petitboot-0.2-4.fc12
--------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 0.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


pfqueue-0.5.6-10.fc12
---------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 0.5.6-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


pfscalibration-1.4-7.fc12
-------------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 1.4-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


pfstools-1.7.0-8.fc12
---------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 1.7.0-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


poppler-0.12.1-3.fc12
---------------------
* Sun Oct 25 2009 Rex Dieter  - 0.12.1-3
- CVE-2009-3607 poppler: create_surface_from_thumbnail_data
  integer overflow (#526924)


python-igraph-0.5.2-4.fc12
--------------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 0.5.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Sat May 02 2009 Neal Becker  - 0.5.2-3
- Try removing Requires


python-polybori-0.5-6.fc12
--------------------------
* Sun Jul 26 2009 Fedora Release Engineering  - 0.5-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild


python-repoze-what-1.0.8-6.fc12
-------------------------------
* Mon Oct 26 2009 Luke Macken  - 1.0.8-5
- Require python-repoze-who-testutil

* Mon Oct 26 2009 Luke Macken  - 1.0.8-6
- Rev bump to hack around CVS tags


qemu-0.11.0-8.fc12
------------------
* Wed Oct 21 2009 Glauber Costa  - 2:0.11.0-8
- Properly save kvm time registers (#524229)


quassel-0.5.0-1.fc12
--------------------
* Fri Oct 23 2009 Steven M. Parrish  - 0.5.0-1
- Official 0.5.0 release


samba-3.4.2-47.fc12
-------------------
* Fri Oct 09 2009 Simo Sorce  - 3.4.2-47
- Spec file cleanup
- Fix sources upstream location
- Remove conditionals to build talloc and tdb, now they are completely indepent
  packages in Fedora
- Add defattr() where missing
- Turn all tabs into 4 spaces
- Remove unused migration script
- Split winbind-clients out of main winbind package to avoid multilib to include
  huge packages for no good reason

* Thu Oct 01 2009 Guenther Deschner  - 3.4.2-0.46
- Update to 3.4.2
- Security Release, fixes CVE-2009-2813, CVE-2009-2948 and CVE-2009-2906

* Wed Sep 16 2009 Tomas Mraz  - 3.4.1-0.45
- Use password-auth common PAM configuration instead of system-auth

* Wed Sep 09 2009 Guenther Deschner  - 3.4.1-0.44
- Update to 3.4.1


squidGuard-1.4-8.fc12
---------------------
* Mon Oct 26 2009 Jon Ciesla  - 1.4-8
- Applying upstream patches for CVE-2009-3700, BZ 530862.

* Thu Sep 24 2009 Jon Ciesla  - 1.4-7
- Make squidGuard.cgi config(noreplace)
- Relocated logs, updated logrotate file.
- Updated blacklist URL.


sssd-0.7.0-2.fc12
-----------------
* Mon Oct 26 2009 Stephen Gallagher  - 0.7.0-2
- Fix upgrade issues from old (pre-0.5.0) releases of SSSD


strace-4.5.19-1.fc12
--------------------
* Wed Oct 21 2009 Roland McGrath  - 4.5.19-1
- New upstream release, work mostly by Dmitry V. Levin 
  + exit/kill strace with traced process exitcode/signal (#105371);
  + fixed build on ARM EABI (#507576);
  + fixed display of 32-bit argv array on 64-bit architectures (#519480);
  + fixed display of 32-bit fcntl(F_SETLK) on 64-bit architectures (#471169);
  + fixed several bugs in strings decoder, including potential heap
    memory corruption (#470529, #478324, #511035).


totem-2.28.2-1.fc12
-------------------
* Mon Oct 26 2009 Bastien Nocera  2.28.2-1
- Update to 2.28.2

* Tue Oct 20 2009 Bastien Nocera  2.28.1-4
- Add missing dependency (#529845)


trac-iniadmin-plugin-0.1-7.20091026svn6877.fc12
-----------------------------------------------
* Mon Oct 26 2009 Jesse Keating  - 0.1-7.20091026svn3915
- Update for 0.11


transmission-1.76-1.fc12
------------------------
* Sun Oct 25 2009 Rahul Sundaram  - 1.76-1
- http://trac.transmissionbt.com/wiki/Changes#version-1.76


uxlaunch-0.30-1.fc12
--------------------
* Mon Oct 26 2009 Peter Robinson  0.30-1
- New upstream 0.30 release

* Wed Oct 14 2009 Peter Robinson  0.29-1
- New upstream 0.29 release


wxMaxima-0.8.3a-1.fc12
----------------------
* Sun Oct 25 2009 Rex Dieter  - 0.8.3a-1
- wxMaxima-0.8.3a (#530915)


xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12
------------------------------------------------------
* Fri Oct 09 2009 Dave Airlie  6.13.0-0.9.20091006git457646d73
- reload cursors on mode switch/rotate

* Fri Oct 09 2009 Dave Airlie  6.13.0-0.10.20091006git457646d73
- Don't use scratch pixmaps for rotate

* Wed Oct 07 2009 Dave Airlie  6.13.0-0.8.20091006git457646d73
- fix rotate (#527000)


xorg-x11-drv-intel-2.9.1-1.fc12
-------------------------------
* Mon Oct 26 2009 Adam Jackson  2.9.1-1
- intel 2.9.1

* Fri Oct 09 2009 Dave Airlie  2.9.0-3
- set gamma on mode set major for kms


xorg-x11-drv-neomagic-1.2.4-2.fc12
----------------------------------
* Mon Oct 26 2009 Adam Jackson  1.2.4-2
- neomagic-usleep.patch: Fix for new server ABI. (#523800)


xpad-4.0-5.fc12
---------------
* Sat Oct 24 2009 Christoph Wickert  - 4.0-5
- Remove autostart again. Doesn't work properly and is annoying on Live CDs
- Spec file clean-ups


Summary:
Added Packages: 2
Removed Packages: 1
Modified Packages: 82



From rakesh.pandit at gmail.com  Tue Oct 27 12:32:11 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 27 Oct 2009 18:02:11 +0530
Subject: Package Review Stats for last 7 days ending 25th Oct
Message-ID: 

Top two FAS account holders who have completed reviewing "Package
review" components on bugzilla for last 7 days ending 25th Oct were
Roman Rakus and Nicolas Mailhot.

Roman Rakus : 6

	https://bugzilla.redhat.com/show_bug.cgi?id=503496
	https://bugzilla.redhat.com/show_bug.cgi?id=469002
	https://bugzilla.redhat.com/show_bug.cgi?id=502818
	https://bugzilla.redhat.com/show_bug.cgi?id=502834
	https://bugzilla.redhat.com/show_bug.cgi?id=503482
	https://bugzilla.redhat.com/show_bug.cgi?id=503510


Nicolas Mailhot : 4

	https://bugzilla.redhat.com/show_bug.cgi?id=528675
	https://bugzilla.redhat.com/show_bug.cgi?id=530190
	https://bugzilla.redhat.com/show_bug.cgi?id=526204
	https://bugzilla.redhat.com/show_bug.cgi?id=529323


Mamoru Tasaka : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=529799
	https://bugzilla.redhat.com/show_bug.cgi?id=502614


Mattias Ellert : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=527336
	https://bugzilla.redhat.com/show_bug.cgi?id=527308


Nick Bebout : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=528003
	https://bugzilla.redhat.com/show_bug.cgi?id=512016


Parag AN(????) : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=522482
	https://bugzilla.redhat.com/show_bug.cgi?id=527319


Thomas Spura : 2

	https://bugzilla.redhat.com/show_bug.cgi?id=530205
	https://bugzilla.redhat.com/show_bug.cgi?id=525192


David A. Wheeler : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529404


David Lutterkort : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=514221


David Nalley : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529269


Emmanuel Seyman : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=524896


Jaroslav Reznik : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=530342


Jussi Lehtola : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529466


Kevin Kofler : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528096


Martin Gieseking : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529016


Mat Booth : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=515136


Miroslav Such?? : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=529810


Orion Poplawski : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=504405


Paulo Roma Cavalcanti : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=528892


Pierre-YvesChibon : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=491980


Sebastian Dziallas : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=527245


Simon Wesp : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=492810


Steve Traylen : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=516515


Yanko Kaneti : 1

	https://bugzilla.redhat.com/show_bug.cgi?id=530233



Total reviews modified: 37
Merge Reviews: 0
Review Requests: 37

This report by generated by bzReviewReport.py.
The source is available at:
https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py
Please submit patches or bug reports at: https://fedorahosted.org/triage/

-- 
Rakesh Pandit
https://fedoraproject.org/
freedom, friends, features, first



From maxamillion at fedoraproject.org  Tue Oct 27 13:54:54 2009
From: maxamillion at fedoraproject.org (Adam Miller)
Date: Tue, 27 Oct 2009 08:54:54 -0500
Subject: test2 please disregard
Message-ID: 

many apologies, just trying to sort out my list posting setup.

-Adam

-- 
http://maxamillion.googlepages.com
---------------------------------------------------------
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From jlaska at redhat.com  Tue Oct 27 14:00:48 2009
From: jlaska at redhat.com (James Laska)
Date: Tue, 27 Oct 2009 10:00:48 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <4AE5B378.1000507@RedHat.com>
References: <4AE5B378.1000507@RedHat.com>
Message-ID: <1256652048.2447.10.camel@localhost.localdomain>

On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote:
> [With the next nfs-utils rawhide build, I will be flipping the ]
> [switch that will cause all NFS client mounts to try NFS v4 first ]
> [At the bottom of this email has the workarounds if this change does ]
> [indeed cause pain ]
> 
> As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
> I am one commit away from changing the default protocol version NFS will 
> be using (or at least trying to use).
> 
> What does this means to you? Hopefully nothing! In theory this should 
> be a very seamless transition but with all new technology there
> will be (and are) some rough spots. 
> 
> Why are make the change? See the NFSv4Default wiki for details,
> but in a nutshell:
>     * Better performance - V4 is now a stateful protocol. Meaning the server keeps 
>       state on all the clients access a particular file or directory. This
>       allows the server to give out delegations (or leases) which in turn
>       allows the client to aggressive cache both data and meta data locally
> 
>     * Firewall Friendly- With v4 only one port is used 2049 for all traffic
>       including mounting and file locking.
> 
>     * Finally it enables us use upcoming minor releases of the the protocol. 
>       NFS version 4.1 and pNFS are two example of upcoming minor releases.
> 
> 
> FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I 
> personally have been using it for my home directory for a couple years now..
> For more of the nitty gritty details see  
>     http://www.iaps.com/NFSv4-new-features.html 
> 
> That's the good news... Here is the bad....
> 
> Because the mount command will try NFS v4 first, mounts to older Linux servers
> will start failing like:
> 
>  # mount linux-server:/export /mnt
>  mount.nfs: mounting linux-server:/export failed, reason given by server:
>     No such file or directory
> 
> This is due to a defect in the Linux server exporting code, which is fixed 
> in F-12, *but* there are a number of workarounds
> 
> On the server (Which is suggested):
>    * Add the following entry to the /etc/exports file:
>      / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
> 
> On the client, go back to v3 mounts by doing one of the following:
> 
>    * Add -o v3 to command line, similar to:
>         mount linux-server:/export /mnt
> 
>    * Change the default mount version in the new /etc/nfsmount.conf file by 
>      uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
>      See nfsmount.conf(5) man page for details. The diff would look like:
> 
>     --- /etc/nfsmount.conf.orig	2009-10-26 09:30:21.000000000 -0400
>     +++ /etc/nfsmount.conf	2009-10-26 10:31:30.227443686 -0400
>     @@ -31,7 +31,7 @@
>     # Protocol Version [2,3,4]
>     # This defines the default protocol version which will
>     # be used to start the negotiation with the server.
>    -# Defaultvers=4
>    +Defaultvers=3
>     #
>     # Setting this option makes it mandatory the server supports the
>     # given version. The mount will fail if the given version is 

Haven't gone through the full thread yet, but is it worth adding a
note/admonition to our NFS installation instructions that changing the
nfs server configuration may be necessary?

http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From rwheeler at redhat.com  Tue Oct 27 14:05:19 2009
From: rwheeler at redhat.com (Ric Wheeler)
Date: Tue, 27 Oct 2009 10:05:19 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <1256652048.2447.10.camel@localhost.localdomain>
References: <4AE5B378.1000507@RedHat.com>
	<1256652048.2447.10.camel@localhost.localdomain>
Message-ID: <4AE6FE1F.1080505@redhat.com>

On 10/27/2009 10:00 AM, James Laska wrote:
> On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote:
>> [With the next nfs-utils rawhide build, I will be flipping the ]
>> [switch that will cause all NFS client mounts to try NFS v4 first ]
>> [At the bottom of this email has the workarounds if this change does ]
>> [indeed cause pain ]
>>
>> As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
>> I am one commit away from changing the default protocol version NFS will
>> be using (or at least trying to use).
>>
>> What does this means to you? Hopefully nothing! In theory this should
>> be a very seamless transition but with all new technology there
>> will be (and are) some rough spots.
>>
>> Why are make the change? See the NFSv4Default wiki for details,
>> but in a nutshell:
>>      * Better performance - V4 is now a stateful protocol. Meaning the server keeps
>>        state on all the clients access a particular file or directory. This
>>        allows the server to give out delegations (or leases) which in turn
>>        allows the client to aggressive cache both data and meta data locally
>>
>>      * Firewall Friendly- With v4 only one port is used 2049 for all traffic
>>        including mounting and file locking.
>>
>>      * Finally it enables us use upcoming minor releases of the the protocol.
>>        NFS version 4.1 and pNFS are two example of upcoming minor releases.
>>
>>
>> FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
>> personally have been using it for my home directory for a couple years now..
>> For more of the nitty gritty details see
>>      http://www.iaps.com/NFSv4-new-features.html
>>
>> That's the good news... Here is the bad....
>>
>> Because the mount command will try NFS v4 first, mounts to older Linux servers
>> will start failing like:
>>
>>   # mount linux-server:/export /mnt
>>   mount.nfs: mounting linux-server:/export failed, reason given by server:
>>      No such file or directory
>>
>> This is due to a defect in the Linux server exporting code, which is fixed
>> in F-12, *but* there are a number of workarounds
>>
>> On the server (Which is suggested):
>>     * Add the following entry to the /etc/exports file:
>>       / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
>>
>> On the client, go back to v3 mounts by doing one of the following:
>>
>>     * Add -o v3 to command line, similar to:
>>          mount linux-server:/export /mnt
>>
>>     * Change the default mount version in the new /etc/nfsmount.conf file by
>>       uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
>>       See nfsmount.conf(5) man page for details. The diff would look like:
>>
>>      --- /etc/nfsmount.conf.orig	2009-10-26 09:30:21.000000000 -0400
>>      +++ /etc/nfsmount.conf	2009-10-26 10:31:30.227443686 -0400
>>      @@ -31,7 +31,7 @@
>>      # Protocol Version [2,3,4]
>>      # This defines the default protocol version which will
>>      # be used to start the negotiation with the server.
>>     -# Defaultvers=4
>>     +Defaultvers=3
>>      #
>>      # Setting this option makes it mandatory the server supports the
>>      # given version. The mount will fail if the given version is
>
> Haven't gone through the full thread yet, but is it worth adding a
> note/admonition to our NFS installation instructions that changing the
> nfs server configuration may be necessary?
>
> http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html
>
> Thanks,
> James
>


I think that adding a note to the documentation would be a very good thing...

ric



From bnocera at redhat.com  Tue Oct 27 15:15:22 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 27 Oct 2009 15:15:22 +0000
Subject: libmusicbrainz orphaned
Message-ID: <1256656522.2367.108.camel@localhost.localdomain>

Heya,

Seeing as libmusicbrainz will have a limited shelf life (the upstream
servers for that revision of the protocol will be switched off shortly),
and that no GNOME apps use it any more, I'm letting it go.

I'd expect Rex to pick it up, as KDE still uses it.

Cheers



From ndbecker2 at gmail.com  Tue Oct 27 15:59:30 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 27 Oct 2009 11:59:30 -0400
Subject: texlive 2009 - should set TEXMFCNF?
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: 

Jindrich Novy wrote:

> On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
>> I wonder if texlive should include a /etc/profile.d package to set
>> TEXMFCNF,
>> so that other packages, such as xdvipdfmx will work?  Or, should texlive
>> just obsolete xdvipdfmx and include it's own version?
> 
> I will try to fix it in the texmf.cnf kpathsea configuration file
> directly in the new TL2009 update.
> 
> Jindrich
> 
Could you explain?  Will you replace the current xdvipdfmx?  The current 
will use kpathsea and will look for config in /usr/share/texmf.  I was 
thinking either:

1) Replace the current xdvipdfmx with the one shipped with texlive

or

2) Use /etc/profile.d to set TEXMFCNF



From karlthered at gmail.com  Tue Oct 27 16:05:26 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Tue, 27 Oct 2009 17:05:26 +0100
Subject: libmusicbrainz orphaned
In-Reply-To: <1256656522.2367.108.camel@localhost.localdomain>
References: <1256656522.2367.108.camel@localhost.localdomain>
Message-ID: <4AE71A46.8020504@gmail.com>

Man, that's worrying.
libmusicbrainz is an indirect dependence of listen (through
libtunepimp), if no one steps, i'll sure have to.
At least, i'm willing to co-maintain it.

H.








From martind1111 at gmail.com  Tue Oct 27 16:24:10 2009
From: martind1111 at gmail.com (Martin Dubuc)
Date: Tue, 27 Oct 2009 12:24:10 -0400
Subject: Wi-Fi Question
Message-ID: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>

On most laptops, there is a way to disable Wi-Fi either through function
keys or kill switch. I am wondering if there is a way programmatically
speaking to figure out whether or not Wi-Fi is currently disabled because
the user has pressed the Wi-Fi function key or turned Wi-Fi off with the
kill switch.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dennis at ausil.us  Tue Oct 27 16:26:27 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 11:26:27 -0500
Subject: the mass rebuild and i586 rpms?
In-Reply-To: <4AE0F8FD.9040801@fi.muni.cz>
References: <5256d0b0910191220s4551daefx46907b1bdabf8926@mail.gmail.com>
	<1256232577.2497.43.camel@samson.armitage.org.uk>
	<4AE0F8FD.9040801@fi.muni.cz>
Message-ID: <200910271126.33247.dennis@ausil.us>

On Thursday 22 October 2009 07:29:49 pm Milos Jakubicek wrote:
> Hi,

> > Not a primary arch package (should the package be blocked in the primary
> > arch kojihub?)
> > ==========================
> > prtconf
> > silo
> > xorg-x11-drv-sunffb
> 
> There are much more of them! I don't know whether it is possible to
> block a package in a single Koji hub and if our infrastructure team is
> willing to go in this way -- Jesse?

blocking a package on the primary hub will result in the package also being 
blocked on the secodnary arch hubs.  since one of the things we want to do is 
keep the arches in sync.  it will also mean that a packges doesnt get branched 
in cvs since the branching tools will think its no longer needed.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From orion at cora.nwra.com  Tue Oct 27 16:58:43 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 27 Oct 2009 10:58:43 -0600
Subject: prelinked octave segfaults in F-12
Message-ID: <4AE726C3.9040103@cora.nwra.com>

I'd like to call attention to this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=526833

Apparently, prelinking octave on F-12 causes it to segfault on startup. 
  Can anyone else reproduce this?  Does anyone have an idea as to why 
this might happen?

-- 
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 jkeating at redhat.com  Tue Oct 27 17:06:02 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Oct 2009 10:06:02 -0700
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <1256652048.2447.10.camel@localhost.localdomain>
References: <4AE5B378.1000507@RedHat.com>
	<1256652048.2447.10.camel@localhost.localdomain>
Message-ID: <1256663162.3413.0.camel@localhost.localdomain>

On Tue, 2009-10-27 at 10:00 -0400, James Laska wrote:
> 
> Haven't gone through the full thread yet, but is it worth adding a
> note/admonition to our NFS installation instructions that changing the
> nfs server configuration may be necessary?
> 
> http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html 

I do believe this change is targeting F13 though, not F12, so please
don't change any F12 documentation (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jkeating at redhat.com  Tue Oct 27 17:10:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Oct 2009 10:10:55 -0700
Subject: Wi-Fi Question
In-Reply-To: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
Message-ID: <1256663455.3413.2.camel@localhost.localdomain>

On Tue, 2009-10-27 at 12:24 -0400, Martin Dubuc wrote:
> On most laptops, there is a way to disable Wi-Fi either through function
> keys or kill switch. I am wondering if there is a way programmatically
> speaking to figure out whether or not Wi-Fi is currently disabled because
> the user has pressed the Wi-Fi function key or turned Wi-Fi off with the
> kill switch. 

At least on my laptop I have:

/sys/class/rfkill/rfkill1/state when my kill switch is thrown.  This
seems to cover the wifi.  When I unkill, which enables bluetooth, I get
rfkill2 as well with a state of 1.  In my bios I have the switch set to
cover cellular and bluetooth, so no switch can kill the wifi.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From jamatos at fc.up.pt  Tue Oct 27 17:23:54 2009
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Tue, 27 Oct 2009 17:23:54 +0000
Subject: prelinked octave segfaults in F-12
In-Reply-To: <4AE726C3.9040103@cora.nwra.com>
References: <4AE726C3.9040103@cora.nwra.com>
Message-ID: <200910271723.55019.jamatos@fc.up.pt>

On Tuesday 27 October 2009 16:58:43 Orion Poplawski wrote:
> I'd like to call attention to this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=526833
> 
> Apparently, prelinking octave on F-12 causes it to segfault on startup.
>   Can anyone else reproduce this?

I am sorry for not reporting this before but I had the same problem and I 
found the same solution.

When octave segfaults on start the first step is to run
prelink  -u /usr/bin/octave

and then it works again.

>   Does anyone have an idea as to why this might happen?

Not me. :-(

-- 
Jos? Ab?lio



From dennis at ausil.us  Tue Oct 27 17:40:14 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 12:40:14 -0500
Subject: RFC: proposed macro deffinitions for F-13
Message-ID: <200910271240.18937.dennis@ausil.us>

Hi All,

Id like to get some feedback on the patches that i'm proposing for F-13.  
quite a few packages that need to deal with differences between 32bit/64bit  or 
multilib arches have defines for the appropriate arches.  sometimes incomplete 
since they don't include secondary arches.

I wanted to get some feedback. and see if there are other cases we should add.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redhat-rpm-config-9.0.3-multilibarches.patch
Type: text/x-patch
Size: 490 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm-4.7.1-archdefs.patch
Type: text/x-patch
Size: 1109 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From sandeen at redhat.com  Tue Oct 27 17:45:10 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 27 Oct 2009 12:45:10 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271240.18937.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
Message-ID: <4AE731A6.8010303@redhat.com>

Dennis Gilmore wrote:
> Hi All,
> 
> Id like to get some feedback on the patches that i'm proposing for F-13.  
> quite a few packages that need to deal with differences between 32bit/64bit  or 
> multilib arches have defines for the appropriate arches.  sometimes incomplete 
> since they don't include secondary arches.
> 
> I wanted to get some feedback. and see if there are other cases we should add.
> 
> Dennis
> 

I have hacks like this in e2fsprogs.spec for example:


%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
      %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif

Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?

-Eric



From dennis at ausil.us  Tue Oct 27 18:15:28 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 13:15:28 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <4AE731A6.8010303@redhat.com>
References: <200910271240.18937.dennis@ausil.us> <4AE731A6.8010303@redhat.com>
Message-ID: <200910271315.33891.dennis@ausil.us>

On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
> Dennis Gilmore wrote:
> > Hi All,
> >
> > Id like to get some feedback on the patches that i'm proposing for F-13.
> > quite a few packages that need to deal with differences between
> > 32bit/64bit  or multilib arches have defines for the appropriate arches. 
> > sometimes incomplete since they don't include secondary arches.
> >
> > I wanted to get some feedback. and see if there are other cases we should
> > add.
> >
> > Dennis
> 
> I have hacks like this in e2fsprogs.spec for example:
> 
> 
> %ifarch %{multilib_arches}
> mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
>       %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
> install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
> %endif
> 
> Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
> type of header mangling for multiarch?

right now you need to define multilib_arches for that to work with my proposed 
changes you could drop your defines  and use 
%ifarch %{multilib64} %{multilib32}

maybe we want to define a multilibarches macro also   that way if/when we add a 
new multilib arch. we make one changes and rebuild everything and we support 
it. rather than changing potentially hundresd of spec files.  of course they 
will need to be changed to use the new macros.


Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From ajax at redhat.com  Tue Oct 27 18:16:46 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 27 Oct 2009 14:16:46 -0400
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271240.18937.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
Message-ID: <1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>

On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:

> Id like to get some feedback on the patches that i'm proposing for F-13.  
> quite a few packages that need to deal with differences between 32bit/64bit  or 
> multilib arches have defines for the appropriate arches.  sometimes incomplete 
> since they don't include secondary arches.
> 
> I wanted to get some feedback. and see if there are other cases we should add.

+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x

Remind me what the asymmetry is for here?  Why is %{ix86} not in
%{multilib32} ?

In general I'd kind of prefer to see headers modified to use gcc's
predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
can get.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From tomek at pipebreaker.pl  Tue Oct 27 18:18:46 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Tue, 27 Oct 2009 19:18:46 +0100
Subject: Wi-Fi Question
In-Reply-To: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
Message-ID: <20091027181846.GA25682@mother.pipebreaker.pl>

On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote:
> On most laptops, there is a way to disable Wi-Fi either through function
> keys or kill switch. I am wondering if there is a way programmatically
> speaking to figure out whether or not Wi-Fi is currently disabled because
> the user has pressed the Wi-Fi function key or turned Wi-Fi off with the
> kill switch.

  You can install "rfkill" package and use same-named command:
% rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: yes
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no


-- 
Tomasz Torcz            There exists no separation between gods and men:
xmpp: zdzichubg at chrome.pl   one blends softly casual into the other.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 238 bytes
Desc: not available
URL: 

From dennis at ausil.us  Tue Oct 27 18:24:33 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 13:24:33 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
References: <200910271240.18937.dennis@ausil.us>
	<1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
Message-ID: <200910271324.34058.dennis@ausil.us>

On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
> On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > Id like to get some feedback on the patches that i'm proposing for F-13.
> > quite a few packages that need to deal with differences between
> > 32bit/64bit  or multilib arches have defines for the appropriate arches. 
> > sometimes incomplete since they don't include secondary arches.
> >
> > I wanted to get some feedback. and see if there are other cases we should
> > add.
> 
> +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> 
> Remind me what the asymmetry is for here?  Why is %{ix86} not in
> %{multilib32} ?
> 
> In general I'd kind of prefer to see headers modified to use gcc's
> predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
> can get.

it should be the attached patch.  the initial one was based on what gcc does 
in its spec.  it treats %{ix86} as  not being multilib. 

+%multilib32 %{ix86} %{sparc32} ppc s390
+%multilib64 x86_64 %{sparc64} ppc64 s390x

-------------- next part --------------
A non-text attachment was scrubbed...
Name: redhat-rpm-config-9.0.3-multilibarches.patch
Type: text/x-patch
Size: 490 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From roland at redhat.com  Tue Oct 27 18:33:26 2009
From: roland at redhat.com (Roland McGrath)
Date: Tue, 27 Oct 2009 11:33:26 -0700 (PDT)
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: Steve Dickson's message of  Monday,
	26 October 2009 14:49:46 -0400 <4AE5EF4A.9050606@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
	<20091026174027.06B257B3E@magilla.sf.frob.com>
	<4AE5E5BB.90109@RedHat.com>
	<20091026181137.B0A857B3E@magilla.sf.frob.com>
	<4AE5EF4A.9050606@RedHat.com>
Message-ID: <20091027183326.0A3857B79@magilla.sf.frob.com>

> But with with older releases I don't messing with people configuration 
> files since I would not want to break an existing configuration... 

Still never suggested that.

> Note, there is a number of people who are currently running with 
> correctly configured v4 server... I would hate to mess those people up.. 

Of course.  So push an F-11 update where whatever configuration never
mentions v4 and doesn't work for v4, doesn't advertise v4.



From deadbabylon at googlemail.com  Tue Oct 27 18:39:02 2009
From: deadbabylon at googlemail.com (Sebastian Vahl)
Date: Tue, 27 Oct 2009 19:39:02 +0100
Subject: KDE-SIG weekly report (44/2009)
Message-ID: <200910271939.13140.deadbabylon@googlemail.com>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 44/2009

Time: 2009-10-27 14:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-27

Meeting minutes: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-27/fedora-meeting.2009-10-27-14.06.html

Meeting log: http://meetbot.fedoraproject.org/fedora-
meeting/2009-10-27/fedora-meeting.2009-10-27-14.06.log.html

----------------------------------------------------------------------------------

= Participants =

*  BenBoeckel
* EikeHein
* JaroslavReznik
* KevinKofler
* LukasTinkl
* MaryEllenFoster
* RexDieter
* SebastianVahl
* StevenParrish
* ThanNgo
* ThomasJanssen
* "nucleo" 

----------------------------------------------------------------------------------

= Agenda =

*  topics to discuss:
o Final Fedora 12 artwork
o Status of eigen2
o qt-4.5.3: updates, F-12
o soprano status: sesame, virtuoso 

= Summary =

o Final Fedora 12 artwork:
* Current status of KSplash theme for Constantine [1] 
* This needs to be adapted for KDM theme. 

o Status of eigen2:
* eigen2 was downgraded to 2.0.6 in F-12 and all depending packages were 
rebuilt and tagged. 

o qt-4.5.3: updates, F-12:
* RexDieter asked about the handling of qt-4.5.3 in F-12 (updates-testing vs. 
F-12 final).
* 2 issues are known so far:
- Problems with qt-4.5.3 and the qt4 build of Opera.
- 3-star-echo-mode causes the auth dialogs to pause/freeze. (kde#211250)  [2]
* F-12 final is preferred but awaiting feedback from ThanNgo first. 

o soprano status: sesame, virtuoso:
* MaryEllenFoster gave a status update of her work on soprano-sesame2 backend:
- https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame [3]
- There a still a lot of JPackage packages which needs to be reviewed or 
updated. 
* Virtuoso will not be working properly until KDE 4.4. gets released or the 
relevant changes gets backported.
* virtuoso-opensource-5.0.12 packages are built as updates in F-12.
* soprano-2.3.65 with virtuoso support is built in devel branch (also 
available in kde-unstable repositories at kde-redhat). 

o Open discussion:
* gtk-qt-engine was replaced by kcm-gtk. 

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03

----------------------------------------------------------------------------------

= Links =

[1] http://rezza.hofyland.cz/fedora/artwork/f12/constantine-ksplash-
rain-80.png
[2] https://bugs.kde.org/show_bug.cgi?id=211250
[3] https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From jakub at redhat.com  Tue Oct 27 18:39:43 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 27 Oct 2009 19:39:43 +0100
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271324.34058.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
	<1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
	<200910271324.34058.dennis@ausil.us>
Message-ID: <20091027183943.GP14664@tyan-ft48-01.lab.bos.redhat.com>

On Tue, Oct 27, 2009 at 01:24:33PM -0500, Dennis Gilmore wrote:
> it should be the attached patch.  the initial one was based on what gcc does 
> in its spec.  it treats %{ix86} as  not being multilib. 

That's because %{ix86} gcc isn't multilib capable, unlike e.g. ppc/ppc64
or sparcv9/sparc64 where the support is symmetric (32-bit gcc can compile
64-bit code and vice versa), on x86_64 you need x86_64 gcc to be able to
compile 64-bit stuff.

	Jakub



From sandeen at redhat.com  Tue Oct 27 18:47:13 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 27 Oct 2009 13:47:13 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271315.33891.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us> <4AE731A6.8010303@redhat.com>
	<200910271315.33891.dennis@ausil.us>
Message-ID: <4AE74031.7060508@redhat.com>

Dennis Gilmore wrote:
> On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
>> Dennis Gilmore wrote:
>>> Hi All,
>>>
>>> Id like to get some feedback on the patches that i'm proposing for F-13.
>>> quite a few packages that need to deal with differences between
>>> 32bit/64bit  or multilib arches have defines for the appropriate arches. 
>>> sometimes incomplete since they don't include secondary arches.
>>>
>>> I wanted to get some feedback. and see if there are other cases we should
>>> add.
>>>
>>> Dennis
>> I have hacks like this in e2fsprogs.spec for example:
>>
>>
>> %ifarch %{multilib_arches}
>> mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
>>       %{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
>> install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
>> %endif
>>
>> Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
>> type of header mangling for multiarch?
> 
> right now you need to define multilib_arches for that to work with my proposed 
> changes you could drop your defines  and use 
> %ifarch %{multilib64} %{multilib32}

Right, I was hoping for maybe some macros to make my above mess simpler;

%{do_magic_header_stuff} header1.h header2.h ...

-Eric



From redhat at olen.net  Tue Oct 27 19:03:54 2009
From: redhat at olen.net (Ola Thoresen)
Date: Tue, 27 Oct 2009 20:03:54 +0100
Subject: Wi-Fi Question
In-Reply-To: <20091027181846.GA25682@mother.pipebreaker.pl>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
Message-ID: <4AE7441A.8030404@olen.net>

On 27. okt. 2009 19:18, Tomasz Torcz wrote:
>   You can install "rfkill" package and use same-named command:



Nice app. Thanks for the tip.
But does anyone have any idea about how to disable the hardware kill
switch, when linux insists it is enabled no matter what position the
switch is really set to:

- WLAN enabled (hardware switch set to "On"):

# rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes


- Switching to "off" shows this in the log:
 atkbd.c: Unknown key pressed (translated set 2, code 0xf1 on
isa0060/serio0).
 atkbd.c: Use 'setkeycodes e071 ' to make it known.
 atkbd.c: Unknown key released (translated set 2, code 0xf1 on
isa0060/serio0).
 atkbd.c: Use 'setkeycodes e071 ' to make it known.

# rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes


Still no luck...






From jwboyer at gmail.com  Tue Oct 27 19:17:57 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 27 Oct 2009 15:17:57 -0400
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271240.18937.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
Message-ID: <20091027191757.GA4356@hansolo.jdub.homelinux.org>

On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
>+# arch macro for all supported 32 bit builds
>+%32bitarches %{ix86} %{sparc32} %{arm} s390
>+# arch macro for all supported 64 bit builds
>+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha} 

missing ppc and ppc64 respectively here, aren't you?

josh



From dennis at ausil.us  Tue Oct 27 19:30:44 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 14:30:44 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <20091027191757.GA4356@hansolo.jdub.homelinux.org>
References: <200910271240.18937.dennis@ausil.us>
	<20091027191757.GA4356@hansolo.jdub.homelinux.org>
Message-ID: <200910271430.49086.dennis@ausil.us>

On Tuesday 27 October 2009 02:17:57 pm Josh Boyer wrote:
> On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
> >+# arch macro for all supported 32 bit builds
> >+%32bitarches %{ix86} %{sparc32} %{arm} s390
> >+# arch macro for all supported 64 bit builds
> >+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}
> 
> missing ppc and ppc64 respectively here, aren't you?
> 
> josh
indeed i am sorry  this should be better

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm-4.7.1-archdefs.patch
Type: text/x-patch
Size: 1118 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From pjones at redhat.com  Tue Oct 27 19:36:31 2009
From: pjones at redhat.com (Peter Jones)
Date: Tue, 27 Oct 2009 15:36:31 -0400
Subject: Wi-Fi Question
In-Reply-To: <4AE7441A.8030404@olen.net>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>	<20091027181846.GA25682@mother.pipebreaker.pl>
	<4AE7441A.8030404@olen.net>
Message-ID: <4AE74BBF.5040702@redhat.com>

On 10/27/2009 03:03 PM, Ola Thoresen wrote:
> On 27. okt. 2009 19:18, Tomasz Torcz wrote:
>>   You can install "rfkill" package and use same-named command:
> 
> Nice app. Thanks for the tip.
> But does anyone have any idea about how to disable the hardware kill
> switch, when linux insists it is enabled no matter what position the
> switch is really set to:

AIUI, this means there's a physical switch somewhere on the device.

-- 
        Peter



From martind1111 at gmail.com  Tue Oct 27 19:49:35 2009
From: martind1111 at gmail.com (Martin Dubuc)
Date: Tue, 27 Oct 2009 15:49:35 -0400
Subject: Wi-Fi Question
In-Reply-To: <20091027181846.GA25682@mother.pipebreaker.pl>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
Message-ID: <7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>

This is a very nice tool. Unfortunately, on my system running Fedora 11, I
get the following erro:
Can't open RFKILL control device: No such file or directory

Using strace, I discovered that rfkill is trying to open path /dev/rfkill,
but this path does not exist on my system. Instead, it should try to open
path /sys/class/rfkill.

Martin

On Tue, Oct 27, 2009 at 2:18 PM, Tomasz Torcz  wrote:

> On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote:
> > On most laptops, there is a way to disable Wi-Fi either through function
> > keys or kill switch. I am wondering if there is a way programmatically
> > speaking to figure out whether or not Wi-Fi is currently disabled because
> > the user has pressed the Wi-Fi function key or turned Wi-Fi off with the
> > kill switch.
>
>   You can install "rfkill" package and use same-named command:
> % rfkill list
> 0: tpacpi_bluetooth_sw: Bluetooth
>        Soft blocked: yes
>        Hard blocked: no
> 2: phy0: Wireless LAN
>        Soft blocked: no
>        Hard blocked: no
>
>
> --
> Tomasz Torcz            There exists no separation between gods and men:
> xmpp: zdzichubg at chrome.pl   one blends softly casual into the other.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mjg at redhat.com  Tue Oct 27 20:10:03 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 27 Oct 2009 20:10:03 +0000
Subject: Wi-Fi Question
In-Reply-To: <4AE7441A.8030404@olen.net>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<4AE7441A.8030404@olen.net>
Message-ID: <20091027201003.GA31518@srcf.ucam.org>

On Tue, Oct 27, 2009 at 08:03:54PM +0100, Ola Thoresen wrote:

> Nice app. Thanks for the tip.
> But does anyone have any idea about how to disable the hardware kill
> switch, when linux insists it is enabled no matter what position the
> switch is really set to:

What hardware is this?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From jkeating at redhat.com  Tue Oct 27 20:17:15 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Oct 2009 13:17:15 -0700
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271240.18937.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
Message-ID: <1256674635.2268.0.camel@localhost.localdomain>

On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> Id like to get some feedback on the patches that i'm proposing for F-13.  
> quite a few packages that need to deal with differences between 32bit/64bit  or 
> multilib arches have defines for the appropriate arches.  sometimes incomplete 
> since they don't include secondary arches. 

I'm not really a fan of growing more macro goo, particularly if it's
Fedora specific macro goo :/

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From dennis at ausil.us  Tue Oct 27 20:29:42 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 15:29:42 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <1256674635.2268.0.camel@localhost.localdomain>
References: <200910271240.18937.dennis@ausil.us>
	<1256674635.2268.0.camel@localhost.localdomain>
Message-ID: <200910271529.47686.dennis@ausil.us>

On Tuesday 27 October 2009 03:17:15 pm Jesse Keating wrote:
> On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > Id like to get some feedback on the patches that i'm proposing for F-13.
> > quite a few packages that need to deal with differences between
> > 32bit/64bit  or multilib arches have defines for the appropriate arches. 
> > sometimes incomplete since they don't include secondary arches.
> 
> I'm not really a fan of growing more macro goo, particularly if it's
> Fedora specific macro goo :/
> 
the multilib ones were the only ones i intended to put in redhat-rpm-config 
though im just as happy to try and get it into rpm.  the rest i had intended 
to get into rpm.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From SteveD at redhat.com  Tue Oct 27 20:38:07 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 27 Oct 2009 16:38:07 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091027183326.0A3857B79@magilla.sf.frob.com>
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
		<20091026174027.06B257B3E@magilla.sf.frob.com>	<4AE5E5BB.90109@RedHat.com>	<20091026181137.B0A857B3E@magilla.sf.frob.com>	<4AE5EF4A.9050606@RedHat.com>
	<20091027183326.0A3857B79@magilla.sf.frob.com>
Message-ID: <4AE75A2F.8040907@RedHat.com>



On 10/27/2009 02:33 PM, Roland McGrath wrote:
>> But with with older releases I don't messing with people configuration 
>> files since I would not want to break an existing configuration... 
> 
> Still never suggested that.
> 
>> Note, there is a number of people who are currently running with 
>> correctly configured v4 server... I would hate to mess those people up.. 
> 
> Of course.  So push an F-11 update where whatever configuration never
> mentions v4 and doesn't work for v4, doesn't advertise v4.
> 
Not sure how I would do this without the update being called a 
regression... any update that disables features does not seem
like a good thing...

steved.



From SteveD at redhat.com  Tue Oct 27 20:45:29 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 27 Oct 2009 16:45:29 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: 
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
		<4AE5E535.2040107@RedHat.com>
	
Message-ID: <4AE75BE9.5030905@RedHat.com>



On 10/26/2009 04:06 PM, Frank Ch. Eigler wrote:
> Steve Dickson  writes:
> 
>> [...]
>>> Unfortunately, this sounds like "only".  Is it out of the question to
>>> make the client look for this case (an upgraded client in an existing
>>> unupgraded, unchanged network) and handle it?
>> We talked about it... See [...]
>>
>> But in the end, I decided not to do this since its not clear how the change
>> would interact with other NFS servers...
> 
> It's a bit odd that we're about to push a backward-incompatible
> change into Fedora, just in case non-Fedora servers are around.
Well the reason for the incompatibility is the simple fact that 
the Linux server is a bit behind the rest of the servers out there
when it comes to this particular type of v4 support... 

Note, I've been pushing kernel patches to for over a year now (which are 
in currently in the F-12) which would bring the server up to speed in 
this area... but they gained any priority with the maintainer... 
until recently... 

steved.



From ville.skytta at iki.fi  Tue Oct 27 20:48:13 2009
From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=)
Date: Tue, 27 Oct 2009 22:48:13 +0200
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
References: <200910271240.18937.dennis@ausil.us>
	<1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
Message-ID: <200910272248.13713.ville.skytta@iki.fi>

On Tuesday 27 October 2009, Adam Jackson wrote:

> +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> 
> Remind me what the asymmetry is for here?  Why is %{ix86} not in
> %{multilib32} ?

Hm, maybe a stupid question: in what sense are %{ix86} multilib in the first 
place?



From dennis at ausil.us  Tue Oct 27 21:03:14 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Oct 2009 16:03:14 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910272248.13713.ville.skytta@iki.fi>
References: <200910271240.18937.dennis@ausil.us>
	<1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
	<200910272248.13713.ville.skytta@iki.fi>
Message-ID: <200910271603.19441.dennis@ausil.us>

On Tuesday 27 October 2009 03:48:13 pm Ville Skytt? wrote:
> On Tuesday 27 October 2009, Adam Jackson wrote:
> > +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> > +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> >
> > Remind me what the asymmetry is for here?  Why is %{ix86} not in
> > %{multilib32} ?
> 
> Hm, maybe a stupid question: in what sense are %{ix86} multilib in the
>  first place?
when you install %{ix86} packages on a x86_64 system.  same for ppc and 
%{sparc32} and s390.  

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From tibbs at math.uh.edu  Tue Oct 27 21:06:26 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Tue, 27 Oct 2009 16:06:26 -0500
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
	happen
In-Reply-To: <4AE5B378.1000507@RedHat.com> (Steve Dickson's message of "Mon,
	26 Oct 2009 10:34:32 -0400")
References: <4AE5B378.1000507@RedHat.com>
Message-ID: 

>>>>> "SD" == Steve Dickson  writes:

SD> On the server (Which is suggested): Add the following entry to the
SD> /etc/exports file:

SD> / *(ro,fsid=0)

SD> Note: 'fsid=0' is explained in the exports(5) man pages.

Could someone comment on any potential security issues that exporting
the root in this way exposes?  If all of my exported filesystems happen
to live under /export, can I export that directory instead of '/' and
have things work properly?  If, for whatever reason, I need to export a
file system that doesn't live in /export, would I still be able to mount
it?

 - J<



From pjones at redhat.com  Tue Oct 27 21:19:01 2009
From: pjones at redhat.com (Peter Jones)
Date: Tue, 27 Oct 2009 17:19:01 -0400
Subject: Wi-Fi Question
In-Reply-To: <7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>	<20091027181846.GA25682@mother.pipebreaker.pl>
	<7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
Message-ID: <4AE763C5.9070304@redhat.com>

On 10/27/2009 03:49 PM, Martin Dubuc wrote:
> This is a very nice tool. Unfortunately, on my system running Fedora 11, I
> get the following erro:
> Can't open RFKILL control device: No such file or directory
> 
> Using strace, I discovered that rfkill is trying to open path /dev/rfkill,
> but this path does not exist on my system. Instead, it should try to open
> path /sys/class/rfkill.

Yep, that feature isn't in kernels that old.

> 
> Martin
> 
> On Tue, Oct 27, 2009 at 2:18 PM, Tomasz Torcz  wrote:
> 
>> On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote:
>>> On most laptops, there is a way to disable Wi-Fi either through function
>>> keys or kill switch. I am wondering if there is a way programmatically
>>> speaking to figure out whether or not Wi-Fi is currently disabled because
>>> the user has pressed the Wi-Fi function key or turned Wi-Fi off with the
>>> kill switch.
>>
>>   You can install "rfkill" package and use same-named command:
>> % rfkill list
>> 0: tpacpi_bluetooth_sw: Bluetooth
>>        Soft blocked: yes
>>        Hard blocked: no
>> 2: phy0: Wireless LAN
>>        Soft blocked: no
>>        Hard blocked: no
>>
>>
>> --
>> Tomasz Torcz            There exists no separation between gods and men:
>> xmpp: zdzichubg at chrome.pl   one blends softly casual into the other.
>>
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
> 


-- 
        Peter

For some reason it has always seemed to me that the term software 
engineering contains some very optimistic assumptions about the 
nature of reality.



From linville at redhat.com  Tue Oct 27 21:20:33 2009
From: linville at redhat.com (John W. Linville)
Date: Tue, 27 Oct 2009 17:20:33 -0400
Subject: Wi-Fi Question
In-Reply-To: <7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
Message-ID: <20091027212033.GB21907@redhat.com>

On Tue, Oct 27, 2009 at 03:49:35PM -0400, Martin Dubuc wrote:
> This is a very nice tool. Unfortunately, on my system running Fedora 11, I
> get the following erro:
> Can't open RFKILL control device: No such file or directory
> 
> Using strace, I discovered that rfkill is trying to open path /dev/rfkill,
> but this path does not exist on my system. Instead, it should try to open
> path /sys/class/rfkill.

No, it shouldn't -- not the same thing.

As Peter Jones pointed-out, you need a newer kernel for that tool to work.

Hth...

John
-- 
John W. Linville		Linux should be at the core
linville at redhat.com			of your literate lifestyle.



From roland at redhat.com  Tue Oct 27 21:25:37 2009
From: roland at redhat.com (Roland McGrath)
Date: Tue, 27 Oct 2009 14:25:37 -0700 (PDT)
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: Steve Dickson's message of  Tuesday,
	27 October 2009 16:38:07 -0400 <4AE75A2F.8040907@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com> 
	<20091026174027.06B257B3E@magilla.sf.frob.com>
	<4AE5E5BB.90109@RedHat.com>
	<20091026181137.B0A857B3E@magilla.sf.frob.com>
	<4AE5EF4A.9050606@RedHat.com>
	<20091027183326.0A3857B79@magilla.sf.frob.com>
	<4AE75A2F.8040907@RedHat.com>
Message-ID: <20091027212537.7A7597CE1@magilla.sf.frob.com>

> > Of course.  So push an F-11 update where whatever configuration never
> > mentions v4 and doesn't work for v4, doesn't advertise v4.
> > 
> Not sure how I would do this without the update being called a 
> regression... any update that disables features does not seem
> like a good thing...

I described an update that disables FEATURES YOU SAID DO NOT WORK.



From redhat at olen.net  Tue Oct 27 21:40:30 2009
From: redhat at olen.net (Ola Thoresen)
Date: Tue, 27 Oct 2009 22:40:30 +0100
Subject: Wi-Fi Question
In-Reply-To: <20091027201003.GA31518@srcf.ucam.org>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>	<20091027181846.GA25682@mother.pipebreaker.pl>	<4AE7441A.8030404@olen.net>
	<20091027201003.GA31518@srcf.ucam.org>
Message-ID: <4AE768CE.1030508@olen.net>

On 27. okt. 2009 21:10, Matthew Garrett wrote:
> On Tue, Oct 27, 2009 at 08:03:54PM +0100, Ola Thoresen wrote:
> 
>> Nice app. Thanks for the tip.
>> But does anyone have any idea about how to disable the hardware kill
>> switch, when linux insists it is enabled no matter what position the
>> switch is really set to:
> 
> What hardware is this?
> 

02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
[Golan] Network Connection (rev 02)

(And it is the physical switch I am turning on and off)

Has had this issue for years (really). Here is a message from 2007 to
this list about it:
http://www.opensubscriber.com/message/fedora-devel-list at redhat.com/7502379.html
- With a link to an ubuntuforum-thread about the same issue.

Not really expecting a fix now, but if anyone is interessted, I can
submit a bug or try different kernels or whatever you need.


Rgds.

Ola (T)



From mjg at redhat.com  Tue Oct 27 21:48:53 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 27 Oct 2009 21:48:53 +0000
Subject: Wi-Fi Question
In-Reply-To: <4AE768CE.1030508@olen.net>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<4AE7441A.8030404@olen.net> <20091027201003.GA31518@srcf.ucam.org>
	<4AE768CE.1030508@olen.net>
Message-ID: <20091027214853.GA949@srcf.ucam.org>

On Tue, Oct 27, 2009 at 10:40:30PM +0100, Ola Thoresen wrote:
> On 27. okt. 2009 21:10, Matthew Garrett wrote:
> > What hardware is this?
> > 
> 
> 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
> [Golan] Network Connection (rev 02)
> 
> (And it is the physical switch I am turning on and off)

What's it plugged into?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From fedoraproject at cyberpear.com  Wed Oct 28 03:30:02 2009
From: fedoraproject at cyberpear.com (James Cassell)
Date: Tue, 27 Oct 2009 23:30:02 -0400
Subject: Packaging Survey - May 2009
In-Reply-To: <4A201396.5070105@fedoraproject.org>
References: <4A1D24AC.4090802@fedoraproject.org>
	<9497e9990905290704s6a531dc5i772d52601399973e@mail.gmail.com>
	<4A201396.5070105@fedoraproject.org>
Message-ID: 

On Fri, 29 May 2009 12:55:50 -0400, Rahul Sundaram  
 wrote:

> On 05/29/2009 07:34 PM, Mat Booth wrote:
>
>>
>> I don't think JEP should be on that list. I've used it in few
>> commercial products and its a thousand dollars a pop for a source code
>> licence:
>>
>> http://www.singularsys.com/order/
>
> JEP in the wiki is linked to http://sourceforge.net/projects/jep/. Are
> you even talking about the same software?

at the top of the sourceforge link you provided, it say "As of 2008-09-29  
00:00, this project may now be found at http://www.singularsys.com/jep"
so yes, it's the same software


-- 
James Cassell



From bojan at rexursive.com  Wed Oct 28 05:40:15 2009
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 28 Oct 2009 16:40:15 +1100
Subject: Notice: Fedora 12 Tagging Status Update
In-Reply-To: <4ADF6C96.3000006@redhat.com>
References: <4ADF6C96.3000006@redhat.com>
Message-ID: <1256708415.2488.2.camel@shrek.rexursive.com>

On Wed, 2009-10-21 at 16:18 -0400, Warren Togami wrote:
> 5) How many untagged packages are there?
> 
> koji list-tagged --latest dist-f12-updates-candidate

I ran this today (just for kicks). It gives back 323 packages. Even with
false positives, it a large amount for zero day updates.

This is just FYI. The original e-mail was about removing a backlog of
250+ packages waiting in Bodhi.

-- 
Bojan



From abo at root.snowtree.se  Wed Oct 28 06:41:34 2009
From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Wed, 28 Oct 2009 07:41:34 +0100
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <200910271324.34058.dennis@ausil.us>
References: <200910271240.18937.dennis@ausil.us>
	<1256667406.15835.9726.camel@atropine.boston.devel.redhat.com>
	<200910271324.34058.dennis@ausil.us>
Message-ID: <1256712095.28538.842.camel@tempo.alexander.bostrom.net>

tis 2009-10-27 klockan 13:24 -0500 skrev Dennis Gilmore:
> On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
> > On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > > Id like to get some feedback on the patches that i'm proposing for F-13.
> > > quite a few packages that need to deal with differences between
> > > 32bit/64bit  or multilib arches have defines for the appropriate arches. 
> > > sometimes incomplete since they don't include secondary arches.
> > >
> > > I wanted to get some feedback. and see if there are other cases we should
> > > add.
> > 
> > +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> > +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> > 
> > Remind me what the asymmetry is for here?  Why is %{ix86} not in
> > %{multilib32} ?

[...]

> it should be the attached patch.  the initial one was based on what gcc does 
> in its spec.  it treats %{ix86} as  not being multilib. 
> 
> +%multilib32 %{ix86} %{sparc32} ppc s390
> +%multilib64 x86_64 %{sparc64} ppc64 s390x

I thought the idea was: "multilibXX" is arches where libs go in "libXX"

Then "ix86" would indeed not be in multiliob32. (It should rather be in
"multilib" then, for symmetry...)

/abo




From redhat at olen.net  Wed Oct 28 08:43:17 2009
From: redhat at olen.net (Ola Thoresen)
Date: Wed, 28 Oct 2009 09:43:17 +0100
Subject: Wi-Fi Question
In-Reply-To: <20091027214853.GA949@srcf.ucam.org>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>	<20091027181846.GA25682@mother.pipebreaker.pl>	<4AE7441A.8030404@olen.net>
	<20091027201003.GA31518@srcf.ucam.org>	<4AE768CE.1030508@olen.net>
	<20091027214853.GA949@srcf.ucam.org>
Message-ID: <4AE80425.6050003@olen.net>

On 27. okt. 2009 22:48, Matthew Garrett wrote:
> On Tue, Oct 27, 2009 at 10:40:30PM +0100, Ola Thoresen wrote:
>> On 27. okt. 2009 21:10, Matthew Garrett wrote:
>>> What hardware is this?
>>>
>>
>> 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
>> [Golan] Network Connection (rev 02)
>>
>> (And it is the physical switch I am turning on and off)
>
> What's it plugged into?
>

What do you mean?

It is a built in PCI-card. And the switch is located in the front of the 
laptop.  Similar to this:
http://farm3.static.flickr.com/2415/2110359746_6502d6e204_o.jpg
It has two positions, "On" and "Off"
The card is clearly detected (the output above is from lspci), and 
flipping the switch is causing the messages about unknown keycodes in 
dmesg and /var/log/messages.



Rgds.

Ola (T)



From pbrobinson at gmail.com  Wed Oct 28 08:47:33 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 28 Oct 2009 08:47:33 +0000
Subject: Notice: Fedora 12 Tagging Status Update
In-Reply-To: <1256708415.2488.2.camel@shrek.rexursive.com>
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
Message-ID: <5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>

On Wed, Oct 28, 2009 at 5:40 AM, Bojan Smojver  wrote:
> On Wed, 2009-10-21 at 16:18 -0400, Warren Togami wrote:
>> 5) How many untagged packages are there?
>>
>> koji list-tagged --latest dist-f12-updates-candidate
>
> I ran this today (just for kicks). It gives back 323 packages. Even with
> false positives, it a large amount for zero day updates.
>
> This is just FYI. The original e-mail was about removing a backlog of
> 250+ packages waiting in Bodhi.

I thought dist-f12-updates-candidate were packages that had been build
for F-12 but had not yet been tagged. It doesn't necessarily mean they
are going to be pushed into F-12.

Peter



From linus.ml.walleij at gmail.com  Wed Oct 28 09:33:45 2009
From: linus.ml.walleij at gmail.com (Linus Walleij)
Date: Wed, 28 Oct 2009 10:33:45 +0100
Subject: What requires libgcc, actually?
Message-ID: <63386a3d0910280233m7f3dc02aoedafd909b0a9371@mail.gmail.com>

Just a quick question for those who know:

The shared libs from libgcc: /lib/libgcc*so* are not required by
anything:

[root at localhost ~]# rpm -q --whatrequires libgcc-4.4.1-2.fc11.i586
no package requires libgcc-4.4.1-2.fc11.i586

I have a vague memory that libstdc++ uses this runtime for e.g.
exception and that is why it's there.

Is libstdc++ missing a Requires: libgcc in it's spec, and/or are other
packages missing it as well?

It makes little sense to have a package installed that is not used
by anything....

Linus Walleij



From kwizart at gmail.com  Wed Oct 28 09:41:04 2009
From: kwizart at gmail.com (Nicolas Chauvet)
Date: Wed, 28 Oct 2009 10:41:04 +0100
Subject: What requires libgcc, actually?
In-Reply-To: <63386a3d0910280233m7f3dc02aoedafd909b0a9371@mail.gmail.com>
References: <63386a3d0910280233m7f3dc02aoedafd909b0a9371@mail.gmail.com>
Message-ID: 

2009/10/28 Linus Walleij :
> Just a quick question for those who know:
>
> The shared libs from libgcc: /lib/libgcc*so* are not required by
> anything:
>
> [root at localhost ~]# rpm -q --whatrequires libgcc-4.4.1-2.fc11.i586
> no package requires libgcc-4.4.1-2.fc11.i586

Use this instead:
repoquery --whatrequires "libgcc_s.so.1()(64bit)"
or on 32bit systems:
repoquery --whatrequires  libgcc_s.so.1

Nicolas (kwizart)



From harald at redhat.com  Wed Oct 28 09:47:50 2009
From: harald at redhat.com (Harald Hoyer)
Date: Wed, 28 Oct 2009 10:47:50 +0100
Subject: Should installkernel be passing --dracut to new-kernel-pkg?
In-Reply-To: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
References: <1256215683.2191.40.camel@moss-pluto.epoch.ncsc.mil>
Message-ID: <4AE81346.1070000@redhat.com>

On 10/22/2009 02:48 PM, Stephen Smalley wrote:
> Hi,
>
> /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a
> make install from a kernel.org kernel tree tries to
> invoke /sbin/mkinitrd rather than dracut.  Is that intentional?
>
> Also, any ideas on why a dracut-generated initramfs image generated for
> a kernel.org kernel tree would be so much larger than the Fedora kernel
> one (same .config)?
>
> 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img
> 82M /boot/initramfs-2.6.32-rc2.img
>

Newer dracut versions will strip kernel modules automatically.
The old version only strips, if the executable bit is set.



From kevin.kofler at chello.at  Wed Oct 28 10:24:51 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Oct 2009 11:24:51 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
	
	<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
	
	<20d6441a0910261530r2814b7a8s82c51e99717675ad@mail.gmail.com>
Message-ID: 

Jud Craft wrote:

> On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
>> But this is about C++.
> 
> I don't mean to misunderstand, but if I recall from your very first
> post in this thread...
> 
>> Actually, the ABI issue is only if you use the C code generator, not the
>> native ones.
> 
> Hence I thought you were talking about ABI issues with C.

You misunderstood me. The C code generator is an LLVM *back*end, not a 
frontend. The frontend is what recognizes the input language, the backend is 
what defines the output LLVM generates.

> I'm not up on how LLVM frontend integration works, so I actually don't
> understand the distinction between "the LLVM C Backend" and "the
> native LLVM backends".

LLVM can either directly output machine code (native backend) for some 
architectures or it can output preoptimized C code (especially for those 
architectures which don't have a native backend). The latter is what the "C 
code generator" or "C backend" does.

The ABI issues are when using one of the C++ frontends with the C backend.

> Simply, can I write and compile a GTK program with LLVM?

Yes.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 28 10:26:54 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Oct 2009 11:26:54 +0100
Subject: Looking into LLVM
References: <4AE47047.9000401@fedoraproject.org>
	
Message-ID: 

Eric Springer wrote:
> As for C++, I couldn't get some of my programs to compile as it seemed
> to spew at some of the template usage. Anyway it looks very promising
> and I look forward to using it in the future (especially with its
> non-nonsense licensing).

So you don't consider it "nonsense" to allow proprietary software companies 
to steal all your code without giving anything back? They can even sell you 
back some trivially modified version of YOUR OWN code! Non-copyleft licenses 
suck.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 28 10:39:59 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Oct 2009 11:39:59 +0100
Subject: rawhide report: 20091027 changes
References: <20091027121110.GA20529@releng2.fedora.phx.redhat.com>
Message-ID: 

Rawhide Report wrote:
> Removed package lam

Why was this package removed that late in F12's cycle, causing these broken 
dependencies:
> blacs-lam-1.1-33.fc12.i686 requires liblamf77mpi.so.0
> blacs-lam-1.1-33.fc12.i686 requires liblam.so.0
> orsa-lam-0.7.0-11.fc12.i686 requires lam
> scalapack-lam-1.7.5-7.fc12.i686 requires liblam.so.0
> scalapack-lam-1.7.5-7.fc12.i686 requires liblamf77mpi.so.0
> tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0
> tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0
> tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0
> tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0
?

I guess those -lam subpackages can and should be disabled, but at the very 
least this should have been properly coordinated.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct 28 10:43:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Oct 2009 11:43:36 +0100
Subject: libmusicbrainz orphaned
References: <1256656522.2367.108.camel@localhost.localdomain>
	<4AE71A46.8020504@gmail.com>
Message-ID: 

Ha?kel Gu?mar wrote:
> libmusicbrainz is an indirect dependence of listen (through
> libtunepimp), if no one steps, i'll sure have to.

They need to upgrade to libmusicbrainz3. The libtunepimp/libmusicbrainz 
protocol won't be supported server-side anymore very soon. :-(

There's also stuff in KDE which is affected, like Kscd (which for some 
stupid reason was converted from freedb to the obsolete libmusicbrainz API 
when it was already deprecated :-( ).

        Kevin Kofler



From jwboyer at gmail.com  Wed Oct 28 11:32:17 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 07:32:17 -0400
Subject: Notice: Fedora 12 Tagging Status Update
In-Reply-To: <5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
	<5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
Message-ID: <20091028113217.GB4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 08:47:33AM +0000, Peter Robinson wrote:
>On Wed, Oct 28, 2009 at 5:40 AM, Bojan Smojver  wrote:
>> On Wed, 2009-10-21 at 16:18 -0400, Warren Togami wrote:
>>> 5) How many untagged packages are there?
>>>
>>> koji list-tagged --latest dist-f12-updates-candidate
>>
>> I ran this today (just for kicks). It gives back 323 packages. Even with
>> false positives, it a large amount for zero day updates.
>>
>> This is just FYI. The original e-mail was about removing a backlog of
>> 250+ packages waiting in Bodhi.
>
>I thought dist-f12-updates-candidate were packages that had been build
>for F-12 but had not yet been tagged. It doesn't necessarily mean they
>are going to be pushed into F-12.

Correct.  It's the default tag for any build done for F12.

josh



From jwboyer at gmail.com  Wed Oct 28 11:35:30 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 07:35:30 -0400
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org>
	
	
Message-ID: <20091028113530.GC4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 11:26:54AM +0100, Kevin Kofler wrote:
>Eric Springer wrote:
>> As for C++, I couldn't get some of my programs to compile as it seemed
>> to spew at some of the template usage. Anyway it looks very promising
>> and I look forward to using it in the future (especially with its
>> non-nonsense licensing).
>
>So you don't consider it "nonsense" to allow proprietary software companies 
>to steal all your code without giving anything back? They can even sell you 
>back some trivially modified version of YOUR OWN code! Non-copyleft licenses 
>suck.

It's not stealing if you licensed it that way.  Please avoid inflammatory
language.

josh



From jgarzik at pobox.com  Wed Oct 28 11:44:35 2009
From: jgarzik at pobox.com (Jeff Garzik)
Date: Wed, 28 Oct 2009 07:44:35 -0400
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org> 
	<8278b1b0910251035p266800cci45f39baac8502aa1@mail.gmail.com>
	
	<20d6441a0910252040o232b404ftd44a62b59f4f1689@mail.gmail.com>
	
	<20d6441a0910261530r2814b7a8s82c51e99717675ad@mail.gmail.com>
	
Message-ID: <4AE82EA3.2080404@pobox.com>

On 10/28/2009 06:24 AM, Kevin Kofler wrote:
> Jud Craft wrote:
>
>> On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
>>> But this is about C++.
>>
>> I don't mean to misunderstand, but if I recall from your very first
>> post in this thread...
>>
>>> Actually, the ABI issue is only if you use the C code generator, not the
>>> native ones.
>>
>> Hence I thought you were talking about ABI issues with C.
>
> You misunderstood me. The C code generator is an LLVM *back*end, not a
> frontend. The frontend is what recognizes the input language, the backend is
> what defines the output LLVM generates.
>
>> I'm not up on how LLVM frontend integration works, so I actually don't
>> understand the distinction between "the LLVM C Backend" and "the
>> native LLVM backends".
>
> LLVM can either directly output machine code (native backend) for some
> architectures or it can output preoptimized C code (especially for those
> architectures which don't have a native backend). The latter is what the "C
> code generator" or "C backend" does.

clang and all other LLVM language front-ends produce "bitcode", which is 
virtualized machine code a la JVM.  LLVM backend generates 
processor-dependent machine code from processor-independent machine code.

The LLVM C __backend__ converts bitcode back into C...   something no 
idiot in their right mind would use for C++ or anything else.  The LLVM 
C backend is not commonly used.

The vast, vast majority of people trying to compile C++ programs with 
LLVM would either use
	clang -> llvm -> asm code
		or
	llvm-gcc -> llvm -> asm code

Certainly not
	Clang (C++) ? LLVM ? LLVM C backend ? gcc [-> asm code]

Regards,

	Jeff





From ewan at macmahon.me.uk  Wed Oct 28 12:05:06 2009
From: ewan at macmahon.me.uk (Ewan Mac Mahon)
Date: Wed, 28 Oct 2009 12:05:06 +0000
Subject: Wi-Fi Question
In-Reply-To: <4AE80425.6050003@olen.net>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<4AE7441A.8030404@olen.net> <20091027201003.GA31518@srcf.ucam.org>
	<4AE768CE.1030508@olen.net> <20091027214853.GA949@srcf.ucam.org>
	<4AE80425.6050003@olen.net>
Message-ID: <20091028120506.GF3591@macmahon.me.uk>

On Wed, Oct 28, 2009 at 09:43:17AM +0100, Ola Thoresen wrote:
> On 27. okt. 2009 22:48, Matthew Garrett wrote:
>> On Tue, Oct 27, 2009 at 10:40:30PM +0100, Ola Thoresen wrote:
>>> On 27. okt. 2009 21:10, Matthew Garrett wrote:
>>>> What hardware is this?
>>>
>>> 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
>>> [Golan] Network Connection (rev 02)
>>>
>>> (And it is the physical switch I am turning on and off)
>>
>> What's it plugged into?
>
> What do you mean?
>
> It is a built in PCI-card. And the switch is located in the front of the  
> laptop.

What make and model is the laptop?

Ewan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From rawhide at fedoraproject.org  Wed Oct 28 12:07:58 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 28 Oct 2009 12:07:58 +0000
Subject: rawhide report: 20091028 changes
Message-ID: <20091028120758.GA8872@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct 28 06:15:09 UTC 2009

Broken deps for i386
----------------------------------------------------------
	banshee-1.5.1-0.3.git20090917.fc12.i686 requires mono(Mono.Zeroconf) = 0:2.0.0.76
	galeon-2.0.7-16.fc12.i686 requires gecko-libs = 0:1.9.1.3



Broken deps for x86_64
----------------------------------------------------------
	banshee-1.5.1-0.3.git20090917.fc12.i686 requires mono(Mono.Zeroconf) = 0:2.0.0.76
	banshee-1.5.1-0.3.git20090917.fc12.x86_64 requires mono(Mono.Zeroconf) = 0:2.0.0.76
	galeon-2.0.7-16.fc12.x86_64 requires gecko-libs = 0:1.9.1.3



Broken deps for ppc
----------------------------------------------------------
	banshee-1.5.1-0.3.git20090917.fc12.ppc requires mono(Mono.Zeroconf) = 0:2.0.0.76
	banshee-1.5.1-0.3.git20090917.fc12.ppc64 requires mono(Mono.Zeroconf) = 0:2.0.0.76
	galeon-2.0.7-16.fc12.ppc requires gecko-libs = 0:1.9.1.3



Broken deps for ppc64
----------------------------------------------------------
	banshee-1.5.1-0.3.git20090917.fc12.ppc64 requires mono(Mono.Zeroconf) = 0:2.0.0.76
	galeon-2.0.7-16.fc12.ppc64 requires gecko-libs = 0:1.9.1.3
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package globus-gfork
        Globus Toolkit - GFork
New package kmagnet
        A simple puzzle game with a built-in puzzle editor
New package lam
        The Local Area Multicomputer programming environment
New package sblim-cmpi-dns
        SBLIM WBEM-SMT Dns
New package sblim-cmpi-params
        SBLIM params instrumentation
New package sblim-cmpi-samba
        SBLIM WBEM-SMT Samba
New package sblim-cmpi-syslog
        SBLIM syslog instrumentation
Removed package libgnomedb
Removed package tetex-bytefield
Removed package tetex-prosper
Updated Packages:

Miro-2.5.2-5.fc12
-----------------
* Tue Oct 27 2009 Jan Horak  - 2.5.2-5
- Rebuild against newer gecko


aqsis-1.6.0-3.fc12
------------------
* Mon Oct 19 2009 kwizart < kwizart at gmail.com > - 1.6.0-3
- Minor updates to SPEC file by Leon Tony Atkinson - 

* Sat Oct 17 2009 kwizart < kwizart at gmail.com > - 1.6.0-1
- Update to 1.6.0


asterisk-1.6.1.8-1.fc12
-----------------------
* Tue Oct 27 2009 Jeffrey C. Ollie  - 1.6.1.8-1
- Update to 1.6.1.8 to fix bug 531199:
-
- http://downloads.asterisk.org/pub/security/AST-2009-007.html
-
- A missing ACL check for handling SIP INVITEs allows a device to make
- calls on networks intended to be prohibited as defined by the "deny"
- and "permit" lines in sip.conf. The ACL check for handling SIP
- registrations was not affected.


atlas-3.8.3-12.fc12
-------------------
* Sat Oct 24 2009 Deji Akingunola  - 3.8.3-12
- Use alternatives to workaround multilib conflicts (BZ#508565).

* Tue Sep 29 2009 Deji Akingunola  - 3.8.3-11
- Obsolete the -header subpackage properly.


binutils-2.19.51.0.14-34.fc12
-----------------------------
* Tue Oct 27 2009 Jan Kratochvil  2.19.51.0.14-34
- Fix rpm --excludedocs (BZ 515922).
- Fix spurious scriplet errors by `exit 0'. (BZ 517979, Nick Clifton)


blam-1.8.5-19.fc12
------------------
* Tue Oct 27 2009 Jan Horak  - 1.8.5-19
- Rebuild against newer gecko

* Mon Oct 26 2009 Dennis Gilmore  - 1.8.5-18
- ExcludeArch sparc64


clc-0.02-2.fc12
---------------
* Sat Oct 24 2009 Sean Middleditch  0.02-2
- Removed explicit build requires version dependency.

* Tue Sep 29 2009 Sean Middleditch  0.02-1
- Update to upstream 0.02 release.
- Explicit version dependency for libtelnet due to unstable API/ABI.


constantine-backgrounds-12.1.0-1.fc12
-------------------------------------
* Tue Oct 27 2009 Martin Sourada  - 12.1.0-1
- New default, final extras selection, start building extras-kde subpackage

* Tue Oct 06 2009 Rex Dieter  - 12.0.0-2
- Provides: system-backgrounds(-kde) for F-12+ (until something else does)


cvc3-2.1-3.fc12
---------------
* Tue Oct 27 2009 Jerry James  - 2.1-3
- Drop the graphviz BR to block generation of huge class graphs
- Use the new (X)Emacs RPM macros to simplify the spec file


evince-2.28.1-4.fc12
--------------------
* Tue Oct 27 2009 Matthias Clasen  - 2.28.1-4
- Avoid a help file seriesid clash


fedora-gnome-theme-12.3-2.fc12
------------------------------
* Tue Oct 27 2009 Matthias Clasen  12.3-2
- Drop unused dependencies


fence-agents-3.0.4-3.fc12
-------------------------
* Tue Oct 27 2009 Fabio M. Di Nitto  - 3.0.4-2
- Fix Requires: on libvirt/libvirt-client

* Tue Oct 27 2009 Fabio M. Di Nitto  - 3.0.4-3
- Switch to file based Requires for virsh


fipscheck-1.2.0-4.fc12
----------------------
* Tue Oct 27 2009 Tomas Mraz  - 1.2.0-4
- ldconfig must be in the lib subpackage post(un)


firefox-3.5.4-1.fc12
--------------------
* Mon Oct 26 2009 Jan Horak  - 3.5.4-1
- Update to 3.5.4


gdm-2.28.1-12.fc12
------------------
* Tue Oct 27 2009 Ray Strode  2.28.1-11
- Tighten permissions on /var/run/gdm (bug 531063)

* Tue Oct 27 2009 Ray Strode  2.28.1-12
- One more go at bug 527920

* Mon Oct 26 2009 Ray Strode  2.28.1-10
- Position shutdown menu properly on multihead machines


gnome-applets-2.28.0-2.fc12
---------------------------
* Tue Oct 27 2009 Matthias Clasen  - 1:2.28.0-2
- Fix a help file seriesid clash between accessx-status and invest-applet


gnome-device-manager-0.2-6.fc12
-------------------------------
* Tue Oct 27 2009 Matthias Clasen  0.2-6
- Avoid a help file seriesid clash


gnome-disk-utility-2.28.0-5.fc12
--------------------------------
* Tue Oct 13 2009 Tomas Bzatek  - 2.28.0-5.fc12
- Fix nautilus crashes by proper object referencing


gnome-python2-extras-2.25.3-12.fc12
-----------------------------------
* Tue Oct 27 2009 Jan Horak  - 2.25.3-12
- Rebuild against newer gecko


gnome-web-photo-0.9-2.fc12
--------------------------
* Tue Oct 27 2009 Jan Horak  - 0.9-2
- Rebuild against newer gecko


gstreamer-plugins-base-0.10.25-3.fc12
-------------------------------------
* Tue Oct 27 2009 Bastien Nocera  0.10.25-3
- Fix audio disappearing with newer pulsesink


hsqldb-1.8.0.10-4.fc12
----------------------
* Thu Oct 22 2009 Jesse Keating  - 1.8.0.10-4
- Add patches from Caolan for #523110 and #517839


httpd-2.2.13-4.fc12
-------------------
* Tue Oct 27 2009 Tom "spot" Callaway  2.2.13-4
- add additional explanatory text to test page to help prevent legal emails to Fedora

* Tue Sep 08 2009 Joe Orton  2.2.13-2
- restart service in posttrans (#491567)


initscripts-9.02-1
------------------
* Tue Oct 27 2009 Bill Nottingham  - 9.02-1
- remove long-since deprecated initlog
- remove IUCV support (#507217)
- halt: put a wrapper around killall5 to account for retval 2 not being an error (#526539, )
- ifup-eth: honor DEFROUTE=yes|no for 'all' connection types. (#528822)
- network-functions: load bonding driver if BONDING_OPTS is defined. (#516569)
- rc.sysinit: put /dev/shm in mtab too, as dracut now mounts it. (#528667)

* Fri Oct 09 2009 Bill Nottingham  - 9.01-1
- rc.sysinit: fix handling of dmraid output to avoid error messages (#527726, )
- rwtab: add /var/lib/xend (#526046)
- translation updates: fi, nb, pl


kde-settings-4.3-12
-------------------
* Tue Oct 27 2009 Rex Dieter  4.3-12
- plasma-desktop-appletsrc: Constantine wallpaper
- drop /etc/kde/kdm/Xservers (#530660)


krb5-auth-dialog-0.13-2.fc12
----------------------------
* Tue Oct 27 2009 Matthias Clasen  - 0.13-2
- Fix a clash with the help file seriesid


libatasmart-0.17-1.fc12
-----------------------
* Tue Oct 27 2009 Lennart Poettering  0.17-1
- New upstream release
- Fixes bug 491552


libgphoto2-2.4.7-2.fc12
-----------------------
* Fri Oct 23 2009 Jindrich Novy  2.4.7-2
- return the dual-mode device to kernel once we don't use it (#530545)


libkate-0.3.6-1.fc12
--------------------
* Fri Oct 16 2009 kwizart < kwizart at gmail.com > - 0.3.6-1
- Update to 0.3.6


libtelnet-0.12-1.fc12
---------------------
* Sat Oct 24 2009 Sean Middleditch  0.12-1
- Update to libtelnet 0.12.
- Include libtelnet.pc in -devel package.


libvoikko-2.2.1-2.fc12
----------------------
* Mon Oct 26 2009 Ville-Pekka Vainio  - 2.2.1-2
- Add Python interface (package python-libvoikko, noarch)


mono-zeroconf-0.9.0-2.fc12
--------------------------
* Thu Oct 22 2009 Paul Lange  - 0.9-1
- update to version 0.9
- move docs into devel package

* Thu Oct 22 2009 Michel Salim  - 0.9.0-2
- Make AvahiDbus the only provider for now


mozvoikko-1.0-5.fc12
--------------------
* Tue Oct 27 2009 Jan Horak  - 1.0-5
- Rebuild against newer gecko


netcdf-4.0.1-3.fc12
-------------------
* Fri Oct 23 2009 Orion Poplawski  - 4.0.1-3
- Don't ship multi-lib incompatible nc-config
- Require gcc-gfortran for -devel (bug #483469)


openssh-5.2p1-29.fc12
---------------------
* Tue Oct 27 2009 Jan F. Chadima  - 5.2p1-29
- Resolve locking in ssh-add (#491312)


perl-Gtk2-MozEmbed-0.08-6.fc12.8
--------------------------------
* Tue Oct 27 2009 Jan Horak  - 0.08-6.8
- Rebuild against newer gecko


qt-4.5.3-6.fc12
---------------
* Fri Oct 16 2009 Than Ngo  - 4.5.3-6
- subpackage sqlite plugin, add Require on qt-sqlite in qt-x11
  for assistant

* Wed Oct 14 2009 Rex Dieter  4.5.3-5
- drop needless Prereq: /etc/ld.so.conf.d

* Sat Oct 10 2009 Than Ngo  - 4.5.3-4
- fix translation build issue
- rhel cleanup


sabayon-2.28.1-1.fc12
---------------------
* Tue Oct 27 2009 Tomas Bzatek  - 2.28.1-1
- Update to 2.28.1


seamonkey-2.0-7.fc12
--------------------
* Tue Oct 27 2009 Martin Stransky  2.0-7
- Update to 2.0


selinux-policy-3.6.32-35.fc12
-----------------------------
* Tue Oct 27 2009 Dan Walsh  3.6.32-35
- Allow bittlebee to connect to privoxy port
- Allow iptables to work with shorewall

* Fri Oct 23 2009 Dan Walsh  3.6.32-33
- Allow firefox to transition to java

* Fri Oct 23 2009 Dan Walsh  3.6.32-34
- Turn allow_postfix_local_write_mail_spool on by default
- Allow bluetooth setpcap
- Allow dbus to transiton to rpm_t when executing debuginfo-install
- Allow chrome-sandbox to sends it self signals.
- Fix the labeling of /usr/lib/libswscale.so.0.7.1
- Allow spamassassin to list /var/lib/spamassassin

* Thu Oct 22 2009 Dan Walsh  3.6.32-32
- Allow unconfined_execmem_t to transition to sandbox
- Allow postfix_cleanup to read etc_alias
- Allow consolekit to signal udev

* Wed Oct 21 2009 Dan Walsh  3.6.32-31
- Allow unconfined_execmem_t to transition to sandbox
- Add sectool policy
- Add sssd log files

* Tue Oct 20 2009 Dan Walsh  3.6.32-30
- Fixes found for confined users day

* Sat Oct 17 2009 Dan Walsh  3.6.32-29
- Allow ccs to communicate with userdomains, and create tmpfs_t
- Add /dev/noz* as a modem_device_t and allow modemmanager to rw it.
- Add mapping for /var/run/lircd

* Thu Oct 15 2009 Dan Walsh  3.6.32-28
- Allow sandbox_domain to interact with userdomain fifo_files

* Wed Oct 14 2009 Dan Walsh  3.6.32-27
- Allow plymouthd_t to use frame_buffer


setroubleshoot-2.2.42-1.fc12
----------------------------
* Mon Oct 26 2009 Dan Walsh  - 2.2.42-1
- Update po
- Fix bugzilla reporting to handle LoadError exception


setroubleshoot-plugins-2.1.29-1.fc12
------------------------------------
* Mon Oct 26 2009  - 2.1.29-1
- Update-po
- Add httpd_write_content plugin


sound-juicer-2.28.0-4.fc12
--------------------------
* Tue Oct 27 2009 Bastien Nocera  2.28.0-4
- Fix crasher when extracting a CD that's not in musicbrainz (#528297)


sssd-0.7.1-1.fc12
-----------------
* Tue Oct 27 2009 Stephen Gallagher  - 0.7.1-1
- Fix segfault in sssd_pam when cache_credentials was enabled
- Update the sample configuration
- Fix upgrade issues caused by data provider service removal


system-config-language-1.3.3-3.fc12
-----------------------------------
* Mon Oct 26 2009 Pravin Satpute - 1.3.3-3
- fixed 530698

* Fri Oct 09 2009 Pravin Satpute - 1.3.3-2
- fixed 525040


tetex-perltex-1.9-1.fc12
------------------------
* Mon Oct 26 2009 Tom "spot" Callaway  - 1.9-1
- update to 1.9


texlive-2007-46.fc12
--------------------
* Fri Oct 23 2009 Jindrich Novy  2007-46
- add missing dependency on kpathsea


texlive-texmf-2007-32.fc12
--------------------------
* Mon Oct 26 2009 Tom "spot" Callaway  2007-32
- resolve conflict between texlive-texmf (and -doc) and tetex-perltex
- resolve conflict between texlive-texmf and tetex-prosper
- resolve conflict between texlive-texmf and tetex-perltex


tuxcmd-0.6.69-git20091027.1.fc12
--------------------------------
* Tue Oct 27 2009 Tomas Bzatek  0.6.69-git20091027.1
- Rebase to latest git
- Enable PowerPC architectures


xulrunner-1.9.1.4-1.fc12
------------------------
* Mon Oct 26 2009 Jan Horak  - 1.9.1.4-1
- Update to 1.9.1.4


Summary:
Added Packages: 7
Removed Packages: 3
Modified Packages: 50



From andreas.tunek at gmail.com  Wed Oct 28 12:12:03 2009
From: andreas.tunek at gmail.com (Andreas Tunek)
Date: Wed, 28 Oct 2009 13:12:03 +0100
Subject: Nightly composes, rawhide or F12?
Message-ID: 

Are the nightly composes (such as this:
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ ) a
build of what will become F12 or are they a build of rawhide?

Best regards
Andreas



From pbrobinson at gmail.com  Wed Oct 28 12:24:13 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 28 Oct 2009 12:24:13 +0000
Subject: Nightly composes, rawhide or F12?
In-Reply-To: 
References: 
Message-ID: <5256d0b0910280524h1ae93d55t2f69a5fce6556f4c@mail.gmail.com>

On Wed, Oct 28, 2009 at 12:12 PM, Andreas Tunek  wrote:
> Are the nightly composes (such as this:
> http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ ) a
> build of what will become F12 or are they a build of rawhide?

I believe F-12 and rawhide are still one and the same. F-13 rawhide
hasn't opened up yet so they're still just a collection of tagged
packages in koji waiting to be released to unsuspecting people :-)

Peter



From jwboyer at gmail.com  Wed Oct 28 12:27:34 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 08:27:34 -0400
Subject: Nightly composes, rawhide or F12?
In-Reply-To: 
References: 
Message-ID: <20091028122734.GD4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 01:12:03PM +0100, Andreas Tunek wrote:
>Are the nightly composes (such as this:
>http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ ) a
>build of what will become F12 or are they a build of rawhide?

Both.  Rawhide _is_ what will become F12.  At least until it's switched
from the dist-f12 to the dist-f13 tag.

josh



From poelstra at redhat.com  Wed Oct 28 13:49:37 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 28 Oct 2009 09:49:37 -0400
Subject: Upcoming schedule
Message-ID: <4AE84BF1.3020509@redhat.com>

Tue 20-Oct  Mon 02-Nov  Beta Testing
Fri 30-Oct  Fri 30-Oct  Blocker Bug Day (F12Blocker) #2
Mon 02-Nov  Mon 02-Nov  End of Beta Testing
Wed 04-Nov  Wed 04-Nov  Compose RC
Wed 04-Nov  Wed 04-Nov  Enable Fedora 12 Updates
Wed 04-Nov  Wed 11-Nov  Test RC
Mon 09-Nov  Mon 09-Nov  F12 Blocker Review (go/no go) 3 PM EDT
Wed 11-Nov  Wed 11-Nov  F12 Project Wide Release Readiness Meeting



From ajax at redhat.com  Wed Oct 28 14:51:30 2009
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 28 Oct 2009 10:51:30 -0400
Subject: What requires libgcc, actually?
In-Reply-To: 
References: <63386a3d0910280233m7f3dc02aoedafd909b0a9371@mail.gmail.com>
	
Message-ID: <1256741490.15835.9821.camel@atropine.boston.devel.redhat.com>

On Wed, 2009-10-28 at 10:41 +0100, Nicolas Chauvet wrote:
> 2009/10/28 Linus Walleij :
> > Just a quick question for those who know:
> >
> > The shared libs from libgcc: /lib/libgcc*so* are not required by
> > anything:
> >
> > [root at localhost ~]# rpm -q --whatrequires libgcc-4.4.1-2.fc11.i586
> > no package requires libgcc-4.4.1-2.fc11.i586
> 
> Use this instead:
> repoquery --whatrequires "libgcc_s.so.1()(64bit)"
> or on 32bit systems:
> repoquery --whatrequires  libgcc_s.so.1

Or more generally:

% repoquery --whatrequires --alldeps libgcc

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From greno at verizon.net  Wed Oct 28 16:41:57 2009
From: greno at verizon.net (greno at verizon.net)
Date: Wed, 28 Oct 2009 11:41:57 -0500 (CDT)
Subject: axis2: openjdk6 javascript e4x rhino
Message-ID: <32687505.404792.1256748117220.JavaMail.root@vms062.mailsrvcs.net>

An HTML attachment was scrubbed...
URL: 

From overholt at redhat.com  Wed Oct 28 16:47:56 2009
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 28 Oct 2009 12:47:56 -0400
Subject: axis2: openjdk6 javascript e4x rhino
In-Reply-To: <32687505.404792.1256748117220.JavaMail.root@vms062.mailsrvcs.net>
References: <32687505.404792.1256748117220.JavaMail.root@vms062.mailsrvcs.net>
Message-ID: <20091028164755.GD2752@redhat.com>

* greno at verizon.net  [2009-10-28 12:42]:
> 
> This appears to be related to this bug:  https://bugs.launchpad.net/ubuntu/
> +source/openjdk-6/+bug/255149
> 
> What is the best way to workaround this rhino problem with openjdk6?

I recommend emailing fedora-devel-java-list.

Andrew



From promac at gmail.com  Wed Oct 28 17:28:37 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 28 Oct 2009 15:28:37 -0200
Subject: Wi-Fi Question
In-Reply-To: <4AE763C5.9070304@redhat.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
	<4AE763C5.9070304@redhat.com>
Message-ID: <68720af30910281028y1781b14bxd088c9df4905814b@mail.gmail.com>

On Tue, Oct 27, 2009 at 7:19 PM, Peter Jones  wrote:

> On 10/27/2009 03:49 PM, Martin Dubuc wrote:
> > This is a very nice tool. Unfortunately, on my system running Fedora 11,
> I
> > get the following erro:
> > Can't open RFKILL control device: No such file or directory
> >
> > Using strace, I discovered that rfkill is trying to open path
> /dev/rfkill,
> > but this path does not exist on my system. Instead, it should try to open
> > path /sys/class/rfkill.
>
> Yep, that feature isn't in kernels that old.
>
>
>
I have the same problem with a Philco 1001 notebok (intel atom) and F11.

You mean a 2.6.30 kernel is too old?

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From awilliam at redhat.com  Wed Oct 28 18:04:25 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Wed, 28 Oct 2009 11:04:25 -0700
Subject: Wi-Fi Question
In-Reply-To: <68720af30910281028y1781b14bxd088c9df4905814b@mail.gmail.com>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
	<4AE763C5.9070304@redhat.com>
	<68720af30910281028y1781b14bxd088c9df4905814b@mail.gmail.com>
Message-ID: <1256753065.2314.610.camel@adam.local.net>

On Wed, 2009-10-28 at 15:28 -0200, Paulo Cavalcanti wrote:

>         Yep, that feature isn't in kernels that old.
>         
>         
>         
> 
> I have the same problem with a Philco 1001 notebok (intel atom) and
> F11.
> 
> You mean a 2.6.30 kernel is too old?

Exactly. Fedora tends to run with a pretty aggressive definition of
'old' :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From dennis at ausil.us  Wed Oct 28 18:22:05 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 28 Oct 2009 13:22:05 -0500
Subject: RFC: proposed macro deffinitions for F-13
In-Reply-To: <1256712095.28538.842.camel@tempo.alexander.bostrom.net>
References: <200910271240.18937.dennis@ausil.us>
	<200910271324.34058.dennis@ausil.us>
	<1256712095.28538.842.camel@tempo.alexander.bostrom.net>
Message-ID: <200910281322.14843.dennis@ausil.us>

On Wednesday 28 October 2009 01:41:34 am Alexander Bostr?m wrote:
> tis 2009-10-27 klockan 13:24 -0500 skrev Dennis Gilmore:
> > On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
> > > On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
> > > > Id like to get some feedback on the patches that i'm proposing for
> > > > F-13. quite a few packages that need to deal with differences between
> > > > 32bit/64bit  or multilib arches have defines for the appropriate
> > > > arches. sometimes incomplete since they don't include secondary
> > > > arches.
> > > >
> > > > I wanted to get some feedback. and see if there are other cases we
> > > > should add.
> > >
> > > +%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
> > > +%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
> > >
> > > Remind me what the asymmetry is for here?  Why is %{ix86} not in
> > > %{multilib32} ?
> 
> [...]
> 
> > it should be the attached patch.  the initial one was based on what gcc
> > does in its spec.  it treats %{ix86} as  not being multilib.
> >
> > +%multilib32 %{ix86} %{sparc32} ppc s390
> > +%multilib64 x86_64 %{sparc64} ppc64 s390x
> 
> I thought the idea was: "multilibXX" is arches where libs go in "libXX"

thats only part of it.  the other issue you hit is that alot of packages have 
wrapper headers and the put the real headers in with -32 or -64 prefixes

so /usr/include/foo.h includes foo-32.h or foo-64.h depending on the arch your 
building for. this is to make sure headers dont conflict on multilib arches.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

From SteveD at redhat.com  Wed Oct 28 18:59:29 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Wed, 28 Oct 2009 14:59:29 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: 
References: <4AE5B378.1000507@RedHat.com> 
Message-ID: <4AE89491.4030303@RedHat.com>

On 10/27/2009 05:06 PM, Jason L Tibbitts III wrote:
>>>>>> "SD" == Steve Dickson  writes:
> 
> SD> On the server (Which is suggested): Add the following entry to the
> SD> /etc/exports file:
> 
> SD> / *(ro,fsid=0)
> 
> SD> Note: 'fsid=0' is explained in the exports(5) man pages.
> 
> Could someone comment on any potential security issues that exporting
> the root in this way exposes?  
Unfortunately this entry will expose your entire root in a read-only
fashion...

> If all of my exported filesystems happen to live under /export, can I 
> export that directory instead of '/' and have things work properly?  
Only by adding the above export entry would you be able to mount /export.

But since all your exports are under /export you might want to consider 
making '/export' your pseudo root by doing something like:
   /export *(ro,fsid=0)
   /export/home *(rw)

Then the clients could do a 'mount /home' which would mount the
/export/home directory on the server... Plus if the client dose 
a mount / the only directory they could 'see' would be 'home'

> If, for whatever reason, I need to export a file system that doesn't 
> live in /export, would I still be able to mount it?
With the '/ *(ro,fsid=0)' entry, Yes, you would be able to mount other
exported directories.. 

With the '/export *(ro,fsid=0)' entry, No, the client will only see 
directories under '/export'. The rest of the filesystem would not be
seen...

I hope this helps... 

steved.



From roland at redhat.com  Wed Oct 28 19:05:14 2009
From: roland at redhat.com (Roland McGrath)
Date: Wed, 28 Oct 2009 12:05:14 -0700 (PDT)
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: Steve Dickson's message of  Wednesday,
	28 October 2009 14:59:29 -0400 <4AE89491.4030303@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE89491.4030303@RedHat.com>
Message-ID: <20091028190514.B7E231D3@magilla.sf.frob.com>

It sounds like you are saying that there is no way to export the same
host filesystems with the same client-perceived names under v4 as was
being done before under v[23].  Is that really true?

My old /etc/exports is:

/mirror                        *(ro,insecure,sync,mp,all_squash)

So clients mount server:/mirror to see my /mirror directory's contents.
No other /foo directory is exported or visible at all to clients, and
that's how it should stay.

How do I get the same results for v4 clients?


Thanks,
Roland



From redhat at olen.net  Wed Oct 28 19:20:48 2009
From: redhat at olen.net (Ola Thoresen)
Date: Wed, 28 Oct 2009 20:20:48 +0100
Subject: Wi-Fi Question
In-Reply-To: <20091028120506.GF3591@macmahon.me.uk>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>	<20091027181846.GA25682@mother.pipebreaker.pl>	<4AE7441A.8030404@olen.net>
	<20091027201003.GA31518@srcf.ucam.org>	<4AE768CE.1030508@olen.net>
	<20091027214853.GA949@srcf.ucam.org>	<4AE80425.6050003@olen.net>
	<20091028120506.GF3591@macmahon.me.uk>
Message-ID: <4AE89990.1080805@olen.net>

On 28. okt. 2009 13:05, Ewan Mac Mahon wrote:

> 
> What make and model is the laptop?
> 

It is a Compal HGL31
(Compal is selling their laptops under a lot of different brands)


Rgds.

Ola Thoresen




From mmcgrath at redhat.com  Wed Oct 28 20:35:18 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Wed, 28 Oct 2009 15:35:18 -0500 (CDT)
Subject: CVS checkouts working again
Message-ID: 

It has come to our attention the nightly cvs checkout tarballs stopped
working.  A restorecon later and we're back in business.  Just letting
everyone know.

http://cvs.fedoraproject.org/webfiles/

	-Mike



From jlaska at redhat.com  Wed Oct 28 21:05:09 2009
From: jlaska at redhat.com (James Laska)
Date: Wed, 28 Oct 2009 17:05:09 -0400
Subject: [Test-Announce] F-12 Blocker Meeting 2009-10-30 @ 15:00 UTC (11 AM
	EDT)
Message-ID: <1256763909.2417.63.camel@localhost.localdomain>

When: Friday, 2009-10-30 @ 15:00 UTC (11 AM EDT)
Where: #fedora-bugzappers on irc.freenode.net

Please join us this Friday for another review of the Fedora 12 release
blocker bug list [1].  After two previous reviews, the list is now down
to 44 issues.  I've included a snapshot of the list (sorted by
component) below.  If you are the reported or maintainer for one of the
issues below, please take a moment to ensure the issue is up-to-date.

BUG#   STATUS    COMPONENT          SUMMARY
531347 NEW       abrt               abrt eating 99% cpu                                                      
493058 ASSIGNED  anaconda           Custom partitioning creation/edit causes traceback                       
506013 MODIFIED  anaconda           liveinst crash - DBusException ... No such property HwAddress            
510545 MODIFIED  anaconda           RFE: encryption key escrow support                                       
517260 MODIFIED  anaconda           liveinst fails at partitioning screen                                    
517491 ASSIGNED  anaconda           Anaconda fails if filesystem should be shrunk                            
526789 ASSIGNED  anaconda           Install didn't reboot at the end                                         
526925 ASSIGNED  anaconda           [Back] button does not have a corresponding icon (like [Next] does)      
527952 MODIFIED  anaconda           AttributeError: 'NoneType' object has no attribute 'disk'                
528317 MODIFIED  anaconda           anaconda traceback in getDefaultTimeZone KeyError en_AU                  
531407 MODIFIED  anaconda           --encrypted option does not work with pv in kickstart script             
530603 MODIFIED  compiz             Loads of "unknown actions" in GNOME keybindings                          
528909 NEW       DeviceKit-disks    DevKit 95-devkit-disks.rules should avoid scan all DM devices            
530913 NEW       DeviceKit-power    Couldn't hibernate: Swap space is encrypted                              
528097 MODIFIED  dmraid             /sbin/dmraid needs possibly unmounted /usr/lib                           
529267 NEW       fedora-logos       Better label + icon for the installer on the live cd                     
528497 MODIFIED  firstaidkit        FirstAidKit does not start when using F-12-Beta rescue mode from disc1.is
530320 NEW       firstboot          firstboot errors when loading modules                                    
512944 MODIFIED  gdm                fast-user-switching locks up login screen                                
531423 ASSIGNED  gdm                double-spacing in language and keyboard dialogs                          
531339 NEW       grubby             /sbin/installkernel isn't right for dracut                               
529982 NEW       gvfs               [abrt] crash detected in gvfs-1.4.0-6.fc12                               
517839 MODIFIED  hsqldb             bitxor and bitor both mapped to single bitor function                    
523110 MODIFIED  hsqldb             autoincrement bustage on column redefinition                             
528537 ASSIGNED  kernel             fails to get kickstart file over nfs.                                    
524795 ON_QA     libsigsegv         libsigsegv allocates alternate stack on the main stack                   
526549 NEW       lvm2               rats_install kickstart fails due to swap device prompt                   
523815 ASSIGNED  nautilus           nautilus hoses vino                                                      
531425 NEW       nfs-utils          newly installed system,NFS daemon start failed after  boot               
529349 ASSIGNED  PackageKit         Can't use yum with outdated or no repo data                              
530945 NEW       PackageKit         Package-kit ask for key but does not import                              
526044 NEW       polkit             Using invalid subject type crashes polkitd                               
517625 ASSIGNED  xorg-x11-drv-ati   Xorg stops responding and consumes 93%+ CPU time (radeon driver pcie_aspm
522929 ASSIGNED  xorg-x11-drv-ati   Occasional system hang when KMS kicks in (RV770)                         
522970 ASSIGNED  xorg-x11-drv-ati   popup messages unreadable                                                
531174 NEW       xorg-x11-drv-ati   KMS Screen Out-of-sync                                                   
531383 ASSIGNED  xorg-x11-drv-ati   KMS: VT Switch Problem with Radeon XPRESS 200M                           
514600 ASSIGNED  xorg-x11-drv-intel Intel 82G965 requires 'nomodeset' workaround to get working text-mode    
528005 MODIFIED  xorg-x11-drv-nouveaX server crash                                                           
530169 ASSIGNED  xorg-x11-drv-nouveanouveau + gdm crashes                     

Have an issue you'd like to propose as an F12 release blocker?  Please
consider the following criteria when escalating an issue:

      * Can this issue be fixed with a future update or is it part of
        the critical path? [2]
      * Is this defect a high (or greater) severity [3] with no, or an
        unreasonable, workaround?
      * Is this an embarrassing bug affecting a large number of users?

Come join the fun!
James

[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Blocker&hide_resolved=1
[2]
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_how_to_determine_packages_within_the_path
[3]
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
-------------- next part --------------
_______________________________________________
test-announce mailing list
test-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

From bojan at rexursive.com  Wed Oct 28 21:06:02 2009
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 28 Oct 2009 21:06:02 +0000 (UTC)
Subject: Notice: Fedora 12 Tagging Status Update
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
	<5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
Message-ID: 

Peter Robinson  gmail.com> writes:

> I thought dist-f12-updates-candidate were packages that had been build
> for F-12 but had not yet been tagged. It doesn't necessarily mean they
> are going to be pushed into F-12.

True, but there is no way to say right now which one would those be. So, if 50%
of them are destined for updates (a pretty safe bet, I'd say), it's still a
rather large number.

--
Bojan




From bruno at wolff.to  Wed Oct 28 21:27:26 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 28 Oct 2009 16:27:26 -0500
Subject: Wi-Fi Question
In-Reply-To: <1256753065.2314.610.camel@adam.local.net>
References: <7a0107ba0910270924n6723e8b9o56bda88868d3c337@mail.gmail.com>
	<20091027181846.GA25682@mother.pipebreaker.pl>
	<7a0107ba0910271249x1fd3f917le257e580b2b721ca@mail.gmail.com>
	<4AE763C5.9070304@redhat.com>
	<68720af30910281028y1781b14bxd088c9df4905814b@mail.gmail.com>
	<1256753065.2314.610.camel@adam.local.net>
Message-ID: <20091028212726.GB11055@wolff.to>

On Wed, Oct 28, 2009 at 11:04:25 -0700,
  Adam Williamson  wrote:
> On Wed, 2009-10-28 at 15:28 -0200, Paulo Cavalcanti wrote:
> 
> >         Yep, that feature isn't in kernels that old.
> >         
> >         
> >         
> > 
> > I have the same problem with a Philco 1001 notebok (intel atom) and
> > F11.
> > 
> > You mean a 2.6.30 kernel is too old?
> 
> Exactly. Fedora tends to run with a pretty aggressive definition of
> 'old' :)

He must have missed my comment about kernel-2.6.31.5-96 being old when
the kernel-2.6.31.5-97 build had been available in koji for less than a day.



From jwboyer at gmail.com  Wed Oct 28 22:11:30 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 18:11:30 -0400
Subject: Notice: Fedora 12 Tagging Status Update
In-Reply-To: 
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
	<5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
	
Message-ID: <20091028221111.GH4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 09:06:02PM +0000, Bojan Smojver wrote:
>Peter Robinson  gmail.com> writes:
>
>> I thought dist-f12-updates-candidate were packages that had been build
>> for F-12 but had not yet been tagged. It doesn't necessarily mean they
>> are going to be pushed into F-12.
>
>True, but there is no way to say right now which one would those be. So, if 50%
>of them are destined for updates (a pretty safe bet, I'd say), it's still a
>rather large number.

We had around 400 0-day stable updates for F11 if I'm remembering correctly.

josh



From tonynelson at georgeanelson.com  Wed Oct 28 22:17:31 2009
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Wed, 28 Oct 2009 18:17:31 -0400
Subject: Fedora PPC for oldworld Mac?
Message-ID: <1256768251.31270.1@localhost.localdomain>

Sorry to bug developers, but I didn't get any bites from PPC users on 
fedora-list.

Does Fedora PPC work or install on oldworld PCI Macs, such as a beige 
G3 desktop?  My impression is that no one has tried it on an oldworld 
Mac in the last few releases, and that getting it to boot at all would 
be an adventure.

(Otherwise I'm going to try Debian Lenny, which is said to work, but 
about which I know nothing.  The machine has 416 MB memory and I'll 
install a 40 GB hard disk for Linux, so other than speed it should be 
good to go.)

-- 
____________________________________________________________________
TonyN.:'                       
      '                              



From jwboyer at gmail.com  Wed Oct 28 22:24:49 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 18:24:49 -0400
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <1256768251.31270.1@localhost.localdomain>
References: <1256768251.31270.1@localhost.localdomain>
Message-ID: <20091028222449.GI4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
>Sorry to bug developers, but I didn't get any bites from PPC users on 
>fedora-list.
>
>Does Fedora PPC work or install on oldworld PCI Macs, such as a beige 
>G3 desktop?  My impression is that no one has tried it on an oldworld 

No, it doesn't.  The ppc specific release notes cover that here:

http://docs.fedoraproject.org/release-notes/f11/en-US/index.html#sect-Release_Notes-Hardware_Requirements

josh



From rayvd at bludgeon.org  Wed Oct 28 22:42:39 2009
From: rayvd at bludgeon.org (Ray Van Dolson)
Date: Wed, 28 Oct 2009 15:42:39 -0700
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <4AE89491.4030303@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE89491.4030303@RedHat.com>
Message-ID: <20091028224238.GA8084@bludgeon.org>

> > If, for whatever reason, I need to export a file system that doesn't 
> > live in /export, would I still be able to mount it?
> With the '/ *(ro,fsid=0)' entry, Yes, you would be able to mount other
> exported directories.. 
> 
> With the '/export *(ro,fsid=0)' entry, No, the client will only see 
> directories under '/export'. The rest of the filesystem would not be
> seen...

I suppose you could bind mount that other directory to be inside of
/export though and expose it that way?

> 
> I hope this helps... 
> 
> steved.



From erikina at gmail.com  Wed Oct 28 22:45:20 2009
From: erikina at gmail.com (Eric Springer)
Date: Thu, 29 Oct 2009 08:45:20 +1000
Subject: Looking into LLVM
In-Reply-To: 
References: <4AE47047.9000401@fedoraproject.org>
	 
	
Message-ID: 

On Wed, Oct 28, 2009 at 8:26 PM, Kevin Kofler  wrote:
> So you don't consider it "nonsense" to allow proprietary software companies
> to steal all your code without giving anything back?

When I write (opensource) code, I hope it's as useful to as many
people as possible. I'm not expecting recognition or payment or trying
to pushing any agenda, so I prefer to give without string attached.

Of course if it's your code, please do what ever you see fit . The
"nonsense" comment was more about all the compliance stuff required
when dealing with GPL software in propreitary projects


>They can even sell you
> back some trivially modified version of YOUR OWN code!

It'd be a hard sell!



From smooge at gmail.com  Wed Oct 28 22:51:50 2009
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 28 Oct 2009 16:51:50 -0600
Subject: Update/reboot of Fedora Infrastructure on 2009-10-29 21:00 UTC
Message-ID: <80d7e4090910281551t48409aa3w7748811ae1babe6a@mail.gmail.com>

Outage Notification - 2009-10-29 21:00 UTC

There will be an outage starting at 2009-10-29 21:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2009-10-29 21:00 UTC'

Affected Services:

Buildsystem
CVS / Source Control
Database
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent
Translation Services
Websites

Unaffected Services:

* None *

Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/1775

Reason for Outage:
Major update for OS.

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to track
the status of this outage.



-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning



From bojan at rexursive.com  Wed Oct 28 22:52:13 2009
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 28 Oct 2009 22:52:13 +0000 (UTC)
Subject: Notice: Fedora 12 Tagging Status Update
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
	<5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
	
	<20091028221111.GH4356@hansolo.jdub.homelinux.org>
Message-ID: 

Josh Boyer  gmail.com> writes:

> We had around 400 0-day stable updates for F11 if I'm remembering correctly.

Which makes me think - as many should be part of the release as possible, right?

--
Bojan






From jwboyer at gmail.com  Wed Oct 28 23:25:42 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Oct 2009 19:25:42 -0400
Subject: Notice: Fedora 12 Tagging Status Update
In-Reply-To: 
References: <4ADF6C96.3000006@redhat.com>
	<1256708415.2488.2.camel@shrek.rexursive.com>
	<5256d0b0910280147q35b4dbf0r69265cee0ea100ad@mail.gmail.com>
	
	<20091028221111.GH4356@hansolo.jdub.homelinux.org>
	
Message-ID: <20091028232542.GJ4356@hansolo.jdub.homelinux.org>

On Wed, Oct 28, 2009 at 10:52:13PM +0000, Bojan Smojver wrote:
>Josh Boyer  gmail.com> writes:
>
>> We had around 400 0-day stable updates for F11 if I'm remembering correctly.
>
>Which makes me think - as many should be part of the release as possible, right?

Yep.  Which is why bodhi submission for F12 is currently disabled and we're
encouraging people to submit tag requests.

josh



From tonynelson at georgeanelson.com  Thu Oct 29 02:25:58 2009
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Wed, 28 Oct 2009 22:25:58 -0400
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <20091028222449.GI4356@hansolo.jdub.homelinux.org> (from
	jwboyer@gmail.com on Wed Oct 28 18:24:49 2009)
Message-ID: <1256783158.32634.0@localhost.localdomain>

On 09-10-28 18:24:49, Josh Boyer wrote:
> On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
> >Sorry to bug developers, but I didn't get any bites from PPC
> >users on fedora-list.
> >
> >Does Fedora PPC work or install on oldworld PCI Macs, such as
> >a beige G3 desktop?  My impression is that no one has tried it
> >on an oldworld
> 
> 
> No, it doesn't.  The ppc specific release notes cover that here:
> 
> http://docs.fedoraproject.org/release-notes/f11/en-US/
> index.html#sect-Release_Notes-Hardware_Requirements

I'd looked at the release notes.  They says "Minimum CPU: PowerPC 
G3..." and "Although Old World machines should work, they require a 
special bootloader which is not included in the Fedora distribution."  
My question is whether anyone has tried it in any recent Fedora
release and knows whether "should" means "do" or "don't".

(FWIW, the special bootloader is BootX, and Debian Lenny is installing 
now, so /some/ form of Linux works.  I just don't know anything but 
hearsay about Debian.  I see it uses "apt".)

-- 
____________________________________________________________________
TonyN.:'                       
      '                              



From john.brown009 at gmail.com  Wed Oct 28 21:39:31 2009
From: john.brown009 at gmail.com (TK009)
Date: Wed, 28 Oct 2009 17:39:31 -0400
Subject: Upcoming Bugzilla Changes
Message-ID: <20091028213931.GC2663@blackhare>

The time is almost here to reap the harvest on which so many have toiled and 
enjoy the bounty that is Fedora 12. With each new Fedora release comes some 
Bugzilla housekeeping.  This e-mail is designed to let you know about two things
 happening around November 17, 2009 (Fedora 12 release day) and 
what you need to do, if anything.

(1) We will be automatically changing the version all rawhide bugs to Fedora 12.  
This will result in regular bugs reported against rawhide during the Fedora 12 
development cycle being changed to version '12' instead of their current 
assignment, 'rawhide'.  This is done in order to more accurately tell where in 
the lineage of releases the bug was last reported because over time 'rawhide' 
becomes ambiguous.

Note that this procedure does not apply to bugs that are against component 
'Package Review' or bugs that have the 'FutureFeature' or 'Tracking' keywords 
set. 
They will stay open as rawhide bugs indefinitely.

If you do not want your bugs changed to version '12', add the FutureFeature 
keyword. 
If you need help changing a large amount of bugs manually, we'd be glad to help. 
Stop by #fedora-bugzappers on irc.freenode.net and we'll help you.

(2) All bugs for upcoming EOL releases (at this point, Fedora 10) will get a 
comment on release day, explaining that one month of maintenance remains.  
These bugs must move to a later version if still applicable or they will be 
automatically closed in one month with a resolution of WONTFIX.

More about these processes is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping

Thanks for reading,
Edward Kirk
Fedora Bug Triage Team 

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From christoph.frieben at googlemail.com  Thu Oct 29 08:49:13 2009
From: christoph.frieben at googlemail.com (Christoph Frieben)
Date: Thu, 29 Oct 2009 09:49:13 +0100
Subject: Font rendering slightly degraded in recent rawhide
Message-ID: 

I have the impression that since about 2 days ago the font rendering
in Fedora rawhide is less good than before. Fonts appear fuzzier, and
in particular Luxi Mono looks more deformed. There hasn't been a
freetype update, thus some GNOME package might be responsible.
I have noticed this effect on 2 different systems, one with an ATI
video card, the other with an Intel onboard graphics device. ~C



From tomek at pipebreaker.pl  Thu Oct 29 09:20:26 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Thu, 29 Oct 2009 10:20:26 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
Message-ID: <20091029092026.GB25682@mother.pipebreaker.pl>

On Thu, Oct 29, 2009 at 09:49:13AM +0100, Christoph Frieben wrote:
> I have the impression that since about 2 days ago the font rendering
> in Fedora rawhide is less good than before. Fonts appear fuzzier, and
> in particular Luxi Mono looks more deformed. There hasn't been a
> freetype update, thus some GNOME package might be responsible.
> I have noticed this effect on 2 different systems, one with an ATI

  There was a change to font properties which changed "Best shapes"
to turn on slight hinting.

-- 
Tomasz Torcz                Only gods can safely risk perfection,
xmpp: zdzichubg at chrome.pl     it's a dangerous thing for a man.  -- Alia



From jnovy at redhat.com  Thu Oct 29 10:14:05 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Thu, 29 Oct 2009 11:14:05 +0100
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: 
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
	
Message-ID: <20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>

On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
> Jindrich Novy wrote:
> 
> > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
> >> I wonder if texlive should include a /etc/profile.d package to set
> >> TEXMFCNF,
> >> so that other packages, such as xdvipdfmx will work?  Or, should texlive
> >> just obsolete xdvipdfmx and include it's own version?
> > 
> > I will try to fix it in the texmf.cnf kpathsea configuration file
> > directly in the new TL2009 update.
> > 
> > Jindrich
> > 
> Could you explain?

The plan was to update the texmf.cnf to tell kpathsea to look for
files in the /usr/share/texmf tree prior to the main TL2009 tree. This
should make the utilities like xdvipdfmx work even though they are
linked against old kpathsea and expects configuration bits in
/usr/share/texmf.

> Will you replace the current xdvipdfmx?

Currently I'm trying to not to replace any package that has a separate
upstream and is already packaged separatelly in Fedora.

Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From rawhide at fedoraproject.org  Thu Oct 29 11:06:43 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 29 Oct 2009 11:06:43 +0000
Subject: rawhide report: 20091029 changes
Message-ID: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 29 06:15:07 UTC 2009

Broken deps for i386
----------------------------------------------------------
	banshee-1.5.1-3.fc12.i686 requires mono(Mono.Zeroconf) = 0:4.0.0.90
	blam-1.8.5-18.fc12.i686 requires gecko-libs = 0:1.9.1.3
	galeon-2.0.7-16.fc12.i686 requires gecko-libs = 0:1.9.1.3
	1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0



Broken deps for x86_64
----------------------------------------------------------
	banshee-1.5.1-3.fc12.i686 requires mono(Mono.Zeroconf) = 0:4.0.0.90
	banshee-1.5.1-3.fc12.x86_64 requires mono(Mono.Zeroconf) = 0:4.0.0.90
	blam-1.8.5-18.fc12.x86_64 requires gecko-libs = 0:1.9.1.3
	galeon-2.0.7-16.fc12.x86_64 requires gecko-libs = 0:1.9.1.3
	1:nant-0.85-30.fc12.x86_64 requires mono(NDoc.Core) = 0:1.3.3498.0



Broken deps for ppc
----------------------------------------------------------
	banshee-1.5.1-3.fc12.ppc requires mono(Mono.Zeroconf) = 0:4.0.0.90
	banshee-1.5.1-3.fc12.ppc64 requires mono(Mono.Zeroconf) = 0:4.0.0.90
	blam-1.8.5-18.fc12.ppc requires gecko-libs = 0:1.9.1.3
	galeon-2.0.7-16.fc12.ppc requires gecko-libs = 0:1.9.1.3



Broken deps for ppc64
----------------------------------------------------------
	banshee-1.5.1-3.fc12.ppc64 requires mono(Mono.Zeroconf) = 0:4.0.0.90
	galeon-2.0.7-16.fc12.ppc64 requires gecko-libs = 0:1.9.1.3
	python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot



New package gnome-globalmenu
        Global Menu for GNOME
Updated Packages:

DeviceKit-power-012-2.fc12
--------------------------
* Wed Oct 28 2009 Matthias Clasen  - 012-2
- Make hibernate work again


anaconda-12.41-1.fc12
---------------------
* Wed Oct 28 2009 Chris Lumens  - 12.40-1
- preexist -> onPart (#531407). (clumens)
- Support upgrading when the language isn't in lang-table (#528317).
  (clumens)
- max_logical -> max_logicals (#530786). (clumens)
- We moved from dialog to newt.. (#528497) (msivak)

* Wed Oct 28 2009 David Cantrell  - 12.41-1
- BR system-config-keyboard (dcantrell)


apr-1.3.9-3.fc12
----------------
* Sun Oct 25 2009 Bojan Smojver  - 1.3.9-3
- remove uuid/crypt libs from pkg-config file


banshee-1.5.1-3.fc12
--------------------
* Wed Oct 28 2009 Kevin Kofler  - 1.5.1-3
- Rebuild against new mono-zeroconf (#526132)

* Mon Oct 26 2009 Dennis Gilmore  - 1.5.1-2
- ExcludeArch sparc64

* Mon Oct 19 2009 Michel Salim  - 1.5.1-1
- Update to final 1.5.1 release


banshee-mirage-0.5.0-5.fc12
---------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.5.0-5
- switch to ExcludeArch, excluding sparc64


bareftp-0.2.3-4.fc12
--------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.2.3-4
- Exclude sparc64 no mono available


beagle-0.3.9-15.fc12
--------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.3.9-15
- enable s390 and s390x


blam-1.8.5-18.fc12
------------------

bless-0.6.0-5.fc12
------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.6.0-5
- ExckudeArch sparc64


bzr-2.0.1-1.fc12
----------------
* Thu Oct 29 2009 Henrik Nordstrom  - 2.0.1-1
- Update to 2.0.1 bugfix release


cdcollect-0.6.0-10.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.6.0-10
- ExcludeArch sparc64  no mono there


chronojump-0.8.11-3.fc12
------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.11-3
- ExcludeArch sparc64.  no mono available


clutter-sharp-0-0.6.20090828.fc12
---------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0-0.6.20090828
- ExcludeArch sparc64


constantine-kde-theme-12.1.0-1.fc12
-----------------------------------
* Wed Oct 28 2009 Jaroslav Reznik  12.1.0-1
- Constantine Smile KSplash Theme
- Constantine Loadme! login screen Theme


cowbell-0.3-0.svn47.1.fc12.4
----------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.3.0-0.svn47.1.4
- ExcludeArch sparc64 no mono


cups-1.4.1-12.fc12
------------------
* Tue Oct 27 2009 Jiri Popelka  1:1.4.1-12
- Fix incorrectly applied patch from #STR3285 (bug #531108).
- Set the PRINTER_IS_SHARED variable for admin.cgi (bug #529634, #STR3390).
- Pass through serial parameters correctly in web interface (bug #529635, #STR3391).
- Fixed German translation (bug #531144, #STR3396).

* Tue Oct 20 2009 Jiri Popelka  1:1.4.1-11
- Fix cups-lpd to create unique temporary data files (bug #529838).


dbus-sharp-0.63-14.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.63-14
- ExcludeArch sparc64


evolution-sharp-0.21.1-5.fc12
-----------------------------
* Mon Oct 26 2009 Dennis Gilmore  0.20.1-5
- ExcludeArch sparc64


f-spot-0.6.1.3-2.fc12
---------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.6.1.3-2
- ExcludeArch sparc64


fedora-logos-12.0.2-2.fc12
--------------------------
* Wed Oct 28 2009 Tom "spot" Callaway  - 12.0.2-1
- Update to 12.0.2, has improved system-software-install icon

* Wed Oct 28 2009 Tom "spot" Callaway  - 12.0.2-2
- Fixed 12.0.2 source, package up scalable svg source for system-software-install icon


flickrnet-2.2-3.fc12
--------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.2-3
- enable sparcv9 s390 s390x


fluidsynth-1.0.9-4.fc12
-----------------------
* Wed Oct 28 2009 Orcan Ogetbil  - 1.0.9-4
- Fix doxygen doc multilib conflict (RHBZ#528240)


gbrainy-1.1-6.fc12
------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.1-6
- Exclude sparc64


gecko-sharp2-0.13-13.fc12
-------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.13-13
- ExcludeArch sparc64


gmime-2.4.7-3.fc12
------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.4.7-3
- build mono support on s390 and s390x
- exclude mono support on sparc64


gnome-desktop-sharp-2.26.0-5.fc12
---------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.26.0-5
- Exclude sparc64


gnome-do-0.8.2-3.fc12
---------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.2-3
- Exclude sparc64  no mono available


gnome-guitar-0.8.1-7.fc12
-------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.1-7
- ExcludeArch sparc64


gnome-rdp-0.2.3-6.fc12
----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.2.3-6
- exclude sparc64


gnome-settings-daemon-2.28.1-5.fc12
-----------------------------------
* Wed Oct 28 2009 Bastien Nocera  2.28.1-5
- Update OSD code again

* Tue Oct 27 2009 Bastien Nocera  2.28.1-4
- Fix bluriness in OSD


gnome-sharp-2.24.0-7.fc12
-------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.24.0-7
- build sparcv9


gnome-subtitles-0.8-10.fc12
---------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8-10
- ExcludeArch sparc64


gsf-sharp-0.8.1-12.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.1-12
- exclude sparc64


gtk-sharp-1.0.10-25.fc12
------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.0.10-25
- ExcludeArch sparc64


gtk2-2.18.3-15.fc12
-------------------
* Wed Oct 28 2009 Matthias Clasen  - 2.18.3-14
- Make the new tooltips sharp
- Improve the Metacity compositor workaround for new tooltips

* Wed Oct 28 2009 Matthias Clasen  - 2.18.3-15
- Work around a bug in the X automatic compositor (#531443)

* Mon Oct 26 2009 Matthias Clasen  - 2.18.3-12
- Fix a possible assertion failure in GtkToolButton


gtksourceview-sharp-2.0.12-10.fc12
----------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.0.12-10
- switch sparc to sparcv9 for arches


gtksourceview2-sharp-1.0-6.svn89788.fc12
----------------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.0-6.svn89788
- ExcludeArch sparc64


ipod-sharp-0.8.2-2.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.2-2
- ExcludeArch sparc64


jack-audio-connection-kit-0.116.1-7.fc12
----------------------------------------
* Tue Oct 27 2009 Dennis Gilmore  - 0.116.1-7
- dont build libfreebob support on s390 arches


lat-1.2.3-9.fc12
----------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.2.3-9
- remove fedora 5 conditionals
- ExcldeArch sparc64


libpcap-1.0.0-4.20090922gite154e2.fc12
--------------------------------------
* Sat Oct 17 2009 Dennis Gilmore  14:1.0.0-4.20090922gite154e2
- use -fPIC on sparc arches


log4net-1.2.10-8.fc12
---------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.2.10-8
- Exclude sparc64  no mono


metacity-2.28.0-6.fc12
----------------------
* Wed Oct 28 2009 Matthias Clasen  - 2.28.0-6
- Make tooltips look sharper

* Wed Oct 21 2009 Matthias Clasen  - 2.28.0-4
- Make tooltips look match GTK+


mod_mono-2.4.2-3.fc12
---------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.4.2-3
- excludeArch sparc64


mono-addins-0.4-9.20091702svn127062.fc12
----------------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.4-9.20091702svn127062
- exclude sparc64


mono-basic-2.4.2-4.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.4.2-4
- ExcludeArch sparc64


mono-cecil-flowanalysis-0.1-0.10.20080409svn100264.fc12
-------------------------------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.1-0.10.20080409svn100264
- ExcludeArch sparc64


mono-nat-1.0.2-3.fc12
---------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.0.2-3
- ExcludeArch sparc64


mono-ndoc-1.3.1-7.fc12
----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.3.1-7
- ExcludeArch sparc64 no mono available


mono-sharpcvslib-0.35-12.fc12
-----------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.35-12
- ExcludeArch sparc64


mono-tools-2.4.2-6.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.4.2-6
- exclude sparc64


mono-zeroconf-0.7.6-11.fc12
---------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.7.6-11
- ExcludeArch sparc64


monotorrent-0.72-5.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.72-5
- exclude sparc64


monsoon-0.21-3.fc12
-------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.21-3
- exclude sparc64


muine-0.8.11-3.fc12
-------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.8.11-3
- exclude sparc64  no mono


mxml-2.5-5.fc12
---------------
* Wed Oct 28 2009 Orcan Ogetbil  - 2.5-5
- Fix typo in the .pc file (RHBZ#503628). Patch by Robert Szalai


mysql-5.1.39-4.fc12
-------------------
* Sat Oct 17 2009 Tom Lane  5.1.39-4
- Replace kluge fix for ndbd sparc crash with a real fix (mysql bug 48132)


ndesk-dbus-0.6.1a-8.fc12
------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.6.1a-8
- ExcludeArch sparc64


ndesk-dbus-glib-0.4.1-8.fc12
----------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.4.1-8
- ExcludeArch sparc64


notify-sharp-0.4.0-0.10.20080912svn.fc12
----------------------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.4.0-0.10.20080912svn
- Switch to ExcludeArch sparc64 has no mono


nspr-4.8.2-1.fc12
-----------------
* Tue Oct 13 2009 Kai Engert  - 4.8.2-1
- update to 4.8.2


pygpgme-0.1-17.20090824bzr68.fc12
---------------------------------
* Wed Oct 28 2009 Toshio Kuratomi  - 0.1-17.20090824bzr68
- Include tests and examples as documentation.


snort-2.8.5.1-1.fc12
--------------------
* Sun Oct 25 2009 Dennis Gilmore  - 2.8.5.1-1
- update for CVE-2009-3641


sublib-0.9-6.fc12
-----------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.9-6
- disable for sparc64  no mono


taglib-sharp-2.0.3.2-5.fc12
---------------------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.0.3.2-5
- switch sparc to sparcv9


tanukiwrapper-3.2.3-5.fc12
--------------------------
* Sun Oct 25 2009 Dennis Gilmore  - 0:3.2.3-5
- add patch with sparc support


tomboy-1.0.0-2.fc12
-------------------
* Mon Oct 26 2009 Dennis Gilmore  - 1.0.0-2
- exclude sparc64  no mono available


webkit-sharp-0.2-6.fc12
-----------------------
* Mon Oct 26 2009 Dennis Gilmore  - 0.2-6
- build for sparcv9 s390 s390x


xsp-2.4.2-3.fc12
----------------
* Mon Oct 26 2009 Dennis Gilmore  - 2.4.2-3
- enable sparcv9 s390 s390x


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 69



From swhiteho at redhat.com  Thu Oct 29 11:19:51 2009
From: swhiteho at redhat.com (Steven Whitehouse)
Date: Thu, 29 Oct 2009 11:19:51 +0000
Subject: Orphan Package: system-config-cluster
In-Reply-To: <1256217277.6052.668.camel@localhost.localdomain>
References: <1256116297.2716.10.camel@localhost.localdomain>
	<20091021181022.GA7460@clingman.lan>
	<1256217277.6052.668.camel@localhost.localdomain>
Message-ID: <1256815191.2733.4.camel@localhost.localdomain>

Hi,

[from last week's announcement]
> 
> system-config-cluster is currently dead as an upstream project. If
> someone wants to take over the fedora package, then they will first have
> to take over the upstream side of things too.
>
Here then, for the second time of asking, is a request to see if anybody
will take on the upstream maintenance of system-config-cluster.

If I receive no interest by this time next week, then I'll start the
package retirement process,

Steve.




From clodoaldo.pinto.neto at gmail.com  Thu Oct 29 11:29:59 2009
From: clodoaldo.pinto.neto at gmail.com (Clodoaldo Neto)
Date: Thu, 29 Oct 2009 09:29:59 -0200
Subject: httpd run directory permissions in F12/11
Message-ID: 

I've been using Fedora 10 and while trying F12 beta I noticed a
problem in the httpd run directory permission. Then I tried F11 and
the same problem happens:

[Wed Oct 28 12:05:02 2009] [notice] Apache/2.2.13 (Unix) DAV/2
PHP/5.2.9 mod_python/3.3.1 Python/2.6 mod_ssl/2.2.13
OpenSSL/0.9.8k-fips mod_wsgi/2.6 mod_perl/2.0.4 Perl/v5.10.0
configured -- resuming normal operations
[Wed Oct 28 12:05:09 2009] [error] [client 10.0.2.15] (13)Permission
denied: mod_wsgi (pid=2722): Unable to connect to WSGI daemon process
'mygroup' on '/etc/httpd/run/wsgi.2692.0.1.sock' after multiple
attempts.

The problem is that until F10 the httpd socket directory was /var/run/
and in F11 and F12 it is /var/run/httpd:

# ll /etc/httpd/run
lrwxrwxrwx. 1 root root 19 2009-10-28 11:04 /etc/httpd/run ->
../../var/run/httpd

# ll -d /var/run/httpd
drwx------. 2 root root 4096 2009-10-28 11:51 /var/run/httpd

# ll -d /var/run
drwxr-xr-x. 31 root root 4096 2009-10-28 11:35 /var/run

# ll /var/run/httpd/
total 4
-rw-r--r--. 1 root   root 5 2009-10-28 12:05 httpd.pid
srwx------. 1 apache root 0 2009-10-28 12:05 wsgi.2692.0.1.sock

That can break some apache modules like mod_wsgi which rely on sockets.

Any of these solve the problem:

# chmod o+x /var/run/httpd
# chown apache.root /var/run/httpd

Is there a reason for the /var/run/httpd permissions to be as in
F11/12 ? Is it necessary to have the user intervention to fix it? I
have posted at the mod_wsgi list:

http://groups.google.com/group/modwsgi/t/c5f5abc122088478

Regards, Clodoaldo Neto



From choeger at cs.tu-berlin.de  Thu Oct 29 11:38:24 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 29 Oct 2009 12:38:24 +0100
Subject: Feature request: AMD K10 thermal sensors
Message-ID: <1256816304.2552.3.camel@choeger5.umpa.netz>

Hi,

since a year or so the AMD K10 thermal sensors module (k10temp) seems to
be floating around  the web. I would appreciate some kernel packager
integrating it into the fedora 11 stock kernel - since without it I can
not build (and trust!) a silent cooling system.

Any plans on this issue?

regards

Christoph


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From dwmw2 at infradead.org  Thu Oct 29 12:18:30 2009
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 29 Oct 2009 12:18:30 +0000
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <1256783158.32634.0@localhost.localdomain>
References: <1256783158.32634.0@localhost.localdomain>
Message-ID: <1256818710.9814.150.camel@macbook.infradead.org>

On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote:
> On 09-10-28 18:24:49, Josh Boyer wrote:
> > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
> > >Sorry to bug developers, but I didn't get any bites from PPC
> > >users on fedora-list.
> > >
> > >Does Fedora PPC work or install on oldworld PCI Macs, such as
> > >a beige G3 desktop?  My impression is that no one has tried it
> > >on an oldworld
> > 
> > 
> > No, it doesn't.  The ppc specific release notes cover that here:
> > 
> > http://docs.fedoraproject.org/release-notes/f11/en-US/
> > index.html#sect-Release_Notes-Hardware_Requirements
> 
> I'd looked at the release notes.  They says "Minimum CPU: PowerPC 
> G3..." and "Although Old World machines should work, they require a 
> special bootloader which is not included in the Fedora distribution."  
> My question is whether anyone has tried it in any recent Fedora
> release and knows whether "should" means "do" or "don't".
> 
> (FWIW, the special bootloader is BootX, and Debian Lenny is installing 
> now, so /some/ form of Linux works.  I just don't know anything but 
> hearsay about Debian.  I see it uses "apt".)

I don't know of anyone who's tried it recently, but in the past we've
fixed things in the kernel to make it work properly on OldWorld Macs and
it _has_ been known to work fine.

It _ought_ to work if you sort out the bootloader.

-- 
dwmw2



From paul at city-fan.org  Thu Oct 29 12:35:36 2009
From: paul at city-fan.org (Paul Howarth)
Date: Thu, 29 Oct 2009 12:35:36 +0000
Subject: httpd run directory permissions in F12/11
In-Reply-To: 
References: 
Message-ID: <4AE98C18.9020102@city-fan.org>

On 29/10/09 11:29, Clodoaldo Neto wrote:
> I've been using Fedora 10 and while trying F12 beta I noticed a
> problem in the httpd run directory permission. Then I tried F11 and
> the same problem happens:
>
> [Wed Oct 28 12:05:02 2009] [notice] Apache/2.2.13 (Unix) DAV/2
> PHP/5.2.9 mod_python/3.3.1 Python/2.6 mod_ssl/2.2.13
> OpenSSL/0.9.8k-fips mod_wsgi/2.6 mod_perl/2.0.4 Perl/v5.10.0
> configured -- resuming normal operations
> [Wed Oct 28 12:05:09 2009] [error] [client 10.0.2.15] (13)Permission
> denied: mod_wsgi (pid=2722): Unable to connect to WSGI daemon process
> 'mygroup' on '/etc/httpd/run/wsgi.2692.0.1.sock' after multiple
> attempts.
>
> The problem is that until F10 the httpd socket directory was /var/run/
> and in F11 and F12 it is /var/run/httpd:
>
> # ll /etc/httpd/run
> lrwxrwxrwx. 1 root root 19 2009-10-28 11:04 /etc/httpd/run ->
> ../../var/run/httpd
>
> # ll -d /var/run/httpd
> drwx------. 2 root root 4096 2009-10-28 11:51 /var/run/httpd
>
> # ll -d /var/run
> drwxr-xr-x. 31 root root 4096 2009-10-28 11:35 /var/run
>
> # ll /var/run/httpd/
> total 4
> -rw-r--r--. 1 root   root 5 2009-10-28 12:05 httpd.pid
> srwx------. 1 apache root 0 2009-10-28 12:05 wsgi.2692.0.1.sock
>
> That can break some apache modules like mod_wsgi which rely on sockets.
>
> Any of these solve the problem:
>
> # chmod o+x /var/run/httpd
> # chown apache.root /var/run/httpd
>
> Is there a reason for the /var/run/httpd permissions to be as in
> F11/12 ? Is it necessary to have the user intervention to fix it? I
> have posted at the mod_wsgi list:
>
> http://groups.google.com/group/modwsgi/t/c5f5abc122088478

I had exactly the same problem with mod_fcgid and ended up creating a 
separate socket directory /var/run/mod_fcgid with appropriate 
permissions instead of following /etc/httpd/run.

If you create a directory matching /var/run/mod_.* with suitable 
permissions and include that directory in your package then it should 
get the right SELinux context set so that it will work out of the box.

Paul.



From liangsuilong at gmail.com  Thu Oct 29 13:09:06 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Thu, 29 Oct 2009 21:09:06 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: 

To Adam Williamson

I have upgraded the latest packages from Rawhide, including xorg-x11-drv-ati
and some components of X. It looks quite good. Glxgears performance grows
from about 640 fps to more than 1000 fps. Gnome-terminal is more smooth but
not perfect.

I found other problems in Fedora 12. I do not know whether they are related
to ATi KMS and opensource dirvers or not.

First Problem:

Adobe flash player seems to take up too much cpu usage. It makes machine run
slow. If I open too many web page full of flash, no matter in chromium or in
firefox, It is too slow. I almost can not do anything. Firefox looks a
little better than chormium. maybe there is a bug of chromium , or adobe
flash player or ATi's driver. I can not make sure. I test on another desktop
(NVIDIA card). It looks better. CPU usage is still very high, however, flash
player runs enough smoothly. And then, Tom 'spot' Callaway has not pushed a
new upgrade for chromium browser. But I do not want to disturbing him. I
just wait for him silently. Haha!

Second Problem:

I try to hibernate my desktop. Later I wake them up. The brightness of LCD
screen is not normal. It is too low. I nearly can not see what is it in the
screen. I switch to tty console. It is the same with GUI environment. My
screen is LG L1953T 19" inch flat screen. Is the bug related to ATi drivers?

At last, Thanks to developers again.


-- 
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liangsuilong at gmail.com  Thu Oct 29 13:09:06 2009
From: liangsuilong at gmail.com (Liang Suilong)
Date: Thu, 29 Oct 2009 21:09:06 +0800
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
Message-ID: 

To Adam Williamson

I have upgraded the latest packages from Rawhide, including xorg-x11-drv-ati
and some components of X. It looks quite good. Glxgears performance grows
from about 640 fps to more than 1000 fps. Gnome-terminal is more smooth but
not perfect.

I found other problems in Fedora 12. I do not know whether they are related
to ATi KMS and opensource dirvers or not.

First Problem:

Adobe flash player seems to take up too much cpu usage. It makes machine run
slow. If I open too many web page full of flash, no matter in chromium or in
firefox, It is too slow. I almost can not do anything. Firefox looks a
little better than chormium. maybe there is a bug of chromium , or adobe
flash player or ATi's driver. I can not make sure. I test on another desktop
(NVIDIA card). It looks better. CPU usage is still very high, however, flash
player runs enough smoothly. And then, Tom 'spot' Callaway has not pushed a
new upgrade for chromium browser. But I do not want to disturbing him. I
just wait for him silently. Haha!

Second Problem:

I try to hibernate my desktop. Later I wake them up. The brightness of LCD
screen is not normal. It is too low. I nearly can not see what is it in the
screen. I switch to tty console. It is the same with GUI environment. My
screen is LG L1953T 19" inch flat screen. Is the bug related to ATi drivers?

At last, Thanks to developers again.


-- 
http://www.liangsuilong.info
Fight for freedom!!!!(3F?
Ask not what your Linux distro can do for you!
Ask what you can do for your Linux distro!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From clodoaldo.pinto.neto at gmail.com  Thu Oct 29 13:20:36 2009
From: clodoaldo.pinto.neto at gmail.com (Clodoaldo Neto)
Date: Thu, 29 Oct 2009 11:20:36 -0200
Subject: httpd run directory permissions in F12/11
In-Reply-To: <4AE98C18.9020102@city-fan.org>
References: 
	<4AE98C18.9020102@city-fan.org>
Message-ID: 

2009/10/29 Paul Howarth :
> On 29/10/09 11:29, Clodoaldo Neto wrote:
>>
>> I've been using Fedora 10 and while trying F12 beta I noticed a
>> problem in the httpd run directory permission. Then I tried F11 and
>> the same problem happens:
>>
>> [Wed Oct 28 12:05:02 2009] [notice] Apache/2.2.13 (Unix) DAV/2
>> PHP/5.2.9 mod_python/3.3.1 Python/2.6 mod_ssl/2.2.13
>> OpenSSL/0.9.8k-fips mod_wsgi/2.6 mod_perl/2.0.4 Perl/v5.10.0
>> configured -- resuming normal operations
>> [Wed Oct 28 12:05:09 2009] [error] [client 10.0.2.15] (13)Permission
>> denied: mod_wsgi (pid=2722): Unable to connect to WSGI daemon process
>> 'mygroup' on '/etc/httpd/run/wsgi.2692.0.1.sock' after multiple
>> attempts.
>>
>> The problem is that until F10 the httpd socket directory was /var/run/
>> and in F11 and F12 it is /var/run/httpd:
>>
>> # ll /etc/httpd/run
>> lrwxrwxrwx. 1 root root 19 2009-10-28 11:04 /etc/httpd/run ->
>> ../../var/run/httpd
>>
>> # ll -d /var/run/httpd
>> drwx------. 2 root root 4096 2009-10-28 11:51 /var/run/httpd
>>
>> # ll -d /var/run
>> drwxr-xr-x. 31 root root 4096 2009-10-28 11:35 /var/run
>>
>> # ll /var/run/httpd/
>> total 4
>> -rw-r--r--. 1 root ? root 5 2009-10-28 12:05 httpd.pid
>> srwx------. 1 apache root 0 2009-10-28 12:05 wsgi.2692.0.1.sock
>>
>> That can break some apache modules like mod_wsgi which rely on sockets.
>>
>> Any of these solve the problem:
>>
>> # chmod o+x /var/run/httpd
>> # chown apache.root /var/run/httpd
>>
>> Is there a reason for the /var/run/httpd permissions to be as in
>> F11/12 ? Is it necessary to have the user intervention to fix it? I
>> have posted at the mod_wsgi list:
>>
>> http://groups.google.com/group/modwsgi/t/c5f5abc122088478
>
> I had exactly the same problem with mod_fcgid and ended up creating a
> separate socket directory /var/run/mod_fcgid with appropriate permissions
> instead of following /etc/httpd/run.
>
> If you create a directory matching /var/run/mod_.* with suitable permissions
> and include that directory in your package then it should get the right
> SELinux context set so that it will work out of the box.

Thanks for the workaround. But then what is the point of having a
default httpd run directory as a symlink in the /etc/httpd directory?
I could just set /var/run or run/.. as the socket directory avoiding
the extra work and future maintenance of creating a directory.

What I mean is why restrict the httpd run directory read permission to
root if apache will run as the apache user and not as root?

Regards, Clodoaldo

>
> Paul.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From christoph.frieben at googlemail.com  Thu Oct 29 13:30:16 2009
From: christoph.frieben at googlemail.com (Christoph Frieben)
Date: Thu, 29 Oct 2009 14:30:16 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <20091029092026.GB25682@mother.pipebreaker.pl>
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
Message-ID: 

2009/10/29 Tomasz Torcz:
> ?There was a change to font properties which changed "Best shapes"
> to turn on slight hinting.

Good point, but I wonder why this change has been made. It suffices to
look at two attachments to

  https://bugzilla.redhat.com/show_bug.cgi?id=198082

namely

  https://bugzilla.redhat.com/attachment.cgi?id=351609
  https://bugzilla.redhat.com/attachment.cgi?id=351613

which demonstrate that medium hinting used to give better results,
namely for MS fonts. However, this holds at least for Luxi Mono, too ,
the traditional Red Hat/Fedora monospaced default font.
To me, even the current system font looks blurred and uneven when
slight hinting is chosen instead of medium one. ~C



From pknirsch at redhat.com  Thu Oct 29 13:40:29 2009
From: pknirsch at redhat.com (Phil Knirsch)
Date: Thu, 29 Oct 2009 14:40:29 +0100
Subject: 2009-10-22 - Power Management Test Day report
Message-ID: <4AE99B4D.3060002@redhat.com>

Here a short report from the Power Management Fedora Test day on 
10/22/09 [1]. First of all many thanks to all the people who 
participated in it and who reported their findings. In order to make 
things easier for testers and to make sure we get a lot more stable and 
comparable results Marcela Maslanova, Jan Vcelak and Petr Lautrbach put 
together a rpm that consisted of all our test scripts, an easy 
call-script to easily run them and a "collect" script to pack together 
all results. Additionally the rpm itself has requirements against all 
the packages we needed for the tests, so a simple installation of the 
testday rpm provided a solid and easy method for every tester. This 
worked out really well and made test results very consistent. 
Unfortunately time ran out for including the automatic upload script 
from Mike McGrath and the ALPM test script, but that didn't seem to pose 
a big problem, roughly half of the testers provided results for ALPM as 
well.

We got 30 results overall with half of them including ALPM test results, 
too. Overall the results showed us what we wanted to know:

  - The tools we're shipping are working as expected, no crashes or 
anything like that observed
  - Wakeups and system behavior in genereral in comparison to our Fedora 
11 test day doesn't show any regressions
  - New features seem to be working as expected

Rudolf Kastel discovered one strange bug with one of the profiles which 
we couldn't reproduce yet, but we're still investigating with him.

All in all the whole test day was a real success. Especially the great 
idea of Marcela, Jan and Petr to make a rpm for the testday which 
automated a lot of the work that needed to be done.

For the next testday we already plan to expand that idea and include the 
automated upload script which will make it even easier for the testers.

[1] https://fedoraproject.org/wiki/Test_Day:2009-10-22

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch 
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From mike at cchtml.com  Thu Oct 29 13:48:14 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 29 Oct 2009 08:48:14 -0500
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <4AE99B4D.3060002@redhat.com>
References: <4AE99B4D.3060002@redhat.com>
Message-ID: <4AE99D1E.6040601@cchtml.com>

Phil Knirsch wrote:
> 
> All in all the whole test day was a real success. Especially the great
> idea of Marcela, Jan and Petr to make a rpm for the testday which
> automated a lot of the work that needed to be done.
> 
> For the next testday we already plan to expand that idea and include the
> automated upload script which will make it even easier for the testers.
> 


I would have participated if I could have run Rawhide from my USB drive,
but it seems test day images are no longer created and the USB drive I
was trying to use kept overheating after attempting to update from Beta
2 to the latest rawhide (several hundred packages). It's my own fault
for using a shoddy drive, but are test images no longer being made? Even
though I do have a slew of machines, I'm not privileged enough to have a
completely unused machine to install rawhide full time on. Next time
I'll attempt using a external HDD USB drive, which should have more success.



From mschmidt at redhat.com  Thu Oct 29 13:51:23 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 29 Oct 2009 14:51:23 +0100
Subject: Feature request: AMD K10 thermal sensors
In-Reply-To: <1256816304.2552.3.camel@choeger5.umpa.netz>
References: <1256816304.2552.3.camel@choeger5.umpa.netz>
Message-ID: <4AE99DDB.80105@redhat.com>

Dne 29.10.2009 12:38, Christoph H?ger napsal(a):
> since a year or so the AMD K10 thermal sensors module (k10temp) seems to
> be floating around  the web. I would appreciate some kernel packager
> integrating it into the fedora 11 stock kernel - since without it I can
> not build (and trust!) a silent cooling system.
>
> Any plans on this issue?

AMD K10 sensors support has been repeatedly refused by upstream 
lm_sensors developers because of the sensors' unreliability.

e.g. Rudolf Marek said in LKML on 2009-08-28:
> There is a problem that all chips of fam10h have some errata which renders the
> monitoring driver unusable. Some people proposed a workaround if temps look too
> suspicious to refuse to load. This is against a sense of monitoring to refuse
> the values where they don't look "right". So there is no driver.

Michal



From choeger at cs.tu-berlin.de  Thu Oct 29 14:08:44 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 29 Oct 2009 15:08:44 +0100
Subject: Feature request: AMD K10 thermal sensors
In-Reply-To: <4AE99DDB.80105@redhat.com>
References: <1256816304.2552.3.camel@choeger5.umpa.netz>
	<4AE99DDB.80105@redhat.com>
Message-ID: <1256825324.3433.0.camel@choeger5.umpa.netz>

Am Donnerstag, den 29.10.2009, 14:51 +0100 schrieb Michal Schmidt:
> Dne 29.10.2009 12:38, Christoph H?ger napsal(a):
> > since a year or so the AMD K10 thermal sensors module (k10temp) seems to
> > be floating around  the web. I would appreciate some kernel packager
> > integrating it into the fedora 11 stock kernel - since without it I can
> > not build (and trust!) a silent cooling system.
> >
> > Any plans on this issue?
> 
> AMD K10 sensors support has been repeatedly refused by upstream 
> lm_sensors developers because of the sensors' unreliability.
> 
> e.g. Rudolf Marek said in LKML on 2009-08-28:
> > There is a problem that all chips of fam10h have some errata which renders the
> > monitoring driver unusable. Some people proposed a workaround if temps look too
> > suspicious to refuse to load. This is against a sense of monitoring to refuse
> > the values where they don't look "right". So there is no driver.

So this means there is no chance to get my thermal sensors working under
fedora? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From john.brown009 at gmail.com  Thu Oct 29 14:14:17 2009
From: john.brown009 at gmail.com (TK009)
Date: Thu, 29 Oct 2009 10:14:17 -0400
Subject: [Announcement]Bug Triage Event 2009-10-30 @ 1600-2000 UTC
	(1200-1600 hours EDT)
Message-ID: <20091029141417.GA2447@blackhare>

When: Friday, 2009-10-30 @ 16:00-20:00 UTC (1200-1600 hours EDT)
Where: #fedora-qa on irc.freenode.net
F-12 Blocker Meeting may still be in session (more than likely) in 
#fedora-bugzappers, so we will be gathering in #fedora-qa.

The Bug Zappers will be holding a bug triage event this Friday (tomorrow) and 
would like to invite any and all that are interested in lending a hand to join 
us.
Our goal for this event is to review and triage Fedora 10 bug reports still in 
the status of 'NEW' with the aim of confirming and re-versioning or closing 
where approriate. This is an effort to put 'eyes' on these reports before EOL 
(End Of Life) changes close them.

whether your just curoius about the triage process or have questions and would 
like to learn more. This is an oppertunity to do so.
Maybe you like help filing a bug report? We're happy to help.

Everyone is welcome!

I hope to see you there
Edward (tk009)



From mmaslano at redhat.com  Thu Oct 29 14:15:50 2009
From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=)
Date: Thu, 29 Oct 2009 14:15:50 -0000
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <4AE99D1E.6040601@cchtml.com>
References: <4AE99B4D.3060002@redhat.com> <4AE99D1E.6040601@cchtml.com>
Message-ID: <8EA0BF74.4060706@redhat.com>

On 10/29/2009 02:48 PM, Michael Cronenworth wrote:
> Phil Knirsch wrote:
>   
>> All in all the whole test day was a real success. Especially the great
>> idea of Marcela, Jan and Petr to make a rpm for the testday which
>> automated a lot of the work that needed to be done.
>>
>> For the next testday we already plan to expand that idea and include the
>> automated upload script which will make it even easier for the testers.
>>
>>     
>
> I would have participated if I could have run Rawhide from my USB drive,
> but it seems test day images are no longer created and the USB drive I
> was trying to use kept overheating after attempting to update from Beta
> 2 to the latest rawhide (several hundred packages). It's my own fault
> for using a shoddy drive, but are test images no longer being made? Even
> though I do have a slew of machines, I'm not privileged enough to have a
> completely unused machine to install rawhide full time on. Next time
> I'll attempt using a external HDD USB drive, which should have more success.
>
>   
We were thinking about some image, but for measurement we
needed installed system. Anyway requirements for tests were huge
e.g. openoffice, kernel-debuginfo.

-- 
Marcela Ma?l??ov?
BaseOS team Brno



From dululu at gmail.com  Thu Oct 29 14:21:25 2009
From: dululu at gmail.com (Dululu Ululu)
Date: Thu, 29 Oct 2009 16:21:25 +0200
Subject: Feature request: Adding device ID to kernel option driver
Message-ID: <7e6367140910290721i54c9beabn5cefec427ee163e@mail.gmail.com>

Hi

I've got a wireless CDMA modem that works perfectly using the option usb
serial driver, but is not currently listed as one of the supported devices.
I've been manually adding its ID to option.c and recompiling the driver
since F8. This however means that each time I perform a kernel upgrade I
lose internet connectivity until I've done this. It also means that
yum-presto won't do a delta upgrade of the kernel since it's contents have
changed, I have to download the full package (CDMA cell network, can get
pretty expensive).

 Do I get this added to the Fedora kernel first or should I send it
upstream? Any pointers as to the procedures to follow (links to
documentation detailing who to contact etc would be most appreciated).

Thanks

Dululu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mike at cchtml.com  Thu Oct 29 14:24:30 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 29 Oct 2009 09:24:30 -0500
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <8EA0BF74.4060706@redhat.com>
References: <4AE99B4D.3060002@redhat.com> <4AE99D1E.6040601@cchtml.com>
	<8EA0BF74.4060706@redhat.com>
Message-ID: <4AE9A59E.8080306@cchtml.com>

Marcela Ma?l??ov? on 10/29/2045 08:17 AM wrote:
> We were thinking about some image, but for measurement we
> needed installed system. Anyway requirements for tests were huge
> e.g. openoffice, kernel-debuginfo.
> 

When you use a USB drive you can install any number of packages. Just
set your test-day.rpm to Require: openoffice and people could do so.



From josef at toxicpanda.com  Thu Oct 29 14:25:47 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Thu, 29 Oct 2009 10:25:47 -0400
Subject: Feature request: Adding device ID to kernel option driver
In-Reply-To: <7e6367140910290721i54c9beabn5cefec427ee163e@mail.gmail.com>
References: <7e6367140910290721i54c9beabn5cefec427ee163e@mail.gmail.com>
Message-ID: <1b7401870910290725v67629b5bue90a9e8d4052edb5@mail.gmail.com>

On Thu, Oct 29, 2009 at 10:21 AM, Dululu Ululu  wrote:
> Hi
>
> I've got a wireless CDMA modem that works perfectly using the option usb
> serial driver, but is not currently listed as one of the supported devices.
> I've been manually adding its ID to option.c and recompiling the driver
> since F8. This however means that each time I perform a kernel upgrade I
> lose internet connectivity until I've done this. It also means that
> yum-presto won't do a delta upgrade of the kernel since it's contents have
> changed, I have to download the full package (CDMA cell network, can get
> pretty expensive).
>
> ?Do I get this added to the Fedora kernel first or should I send it
> upstream? Any pointers as to the procedures to follow (links to
> documentation detailing who to contact etc would be most appreciated).
>

Send the patch upstream.  You can read this for instructions on how to
send a patch

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD

Thanks,

Josef



From john.brown009 at gmail.com  Thu Oct 29 14:26:24 2009
From: john.brown009 at gmail.com (TK009)
Date: Thu, 29 Oct 2009 10:26:24 -0400
Subject: disregard my last email. Worng list, very sorry.
Message-ID: <20091029142624.GC2447@blackhare>

brain lock on my annnouncement email. wrong list.


TK009



From nicolas.mailhot at laposte.net  Thu Oct 29 14:34:06 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Oct 2009 15:34:06 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
Message-ID: <117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>



Le Jeu 29 octobre 2009 14:30, Christoph Frieben a ?crit :
>
> 2009/10/29 Tomasz Torcz:
>> ?There was a change to font properties which changed "Best shapes"
>> to turn on slight hinting.
>
> Good point, but I wonder why this change has been made. It suffices to
> look at two attachments to
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=198082
>
> namely
>
>   https://bugzilla.redhat.com/attachment.cgi?id=351609
>   https://bugzilla.redhat.com/attachment.cgi?id=351613
>
> which demonstrate that medium hinting used to give better results,
> namely for MS fonts.

It is well known that some old fonts like Microsoft core fonts have bad/buggy
hinting (MS hides the problem by adding font-specific workarounds in its text
stack). They should certainly never be used to evaluate if a general default
is good or not.

(that is also something to consider before activating the patented bytecode
engine: in-fonts hints are not necessarily better than what freetype
auto-computes in many cases)

> However, this holds at least for Luxi Mono, too ,
> the traditional Red Hat/Fedora monospaced default font.

Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the
distribution.

> To me, even the current system font looks blurred and uneven when
> slight hinting is chosen instead of medium one. ~C

Unfortunately it is very difficult to get two people to agree on the right
hinting level.

-- 
Nicolas Mailhot




From SteveD at redhat.com  Thu Oct 29 14:58:23 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Thu, 29 Oct 2009 10:58:23 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091028224238.GA8084@bludgeon.org>
References: <4AE5B378.1000507@RedHat.com>
		<4AE89491.4030303@RedHat.com>
	<20091028224238.GA8084@bludgeon.org>
Message-ID: <4AE9AD8F.1030407@RedHat.com>



On 10/28/2009 06:42 PM, Ray Van Dolson wrote:
>>> If, for whatever reason, I need to export a file system that doesn't 
>>> live in /export, would I still be able to mount it?
>> With the '/ *(ro,fsid=0)' entry, Yes, you would be able to mount other
>> exported directories.. 
>>
>> With the '/export *(ro,fsid=0)' entry, No, the client will only see 
>> directories under '/export'. The rest of the filesystem would not be
>> seen...
> 
> I suppose you could bind mount that other directory to be inside of
> /export though and expose it that way?
I guess... but then you might have to had the crossmnt export option..

steved.



From ndbecker2 at gmail.com  Thu Oct 29 14:58:43 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 29 Oct 2009 10:58:43 -0400
Subject: texlive 2009 - should set TEXMFCNF?
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: 

Jindrich Novy wrote:

> On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
>> Jindrich Novy wrote:
>> 
>> > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
>> >> I wonder if texlive should include a /etc/profile.d package to set
>> >> TEXMFCNF,
>> >> so that other packages, such as xdvipdfmx will work?  Or, should
>> >> texlive just obsolete xdvipdfmx and include it's own version?
>> > 
>> > I will try to fix it in the texmf.cnf kpathsea configuration file
>> > directly in the new TL2009 update.
>> > 
>> > Jindrich
>> > 
>> Could you explain?
> 
> The plan was to update the texmf.cnf to tell kpathsea to look for
> files in the /usr/share/texmf tree prior to the main TL2009 tree. This
> should make the utilities like xdvipdfmx work even though they are
> linked against old kpathsea and expects configuration bits in
> /usr/share/texmf.
> 
>> Will you replace the current xdvipdfmx?
> 
> Currently I'm trying to not to replace any package that has a separate
> upstream and is already packaged separatelly in Fedora.
> 
> Jindrich
> 
I am maintainer for xdvipdfmx and would be perfectly happy if you adopt it.



From gmaxwell at gmail.com  Thu Oct 29 15:17:05 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Thu, 29 Oct 2009 11:17:05 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to 
	happen
In-Reply-To: <4AE5D8AA.2050503@RedHat.com>
References: <4AE5B378.1000507@RedHat.com> 
	<4AE5D8AA.2050503@RedHat.com>
Message-ID: 

On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson  wrote:
> On a pre F-12 Server:
> ? 2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and
> ? ? ?reset the exports with 'exportfs -arv' (see exports(5) for details).


*Please* stop recommending this to people.

This is a myopic configuration change which will violate the security
assumptions of almost any system out there.   It's not what
practically anyone wants. Arguably the exports tool should even
prohibit this kind of configuration unless you set some
yes-I-really-intend-to-be-completely-insecure knob, it's certainly not
something that should be recommended as a fix for "help! nfs stopped
working when I upgrade to F13".



From SteveD at redhat.com  Thu Oct 29 15:17:54 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Thu, 29 Oct 2009 11:17:54 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: <20091028190514.B7E231D3@magilla.sf.frob.com>
References: <4AE5B378.1000507@RedHat.com>
		<4AE89491.4030303@RedHat.com>
	<20091028190514.B7E231D3@magilla.sf.frob.com>
Message-ID: <4AE9B222.2060905@RedHat.com>



On 10/28/2009 03:05 PM, Roland McGrath wrote:
> It sounds like you are saying that there is no way to export the same
> host filesystems with the same client-perceived names under v4 as was
> being done before under v[23].  Is that really true?
With Pre-F12 servers... Yeah... 

The V4 protocol requires a 'pseudo root' to be defined. Other servers simply 
make '/' the pseudo root which allows all exports just to work with all versions.
The Linux server have the feature of being able to define the pseudo root with 
the use of the 'fsid=0' export option. A feature none of the other servers 
have. 

Unfortunately, there was no forethought as to what happens when a
pseudo root is not defined, until recently... Patches in both the
F-12 kernel and rpc.mountd now dynamically allocate a pseudo root
when one is not defined... Basically meaning '/' becomes the pseudo 
root when there is no fsid=0 export option.

> 
> My old /etc/exports is:
> 
> /mirror                        *(ro,insecure,sync,mp,all_squash)
> 
> So clients mount server:/mirror to see my /mirror directory's contents.
> No other /foo directory is exported or visible at all to clients, and
> that's how it should stay.
> 
> How do I get the same results for v4 clients?
Use a F-12 server or added the '/ *(ro,fsid=0)' export entry like:

/                              *(ro,fsid=0)
/mirror                        *(ro,insecure,sync,mp,all_squash)


steved.-



From SteveD at redhat.com  Thu Oct 29 15:20:21 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Thu, 29 Oct 2009 11:20:21 -0400
Subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to
 happen
In-Reply-To: 
References: <4AE5B378.1000507@RedHat.com>
		<4AE5D8AA.2050503@RedHat.com>
	
Message-ID: <4AE9B2B5.3090503@RedHat.com>



On 10/29/2009 11:17 AM, Gregory Maxwell wrote:
> On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson  wrote:
>> On a pre F-12 Server:
>>   2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and
>>      reset the exports with 'exportfs -arv' (see exports(5) for details).
> 
> 
> *Please* stop recommending this to people.
> 
> This is a myopic configuration change which will violate the security
> assumptions of almost any system out there.   It's not what
> practically anyone wants. Arguably the exports tool should even
> prohibit this kind of configuration unless you set some
> yes-I-really-intend-to-be-completely-insecure knob, it's certainly not
> something that should be recommended as a fix for "help! nfs stopped
> working when I upgrade to F13".
> 
I guess I just have confidence that people understand what
they are doing... sorry...

steved.
 



From vpivaini at cs.helsinki.fi  Thu Oct 29 15:31:37 2009
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Thu, 29 Oct 2009 17:31:37 +0200
Subject: httpd run directory permissions in F12/11
In-Reply-To: 
References: 
Message-ID: <1256830297.2095.0.camel@lightweight>

to, 2009-10-29 kello 09:29 -0200, Clodoaldo Neto kirjoitti:
> I've been using Fedora 10 and while trying F12 beta I noticed a
> problem in the httpd run directory permission. Then I tried F11 and
> the same problem happens:

I've opened a bug about this a while ago -
https://bugzilla.redhat.com/show_bug.cgi?id=495780

-- 
Ville-Pekka Vainio



From christoph.frieben at googlemail.com  Thu Oct 29 16:21:16 2009
From: christoph.frieben at googlemail.com (Christoph Frieben)
Date: Thu, 29 Oct 2009 17:21:16 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
Message-ID: 

2009/10/29 Nicolas Mailhot:
> It is well known that some old fonts like Microsoft core fonts have bad/buggy
> hinting (MS hides the problem by adding font-specific workarounds in its text
> stack). They should certainly never be used to evaluate if a general default
> is good or not.

The empirical result remains, however, and it is consistent with that
of any other
font that I have looked at.

> Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the
> distribution.

It was the default monospaced font for RHL 8/9, Fedora Core 1/2/3/4/5/6,
RHEL 3/4/5 and still **is** for current RHEL 5.4. I thus consider legitimate to
comment on it, too, as I expect to be not the only person being attached
to using it ..

> Unfortunately it is very difficult to get two people to agree on the right
> hinting level.

I find the effect quite deterring and was actually bothered by it before even
getting aware that the default hinting had been altered.
Any feedback by other users is thus welcome in order to rule out a single
user impression. Finally, I'd be interested to know why the hinting has been
changed at all. There is no bug ID or any factual reason given in the
changelog of package gnome-settings-daemon. ~C



From dakingun at gmail.com  Thu Oct 29 16:52:18 2009
From: dakingun at gmail.com (Deji Akingunola)
Date: Thu, 29 Oct 2009 12:52:18 -0400
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
Message-ID: 

On Thu, Oct 29, 2009 at 12:21 PM, Christoph Frieben
 wrote:
> 2009/10/29 Nicolas Mailhot:

> The empirical result remains, however, and it is consistent with that
> of any other
> font that I have looked at.
>
>> Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the
>> distribution.
>
> It was the default monospaced font for RHL 8/9, Fedora Core 1/2/3/4/5/6,
> RHEL 3/4/5 and still **is** for current RHEL 5.4. I thus consider legitimate to
> comment on it, too, as I expect to be not the only person being attached
> to using it ..
>
The Luxi fonts I think you were referring to were removed in F-9 due
to licensing concerns ( Bug 317641).

Deji



From nicolas.mailhot at laposte.net  Thu Oct 29 16:59:46 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Oct 2009 17:59:46 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
Message-ID: <9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>



Le Jeu 29 octobre 2009 17:21, Christoph Frieben a ?crit :

> The empirical result remains, however, and it is consistent with that
> of any other font that I have looked at.

It is consistent for you. You'd need a massive test campaign to prove this is
not subjective, not limited to a specific set of fonts, a particular
hardware/screen resolution/dpi, etc. The internet is littered with opinions on
font rendering that all disagree with each other.

>> Luxi Mono is not the Red Hat/Fedora monospaced font and is not even in the
>> distribution.
>
> It was the default monospaced font for RHL 8/9, Fedora Core 1/2/3/4/5/6,
> RHEL 3/4/5 and still **is** for current RHEL 5.4. I thus consider legitimate
> to
> comment on it, too, as I expect to be not the only person being attached
> to using it ..

You may comment on it, but do not expect Fedora to care over-much about a
component that was removed in Fedora 9 (4 release cycles ago, for legal
reasons so it has 0 chance to get back in). For RHEL please go through RHEL
channels.

-- 
Nicolas Mailhot




From martind1111 at gmail.com  Thu Oct 29 17:17:09 2009
From: martind1111 at gmail.com (Martin Dubuc)
Date: Thu, 29 Oct 2009 13:17:09 -0400
Subject: Wi-Fi Interface Question
Message-ID: <7a0107ba0910291017y4482ba76j502d280283d09437@mail.gmail.com>

How is it possible to figure out what driver is associated with which
interface. We used to have some of this information available in
/sys/config/hwconf. I am especially interested to know details of Wi-Fi
interfaces (for instance ath5k or iwlagn).

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jonathan.underwood at gmail.com  Thu Oct 29 17:26:25 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Oct 2009 17:26:25 +0000
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: <20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
Message-ID: <645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>

2009/10/29 Jindrich Novy :
> Currently I'm trying to not to replace any package that has a separate
> upstream and is already packaged separatelly in Fedora.
>

IMO I think we'd be better off adopting the texlive versions of the
packages, rather than doing a half-and-half job on this by packaging
individual upstreams. The reason being that Fedora then benefits from
the integration and testing work done by the texlive team. The texlive
xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream"
release.

J.



From jamatos at fc.up.pt  Thu Oct 29 17:36:59 2009
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Thu, 29 Oct 2009 17:36:59 +0000
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: <645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>
References: 
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
	<645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>
Message-ID: <200910291736.59539.jamatos@fc.up.pt>

On Thursday 29 October 2009 17:26:25 Jonathan Underwood wrote:
> IMO I think we'd be better off adopting the texlive versions of the
> packages, rather than doing a half-and-half job on this by packaging
> individual upstreams. The reason being that Fedora then benefits from
> the integration and testing work done by the texlive team. The texlive
> xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream"
> release.
> 
> J.

I am not sure if Jindrich is talking about this but the same could be said 
about the other pure latex packages. If the packages are available on texlive 
they could obsolete the previous versions available on Fedora.

-- 
Jos? Ab?lio



From jonathan.underwood at gmail.com  Thu Oct 29 17:42:30 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Oct 2009 17:42:30 +0000
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: <200910291736.59539.jamatos@fc.up.pt>
References: 
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
	<645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>
	<200910291736.59539.jamatos@fc.up.pt>
Message-ID: <645d17210910291042n7a721586jcb70cdca14d17904@mail.gmail.com>

2009/10/29 Jos? Matos :
> On Thursday 29 October 2009 17:26:25 Jonathan Underwood wrote:
>> IMO I think we'd be better off adopting the texlive versions of the
>> packages, rather than doing a half-and-half job on this by packaging
>> individual upstreams. The reason being that Fedora then benefits from
>> the integration and testing work done by the texlive team. The texlive
>> xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream"
>> release.
>>
>> J.
>
> I am not sure if Jindrich is talking about this but the same could be said
> about the other pure latex packages. If the packages are available on texlive
> they could obsolete the previous versions available on Fedora.

Agreed.



From christoph.frieben at googlemail.com  Thu Oct 29 17:44:51 2009
From: christoph.frieben at googlemail.com (Christoph Frieben)
Date: Thu, 29 Oct 2009 18:44:51 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
	<9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
Message-ID: 

2009/10/29 Nicolas Mailhot:
> You may comment on it, but do not expect Fedora to care overmuch about a
> component that was removed in Fedora 9 (4 release cycles ago, for legal
> reasons so it has 0 chance to get back in). For RHEL please go through RHEL
> channels.
>
> --
> Nicolas Mailhot

I had already pointed out that this issue also affects the current
default system font. Let's see what other people out there think about
this issue. It's not like you are the supreme judge in this matter,
and it's also not the first time that you show up as a hotspur on this
mailing list ..



From kevin.kofler at chello.at  Thu Oct 29 17:47:18 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Oct 2009 18:47:18 +0100
Subject: rawhide report: 20091029 changes
References: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>
Message-ID: 

Rawhide Report wrote:
> banshee-1.5.1-3.fc12.i686 requires mono(Mono.Zeroconf) = 0:4.0.0.90

mono-zeroconf somehow got backwards! Can the current version please go back 
in?

> blam-1.8.5-18.fc12.i686 requires gecko-libs = 0:1.9.1.3
> galeon-2.0.7-16.fc12.i686 requires gecko-libs = 0:1.9.1.3

These also went backwards. blam was already rebuilt in yesterday's Rawhide 
and is now broken, and I had a rebuild of galeon tagged which seems to have 
been replaced by an older build.

> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0

Not sure what went wrong here.

        Kevin Kofler



From awilliam at redhat.com  Thu Oct 29 17:48:56 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 10:48:56 -0700
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <20091029092026.GB25682@mother.pipebreaker.pl>
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
Message-ID: <1256838536.2314.30.camel@adam.local.net>

On Thu, 2009-10-29 at 10:20 +0100, Tomasz Torcz wrote:
> On Thu, Oct 29, 2009 at 09:49:13AM +0100, Christoph Frieben wrote:
> > I have the impression that since about 2 days ago the font rendering
> > in Fedora rawhide is less good than before. Fonts appear fuzzier, and
> > in particular Luxi Mono looks more deformed. There hasn't been a
> > freetype update, thus some GNOME package might be responsible.
> > I have noticed this effect on 2 different systems, one with an ATI
> 
>   There was a change to font properties which changed "Best shapes"
> to turn on slight hinting.

And why the hell are you still using Luxi Mono, anyway? that thing went
out with the ark...

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 29 18:07:06 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:07:06 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
	
Message-ID: <1256839626.2314.33.camel@adam.local.net>

On Thu, 2009-10-29 at 21:09 +0800, Liang Suilong wrote:

> I found other problems in Fedora 12. I do not know whether they are
> related to ATi KMS and opensource dirvers or not. 
> 
> 
> First Problem:
> 
> 
> Adobe flash player seems to take up too much cpu usage. It makes
> machine run slow. If I open too many web page full of flash, no matter
> in chromium or in firefox, It is too slow. I almost can not do
> anything. Firefox looks a little better than chormium. maybe there is
> a bug of chromium , or adobe flash player or ATi's driver. I can not
> make sure. I test on another desktop (NVIDIA card). It looks better.
> CPU usage is still very high, however, flash player runs enough
> smoothly. And then, Tom 'spot' Callaway has not pushed a new upgrade
> for chromium browser. But I do not want to disturbing him. I just wait
> for him silently. Haha!

How's this with the 'nomodeset' parameter?

> Second Problem:
> 
> 
> I try to hibernate my desktop. Later I wake them up. The brightness of
> LCD screen is not normal. It is too low. I nearly can not see what is
> it in the screen. I switch to tty console. It is the same with GUI
> environment. My screen is LG L1953T 19" inch flat screen. Is the bug
> related to ATi drivers?

Try running this command after resuming:

xgamma -r 1.0

does that do the trick?

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From kevin.kofler at chello.at  Thu Oct 29 18:06:13 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Oct 2009 19:06:13 +0100
Subject: rawhide report: 20091029 changes
References: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>
	
Message-ID: 

I wrote:

> Rawhide Report wrote:
>> banshee-1.5.1-3.fc12.i686 requires mono(Mono.Zeroconf) = 0:4.0.0.90
> 
> mono-zeroconf somehow got backwards! Can the current version please go
> back in?
> 
>> blam-1.8.5-18.fc12.i686 requires gecko-libs = 0:1.9.1.3
>> galeon-2.0.7-16.fc12.i686 requires gecko-libs = 0:1.9.1.3
> 
> These also went backwards. blam was already rebuilt in yesterday's Rawhide
> and is now broken, and I had a rebuild of galeon tagged which seems to
> have been replaced by an older build.

Looks like there are 2 different issues there:
* some ExcludeArch: sparc64 rebuilds from:
https://fedorahosted.org/rel-eng/ticket/2818
overwrote newer builds. Dennis Gilmore untagged the mono-zeroconf and blam 
builds which "went backwards", so tomorrow's Rawhide should have the current 
version again. (Hopefully there isn't other stuff which went backwards 
without noticing.)
* galeon and LabPlot somehow got tagged only dist-f12 and not f12-final. I 
wonder what other stuff is affected.

        Kevin Kofler



From awilliam at redhat.com  Thu Oct 29 18:07:55 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:07:55 -0700
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: <1256839626.2314.33.camel@adam.local.net>
References: 
	
	<1256839626.2314.33.camel@adam.local.net>
Message-ID: <1256839675.2314.34.camel@adam.local.net>

On Thu, 2009-10-29 at 11:07 -0700, Adam Williamson wrote:

> > Second Problem:
> > 
> > 
> > I try to hibernate my desktop. Later I wake them up. The brightness of
> > LCD screen is not normal. It is too low. I nearly can not see what is
> > it in the screen. I switch to tty console. It is the same with GUI
> > environment. My screen is LG L1953T 19" inch flat screen. Is the bug
> > related to ATi drivers?
> 
> Try running this command after resuming:
> 
> xgamma -r 1.0

sorry, make that:

xgamma -gamma 1.0

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 29 18:10:12 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:10:12 -0700
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <4AE99B4D.3060002@redhat.com>
References: <4AE99B4D.3060002@redhat.com>
Message-ID: <1256839812.2314.35.camel@adam.local.net>

On Thu, 2009-10-29 at 14:40 +0100, Phil Knirsch wrote:
> Here a short report from the Power Management Fedora Test day on 
> 10/22/09 [1]. First of all many thanks to all the people who 
> participated in it and who reported their findings.

> For the next testday we already plan to expand that idea and include the 
> automated upload script which will make it even easier for the testers.
> 
> [1] https://fedoraproject.org/wiki/Test_Day:2009-10-22

Thanks very much for running the Test Day and organizing it so expertly!
It's great to have the process running smoothly enough that we can get
events off the ground like this with almost no direct management being
done by QA, and great to know the system is valuable for you.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 29 18:13:59 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:13:59 -0700
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <4AE9A59E.8080306@cchtml.com>
References: <4AE99B4D.3060002@redhat.com> <4AE99D1E.6040601@cchtml.com>
	<8EA0BF74.4060706@redhat.com>  <4AE9A59E.8080306@cchtml.com>
Message-ID: <1256840039.2314.37.camel@adam.local.net>

On Thu, 2009-10-29 at 09:24 -0500, Michael Cronenworth wrote:
> Marcela Ma?l??ov? on 10/29/2045 08:17 AM wrote:
> > We were thinking about some image, but for measurement we
> > needed installed system. Anyway requirements for tests were huge
> > e.g. openoffice, kernel-debuginfo.
> > 
> 
> When you use a USB drive you can install any number of packages. 

Not exactly, you need enough spare memory and/or swap space, because
they get installed into 'memory'.

> Just
> set your test-day.rpm to Require: openoffice and people could do so.

Most people couldn't as they'd run out of RAM.

The fact that the organizers specified an installed system was required
is the reason I didn't bother spinning live images for this test day, it
seemed pointless given that fact.

We do still spin test day live images when they are useful/required. For
some events, though, we just link to the latest nightly live image, when
there's no need for any customization for the test day.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mike at cchtml.com  Thu Oct 29 18:15:58 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 29 Oct 2009 13:15:58 -0500
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <1256840039.2314.37.camel@adam.local.net>
References: <4AE99B4D.3060002@redhat.com>
	<4AE99D1E.6040601@cchtml.com>	<8EA0BF74.4060706@redhat.com>
	<4AE9A59E.8080306@cchtml.com>
	<1256840039.2314.37.camel@adam.local.net>
Message-ID: <4AE9DBDE.7090805@cchtml.com>

Adam Williamson on 10/29/2009 01:13 PM wrote:
> 
> Not exactly, you need enough spare memory and/or swap space, because
> they get installed into 'memory'.
> 

Not when you use persistent storage... I have an updated F11 USB stick
that would like to meet you. :)



From jkeating at redhat.com  Thu Oct 29 18:20:40 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Oct 2009 11:20:40 -0700
Subject: rawhide report: 20091029 changes
In-Reply-To: 
References: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>
	
Message-ID: <1256840440.2268.58.camel@localhost.localdomain>

On Thu, 2009-10-29 at 18:47 +0100, Kevin Kofler wrote:
> Rawhide Report wrote:
> > banshee-1.5.1-3.fc12.i686 requires mono(Mono.Zeroconf) = 0:4.0.0.90
> 
> mono-zeroconf somehow got backwards! Can the current version please go back 
> in?

Dennis is looking at this.  Seems something went awry when he was making
changes for a secondary arch.

> 
> > blam-1.8.5-18.fc12.i686 requires gecko-libs = 0:1.9.1.3
> > galeon-2.0.7-16.fc12.i686 requires gecko-libs = 0:1.9.1.3
> 
> These also went backwards. blam was already rebuilt in yesterday's Rawhide 
> and is now broken, and I had a rebuild of galeon tagged which seems to have 
> been replaced by an older build. 

These appear to be fixed now.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

From awilliam at redhat.com  Thu Oct 29 18:30:10 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:30:10 -0700
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
	<9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
Message-ID: <1256841010.2314.43.camel@adam.local.net>

On Thu, 2009-10-29 at 17:59 +0100, Nicolas Mailhot wrote:
> 
> Le Jeu 29 octobre 2009 17:21, Christoph Frieben a ?crit :
> 
> > The empirical result remains, however, and it is consistent with that
> > of any other font that I have looked at.
> 
> It is consistent for you. You'd need a massive test campaign to prove this is
> not subjective, not limited to a specific set of fonts, a particular
> hardware/screen resolution/dpi, etc. The internet is littered with opinions on
> font rendering that all disagree with each other.

Of course, given the above, it's an interesting question why we're going
around changing the defaults in post-Beta phase.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From awilliam at redhat.com  Thu Oct 29 18:44:21 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Thu, 29 Oct 2009 11:44:21 -0700
Subject: 2009-10-22 - Power Management Test Day report
In-Reply-To: <4AE9DBDE.7090805@cchtml.com>
References: <4AE99B4D.3060002@redhat.com> <4AE99D1E.6040601@cchtml.com>
	<8EA0BF74.4060706@redhat.com> <4AE9A59E.8080306@cchtml.com>
	<1256840039.2314.37.camel@adam.local.net> <4AE9DBDE.7090805@cchtml.com>
Message-ID: <1256841861.2314.54.camel@adam.local.net>

On Thu, 2009-10-29 at 13:15 -0500, Michael Cronenworth wrote:
> Adam Williamson on 10/29/2009 01:13 PM wrote:
> > 
> > Not exactly, you need enough spare memory and/or swap space, because
> > they get installed into 'memory'.

> Not when you use persistent storage... I have an updated F11 USB stick
> that would like to meet you. :)

Hmm, point. I kinda thought persistent storage was only for /home
though? IMBW. If so, we'll reconsider for future test days.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From nicolas.mailhot at laposte.net  Thu Oct 29 18:48:04 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Oct 2009 19:48:04 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
	<9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
	
Message-ID: <34433d10df70217bf37650435c0be711.squirrel@arekh.dyndns.org>



Le Jeu 29 octobre 2009 18:44, Christoph Frieben a ?crit :
>
> 2009/10/29 Nicolas Mailhot:
>> You may comment on it, but do not expect Fedora to care overmuch about a
>> component that was removed in Fedora 9 (4 release cycles ago, for legal
>> reasons so it has 0 chance to get back in). For RHEL please go through RHEL
>> channels.

> I had already pointed out that this issue also affects the current
> default system font. Let's see what other people out there think about
> this issue. It's not like you are the supreme judge in this matter,
> and it's also not the first time that you show up as a hotspur on this
> mailing list ..

Why stop to this mailing list? It seems my nefarious influence extends much
wider!

http://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages_(2008-07-24)

http://www.advogato.org/person/yosch/diary.html?start=61
http://lintian.debian.org/tags/duplicate-font-file.html
http://lintian.debian.org/tags/font-in-non-font-package.html

Abandon hope all ye are surrounded

-- 
Nicolas Mailhot




From kevin.kofler at chello.at  Thu Oct 29 18:48:12 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Oct 2009 19:48:12 +0100
Subject: rawhide report: 20091029 changes
References: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>
	
Message-ID: 

I wrote:

> Rawhide Report wrote:
>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
> 
> Not sure what went wrong here.

I figured it out. mono-ndoc very "cleverly" encodes the date it was built 
into Mono's equivalent of a soname! So a simple rebuild at a later date, 
even with nothing changed, will change its ABI version. Yay! :-(

I'm rebuilding nant and will file a tag request shortly. But in the long 
run, somebody ought to fix mono-ndoc!

        Kevin Kofler



From cemeyer at u.washington.edu  Thu Oct 29 18:49:01 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Thu, 29 Oct 2009 11:49:01 -0700
Subject: Feature request: AMD K10 thermal sensors
In-Reply-To: <1256825324.3433.0.camel@choeger5.umpa.netz>
References: <1256816304.2552.3.camel@choeger5.umpa.netz>
	<4AE99DDB.80105@redhat.com>
	<1256825324.3433.0.camel@choeger5.umpa.netz>
Message-ID: <200910291149.01680.cemeyer@u.washington.edu>

On Thursday 29 October 2009 07:08:44 am Christoph H?ger wrote:
> Am Donnerstag, den 29.10.2009, 14:51 +0100 schrieb Michal Schmidt:
> > Dne 29.10.2009 12:38, Christoph H?ger napsal(a):
> > > since a year or so the AMD K10 thermal sensors module (k10temp) seems
> > > to be floating around  the web. I would appreciate some kernel packager
> > > integrating it into the fedora 11 stock kernel - since without it I can
> > > not build (and trust!) a silent cooling system.
> > >
> > > Any plans on this issue?
> >
> > AMD K10 sensors support has been repeatedly refused by upstream
> > lm_sensors developers because of the sensors' unreliability.
> >
> > e.g. Rudolf Marek said in LKML on 2009-08-28:
> > > There is a problem that all chips of fam10h have some errata which
> > > renders the monitoring driver unusable. Some people proposed a
> > > workaround if temps look too suspicious to refuse to load. This is
> > > against a sense of monitoring to refuse the values where they don't
> > > look "right". So there is no driver.
> 
> So this means there is no chance to get my thermal sensors working under
> fedora?

Perhaps see if RPMFusion will carry the kmod.

Regards,
-- 
Conrad Meyer 



From kevin.kofler at chello.at  Thu Oct 29 18:56:04 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Oct 2009 19:56:04 +0100
Subject: rawhide report: 20091029 changes
References: <20091029110643.GA26271@releng2.fedora.phx.redhat.com>
	 
Message-ID: 

I wrote:

> I wrote:
> 
>> Rawhide Report wrote:
>>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
>> 
>> Not sure what went wrong here.
> 
> I figured it out. mono-ndoc very "cleverly" encodes the date it was built
> into Mono's equivalent of a soname! So a simple rebuild at a later date,
> even with nothing changed, will change its ABI version. Yay! :-(
> 
> I'm rebuilding nant and will file a tag request shortly. But in the long
> run, somebody ought to fix mono-ndoc!

A rebuild of nant failed, some error with log4net:
http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log

Can somebody experienced with Mono please look at this?

        Kevin Kofler



From tcallawa at redhat.com  Thu Oct 29 19:08:42 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Oct 2009 15:08:42 -0400
Subject: Fwd: Request to update ATi OSS driver for Fedora 12
In-Reply-To: 
References: 
	
Message-ID: <4AE9E83A.1010100@redhat.com>

On 10/29/2009 09:09 AM, Liang Suilong wrote:
> And then, Tom 'spot' Callaway has not pushed a new upgrade for chromium
> browser. But I do not want to disturbing him. I just wait for him
> silently. Haha!

There is a reason for the delay:

http://spot.livejournal.com/311443.html

The good news is that there is a workaround fix now, so as soon as the
last package finishes building (I've already done smoke tests on F-11
and F-12), there will be newer chromium packages in the repo. No idea if
it fixes your problem or not, Flash is proprietary software, I can't
debug it, much less fix it.

~spot



From ndbecker2 at gmail.com  Thu Oct 29 19:28:52 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 29 Oct 2009 15:28:52 -0400
Subject: texlive 2009 - should set TEXMFCNF?
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
	
Message-ID: 

Neal Becker wrote:

> Jindrich Novy wrote:
> 
>> On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
>>> Jindrich Novy wrote:
>>> 
>>> > On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
>>> >> I wonder if texlive should include a /etc/profile.d package to set
>>> >> TEXMFCNF,
>>> >> so that other packages, such as xdvipdfmx will work?  Or, should
>>> >> texlive just obsolete xdvipdfmx and include it's own version?
>>> > 
>>> > I will try to fix it in the texmf.cnf kpathsea configuration file
>>> > directly in the new TL2009 update.
>>> > 
>>> > Jindrich
>>> > 
>>> Could you explain?
>> 
>> The plan was to update the texmf.cnf to tell kpathsea to look for
>> files in the /usr/share/texmf tree prior to the main TL2009 tree. This
>> should make the utilities like xdvipdfmx work even though they are
>> linked against old kpathsea and expects configuration bits in
>> /usr/share/texmf.
>> 
>>> Will you replace the current xdvipdfmx?
>> 
>> Currently I'm trying to not to replace any package that has a separate
>> upstream and is already packaged separatelly in Fedora.
>> 
>> Jindrich
>> 
> I am maintainer for xdvipdfmx and would be perfectly happy if you adopt
> it.
> 
s/adopt/obsolete



From pjones at redhat.com  Thu Oct 29 20:00:17 2009
From: pjones at redhat.com (Peter Jones)
Date: Thu, 29 Oct 2009 16:00:17 -0400
Subject: Wi-Fi Interface Question
In-Reply-To: <7a0107ba0910291017y4482ba76j502d280283d09437@mail.gmail.com>
References: <7a0107ba0910291017y4482ba76j502d280283d09437@mail.gmail.com>
Message-ID: <4AE9F451.2090500@redhat.com>

On 10/29/2009 01:17 PM, Martin Dubuc wrote:
> How is it possible to figure out what driver is associated with which
> interface. We used to have some of this information available in
> /sys/config/hwconf. I am especially interested to know details of Wi-Fi
> interfaces (for instance ath5k or iwlagn).

"lshal" will show this info, among mountains of other data.

-- 
        Peter

Teach a man to use food stamps, he'll eat for a day.  Teach a man to *forge*
food stamps, he'll eat for a lifetime.
		-- Dossy



From joost at cnoc.nl  Thu Oct 29 20:06:35 2009
From: joost at cnoc.nl (Joost van der Sluis)
Date: Thu, 29 Oct 2009 21:06:35 +0100
Subject: Including windows-binary files for cross compiling into package
In-Reply-To: <4AE5F9FE.9090506@cchtml.com>
References: <1256579896.23821.186.camel@wsjoost.cnoc.lan>
	<20091026181502.919B02747@magilla.sf.frob.com>
	<1256582576.23821.193.camel@wsjoost.cnoc.lan>
	<4AE5F9FE.9090506@cchtml.com>
Message-ID: <1256846795.12377.4.camel@wsjoost.cnoc.lan>

On Mon, 2009-10-26 at 14:35 -0500, Michael Cronenworth wrote:

> Joost van der Sluis on 10/26/2009 01:42 PM wrote:
> > 
> > Those files are not architecture independent. They are somewhat similar
> > to .o files. They contain the run time library for the language,
> > compiled to native windows object files. If you want to compile your own
> > program with them afterwards, they are linked together into a windows
> > executable.
> > 
> > You could argue that they should belong in a -devel package. But since
> > this package is a compiler, we decided not to split it up into a devel
> > package and a non-devel package. As that would be pointless, as one will
> > not work without the other.
> > 



> They should follow mingw's footsteps, shouldn't they?
> 
> /usr/i686-pc-mingw32/sys-root/mingw/lib
> equals

/usr/x86_64-pc-fpc/sys-root/fpc/lib

That's an idea, but then we would be incompatible with upstream. I can
try to patch the configuration files of fpc so that it searches for
these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the
'standard' location. Also because other packages based in fpc relay on
that.

And what I've read here is that this path is chosen because mingw needs
a root filesystem location. Fpc does not need that, so I think I keep
the default locations, if that's ok.

Regards,

Joost.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ngompa13 at gmail.com  Thu Oct 29 20:41:57 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 29 Oct 2009 15:41:57 -0500
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <1256818710.9814.150.camel@macbook.infradead.org>
References: <1256783158.32634.0@localhost.localdomain>
	<1256818710.9814.150.camel@macbook.infradead.org>
Message-ID: <8278b1b0910291341y7ab9de84la18d640f7562d3d2@mail.gmail.com>

On Thu, Oct 29, 2009 at 7:18 AM, David Woodhouse wrote:

> On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote:
> > On 09-10-28 18:24:49, Josh Boyer wrote:
> > > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
> > > >Sorry to bug developers, but I didn't get any bites from PPC
> > > >users on fedora-list.
> > > >
> > > >Does Fedora PPC work or install on oldworld PCI Macs, such as
> > > >a beige G3 desktop?  My impression is that no one has tried it
> > > >on an oldworld
> > >
> > >
> > > No, it doesn't.  The ppc specific release notes cover that here:
> > >
> > > http://docs.fedoraproject.org/release-notes/f11/en-US/
> > > index.html#sect-Release_Notes-Hardware_Requirements
> >
> > I'd looked at the release notes.  They says "Minimum CPU: PowerPC
> > G3..." and "Although Old World machines should work, they require a
> > special bootloader which is not included in the Fedora distribution."
> > My question is whether anyone has tried it in any recent Fedora
> > release and knows whether "should" means "do" or "don't".
> >
> > (FWIW, the special bootloader is BootX, and Debian Lenny is installing
> > now, so /some/ form of Linux works.  I just don't know anything but
> > hearsay about Debian.  I see it uses "apt".)
>
> I don't know of anyone who's tried it recently, but in the past we've
> fixed things in the kernel to make it work properly on OldWorld Macs and
> it _has_ been known to work fine.
>
> It _ought_ to work if you sort out the bootloader.
>
> --
> dwmw2
>
>
If Mac OS isn't bootable, then you need to use quik (
http://penguinppc.org/bootloaders/quik/ ) instead of BootX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alsadi at gmail.com  Thu Oct 29 22:22:40 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 30 Oct 2009 00:22:40 +0200
Subject: bug solved, we can now make an rpm for xul sqlite-manager
Message-ID: <385866f0910291522h7fdfb673wa37663c24df20241@mail.gmail.com>

hello,

I tried to make an rpm package for  xul sqlite-manager

it's a xul app and a firefox plugin (forget about the plugin)

http://code.google.com/p/sqlite-manager/downloads/list

http://sqlite-manager.googlecode.com/files/SQLiteManager_XR_0.5.6.zip

there was a problem, and it's solved now
http://code.google.com/p/sqlite-manager/issues/detail?id=309

I suggest we make an rpm for it and add it to the repos

what does it do ?
it's a simple desktop/personal database application using sqlite and xulrunner

it can be used where kile or oo.o-base does not fit like livecd

how to pack it ?
make a simple .spec file with %install like this
xulrunner --install-app %{S:1} ${RPM_BUILD_ROOT}/%{_datadir}/%{name}
mkdir -p ${RPM_BUILD_ROOT}/%{_bindir}/
ln %{_datadir}/%{name}/sqlite-manager/sqlite-manager
${RPM_BUILD_ROOT}/%{_bindir}/%{name}

what do you think ?



From jonstanley at gmail.com  Thu Oct 29 23:00:39 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 29 Oct 2009 19:00:39 -0400
Subject: Plan for tomorrow's (20091030) FESCo meeting
Message-ID: 

Following are the topics for tomorrow's FESCo meeting, taking place at
17:00UTC in #fedora-meeting on irc.freenode.net

264 Prohibit packages which require non-free, legally unacceptable, or
binary only content to be functional

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.



From kevin.kofler at chello.at  Fri Oct 30 02:19:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Oct 2009 03:19:55 +0100
Subject: Plan for tomorrow's (20091030) FESCo meeting
References: 
Message-ID: 

Jon Stanley wrote:
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor.

I just filed:
https://fedorahosted.org/fesco/ticket/265 (maintainer issue)
oget refuses to enable fluidsynth's PulseAudio backend

        Kevin Kofler



From tonynelson at georgeanelson.com  Fri Oct 30 02:40:07 2009
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Thu, 29 Oct 2009 22:40:07 -0400
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <1256818710.9814.150.camel@macbook.infradead.org> (from
	dwmw2@infradead.org on Thu Oct 29 08:18:30 2009)
Message-ID: <1256870407.5145.1@localhost.localdomain>

On 09-10-29 08:18:30, David Woodhouse wrote:
> On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote:
> > On 09-10-28 18:24:49, Josh Boyer wrote:
> > > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
> > > >Sorry to bug developers, but I didn't get any bites from PPC
> > > >users on fedora-list.
> > > >
> > > >Does Fedora PPC work or install on oldworld PCI Macs, such as
> > > >a beige G3 desktop?  My impression is that no one has tried it
> > > >on an oldworld
> > > 
> > > 
> > > No, it doesn't.  The ppc specific release notes cover that here:
> > > 
> > > http://docs.fedoraproject.org/release-notes/f11/en-US/
> > > index.html#sect-Release_Notes-Hardware_Requirements
> > 
> > I'd looked at the release notes.  They says "Minimum CPU: PowerPC 
> > G3..." and "Although Old World machines should work, they require a 
> > special bootloader which is not included in the Fedora
> > distribution."  My question is whether anyone has tried it in any 
> > recent Fedora release and knows whether "should" means "do" or 
> > "don't".
> > 
> > (FWIW, the special bootloader is BootX, and Debian Lenny is 
> > installing now, so /some/ form of Linux works.  I just don't know  
> > anything but hearsay about Debian.  I see it uses "apt".)
> 
> I don't know of anyone who's tried it recently, but in the past we've
> fixed things in the kernel to make it work properly on OldWorld Macs
> and it _has_ been known to work fine.

I received a reply off-list from someone who did sucessfully install 
F11 on an oldworld Mac.


> It _ought_ to work if you sort out the bootloader.

I was able to get a Debian Lenny install working (after sorting out the 
bootloader :-), so I am encouraged.

-- 
____________________________________________________________________
TonyN.:'                       
      '                              




From tonynelson at georgeanelson.com  Fri Oct 30 02:40:44 2009
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Thu, 29 Oct 2009 22:40:44 -0400
Subject: Fedora PPC for oldworld Mac?
In-Reply-To: <8278b1b0910291341y7ab9de84la18d640f7562d3d2@mail.gmail.com>
	(from ngompa13@gmail.com on Thu Oct 29 16:41:57 2009)
Message-ID: <1256870444.5145.2@localhost.localdomain>

On 09-10-29 16:41:57, King InuYasha wrote:
> On Thu, Oct 29, 2009 at 7:18 AM, David Woodhouse
> wrote:
> 
> > On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote:
> > > On 09-10-28 18:24:49, Josh Boyer wrote:
> > > > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote:
> > > > >Sorry to bug developers, but I didn't get any bites from PPC
> > > > >users on fedora-list.
> > > > >
> > > > >Does Fedora PPC work or install on oldworld PCI Macs, such as
> > > > >a beige G3 desktop?  My impression is that no one has tried it
> > > > >on an oldworld
> > > >
> > > >
> > > > No, it doesn't.  The ppc specific release notes cover that 
> > > > here:
> > > >
> > > > http://docs.fedoraproject.org/release-notes/f11/en-US/
> > > > index.html#sect-Release_Notes-Hardware_Requirements
> > >
> > > I'd looked at the release notes.  They says "Minimum CPU: PowerPC
> > > G3..." and "Although Old World machines should work, they require
> > > a special bootloader which is not included in the Fedora
> > > distribution."  My question is whether anyone has tried it in any 
> > > recent Fedora release and knows whether "should" means "do" or 
> > > "don't".
> > >
> > > (FWIW, the special bootloader is BootX, and Debian Lenny is
> > > installing now, so /some/ form of Linux works.  I just don't know 
> > > anything but hearsay about Debian.  I see it uses "apt".)
> >
> > I don't know of anyone who's tried it recently, but in the past
> > we've fixed things in the kernel to make it work properly on 
> > OldWorld Macs and it _has_ been known to work fine.
> >
> If Mac OS isn't bootable, then you need to use quik (
> http://penguinppc.org/bootloaders/quik/ ) instead of BootX.

I don't think that would help fix the unbootable MacOS, but in any
case quik doesn't work if Linux is installed on a drive not the boot 
drive, as it is here.

-- 
____________________________________________________________________
TonyN.:'                       
      '                              



From rawhide at fedoraproject.org  Fri Oct 30 10:36:09 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 30 Oct 2009 10:36:09 +0000
Subject: rawhide report: 20091030 changes
Message-ID: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 30 06:15:14 UTC 2009

Broken deps for i386
----------------------------------------------------------
	gnome-applet-timer-2.1.2-4.fc12.i686 requires gnome-audio
	1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0



Broken deps for x86_64
----------------------------------------------------------
	gnome-applet-timer-2.1.2-4.fc12.x86_64 requires gnome-audio
	1:nant-0.85-30.fc12.x86_64 requires mono(NDoc.Core) = 0:1.3.3498.0



Broken deps for ppc
----------------------------------------------------------
	gnome-applet-timer-2.1.2-4.fc12.ppc requires gnome-audio



Broken deps for ppc64
----------------------------------------------------------
	gnome-applet-timer-2.1.2-4.fc12.ppc64 requires gnome-audio



New package javatar
        Java tar archive io package
New package knm-new-fixed-fonts
        12x12 JIS X 0208 Bitmap fonts
New package perl-Makefile-DOM
        Simple DOM parser for Makefiles
New package qbrew
        A Brewing Recipe Calculator
Updated Packages:

LabPlot-1.6.0.2-8.fc12
----------------------
* Wed Oct 28 2009 Kevin Kofler  - 1.6.0.2-8
- fix FTBFS with current GSL (GSL_CONST_CGSM_GAUSS undefined, patch from Debian)

* Sat Oct 24 2009 Kevin Kofler  - 1.6.0.2-7
- drop ExcludeArch ppc64, OCaml is available for ppc64 these days

* Tue Sep 22 2009 Dennis Gilmore  - 1.6.0.2-6
- ExcludeArch s390 s390x and sparc64 no ocaml

* Fri Jul 24 2009 Fedora Release Engineering  - 1.6.0.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Mon Feb 23 2009 Fedora Release Engineering  - 1.6.0.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild


abiword-2.8.1-1.fc12
--------------------
* Thu Oct 29 2009 Marc Maurer  - 1:2.8.1-1
- New upstream release

* Mon Oct 26 2009 Marc Maurer  - 1:2.8.0-1
- New upstream release

* Mon Oct 26 2009 Marc Maurer  - 1:2.8.0-2
- Build with --enable-dynamic


audacious-plugins-2.1-10.fc12
-----------------------------
* Thu Oct 29 2009 Michael Schwendt  - 2.1-10
- Remove decode_thread from sndfile plugin to fix playback.

* Mon Oct 26 2009 Michael Schwendt  - 2.1-9
- Let buffer_time_min in underruns patch depend on default buffer size.

* Sun Oct 25 2009 Michael Schwendt  - 2.1-8
- Patch modplug plugin to remove old cruft and fix playback.


avogadro-1.0.0-1.fc12
---------------------
* Thu Oct 29 2009 Sebastian Dziallas  1.0.0-1
- update to new upstream release


biniax-1.2-7.fc12
-----------------
* Mon Oct 26 2009 Simon Wesp  - 1.2-7
- Re-import to Fedora


blam-1.8.5-19.fc12
------------------
* Tue Oct 27 2009 Jan Horak  - 1.8.5-19
- Rebuild against newer gecko


bluez-4.56-1.fc12
-----------------
* Sat Oct 10 2009 Bastien Nocera  4.56-1
- Update to 4.56

* Fri Oct 09 2009 Bastien Nocera  4.55-3
- Update cable pairing plugin to use libudev

* Wed Oct 07 2009 Bastien Nocera  4.55-2
- Enable caps lowering


brltty-4.1-1.fc12
-----------------
* Wed Oct 28 2009 Stepan Kasal  - 4.1-1
- new upstream version
- use --disable-stripping instead of make variable override
- install the default brltty-pm.conf to docdir only (#526168)
- remove the duplicate copies of rhmkboot and rhmkroot from docdir
- patch configure so that the dirs in summary are not garbled:
  brltty-autoconf-quote.patch

* Tue Oct 20 2009 Stepan Kasal  - 4.0-2
- escape rpm macros in the rpm change log
- add requires to bind subpackages from one build together

* Wed Oct 07 2009 Stepan Kasal  - 4.0-1
- new upstream version
- drop upstreamed patches; ./autogen not needed anymore
- pack the xbrlapi server; move its man page to brlapi package
- add man-page for brltty.conf (#526168)


control-center-2.28.1-4.fc12
----------------------------
* Thu Oct 29 2009 Bastien Nocera  2.28.1-4
- Fix metacity keybindings showing up under compiz


empathy-2.28.1.1-3.fc12
-----------------------
* Thu Oct 29 2009 Matthias Clasen  - 2.28.1.1-3
- Escape notifications
- Fix a crash due to refcounting issues


evince-2.28.1-5.fc12
--------------------
* Thu Oct 29 2009 Marek Kasik  - 2.28.1-5
- Add backported patch evince-aspect-ratio.patch (#531430).
- Preserve aspect ratio of scaled pages and set page orientation
- automatically (gnome bugs #599468 and #599470)


fedora-logos-12.0.3-1.fc12
--------------------------
* Thu Oct 29 2009 Tom "spot" Callaway  - 12.0.3-1
- Update to 12.0.3, yet another name for system-software-install icons


file-roller-2.28.1-2.fc12
-------------------------
* Thu Oct 29 2009 Matthias Clasen  2.28.1-2
- Fix sticky DND


galeon-2.0.7-16.fc12.1
----------------------
* Wed Oct 28 2009 Kevin Kofler  - 2.0.7-16.1
- Rebuild for new xulrunner (1.9.1.4)


gambas2-2.17.0-1.fc12
---------------------
* Thu Oct 29 2009 Tom "spot" Callaway  - 2.17.0-1
- update to 2.17.0


gcc-4.4.2-7.fc12
----------------
* Tue Oct 27 2009 Jakub Jelinek  4.4.2-7
- update from gcc-4_4-branch
  - PRs c++/40808, c/41842, cp-tools/39177
- VTA backports
  - PR bootstrap/41345
- don't emit DW_AT_name:  etc. into debug info
  (#530304, PR debug/41828)
- power7 ABI fixes (PR target/41787)
- fix ICE in ix86_pic_register_p (PR target/41762)

* Thu Oct 22 2009 Jakub Jelinek  4.4.2-6
- update from gcc-4_4-branch
  - PR target/41702
  - fix a pod2man error in gcc.1 (#530102)
  - fix mangling of very large names
- document -print-multi-os-directory in gcc.info and gcc.1
  (#529659, PR other/25507)

* Mon Oct 19 2009 Jakub Jelinek  4.4.2-5
- update from gcc-4_4-branch
  - PR fortran/41755
  - s390 z10 tuning fixes
- provide accurate attributes for powerpc builtins (PR target/23983)
- fix -fcompare-debug differences caused by DCE removal of debug stmts
- fix updating of speculation status with VTA (PR debug/41739)


gdesklets-0.36.1-7.fc12
-----------------------
* Thu Oct 29 2009 Luya Tshimbalanga  0.36.1-7
- Add patch to address compatibility with python 2.6


gnome-applet-timer-2.1.2-4.fc12
-------------------------------
* Thu Oct 29 2009 Christoph Wickert  - 2.1.2-4
- Require gnome-audio (#531877)


gnome-panel-2.28.0-12.fc12
--------------------------
* Thu Oct 29 2009 Matthias Clasen  2.28.0-12
- Make padding work correctly in non-expanded panels (#529614)


gnome-power-manager-2.28.1-5.fc12
---------------------------------
* Thu Oct 29 2009 Bastien Nocera  2.28.1-5
- Fix OSD showing a volume label when switching compositing off

* Wed Oct 28 2009 Bastien Nocera  2.28.1-4
- Match gnome-settings-daemon's positioning for the OSD

* Tue Oct 27 2009 Bastien Nocera  2.28.1-3
- Update OSD to match gnome-settings-daemon's


isdn4k-utils-3.2-67.fc12
------------------------
* Wed Oct 28 2009 Than Ngo  - 3.2-67
- drop useless BR libXp-devel


jasper-1.900.1-14.fc12
----------------------
* Thu Oct 29 2009 Rex Dieter  - 1.900.1-14
- add pkgconfig support


lat-1.2.3-10.fc12
-----------------
* Wed Oct 28 2009 Paul Howarth  1.2.3-10
- Fix deprecation warnings and port to new GtkTooltip API
- Build/Require gtk-sharp2 >= 2.12.0 for new GtkTooltip API
- Add upstream patch for FileSystemWatcher watches
- Add upstream patch for fixing crashes when adding objects
- Update icon cache scriptlets to current best practice
- Scrollkeeper obsoleted by rarian-compat; scriplets now redundant
- Don't need to own directory %{_datadir}/gnome (owned by filesystem)
- Don't need to own directory %{_datadir}/gnome/help (owned by yelp)
- Don't generate mono provides for private plugins
- Add bugzilla reference for ExcludeArch sparc64 (#531451)


libchamplain-0.4.2-1.fc12
-------------------------
* Thu Oct 29 2009 Debarshi Ray  - 0.4.2-1
- Version bump to 0.4.2.
  * Fixed acceptable values of "decel-rate". (GNOME Bugzilla #595552)
  * Fixed GObject Introspection build failure. (GNOME Bugzilla #598942)
  * http://download.gnome.org/sources/libchamplain/0.4/libchamplain-0.4.2.news
  * http://download.gnome.org/sources/libchamplain/0.4/libchamplain-0.4.2.changes

* Mon Oct 19 2009 Debarshi Ray  - 0.4.1-1
- Version bump to 0.4.1.
  * Added champlain_view_remove_layer.
  * ChamplainSelectionLayer now has a "changed" signal.
  * Added champlain_marker_get_highlighted_text_color,
    champlain_marker_set_highlighted_text_color and
    Added champlain_marker_get_highlighted_color.
  * Fixed slowdowns with big caches.
  * Don't emit invalid latitude and longitude notifications.
  * Ensure map is displayed in Eye of GNOME's champlain plugin. (GNOME
    Bugzilla #598106)
  * http://download.gnome.org/sources/libchamplain/0.4/libchamplain-0.4.1.news
  * http://download.gnome.org/sources/libchamplain/0.4/libchamplain-0.4.1.changes

- Enabled GObject Introspection, and added 'Requires: gobject-introspection'
  and 'BuildRequires: gir-repository-devel'. Patched to fix build failure.
  (GNOME Bugzilla #598942)
- Explicitly disabled debug code.
- RPaths fixed by upstream. Removed 'BuildRequires: chrpath'.


libguestfs-1.0.75-1.fc12
------------------------
* Thu Oct 29 2009 Richard W.M. Jones  - 1.0.75-1
- New upstream release 1.0.75.
- New library: libhivex.
- New tools: virt-win-reg, hivexml, hivexget.
- Don't require chntpw.


moblin-icon-theme-0.9-1.fc12
----------------------------
* Thu Oct 29 2009 Peter Robinson  0.9-1
- New upstream 0.9 release


mono-zeroconf-0.9.0-2.fc12
--------------------------

openoffice.org-3.1.1-19.14.fc12
-------------------------------
* Wed Oct 28 2009 Caol?n McNamara  - 1:3.1.1-19.14
- Resolves: ooo#103757 custom shape cut and paste (caolanm)
- Resolves: rhbz#529746 crash on exit after loading .ppt (caolanm)
- Resolves: rhbz#531554 add workspace.chart41.patch (caolanm)

* Mon Oct 19 2009 Caol?n McNamara  - 1:3.1.1-19.13
- Resolves: ooo#105988 a11y crash in impress (caolanm)
- Related: rhbz#529521 add openoffice.org-3.2.0.oooXXXXXX.vcl.dontresolve.patch
  (caolanm)

* Thu Oct 15 2009 Caol?n McNamara  - 1:3.1.1-19.12
- Resolves: rhbz#528409 [si_LK] Default font in oowriter is not
  Language Default (LKLUG), but DejaVu Sans (dtardon)
- Resolves: rhbz#529127 [Indic][Various] Default font in oowriter is
  not Language Default (Lohit or Other), but DejaVu Sans (dtardon)


openssh-5.2p1-30.fc12
---------------------
* Thu Oct 29 2009 Jan F. Chadima  - 5.2p1-30
- Modify the init script to prevent it to hang during generating the keys (#515145)


pam-1.1.0-6.fc12
----------------
* Thu Oct 29 2009 Tomas Mraz  1.1.0-6
- pam_xauth: set the approprate context when creating .xauth files (#531530)


perl-Array-Compare-2.01-1.fc12
------------------------------
* Mon Oct 05 2009 Stepan Kasal  - 2.01-1
- new upstream version, BR perl(Moose)


perl-Authen-SASL-2.13-1.fc12
----------------------------
* Mon Oct 05 2009 Stepan Kasal  - 2.13-1
- new upstream version, BR Test::More


perl-Business-ISBN-Data-20081208-1.fc12
---------------------------------------
* Mon Oct 05 2009 Stepan Kasal  - 20081208-1
- new upstream version


perl-Cache-Memcached-1.27-1.fc12
--------------------------------

perl-Class-Accessor-0.34-1.fc12
-------------------------------
* Mon Oct 05 2009 Stepan Kasal  - 0.34-1
- new upstream version


perl-Devel-Cycle-1.11-1.fc12
----------------------------
* Mon Oct 05 2009 Stepan Kasal  - 1.11-1
- new upstream version


perl-Devel-Symdump-2.08-1.fc12
------------------------------
* Mon Oct 05 2009 Stepan Kasal  - 1:2.08-1
- new upstream version


perl-File-Which-1.09-1.fc12
---------------------------
* Mon Oct 05 2009 Stepan Kasal  - 1.09-1
- new upstream version


perl-GD-2.44-2.fc12
-------------------
* Thu Oct 29 2009 Stepan Kasal  - 2.44-2
- give up tests on ppc

* Mon Oct 05 2009 Stepan Kasal  - 2.44-1
- new upstream version
- run tests always
- do not add bdf_scripts/ to docs
- switch off the test that fails in i686 koji


perl-MIME-Types-1.28-1.fc12
---------------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.28-1
- new upstream version


perl-Module-Find-0.08-1.fc12
----------------------------
* Wed Oct 07 2009 Stepan Kasal  - 0.08-1
- new upstream version


perl-PadWalker-1.9-1.fc12
-------------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.9-1
- new upstream version


perl-Parse-CPAN-Meta-1.40-1.fc12
--------------------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.40-1
- new upstream version


perl-SOAP-Lite-0.710.10-1.fc12
------------------------------
* Wed Oct 07 2009 Stepan Kasal  - 0.710.10-1
- new upstream release
- drop upstreamed patch
- add missing build requires
- use %filter-* macros


perl-String-Format-1.16-1.fc12
------------------------------
* Wed Oct 07 2009 Stepan Kasal  - 1.16-1
- new upstream release


perl-Test-CPAN-Meta-0.13-1.fc12
-------------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 0.13-1
- update to new upstream release


perl-Test-SubCalls-1.09-1.fc12
------------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 1.09-1
- update to new upstream release


perl-Text-CSV_XS-0.68-1.fc12
----------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 0.68-1
- update to new upstream release


perl-UNIVERSAL-can-1.15-1.fc12
------------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 1.15-1
- update to new upstream release


perl-UNIVERSAL-isa-1.03-1.fc12
------------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 1.03-1
- update to new upstream release


perl-UNIVERSAL-require-0.13-1.fc12
----------------------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 0.13-1
- update to new upstream release


perl-URI-1.40-1.fc12
--------------------
* Tue Oct 06 2009 Marcela Ma?l??ov?  - 1.40-1
- update to new upstream release


perl-XML-NamespaceSupport-1.10-1.fc12
-------------------------------------
* Tue Oct 06 2009 Marcela Ma?l??ov?  - 1.10-1
- update to new upstream release


perl-YAML-0.70-2.fc12
---------------------
* Wed Oct 07 2009 Marcela Ma?l??ov?  - 0.70-2
- rebuild for push

* Tue Oct 06 2009 Marcela Ma?l??ov?  - 0.70-1
- new upstream version


pyabiword-0.8.0-1.fc12
----------------------
* Mon Oct 26 2009 Marc Maurer  - 0.8.0-1
- New upstream release


pykickstart-1.64-1.fc12
-----------------------
* Wed Sep 30 2009 Chris Lumens  - 1.64-1
- Update the zfcp command for F12 (#526360).
- Move "make" to %build
LANG=C
export LANG
unset DISPLAY
 (#524215).


python-meh-0.6-1.fc12
---------------------
* Thu Oct 08 2009 Chris Lumens  - 0.6-1
- Make idSkipList work again.
- Support dumping objects derived from Python's object.
- Use the right method to set text on a snack.Entry (#526884).


quodlibet-2.1-3.fc12
--------------------
* Wed Oct 28 2009 Jeffrey C. Ollie  - 2.1-3
- Require gstreamer-plugins-good - BZ#531664


raptor-1.4.18-5.fc12
--------------------
* Thu Oct 29 2009 Orcan Ogetbil  - 1.4.18-5
- Fix multilib conflict (RHBZ#477342)


ruby-1.8.6.383-4.fc12
---------------------
* Thu Oct 29 2009 Mamoru Tasaka  - 1.8.6.383-4
- Use bison to regenerate parse.c to keep the original format of error
  messages (bug 530275 comment 4)

* Sun Oct 25 2009 Mamoru Tasaka  - 1.8.6.383-3
- Patch so that irb saves its history (bug 518584, ruby issue 1556)

* Sat Oct 24 2009 Mamoru Tasaka  - 1.8.6.383-2
- Update to 1.8.6 patchlevel 383 (bug 520063)


tcl-trf-2.1.4-1.fc12
--------------------
* Thu Oct 29 2009 Tom "spot" Callaway  - 2.1.4-1
- Update to 2.1.4


urw-fonts-2.4-9.fc12
--------------------
* Tue Oct 27 2009 Than Ngo  - 2.4-9
- fix #77314, invalid URL


wxGTK-2.8.10-6.fc12
-------------------
* Sun Oct 25 2009 Dan Hor?k  - 2.8.10-6
- add fix for wrong menubar height when using larger system font (#528376)


xemacs-21.5.29-6.fc12
---------------------
* Wed Oct 28 2009 Jerry James  - 21.5.29-6
- Bring back the courier font patch; that was a red herring.
- Really, seriously fix bz 512623 with a TTY font patch.
- Fix the version number in macros.xemacs.
- Build with bignum support.
- Turn off OSS support.


xemacs-packages-extra-20090217-4.fc12
-------------------------------------
* Thu Oct 29 2009 Jerry James  - 20090217-4
- Fix LaTeX BRs.
- Update apel-xemacs Provides.


xfburn-0.4.2-2.fc12
-------------------
* Fri Oct 30 2009 Christoph Wickert  - 0.4.2-2
- Fix infinite loop in blank disk dialog (#525515)
- Don't crash on burning ISO image (#525518)


xorg-x11-drv-nv-2.1.15-2.fc12
-----------------------------
* Wed Oct 28 2009 Adam Jackson  2.1.15-2
- nv-2.1.15-g80-nop-gamma.patch: Install a no-op gamma hook so we don't
  crash immediately on init.


yaboot-1.3.14-23.fc12
---------------------
* Thu Oct 29 2009 Roman Rakus  - 1.3.14-23
- When netbooting "clobber" the LOAD_BUFFER and move the kernel into it to make
  room for RTAS (#530330)
- Adding better netboot support more work on (#458438)


ypbind-1.20.4-20.fc12
---------------------
* Thu Oct 29 2009 Karel Klic  - 3:1.20.4-20
- Bind to domain even if not using NetworkManager
  The fix uses  only the code from upstream ypbind-mt-1.29.91
  Resolves: #531398


zyx-liveinstaller-0.1.16-1.fc12
-------------------------------
* Thu Oct 29 2009 Sebastian Dziallas  - 0.1.16-1
- update to new upstream release


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 70



From mcepl at redhat.com  Fri Oct 30 10:46:02 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 30 Oct 2009 11:46:02 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
References: 	<20091029092026.GB25682@mother.pipebreaker.pl>	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
Message-ID: <4AEAC3EA.90004@redhat.com>

Dne 29.10.2009 15:34, Nicolas Mailhot napsal(a):
> It is well known that some old fonts like Microsoft core fonts have bad/buggy
> hinting (MS hides the problem by adding font-specific workarounds in its text
> stack). They should certainly never be used to evaluate if a general default
> is good or not.
>
> (that is also something to consider before activating the patented bytecode
> engine: in-fonts hints are not necessarily better than what freetype
> auto-computes in many cases)

I don't think we should back progress in order to be friendly to buggy 
closed Microsoft fonts. I know they are quite common outside of the 
Linux world, but I think

a) our free fonts are now so good, that we could limit ourselves to this 
FSF-nirvana ghetto, it doesn't cost that much,
b) many modern fonts (e.g., my preferred Inconsolata) just rely on real 
hinting being present, and it doesn't work that well with auto-hinter. 
Just because of this font, I have switched to freefont-freeworld and I 
cannot be more happy with it.

Really looking forward to Behdad freeing us from the old freefont stuff.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

One reason that life is complex is that it has a real part and an
imaginary part.
     -- Andrew K?nig



From mcepl at redhat.com  Fri Oct 30 10:46:02 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Fri, 30 Oct 2009 11:46:02 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
References: 	<20091029092026.GB25682@mother.pipebreaker.pl>	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
Message-ID: <4AEAC3EA.90004@redhat.com>

Dne 29.10.2009 15:34, Nicolas Mailhot napsal(a):
> It is well known that some old fonts like Microsoft core fonts have bad/buggy
> hinting (MS hides the problem by adding font-specific workarounds in its text
> stack). They should certainly never be used to evaluate if a general default
> is good or not.
>
> (that is also something to consider before activating the patented bytecode
> engine: in-fonts hints are not necessarily better than what freetype
> auto-computes in many cases)

I don't think we should back progress in order to be friendly to buggy 
closed Microsoft fonts. I know they are quite common outside of the 
Linux world, but I think

a) our free fonts are now so good, that we could limit ourselves to this 
FSF-nirvana ghetto, it doesn't cost that much,
b) many modern fonts (e.g., my preferred Inconsolata) just rely on real 
hinting being present, and it doesn't work that well with auto-hinter. 
Just because of this font, I have switched to freefont-freeworld and I 
cannot be more happy with it.

Really looking forward to Behdad freeing us from the old freefont stuff.

Mat?j

-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

One reason that life is complex is that it has a real part and an
imaginary part.
     -- Andrew K?nig



From benny+usenet at amorsen.dk  Fri Oct 30 12:59:49 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Fri, 30 Oct 2009 13:59:49 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: <4AEAC3EA.90004@redhat.com> (=?utf-8?Q?=22Mat=C4=9Bj?= Cepl"'s
	message of "Fri, 30 Oct 2009 11:46:02 +0100")
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	<4AEAC3EA.90004@redhat.com>
Message-ID: 

Mat?j Cepl  writes:

> I don't think we should back progress in order to be friendly to buggy
> closed Microsoft fonts. I know they are quite common outside of the
> Linux world, but I think
>
> a) our free fonts are now so good, that we could limit ourselves to
> this FSF-nirvana ghetto, it doesn't cost that much,
> b) many modern fonts (e.g., my preferred Inconsolata) just rely on
> real hinting being present, and it doesn't work that well with
> auto-hinter. Just because of this font, I have switched to
> freefont-freeworld and I cannot be more happy with it.

It would be nice if fonts like Inconsolata somehow set a flag that they
require hinting. This would prevent the side effects on old fonts.

Your post prompted me to try out Inconsolata in F11. I do not find the
Inconsolata hinting all that impressive though. No hinting at all is
indeed horrible. With full hinting, the "g" gets deformed on my screen,
where it is quite good with medium hinting. The vertical stroke in the
"a" is quite wide and distracting no matter which hinting is chosen.

Back to DejaVu Sans Mono Book.


/Benny




From linville at redhat.com  Fri Oct 30 13:27:57 2009
From: linville at redhat.com (John W. Linville)
Date: Fri, 30 Oct 2009 09:27:57 -0400
Subject: Wi-Fi Interface Question
In-Reply-To: <7a0107ba0910291017y4482ba76j502d280283d09437@mail.gmail.com>
References: <7a0107ba0910291017y4482ba76j502d280283d09437@mail.gmail.com>
Message-ID: <20091030132757.GA23165@redhat.com>

On Thu, Oct 29, 2009 at 01:17:09PM -0400, Martin Dubuc wrote:
> How is it possible to figure out what driver is associated with which
> interface. We used to have some of this information available in
> /sys/config/hwconf. I am especially interested to know details of Wi-Fi
> interfaces (for instance ath5k or iwlagn).

2.6.33 will introduce ethtool support for mac80211-based wireless
devices (which is most of them).

Prior to that, 'ls -l /sys/class/net/wlan0/device/driver' is at least
minimally informative.

Hth!

John
-- 
John W. Linville		Linux should be at the core
linville at redhat.com			of your literate lifestyle.



From kevin.kofler at chello.at  Fri Oct 30 15:00:00 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Oct 2009 16:00 +0100
Subject: rawhide report: 20091030 changes
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>
Message-ID: 

Rawhide Report wrote:
> gnome-applet-timer-2.1.2-4.fc12.i686 requires gnome-audio

That dependency was added to fix a missing file, but the problem is that 
that package got retired in F12. See:
https://bugzilla.redhat.com/show_bug.cgi?id=531877#c4
for details and a suggested fix.

> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0

This one still needs attention from a Mono person to fix the rebuild. (A 
rebuild would be all that's needed, but the problem is that it's failing to 
build. 
http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log )

        Kevin Kofler



From mefoster at gmail.com  Fri Oct 30 16:01:39 2009
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Fri, 30 Oct 2009 16:01:39 +0000
Subject: Orphaning packages
In-Reply-To: <200907141251.36460.cemeyer@u.washington.edu>
References: <200907141251.36460.cemeyer@u.washington.edu>
Message-ID: 

2009/7/14 Conrad Meyer :
> I intend to orphan the JRuby package and some of the dependencies I don't
> believe anything else uses. It's a piece of software upstream really doesn't
> intend to be packaged, and bumping to new versions is a constant struggle.
> Furthermore, I don't have anymore use for it. Here is the list of packages
> I'll orphan sometime in the next week or so:
>
> ?- bytelist
> ?- constantine
> ?- jcodings
> ?- jline
> ?- jna-posix
> ?- joni
> ?- jvyamlb

Hello! I'm sorry to come in three and a half months after the fact
(does that mean that they'll all have to be re-reviewed? :( ), but
jruby is a dependency of some Java stuff that I'm currently working on
so I'd like to take over these packages.

MEF

-- 
Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/
Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab
School of Mathematical and Computer Sciences, Heriot-Watt University

Heriot-Watt University is a Scottish charity registered under charity
number SC000278



From tcallawa at redhat.com  Fri Oct 30 16:03:36 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Oct 2009 12:03:36 -0400
Subject: rawhide report: 20091030 changes
In-Reply-To: 
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>
	
Message-ID: <4AEB0E58.2030502@redhat.com>

On 10/30/2009 11:00 AM, Kevin Kofler wrote:

>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
> 
> This one still needs attention from a Mono person to fix the rebuild. (A 
> rebuild would be all that's needed, but the problem is that it's failing to 
> build. 
> http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log )

Nant (and several other members of the mono stack) have to be carefully
built in a two-stage process (bootstrap, unbootstrap). I'll do it today.

~spot



From jnovy at redhat.com  Fri Oct 30 16:55:16 2009
From: jnovy at redhat.com (Jindrich Novy)
Date: Fri, 30 Oct 2009 17:55:16 +0100
Subject: texlive 2009 - should set TEXMFCNF?
In-Reply-To: <645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>
References: 
	<20091027115946.GA14424@dhcp-lab-133.englab.brq.redhat.com>
	
	<20091029101405.GA31536@dhcp-lab-133.englab.brq.redhat.com>
	<645d17210910291026l519b52c7n694bb4ab718afc3a@mail.gmail.com>
Message-ID: <20091030165516.GA9652@dhcp-lab-133.englab.brq.redhat.com>

On Thu, Oct 29, 2009 at 05:26:25PM +0000, Jonathan Underwood wrote:
> 2009/10/29 Jindrich Novy :
> > Currently I'm trying to not to replace any package that has a separate
> > upstream and is already packaged separatelly in Fedora.
> >
> 
> IMO I think we'd be better off adopting the texlive versions of the
> packages, rather than doing a half-and-half job on this by packaging
> individual upstreams. The reason being that Fedora then benefits from
> the integration and testing work done by the texlive team. The texlive
> xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream"
> release.
> 
> J.

Ok, no problem with obsoleting a Fedora package with a TeX Live
variant if you, as a package maintainer of it, wish to. I will add
Obsoletes for xdvipdfmx.

I'm presenting a complete list of packages shipped in TeX Live to
discuss another possible obsoletions:

dvipdfm
dvipdfmx
getafm
lcdftypetools
psutils
t1utils
xdvi
dvipng
xdvipdfmx

If you think that also some of these packages in Fedora should be
obsoleted, please let me know and I will do so in the next TL repo
update.

Thanks,
Jindrich

-- 
Jindrich Novy    http://people.redhat.com/jnovy/



From tcallawa at redhat.com  Fri Oct 30 17:16:03 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Oct 2009 13:16:03 -0400
Subject: rawhide report: 20091030 changes
In-Reply-To: <4AEB0E58.2030502@redhat.com>
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>	
	<4AEB0E58.2030502@redhat.com>
Message-ID: <4AEB1F53.5070309@redhat.com>

On 10/30/2009 12:03 PM, Tom "spot" Callaway wrote:
> On 10/30/2009 11:00 AM, Kevin Kofler wrote:
> 
>>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
>>
>> This one still needs attention from a Mono person to fix the rebuild. (A 
>> rebuild would be all that's needed, but the problem is that it's failing to 
>> build. 
>> http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log )
> 
> Nant (and several other members of the mono stack) have to be carefully
> built in a two-stage process (bootstrap, unbootstrap). I'll do it today.

In case I get eaten by raptors (or someone else has to do this task in
the future), here's the gory details:

Nant is extremely sensitive about any changes made to its underlying
dependencies, specifically log4net, mono-nunit22, and mono-sharpcvslib.
Sometimes (possibly all the time), when these packages get rebuilt, or a
butterfly flaps its wings in Beijing, their symbols or locations in the
GAC change slightly, and nant will refuse to rebuild with the log error
you got above:

      [csc] The assembly was not found in the Global Assembly Cache, a
path listed in the MONO_PATH environment variable, or in the location of
the executing assembly
(/builddir/build/BUILD/nant-0.85/build/mono-2.0.unix/nant-0.85-debug/bin/lib/).
                  [csc] **
(/usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe:7194): WARNING **: Could
not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral,
PublicKeyToken=135942c6bc33ad08' or one of its dependencies.
                  [csc] **
(/usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe:7194): WARNING **:
Missing method .ctor in assembly
/builddir/build/BUILD/nant-0.85/build/mono-2.0.unix/nant-0.85-debug/bin/lib/ICSharpCode.SharpCvsLib.dll,
type log4net.Config.XmlConfiguratorAttribute
                  [csc] **
(/usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe:7194): WARNING **: Can't
find custom attr constructor image:
/builddir/build/BUILD/nant-0.85/build/mono-2.0.unix/nant-0.85-debug/bin/lib/ICSharpCode.SharpCvsLib.dll
mtoken: 0x0a0000f4
                  [csc] **
(/usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe:7194): WARNING **: Could
not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral,
PublicKeyToken=135942c6bc33ad08' or one of its dependencies.

Here's how to fix it.

1. Set %{bootstrap} to 1 in nant.spec. Minor release increment in
nant.spec. Rebuild. {Tag package in buildroot}
2. Increment release in mono-nunit22.spec. Rebuild. {Tag package in
buildroot}
3. Increment release in log4net.spec. Rebuild. {Tag package in buildroot}
4. Increment release in mono-sharpcvslib.spec. Rebuild. {Tag package in
buildroot}
5. Reset %{bootstrap} to 0 in nant.spec. Major release increment in
nant.spec (drop minor). Rebuild (nant should now build cleanly).

This is easier to do with a chain build, but since chain builds only
work for unfrozen rawhide...I'm having to do this by hand.

~spot




From mikem.rtp at gmail.com  Fri Oct 30 17:34:23 2009
From: mikem.rtp at gmail.com (Mike McLean)
Date: Fri, 30 Oct 2009 13:34:23 -0400
Subject: misguided flash player warning?
Message-ID: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>

After updating Firefox it gave me the "You should update Adobe Flash
Player right now." page. However, I already have the latest version
(10.0.32.18). I don't see anything newer. Am I missing something, or
is Firefox just getting it wrong?



From loganjerry at gmail.com  Fri Oct 30 17:42:28 2009
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 30 Oct 2009 11:42:28 -0600
Subject: misguided flash player warning?
In-Reply-To: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
References: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
Message-ID: <870180fe0910301042w2805013t397fbb50b191307@mail.gmail.com>

On Fri, Oct 30, 2009 at 11:34 AM, Mike McLean  wrote:
> After updating Firefox it gave me the "You should update Adobe Flash
> Player right now." page. However, I already have the latest version
> (10.0.32.18). I don't see anything newer. Am I missing something, or
> is Firefox just getting it wrong?

My wife got that on her Windows machine that already had the latest
version of Adobe Flash installed.  I got that on my Fedora machine
with no version of Adobe Flash at all (although I do have swfdec
installed).  Perhaps Firefox is showing that page to everybody.
-- 
Jerry James
http://www.jamezone.org/



From mrmazda at earthlink.net  Fri Oct 30 17:44:16 2009
From: mrmazda at earthlink.net (Felix Miata)
Date: Fri, 30 Oct 2009 13:44:16 -0400
Subject: Which was first Webkit/Epiphany release version
Message-ID: <4AEB25F0.5070908@earthlink.net>

2.24?
2.25?
2.26?
2.27? (my guess)
2.28?

And, when did the switch from Gecko happen? F10? F11? F12?
-- 
"   A patriot without religion . . . is as great a
paradox, as an honest man without the fear of God. . . .
			2nd U.S. President, John Adams
 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From bruno at wolff.to  Fri Oct 30 18:19:58 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 30 Oct 2009 13:19:58 -0500
Subject: rawhide report: 20091030 changes
In-Reply-To: <4AEB1F53.5070309@redhat.com>
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>
	 <4AEB0E58.2030502@redhat.com>
	<4AEB1F53.5070309@redhat.com>
Message-ID: <20091030181958.GA23858@wolff.to>

On Fri, Oct 30, 2009 at 13:16:03 -0400,
  Tom spot Callaway  wrote:
> 
> In case I get eaten by raptors (or someone else has to do this task in
> the future), here's the gory details:

I don't think I need to know the gory details of you being eaten by raptors.



From kevin.kofler at chello.at  Fri Oct 30 18:30:13 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Oct 2009 19:30:13 +0100
Subject: rawhide report: 20091030 changes
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>
	
Message-ID: 

I wrote:

> Rawhide Report wrote:
>> gnome-applet-timer-2.1.2-4.fc12.i686 requires gnome-audio
> 
> That dependency was added to fix a missing file, but the problem is that
> that package got retired in F12. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=531877#c4
> for details and a suggested fix.

This got fixed by the maintainer (Christoph Wickert) in 2.1.2-5.fc12 and the 
fixed build is already tagged f12-final, thanks!

>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
> 
> This one still needs attention from a Mono person to fix the rebuild. (A
> rebuild would be all that's needed, but the problem is that it's failing
> to build.
> http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log )

spot replied he's taking care of this one, thanks!

        Kevin Kofler



From christoph.frieben at googlemail.com  Fri Oct 30 18:42:14 2009
From: christoph.frieben at googlemail.com (Christoph Frieben)
Date: Fri, 30 Oct 2009 19:42:14 +0100
Subject: Which was first Webkit/Epiphany release version
In-Reply-To: <4AEB25F0.5070908@earthlink.net>
References: <4AEB25F0.5070908@earthlink.net>
Message-ID: 

2009/10/30 Felix Miata:
> 2.24?
> 2.25?
> 2.26?
> 2.27? (my guess)
> 2.28?
>
> And, when did the switch from Gecko happen? F10? F11? F12?

This was epiphany-2.27.2-1.fc12:

* Mon Jun 01 2009 Matthias Clasen  - 2.27.2-1
- Update to 2.27.2
- Build against webkit instead of gecko



From cemeyer at u.washington.edu  Fri Oct 30 18:49:43 2009
From: cemeyer at u.washington.edu (Conrad Meyer)
Date: Fri, 30 Oct 2009 11:49:43 -0700
Subject: Orphaning packages
In-Reply-To: 
References: <200907141251.36460.cemeyer@u.washington.edu>
	
Message-ID: <200910301149.44055.cemeyer@u.washington.edu>

On Friday 30 October 2009 09:01:39 am Mary Ellen Foster wrote:
> 2009/7/14 Conrad Meyer :
> > I intend to orphan the JRuby package and some of the dependencies I don't
> > believe anything else uses. It's a piece of software upstream really
> > doesn't intend to be packaged, and bumping to new versions is a constant
> > struggle. Furthermore, I don't have anymore use for it. Here is the list
> > of packages I'll orphan sometime in the next week or so:
> >
> >  - bytelist
> >  - constantine
> >  - jcodings
> >  - jline
> >  - jna-posix
> >  - joni
> >  - jvyamlb
> 
> Hello! I'm sorry to come in three and a half months after the fact
> (does that mean that they'll all have to be re-reviewed? :( ), but
> jruby is a dependency of some Java stuff that I'm currently working on
> so I'd like to take over these packages.
> 
> MEF

They're all orphaned in pkgdb. I'm not sure what process you'll need to go 
through to take them over (at the least, you'll probably have to talk to rel-
eng to get the dead.package's removed).

Regards,
-- 
Conrad Meyer 



From karlthered at gmail.com  Fri Oct 30 18:54:35 2009
From: karlthered at gmail.com (=?ISO-8859-1?Q?Ha=EFkel_Gu=E9mar?=)
Date: Fri, 30 Oct 2009 19:54:35 +0100
Subject: Which was first Webkit/Epiphany release version
In-Reply-To: <4AEB25F0.5070908@earthlink.net>
References: <4AEB25F0.5070908@earthlink.net>
Message-ID: <4AEB366B.6020109@gmail.com>

Epiphany switched to webkit by default since 2.27 series, for Fedora, it
will be for F-12.

Cheers,
H.



From MathStuf at gmail.com  Fri Oct 30 18:58:24 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Fri, 30 Oct 2009 14:58:24 -0400
Subject: rawhide report: 20091030 changes
References: <20091030103609.GA5828@releng2.fedora.phx.redhat.com>
	 <4AEB0E58.2030502@redhat.com>
	<4AEB1F53.5070309@redhat.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Tom "spot" Callaway wrote:

> On 10/30/2009 12:03 PM, Tom "spot" Callaway wrote:
>> On 10/30/2009 11:00 AM, Kevin Kofler wrote:
>> 
>>>> 1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0
>>>
>>> This one still needs attention from a Mono person to fix the rebuild. (A 
>>> rebuild would be all that's needed, but the problem is that it's failing to 
>>> build. 
>>> http://koji.fedoraproject.org/koji/getfile?taskID=1777541&name=build.log )
>> 
>> Nant (and several other members of the mono stack) have to be carefully
>> built in a two-stage process (bootstrap, unbootstrap). I'll do it today.
> 
> In case I get eaten by raptors (or someone else has to do this task in
> the future), here's the gory details:

Don't worry, this[1] will protect you. ;)

- --Ben

[1]http://store.xkcd.com/xkcd/#NoRaptors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJK6zdQAAoJEKaxavVX4C1X8zcQAO1tPOAVG+xYLCGNprzchXxQ
4KlnHOUDrkWAPVOOZXFEt1ITjvrCHAN7L2ZGP6K9UhKENmFxItDSRk6+9YJs+ucg
o8Pyq1sul7bv+P4yHqcyMGUvq/Sc43YxnXkEhCRZpPRb+s5HJd0/5MioBm+AAZ8H
o+IpZR3zSbODOFG+vCI8BgrGekJN//Z0cvjtdpdEn8xBYD9qmhcBQ8+FL+6tQsxO
qz0cQtDiJyXv8H8XK4IB1R3mptWItStxORRFIlc2cMWFwmkmtfCYNWPWUOIv2Fm7
bSLw1b7bpKtjy8Qbr3t2vL4SvOsiFIUdPAEdQYU/pfEW0bF4HAaH8j05qxRU7kaq
fkbCoCasMFWlWzfxnF7eI0TD2MiboL6HrVOHwALeTyf+dZxdn3dBVfCD+3biKWfv
vrwhR6Qq0Z8tjKbT44R6hWVF4q2NyXhqlBl8Xx2XmPPFbPdjF0OYLW2dW9bHFSHz
fMPMamKWo5BDzz45k6VlIY4XBcstmGsyHtvTGKRDKTBbQQAxQuhlccW+i+9p4QDv
Vs+5FLNY2GIxuRTB/6t7JuQakC4GTN5IExkjh3PMxp4JYOqQu47BUpSLp78+cp9m
GmReYcTiCsoUkMaKfM754MuMs0RKW1gQGtiPYnkbVtqj9b5uaRF7pIjhOqwx9sqK
xqXg5sRPlcS45oWgFQO2
=x44Y
-----END PGP SIGNATURE-----




From nicolas.mailhot at laposte.net  Fri Oct 30 19:46:43 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 30 Oct 2009 20:46:43 +0100
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	<4AEAC3EA.90004@redhat.com> 
Message-ID: <18a1b11a78731a6975c56d0389b667e8.squirrel@arekh.dyndns.org>



Le Ven 30 octobre 2009 13:59, Benny Amorsen a ?crit :

> It would be nice if fonts like Inconsolata somehow set a flag that they
> require hinting. This would prevent the side effects on old fonts.

This could technically be done in fontconfig IIRC but it would require a lot
of unglamorous manual testing and triaging. Which no one is volunteering to
do. And before we go there (tackle problems that require manual testing) there
is a lot of font problems that can be detected automatically, and need fixing
too.

-- 
Nicolas Mailhot




From orion at cora.nwra.com  Fri Oct 30 20:22:48 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 30 Oct 2009 14:22:48 -0600
Subject: misguided flash player warning?
In-Reply-To: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
References: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
Message-ID: <4AEB4B18.4090705@cora.nwra.com>

On 10/30/2009 11:34 AM, Mike McLean wrote:
> After updating Firefox it gave me the "You should update Adobe Flash
> Player right now." page. However, I already have the latest version
> (10.0.32.18). I don't see anything newer. Am I missing something, or
> is Firefox just getting it wrong?
>

https://bugzilla.redhat.com/show_bug.cgi?id=523273

-- 
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 mike at miketc.net  Fri Oct 30 22:31:01 2009
From: mike at miketc.net (Mike Chambers)
Date: Fri, 30 Oct 2009 17:31:01 -0500
Subject: Gnome panel crashes when changing color
Message-ID: <1256941861.5699.2.camel@scrappy.miketc.net>

It seems, whether you use the bottom panel, or change the top panel to
be the bottom (speaking after an initial rawhide install), and go to
properties and change the color of it, it crashes.  It logs you out of
gnome and into gdm, then fails to load and won't allow you to log in to
gnome again.

Anyone else seen this lately?

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From awilliam at redhat.com  Fri Oct 30 22:32:44 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 30 Oct 2009 15:32:44 -0700
Subject: 2009-10-30 Fedora 12 blocker bug review meeting recap
Message-ID: <1256941964.2314.118.camel@adam.local.net>

(Scene: Curtain raises. A haggard figure stumbles in from stage left,
blinking at the lights.)

AdamW: Where am I? What year is this? WHO'S THE PRESIDENT?!

FIN

Yes, today's epic F12 blocker bug review meeting has finally ended. Some
statistics:

We reviewed 43 bugs in total. The meeting took 406 minutes, at an
average of 9.44 Minutes Per Bug (MPB). Thanks to Marko Myllynen for
suggesting the calculation. :)

We reduced the number of open blocker bugs (excluding second-level
blocker tracker bugs like the X, Anaconda, virtualization and KDE
trackers) from 43 to 25. Of the remaining 25, there is one in NEW state,
11 ASSIGNED, and 13 MODIFIED.

Here's the assignee breakdown for non-MODIFIED bugs:

2: Jerome Glisse, Adam Jackson
1: Dave Airlie, Ben Skeggs, Christoph Hellwig, David Zeuthen, William
Jon McCann, Jiri Moskovc, Matthias Clasen (probably mis-assigned), Steve
Dickson.

We have plans in hand for most of the remaining NEW and ASSIGNED bugs,
so overall the picture for getting all F12 blocker bugs resolved on time
is reasonably rosy as long as we get stuff done over the weekend and
early part of next week.

You can always find the current blocker list at:

https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1

The summary of the meeting (highly recommended over the logs unless you
have a LOT of time) is available at
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-30/fedora-bugzappers.2009-10-30-15.01.html . The full log - for those looking for an insomnia cure - is at http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-30/fedora-bugzappers.2009-10-30-15.01.log.html .

Huge thanks to James Laska, Jesse Keating, Ray Strode, Chuck Ebbert,
Jerome Glisse, Will Woods, Denise Dumas, Matthias Clasen, Dave Airlie,
Bill Nottingham, Filipe Rosset, Chris Lumens, Jeremy Katz, Marko
Myllynen, Eric Paris, Paul Frields, Seth Vidal and Ben Williams for
sticking around through Giganto-Meeting and providing all the necessary
input, this one was a real team effort.

If anyone has any ideas to reduce these meetings in time somewhat, they
would be greatly welcomed on test-list. I can't think of much that
wouldn't involve someone taking more executive decisions pre-meeting,
though.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mclasen at redhat.com  Fri Oct 30 22:34:38 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 30 Oct 2009 18:34:38 -0400
Subject: Gnome panel crashes when changing color
In-Reply-To: <1256941861.5699.2.camel@scrappy.miketc.net>
References: <1256941861.5699.2.camel@scrappy.miketc.net>
Message-ID: <1256942078.1761.0.camel@planemask>

On Fri, 2009-10-30 at 17:31 -0500, Mike Chambers wrote:
> It seems, whether you use the bottom panel, or change the top panel to
> be the bottom (speaking after an initial rawhide install), and go to
> properties and change the color of it, it crashes.  It logs you out of
> gnome and into gdm, then fails to load and won't allow you to log in to
> gnome again.
> 
> Anyone else seen this lately?

If your panel crashes, that does not end your session. Try it:

killall -SEGV gnome-panel

If your session ends, most likely the X server crashed.



From m.a.young at durham.ac.uk  Fri Oct 30 22:45:04 2009
From: m.a.young at durham.ac.uk (M A Young)
Date: Fri, 30 Oct 2009 22:45:04 +0000 (GMT)
Subject: misguided flash player warning?
In-Reply-To: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
References: <4f50e0680910301034m54434fdfwda071a3ff80de1e8@mail.gmail.com>
Message-ID: 

On Fri, 30 Oct 2009, Mike McLean wrote:

> After updating Firefox it gave me the "You should update Adobe Flash
> Player right now." page. However, I already have the latest version
> (10.0.32.18). I don't see anything newer. Am I missing something, or
> is Firefox just getting it wrong?

I had time, and about:plugins claimed it was an older version. I fixed it 
by deleting the 
/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so file, 
which was enough to prod firefox into recognizing the right version.

 	Michael Young



From awilliam at redhat.com  Fri Oct 30 22:48:16 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 30 Oct 2009 15:48:16 -0700
Subject: Gnome panel crashes when changing color
In-Reply-To: <1256942078.1761.0.camel@planemask>
References: <1256941861.5699.2.camel@scrappy.miketc.net>
	<1256942078.1761.0.camel@planemask>
Message-ID: <1256942896.2314.120.camel@adam.local.net>

On Fri, 2009-10-30 at 18:34 -0400, Matthias Clasen wrote:
> On Fri, 2009-10-30 at 17:31 -0500, Mike Chambers wrote:
> > It seems, whether you use the bottom panel, or change the top panel to
> > be the bottom (speaking after an initial rawhide install), and go to
> > properties and change the color of it, it crashes.  It logs you out of
> > gnome and into gdm, then fails to load and won't allow you to log in to
> > gnome again.
> > 
> > Anyone else seen this lately?
> 
> If your panel crashes, that does not end your session. Try it:
> 
> killall -SEGV gnome-panel
> 
> If your session ends, most likely the X server crashed.

...in which case, boot to initlevel 3, login, startx, reproduce the bug
if you can, if it dumps you back to the console, take a copy
of /var/log/Xorg.0.log before starting X again. Error messages should be
in there.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From mike at miketc.net  Fri Oct 30 23:03:24 2009
From: mike at miketc.net (Mike Chambers)
Date: Fri, 30 Oct 2009 18:03:24 -0500
Subject: Gnome panel crashes when changing color
In-Reply-To: <1256942896.2314.120.camel@adam.local.net>
References: <1256941861.5699.2.camel@scrappy.miketc.net>
	<1256942078.1761.0.camel@planemask>
	<1256942896.2314.120.camel@adam.local.net>
Message-ID: <1256943804.10831.0.camel@scrappy.miketc.net>

On Fri, 2009-10-30 at 15:48 -0700, Adam Williamson wrote:
> On Fri, 2009-10-30 at 18:34 -0400, Matthias Clasen wrote:
> > On Fri, 2009-10-30 at 17:31 -0500, Mike Chambers wrote:
> > > It seems, whether you use the bottom panel, or change the top panel to
> > > be the bottom (speaking after an initial rawhide install), and go to
> > > properties and change the color of it, it crashes.  It logs you out of
> > > gnome and into gdm, then fails to load and won't allow you to log in to
> > > gnome again.
> > > 
> > > Anyone else seen this lately?
> > 
> > If your panel crashes, that does not end your session. Try it:
> > 
> > killall -SEGV gnome-panel
> > 
> > If your session ends, most likely the X server crashed.
> 
> ...in which case, boot to initlevel 3, login, startx, reproduce the bug
> if you can, if it dumps you back to the console, take a copy
> of /var/log/Xorg.0.log before starting X again. Error messages should be
> in there.

No errors in there that I could find.  But in my .xsession-errors file
there are plenty, which is attached.

-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .xsession-errors.old
Type: application/x-trash
Size: 3472 bytes
Desc: not available
URL: 

From mike at miketc.net  Fri Oct 30 23:08:35 2009
From: mike at miketc.net (Mike Chambers)
Date: Fri, 30 Oct 2009 18:08:35 -0500
Subject: Gnome panel crashes when changing color
In-Reply-To: <1256943804.10831.0.camel@scrappy.miketc.net>
References: <1256941861.5699.2.camel@scrappy.miketc.net>
	<1256942078.1761.0.camel@planemask>
	<1256942896.2314.120.camel@adam.local.net>
	<1256943804.10831.0.camel@scrappy.miketc.net>
Message-ID: <1256944115.10831.2.camel@scrappy.miketc.net>

On Fri, 2009-10-30 at 18:03 -0500, Mike Chambers wrote:
> On Fri, 2009-10-30 at 15:48 -0700, Adam Williamson wrote:
> > On Fri, 2009-10-30 at 18:34 -0400, Matthias Clasen wrote:
> > > On Fri, 2009-10-30 at 17:31 -0500, Mike Chambers wrote:
> > > > It seems, whether you use the bottom panel, or change the top panel to
> > > > be the bottom (speaking after an initial rawhide install), and go to
> > > > properties and change the color of it, it crashes.  It logs you out of
> > > > gnome and into gdm, then fails to load and won't allow you to log in to
> > > > gnome again.
> > > > 
> > > > Anyone else seen this lately?
> > > 
> > > If your panel crashes, that does not end your session. Try it:
> > > 
> > > killall -SEGV gnome-panel
> > > 
> > > If your session ends, most likely the X server crashed.
> > 
> > ...in which case, boot to initlevel 3, login, startx, reproduce the bug
> > if you can, if it dumps you back to the console, take a copy
> > of /var/log/Xorg.0.log before starting X again. Error messages should be
> > in there.
> 
> No errors in there that I could find.  But in my .xsession-errors file
> there are plenty, which is attached.

Oh yea, and removing my .gconf/apps/panel dir restores my panels to the
original defaults and I am able to login again. 



-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From zaitcev at redhat.com  Sat Oct 31 02:37:57 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 30 Oct 2009 20:37:57 -0600
Subject: Font rendering slightly degraded in recent rawhide
In-Reply-To: 
References: 
	<20091029092026.GB25682@mother.pipebreaker.pl>
	
	<117066306aa8208e2147d027e06df8e0.squirrel@arekh.dyndns.org>
	
	<9541482d0cc82baccf633eb60ac80709.squirrel@arekh.dyndns.org>
	
Message-ID: <20091030203757.197981b4@redhat.com>

On Thu, 29 Oct 2009 18:44:51 +0100, Christoph Frieben  wrote:

> I had already pointed out that this issue also affects the current
> default system font. Let's see what other people out there think about
> this issue. It's not like you are the supreme judge in this matter,
> and it's also not the first time that you show up as a hotspur on this
> mailing list ..

My default system font looks better than 2 days ago, although not
by much. I'd be fine with any setting. Is it what you're asking?

-- Pete



From bruno at wolff.to  Sat Oct 31 04:07:24 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 30 Oct 2009 23:07:24 -0500
Subject: What to do with package that wants to use sse?
Message-ID: <20091031040724.GA22910@wolff.to>

I am working on packaging pagedgeometry and I noticed that when building
on gcc it passes -msse which I am guessing says to use sse instructions.
I think that even in F12 we can't assume these instructions are available.
The package may gain a lot of benefit from using those instructions.
(I haven't tested that yet as I am still pretty early in the process.)
Is there some relatively standard way to handle something like this?



From awilliam at redhat.com  Sat Oct 31 04:29:24 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Fri, 30 Oct 2009 21:29:24 -0700
Subject: What to do with package that wants to use sse?
In-Reply-To: <20091031040724.GA22910@wolff.to>
References: <20091031040724.GA22910@wolff.to>
Message-ID: <1256963364.2314.123.camel@adam.local.net>

On Fri, 2009-10-30 at 23:07 -0500, Bruno Wolff III wrote:
> I am working on packaging pagedgeometry and I noticed that when building
> on gcc it passes -msse which I am guessing says to use sse instructions.
> I think that even in F12 we can't assume these instructions are available.
> The package may gain a lot of benefit from using those instructions.
> (I haven't tested that yet as I am still pretty early in the process.)
> Is there some relatively standard way to handle something like this?

You should always adjust any build process which wants to use custom
compiler flags to use the standard Fedora flags. Well-written build
systems allow you to set compiler flags trivially with a parameter or
environment variable. Badly-written ones hard-code their preferred flags
and require you to patch before you can pass in the Fedora flags. In the
latter case, patch the build system and send the patch upstream.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From bruno at wolff.to  Sat Oct 31 05:51:12 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Oct 2009 00:51:12 -0500
Subject: What to do with package that wants to use sse?
In-Reply-To: <1256963364.2314.123.camel@adam.local.net>
References: <20091031040724.GA22910@wolff.to>
	<1256963364.2314.123.camel@adam.local.net>
Message-ID: <20091031055112.GA4392@wolff.to>

On Fri, Oct 30, 2009 at 21:29:24 -0700,
  Adam Williamson  wrote:
> 
> You should always adjust any build process which wants to use custom
> compiler flags to use the standard Fedora flags. Well-written build
> systems allow you to set compiler flags trivially with a parameter or
> environment variable. Badly-written ones hard-code their preferred flags
> and require you to patch before you can pass in the Fedora flags. In the
> latter case, patch the build system and send the patch upstream.

The way they have this setup with cmake is such that it seems to add
-msse on to the Fedora defaults. I think they are going to want that
to be the normal case when building for linux. Under those circumstances,
am I supposed to ask them to put in a test for Fedora in the cmake
build file or is there some standard way of adding -msse when options
aren't specified from rpm, but it is added when they are not?
I am not sure what I am supposed to recommend to upstream other than perhaps
something they aren't likely to do.

Changing the cmake specs in the spec file won't be hard.



From kwizart at gmail.com  Sat Oct 31 08:25:30 2009
From: kwizart at gmail.com (Nicolas Chauvet)
Date: Sat, 31 Oct 2009 09:25:30 +0100
Subject: What to do with package that wants to use sse?
In-Reply-To: <20091031040724.GA22910@wolff.to>
References: <20091031040724.GA22910@wolff.to>
Message-ID: 

2009/10/31 Bruno Wolff III :
> I am working on packaging pagedgeometry and I noticed that when building
> on gcc it passes -msse which I am guessing says to use sse instructions.
> I think that even in F12 we can't assume these instructions are available.
> The package may gain a lot of benefit from using those instructions.
> (I haven't tested that yet as I am still pretty early in the process.)
> Is there some relatively standard way to handle something like this?
-msse is fine for x86_64 and ia64  by default (but not for non-intel arches).
The only way to have sse enabled on ix86 is for a library to be built
twice, the provides the sse version in %{_libdir}/sse2. The linker
will then enable the appropriate library at runtime.
(note that only sse2 wrap exists - not sse{,3,4},atom,i7 )
That's not possible when the optimized code is within a binary.

Now I would really like to promote a comprehensive understanding of that policy.
Because sometimes the application requirements are beyond the entry
point of  sse. There is a package, outside of the Fedora collection,
that might be compiled with sse on ix86.
There is generic code for it, so it will probably works on s390 or
sparc, along with non-sse ix86. But mixing real time multimedia
streams for deejay will then became harder if not sse enabled. So the
application requirement was to be higher than if the app wasn't
compiled with sse.

I also have another case for a package which is an image renderer for blender.
Using such app on computer that doesn't have sse is really a miss
understanding of what your computer is better used at.

Nicolas (kwizart)



From rawhide at fedoraproject.org  Sat Oct 31 11:07:06 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 31 Oct 2009 11:07:06 +0000
Subject: rawhide report: 20091031 changes
Message-ID: <20091031110706.GA5600@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 31 06:15:21 UTC 2009

Broken deps for i386
----------------------------------------------------------
	1:nant-0.85-30.fc12.i686 requires mono(NDoc.Core) = 0:1.3.3498.0



Broken deps for x86_64
----------------------------------------------------------
	1:nant-0.85-30.fc12.x86_64 requires mono(NDoc.Core) = 0:1.3.3498.0









Updated Packages:

argyllcms-1.0.4-3.fc12
----------------------
* Fri Oct 30 2009 Richard Hughes  - 1.0.4-3
- Install the udev rules file so users can get the correct device
  permissions on F12 and above which does not use HAL policy files.


compiz-0.8.2-19.fc12
--------------------
* Fri Oct 30 2009 Adel Gadllah  - 0.8.2-17
- Use better lables for keybindings


galeon-2.0.7-17.fc12
--------------------
* Fri Oct 30 2009 Kevin Kofler  - 2.0.7-17
- Bump Release to fix upgrade path from F11


gnome-applet-timer-2.1.2-5.fc12
-------------------------------
* Fri Oct 30 2009 Christoph Wickert  - 2.1.2-5
- Use default sound form sound-theme-freedesktop (#531877)


gutenprint-5.2.4-7.fc12
-----------------------
* Thu Oct 29 2009 Tim Waugh  5.2.4-7
- Removed incorrect Device ID for Brother HL-2060 (bug #531370).


hplip-3.9.8-20.fc12
-------------------
* Fri Oct 30 2009 Tim Waugh  3.9.8-20
- Reverted retry patch until it can be tested some more.

* Thu Oct 29 2009 Tim Waugh  3.9.8-19
- Retry when connecting to device fails (bug #528483).
- Avoid busy loop in hpcups when backend has exited (bug #525944).

* Wed Oct 28 2009 Tim Waugh  3.9.8-18
- Set a printer-state-reason when there's a missing required plugin
  (bug #531330).


jabbim-0.5-0.12.svn20091030.fc12
--------------------------------
* Fri Oct 30 2009 Michal Schmidt  0.5-0.12.svn20091030
- Update to svn rev. 4233 (bugfixes and German translation update)
- Drop 3 upstreamed patches.


kcm-gtk-0.5.3-1.fc12
--------------------
* Fri Oct 30 2009 Rex Dieter  0.5.3-1
- kcm-gtk-0.5.3
- .gtkrc-2.0-kde4 doesn't get used (#531788)


libvirt-0.7.1-15.fc12
---------------------
* Thu Oct 29 2009 Mark McLoughlin  - 0.7.1-14
- Make libvirt-devel require libvirt-client, not libvirt
- Fix xen driver recounting (#531429)
- Fix crash on virsh error (#531429)
- Fix segfault where XML parsing fails in qemu disk hotplug
- Fix segfault where interface target device name is ommitted (#523418)

* Thu Oct 29 2009 Mark McLoughlin  - 0.7.1-15
- Avoid compressing small log files (#531030)


mingw32-dlfcn-0-0.7.r11.fc12
----------------------------
* Fri Oct 30 2009 Erik van Pienbroek  - 0-0.7.r11
- Use %global instead of %define
- Automatically generate debuginfo subpackage
- Fixed %defattr line
- Added -static subpackage
- Fixed linker error with C++ applications


mingw32-gtk2-2.18.3-1.fc12
--------------------------
* Sat Oct 17 2009 Erik van Pienbroek  - 2.18.3-1
- Update to 2.18.3
- Drop upstreamed patch (GNOME BZ #597535)
- Re-enable GDI+ support as it's fixed upstream (GNOME BZ #552678)
- This release contains a workaround for a rendering bug which got
  introduced during the CSW merge (GNOME BZ #598299)

* Tue Oct 06 2009 Erik van Pienbroek  - 2.18.2-1
- Update to 2.18.2

* Thu Oct 01 2009 Erik van Pienbroek  - 2.18.1-1
- Update to 2.18.1


pacemaker-1.0.5-4.fc12
----------------------
* Thu Oct 29 2009 Andrew Beekhof  - 1.0.5-4
- Include the fixes from CoroSync integration testing
- Move the resource templates - they're not documentation
- Ensure documentation is placed in a standard location
- Exclude documentation that is included elsewhere in the package

- Update the tarball from upstream to version ee19d8e83c2a
  + High: cib: Correctly clean up when both plaintext and tls remote ports are requested
  + High: PE: Bug bnc#515172 - Provide better defaults for lt(e) and gt(e) comparisions
  + High: PE: Bug lf#2197 - Allow master instances placemaker to be influenced by colocation constraints
  + High: PE: Make sure promote/demote pseudo actions are created correctly
  + High: PE: Prevent target-role from promoting more than master-max instances
  + High: ais: Bug lf#2199 - Prevent expected-quorum-votes from being populated with garbage
  + High: ais: Prevent deadlock - dont try to release IPC message if the connection failed
  + High: cib: For validation errors, send back the full CIB so the client can display the errors
  + High: cib: Prevent use-after-free for remote plaintext connections
  + High: crmd: Bug lf#2201 - Prevent use-of-NULL when running heartbeat


parole-0.1.91-1.fc12
--------------------
* Fri Oct 30 2009 Christoph Wickert  - 0.1.91-1
- Update tp 0.1.91


perl-Business-ISBN-2.05-1.fc12
------------------------------
* Mon Oct 05 2009 Stepan Kasal  - 2.05-1
- new upstream version


perl-Digest-SHA1-2.12-1.fc12
----------------------------
* Mon Oct 05 2009 Stepan Kasal  - 2.12-1
- new upstream version


perl-MIME-Lite-3.026-2.fc12
---------------------------
* Wed Oct 07 2009 Stepan Kasal  - 3.26-1
- new upstream version
- fix buildrequires
- add requires not detected automatically

* Wed Oct 07 2009 Stepan Kasal  - 3.26-2
- no need to search for *.bs files in noarch rpm


perl-Test-Deep-0.106-1.fc12
---------------------------
* Fri Oct 30 2009 Stepan Kasal  - 0.106-1
- new upstream version


perl-Test-Pod-1.40-1.fc12
-------------------------
* Fri Oct 30 2009 Stepan Kasal  - 1.40-1
- new upstream version


perl-Test-Prereq-1.037-1.fc12
-----------------------------
* Fri Oct 30 2009 Stepan Kasal  - 1.037-1
- new upstream version


qemu-0.11.0-9.fc12
------------------
* Thu Oct 29 2009 Mark McLoughlin  - 2:0.11.0-9
- Fix dropped packets with non-virtio NICs (#531419)


qt-4.5.3-7.fc12
---------------
* Thu Oct 29 2009 Than Ngo  - 4.5.3-7
- fix glib-even-loop issue, regression which causes
  Password dialogs get stuck


resource-agents-3.0.4-2.fc12
----------------------------
* Wed Oct 28 2009 Andrew Beekhof  - 3.0.4-2
- Update Pacameker agents to upstream version: e2338892f59f
  + High: send_arp - turn on unsolicited mode for compatibilty with the libnet version's exit codes
  + High: Trap sigterm for compatibility with the libnet version of send_arp
  + Medium: Bug - lf#2147: IPaddr2: behave if the interface is down
  + Medium: IPv6addr: recognize network masks properly
  + Medium: RA: VirtualDomain: avoid needlessly invoking "virsh define"


system-config-printer-1.1.13-6.fc12
-----------------------------------
* Fri Oct 30 2009 Tim Waugh  1.1.13-6
- Avoid traceback in IPP notification handlers (bug #530641).
- Avoid epydoc dependency.

* Thu Oct 29 2009 Tim Waugh  1.1.13-5
- Added upstream patch for custom state reasons (bug #531872).
- Strip 'zjs' from make-and-model as well (bug #531869).

* Wed Oct 28 2009 Tim Waugh  1.1.13-4
- Troubleshoot: connect to the right server when choosing a network
  queue (bug #531482).
- Strip 'zxs' and 'pcl3' from make-and-model (bug #531048).
- Fixed visibility tracking for jobs window (bug #531438).
- Don't display properties dialog for first test page (bug #531490).
- Determine make/model for network printers (bug #524321).
- Auto-select the correct driver entry for raw queues.
- Avoid traceback in PhysicalDevice.py.
- Let Return key activate the Find button for Find Network Printer.


x86info-1.25-1.45.fc12
----------------------
* Fri Oct 30 2009 Dave Jones 
- Update to new upstream 1.25


xinetd-2.3.14-28.fc12
---------------------
* Tue Oct 20 2009 Jan Zeleny  - 2:2.3.14-27
- last update of init script modified to work with SELinux correctly

* Tue Oct 20 2009 Jan Zeleny  - 2:2.3.14-28
- added support for new configuration option - file limit for service


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 25



From ikem.krueger at googlemail.com  Sat Oct 31 13:24:46 2009
From: ikem.krueger at googlemail.com (Ikem Krueger)
Date: Sat, 31 Oct 2009 13:24:46 +0000
Subject: Kernel using LZMA compression
Message-ID: 

As I know, the kernel is compressed with bzip2 or gzip. How about
using LZMA instead? Or is that already the case?



From drago01 at gmail.com  Sat Oct 31 13:40:54 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Oct 2009 14:40:54 +0100
Subject: Kernel using LZMA compression
In-Reply-To: 
References: 
Message-ID: 

On Sat, Oct 31, 2009 at 2:24 PM, Ikem Krueger
 wrote:
> As I know, the kernel is compressed with bzip2 or gzip. How about
> using LZMA instead? Or is that already the case?

There is such an option but it is currently disabled due to missing
support in xen.



From bruno at wolff.to  Sat Oct 31 14:29:22 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Oct 2009 09:29:22 -0500
Subject: What to do with package that wants to use sse?
In-Reply-To: 
References: <20091031040724.GA22910@wolff.to>
	
Message-ID: <20091031142922.GA23171@wolff.to>

On Sat, Oct 31, 2009 at 09:25:30 +0100,
  Nicolas Chauvet  wrote:
> -msse is fine for x86_64 and ia64  by default (but not for non-intel arches).
> The only way to have sse enabled on ix86 is for a library to be built
> twice, the provides the sse version in %{_libdir}/sse2. The linker
> will then enable the appropriate library at runtime.
> (note that only sse2 wrap exists - not sse{,3,4},atom,i7 )
> That's not possible when the optimized code is within a binary.

That is very useful information. It sounds like I will want to do this for
this package, since enabling sse2 will turn on the sse instructions and sse2
might turn out to be useful for this code as well.

> Now I would really like to promote a comprehensive understanding of that policy.

It would be nice to have an example of how do the build for something like this
in one spec file.

If there is some documentation it should be included in or pointed to by
the base packaging page on the wiki so that people can easily run accross it.

> I also have another case for a package which is an image renderer for blender.
> Using such app on computer that doesn't have sse is really a miss
> understanding of what your computer is better used at.

The package I am working on is doing image rendering as an add on to ogre.



From mike at miketc.net  Sat Oct 31 15:16:23 2009
From: mike at miketc.net (Mike Chambers)
Date: Sat, 31 Oct 2009 10:16:23 -0500
Subject: Gnome panel crashes when changing color
In-Reply-To: <1256944115.10831.2.camel@scrappy.miketc.net>
References: <1256941861.5699.2.camel@scrappy.miketc.net>
	<1256942078.1761.0.camel@planemask>
	<1256942896.2314.120.camel@adam.local.net>
	<1256943804.10831.0.camel@scrappy.miketc.net>
	<1256944115.10831.2.camel@scrappy.miketc.net>
Message-ID: <1257002183.1666.0.camel@scrappy.miketc.net>

On Fri, 2009-10-30 at 18:08 -0500, Mike Chambers wrote:
> On Fri, 2009-10-30 at 18:03 -0500, Mike Chambers wrote:
> > On Fri, 2009-10-30 at 15:48 -0700, Adam Williamson wrote:
> > > On Fri, 2009-10-30 at 18:34 -0400, Matthias Clasen wrote:
> > > > On Fri, 2009-10-30 at 17:31 -0500, Mike Chambers wrote:
> > > > > It seems, whether you use the bottom panel, or change the top panel to
> > > > > be the bottom (speaking after an initial rawhide install), and go to
> > > > > properties and change the color of it, it crashes.  It logs you out of
> > > > > gnome and into gdm, then fails to load and won't allow you to log in to
> > > > > gnome again.
> > > > > 
> > > > > Anyone else seen this lately?
> > > > 
> > > > If your panel crashes, that does not end your session. Try it:
> > > > 
> > > > killall -SEGV gnome-panel
> > > > 
> > > > If your session ends, most likely the X server crashed.
> > > 
> > > ...in which case, boot to initlevel 3, login, startx, reproduce the bug
> > > if you can, if it dumps you back to the console, take a copy
> > > of /var/log/Xorg.0.log before starting X again. Error messages should be
> > > in there.
> > 
> > No errors in there that I could find.  But in my .xsession-errors file
> > there are plenty, which is attached.
> 
> Oh yea, and removing my .gconf/apps/panel dir restores my panels to the
> original defaults and I am able to login again. 

Filed a bug against gnome-panel as not sure really what the cause is.
Also attached xsession-error.log to help.

https://bugzilla.redhat.com/show_bug.cgi?id=532213


-- 
Mike Chambers
Madisonville, KY

"Best lil town on Earth!"



From awilliam at redhat.com  Sat Oct 31 16:33:13 2009
From: awilliam at redhat.com (Adam Williamson)
Date: Sat, 31 Oct 2009 09:33:13 -0700
Subject: What to do with package that wants to use sse?
In-Reply-To: <20091031142922.GA23171@wolff.to>
References: <20091031040724.GA22910@wolff.to>
	
	<20091031142922.GA23171@wolff.to>
Message-ID: <1257006793.2314.145.camel@adam.local.net>

On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:

> That is very useful information. It sounds like I will want to do this for
> this package, since enabling sse2 will turn on the sse instructions and sse2
> might turn out to be useful for this code as well.
> 
> > Now I would really like to promote a comprehensive understanding of that policy.
> 
> It would be nice to have an example of how do the build for something like this
> in one spec file.

The documentation there is is at
https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

but it's not a lot.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



From bruno at wolff.to  Sat Oct 31 17:04:11 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Oct 2009 12:04:11 -0500
Subject: What to do with package that wants to use sse?
In-Reply-To: <1257006793.2314.145.camel@adam.local.net>
References: <20091031040724.GA22910@wolff.to>
	
	<20091031142922.GA23171@wolff.to>
	<1257006793.2314.145.camel@adam.local.net>
Message-ID: <20091031170411.GA18785@wolff.to>

On Sat, Oct 31, 2009 at 09:33:13 -0700,
  Adam Williamson  wrote:
> On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:
> 
> > That is very useful information. It sounds like I will want to do this for
> > this package, since enabling sse2 will turn on the sse instructions and sse2
> > might turn out to be useful for this code as well.
> > 
> > > Now I would really like to promote a comprehensive understanding of that policy.
> > 
> > It would be nice to have an example of how do the build for something like this
> > in one spec file.
> 
> The documentation there is is at
> https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
> 
> but it's not a lot.

That is where I would expect sse2 information; either inline or a pointer
to something more comprehensive.

Not much is using sse2 right now. I would expect that the main ogre package
could make use of this, but currently doesn't.

I am having trouble finding good documentation on what the runtime linker
does. The link below is the best description I have found so far, and answers
a question I had about whether stuff needs to be in /usr/lib/sse2/OGRE or
/usr/lib/OGRE/sse2 (the former).
(http://lkml.indiana.edu/hypermail/linux/kernel/0704.3/0002.html

I think I know enough to attempt a -sse2 subpackage for x86 arch.
The path to proven packager is paved with much learning.



From ikem.krueger at googlemail.com  Sat Oct 31 17:03:21 2009
From: ikem.krueger at googlemail.com (Ikem Krueger)
Date: Sat, 31 Oct 2009 17:03:21 +0000
Subject: Kernel using LZMA compression
In-Reply-To: 
References: 
	
Message-ID: 

>> As I know, the kernel is compressed with bzip2 or gzip. How about using LZMA instead? Or is that already the case?

> There is such an option but it is currently disabled due to missing support in xen.
Thanks. But don't understand. What has LZMA todo with Xen?



From drago01 at gmail.com  Sat Oct 31 17:11:06 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Oct 2009 18:11:06 +0100
Subject: Kernel using LZMA compression
In-Reply-To: 
References: 
	
	
Message-ID: 

On Sat, Oct 31, 2009 at 6:03 PM, Ikem Krueger
 wrote:
>>> As I know, the kernel is compressed with bzip2 or gzip. How about using LZMA instead? Or is that already the case?
>
>> There is such an option but it is currently disabled due to missing support in xen.
> Thanks. But don't understand. What has LZMA todo with Xen?

https://bugzilla.redhat.com/show_bug.cgi?id=515831



From a.badger at gmail.com  Sat Oct 31 17:12:10 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 31 Oct 2009 10:12:10 -0700
Subject: What to do with package that wants to use sse?
In-Reply-To: <1257006793.2314.145.camel@adam.local.net>
References: <20091031040724.GA22910@wolff.to>
	
	<20091031142922.GA23171@wolff.to>
	<1257006793.2314.145.camel@adam.local.net>
Message-ID: <20091031171210.GB860@clingman.lan>

On Sat, Oct 31, 2009 at 09:33:13AM -0700, Adam Williamson wrote:
> On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:
> 
> > That is very useful information. It sounds like I will want to do this for
> > this package, since enabling sse2 will turn on the sse instructions and sse2
> > might turn out to be useful for this code as well.
> > 
> > > Now I would really like to promote a comprehensive understanding of that policy.
> > 
> > It would be nice to have an example of how do the build for something like this
> > in one spec file.
> 
> The documentation there is is at
> https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
> 
> but it's not a lot.
> 
We could definitely use a more comprehensive section that addresses the need
to build the library twice, where to drop the resulting libs on the
filesystem, and what flags are/are not supported by the linker.

If someone would like to create a packaging draft for the packaging
committee that wouldbe wonderful.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

From lemenkov at gmail.com  Sat Oct 31 17:31:16 2009
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 31 Oct 2009 20:31:16 +0300
Subject: How to add upstream developer as a (co)maintainer of the existing 
	application?
Message-ID: 

Hello All!

There is a package, already included in Fedora, and there is a
friendly and active upstream developer, who wants to be a
(co)maintainer of this app. (S)he doesn't maintain any packages in
Fedora currently. So the question is - is there a policy on how such
situations should be handled?

I remember, that if Redhat hires someone from upstream, then no
additional procedures with review requests and sponsorship needed (at
least visible to others, outside Redhat) - (s)he just started to be a
(co)maintainer.

-- 
With best regards, Peter Lemenkov.



From bruno at wolff.to  Sat Oct 31 17:40:48 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Oct 2009 12:40:48 -0500
Subject: How to add upstream developer as a (co)maintainer of the
 existing application?
In-Reply-To: 
References: 
Message-ID: <20091031174048.GA17985@wolff.to>

On Sat, Oct 31, 2009 at 20:31:16 +0300,
  Peter Lemenkov  wrote:
> 
> There is a package, already included in Fedora, and there is a
> friendly and active upstream developer, who wants to be a
> (co)maintainer of this app. (S)he doesn't maintain any packages in
> Fedora currently. So the question is - is there a policy on how such
> situations should be handled?

I don't know the exact procedure, but they still need to be sponsored.
Sponsors are allowed to sponsor people who are not primary maintainers
of a package.

Because maintaining the package upstream doesn't necessarily mean that
the person knows what they need to be a good Fedora packager, this isn't
going to be automatic.



From jreiser at bitwagon.com  Sat Oct 31 20:02:50 2009
From: jreiser at bitwagon.com (John Reiser)
Date: Sat, 31 Oct 2009 13:02:50 -0700
Subject: Kernel using LZMA compression
In-Reply-To: 
References: 		
	
Message-ID: <4AEC97EA.8070603@bitwagon.com>

>> Thanks. But don't understand. What has LZMA todo with Xen?

> https://bugzilla.redhat.com/show_bug.cgi?id=515831

The executive summary is: Xen does not let a kernel boot itself,
because mimicking bare hardware is too tedious (and pointless.)
Instead, Xen instantiates an instance of a kernel into the Xen
environment.  To do this instantiation, Xen does its own decom-
pression, so Xen must know everything about the compression.

-- 



From choeger at cs.tu-berlin.de  Sat Oct 31 11:51:43 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sat, 31 Oct 2009 12:51:43 +0100
Subject: Feature request: AMD K10 thermal sensors
In-Reply-To: <4AE99DDB.80105@redhat.com>
References: <1256816304.2552.3.camel@choeger5.umpa.netz>
	<4AE99DDB.80105@redhat.com>
Message-ID: <1256989904.2630.0.camel@choeger5.umpa.netz>

Am Donnerstag, den 29.10.2009, 14:51 +0100 schrieb Michal Schmidt:
> Dne 29.10.2009 12:38, Christoph H?ger napsal(a):
> > since a year or so the AMD K10 thermal sensors module (k10temp) seems to
> > be floating around  the web. I would appreciate some kernel packager
> > integrating it into the fedora 11 stock kernel - since without it I can
> > not build (and trust!) a silent cooling system.
> >
> > Any plans on this issue?
> 
> AMD K10 sensors support has been repeatedly refused by upstream 
> lm_sensors developers because of the sensors' unreliability.
> 
> e.g. Rudolf Marek said in LKML on 2009-08-28:
> > There is a problem that all chips of fam10h have some errata which renders the
> > monitoring driver unusable. Some people proposed a workaround if temps look too
> > suspicious to refuse to load. This is against a sense of monitoring to refuse
> > the values where they don't look "right". So there is no driver.
> 
> Michal


Just one question: How are the lm_sensors names (10h, 11h) related to
current processors? 11h seems to be WIP.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: 

From kevin at scrye.com  Sat Oct 31 20:38:35 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 31 Oct 2009 14:38:35 -0600
Subject: Addition to the Policy for non responsive maintainers
Message-ID: <20091031143835.3474f21c@ohm.scrye.com>

Greetings.

FESCo has made an additional 'fast track' process for non responsive
maintainers available for some rare cases. 

See
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Fast_Track_procedure
for more details. 

See https://fedorahosted.org/fesco/ticket/251 for more discussion. 

As well as:
http://meetbot.fedoraproject.org/fedora-meeting/2009-09-18/fedora-meeting.2009-09-18-16.59.log.html#l-31
For the meeting discussion. 

Sorry for the delay in writing this up and announcing it. 
We have enacted a new process that should update the wiki and make
announcements like these whenever policy is changed. 

thanks,

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce