From mjs at clemson.edu Tue Jul 1 00:23:03 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Tue, 01 Jul 2008 00:23:03 +0000 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214854016.353.26.camel@localhost.localdomain> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> <1214854016.353.26.camel@localhost.localdomain> Message-ID: <1214871783.18111.17.camel@valkyrie.localdomain> On Mon, 2008-06-30 at 15:26 -0400, Simo Sorce wrote: > On Mon, 2008-06-30 at 18:38 +0000, Matthew Saltzman wrote: > > > > My original point was simply that interoperability of GPL software and > > software released under a number of other FOSS licenses is hindered by > > the GPL's prohibition^H^H^H^H^H^H^H^H^H^H^H lack of permission to > > distribute combined works. Unfortunately, an all-GPL world is a > > utopian > > dream; the real world is more complicated and more frustrating. > > Sorry but this comment is either grossly imprecise and dictated by hurry > in writing up[, or it underlines a gross misunderstanding of the GPL. In > either case, as it is just false. > > First, a copyleft license by nature, cannot be compatible with just any > license, but only with licenses that follow certain rules, for obvious > reasons. Trying to discuss this point is like trying to argue that > gravity sucks and whine about it. Any license, by nature, cannot be compatible with just any other license (except for distribution in the public domain). I don't know of another license that prohibits linking to libraries based on the library license terms. On the other hand, the "My license is red hot; your license ain't doodly-squat" attitude of some GPL defenders isn't terribly helpful either. > > Second, you should really differentiate between GPLv2 and GPLv3, as > GPLv3 address, with many others, also the license compatibility problem, > making GPLv3 more compatible with other copyleft licenses. Some of them. It doesn't help if it's not compatible with the license of the software you need at that moment. > > Third and not less important the first, the GPL (v2/3) does NOT prohibit > distribution of combined works as long as all pieces use GPL compatible > licenses. That's what I meant. Sorry if I wasn't clear. > > Being GPL compatible is not difficult at all, in most cases modern > licenses that are not GPL (at least v3) compatible, are not by choice, > so you should really look at both sides of the equation, you cannot > blame the GPL for lack of compatibility, compatibility is always a two > sides story. That said I am not pointing fingers at anyone, as I believe > everyone have the right to choose and draft the license for their own > software they way they want. Many licenses that are not compatible with GPLv3 are so because they were written before GPLv3 existed. The differences between GPLv3 and CPL seems from what I've read to be due to relatively technical legal points, such as the "choice of law" clause in the CPL (which predates the GPLv3). > > Finally, please let's keep this para-legal quasi-trolling off the > fedora-*DEVEL* mailing list thanks. I was happy to let the thread die back a couple weeks ago. > > > Simo. > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From rda at rincon.com Tue Jul 1 01:51:31 2008 From: rda at rincon.com (Bob Arendt) Date: Mon, 30 Jun 2008 18:51:31 -0700 Subject: how to startup without a display manager In-Reply-To: <20080630233900.GS20457@bakeyournoodle.com> References: <48696CDD.5020002@gmail.com> <20080630233900.GS20457@bakeyournoodle.com> Message-ID: <48698DA3.6010302@rincon.com> Tony Breeds wrote: > On Mon, Jun 30, 2008 at 06:31:41PM -0500, Ted X Toth wrote: >> I want to play with Openbox on Fedora as a standalone window manager. Do >> I need to configure /etc/X11/prefdm to not start any display manager? > > IIRC (it's been a while) You change the default init level from 5 to 3. > > You can do this by either: > a) changing the "id" line of /etc/inittab from: > id:5:initdefault: > to > id:3:initdefault: > and rebooting > or; > b) Appending a "3" to your kernel options, and rebooting. > > That should leave you at a console login, from which you can startx > > Yours Tony > > linux.conf.au http://www.marchsouth.org/ > Jan 19 - 24 2009 The Australian Linux Technical Conference! > c) Without rebooting - change to vt (say, ctl-alt-F1). init 3 (go to runlevel 3, no Xserver) startx /usr/bin/xterm (manually start the Xserver with a program) This example used xterm. I'll use this for quick xserver tests. When the xserver comes up, I'll start a window manager at the command line (say, "twm"). Then I can run things like glxgears in a fairly raw environment. You can use a window manager as the start program as well (/usr/bin/metacity) or a session startup (/usr/bin/startxfce4). It's important to give the full path of the executable to startx. When the original program quits, the Xserver exits (like exiting the original xterm). To get back to the normal graphical mode, type "init 5". The init commands have to issued as root. It's best to use a seperate VT and login as a mortal user to run startx (as noted in earlier threads, many advise against running an X-session as root). Have fun. Cheers, -Bob Arendt From abartlet at samba.org Tue Jul 1 02:01:37 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 01 Jul 2008 12:01:37 +1000 Subject: Help wanted with Samba4 and OpenChange Message-ID: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> I've recently been working on packaging Heimdal, Samba4 and OpenChange for Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - OpenChange) This will enable much better access to Microsoft Exchange servers from clients such as kdepim, and hopefully Evolution (pending a re-licensing). I've got a feature page for this here: https://fedoraproject.org/wiki/Features/OpenChange Now, the reason I'm posting here is that I would rather not do this alone, and would love some co-maintainers of the packagers above, or at least some help with the review and sponsorship, or advise on the best way forward. Any assistance gratefully received, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Jul 1 03:33:31 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 30 Jun 2008 22:33:31 -0500 Subject: Fedora Freedom and linux-libre In-Reply-To: <1214757565.14710.25.camel@valkyrie.localdomain> References: <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> Message-ID: <1218b5bc0806302033x7c86a0d2w7d3645383508657b@mail.gmail.com> On Sun, Jun 29, 2008 at 11:39 AM, Matthew Saltzman wrote: > Good for them. (No sarcasm intended.) But an anecdote is not a proof. I'm countering the implied FUD that the GPL scares away commercial developers by pointing out how copyleft licenses can in fact attract commercial development to the open source model who would otherwise avoid it, as copyleft licenses can protect their bottom line in a way that so-called "permissive" licenses can not. And I even gave a concrete example, lets call it a case study. Which is more than what you're giving. The GPL is not the only license that protects code released under it > from incorporation into proprietary products. But some clauses in the > GPL prevent interoperability with other software that (for whatever > reason) was released under different licenses that even the FSF > acknowledges are in the spirit of freedom and open source. That's too > bad for free and open-source software. This is what you call a 'bug'. Yes, bugs are unfortunate, but bugs can be fixed. Lets look at another case study: It just so happens that the Second Life client has run in to this. It uses the APR library, which is under the Apache License 2.0, which on a technicality is incompatable with the GPLv2. Linden Lab solved this by "patching" the GPL by giving a FLOSS exception. Problem solved. And it just so happens the FSF released a new version of the GPL, version 3 which fixes the Apache License incompatability. Unfortunately Linden Lab chose GPLv2 Only, me and others have asked them to update to GPLv3, or at least switch to GPLv2+, but it has been blown off as being rather low priority for them... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Tue Jul 1 03:49:45 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 30 Jun 2008 22:49:45 -0500 Subject: Question regarding Asterisk audio license and Fedora In-Reply-To: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> References: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> Message-ID: <20080701034945.GA6715@wolff.to> On Mon, Jun 30, 2008 at 18:25:38 -0500, "W. Michael Petullo" wrote: > I am trying to help get some voice recordings for the Asterisk PBX into > Fedora. These support features like voicemail and an echo test. > > Unfortunately, the audio files are not released with a clear license. As > far as I know, the woman who made the recordings does not want the > recordings used for commercial purposes. However, I am still looking for > this in writing. Does anyone know of a clear statement on this matter from > the copyright holder? Did you talk to the Callweaver guys to see what they are doing? From jwilliam at xmission.com Tue Jul 1 04:19:40 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Mon, 30 Jun 2008 22:19:40 -0600 Subject: GUI root login and NTFS mounts? Message-ID: When I login as root with the GUI my NTFS file systems get mounted. And if I logout and login as a normal user they are still mounted. This seems like it may be a bug to me. If I login first as a normal user they aren't mounted. What is mounting them and how can I control if a file system gets mounted or not? They aren't listed in /etc/fstab and they get mounted under /media. I would like to figure this out so I don't have to login as root to mount them. And I don't want them all mounted either. Thanks! Jerry Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From clydekunkel7734 at cox.net Tue Jul 1 05:14:40 2008 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Tue, 01 Jul 2008 01:14:40 -0400 Subject: GUI root login and NTFS mounts? In-Reply-To: References: Message-ID: <4869BD40.2060305@cox.net> Jerry Williams wrote: > When I login as root with the GUI my NTFS file systems get mounted. > > > > And I don?t want them all mounted either. > I found the following resolved the problem for me (from an oldish thread): > maybe related to this > https://www.redhat.com/archives/fedora-test-list/2008-May/msg00935.html > > IIRC (?) > > > Old stuff: > > Fedora 7 has a file called > /usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi > to prevent this from happening, here's its contents: > > > > > > > true > > > > > > If that file is no longer there in Fedora 8, try adding it and see if > that > helps. > > > HTH > > -- Ronald Warsow --------------------------------- Regards, Old Fart From j.w.r.degoede at hhs.nl Tue Jul 1 07:59:33 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 01 Jul 2008 09:59:33 +0200 Subject: Dependencies breakage in released Fedora versions (twice now) Message-ID: <4869E3E5.2080809@hhs.nl> Hi All, The last week I've had bugs filed twice against packages I maintain because their dependencies had broken, and this is not with rawhide but in F-9 and F-8 !! One of these 2 breakages was due to a php version bump for security reasons, and I can live with that. One kind request to Joe Orton (in the CC) though, next time if you have the time please remember that maniadrive has a full versioned dependency on php and will break with each upstream version change. All my packages are wide open so next time please feel free to rebuild maniadrive and include it in the update. The other dependency breakage though is due to rddtool (which also included a shared libary) being updated from a release candidate to the final, and this change includes a soname change. This is not acceptable in a released version unless there is a _really_ _really_ good reason, and even if there is a really_ _really_ good reason this should have been coordinated with any dependend packages. Perhaps we can add a dependency check in bodhi, or if that slows bodhi down to much atleast run the dep-checking script currently run on rawhide also on "F-x + upodates + updates-testing", running the dep-checking script on "F-x + upodates + updates-testing" would have caught both these dep breakages as both packages have gone through testing first. Then any broken deps should be mailed to the maintainers of the involved packages and to rel-eng, which then should block (or completely reject) non critical updates until the deps are solved. Regards, Hans From bnocera at redhat.com Tue Jul 1 09:35:57 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 01 Jul 2008 10:35:57 +0100 Subject: Evolution glib problems anyone? In-Reply-To: <20080630103158.M50149@all-the-johnsons.co.uk> References: <20080630103158.M50149@all-the-johnsons.co.uk> Message-ID: <1214904957.5014.14.camel@cookie.hadess.net> On Mon, 2008-06-30 at 11:35 +0100, Paul F. Johnson wrote: > Hi, > > I'm trying to start up evolution and all I seem to get are the following back > > [paul at t7 ~]$ evolution > CalDAV Eplugin starting up ... > ** (evolution:4765) : DEBUG: mailto URL command: evolution %s > ** (evolution>7465) : DEBUG: mailto URL program: evolution > > GLib-ERROR **: gmem.c:136: failed to allocate 31740376080 bytes > aborting... > Trace/breakpoint trap > > I'm not sure why it's trying to allocate such a huge amount of memory either. That's a bug in the caller, usually memory that was trampled on. Try running evolution in valgrind. Running under gdb will only give you the location of where that memory corruption has had effect. From j.w.r.degoede at hhs.nl Tue Jul 1 09:42:28 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 01 Jul 2008 11:42:28 +0200 Subject: Dependencies breakage in released Fedora versions (twice now) In-Reply-To: <4869E3E5.2080809@hhs.nl> References: <4869E3E5.2080809@hhs.nl> Message-ID: <4869FC04.7070003@hhs.nl> Hans de Goede wrote: > Hi All, > > The last week I've had bugs filed twice against packages I maintain > because their dependencies had broken, and this is not with rawhide but > in F-9 and F-8 !! > I've just learned that the rrdtool update breaks 2 more packages, bad bad bad! Regards, Hans From jorton at redhat.com Tue Jul 1 09:42:45 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 1 Jul 2008 10:42:45 +0100 Subject: Dependencies breakage in released Fedora versions (twice now) In-Reply-To: <4869E3E5.2080809@hhs.nl> References: <4869E3E5.2080809@hhs.nl> Message-ID: <20080701094244.GA7073@redhat.com> On Tue, Jul 01, 2008 at 09:59:33AM +0200, Hans de Goede wrote: > One of these 2 breakages was due to a php version bump for security > reasons, and I can live with that. One kind request to Joe Orton (in the > CC) though, next time if you have the time please remember that > maniadrive has a full versioned dependency on php and will break with > each upstream version change. All my packages are wide open so next time > please feel free to rebuild maniadrive and include it in the update. Sure - sorry, I keep forgetting I need to do this. joe From rjones at redhat.com Tue Jul 1 09:39:29 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 1 Jul 2008 10:39:29 +0100 Subject: Dependencies breakage in released Fedora versions (twice now) In-Reply-To: <4869FC04.7070003@hhs.nl> References: <4869E3E5.2080809@hhs.nl> <4869FC04.7070003@hhs.nl> Message-ID: <20080701093929.GA7701@amd.home.annexia.org> On Tue, Jul 01, 2008 at 11:42:28AM +0200, Hans de Goede wrote: > Hans de Goede wrote: >> Hi All, >> >> The last week I've had bugs filed twice against packages I maintain >> because their dependencies had broken, and this is not with rawhide but in >> F-9 and F-8 !! > > I've just learned that the rrdtool update breaks 2 more packages, bad bad bad! .. and collectd. 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 paul at all-the-johnsons.co.uk Tue Jul 1 10:29:16 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 1 Jul 2008 11:29:16 +0100 Subject: Evolution glib problems anyone? In-Reply-To: <1214904957.5014.14.camel@cookie.hadess.net> References: <20080630103158.M50149@all-the-johnsons.co.uk> <1214904957.5014.14.camel@cookie.hadess.net> Message-ID: <20080701102211.M10249@all-the-johnsons.co.uk> Hi, > That's a bug in the caller, usually memory that was trampled on. Try > running evolution in valgrind. Running under gdb will only give you the > location of where that memory corruption has had effect. Valgrind is showing some interesting stuff which looks camel related - see attached, I'll also post it to the BZ filed #453421 TTFN Paul -- Programmer, GirlGamer www.girlgamer.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: evolution-error.txt URL: From ivazqueznet at gmail.com Tue Jul 1 10:45:58 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 01 Jul 2008 06:45:58 -0400 Subject: Dependencies breakage in released Fedora versions (twice now) In-Reply-To: <4869E3E5.2080809@hhs.nl> References: <4869E3E5.2080809@hhs.nl> Message-ID: <1214909158.30544.142.camel@ignacio.lan> On Tue, 2008-07-01 at 09:59 +0200, Hans de Goede wrote: > Perhaps we can add a dependency check in bodhi, or if that slows bodhi down to > much atleast run the dep-checking script currently run on rawhide also on "F-x > + upodates + updates-testing", running the dep-checking script on "F-x + > upodates + updates-testing" would have caught both these dep breakages as both > packages have gone through testing first. https://fedorahosted.org/bodhi/ticket/79 -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Tue Jul 1 10:58:24 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 01 Jul 2008 11:58:24 +0100 Subject: Fedora Freedom and linux-libre In-Reply-To: <48693698.9090803@gmail.com> References: <4856C6CE.4020107@gmail.com> <1213821124.11083.30.camel@valkyrie.localdomain> <1213831117.11083.63.camel@valkyrie.localdomain> <1213903944.12452.23.camel@valkyrie.localdomain> <200806192104.m5JL4XBZ014337@laptop13.inf.utfsm.cl> <1213915327.17201.22.camel@valkyrie.localdomain> <1218b5bc0806290853q2e216fdbo9b78fd1874241147@mail.gmail.com> <1214757565.14710.25.camel@valkyrie.localdomain> <1214757728.3307.43.camel@localhost.localdomain> <1214838652.25060.32.camel@valkyrie.localdomain> <29589.192.54.193.59.1214840085.squirrel@rousalka.dyndns.org> <1214851086.25060.66.camel@valkyrie.localdomain> <1214854016.353.26.camel@localhost.localdomain> <48693698.9090803@gmail.com> Message-ID: <486A0DD0.3030001@redhat.com> Les Mikesell wrote: > Simo Sorce wrote: >> >> Sorry but this comment is either grossly imprecise and dictated by hurry >> in writing up[, or it underlines a gross misunderstanding of the GPL. In >> either case, as it is just false. >> >> First, a copyleft license by nature, > > Can you define copyleft? Oh, come on, you're trolling now. Copyleft is a well-understood term, common in any discussion of software licences. If you don't know what it means I suggest you should leave this argument forthwith. Andrew. From rawhide at fedoraproject.org Tue Jul 1 11:00:07 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 1 Jul 2008 11:00:07 +0000 (UTC) Subject: rawhide report: 20080701 changes Message-ID: <20080701110007.AE345209D2E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080630/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080701/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package btrfs-progs Userspace programs for btrfs New package clive Video extraction tool for user-uploaded video hosts New package libcxgb3 Chelsio T3 iWARP HCA Userspace Driver New package libformula Formula Parser New package libibcommon OpenFabrics Alliance InfiniBand management common library New package libibmad OpenFabrics Alliance InfiniBand MAD library New package libibumad OpenFabrics Alliance InfiniBand umad (user MAD) library New package libloader Resource Loading Framework New package libzrtpcpp ZRTP support library for the GNU ccRTP stack New package mairix A program for indexing and searching email messages New package perl-Test-WWW-Selenium Perl Client for the Selenium Remote Control test tool New package portreserve TCP port reservation utility Updated Packages: PolicyKit-0.8-3.fc10 -------------------- * Mon Jun 30 18:00:00 2008 - Bastien Nocera - 0.8-3.fc10 - Upstream patch to allow root to read auths automoc-1.0-0.7.beta2.fc10 -------------------------- * Mon Jun 30 18:00:00 2008 Rex Dieter 1.0-0.7.beta2 - automoc4-0.9.83 (aka 1.0beta2) - drop lib64 patch baekmuk-ttf-fonts-2.2-9.fc10 ---------------------------- certmaster-0.20-2.fc10 ---------------------- * Fri Jun 6 18:00:00 2008 Adrian Likins - 0.20-2 - fix fedora bug #441283 - typo in postinstall scriptlet (the init.d symlinks for runlevels 1 and 6 were created wrong) * Tue Apr 15 18:00:00 2008 Steve Salevan - 0.19-3 - added in trigger directories * Tue Apr 15 18:00:00 2008 Michael DeHaan - 0.20-1 - new release - fix changelog versions * Mon Mar 17 18:00:00 2008 Adrian Likins - 0.19-2 - removed unused minion/ and overlord/ dirs cjkunifonts-0.1.20060928-6.fc10 ------------------------------- func-0.20-1.fc10 ---------------- * Sat Jun 28 18:00:00 2008 Adrian Likins - 0.18-2 - fix fedora bug #441283 - typo in postinstall scriptlet (the init.d symlinks for runlevels 1 and 6 were created wrong) icu-4.0-0.3.d03.fc10 -------------------- * Mon Jun 30 18:00:00 2008 Caolan McNamara - 4.0-0.3.d03 - 4.0 release candidate * Wed Jun 4 18:00:00 2008 Caolan McNamara - 4.0-0.2.d02 - drop icu.icu5498.openoffice.org.patch jd-2.0.0-0.6.svn2159_trunk.fc10 ------------------------------- * Tue Jul 1 18:00:00 2008 Mamoru Tasaka - svn 2159 kde-settings-4.0-24.fc9 ----------------------- * Tue May 20 18:00:00 2008 Rex Dieter 4.0-24 - kdm pam settings need to sync with gdm (#447245) kernel-2.6.26-0.98.rc8.git1.fc10 -------------------------------- * Mon Jun 30 18:00:00 2008 Dave Jones - 2.6.26-rc8-git1 libgpod-0.6.0-6.fc10 -------------------- * Mon Jun 30 18:00:00 2008 Dan Horak - 0.6.0-6 - add patch for sg3_utils 1.26 and rebuild libipoddevice-0.5.3-5.fc10 -------------------------- * Mon Jun 30 18:00:00 2008 Dan Horak - 0.5.3-5 - add patch for sg3_utils 1.26 and rebuild liferea-1.4.15-6.fc9 -------------------- lsvpd-1.6.4-3.fc10 ------------------ * Mon Jun 30 18:00:00 2008 - Dan Horak - 1.6.4-3 - add patch for sg3_utils 1.26 and rebuild manedit-1.1.1-1.fc10 -------------------- * Mon Jun 30 18:00:00 2008 Mamoru Tasaka - 1.1.1-1 - 1.1.1 - Seems that URL are moved temporarily - Fix segv on clicking "Index" on manview - Fix potentially insecure tmpdir creation mod_nss-1.0.7-5.fc10 -------------------- * Mon Jun 30 18:00:00 2008 Rob Crittenden - 1.0.7-5 - Include patch to fix NSSFIPS (446851) mysql-proxy-0.6.1-2.fc10 ------------------------ * Mon Jun 30 18:00:00 2008 Ruben Kerkhof - 0.6.1-2 - Rebuild to pick up new libevent mythes-de-0.20080630-1.fc10 --------------------------- * Mon Jun 30 18:00:00 2008 Caolan McNamara - 0.20080630-1 - latest version nfs-utils-1.1.2-11.fc10 ----------------------- * Mon Jun 30 18:00:00 2008 Steve Dickson 1.1.2-10 - Rebuild for the updated libevent lib. * Mon Jun 30 18:00:00 2008 Dennis Gilmore 1.1.2-11 - add sparc arch handling nkf-2.0.8b-3.fc10 ----------------- * Tue Jul 1 18:00:00 2008 Akira TAGOH - 1:2.0.8b-3 - Add perl(:MODULE_COMPAT_...) deps. (#453413) openoffice.org-3.0.0-0.0.20.1.fc10 ---------------------------------- * Thu Jun 26 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.20-1 - next version - Resolves: rhbz#450661 openoffice.org-3.0.0.ooo90306.sw.wrongprotection.patch - Resolves: rhbz#448464 openoffice.org-3.0.0.ooo48400.svx.fixspelling.patch - Resolves: rhbz#450930 openoffice.org-3.0.0.ooo90697.sd.a11ycrash.patch - Resolves: rhbz#451512 set better math default print options - Resolves: rhbz#451708 openoffice.org-3.0.0.oooXXXXX.connectivity.mozprofilefinder.patch - Resolves: rhbz#452777 Ukranian langpack - drop integrated openoffice.org-3.0.0.ooo87882.lingucomponent.systemdicts.patch - drop integrated openoffice.org-3.0.0.ooo87604.fixupsystemhunspell.patch - drop integrated openoffice.org-3.0.0.ooo90071.chart2.negativecount.patch - add openoffice.org-3.0.0.ooo90876.connectivity.evoab2.patch patch-2.5.4-35.fc10 ------------------- * Mon Jun 30 18:00:00 2008 Tim Waugh 2.5.4-35 - Don't fail if setfilecon() returns EPERM (bug #453365), although the setfilecon man page suggests that ENOTSUP will be returned in this case. perl-MooseX-AttributeHelpers-0.12-2.fc10 ---------------------------------------- * Mon Jun 30 18:00:00 2008 Chris Weyl 0.12-2 - ...and fix filtering. heh. * Mon Jun 30 18:00:00 2008 Chris Weyl 0.12-1 - update to 0.12 - switch to Module::Install incantations - update BR's - update provides filtering * Wed May 28 18:00:00 2008 Chris Weyl 0.09-1 - update to 0.09 perl-Net-Netmask-1.9015-2.fc10 ------------------------------ * Mon Jun 30 18:00:00 2008 Paul Howarth - 1.9015-2 - Add perl(:MODULE_COMPAT...) dependency (#449362) - Remove redundant buildreq perl - Fix "make check" syntax - Fix argument order for find with -depth perl-Net-SSH2-0.18-5.fc10 ------------------------- * Mon Jun 30 18:00:00 2008 Chris Weyl 0.18-5 - apply patch for 5.10 perl-Perl-Critic-1.082-1.fc10 ----------------------------- * Sun Mar 9 18:00:00 2008 Chris Weyl 1.082-1 - update to 1.082 - resolve BZ#431577 - add t/ examples/ extras/ tools/, and filter perl-Sub-Exporter-0.979-1.fc10 ------------------------------ * Mon Jun 30 18:00:00 2008 Chris Weyl 0.979-1 - update to 0.979 - drop BR's on: perl(Test::Pod::Coverage), perl(Test::Pod) php-pear-PHP-CodeSniffer-1.1.0-0.1.RC2.fc10 ------------------------------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 1.1.0-0.1.RC2 - Upstream 1.1.0RC2 php-pear-PhpDocumentor-1.4.2-1.fc10 ----------------------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 1.4.2-1 - Upstream 1.4.2. policycoreutils-2.0.50-1.fc10 ----------------------------- * Mon Jun 30 18:00:00 2008 Dan Walsh 2.0.50-1 - Update to upstream * Fix audit2allow generation of role-type rules from Karl MacMillan. python-BeautifulSoup-3.0.7-2.fc10 --------------------------------- * Mon Jun 30 18:00:00 2008 Terje Rosten - 3.0.7-2 - Rebuild * Mon Jun 23 18:00:00 2008 Michel Alexandre Salim - 3.0.7-1 - Update to 3.0.7 python-kiwi-1.9.22-1.fc10 ------------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 1.9.22-1 - Upstream 1.9.22 python-logilab-common-0.32.0-1.fc10 ----------------------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 0.32.0-1 - Upstream 0.32.0 python-pgsql-0.9.7-1.fc10 ------------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 0.9.7-1 - Upstream 0.9.7 - Adjust URL and Source to the PyPi location revisor-2.1.1-5.fc10 -------------------- * Mon Jun 30 18:00:00 2008 Jeroen van Meeuwen 2.1.1-5 - Latest rebuild - Fix running GUI - Add check for architecture composing - Bugfixes in live media creation - Add bluray disc support - F-9 Release rsync-3.0.3-0.fc10 ------------------ * Mon Jun 30 18:00:00 2008 Simo Sorce 3.0.3-0.fc10 - New upstream release ruby-1.8.6.230-3.fc10 --------------------- * Mon Jun 30 18:00:00 2008 Akira TAGOH - 1.8.6.230-3 - Backported from upstream SVN to fix a segfault issue. (#452825) - Backported from upstream SVN to fix an integer overflow in rb_ary_fill. scanssh-2.1-17.fc10 ------------------- * Mon Jun 30 18:00:00 2008 Patrick "Jima" Laughton 2.1-17 - Rebuild for new libevent scim-1.4.7-26.fc10 ------------------ * Mon Jun 30 18:00:00 2008 Jens Petersen - 1.4.7-26.fc10 - make xinput script no longer require multilib immodules (Julian Sikorski, #448268) - remove the hacks in xinput script counting the number of IMEs sg3_utils-1.26-1.fc10 --------------------- * Mon Jun 30 18:00:00 2008 Dan Horak - 1.26-1 - update to upstream version 1.26 system-config-printer-1.0.3-1.fc10 ---------------------------------- * Mon Jun 30 18:00:00 2008 Tim Waugh 1.0.3-1 - Updated pycups to 1.9.40. - 1.0.3. * Fri Jun 20 18:00:00 2008 Tim Waugh - Updated pysmbc to 1.0.4. twinkle-1.2-3.fc10 ------------------ * Mon Jun 30 18:00:00 2008 Kevin Fenzi - 1.2-3 - Rebuild with libzrtpcpp vala-0.3.4-1.fc10 ----------------- * Tue Jul 1 18:00:00 2008 Lennart Poettering - 0.3.4-1 - Update to 0.3.4 vdr-femon-1.6.1-1.fc9 --------------------- * Sun Jun 22 18:00:00 2008 Ville Skytt?? - 1.6.1-1 - 1.6.1. verbiste-0.1.23-1.fc10 ---------------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 0.1.23-1 - Upstream 0.1.23 xerces-c-2.8.0-2.fc10 --------------------- * Mon Jun 30 18:00:00 2008 Peter Lemenkov 2.8.0-2 - Spec cleanups ( https://bugzilla.redhat.com/show_bug.cgi?id=435132 ) xorg-x11-drv-radeonhd-1.2.1-3.3.20080630git.fc10 ------------------------------------------------ * Mon Jun 30 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.3.20080630git - New snapshot (upstream commit c2139d8c7aed128644dcb1481426164ece0b967d): - c2139d8c: R5xx Accel: another 2DFlush fix... - dbc7057d: R5xx EXA: Destroy Nulls the XAAInfo... Oops... - 5fe51b2e: r5xx accel: bring 2DFlush and engine initialisation into the r300+ era. - 85ae6e1b: r5xx accel: move r5xx_2dregs to r5xx_regs.c. - 39209b36: rhddump: bail out correctly when no pci-tag is provided. - 10d5a41d: DAC: Program TV mux only for DACB. - 7825387b: CloseScreen: Fix test for AccelMethod. xorg-x11-server-utils-7.4-1.fc10 -------------------------------- * Mon Jun 30 18:00:00 2008 Adam Jackson 7.4-1 - Drop xtrap utils, it's deprecated upstream. yaz-3.0.34-1.fc10 ----------------- * Mon Jun 30 18:00:00 2008 Konstantin Ryabitsev - 3.0.34-1 - Upstream 3.0.34 Summary: Added Packages: 12 Removed Packages: 0 Modified Packages: 49 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 pygoocanvas-0.9.0-3.fc9.i386 requires goocanvas = 0:0.9 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 pygoocanvas-0.9.0-3.fc9.x86_64 requires goocanvas = 0:0.9 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 pygoocanvas-0.9.0-3.fc9.ppc requires goocanvas = 0:0.9 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot pygoocanvas-0.9.0-3.fc9.ppc64 requires goocanvas = 0:0.9 scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From tcallawa at redhat.com Tue Jul 1 11:42:39 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 Jul 2008 07:42:39 -0400 Subject: Question regarding Asterisk audio license and Fedora In-Reply-To: <80d7e4090806301656u180411b8w5d13b279199e57d2@mail.gmail.com> References: <14871.76.6.125.15.1214868338.squirrel@mail.voxel.net> <80d7e4090806301656u180411b8w5d13b279199e57d2@mail.gmail.com> Message-ID: <1214912559.10104.2.camel@localhost.localdomain> On Mon, 2008-06-30 at 17:56 -0600, Stephen John Smoogen wrote: > Sandra had the best phone voice I have dealt with in many years. She is no longer with Red Hat. I could probably still ask her about it though. ~spot From txtoth at gmail.com Tue Jul 1 12:24:23 2008 From: txtoth at gmail.com (Ted X Toth) Date: Tue, 01 Jul 2008 07:24:23 -0500 Subject: how to startup without a display manager In-Reply-To: <48698DA3.6010302@rincon.com> References: <48696CDD.5020002@gmail.com> <20080630233900.GS20457@bakeyournoodle.com> <48698DA3.6010302@rincon.com> Message-ID: <486A21F7.1000407@gmail.com> Bob Arendt wrote: > Tony Breeds wrote: >> On Mon, Jun 30, 2008 at 06:31:41PM -0500, Ted X Toth wrote: >>> I want to play with Openbox on Fedora as a standalone window >>> manager. Do I need to configure /etc/X11/prefdm to not start any >>> display manager? >> >> IIRC (it's been a while) You change the default init level from 5 to 3. >> >> You can do this by either: >> a) changing the "id" line of /etc/inittab from: >> id:5:initdefault: >> to >> id:3:initdefault: >> and rebooting >> or; >> b) Appending a "3" to your kernel options, and rebooting. >> >> That should leave you at a console login, from which you can startx >> >> Yours Tony >> >> linux.conf.au http://www.marchsouth.org/ >> Jan 19 - 24 2009 The Australian Linux Technical Conference! >> > > c) Without rebooting - change to vt (say, ctl-alt-F1). > init 3 (go to runlevel 3, no Xserver) > startx /usr/bin/xterm (manually start the Xserver with a > program) > > This example used xterm. I'll use this for quick xserver tests. > When the xserver comes up, I'll start a window manager at the command > line (say, "twm"). Then I can run things like glxgears in a fairly > raw environment. You can use a window manager as the start program > as well (/usr/bin/metacity) or a session startup (/usr/bin/startxfce4). > It's important to give the full path of the executable to startx. > > When the original program quits, the Xserver exits (like exiting the > original xterm). > > To get back to the normal graphical mode, type "init 5". > > The init commands have to issued as root. > > It's best to use a seperate VT and login as a mortal user > to run startx (as noted in earlier threads, many advise against > running an X-session as root). Have fun. > > Cheers, > -Bob Arendt > I was going to use 'init 5' instead of 'startup' in my subject line and now I see I should have. I want to boot to run level 5 and start twm or an Openbox session instead of starting gdm. Ted From skvidal at fedoraproject.org Tue Jul 1 12:25:20 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 01 Jul 2008 08:25:20 -0400 Subject: comps.rng In-Reply-To: <1214508328.19297.23.camel@metroid.rdu.redhat.com> References: <1214508328.19297.23.camel@metroid.rdu.redhat.com> Message-ID: <1214915120.19021.27.camel@rosebud> On Thu, 2008-06-26 at 15:25 -0400, Will Woods wrote: > If you check the 'comps' module in package CVS, you'll see the new file > comps.rng[1]. This is a RELAX NG[2] schema for validating the grammar of > our comps.xml files. > > We're hoping to rig this up to the CVS checkin procedure to ensure that > all changes result in valid comps files. We're also going to use it as > part of the daily acceptance testing for Rawhide. > > Nicolas Mailhot gets all the thanks for writing the schema - I just > checked it into CVS. > > If anyone would care to comment on the undocumented[3] parts of comps - > especially what the heck metapkg is for and whether we need it - it > would be greatly appreciated. > 1. groups cannot require other groups - only categories can require groups: so this section under 'group': Other groups that this group requires. can be removed entirely. 2. basearchonly no longer exists and is no longer honored in comps. So you can remove this section entirely, too: hope this helps. -sv From wolfy at nobugconsulting.ro Tue Jul 1 12:35:45 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 01 Jul 2008 15:35:45 +0300 Subject: how to startup without a display manager In-Reply-To: <486A21F7.1000407@gmail.com> References: <48696CDD.5020002@gmail.com> <20080630233900.GS20457@bakeyournoodle.com> <48698DA3.6010302@rincon.com> <486A21F7.1000407@gmail.com> Message-ID: <486A24A1.4000800@nobugconsulting.ro> Ted X Toth wrote: > I was going to use 'init 5' instead of 'startup' in my subject line > and now I see I should have. I want to boot to run level 5 and start > twm or an Openbox session instead of starting gdm. > less /etc/X11/prefdm From selinux at gmail.com Tue Jul 1 13:19:25 2008 From: selinux at gmail.com (Tom London) Date: Tue, 1 Jul 2008 06:19:25 -0700 Subject: GUI root login and NTFS mounts? In-Reply-To: <4869BD40.2060305@cox.net> References: <4869BD40.2060305@cox.net> Message-ID: <4c4ba1530807010619mca7b6cey4894505aab1a0bbd@mail.gmail.com> On Mon, Jun 30, 2008 at 10:14 PM, Clyde E. Kunkel wrote: > Jerry Williams wrote: >> >> When I login as root with the GUI my NTFS file systems get mounted. >> >> >> >> And I don't want them all mounted either. >> > I found the following resolved the problem for me (from an oldish thread): > >> maybe related to this >> https://www.redhat.com/archives/fedora-test-list/2008-May/msg00935.html >> >> IIRC (?) >> >> >> Old stuff: >> >> Fedora 7 has a file called >> >> /usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi >> to prevent this from happening, here's its contents: >> >> >> >> >> >> >> true >> >> >> >> >> >> If that file is no longer there in Fedora 8, try adding it and see if >> that helps. >> >> >> HTH >> >> -- Ronald Warsow > > > --------------------------------- > Regards, > > Old Fart I believe HAL does not try to mount partitions/devices that are in /etc/fstab, so I added an entry for the partition to /etc/fstab with "noauto". For example, I have the following line in mine: /dev/sda1 /mnt/windows ntfs-3g rw,noauto 0 0 tom -- Tom London From lystor at lystor.org.ua Tue Jul 1 13:26:29 2008 From: lystor at lystor.org.ua (Nikolay Ulyanitsky) Date: Tue, 01 Jul 2008 16:26:29 +0300 Subject: Bug in mock: Error with building kmod packages in RHEL Message-ID: <1214918789.2676.2.camel@localhost.localdomain> 1) $ mock -r redhat-5-i386 --target=i686 ipw3945-kmod-1.2.0-4.8.el5.src.rpm 2) $ rpm -qp -R /var/lib/mock/redhat-5-i386/result/kmod-ipw3945-1.2.0-4.8.el5.i686.rpm rpmlib(VersionedDependencies) <= 3.0.3-1 /sbin/depmod /sbin/depmod /bin/sh /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 [[[Requires are INCORRECT for RHEL!]]] 3) Patching backend.py: backend.py.diff --- backend.py.orig 2008-03-17 06:32:35.000000000 +0200 +++ backend.py 2008-07-01 15:47:16.000000000 +0300 @@ -291,6 +291,7 @@ os.symlink("/proc/self/fd/0", self.makeChrootPath("dev/stdin")) os.symlink("/proc/self/fd/1", self.makeChrootPath("dev/stdout")) os.symlink("/proc/self/fd/2", self.makeChrootPath("dev/stderr")) + os.symlink("/proc/self/fd", self.makeChrootPath("/dev/fd")) os.umask(prevMask) # mount/umount 4) $ mock -r redhat-5-i386 --target=i686 ipw3945-kmod-1.2.0-4.8.el5.src.rpm 5) $ rpm -qp -R /var/lib/mock/redhat-5-i386/result/kmod-ipw3945-1.2.0-4.8.el5.i686.rpm rpmlib(VersionedDependencies) <= 3.0.3-1 /sbin/depmod /sbin/depmod /bin/sh /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 kernel(rhel5_net_ieee80211_ga) = 266557407e6293b3d4447d740257a79c67cb9d4b kernel(rhel5_mm_ga) = 09f63dfab81bba7e01a2bf693f5ce125db466051 kernel(rhel5_drivers_pci_ga) = 33d9e0612417f727a0d8311c229fe8a80c65bb65 kernel(rhel5_net_core_ga) = 5aae342a66dcbcc14a7c1c001624f73a13620809 kernel(rhel5_drivers_base_ga) = 2490efa8790e7d4b3c7ae4536866c48f1334a356 kernel(rhel5_kernel_ga) = 2cd142708e2d573b2de522df5df87aaeb7c1d298 kernel(rhel5_kernel_module_ga) = 1b051ce57d6b18fdf071786f6f7296d3d0ab28f9 kernel(rhel5_lib_ga) = 088a6b77cde4f82c65b0d7f34802cfa41d209328 kernel(rhel5_fs_sysfs_ga) = bb43e88ba2b9ebed086513342d9a5a18ed9355a7 kernel(rhel5_kernel_irq_ga) = 828c3f468e7a640d409d2bf24b4676e457406917 kernel(rhel5_arch_i386_mm_ga) = 0164a9bd3f1d0935cd3dcb734785179f25c1a064 kernel(rhel5_arch_i386_kernel_ga) = d1c30e0a553e9225eebd1b866e0d3ed7a6154147 kernel(rhel5_net_sched_ga) = 85d96cb2f432b540922c05edf889854d63884830 kernel(rhel5_drivers_char_ga) = 9825f97c6773e4d766359d55afa360b0c31cd1a6 kernel(rhel5_vmlinux_ga) = 2bf444396ff7060828059d7a5379435140aee48a [[[Requires are CORRECT for RHEL!]]] Please, add patch to mock to fix the error with building kmod packages in RHEL Additinal information: -------------------------------------------------------------------------------------- RHBZ#453583 -------------------------------------------------------------------------------------- ipw3945-kmod-1.2.0-4.8.el5.src.rpm can be found in rhel-5.2-server-supplementary-i386-disc1.iso -------------------------------------------------------------------------------------- $ rpm -q mock mock-0.9.7-1.el5 (from EPEL) -------------------------------------------------------------------------------------- $ cat /etc/issue Red Hat Enterprise Linux Server release 5.2 (Tikanga) -------------------------------------------------------------------------------------- $ cat /etc/mock/redhat-5-i386.cfg config_opts['root'] = 'redhat-5-i386' config_opts['target_arch'] = 'i386' config_opts['chroot_setup_cmd'] = 'install buildsys-build' config_opts['macros']['%dist'] = ".el5" config_opts['macros']['%el5'] = "2" config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 metadata_expire=1 # repos [rhel] name=rhel baseurl=file:///var/data/linux/redhat/5.2/i386 [rhel-updates] name=rhel-updates baseurl=file:///var/data/linux/redhat/5.2/updates/i386 [groups] name=groups baseurl=file:///var/data/linux/redhat/5.2/updates/groups/i386 """ -------------------------------------------------------------------------------------- $ cat /etc/mock/site-defaults.cfg config_opts['plugin_conf']['ccache_enable'] = False From jbarnes at virtuousgeek.org Tue Jul 1 15:55:38 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 1 Jul 2008 08:55:38 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> Message-ID: <200807010855.38912.jbarnes@virtuousgeek.org> On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > I've recently been working on packaging Heimdal, Samba4 and OpenChange > for Fedora. > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > OpenChange) > > This will enable much better access to Microsoft Exchange servers from > clients such as kdepim, and hopefully Evolution (pending a > re-licensing). > > I've got a feature page for this here: > > https://fedoraproject.org/wiki/Features/OpenChange > > Now, the reason I'm posting here is that I would rather not do this > alone, and would love some co-maintainers of the packagers above, or at > least some help with the review and sponsorship, or advise on the best > way forward. > > Any assistance gratefully received, I've been really looking forward to this; how can I help? What's involved with co-maintainership? At the very least I can help with testing and such... Thanks, Jesse From jspaleta at gmail.com Tue Jul 1 20:09:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 Jul 2008 12:09:47 -0800 Subject: Heads up for matplotlib and basemap users Message-ID: <604aa7910807011309u1c51e2e1yb5d90888c235217e@mail.gmail.com> I'm building python-matplotlib-0.98 python-basemap-0.99 into rawhide over the next couple of days. There are some API changes, so this is a heads up for anyone making use of theses python modules. I will NOT be putting these into F9 or F8. -jef From amadeus84 at verizon.net Tue Jul 1 23:04:55 2008 From: amadeus84 at verizon.net (Amadeus W.M.) Date: Tue, 1 Jul 2008 23:04:55 +0000 (UTC) Subject: kernel 2.6.25.7 Message-ID: Any idea when the 2.6.25.7 kernel will be pushed to updates? I desperately need a bug fix in the bttv driver. Thanks! From snecklifter at gmail.com Tue Jul 1 23:33:45 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 2 Jul 2008 00:33:45 +0100 Subject: kernel 2.6.25.7 In-Reply-To: References: Message-ID: <364d303b0807011633i641f10e1ue856c4d0af5e35c7@mail.gmail.com> Hi Amadeus, 2008/7/2 Amadeus W.M. : > Any idea when the 2.6.25.7 kernel will be pushed to updates? I desperately > need a bug fix in the bttv driver. Thanks! This is already available in -testing as a 2.6.25.9-based kernel. # yum update kernel --enablerepo=updates-testing Please note that this list is for development of fedora only - please use #fedora or fedora-list for queries such as this. Regards -- Christopher Brown http://www.chruz.com From bojan at rexursive.com Wed Jul 2 00:06:49 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 02 Jul 2008 10:06:49 +1000 Subject: Rawhide apr/apr-util packages going 1.3.x Message-ID: <1214957209.6030.5.camel@shrek.rexursive.com> Just a warning that this may cause breakage for various software that depends on APR and APR-util, such as httpd and friends. Also note that with new apr-util package, there will be apr-util-ldap which actually provides LDAP support for things like httpd, but the libraries are loaded as DSOs on demand. Meaning, you'll have to specifiy in your package that you need apr-util-ldap in order to have that support. There will also be two new DBD drivers available: apr-util-freetds and apr-util-odbc. -- Bojan From abartlet at samba.org Wed Jul 2 01:38:35 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 02 Jul 2008 11:38:35 +1000 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807010855.38912.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> Message-ID: <1214962715.6614.9.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-07-01 at 08:55 -0700, Jesse Barnes wrote: > On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > > for Fedora. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > > OpenChange) > > > > This will enable much better access to Microsoft Exchange servers from > > clients such as kdepim, and hopefully Evolution (pending a > > re-licensing). > > > > I've got a feature page for this here: > > > > https://fedoraproject.org/wiki/Features/OpenChange > > > > Now, the reason I'm posting here is that I would rather not do this > > alone, and would love some co-maintainers of the packagers above, or at > > least some help with the review and sponsorship, or advise on the best > > way forward. > > > > Any assistance gratefully received, > > I've been really looking forward to this; how can I help? What's involved > with co-maintainership? At the very least I can help with testing and > such... In terms of co-maintainership, perhaps best to ask this of others - I'm new at this game too. The next task is to rebuild kdepim against libmapi. Once you see the kdepim spec file, it is a simple change, but it needs to be done on rawhide. Knowing if this whole thing actually works would be really valuable. (I'll setup a rawhide KVM image in due course). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jbarnes at virtuousgeek.org Wed Jul 2 01:43:10 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 1 Jul 2008 18:43:10 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1214962715.6614.9.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> <1214962715.6614.9.camel@naomi.s4.naomi.abartlet.net> Message-ID: <200807011843.10136.jbarnes@virtuousgeek.org> On Tuesday, July 01, 2008 6:38 pm Andrew Bartlett wrote: > On Tue, 2008-07-01 at 08:55 -0700, Jesse Barnes wrote: > > On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > > > for Fedora. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > > > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > > > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > > > OpenChange) > > > > > > This will enable much better access to Microsoft Exchange servers from > > > clients such as kdepim, and hopefully Evolution (pending a > > > re-licensing). > > > > > > I've got a feature page for this here: > > > > > > https://fedoraproject.org/wiki/Features/OpenChange > > > > > > Now, the reason I'm posting here is that I would rather not do this > > > alone, and would love some co-maintainers of the packagers above, or at > > > least some help with the review and sponsorship, or advise on the best > > > way forward. > > > > > > Any assistance gratefully received, > > > > I've been really looking forward to this; how can I help? What's > > involved with co-maintainership? At the very least I can help with > > testing and such... > > In terms of co-maintainership, perhaps best to ask this of others - I'm > new at this game too. > > The next task is to rebuild kdepim against libmapi. Once you see the > kdepim spec file, it is a simple change, but it needs to be done on > rawhide. Knowing if this whole thing actually works would be really > valuable. > > (I'll setup a rawhide KVM image in due course). Ok, I'll pull down your specs and give them a try locally... I've gotta build a rawhide image too. Thanks, Jesse From sundaram at fedoraproject.org Wed Jul 2 01:45:46 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Jul 2008 07:15:46 +0530 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807010855.38912.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> Message-ID: <486ADDCA.9010106@fedoraproject.org> Jesse Barnes wrote: > > I've been really looking forward to this; how can I help? What's involved > with co-maintainership? At the very least I can help with testing and > such... If you are new to Fedora, get a Fedora account at https://admin.fedoraproject.org/accounts/ Then sign up for co-maintaining the package at https://admin.fedoraproject.org/pkgdb You might also want to refer the following documents http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership You can test the packages by using rawhide and providing feedback via bugzilla or bodhi, the updates system at https://admin.fedoraproject.org/updates Rahul From abartlet at samba.org Wed Jul 2 02:16:12 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 02 Jul 2008 12:16:12 +1000 Subject: Copyright licence finder? Message-ID: <1214964972.6614.21.camel@naomi.s4.naomi.abartlet.net> I wondered if, in auditing for licence tag correctness, if anybody had written a copyright/licence block finder? I'm thinking of a tool that looks for comment blocks in C code that look like copyright notices, and complies them together listing only unique licences. It could be very useful in finding the full list of unique licences (of the BSD variety in particular) for filling out the licence tag, as the output could be pushed into a file to comply with the 'acknowledgement in the source or documentation requirement, for binary packages. A possible output could look like the manually constructed copyright files in Debian/ubuntu: http://changelogs.ubuntu.com/changelogs/pool/universe/w/wmi/wmi_0.1.6-1/python-wmi.copyright Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjan at infradead.org Wed Jul 2 04:13:36 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 1 Jul 2008 21:13:36 -0700 Subject: Copyright licence finder? In-Reply-To: <1214964972.6614.21.camel@naomi.s4.naomi.abartlet.net> References: <1214964972.6614.21.camel@naomi.s4.naomi.abartlet.net> Message-ID: <20080701211336.7c2abca6@infradead.org> On Wed, 02 Jul 2008 12:16:12 +1000 Andrew Bartlett wrote: > I wondered if, in auditing for licence tag correctness, if anybody had > written a copyright/licence block finder? > > I'm thinking of a tool that looks for comment blocks in C code that > look like copyright notices, and complies them together listing only > unique licences. > have you looked at fossology ? -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From bruno at wolff.to Wed Jul 2 04:33:17 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 1 Jul 2008 23:33:17 -0500 Subject: kernel 2.6.25.7 In-Reply-To: References: Message-ID: <20080702043317.GA31027@wolff.to> On Tue, Jul 01, 2008 at 23:04:55 +0000, "Amadeus W.M." wrote: > Any idea when the 2.6.25.7 kernel will be pushed to updates? I desperately > need a bug fix in the bttv driver. Thanks! You could try kernel-2.6.25.9-79.fc9 from koji at: http://koji.fedoraproject.org/koji/buildinfo?buildID=54443 From A.J.Delaney at brighton.ac.uk Wed Jul 2 07:36:00 2008 From: A.J.Delaney at brighton.ac.uk (A.J.Delaney at brighton.ac.uk) Date: Wed, 02 Jul 2008 08:36:00 +0100 Subject: Cross toolchain support for SPUs on Cell / ppc64 In-Reply-To: <485D0E74.3080907@linux.vnet.ibm.com> References: <485BFD17.9090503@linux.vnet.ibm.com> <1214022113.3615.36.camel@beck.corsepiu.local> <485D0E74.3080907@linux.vnet.ibm.com> Message-ID: <1214984160.3480.19.camel@ScaryMonster> Jochen, On Sat, 2008-06-21 at 16:21 +0200, Jochen Roth wrote: > Ralf Corsepius wrote: > >> Our suggestion would be to build spu-binutils from the same source as > >> the system gcc for ppc is build. > > Theoretically, this would be one possibility, however, practice tells > > this doesn't work, because there always will be situations when you will > > want to patch/apply hacks to your cross-binutils, > > Yes, we need a separate spu-binutils package for the assembly anyway. > And then we can build the spu-binutils from the same source tree as the > systems binutils package. As you know I have been following an alternative method of delivering an spu-binutils package; one of creating a package outside the existing binutils.spec file. After experimentation I'm now convinced that your approach is correct. It is necessary to add a spu-binutils package to the binutils.spec, and similarly an spu-binutils package to the gcc43.spec. This ensures that binutils and spu-binutils share the same .po files and that they are always at some synchronised correct point release etc... It would be far too easy to fall out of sync with binutils if the package was a separate .spec file. >From my reading of the matter you and I would both like to see spu-binutils and spu-gcc pushed into Fedora. I think both of us are in the dark about how Fedora would like its cross-compilers packaged and installed. Is there a policy on this? Or could someone who has experience with Fedora compiler packaging suggest how they would like to see the packaging done. -- Aidan Delaney From petersen at redhat.com Wed Jul 2 07:46:59 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 2 Jul 2008 17:46:59 +1000 Subject: GNU Unifont update In-Reply-To: <48303EAB.4030702@gmail.com> References: <482BB8E3.9060402@gmail.com> <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> <48303EAB.4030702@gmail.com> Message-ID: <20080702174659.78ec8534@dhcp-0-235.bne.redhat.com> Hi Qianqian, Sorry for the late reply. Just saw this now... > The maintaining expense for both packages is not that much though. > I would be glad to maintain GNU Unifont, or show Paul how to do that > if he wants. The spec files for both packages can be almost identical. Do you still want to do this? :) It would be nice to have Unifont in Fedora. Jens From rc040203 at freenet.de Wed Jul 2 07:55:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Jul 2008 09:55:10 +0200 Subject: Cross toolchain support for SPUs on Cell / ppc64 In-Reply-To: <1214984160.3480.19.camel@ScaryMonster> References: <485BFD17.9090503@linux.vnet.ibm.com> <1214022113.3615.36.camel@beck.corsepiu.local> <485D0E74.3080907@linux.vnet.ibm.com> <1214984160.3480.19.camel@ScaryMonster> Message-ID: <1214985310.14081.29.camel@beck.corsepiu.local> On Wed, 2008-07-02 at 08:36 +0100, A.J.Delaney at brighton.ac.uk wrote: > Jochen, > On Sat, 2008-06-21 at 16:21 +0200, Jochen Roth wrote: > > Ralf Corsepius wrote: > > >> Our suggestion would be to build spu-binutils from the same source as > > >> the system gcc for ppc is build. > > > Theoretically, this would be one possibility, however, practice tells > > > this doesn't work, because there always will be situations when you will > > > want to patch/apply hacks to your cross-binutils, > > > > Yes, we need a separate spu-binutils package for the assembly anyway. > > And then we can build the spu-binutils from the same source tree as the > > systems binutils package. > >From my reading of the matter you and I would both like to see > spu-binutils and spu-gcc pushed into Fedora. I think both of us are in > the dark about how Fedora would like its cross-compilers packaged and > installed. Is there a policy on this? Nope, there isn't. All I can say, I for one don't see any reason for treating cross-toolchain packages any different from any other packages. Besides of them facing the bugs in rpm/redhat-rpm-config which happen to render packaging cross-toolchains difficult, and GCC's installation directory conventions which happen to clash with the FHS, they are ordinary applications. > Or could someone who has > experience with Fedora compiler packaging suggest how they would like to > see the packaging done. Well, I happen package cross toolchains for Fedora for quite some time[1]. Hans's avr packages inherited some aspects from these during their package review. Ralf [1] cf. ftp://ftp.rtems.org/pub/rtems/linux From nicolas.mailhot at laposte.net Wed Jul 2 08:03:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 2 Jul 2008 10:03:26 +0200 (CEST) Subject: GNU Unifont update In-Reply-To: <20080702174659.78ec8534@dhcp-0-235.bne.redhat.com> References: <482BB8E3.9060402@gmail.com> <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> <48303EAB.4030702@gmail.com> <20080702174659.78ec8534@dhcp-0-235.bne.redhat.com> Message-ID: <41614.192.54.193.59.1214985806.squirrel@rousalka.dyndns.org> Le Mer 2 juillet 2008 09:46, Jens Petersen a ?crit : > > Hi Qianqian, > > Sorry for the late reply. Just saw this now... > >> The maintaining expense for both packages is not that much though. >> I would be glad to maintain GNU Unifont, or show Paul how to do that >> if he wants. The spec files for both packages can be almost >> identical. > > Do you still want to do this? :) > It would be nice to have Unifont in Fedora. Or more generaly to have more fonts in Fedora. It's been ages since anyone but the usual suspects packaged a new font in Fedora (and a fixed team does not scale) -- Nicolas Mailhot From promac at gmail.com Wed Jul 2 08:56:54 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 2 Jul 2008 05:56:54 -0300 Subject: kernel 2.6.25.7 In-Reply-To: <20080702043317.GA31027@wolff.to> References: <20080702043317.GA31027@wolff.to> Message-ID: <68720af30807020156p66546c20j594f6b1a4a7599ed@mail.gmail.com> On Wed, Jul 2, 2008 at 1:33 AM, Bruno Wolff III wrote: > On Tue, Jul 01, 2008 at 23:04:55 +0000, > "Amadeus W.M." wrote: > > Any idea when the 2.6.25.7 kernel will be pushed to updates? I > desperately > > need a bug fix in the bttv driver. Thanks! > > You can use the video4linux kmdl from ATrpms. It will give you a video4linux kernel tree from June 22nd 2008. It solved my problems with the bttv driver. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From debarshi.ray at gmail.com Wed Jul 2 08:59:42 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 2 Jul 2008 14:29:42 +0530 Subject: GNU Unifont update In-Reply-To: <41614.192.54.193.59.1214985806.squirrel@rousalka.dyndns.org> References: <482BB8E3.9060402@gmail.com> <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> <48303EAB.4030702@gmail.com> <20080702174659.78ec8534@dhcp-0-235.bne.redhat.com> <41614.192.54.193.59.1214985806.squirrel@rousalka.dyndns.org> Message-ID: <3170f42f0807020159p6b57c72ci90246f6c65bb20da@mail.gmail.com> >>> The maintaining expense for both packages is not that much though. >>> I would be glad to maintain GNU Unifont, or show Paul how to do that >>> if he wants. The spec files for both packages can be almost >>> identical. >> >> Do you still want to do this? :) >> It would be nice to have Unifont in Fedora. > > Or more generaly to have more fonts in Fedora. It's been ages since > anyone but the usual suspects packaged a new font in Fedora (and a > fixed team does not scale) Is someone already doing this? If not, then I am interested. If yes, then I can help with the review. Happy hacking, Debarshi From promac at gmail.com Wed Jul 2 09:06:52 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 2 Jul 2008 06:06:52 -0300 Subject: kernel 2.6.25 hanging at boot Message-ID: <68720af30807020206i1ff24fr3153e0202cec5da@mail.gmail.com> Hi, I have been having problems with kernel 2.6.25 on F8 with my Dell Vostro 1400 laptop. The boot sometimes freezes. It just writes: Decompressing Linux ....done. Booting the kernel. and then hangs forever, and I have to press the power down button. The interesting thing is that if I suppress the quiet option in /etc/grub.conf to have a verbose boot, It does not hang (so it seems). This makes me believe that this extra printing introduces a small delay in the boot process, giving time to something initialize properly, Does this make any sense at all? Could it be some kind of race condition? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.lesca at solinos.it Wed Jul 2 09:40:59 2008 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 02 Jul 2008 11:40:59 +0200 Subject: Kernel 2.6.25 (F8/F9) problem Message-ID: <1214991659.4240.32.camel@lesca.home.solinos.it> On this kind of server (HP ProLiant DL380 G5) > http://www.smolts.org/client/show/pub_e04ad1d7-e691-4b54-a3b6-1a5ff974d5bd It's NOT possible install then use F9 and F8+update. This is a HP common server, since there is the problem for over a month, means that no one is using Fedora 8 + update or Fedora 9 on this kind of server. If someone was able to run Fedora 8 + Updates or Fedora 9 on these servers, please let me know how to do. The problem witch I have fount is this: > Subject: f8/f9 on HP: kernel 2.6.25.x problem > > if I install f9-i386 (kernel 2.6.25) or install f8-i386+upgrade with > last kernel 2.6.25 > > I get this error: > > > invalid opcode: 0000 [#1] SMP > > Modules linked in: sg ipmi_si(+) hpwdt(+) ipmi_msghandler bnx2 > button iTCO_wdt sr_mod pcspkr iTCO_vendor_support i5000_edac edac_core > cdrom ata_piix libata cciss sd_mod scsi_mod dm_snapshot dm_zero > dm_mirror dm_mod xfs uhci_hcd ohci_hcd ehci_hcd [last unloaded: > scsi_wait_scan] > > > > Pid: 1173, comm: modprobe Not tainted (2.6.25.4-10.fc8PAE #1) > > EIP: 0060:[] EFLAGS: 00210286 CPU: 3 > > EIP is at 0xf7c5edca > > EAX: 5f32335f EBX: 000f0000 ECX: 00cd0100 EDX: 00000000 > > ESI: d0ffffff EDI: c39bd09b EBP: f7c5eda8 ESP: f7c5ed78 > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > Process modprobe (pid: 1173, ti=f7c5e000 task=f6e08e70 > task.ti=f7c5e000) > > Stack: f89c54a9 00000060 ffff007b 00200286 f7949000 ffffffed > f7c5eda8 f7c5eda8 > > c00ffee0 00000000 000f1fff c00f0000 f7c5edc8 c00f0000 > c00ffee0 f7c5edc8 > > c00f0000 f89c65d0 f89c65a0 f7949000 f7c5eddc c050659d > f7949054 00000000 > > Call Trace: > > [] ? hpwdt_init_one+0x18b/0x3a3 [hpwdt] > > [] ? pci_device_probe+0x39/0x5b > > [] ? driver_probe_device+0xc0/0x137 > > [] ? __driver_attach+0x73/0xa9 > > [] ? bus_for_each_dev+0x37/0x5c > > [] ? driver_attach+0x14/0x16 > > [] ? __driver_attach+0x0/0xa9 > > [] ? bus_add_driver+0x90/0x1b7 > > [] ? driver_register+0x47/0xa2 > > [] ? __pci_register_driver+0x35/0x61 > > [] ? hpwdt_init+0x17/0x19 [hpwdt] > > [] ? sys_init_module+0x1610/0x177a > > [] ? do_page_fault+0x528/0x909 > > [] ? param_get_int+0x0/0x15 > > [] ? do_sync_read+0x0/0xe9 > > [] ? sys_read+0x3b/0x60 > > [] ? syscall_call+0x7/0xb > > ======================= > > Code: 00 ff 1f 0f 00 00 00 0f c0 c8 ed c5 f7 00 00 0f c0 e0 fe 0f c0 > c8 ed c5 f7 00 00 0f c0 d0 65 9c f8 a0 65 9c f8 00 90 94 f7 dc ed > f7 9d 65 50 c0 54 90 94 f7 00 00 00 00 d0 65 9c f8 f4 ed c5 > > EIP: [] 0xf7c5edca SS:ESP 0068:f7c5ed78 > > ---[ end trace 732bbc392f92b3f6 ]--- > > input: Ups Manufacturing RS232-USB converter as /class/input/input5 > > input,hidraw0: USB HID v1.00 Gamepad [Ups Manufacturing RS232-USB > converter] on usb-0000:00:1d.2-2 > > usb 4-2: New USB device found, idVendor=0a6d, idProduct=0005 > > usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 4-2: Product: RS232-USB converter > > usb 4-2: Manufacturer: Ups Manufacturing > > usb 6-1: new full speed USB device using uhci_hcd and address 2 > > usb 6-1: configuration #1 chosen from 1 choice > > input: HP Virtual Keyboard as /class/input/input6 > > input,hidraw1: USB HID v1.01 Keyboard [HP Virtual Keyboard] on > usb-0000:01:04.4-1 > > input: HP Virtual Keyboard as /class/input/input7 > > input,hidraw2: USB HID v1.01 Mouse [HP Virtual Keyboard] on > usb-0000:01:04.4-1 > > usb 6-1: New USB device found, idVendor=03f0, idProduct=1027 > > usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 6-1: Product: Virtual Keyboard > > usb 6-1: Manufacturer: HP > > usb 6-2: new full speed USB device using uhci_hcd and address 3 > > usb 6-2: configuration #1 chosen from 1 choice > > hub 6-2:1.0: USB hub found > > hub 6-2:1.0: 7 ports detected > > usb 6-2: New USB device found, idVendor=03f0, idProduct=1327 > > usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 6-2: Product: Virtual Hub > > usb 6-2: Manufacturer: HP > > NET: Registered protocol family 10 > > lo: Disabled Privacy Extensions > > ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 23 (level, low) -> IRQ 23 > > device-mapper: multipath: version 1.0.5 loaded > > (this errore is grab from dmesg of f8+upd) > > F8 after a lot of timeout during the boot start, but f9+update or f9 > +update-testing or f9+update-rawhide (2.6.26) not start ... > -- Dario Lesca From nphilipp at redhat.com Wed Jul 2 10:12:38 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Jul 2008 12:12:38 +0200 Subject: howto push dependencies into sub packages In-Reply-To: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> References: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> Message-ID: <1214993558.3163.16.camel@gibraltar.str.redhat.com> Hi Peter, On Mon, 2008-06-02 at 19:31 +0100, Peter Robinson wrote: > I maintain the geoclue package. It has a number of providers that can > be compiled in. I've tried to introduce a couple of subpackages for > the gpsd and gypsy providers so that you can just install the > providers you need and not have to pull in extra packages that you > might not need (gpsd and gypsy do essentially the same thing so you > probably don't need both). The problem I'm having is that with the > addition of the gpsd provider (see F-9 testing if you aren't on > rawhide) pulls in gpsd for the main package and not for the > geoclue-gpsd package. How do I push this requirement down to the sub > package so that it doesn't affect the main package (I've got the gpsd > requirements in the sub package). I see nobody's answered yet... I guess what you want to do is to have your -gpsd subpackage requires gpsd so if it is installed, gpsd will be there as well? In that case, just put the "Requires: gpsd ..." line in the "%package gpsd" section, right beside the "Requires: geoclue = %{PACKAGE_VERSION}" line. HTH, Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From pbrobinson at gmail.com Wed Jul 2 10:28:32 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 2 Jul 2008 11:28:32 +0100 Subject: howto push dependencies into sub packages In-Reply-To: <1214993558.3163.16.camel@gibraltar.str.redhat.com> References: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> <1214993558.3163.16.camel@gibraltar.str.redhat.com> Message-ID: <5256d0b0807020328m787e1d11p51c9c14a76bd1e48@mail.gmail.com> Hi Nils, >> I maintain the geoclue package. It has a number of providers that can >> be compiled in. I've tried to introduce a couple of subpackages for >> the gpsd and gypsy providers so that you can just install the >> providers you need and not have to pull in extra packages that you >> might not need (gpsd and gypsy do essentially the same thing so you >> probably don't need both). The problem I'm having is that with the >> addition of the gpsd provider (see F-9 testing if you aren't on >> rawhide) pulls in gpsd for the main package and not for the >> geoclue-gpsd package. How do I push this requirement down to the sub >> package so that it doesn't affect the main package (I've got the gpsd >> requirements in the sub package). > > I see nobody's answered yet... I guess what you want to do is to have > your -gpsd subpackage requires gpsd so if it is installed, gpsd will be > there as well? > > In that case, just put the "Requires: gpsd ..." line in the "%package > gpsd" section, right beside the "Requires: geoclue = %{PACKAGE_VERSION}" > line. That's what I thought would be the case and have done but it seems that rpm with the auto deps still wants the dependency for the root package as well. For example with a package I maintain called geoclue I have two subpackages called geoclue-gypsy and geoclue-gpsd to try and keep the deps down (gypsy and gpsd essentially do the same thing) but if you just install geoclue without any of the sub packages it will still pull in both gpsd and gypsy as deps. This is what I want to avoid. A yum output eg below. Cheers, Peter [root at euuklonw7300b1n ~]# yum install geoclue Loaded plugins: refresh-packagekit, refresh-updatesd Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package geoclue.x86_64 0:0.11.1-9.fc9 set to be updated --> Processing Dependency: libgypsy.so.0()(64bit) for package: geoclue --> Processing Dependency: libgps.so.17()(64bit) for package: geoclue --> Running transaction check ---> Package gypsy.x86_64 0:0.6-3.fc9 set to be updated ---> Package gpsd.x86_64 0:2.37-2.fc9 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: geoclue x86_64 0.11.1-9.fc9 updates 82 k Installing for dependencies: gpsd x86_64 2.37-2.fc9 fedora 188 k gypsy x86_64 0.6-3.fc9 updates 41 k Transaction Summary ============================================================================= Install 3 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 311 k Is this ok [y/N]: From nphilipp at redhat.com Wed Jul 2 10:36:58 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 02 Jul 2008 12:36:58 +0200 Subject: howto push dependencies into sub packages In-Reply-To: <5256d0b0807020328m787e1d11p51c9c14a76bd1e48@mail.gmail.com> References: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> <1214993558.3163.16.camel@gibraltar.str.redhat.com> <5256d0b0807020328m787e1d11p51c9c14a76bd1e48@mail.gmail.com> Message-ID: <1214995018.3163.23.camel@gibraltar.str.redhat.com> Hi Peter, On Wed, 2008-07-02 at 11:28 +0100, Peter Robinson wrote: > For example with a package I maintain called geoclue I have two > subpackages called geoclue-gypsy and geoclue-gpsd to try and keep the > deps down (gypsy and gpsd essentially do the same thing) but if you > just install geoclue without any of the sub packages it will still > pull in both gpsd and gypsy as deps. This is what I want to avoid. A > yum output eg below. > > Cheers, > Peter > > [root at euuklonw7300b1n ~]# yum install geoclue > Loaded plugins: refresh-packagekit, refresh-updatesd > Setting up Install Process > Parsing package install arguments > Resolving Dependencies > --> Running transaction check > ---> Package geoclue.x86_64 0:0.11.1-9.fc9 set to be updated > --> Processing Dependency: libgypsy.so.0()(64bit) for package: geoclue > --> Processing Dependency: libgps.so.17()(64bit) for package: geoclue This suggests that geoclue (the main package) has files which link directly to the gypsy and gps libs respectively; rpmbuild detects this and sets automatic dependencies. >From looking at your spec file, you include the %{_libexecdir}/geoclue-{gpsd,gypsy} files not only in their subpackages but also in the main package (by way of "%{_libexecdir}/geoclue-*"). To avoid that, you should either list all other files in that directory for the main package or use this construct: %files ... %{_libexecdir}/geoclue-* %exclude %{_libexecdir}/geoclue-gpsd %exclude %{_libexecdir}/geoclue-gypsy Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rawhide at fedoraproject.org Wed Jul 2 10:45:42 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 2 Jul 2008 10:45:42 +0000 (UTC) Subject: rawhide report: 20080702 changes Message-ID: <20080702104542.63734209D77@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080701/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080702/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package antlr3 ANother Tool for Language Recognition New package librepository Hierarchical repository abstraction layer New package opensm OpenIB InfiniBand Subnet Manager and management utilities New package perl-Math-FFT Perl module to calculate Fast Fourier Transforms New package ristretto Image-viewer for the Xfce desktop environment New package usb_modeswitch USB Modeswitch gets 4G cards in operational mode Removed package fonts-chinese Removed package fonts-korean Updated Packages: Pixie-2.2.4-1.fc10 ------------------ * Tue Jul 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 2.2.4-1 - Update to 2.2.4 (final) ScientificPython-2.6.1-1.fc10 ----------------------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta - 2.6.1-1 - Latest Stable release anaconda-11.4.1.10-1 -------------------- * Tue Jul 1 18:00:00 2008 Chris Lumens - 11.4.1.10-1 - Remove old livecd flag (katzj) - Explicitly setup livecd install by passing --liveinst to anaconda (katzj) - Check return value of asprintf() consistently (dcantrell) - Per strtol(3) man page, set errno=0 before call. (dcantrell) - Rescue mode no longer needs access to a methodstr (#453044). (clumens) - Use strtol() instead of atoi() (dcantrell) - Spell pseudo correctly. (pjones) apr-1.3.2-1.fc10 ---------------- * Thu Jun 19 18:00:00 2008 Bojan Smojver - 1.3.2-1 - bump up to 1.3.2 * Sun Jun 1 18:00:00 2008 Bojan Smojver - 1.3.0-1 - bump up to 1.3.0 augeas-0.2.1-1.fc10 ------------------- * Tue Jul 1 18:00:00 2008 David Lutterkort - 0.2.1-1 - New version cairo-dock-1.6.1-0.1.svn1163_trunk.fc10 --------------------------------------- * Tue Jul 1 18:00:00 2008 Mamoru Tasaka - rev. 1163 cfv-1.18.2-1.fc10 ----------------- cups-1.3.7-12.fc10 ------------------ * Tue Jul 1 18:00:00 2008 Tim Waugh 1:1.3.7-12 - Fixed bug #447200 again. * Tue Jul 1 18:00:00 2008 Tim Waugh 1:1.3.7-11 - Use portreserve. cyrus-sasl-2.1.22-15.fc10 ------------------------- * Tue Jul 1 18:00:00 2008 Tomas Mraz - 2.1.22-15 - drop reload from initscript help (#448154) - fix hang in rimap auth method (#438533) - build the krb4 plugin (#154675) * Fri May 23 18:00:00 2008 Dennis Gilmore - 2.1.22-14 - make it so that bootstrap actually works * Thu May 22 18:00:00 2008 Tom "spot" Callaway - 2.1.22-13.1 - minor release bump for sparc rebuild denyhosts-2.6-10.fc10 --------------------- * Tue Jul 1 18:00:00 2008 Jason L Tibbitts III - 2.6-10 - Fix initscript lockfile handling: Stop creating the lockfile in the initscript. Clean up stray lockfiles automatically. Don't attempt to start the daemon if its already running. - Various initscript cleanups. - Set default configuration file location to match what we use. - Make it easier to add extra options like --debug from the sysconfig file. * Fri Jan 4 17:00:00 2008 Jason L Tibbitts III - 2.6-9 - Properly escape percent symbols in the changelog entries. gnome-power-manager-2.23.3-2.fc10 --------------------------------- * Tue Jul 1 18:00:00 2008 Richard Hughes - 2.23.3-1 - Update to 2.23.3, which should fix backlight brightness. gnutls-2.4.1-1.fc10 ------------------- * Tue Jul 1 18:00:00 2008 Tomas Mraz 2.4.1-1 - new upstream version - correct the license tag - explicit --with-included-opencdk not needed - use external lzo library, internal not included anymore iptables-1.4.1.1-1.fc10 ----------------------- * Tue Jul 1 18:00:00 2008 Thomas Woerner 1.4.1.1-1 - upstream bug fix release 1.4.1.1 - dropped extra patch for 1.4.1 - not needed anymore jd-2.0.0-0.6.svn2161_trunk.fc10 ------------------------------- * Wed Jul 2 18:00:00 2008 Mamoru Tasaka - svn 2161 libXfont-1.3.2-1.fc9 -------------------- * Mon Jun 30 18:00:00 2008 Adam Jackson 1.3.2-1 - libXfont 1.3.2 libgtop2-2.23.4-1.fc10 ---------------------- * Tue Jul 1 18:00:00 2008 Matthias Clasen - 2.23.4-1 - Update to 2.23.4 livecd-tools-017.1-1.fc9 ------------------------ * Mon Jun 16 18:00:00 2008 Jeremy Katz - 017.1-1 - Handle copying timezone to /etc/localtime (#445624) - livecd-iso-to-disk: Ensure disk isn't mounted before writing to it (#446472) - livecd-iso-to-disk: Quote iso path (#446472) - Fix --base-on (#437906) - Use a fake /selinux to avoid problems with loading new policy (eparis) lm_sensors-3.0.2-1.fc10 ----------------------- * Tue Jul 1 18:00:00 2008 Hans de Goede 3.0.2-1 - New upstream release 3.0.2 - This release contains various important fixes to sensors-detect, which made it unsafe to run sensors-detect on certain systems - Drop all patches (all upstreamed) mesa-7.1-0.35.fc9 ----------------- * Thu Jun 12 18:00:00 2008 Dave Airlie 7.1-0.35 - Update mesa to latest git snapshot - drop patches merged upstream * Wed Jun 4 18:00:00 2008 Adam Jackson 7.1-0.34 - Link libdricore with gcc instead of ld, so we automagically pick up the ld --build-id flags. * Wed May 28 18:00:00 2008 Dave Airlie 7.1-0.33 - Add initial r500 3D driver * Tue May 13 18:00:00 2008 Adam Jackson 7.1-0.32 - Update dri2proto requirement. (#446166) nec2c-0.7-2.fc10 ---------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta - 0.7-2 - Patch for ppc build * Tue Jul 1 18:00:00 2008 Jef Spaleta - 0.7-1 - new release ocaml-json-static-0.9.6-5.fc10 ------------------------------ * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 0.9.6-5 - Ignore Asttypes & Parsetree deps. - Bump release to -5 to avoid upgrade problems between releases. ocaml-openin-20070524-4.fc10 ---------------------------- * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 20070524-4 - Ignore Asttypes & Parsetree deps. ocaml-pa-monad-1.2.0-5.fc10 --------------------------- * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 1.2.0-5 - Ignore Asttypes & Parsetree deps. - Bump release to avoid EVR problems across branches. ocaml-pgocaml-1.1-3.fc10 ------------------------ * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 1.1-3 - Ignore Parsetree dep. - Bump release to -3 to solve EVR problems with F-9. perl-Authen-SASL-2.12-1.fc10 ---------------------------- * Tue Jul 1 18:00:00 2008 Steven Pritchard 2.12-1 - Update to 2.12. perl-Digest-Nilsimsa-0.06-10.fc10 --------------------------------- * Tue Jul 1 18:00:00 2008 Paul Howarth 0.06-10 - Add perl(:MODULE_COMPAT...) dependency (#453564) - Remove redundant buildreq perl - Clean buildroot at start of %install - Move "make test" to %check - Install into %{perl_vendorarch} and use "make pure_install" - Fix argument order for find with -depth - Only specify compiler flags once - Only specify version number once perl-File-Flat-1.04-2.fc10 -------------------------- * Tue Jul 1 18:00:00 2008 Ralf Cors??pius - 1.04-2 - BR: perl(Test::CPAN::Meta). perl-MIME-tools-5.427-1.fc10 ---------------------------- * Tue Jul 1 18:00:00 2008 Paul Howarth 5.427-1 - Update to 5.427 - Require and BuildRequire perl(IO::File) >= 1.13 perl-Params-CallbackRequest-1.19-1.fc10 --------------------------------------- * Tue Jul 1 18:00:00 2008 Steven Pritchard 1.19-1 - Update to 1.19. - BR Test::Simple. perl-Test-CPAN-Meta-0.12-1.fc10 ------------------------------- * Tue Jul 1 18:00:00 2008 Steven Pritchard 0.12-1 - Update to 0.12. - BR Test::Builder and Test::Builder::Tester. pidgin-2.4.3-1.fc10.1 --------------------- * Tue Jul 1 18:00:00 2008 Stu Tomlinson 2.4.3-1.1 - Add a patch to build with latest rawhide tcl * Tue Jul 1 18:00:00 2008 Stu Tomlinson 2.4.3-1 - 2.4.3 plymouth-0.5.0-2.fc10 --------------------- * Tue Jul 1 18:00:00 2008 Ray Strode - 0.5.0-2 - Pull in spinfinity by default. This whole "figure out which plugin to use" set of scripts and scriptlets needs work. We need to separate distro default from user choice. * Tue Jul 1 18:00:00 2008 Ray Strode - 0.5.0-1 - Add new client "ask-for-password" command which feeds the user input to a program instead of standard output, and loops when the program returns non-zero exit status. policycoreutils-2.0.51-2.fc10 ----------------------------- * Tue Jul 1 18:00:00 2008 Dan Walsh 2.0.50-2 - Remove semodule use within semanage - Fix launching of polgengui from toolbar portreserve-0.0.3-1.fc10 ------------------------ * Tue Jul 1 18:00:00 2008 Tim Waugh 0.0.3-1 - 0.0.3: - Allow multiple services to be defined in a single configuration file. - Allow protocol specifications, e.g. ipp/udp. python-dateutil-1.4-1.fc10 -------------------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta 1.4-1 - Latest upstream release python-matplotlib-0.98.1-1.fc10 ------------------------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta - 0.98.1-1 - Latest upstream release python-xlib-0.14-1.fc10 ----------------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta - 0.14-1 - Latest upstream release ruby-1.8.6.230-4.fc10 --------------------- * Tue Jul 1 18:00:00 2008 Akira TAGOH - 1.8.6.230-4 - Backported from upstream SVN to fix a segfault issue with Array#fill. rubygem-hoe-1.7.0-1.fc10 ------------------------ * Tue Jul 1 18:00:00 2008 Darryl Pierce - 1.7.0-1 - Release 1.7.0 of the gem. safekeep-1.0.4-1.fc10 --------------------- * Tue Jul 1 18:00:00 2008 Jef Spaleta 1.0.4-1 - Latest upstream release sblim-cmpi-base-1.5.5-1.fc10 ---------------------------- * Tue Jul 1 18:00:00 2008 Vitezslav Crhonek - 1.5.5-1 - Update to 1.5.5 - Spec file revision * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.5.4-8 - Autorebuild for GCC 4.3 system-config-date-1.9.32-1.fc10 -------------------------------- * Tue Jul 1 18:00:00 2008 Nils Philippsen - 1.9.32-1 - fix Arabic timezone translation (#453202, patch by Muayyad Alsadi) tinyerp-4.2.2-3.fc10 -------------------- * Fri May 30 18:00:00 2008 Dan Horak 4.2.2-3 - add missing R: python-matplotlib (Resolves: #449118) tog-pegasus-2.7.0-9.fc10 ------------------------ * Tue Jul 1 18:00:00 2008 Vitezslav Crhonek - 2:2.7.0-9 - Add SNMP indication handler to package Resolves: #452930 util-linux-ng-2.14-2.fc10 ------------------------- * Tue Jul 1 18:00:00 2008 Karel Zak 2.14-2 - fix #390691 - mount should check selinux context on mount, and warn on file_t vnc-4.1.2-31.fc10 ----------------- * Thu May 29 18:00:00 2008 Adam Tkac 4.1.2-31 - substituted vnc-210617.patch with improved version - vnc-viewerIPv6.patch (#438422) xorg-x11-xinit-1.0.9-1.fc9 -------------------------- * Wed Jun 11 18:00:00 2008 Adam Jackson 1.0.9-1 - xinit 1.0.9 * Tue Apr 8 18:00:00 2008 Adam Jackson 1.0.7-7 - Xsession: Don't start ssh-agent for gnome sessions anymore, gnome-keyring acts as an agent now. (#441123) zoneminder-1.22.3-15.fc10 ------------------------- * Tue Jul 1 18:00:00 2008 Martin Ebourne - 1.22.3-15 - Add perl module compat dependency, bz #453590 Summary: Added Packages: 6 Removed Packages: 2 Modified Packages: 48 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.i386 requires libgnutls.so.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.i386 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese pygoocanvas-0.9.0-3.fc9.i386 requires goocanvas = 0:0.9 sblim-cmpi-base-test-1.5.5-1.fc10.i386 requires sblim-testsuite = 0:1.2.4-1 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 smart-0.52-54.fc9.i386 requires smart-config stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.x86_64 requires libgnutls.so.13()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese pygoocanvas-0.9.0-3.fc9.x86_64 requires goocanvas = 0:0.9 sblim-cmpi-base-test-1.5.5-1.fc10.x86_64 requires sblim-testsuite = 0:1.2.4-1 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) liferea-1.4.15-6.fc9.ppc requires libgnutls.so.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese pygoocanvas-0.9.0-3.fc9.ppc requires goocanvas = 0:0.9 sblim-cmpi-base-test-1.5.5-1.fc10.ppc requires sblim-testsuite = 0:1.2.4-1 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 smart-0.52-54.fc9.ppc requires smart-config stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) liferea-1.4.15-6.fc9.ppc64 requires libgnutls.so.13()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese perl-Bit-Vector-6.4-8.fc9.ppc64 requires perl(Carp::Clan) perl-DBIx-Class-0.08010-6.fc10.noarch requires perl(Carp::Clan) perl-Date-Calc-5.4-6.fc9.ppc64 requires perl(Carp::Clan) perl-Declare-Constraints-Simple-0.03-3.fc9.noarch requires perl(Carp::Clan) perl-Object-Deadly-0.09-3.fc9.noarch requires perl(Carp::Clan) >= 0:5.4 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 perl-XML-Atom-SimpleFeed-0.8-2.fc10.noarch requires perl(Carp::Clan) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot pygoocanvas-0.9.0-3.fc9.ppc64 requires goocanvas = 0:0.9 sblim-cmpi-base-test-1.5.5-1.fc10.ppc64 requires sblim-testsuite = 0:1.2.4-1 scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From pbrobinson at gmail.com Wed Jul 2 11:03:20 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 2 Jul 2008 12:03:20 +0100 Subject: howto push dependencies into sub packages In-Reply-To: <1214995018.3163.23.camel@gibraltar.str.redhat.com> References: <5256d0b0806021131g2775a821g9b78a0a0112f49f@mail.gmail.com> <1214993558.3163.16.camel@gibraltar.str.redhat.com> <5256d0b0807020328m787e1d11p51c9c14a76bd1e48@mail.gmail.com> <1214995018.3163.23.camel@gibraltar.str.redhat.com> Message-ID: <5256d0b0807020403p77ba5320gd893b9290814e2d0@mail.gmail.com> Hi Nils, >> For example with a package I maintain called geoclue I have two >> subpackages called geoclue-gypsy and geoclue-gpsd to try and keep the >> deps down (gypsy and gpsd essentially do the same thing) but if you >> just install geoclue without any of the sub packages it will still >> pull in both gpsd and gypsy as deps. This is what I want to avoid. A >> yum output eg below. >> >> Cheers, >> Peter >> >> [root at euuklonw7300b1n ~]# yum install geoclue >> Loaded plugins: refresh-packagekit, refresh-updatesd >> Setting up Install Process >> Parsing package install arguments >> Resolving Dependencies >> --> Running transaction check >> ---> Package geoclue.x86_64 0:0.11.1-9.fc9 set to be updated >> --> Processing Dependency: libgypsy.so.0()(64bit) for package: geoclue >> --> Processing Dependency: libgps.so.17()(64bit) for package: geoclue > > This suggests that geoclue (the main package) has files which link > directly to the gypsy and gps libs respectively; rpmbuild detects this > and sets automatic dependencies. > > >From looking at your spec file, you include the > %{_libexecdir}/geoclue-{gpsd,gypsy} files not only in their subpackages > but also in the main package (by way of "%{_libexecdir}/geoclue-*"). To > avoid that, you should either list all other files in that directory for > the main package or use this construct: > > %files > ... > %{_libexecdir}/geoclue-* > %exclude %{_libexecdir}/geoclue-gpsd > %exclude %{_libexecdir}/geoclue-gypsy Thanks for pointing that out, I was under the misguided impression that if it was listed in the subpackage that it wouldn't be picked up in the main package. I should have actually done a rpm -ql on the package to see for myself. I also noticed a couple of other related files that should have been put in the subpackage as well. Looks like I have now fixed the issue. Thanks for your help! Peter From nicolas.mailhot at laposte.net Wed Jul 2 11:14:44 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 2 Jul 2008 13:14:44 +0200 (CEST) Subject: GNU Unifont update In-Reply-To: <3170f42f0807020159p6b57c72ci90246f6c65bb20da@mail.gmail.com> References: <482BB8E3.9060402@gmail.com> <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> <48303EAB.4030702@gmail.com> <20080702174659.78ec8534@dhcp-0-235.bne.redhat.com> <41614.192.54.193.59.1214985806.squirrel@rousalka.dyndns.org> <3170f42f0807020159p6b57c72ci90246f6c65bb20da@mail.gmail.com> Message-ID: <26498.192.54.193.59.1214997284.squirrel@rousalka.dyndns.org> Le Mer 2 juillet 2008 10:59, Debarshi Ray a ?crit : > >>>> The maintaining expense for both packages is not that much though. >>>> I would be glad to maintain GNU Unifont, or show Paul how to do >>>> that >>>> if he wants. The spec files for both packages can be almost >>>> identical. >>> >>> Do you still want to do this? :) >>> It would be nice to have Unifont in Fedora. >> >> Or more generaly to have more fonts in Fedora. It's been ages since >> anyone but the usual suspects packaged a new font in Fedora (and a >> fixed team does not scale) > > Is someone already doing this? If not, then I am interested. If yes, > then I can help with the review. There are lots of unclaimed fonts on https://fedoraproject.org/wiki/Category:Font_wishlist If you have the time and interest please do not block on Unifont. Our packaging wishlist has other elements. Regards, -- Nicolas Mailhot From bruno at wolff.to Wed Jul 2 13:26:54 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 2 Jul 2008 08:26:54 -0500 Subject: kernel 2.6.25.7 In-Reply-To: <68720af30807020156p66546c20j594f6b1a4a7599ed@mail.gmail.com> References: <20080702043317.GA31027@wolff.to> <68720af30807020156p66546c20j594f6b1a4a7599ed@mail.gmail.com> Message-ID: <20080702132653.GA27405@wolff.to> On Wed, Jul 02, 2008 at 05:56:54 -0300, Paulo Cavalcanti wrote: > On Wed, Jul 2, 2008 at 1:33 AM, Bruno Wolff III wrote: > > > On Tue, Jul 01, 2008 at 23:04:55 +0000, > > "Amadeus W.M." wrote: > > > Any idea when the 2.6.25.7 kernel will be pushed to updates? I > > desperately > > > need a bug fix in the bttv driver. Thanks! > > > > > > You can use the video4linux kmdl from ATrpms. It will > give you a video4linux kernel tree from June 22nd 2008. Also the 2.6.25.9 got pushed to updates last night. From rmeggins at redhat.com Wed Jul 2 13:40:11 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 02 Jul 2008 07:40:11 -0600 Subject: Adding man pages to existing package? Message-ID: <486B853B.4070900@redhat.com> Is it better to have the man pages in the main package, or in a separate -man sub-package? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Wed Jul 2 13:42:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Jul 2008 19:12:51 +0530 Subject: Adding man pages to existing package? In-Reply-To: <486B853B.4070900@redhat.com> References: <486B853B.4070900@redhat.com> Message-ID: <486B85DB.7000705@fedoraproject.org> Rich Megginson wrote: > Is it better to have the man pages in the main package, or in a separate > -man sub-package? The current guidelines has this to say: http://fedoraproject.org/wiki/Packaging/Guidelines#Documentation Put it in the main package unless it is substantial amount of space. Rahul From marcelo.gobelli at gmail.com Wed Jul 2 14:32:51 2008 From: marcelo.gobelli at gmail.com (marcelo gobelli) Date: Wed, 2 Jul 2008 07:32:51 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> Message-ID: <72fee6e40807020732q473e0fa3o26a2b157847039a4@mail.gmail.com> I am new to this game. I am willing to help if you need extra help maybe with testing.... marcelo On 6/30/08, Andrew Bartlett wrote: > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > for Fedora. > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > OpenChange) > > This will enable much better access to Microsoft Exchange servers from > clients such as kdepim, and hopefully Evolution (pending a > re-licensing). > > I've got a feature page for this here: > > https://fedoraproject.org/wiki/Features/OpenChange > > Now, the reason I'm posting here is that I would rather not do this > alone, and would love some co-maintainers of the packagers above, or at > least some help with the review and sponsorship, or advise on the best > way forward. > > Any assistance gratefully received, > > Andrew Bartlett > -- > Andrew Bartlett > http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Red Hat Inc. > > -- > 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 nicolas.mailhot at laposte.net Wed Jul 2 15:13:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 2 Jul 2008 17:13:01 +0200 (CEST) Subject: [Fwd: Re: GNU Unifont update] Message-ID: <15695.192.54.193.59.1215011581.squirrel@rousalka.dyndns.org> [FWD because Paul Hardy forrgot to subscribe] I just finished the glyphs and posted them at http://unifoundry.com/unifont.html on 20 June 2008. I then took a vacation I had planned for a long time. I was trying to get something in releasable form before my vacation, but it didn't happen. I intend to package all the sources used to build the GNU Unifont: my software, plus software that Roman Czyborra wrote originally, plus software that Luis Gonzalez Miranda wrote to convert the .hex font into a TrueType font with my modifications, in one source tree with make files and man pages. I've been wrapping this up behind the scenes and expect to finish this weekend. I would like to go through the Fedora release process, starting with just the font and then adding the whole source tree to build the font. Qianqian Fang will be able to guide me through this process (and I've been in frequent contact with him while adding the missing CJK glyphs), but review by anyone else of course would be welcome. If anyone would like updates on this, you can email me at unifoundry at unifoundry.com and I'll keep you posted on the latest developments. Thanks for your interest! Paul Hardy Le Mer 2 juillet 2008 10:59, Debarshi Ray a ?crit : > >>>> The maintaining expense for both packages is not that much though. >>>> I would be glad to maintain GNU Unifont, or show Paul how to do >>>> that >>>> if he wants. The spec files for both packages can be almost >>>> identical. >>> >>> Do you still want to do this? :) >>> It would be nice to have Unifont in Fedora. >> >> Or more generaly to have more fonts in Fedora. It's been ages since >> anyone but the usual suspects packaged a new font in Fedora (and a >> fixed team does not scale) > > Is someone already doing this? If not, then I am interested. If yes, > then I can help with the review. There are lots of unclaimed fonts on https://fedoraproject.org/wiki/Category:Font_wishlist If you have the time and interest please do not block on Unifont. Our packaging wishlist has other elements. Regards, -- Nicolas Mailhot -- Nicolas Mailhot From jwilson at redhat.com Wed Jul 2 16:04:54 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 2 Jul 2008 12:04:54 -0400 Subject: Kernel 2.6.25 (F8/F9) problem In-Reply-To: <1214991659.4240.32.camel@lesca.home.solinos.it> References: <1214991659.4240.32.camel@lesca.home.solinos.it> Message-ID: <200807021204.54804.jwilson@redhat.com> On Wednesday 02 July 2008 05:40:59 am Dario Lesca wrote: > On this kind of server (HP ProLiant DL380 G5) > > > http://www.smolts.org/client/show/pub_e04ad1d7-e691-4b54-a3b6-1a5ff974d5b > >d > > It's NOT possible install then use F9 and F8+update. > > This is a HP common server, since there is the problem for over a month, > means that no one is using Fedora 8 + update or Fedora 9 on this kind of > server. > > If someone was able to run Fedora 8 + Updates or Fedora 9 on these > servers, please let me know how to do. Please file a bug. We do have DL380 G5 hardware here in the lab. It typically gets used for RHEL testing, but I'm sure someone can get Fedora on one and see what they can see. This hardware definitely needs to work come RHEL6 time, so fixing it in Fedora sooner than later would be good... Please feel free to add me (jwilson at redhat.com) to the cc list when you open the bug. > The problem witch I have fount is this: > > Subject: f8/f9 on HP: kernel 2.6.25.x problem > > > > if I install f9-i386 (kernel 2.6.25) or install f8-i386+upgrade with > > last kernel 2.6.25 > > > > I get this error: > > > invalid opcode: 0000 [#1] SMP > > > Modules linked in: sg ipmi_si(+) hpwdt(+) ipmi_msghandler bnx2 > > > > button iTCO_wdt sr_mod pcspkr iTCO_vendor_support i5000_edac edac_core > > cdrom ata_piix libata cciss sd_mod scsi_mod dm_snapshot dm_zero > > dm_mirror dm_mod xfs uhci_hcd ohci_hcd ehci_hcd [last unloaded: > > scsi_wait_scan] > > > > > Pid: 1173, comm: modprobe Not tainted (2.6.25.4-10.fc8PAE #1) > > > EIP: 0060:[] EFLAGS: 00210286 CPU: 3 > > > EIP is at 0xf7c5edca > > > EAX: 5f32335f EBX: 000f0000 ECX: 00cd0100 EDX: 00000000 > > > ESI: d0ffffff EDI: c39bd09b EBP: f7c5eda8 ESP: f7c5ed78 > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > > > Process modprobe (pid: 1173, ti=f7c5e000 task=f6e08e70 > > > > task.ti=f7c5e000) > > > > > Stack: f89c54a9 00000060 ffff007b 00200286 f7949000 ffffffed > > > > f7c5eda8 f7c5eda8 > > > > > c00ffee0 00000000 000f1fff c00f0000 f7c5edc8 c00f0000 > > > > c00ffee0 f7c5edc8 > > > > > c00f0000 f89c65d0 f89c65a0 f7949000 f7c5eddc c050659d > > > > f7949054 00000000 > > > > > Call Trace: > > > [] ? hpwdt_init_one+0x18b/0x3a3 [hpwdt] > > > [] ? pci_device_probe+0x39/0x5b > > > [] ? driver_probe_device+0xc0/0x137 > > > [] ? __driver_attach+0x73/0xa9 > > > [] ? bus_for_each_dev+0x37/0x5c > > > [] ? driver_attach+0x14/0x16 > > > [] ? __driver_attach+0x0/0xa9 > > > [] ? bus_add_driver+0x90/0x1b7 > > > [] ? driver_register+0x47/0xa2 > > > [] ? __pci_register_driver+0x35/0x61 > > > [] ? hpwdt_init+0x17/0x19 [hpwdt] > > > [] ? sys_init_module+0x1610/0x177a > > > [] ? do_page_fault+0x528/0x909 > > > [] ? param_get_int+0x0/0x15 > > > [] ? do_sync_read+0x0/0xe9 > > > [] ? sys_read+0x3b/0x60 > > > [] ? syscall_call+0x7/0xb > > > ======================= > > > Code: 00 ff 1f 0f 00 00 00 0f c0 c8 ed c5 f7 00 00 0f c0 e0 fe 0f c0 > > > > c8 ed c5 f7 00 00 0f c0 d0 65 9c f8 a0 65 9c f8 00 90 94 f7 dc ed > > f7 9d 65 50 c0 54 90 94 f7 00 00 00 00 d0 65 9c f8 f4 ed c5 > > > > > EIP: [] 0xf7c5edca SS:ESP 0068:f7c5ed78 > > > ---[ end trace 732bbc392f92b3f6 ]--- > > > input: Ups Manufacturing RS232-USB converter as /class/input/input5 > > > input,hidraw0: USB HID v1.00 Gamepad [Ups Manufacturing RS232-USB > > > > converter] on usb-0000:00:1d.2-2 > > > > > usb 4-2: New USB device found, idVendor=0a6d, idProduct=0005 > > > usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > > usb 4-2: Product: RS232-USB converter > > > usb 4-2: Manufacturer: Ups Manufacturing > > > usb 6-1: new full speed USB device using uhci_hcd and address 2 > > > usb 6-1: configuration #1 chosen from 1 choice > > > input: HP Virtual Keyboard as /class/input/input6 > > > input,hidraw1: USB HID v1.01 Keyboard [HP Virtual Keyboard] on > > > > usb-0000:01:04.4-1 > > > > > input: HP Virtual Keyboard as /class/input/input7 > > > input,hidraw2: USB HID v1.01 Mouse [HP Virtual Keyboard] on > > > > usb-0000:01:04.4-1 > > > > > usb 6-1: New USB device found, idVendor=03f0, idProduct=1027 > > > usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > > usb 6-1: Product: Virtual Keyboard > > > usb 6-1: Manufacturer: HP > > > usb 6-2: new full speed USB device using uhci_hcd and address 3 > > > usb 6-2: configuration #1 chosen from 1 choice > > > hub 6-2:1.0: USB hub found > > > hub 6-2:1.0: 7 ports detected > > > usb 6-2: New USB device found, idVendor=03f0, idProduct=1327 > > > usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > > usb 6-2: Product: Virtual Hub > > > usb 6-2: Manufacturer: HP > > > NET: Registered protocol family 10 > > > lo: Disabled Privacy Extensions > > > ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 23 (level, low) -> IRQ 23 > > > device-mapper: multipath: version 1.0.5 loaded > > > > (this errore is grab from dmesg of f8+upd) > > > > F8 after a lot of timeout during the boot start, but f9+update or f9 > > +update-testing or f9+update-rawhide (2.6.26) not start ... > > -- > Dario Lesca -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Wed Jul 2 16:06:31 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 2 Jul 2008 12:06:31 -0400 Subject: kernel 2.6.25 hanging at boot In-Reply-To: <68720af30807020206i1ff24fr3153e0202cec5da@mail.gmail.com> References: <68720af30807020206i1ff24fr3153e0202cec5da@mail.gmail.com> Message-ID: <200807021206.31174.jwilson@redhat.com> On Wednesday 02 July 2008 05:06:52 am Paulo Cavalcanti wrote: > Hi, > > I have been having problems with kernel 2.6.25 on F8 > with my Dell Vostro 1400 laptop. The boot sometimes freezes. > > It just writes: > > Decompressing Linux ....done. > Booting the kernel. > > and then hangs forever, and I have to press the power down button. > > The interesting thing is that if I suppress the quiet option in > /etc/grub.conf > to have a verbose boot, It does not hang (so it seems). > > This makes me believe that this extra printing introduces a small delay > in the boot process, giving time to something initialize properly, > > Does this make any sense at all? Could it be some kind of race condition? Certainly could be. Definitely file a bug if you haven't already. -- Jarod Wilson jwilson at redhat.com From abo at kth.se Wed Jul 2 16:43:18 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 02 Jul 2008 18:43:18 +0200 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> Message-ID: <1215016998.30577.251.camel@realdor.ite.kth.se> tis 2008-07-01 klockan 12:01 +1000 skrev Andrew Bartlett: > I've recently been working on packaging Heimdal, Samba4 and OpenChange > for Fedora. I really appreciate the initiative here. I'd like to help with the heimdal package, maybe the others as well. I'll go through the ReviewGuidelines and post my findings in bugzilla but as neither of us is sponsored it won't be a formal review. /abo From skvidal at fedoraproject.org Wed Jul 2 17:10:04 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jul 2008 13:10:04 -0400 Subject: yum docs help Message-ID: <1215018604.19021.60.camel@rosebud> Hi folks, we need some help on some yum docs that I'm sure a lot of admins out there have dealt with. I've put together a list of things that I think would help a lot of folks who are using yum/createrepo/etc for the first time and/or are getting involved in slightly more advanced uses. I'd love suggestions for other common (and commonly confusing) cases that could use more docs. Additionally, if anyone wants to help contribute docs on any of these subjects that'd be fantastic. Here's the list: http://skvidal.fedorapeople.org/yum-quickstart-doc-list Thanks, -sv -- I only speak for me. From bpepple at fedoraproject.org Wed Jul 2 17:26:03 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jul 2008 13:26:03 -0400 Subject: Plan for tomorrows (20080703) FESCO meeting Message-ID: <1215019563.2603.2.camel@truman> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- Features - http://fedoraproject.org/wiki/Features/F10PolicyReview -- all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Wed Jul 2 18:19:43 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 02 Jul 2008 11:19:43 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-06-30 Message-ID: <486BC6BF.6010903@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jun-30 Please make corrections and clarifications to the wiki page. == F9 Spins Update == * https://fedorahosted.org/projects/rel-eng/ticket/24 * need virt guests spun up for us from Infrastructure to do the spins and then someone to actually run the commands ** http://fedoraproject.org/wiki/Infrastructure/RFR ** https://fedorahosted.org/fedora-infrastructure/ticket/498 * NEXT ACTIONS: *# jwb will update the ticket *# jeremy will create bugzilla entries *# f13 will attempt making some beta images to put on the torrent server == F10 Release Naming == * Waiting for second round of name review by legal * https://fedorahosted.org/projects/rel-eng/ticket/23 * may run out of time for a them related name == IRC Log == From romal at gmx.de Wed Jul 2 19:25:11 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 02 Jul 2008 21:25:11 +0200 Subject: Packaging of Nagios In-Reply-To: <48642DDD.9000508@edcint.co.nz> References: <48642DDD.9000508@edcint.co.nz> Message-ID: <486BD617.9070201@gmx.de> Hi, I have working packages for Nagios 3.0.3 and Nagios PlugIns 1.4.12. I nearly finished with pnp4nagios, check-multi and nagvis. https://bugzilla.redhat.com/show_bug.cgi?id=452424 https://bugzilla.redhat.com/show_bug.cgi?id=453330 cu romal www.romal.de blog.romal.de Matthew Jurgens schrieb: > I am waiting for the release of the fedora Nagios v3 package and was > > wondering if I could get involved to help speed up the process? > > > > > > From jonathan at jonmasters.org Wed Jul 2 20:10:24 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 16:10:24 -0400 Subject: Request to re-add option to disable SELinux Message-ID: <1215029424.5130.13.camel@perihelion> Hi folks, I'd like to see the re-introduction of an option during (or shortly after, i.e. during firstboot) installation to disable SELinux, or set it to be permissive. My reason for making this request includes: *). A number of activities are not possible today, with SE Linux enabled and enforcing on a default F9 installation. I can give examples - downloading an ISO image and expecting to use it in virt-manager, creating a virtual machine in a non-standard location, etc. *). Policy changes will randomly stop things from working that used to work. Especially on the Desktop, where many possible code paths (SE Linux works by denying until an exception is found and added to the policy...requiring all code paths to be exercised) exist to do something. I found this last week when VPNC randomly broke. *). Tools like nautilus do not support labeling of files via the right-click properties dialog (gnome VFS, etc.) so there is no easy way for an end user who even understands part of this to fix context. This is the number one reason why SELinux should not be enabled by default, except on systems where there is an admin who can use chcon. But there are numerous other justifications I could give, including my personal belief that it's absolutely nuts to thrust SE Linux upon unsuspecting Desktop users (who don't know what it is anyway) without giving them the choice to turn it off. Cheers, Jon. From jkeating at redhat.com Wed Jul 2 20:22:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Jul 2008 16:22:21 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <1215030141.17856.30.camel@localhost.localdomain> On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > But there are numerous other justifications I could give, including my > personal belief that it's absolutely nuts to thrust SE Linux upon > unsuspecting Desktop users (who don't know what it is anyway) without > giving them the choice to turn it off. If they don't know what it is, how are they supposed to decide to shut it off or not? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jcm at redhat.com Wed Jul 2 20:29:20 2008 From: jcm at redhat.com (Jon Masters) Date: Wed, 02 Jul 2008 16:29:20 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030141.17856.30.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> Message-ID: <1215030560.5130.21.camel@perihelion> On Wed, 2008-07-02 at 16:22 -0400, Jesse Keating wrote: > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > But there are numerous other justifications I could give, including my > > personal belief that it's absolutely nuts to thrust SE Linux upon > > unsuspecting Desktop users (who don't know what it is anyway) without > > giving them the choice to turn it off. > > If they don't know what it is, how are they supposed to decide to shut > it off or not? I see your logic Jesse, and I did think about it. But one might also say, "how about we just force it down their throats because it's good medicine for them?" ;) I'm concerned that this is what's happening :) I think what's needed is a nice little paragraph summarizing what SELinux is aiming to do, and then the old option of setting permissive or disabling - users can then set permissive if they prefer to. Jon. From mclasen at redhat.com Wed Jul 2 20:29:29 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 Jul 2008 16:29:29 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <1215030569.3307.1.camel@localhost.localdomain> On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > *). Tools like nautilus do not support labeling of files via the > right-click properties dialog (gnome VFS, etc.) so there is no easy way > for an end user who even understands part of this to fix context. This > is the number one reason why SELinux should not be enabled by default, > except on systems where there is an admin who can use chcon. I don't disagree with the general sentiment that selinux is not a very good fit for desktop users as it is today. But nautilus _does_ support labeling of files via the right-click properties dialog. From dmalcolm at redhat.com Wed Jul 2 20:32:36 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 02 Jul 2008 16:32:36 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <1215030756.4684.98.camel@radiator.bos.redhat.com> On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: [snip] > > *). Tools like nautilus do not support labeling of files via the > right-click properties dialog (gnome VFS, etc.) so there is no easy way > for an end user who even understands part of this to fix context. This > is the number one reason why SELinux should not be enabled by default, > except on systems where there is an admin who can use chcon. Sounds like a regression; this used to work fine (on this RHEL5 ~ FC6 box I can do this from the Permissions tab of the nautilus file properties dialog, and watch the SELinux column of the nautilus List View change). > > But there are numerous other justifications I could give, including my > personal belief that it's absolutely nuts to thrust SE Linux upon > unsuspecting Desktop users (who don't know what it is anyway) without > giving them the choice to turn it off. What is this "kernel" thing? Why do I need it? From jspaleta at gmail.com Wed Jul 2 20:34:10 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 2 Jul 2008 12:34:10 -0800 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030569.3307.1.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030569.3307.1.camel@localhost.localdomain> Message-ID: <604aa7910807021334q332f719ex915b90a662daae7f@mail.gmail.com> On Wed, Jul 2, 2008 at 12:29 PM, Matthias Clasen wrote: > I don't disagree with the general sentiment that selinux is not a very > good fit for desktop users as it is today. But nautilus _does_ support > labeling of files via the right-click properties dialog. Are people more clever than me trying to work out a way to indicate if a file is mislabeled via the file manager graphical interface? Is that even technically possible? And if it is would would be a good UI way to show that information without having to open up a properties dialog window to see it? -jef"votes for slowly pulsating red glow on the mislabeled file icon"spaleta From walters at verbum.org Wed Jul 2 20:28:23 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 2 Jul 2008 16:28:23 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030141.17856.30.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> Message-ID: 2008/7/2 Jesse Keating : > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > But there are numerous other justifications I could give, including my > > personal belief that it's absolutely nuts to thrust SE Linux upon > > unsuspecting Desktop users (who don't know what it is anyway) without > > giving them the choice to turn it off. > > If they don't know what it is, how are they supposed to decide to shut > it off or not? Yeah, we're trying to make installing Fedora not be a Choose Your Own Linux Adventure game. Either the SELinux policy works well enough that it is enabled by default and supported, or it's not. Besides, the option already exists - you can system-config-selinux after installing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Wed Jul 2 20:33:01 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jul 2008 16:33:01 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030569.3307.1.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030569.3307.1.camel@localhost.localdomain> Message-ID: <1215030781.19021.64.camel@rosebud> On Wed, 2008-07-02 at 16:29 -0400, Matthias Clasen wrote: > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > > *). Tools like nautilus do not support labeling of files via the > > right-click properties dialog (gnome VFS, etc.) so there is no easy way > > for an end user who even understands part of this to fix context. This > > is the number one reason why SELinux should not be enabled by default, > > except on systems where there is an admin who can use chcon. > > I don't disagree with the general sentiment that selinux is not a very > good fit for desktop users as it is today. But nautilus _does_ support > labeling of files via the right-click properties dialog. > Where? I see it showing me what they are but I don't see how to change them. is it an option I have to enable? -sv From jonathan at jonmasters.org Wed Jul 2 20:37:48 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 16:37:48 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030560.5130.21.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> Message-ID: <1215031068.5130.30.camel@perihelion> On Wed, 2008-07-02 at 16:29 -0400, Jon Masters wrote: > I think what's needed is a nice little paragraph summarizing what > SELinux is aiming to do, and then the old option of setting permissive > or disabling - users can then set permissive if they prefer to. Note that when I say this, I'm one of the users who might well turn it off (well, set permissive) again on future installs. I've lived with SELinux enforcing on F9 for under two weeks and have found it highly inhibitive to performing many regular everyday tasks I'm used to. I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux policy update in F9 had randomly stopped VPNC from working in a policy update - that came following days of denials trying to do even simple stuff. I can't possibly see how thrusting this default upon masses of otherwise unsuspecting users is a good idea. I'm not saying SELinux isn't a fantastic idea in certain cases, just not on "the desktop". Dan, et al, no offense, but we need the option to come back :) Jon. [0] It had been almost ten years since I last read through all that documentation. So although I learned a lot about our current policy, and what has changed over the years in SELinux, so that I could understand the current targeted policy source, this isn't something regular Fedora users should have to do in order to be using their computers :) From jcm at redhat.com Wed Jul 2 20:39:35 2008 From: jcm at redhat.com (Jon Masters) Date: Wed, 02 Jul 2008 16:39:35 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030569.3307.1.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030569.3307.1.camel@localhost.localdomain> Message-ID: <1215031175.5130.32.camel@perihelion> On Wed, 2008-07-02 at 16:29 -0400, Matthias Clasen wrote: > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > > *). Tools like nautilus do not support labeling of files via the > > right-click properties dialog (gnome VFS, etc.) so there is no easy way > > for an end user who even understands part of this to fix context. This > > is the number one reason why SELinux should not be enabled by default, > > except on systems where there is an admin who can use chcon. > > I don't disagree with the general sentiment that selinux is not a very > good fit for desktop users as it is today. But nautilus _does_ support > labeling of files via the right-click properties dialog. It displays the current context. I'm guessing if you're root at the time then it probably allows you to change it, but that's not useful until there's e.g. a PolicyKit hook that allows regular users to relabel. Jon. From jonathan at jonmasters.org Wed Jul 2 20:46:35 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 16:46:35 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> Message-ID: <1215031595.5130.38.camel@perihelion> On Wed, 2008-07-02 at 16:28 -0400, Colin Walters wrote: > Yeah, we're trying to make installing Fedora not be a Choose Your Own > Linux Adventure game. I agree (partially) with that sentiment. Though it can obviously go way too far with the aim of making life "easier" during a 10 minute install. > Either the SELinux policy works well enough that it is enabled by > default and supported, or it's not. If it were really black and white like that, then I'd have to argue for SELinux to be disabled by default on new Fedora installs and have users go into the system config dialog to turn it back on. After all, if you're going to use the following argument: > Besides, the option already exists - you can system-config-selinux > after installing. Then consider, those who know what SELinux is are more likely to know about that dialog, and therefore more likely to turn it on. If you don't like that, then I suggest giving thought to re-instating the option :) Jon. From m at cotdp.com Wed Jul 2 20:56:43 2008 From: m at cotdp.com (Michael) Date: Wed, 2 Jul 2008 20:56:43 +0000 (GMT) Subject: Kernel 2.6.25 (F8/F9) problem Message-ID: <332221.15344.qm@web25903.mail.ukl.yahoo.com> Yesterday I installed Fedora Core 9 on three HP DL380 G5's and noticed stability problems from the first boot. Apparently randomly one machine would boot (fairly) normally, the other would freeze during boot and the third would tail out stacktraces (CPU# frozen for 61secs?!). All three were fresh installs from the same DVD on the same hardware. Rebooting the machines was a russian roulette on which would come back up. I upgraded from 2.6.25-14.fc9.i686 to 2.6.25.6-55.fc9.i686 and still had the same problem on all three machines. Below is a snapshot from dmesg showing the problem. I have just installed 2.6.26-0.98.rc8.git1.fc10.i686 and the problem seems to have gone away. hpwdt: New timer passed in is 30 seconds. general protection fault: 0018 [#1] SMP Modules linked in: ata_piix(+) joydev ipmi_si ipmi_msghandler iTCO_wdt pata_acpi hpwdt(+) i5000_edac bnx2 serio_raw iTCO _vendor_support libata edac_core button pcspkr dm_snapshot dm_zero dm_mirror dm_mod cciss scsi_mod ext3 jbd mbcache uhci _hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 860, comm: modprobe Not tainted (2.6.25.6-55.fc9.i686 #1) EIP: 0060:[] EFLAGS: 00010046 CPU: 2 EIP is at 0xc0100010 EAX: 00000018 EBX: c00ffee0 ECX: 000f1fff EDX: 00000000 ESI: f88e7608 EDI: f78d5000 EBP: f799ddd0 ESP: f799ddb0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 860, ti=f799d000 task=f6914000 task.ti=f799d000) Stack: f78d5000 c00f0000 f799ddd0 c00f0000 c00ffee0 f88e757c f88e754c f78d5000 f799dde4 c04fdfa9 f78d5054 00000000 f88e757c f799ddf8 c0561dbe f78d5054 f78d510c f88e757c f799de0c c0561ecd f799de18 00000000 c0722310 f799de30 Call Trace: [] ? pci_device_probe+0x39/0x59 [] ? driver_probe_device+0xa0/0x136 [] ? __driver_attach+0x79/0xaf [] ? bus_for_each_dev+0x3b/0x63 [] ? driver_attach+0x14/0x16 [] ? __driver_attach+0x0/0xaf [] ? bus_add_driver+0x9d/0x1ba [] ? driver_register+0x47/0xa7 [] ? __pci_register_driver+0x35/0x64 [] ? hpwdt_init+0x17/0x19 [hpwdt] [] ? sys_init_module+0x17be/0x18f6 [] ? iTCO_wdt_set_NO_REBOOT_bit+0x0/0x5e [iTCO_wdt] [] ? selinux_file_permission+0x100/0x106 [] ? param_get_int+0x0/0x15 [] ? security_file_permission+0xf/0x11 [] ? sys_read+0x3b/0x60 [] ? syscall_call+0x7/0xb [] ? agp_amd64_probe+0x2e4/0x3ee ======================= Code: 20 20 38 30 33 43 4f 4d 50 41 51 ea 00 50 00 f0 31 32 2f 33 31 2f 39 39 20 fc 00 fc f6 86 11 02 00 00 40 75 10 fa b8 18 00 00 00 <8e> d8 8e c0 8e e0 8e e8 8e d0 8d a6 e8 01 00 00 e8 00 00 00 00 EIP: [] 0xc0100010 SS:ESP 0068:f799ddb0 ---[ end trace bf9a71d2e7f8ea36 ]--- BUG: sleeping function called from invalid context at kernel/rwsem.c:21 in_atomic():0, irqs_disabled():1 Pid: 860, comm: modprobe Tainted: G D 2.6.25.6-55.fc9.i686 #1 [] __might_sleep+0xae/0xb3 [] down_read+0x15/0x29 [] acct_collect+0x37/0x15d [] do_exit+0x1a9/0x554 [] die+0x15c/0x164 [] do_general_protection+0x247/0x24f [] ? __ioremap+0x116/0x148 [] ? do_general_protection+0x0/0x24f [] error_code+0x72/0x78 [] pci_device_probe+0x39/0x59 [] driver_probe_device+0xa0/0x136 [] __driver_attach+0x79/0xaf [] bus_for_each_dev+0x3b/0x63 [] driver_attach+0x14/0x16 [] ? __driver_attach+0x0/0xaf [] bus_add_driver+0x9d/0x1ba [] driver_register+0x47/0xa7 [] __pci_register_driver+0x35/0x64 [] hpwdt_init+0x17/0x19 [hpwdt] [] sys_init_module+0x17be/0x18f6 [] ? iTCO_wdt_set_NO_REBOOT_bit+0x0/0x5e [iTCO_wdt] [] ? selinux_file_permission+0x100/0x106 [] ? param_get_int+0x0/0x15 [] ? security_file_permission+0xf/0x11 [] ? sys_read+0x3b/0x60 [] syscall_call+0x7/0xb [] ? agp_amd64_probe+0x2e4/0x3ee ======================= Regards, MC __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html From dledford at redhat.com Wed Jul 2 20:58:41 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 02 Jul 2008 16:58:41 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031175.5130.32.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030569.3307.1.camel@localhost.localdomain> <1215031175.5130.32.camel@perihelion> Message-ID: <1215032322.32506.143.camel@firewall.xsintricity.com> On Wed, 2008-07-02 at 16:39 -0400, Jon Masters wrote: > On Wed, 2008-07-02 at 16:29 -0400, Matthias Clasen wrote: > > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > > > > > *). Tools like nautilus do not support labeling of files via the > > > right-click properties dialog (gnome VFS, etc.) so there is no easy way > > > for an end user who even understands part of this to fix context. This > > > is the number one reason why SELinux should not be enabled by default, > > > except on systems where there is an admin who can use chcon. > > > > I don't disagree with the general sentiment that selinux is not a very > > good fit for desktop users as it is today. But nautilus _does_ support > > labeling of files via the right-click properties dialog. > > It displays the current context. I'm guessing if you're root at the time > then it probably allows you to change it, but that's not useful until > there's e.g. a PolicyKit hook that allows regular users to relabel. Well, that's just incredibly helpful when combined with the whole "you should never, under any circumstances, run X windows as root" thread of a few days ago ;-) -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 walters at verbum.org Wed Jul 2 20:58:58 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 2 Jul 2008 16:58:58 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031595.5130.38.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> Message-ID: On Wed, Jul 2, 2008 at 4:46 PM, Jon Masters wrote: > On Wed, 2008-07-02 at 16:28 -0400, Colin Walters wrote: > > > Yeah, we're trying to make installing Fedora not be a Choose Your Own > > Linux Adventure game. > > I agree (partially) with that sentiment. Though it can obviously go way > too far with the aim of making life "easier" during a 10 minute install. > I don't think we can go too far in cutting out the crap from the install process for desktops. The target audience is (or should be) people who have *more important things* to do with their time than play Build My Own Linux. They hit "Next" on the partitioning screens, firewall, etc. If our defaults are broken, we should acknowledge that as a bug instead of foisting the choice onto our users. > Either the SELinux policy works well enough that it is enabled by > > default and supported, or it's not. > > If it were really black and white like that, then I'd have to argue for > SELinux to be disabled by default on new Fedora installs and have users > go into the system config dialog to turn it back on. After all, if > you're going to use the following argument: > Yes, I think what you should be arguing is that it should be permissive or disabled by default. I'm not sure I would agree with that argument personally given that I see little hope for any other extended security system (e.g. AppArmor is architecturally broken). There are plenty of other possible choices besides just enabling by default or disabling: o Default rawhide installs to permissive o Create a system that automatically sends denials back to Fedora and treat them like crashes o Tune down the default policy to move more things back into unconfined_t, and focus more strongly on vulnerable network servers like Samba, Apache etc. o Actually have a regression test suite for Fedora and run updates through it etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Wed Jul 2 21:09:58 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jul 2008 17:09:58 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030141.17856.30.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> Message-ID: <20080702210958.GA27060@devserv.devel.redhat.com> On Wed, Jul 02, 2008 at 04:22:21PM -0400, Jesse Keating wrote: > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > But there are numerous other justifications I could give, including my > > personal belief that it's absolutely nuts to thrust SE Linux upon > > unsuspecting Desktop users (who don't know what it is anyway) without > > giving them the choice to turn it off. > > If they don't know what it is, how are they supposed to decide to shut > it off or not? Knowing what it is isn't sufficient - they must know enough to make a meaningful risk analysis fo the decision. Very few users I suspect are in that position. From alan at redhat.com Wed Jul 2 21:13:05 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jul 2008 17:13:05 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031068.5130.30.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> Message-ID: <20080702211305.GB27060@devserv.devel.redhat.com> On Wed, Jul 02, 2008 at 04:37:48PM -0400, Jon Masters wrote: > I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux > policy update in F9 had randomly stopped VPNC from working in a policy > update - that came following days of denials trying to do even simple > stuff. I can't possibly see how thrusting this default upon masses of > otherwise unsuspecting users is a good idea. I'm not saying SELinux > isn't a fantastic idea in certain cases, just not on "the desktop". The desktop is where it is most needed. But here is a silly question - why are you using vpnc if you turn SELinux off, telnet would be faster too ? Alan From jonathan at jonmasters.org Wed Jul 2 21:14:27 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 17:14:27 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> Message-ID: <1215033267.5130.49.camel@perihelion> On Wed, 2008-07-02 at 16:58 -0400, Colin Walters wrote: > I don't think we can go too far in cutting out the crap from the > install process for desktops. Like I said, I like the sentiment ;) > If our defaults are broken, we should acknowledge that as a bug > instead of foisting the choice onto our users. Ok, so... > Yes, I think what you should be arguing is that it should be > permissive or disabled by default. Ok then let me just say it. I think the default should be permissive or disabled by default. I was hoping to not have to say that - but I think it's a lot safer on the mass userbase of Fedora than thrusting a fully enforcing SELinux policy set upon them. If I'm having to hack on the policy files on my laptop, there's no hope for a desktop user. > I'm not sure I would agree with that argument personally given that I > see little hope for any other extended security system (e.g. AppArmor > is architecturally broken). Oh, see this is why I didn't want to just say "let's turn it off by default", because people read it as an attack on SELinux itself. But it doesn't have to be like that. SELinux is well designed (App Armor is basically crackrock in my personal opinion) but it's extremely complicated in terms of the policy that exists. It's also not for everyone, in my opinion. I think that SELinux makes great sense on a server running a timesharing environment, far less on a desktop. > There are plenty of other possible choices besides just enabling by > default or disabling: > > o Default rawhide installs to permissive And yet the issues I've had have all been on F9, stock. > o Create a system that automatically sends denials back to Fedora and > treat them like crashes There's still a lead time of days, or weeks. Dan is *very* good (I'm being careful here to explicitly say I'm not attacking the folks behind the policy - he updated the policy within a day of e.g. the VPNC issue) but the whole thing is still very reactionary to problem reports. If a user tries to do some of the things I tried, and they fail, they'll just give up on trying, and think that it's all a waste of time. > o Tune down the default policy to move more things back into > unconfined_t, and focus more strongly on vulnerable network servers > like Samba, Apache etc. This absolutely the most essential thing to be doing. I've been arguing this for ever and ever. Personally, I think SELinux is a great tool on servers to protect network facing stuff...but there needs to be a middle ground on Desktops where people can just get stuff done. I haven't pushed this on fedora-devel - I didn't expect a warm response ;) > o Actually have a regression test suite for Fedora and run updates > through it Well, while we're at it, we really need to encourage more people to use bodhi and start voting (and thereby assigning karma), and knowing about updates (which should only ever contain essential fixes). But that's another whole bucket of worms for a different thread. Jon. > From alan at redhat.com Wed Jul 2 21:16:10 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jul 2008 17:16:10 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031595.5130.38.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> Message-ID: <20080702211610.GC27060@devserv.devel.redhat.com> On Wed, Jul 02, 2008 at 04:46:35PM -0400, Jon Masters wrote: > If it were really black and white like that, then I'd have to argue for > SELinux to be disabled by default on new Fedora installs and have users > go into the system config dialog to turn it back on. After all, if > you're going to use the following argument: "This car has brakes, enable them ?" "Would you like the seatbelts to work ?" "Shall I enable the airbag ?" > Then consider, those who know what SELinux is are more likely to know > about that dialog, and therefore more likely to turn it on. If you don't > like that, then I suggest giving thought to re-instating the option :) One of the Gnome talks summed this up nicely long ago - how do most users see dialogue boxes like that - the answer is as random noise you hit the yes button too. SELinux should be disablable is the wrong discussion. The discussion you should be having is "I've filed a few bugs where SELinux didn't magically do the right thing, how do we fix them and can we make these less likely to occur in future" If it was a car this discussion ie - "I had a brake problem so I disabled them" would not be considered sane Alan From jonathan at jonmasters.org Wed Jul 2 21:16:26 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 17:16:26 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080702211305.GB27060@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> <20080702211305.GB27060@devserv.devel.redhat.com> Message-ID: <1215033386.5130.52.camel@perihelion> On Wed, 2008-07-02 at 17:13 -0400, Alan Cox wrote: > On Wed, Jul 02, 2008 at 04:37:48PM -0400, Jon Masters wrote: > > I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux > > policy update in F9 had randomly stopped VPNC from working in a policy > > update - that came following days of denials trying to do even simple > > stuff. I can't possibly see how thrusting this default upon masses of > > otherwise unsuspecting users is a good idea. I'm not saying SELinux > > isn't a fantastic idea in certain cases, just not on "the desktop". > > The desktop is where it is most needed. Yes, in a perfect world in which policy and reality were so well aligned that everything just worked, all of the time. > But here is a silly question - why are you using vpnc if you turn SELinux off, > telnet would be faster too ? I didn't turn SELinux off. I'm forcing myself to use it in enforcing mode, and I will continue to do so. But I think it's absolutely nuts to expect the average Fedora desktop user to do so :) Jon. From jonathan at jonmasters.org Wed Jul 2 21:20:50 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 17:20:50 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080702211610.GC27060@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> Message-ID: <1215033650.5130.57.camel@perihelion> On Wed, 2008-07-02 at 17:16 -0400, Alan Cox wrote: > On Wed, Jul 02, 2008 at 04:46:35PM -0400, Jon Masters wrote: > > If it were really black and white like that, then I'd have to argue for > > SELinux to be disabled by default on new Fedora installs and have users > > go into the system config dialog to turn it back on. After all, if > > you're going to use the following argument: > > "This car has brakes, enable them ?" Well, you can turn the ABS on and off in some cases. > "Would you like the seatbelts to work ?" > "Shall I enable the airbag ?" You can turn the child restraint passenger system on/off on most models of car to deal with the injury sustained from airbag deployment. "Would you like to use regular gas or premium?" > SELinux should be disablable is the wrong discussion. The discussion you should > be having is "I've filed a few bugs where SELinux didn't magically do the right > thing, how do we fix them and can we make these less likely to occur in future" I think the only way to "fix" it for the foreseeable future is to simplify policy, so that only a very limited set of services are confined. Then, when the graphical tools and user experience have eventually caught up, it'll be trivial to switch policy again. > If it was a car this discussion ie - "I had a brake problem so I disabled them" > would not be considered sane No, but there are many other more suitable analogies :) Jon. From bruno at wolff.to Wed Jul 2 21:36:15 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 2 Jul 2008 16:36:15 -0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080702211610.GC27060@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> Message-ID: <20080702213615.GA4756@wolff.to> On Wed, Jul 02, 2008 at 17:16:10 -0400, Alan Cox wrote: > "Shall I enable the airbag ?" That one I'd actually like. From gemi at bluewin.ch Wed Jul 2 21:47:50 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 02 Jul 2008 23:47:50 +0200 Subject: Koji build failure on ppc64 without visible errors Message-ID: <1215035270.29254.6.camel@localhost.localdomain> The following tasks failed on ppc64: http://koji.fedoraproject.org/koji/taskinfo?taskID=693357 However the build log shows no errors, the build simply stops after creating the src rpm. Any ideas? From ssorce at redhat.com Wed Jul 2 21:48:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 17:48:35 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215033386.5130.52.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> <20080702211305.GB27060@devserv.devel.redhat.com> <1215033386.5130.52.camel@perihelion> Message-ID: <1215035315.353.143.camel@localhost.localdomain> On Wed, 2008-07-02 at 17:16 -0400, Jon Masters wrote: > On Wed, 2008-07-02 at 17:13 -0400, Alan Cox wrote: > > On Wed, Jul 02, 2008 at 04:37:48PM -0400, Jon Masters wrote: > > > I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux > > > policy update in F9 had randomly stopped VPNC from working in a policy > > > update - that came following days of denials trying to do even simple > > > stuff. I can't possibly see how thrusting this default upon masses of > > > otherwise unsuspecting users is a good idea. I'm not saying SELinux > > > isn't a fantastic idea in certain cases, just not on "the desktop". > > > > The desktop is where it is most needed. > > Yes, in a perfect world in which policy and reality were so well aligned > that everything just worked, all of the time. > > > But here is a silly question - why are you using vpnc if you turn SELinux off, > > telnet would be faster too ? > > I didn't turn SELinux off. I'm forcing myself to use it in enforcing > mode, and I will continue to do so. But I think it's absolutely nuts to > expect the average Fedora desktop user to do so :) 1) you are not the average user, your experience is biased and your usage patterns are not standard 2) I use SELinux in enforcing mode since F8, I had almost no problems, I do development and all. I know what SELinux is and when to change to permissive. Moreover, given I am doing development and I am fiddling with non-standard stuff I expect to have randomly problems with SELinux (which is all about blocking non-standard behavior), so I just took my 2 hours self-teaching course on SELinux and know how to diagnose and change labels when needed. I even ventured into changing some policy for the packages I work on, although Dan Walsh is super in helping out with that stuff and learning how to write policies is not strictly needed. Take your time, learn what SELinux is and help back to make it better my providing changes relative to packages you own or you use most. This will be abetter use of your time. I wonder if windows developers had the same attitude toward NTFS ACLs when Microsoft started transitioning them from FAT ... I think us Linux devs can handle SELinux, conceptually and practically. Simo. -- Simo Sorce * Red Hat, Inc * New York From xavier at bachelot.org Wed Jul 2 20:59:51 2008 From: xavier at bachelot.org (Xavier Bachelot) Date: Wed, 02 Jul 2008 22:59:51 +0200 Subject: Packaging of Nagios In-Reply-To: <486BD617.9070201@gmx.de> References: <48642DDD.9000508@edcint.co.nz> <486BD617.9070201@gmx.de> Message-ID: <486BEC47.4040702@bachelot.org> Robert M. Albrecht wrote: > Hi, > > I have working packages for Nagios 3.0.3 and Nagios PlugIns 1.4.12. > > I nearly finished with pnp4nagios, check-multi and nagvis. > I already have a package for pnp4nagios, it's awaiting a good willing reviewer. https://bugzilla.redhat.com/show_bug.cgi?id=442342 There is also DNX by a not-yet-sponsored packager awaiting for review. https://bugzilla.redhat.com/show_bug.cgi?id=441570 And iirc, there are a few other nagios related packages in the review queue. A quick search found only https://bugzilla.redhat.com/show_bug.cgi?id=446847 but there are possibly more. Regards, Xavier From mikeb at redhat.com Wed Jul 2 21:57:32 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 02 Jul 2008 17:57:32 -0400 Subject: Koji build failure on ppc64 without visible errors In-Reply-To: <1215035270.29254.6.camel@localhost.localdomain> References: <1215035270.29254.6.camel@localhost.localdomain> Message-ID: <1215035852.15910.6.camel@localhost.localdomain> On Wed, 2008-07-02 at 23:47 +0200, G?rard Milmeister wrote: > The following tasks failed on ppc64: > http://koji.fedoraproject.org/koji/taskinfo?taskID=693357 > However the build log shows no errors, the build simply > stops after creating the src rpm. In root.log: DEBUG util.py:250: No Package Found for ffcall From jkeating at redhat.com Wed Jul 2 21:57:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Jul 2008 17:57:55 -0400 Subject: Koji build failure on ppc64 without visible errors In-Reply-To: <1215035270.29254.6.camel@localhost.localdomain> References: <1215035270.29254.6.camel@localhost.localdomain> Message-ID: <1215035875.17856.36.camel@localhost.localdomain> On Wed, 2008-07-02 at 23:47 +0200, G?rard Milmeister wrote: > The following tasks failed on ppc64: > http://koji.fedoraproject.org/koji/taskinfo?taskID=693357 > However the build log shows no errors, the build simply > stops after creating the src rpm. > > Any ideas? DEBUG util.py:250: No Package Found for ffcall Mock exist 10 means something in root.log failed, IE initing the buildroot or installing the build requires. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jonathan at jonmasters.org Wed Jul 2 21:57:59 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 17:57:59 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215035315.353.143.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> <20080702211305.GB27060@devserv.devel.redhat.com> <1215033386.5130.52.camel@perihelion> <1215035315.353.143.camel@localhost.localdomain> Message-ID: <1215035879.5130.64.camel@perihelion> On Wed, 2008-07-02 at 17:48 -0400, Simo Sorce wrote: > 1) you are not the average user, your experience is biased and your > usage patterns are not standard I agree I'm not a "typical user", however some of the things I've had problems with are being used by typical users - I'm deliberately trying to avoid examples of copying configuration files and the like :) > Take your time, learn what SELinux is and help back to make it better my > providing changes relative to packages you own or you use most. This > will be abetter use of your time. I'm all for helping to find and fix policy issues - why do you think I left it enabled :) I've followed SELinux on and off for about a decade, though this is the first time I've tried enforcing on a "desktop" box. And I feel that my previous reasoning for turning it off on my desktops and laptops is once again justified...unfortunately. > I wonder if windows developers had the same attitude toward NTFS ACLs > when Microsoft started transitioning them from FAT ... I think us Linux > devs can handle SELinux, conceptually and practically. That's a lousy example. I use Linux ACLs and have done since long before they were upstream and in stock vendor kernels - ACLs are great, and we're not shipping a complex default set of ACLs anyway :) Let's compare apples and apples :) Jon. From jcvlz at jcvlz.com Wed Jul 2 20:56:46 2008 From: jcvlz at jcvlz.com (jcvlz) Date: Wed, 2 Jul 2008 16:56:46 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031595.5130.38.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> Message-ID: <75f1d4690807021356h6e2115a6r91f8490dd4e8b7c9@mail.gmail.com> It sounds like this issue has more to do with how easily an "average" end user can admin/modify selinux and it's policies through a GUI interface. So what about extending the functionality of one of the gui apps? i.e. -If setroubleshoot is not part of the base package, include it and have it turned on by default -Add audit2allow/audit2why functionality to setroubleshoot -Simplify the details section of setroubleshoot to be more meaningful to end-users FWIW - I'm for keeping selinux enforcing by default, but could definitely see where end-users could be running into issues. Juan Velez From caillon at redhat.com Wed Jul 2 22:15:55 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 02 Jul 2008 18:15:55 -0400 Subject: Koji build failure on ppc64 without visible errors In-Reply-To: <1215035875.17856.36.camel@localhost.localdomain> References: <1215035270.29254.6.camel@localhost.localdomain> <1215035875.17856.36.camel@localhost.localdomain> Message-ID: <486BFE1B.3070109@redhat.com> Jesse Keating wrote: > On Wed, 2008-07-02 at 23:47 +0200, G?rard Milmeister wrote: >> The following tasks failed on ppc64: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=693357 >> However the build log shows no errors, the build simply >> stops after creating the src rpm. >> >> Any ideas? > > DEBUG util.py:250: No Package Found for ffcall > > Mock exist 10 means something in root.log failed, IE initing the > buildroot or installing the build requires. "BuildrootError: error building package (arch ppc64), mock exited with status 10 " Which is not really intuitive. That message should probably tell people where to look, or even provide a direct link to the log file in question since we know what arch failed and what log file we need. From mclasen at redhat.com Wed Jul 2 23:01:42 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 Jul 2008 19:01:42 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215030781.19021.64.camel@rosebud> References: <1215029424.5130.13.camel@perihelion> <1215030569.3307.1.camel@localhost.localdomain> <1215030781.19021.64.camel@rosebud> Message-ID: <1215039702.3307.31.camel@localhost.localdomain> On Wed, 2008-07-02 at 16:33 -0400, seth vidal wrote: > On Wed, 2008-07-02 at 16:29 -0400, Matthias Clasen wrote: > > On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > > > > > > > > *). Tools like nautilus do not support labeling of files via the > > > right-click properties dialog (gnome VFS, etc.) so there is no easy way > > > for an end user who even understands part of this to fix context. This > > > is the number one reason why SELinux should not be enabled by default, > > > except on systems where there is an admin who can use chcon. > > > > I don't disagree with the general sentiment that selinux is not a very > > good fit for desktop users as it is today. But nautilus _does_ support > > labeling of files via the right-click properties dialog. > > > > Where? I see it showing me what they are but I don't see how to change > them. > > is it an option I have to enable? Ah, I think the fix for that narrowly missed F9. I have it working on rawhide here. From contact at philipashmore.com Wed Jul 2 23:19:44 2008 From: contact at philipashmore.com (Philip Ashmore) Date: Thu, 03 Jul 2008 00:19:44 +0100 Subject: yum docs help (seth vidal) Message-ID: <486C0D10.1070006@philipashmore.com> Hi there. It would help me (and no doubt others as well) if you could add a section on pup / yum-updatesd. In my experience these seem to be doing do something network-related outside of yum when determining if updates are available - all my repos are local. For example sometimes I get notified that "updates are available" via pup / yum-updatesd KDE panel applet, but running "yum update" yields "no updates available". I use rsync to synchronise my local repos to (geographically) local internet mirrors and even these haven't changed, leading me to suspect that the changes pup / yum-updatesd see haven't even hit the local mirrors yet. Philip Ashmore From jbarnes at virtuousgeek.org Thu Jul 3 00:54:52 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Wed, 2 Jul 2008 17:54:52 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> Message-ID: <200807021754.52422.jbarnes@virtuousgeek.org> On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > I've recently been working on packaging Heimdal, Samba4 and OpenChange > for Fedora. > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > OpenChange) > > This will enable much better access to Microsoft Exchange servers from > clients such as kdepim, and hopefully Evolution (pending a > re-licensing). > > I've got a feature page for this here: > > https://fedoraproject.org/wiki/Features/OpenChange > > Now, the reason I'm posting here is that I would rather not do this > alone, and would love some co-maintainers of the packagers above, or at > least some help with the review and sponsorship, or advise on the best > way forward. > > Any assistance gratefully received, Just pulled down the packages (including the alpha5 samba4 package) and started building. I haven't got to the kde libraries yet (that build will probably take awhile) but on the packages above, I found the following: heimdal: - openssl-devel depends on krb5-devel, but heimdal-devel conflicts with krb5-devel; should it provide it or do we need a virtual provides for krb5? - heimdal seemed to be missing a file directive for the dir.gz info file samba4: - everything seems fine here so far... libmapi: - didn't list the popt requirement, so initially I built without it and the packaging failed due to missing binaries (which required popt-devel) - libmapi-devel should depend on libmapi-0.7... rather than libmapi-libs-0.7...? I've attached my spec file diffs in case you want to see (though now I see you've already fixed the libmapi-libs problem I saw)... Thanks for packaging this stuff, I really hope the MAPI Akonadi code works; I'd *love* to ditch Outlook (it's the next best thing to escaping the Exchange ghetto). Thanks, Jesse -------------- next part -------------- A non-text attachment was scrubbed... Name: heimdal-spec.patch Type: text/x-diff Size: 959 bytes Desc: not available URL: From jmorris at namei.org Thu Jul 3 01:29:07 2008 From: jmorris at namei.org (James Morris) Date: Thu, 3 Jul 2008 11:29:07 +1000 (EST) Subject: Request to re-add option to disable SELinux In-Reply-To: <20080702210958.GA27060@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <20080702210958.GA27060@devserv.devel.redhat.com> Message-ID: On Wed, 2 Jul 2008, Alan Cox wrote: > Knowing what it is isn't sufficient - they must know enough to make a meaningful > risk analysis fo the decision. Very few users I suspect are in that position. This is quite a significant problem, as people tend to underestimate negative risk and overestimate positive risk (according to "Prospect Theory"). And as the odds increase in each direction, people increasingly mis-judge them. e.g. people believe they'll win the lottery but figure they don't need a motorcycle helmet. Bruce Schneier recently discussed the topic: http://www.schneier.com/blog/archives/2008/05/how_to_sell_sec.html The only way to really make progress in improving security is to make it a standard part of the computing landscape; for it to be ubiquitous and generalized, which is the aim of the SELinux project. Having a separate "secure" version or option will not work, as proven many times over with the trusted Unix variants which are essentially forks of their respective mainline products. Avoiding the whole issue will also not work, as DAC security simply cannot provide adequate protection in a globally networked environment. The rationale for MAC has been made very clear in an NSA paper, the reading of which I think is essential for any informed discussion on the issue: http://www.nsa.gov/selinux/papers/inevitability/ Punting the decision to the end user during installation is possibly the worst option. It's our responsibility as the developers of the OS to both get security right and make it usable. It's difficult, indeed, but not impossible. - James -- James Morris From lordmorgul at gmail.com Thu Jul 3 01:29:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 02 Jul 2008 18:29:21 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215033650.5130.57.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> Message-ID: <486C2B71.90801@gmail.com> Jon Masters wrote: > On Wed, 2008-07-02 at 17:16 -0400, Alan Cox wrote: >> SELinux should be disablable is the wrong discussion. The discussion you should >> be having is "I've filed a few bugs where SELinux didn't magically do the right >> thing, how do we fix them and can we make these less likely to occur in future" > > I think the only way to "fix" it for the foreseeable future is to > simplify policy, so that only a very limited set of services are > confined. Then, when the graphical tools and user experience have > eventually caught up, it'll be trivial to switch policy again. selinux-policy-targeted is precisely that. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From jonathan at jonmasters.org Thu Jul 3 01:34:53 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 02 Jul 2008 21:34:53 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <486C2B71.90801@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <486C2B71.90801@gmail.com> Message-ID: <1215048893.6786.4.camel@perihelion> On Wed, 2008-07-02 at 18:29 -0700, Andrew Farris wrote: > Jon Masters wrote: > > On Wed, 2008-07-02 at 17:16 -0400, Alan Cox wrote: > >> SELinux should be disablable is the wrong discussion. The discussion you should > >> be having is "I've filed a few bugs where SELinux didn't magically do the right > >> thing, how do we fix them and can we make these less likely to occur in future" > > > > I think the only way to "fix" it for the foreseeable future is to > > simplify policy, so that only a very limited set of services are > > confined. Then, when the graphical tools and user experience have > > eventually caught up, it'll be trivial to switch policy again. > > selinux-policy-targeted is precisely that. Or more precisely, it would like to be that. Abrupt, single line replies like the above amuse me perhaps more than they should, because they carry the implication that I didn't actually consider what is currently implemented in Fedora before sending my original mail ;) Anyway. I've tried to make my point, I'm done now :) Jon. From lordmorgul at gmail.com Thu Jul 3 03:33:24 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 02 Jul 2008 20:33:24 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215048893.6786.4.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <486C2B71.90801@gmail.com> <1215048893.6786.4.camel@perihelion> Message-ID: <486C4884.9020107@gmail.com> Jon Masters wrote: > On Wed, 2008-07-02 at 18:29 -0700, Andrew Farris wrote: >> Jon Masters wrote: >>> On Wed, 2008-07-02 at 17:16 -0400, Alan Cox wrote: >>>> SELinux should be disablable is the wrong discussion. The discussion you should >>>> be having is "I've filed a few bugs where SELinux didn't magically do the right >>>> thing, how do we fix them and can we make these less likely to occur in future" >>> I think the only way to "fix" it for the foreseeable future is to >>> simplify policy, so that only a very limited set of services are >>> confined. Then, when the graphical tools and user experience have >>> eventually caught up, it'll be trivial to switch policy again. >> selinux-policy-targeted is precisely that. > > Or more precisely, it would like to be that. Abrupt, single line replies > like the above amuse me perhaps more than they should, because they > carry the implication that I didn't actually consider what is currently > implemented in Fedora before sending my original mail ;) > > Anyway. I've tried to make my point, I'm done now :) I apologize for the brevity then, but having read your previous mails it seemed quite clear you hadn't looked at what targeted policy is when asking for it. If there are specific situations, or policy bugs, or services you feel shouldn't be confined under targeted policy it might make sense... but asking for a limited set of services when it exists is just about as confounded as you can get. I meant (and still mean) no offense, but if you want more thoughtful comments it would help to be more clear about what you have and haven't already learned about the situation. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From airlied at redhat.com Thu Jul 3 05:36:08 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 03 Jul 2008 15:36:08 +1000 Subject: Request to re-add option to disable SELinux In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <20080702210958.GA27060@devserv.devel.redhat.com> Message-ID: <1215063368.4735.6.camel@optimus> On Thu, 2008-07-03 at 11:29 +1000, James Morris wrote: > On Wed, 2 Jul 2008, Alan Cox wrote: > > > Knowing what it is isn't sufficient - they must know enough to make a meaningful > > risk analysis fo the decision. Very few users I suspect are in that position. > > This is quite a significant problem, as people tend to underestimate > negative risk and overestimate positive risk (according to "Prospect > Theory"). > > And as the odds increase in each direction, people increasingly mis-judge > them. e.g. people believe they'll win the lottery but figure they don't > need a motorcycle helmet. > > Bruce Schneier recently discussed the topic: > http://www.schneier.com/blog/archives/2008/05/how_to_sell_sec.html > > The only way to really make progress in improving security is to make it a > standard part of the computing landscape; for it to be ubiquitous and > generalized, which is the aim of the SELinux project. > > Having a separate "secure" version or option will not work, as proven many > times over with the trusted Unix variants which are essentially forks of > their respective mainline products. > > Avoiding the whole issue will also not work, as DAC security simply cannot > provide adequate protection in a globally networked environment. The > rationale for MAC has been made very clear in an NSA paper, the reading of > which I think is essential for any informed discussion on the issue: > > http://www.nsa.gov/selinux/papers/inevitability/ > > Punting the decision to the end user during installation is possibly the > worst option. It's our responsibility as the developers of the OS to both > get security right and make it usable. It's difficult, indeed, but not > impossible. That's all nice and all, but really SELinux on by default has never worked on a Fedora gold release, there is always some path through some program that didn't get tested, how about you guys try and come up with a way to solve those problems in advance or at least give developers some tools so regressions in SELinux policy can be tracked. Like we have rpmdiff and that other internal rpm thingy for RHEL, perhaps SELinux team could construct a similiar tool that says your new package is going to violate policy where your old package didn't. Relying on users to mail us the contents of some pop-up dialog box is ass. Ask Dr. Watson. Dave. From gemi at bluewin.ch Thu Jul 3 05:46:27 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 03 Jul 2008 07:46:27 +0200 Subject: Koji build failure on ppc64 without visible errors In-Reply-To: <1215035875.17856.36.camel@localhost.localdomain> References: <1215035270.29254.6.camel@localhost.localdomain> <1215035875.17856.36.camel@localhost.localdomain> Message-ID: <1215063987.29254.8.camel@localhost.localdomain> On Wed, 2008-07-02 at 17:57 -0400, Jesse Keating wrote: > DEBUG util.py:250: No Package Found for ffcall Ah, I missed that, thanks. From johannbg at hi.is Thu Jul 3 06:00:58 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 03 Jul 2008 06:00:58 +0000 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <486C6B1A.2080803@hi.is> Jon Masters wrote: > Hi folks, > > ..... > Cheers, > > Jon. > As I see this there are 2 issues to address/improve... First get rid of the false positives. Dan does an exceptional work on fixing selinux reports. The problem here is not that things don't get FIXED they don't get reported. This is something that Fedora-QA and testers community need to step in and improve as in add to task list do a better jobs of testing and filing reports against selinux both rawhide and update testers. wwoods: Ping something to bring up on next meeting. Second simplify the incident report to the desktop user as in noob it down It's very good from an technical level but tells the noobster absolutely nothing he sees it as gibberish and thinks "where am I supposed to now to make this go away". If he's offered an [ Disable ] button he will it. There is absolutely no need to disable selinux when an exception is just what is wanted/needed :) The report should maybe be something more in this direction... $application is trying to do something it should not be doing.. This is what it try to do < Summarize of the incident> [ Allow exception ] [ Show full incident report ]. Just my 2 cents.. Best regards Johann B. From berrange at redhat.com Thu Jul 3 08:16:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 3 Jul 2008 09:16:19 +0100 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <20080703081619.GD312@redhat.com> On Wed, Jul 02, 2008 at 04:10:24PM -0400, Jon Masters wrote: > *). A number of activities are not possible today, with SE Linux enabled > and enforcing on a default F9 installation. I can give examples - > downloading an ISO image and expecting to use it in virt-manager, > creating a virtual machine in a non-standard location, etc. We are aware of those problems and have work in progress to fix them. If you find problems, file bugs about them. Complaining about things not working without filing bugs won't get us anywhere. 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 alan at redhat.com Thu Jul 3 08:29:55 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jul 2008 04:29:55 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215033650.5130.57.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> Message-ID: <20080703082955.GA25619@devserv.devel.redhat.com> On Wed, Jul 02, 2008 at 05:20:50PM -0400, Jon Masters wrote: > I think the only way to "fix" it for the foreseeable future is to > simplify policy, so that only a very limited set of services are > confined. Then, when the graphical tools and user experience have > eventually caught up, it'll be trivial to switch policy again. How will you know you have "fixed" it if you have the bits in question turned off - you won't. You have no meaningful way to make progress. Sorry if I sound fed up of all of this but I spent 9 months fighting people years back to get firewalling enabled by default, and that had all the same arguments. Today nobody (even Microsoft) would propose otherwise. This is the same thing .. As to Setroubleshoot it would be nicer if it spoke more "end user" ese and could prompt/fix common mislabelling (eg html files) From mschwendt at gmail.com Thu Jul 3 08:34:32 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 3 Jul 2008 10:34:32 +0200 Subject: spicebird Provides pollution Message-ID: <20080703103432.7290e736.mschwendt@gmail.com> Spicebird in rawhide provides 46 sonames, which are provided by the following other packages: nss nspr mozldap xulrunner It does so for libs stored outside run-time linker's search path. This leads to weak RPM dependencies. The worst-case scenario would be that one could remove a required package, because RPM believes that spicebird is one of multiple packages which satisfy the requirement. Two examples of how the soname provides are polluted: nss provides libssl3.so(NSS_3.2) spicebird provides libssl3.so(NSS_3.2) required by: adminutil - 1.1.6-1.fc10.i386 required by: evolution - 2.23.4-2.fc10.i386 required by: evolution-data-server - 2.23.4-1.fc10.i386 required by: fedora-ds-admin - 1.1.5-1.fc10.i386 required by: fedora-ds-base - 1.1.1-2.fc10.i386 required by: jss - 4.2.5-2.fc9.i386 required by: libcurl - 7.18.2-2.fc10.i386 required by: libpurple - 2.4.3-1.fc10.1.i386 required by: mailx - 12.3-0.fc10.i386 required by: mod_nss - 1.0.7-5.fc10.i386 required by: mod_revocator - 1.0.2-4.fc9.i386 required by: mozldap - 6.0.5-2.fc9.i386 required by: nss-tools - 3.12.0.3-3.fc10.i386 required by: nss_compat_ossl - 0.9.2-4.fc9.i386 required by: spicebird - 0.4-5.fc8.i386 required by: xulrunner - 1.9-1.fc10.i386 spicebird provides libxpcom.so xulrunner provides libxpcom.so required by: Miro - 1.2.4-2.fc10.i386 required by: blam - 1.8.3-13.fc9.i386 required by: cairo-dock-plug-ins-gecko - 1.6.1-0.1.svn1163_trunk.fc10.i386 required by: devhelp - 0.19.1-1.fc10.i386 required by: evolution-rss - 0.0.8-7.fc9.i386 required by: firefox - 3.0-1.fc10.i386 required by: galeon - 2.0.5-3.fc10.i386 required by: gnome-python2-gtkmozembed - 2.19.1-16.fc9.i386 required by: gnome-web-photo - 0.3-12.fc9.i386 required by: gnomesword - 2.3.4-2.fc10.i386 required by: gtkmozembedmm - 1.4.2.cvs20060817-20.fc9.i386 required by: libswt3-gtk2 - 1:3.3.2-12.fc9.i386 required by: mugshot - 1.2.1-1.fc10.i386 required by: ruby-gtkmozembed - 0.17.0-0.2.rc1.fc10.i386 required by: xulrunner - 1.9-1.fc10.i386 required by: xulrunner-devel - 1.9-1.fc10.i386 required by: yelp - 2.22.1-2.fc10.i386 required by: spicebird - 0.4-5.fc8.i386 And during installation of those packages, it's only the "shortest pkg name wins" in Yum depsolving, which protects us from problems. Plus explicit deps on specific pkg names. From email.ahmedkamal at googlemail.com Thu Jul 3 08:50:59 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 3 Jul 2008 11:50:59 +0300 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080703082955.GA25619@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> Message-ID: <3da3b5b40807030150q54b564c0oacac8b961abbb526@mail.gmail.com> Why don't we have a compromise policy, where interactive users are not restricted except their browsers? System daemons would be restricted of course. Another suggestion, is when something breaks because of selinux, and I get a balloon about it. However, I am unable to modify selinux policy to "correctly" fix that problem. The suggestion is to allow the user a mechanism to launch the affected program in selinux-free mode ( like launch as administrator from the Vista world!). Basically, selinux builds very tight walls around the system, the end user, needs a hammer to break some of these walls to get his work done. If we don't provide the hammer, he'll end up turnning it off completely! On Thu, Jul 3, 2008 at 11:29 AM, Alan Cox wrote: > On Wed, Jul 02, 2008 at 05:20:50PM -0400, Jon Masters wrote: > > I think the only way to "fix" it for the foreseeable future is to > > simplify policy, so that only a very limited set of services are > > confined. Then, when the graphical tools and user experience have > > eventually caught up, it'll be trivial to switch policy again. > > How will you know you have "fixed" it if you have the bits in question > turned off - you won't. You have no meaningful way to make progress. > > Sorry if I sound fed up of all of this but I spent 9 months fighting people > years back to get firewalling enabled by default, and that had all the same > arguments. Today nobody (even Microsoft) would propose otherwise. > > This is the same thing .. > > As to Setroubleshoot it would be nicer if it spoke more "end user" ese and > could prompt/fix common mislabelling (eg html files) > > -- > 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 d.lesca at solinos.it Thu Jul 3 08:55:35 2008 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 03 Jul 2008 10:55:35 +0200 Subject: Kernel 2.6.25 (F8/F9) problem In-Reply-To: <332221.15344.qm@web25903.mail.ukl.yahoo.com> References: <332221.15344.qm@web25903.mail.ukl.yahoo.com> Message-ID: <1215075335.3846.6.camel@lesca.home.solinos.it> Il giorno mer, 02/07/2008 alle 20.56 +0000, Michael ha scritto: > Yesterday I installed Fedora Core 9 on three HP DL380 G5's and noticed stability problems from the first boot. Apparently randomly one machine would boot (fairly) normally, the other would freeze during boot and the third would tail out stacktraces (CPU# frozen for 61secs?!). All three were fresh installs from the same DVD on the same hardware. Rebooting the machines was a russian roulette on which would come back up. I have fill this bug: https://bugzilla.redhat.com/show_bug.cgi?id=453919 Thanks -- Dario Lesca From d.lesca at solinos.it Thu Jul 3 09:01:19 2008 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 03 Jul 2008 11:01:19 +0200 Subject: Kernel 2.6.25 (F8/F9) problem In-Reply-To: <200807021204.54804.jwilson@redhat.com> References: <1214991659.4240.32.camel@lesca.home.solinos.it> <200807021204.54804.jwilson@redhat.com> Message-ID: <1215075679.3846.11.camel@lesca.home.solinos.it> Il giorno mer, 02/07/2008 alle 12.04 -0400, Jarod Wilson ha scritto: > On Wednesday 02 July 2008 05:40:59 am Dario Lesca wrote: > Please file a bug. I have fill this bug: https://bugzilla.redhat.com/show_bug.cgi?id=453919 If you want to connect on this kind of server, I can give you a root ssh account. Thanks -- Dario Lesca From dwmw2 at infradead.org Thu Jul 3 10:02:19 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 03 Jul 2008 11:02:19 +0100 Subject: Koji build failure on ppc64 without visible errors In-Reply-To: <1215063987.29254.8.camel@localhost.localdomain> References: <1215035270.29254.6.camel@localhost.localdomain> <1215035875.17856.36.camel@localhost.localdomain> <1215063987.29254.8.camel@localhost.localdomain> Message-ID: <1215079339.10393.506.camel@pmac.infradead.org> On Thu, 2008-07-03 at 07:46 +0200, G?rard Milmeister wrote: > On Wed, 2008-07-02 at 17:57 -0400, Jesse Keating wrote: > > DEBUG util.py:250: No Package Found for ffcall > > Ah, I missed that, thanks. I don't see that on https://bugzilla.redhat.com/showdependencytree.cgi?id=FE-ExcludeArch-ppc64 -- dwmw2 From rawhide at fedoraproject.org Thu Jul 3 10:34:31 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 3 Jul 2008 10:34:31 +0000 (UTC) Subject: rawhide report: 20080703 changes Message-ID: <20080703103431.41F4C209D82@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080702/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080703/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package abgraph ABGraph is a simple tool to benchmark webservers New package freehoo Freehoo is a free console based messenger for Yahoo IM Service New package perl-Lingua-Preferred Perl extension to choose a language New package quassel QT4 Based distrubuted IRC system Updated Packages: NetworkManager-0.7.0-0.10.svn3801.fc10 -------------------------------------- * Wed Jul 2 18:00:00 2008 Dan Williams - 1:0.7.0-0.10.svn3801 - Move VPN configuration into connection editor - Fix mobile broadband username/password issues - Fix issues with broken rfkill setups (rh #448889) - Honor APN setting for GSM mobile broadband configurations - Fix adding CDMA connections in the connection editor NetworkManager-openvpn-0.7.0-11.svn3801.fc10 -------------------------------------------- * Wed Jul 2 18:00:00 2008 Dan Williams 1:0.7.0-11.svn3801 - Update for moving VPN editing into connection manager - Import OpenVPN configuration files rather than old custom format NetworkManager-vpnc-0.7.0-0.10.svn3801.fc10 ------------------------------------------- * Wed Jul 2 18:00:00 2008 Dan Williams 1:0.7.0-10.svn3801 - Update for moving VPN editing into connection manager - Add option to disable Dead Peer Detection - Add option to select NAT Traversal mode WindowMaker-0.92.0-18.fc9 ------------------------- * Wed Jul 2 18:00:00 2008 Petr Machata - 0.92.0-18 - Bump up for rebuild. - Resolves: #448360 alienarena-7.10-1.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 Tom "spot" Callaway - 7.10-1 - update to 7.10 (2008) alienarena-data-20080603-1.fc10 ------------------------------- * Wed Jul 2 18:00:00 2008 Tom "spot" Callaway 20080603-1 - update to 2008 data apr-util-1.3.2-4.fc10 --------------------- * Wed Jul 2 18:00:00 2008 Bojan Smojver - 1.3.2-4 - properly fix PostgreSQL detection * Wed Jul 2 18:00:00 2008 Bojan Smojver - 1.3.2-3 - revert build dependencies, change from -2 didn't help - add apr-util-1.3.2-pgsql.patch (remove pgsql_LIBS during detection) * Wed Jul 2 18:00:00 2008 Bojan Smojver - 1.3.2-2 - try adding postgresql-server to build dependencies to pull some libs in * Thu Jun 19 18:00:00 2008 Bojan Smojver - 1.3.2-1 - bump up to 1.3.2 * Sun Jun 1 18:00:00 2008 Bojan Smojver - 1.3.0-1 - bump up to 1.3.0 asterisk-1.6.0-0.17.beta9.fc10 ------------------------------ * Wed Jul 2 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.17.beta9 - Add patch that unbreaks cdr_tds with FreeTDS 0.82. - Properly obsolete conference subpackage. autofs-5.0.3-18 --------------- * Mon Jun 30 18:00:00 2008 Ian Kent - 5.0.3-18 - don't abuse the ap->ghost field on NFS mount. - multi-map doesn't pickup NIS updates automatically. - eliminate redundant DNS name lookups. - mount thread create condition handling fix. - allow directory create on NFS root. - check direct mount path length. - fix incorrect in check in get user info. - fix a couple of memory leaks. cairo-dock-1.6.1-0.1.svn1167_trunk.fc10 --------------------------------------- * Thu Jul 3 18:00:00 2008 Mamoru Tasaka - rev. 1167 chess-1.0-16.fc10 ----------------- * Wed Jul 2 18:00:00 2008 Hans de Goede 1.0-16 - Rebuild for new ogre dotconf-1.0.13-7.fc10 --------------------- * Thu Jul 3 18:00:00 2008 Mamoru Tasaka - 1.0.13-7 - Override config.{sub,guess} explicitly due to redhat-rpm-build-config behavior change on F-10+, otherwise build fails on ppc64 elinks-0.12-0.1.pre1.fc10 ------------------------- * Tue Jul 1 18:00:00 2008 Ondrej Vasik 0.12-0.1.pre1 - unstable elinks-0.12 pre1, solves several long-term issues unsolvable (or very hard to solve) in 0.11.4 (like #173411), in general is elinks-0.12pre1 considered better than 0.11.4 - dropped patches negotiate-auth, chunkedgzip - included in 0.12pre1, modified few others due source code changes evolution-rss-0.1.0-1.fc10 -------------------------- * Wed Jul 2 18:00:00 2008 Lucian Langa - 0.1.0-1 - New upstream fedora-package-config-smart-9.89-14 ----------------------------------- freenx-server-0.7.2-8.0.1.fc10 ------------------------------ func-0.21-1.fc10 ---------------- * Wed Jul 2 18:00:00 2008 Michael DeHaan - 0.21-1 - new release, upstream changes * Mon Jun 30 18:00:00 2008 Michael DeHaan - 0.20-1 - new release, upstream changes geoclue-0.11.1-6.fc10 --------------------- * Wed Jul 2 18:00:00 2008 Peter Robinson 0.11.1-6 - Fixed spec file so gpsd and gypsy are actually properly in a subpackage gnomesword-2.3.5-1.fc10 ----------------------- * Thu Jul 3 18:00:00 2008 Deji Akingunola - 2.3.5-1 - Update to 2.3.5 hunspell-ca-0.20080620-1.fc10 ----------------------------- * Wed Jul 2 18:00:00 2008 Caolan McNamara - 0.20080620-1 - latest version * Fri Aug 3 18:00:00 2007 Caolan McNamara - 0.20060508-2 - clarify license version hunspell-fr-2.3.2-1.fc10 ------------------------ * Wed Jul 2 18:00:00 2008 Caolan McNamara - 2.3.2-1 - latest version iprutils-2.2.8-6.fc10 --------------------- * Wed Jul 2 18:00:00 2008 Roman Rakus - 2.2.8-6 - Fixed ExclusiveArch tag * Wed Jul 2 18:00:00 2008 Roman Rakus - 2.2.8-5 - Fixed chkconfig issue - #453165 iso-codes-3.1-1.fc10 -------------------- * Wed Jul 2 18:00:00 2008 Christopher Aillon - 3.1-1 - Update to 3.1 jd-2.0.0-0.7.beta080702.fc10 ---------------------------- * Thu Jul 3 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.7.beta20080702 - 2.0.0 beta 20080702 kdelibs3-3.5.9-16.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 Kevin Kofler 3.5.9-16 - f9+: use drkonqi from KDE 4 kdebase-runtime in KCrash (#453243) kernel-2.6.26-0.104.rc8.git2.fc10 --------------------------------- * Tue Jul 1 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-06-30 (http://marc.info/?l=linux-wireless&m=121485709702728&w=2) - Upstream wireless updates from 2008-06-30 (http://marc.info/?l=linux-wireless&m=121486432315033&w=2) * Tue Jul 1 18:00:00 2008 Dave Jones - Shorten summary in specfile. * Tue Jul 1 18:00:00 2008 Dave Jones - 2.6.26-rc8-git2 ldm-2.0.7-1.fc9 --------------- * Tue Jul 1 18:00:00 2008 Warren Togami - 2.0.7-1 - 2.0.7 adds keyboard layout setting within ldm libmatthew-java-0.7.1-2.fc10 ---------------------------- * Wed Jul 2 18:00:00 2008 Omair Majid 0.7.1-2 - Fixed hardcoded paths for jni libraries licq-1.3.5-3.fc10 ----------------- * Wed Jul 2 18:00:00 2008 Jiri Moskovcak 1.3.5-3 - fixed problem with logon to icq server - Resolves: #453682 liferea-1.4.16b-5.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 Steven Parrish - 1.4.16b-5 - corrected multiple segfaults. Fixes Bug #453233 * Fri Jun 27 18:00:00 2008 Steven Parrish - 1.4.16b-43 - Cleaned up spec file and removed support for firefox-devel * Fri Jun 27 18:00:00 2008 Steven Parrish - 1.4.16b-4 - removed uneeded patch files linuxdcpp-1.0.1-3.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 Marcin Garski 1.0.1-3 - Fix for CVE-2008-2953 and CVE-2008-2954 (#453731) logjam-4.5.3-24.fc10 -------------------- * Tue Jul 1 18:00:00 2008 Tom "spot" Callaway - 4.5.3-24 - fix ukranian translation (bz 447145) - fix docked behavior (bz 447146) - add close when send option (bz 447147) - fix image resize sigsegv (bz 452170) lxsplit-0.2.3-1.fc10 -------------------- * Thu Jul 3 18:00:00 2008 Rahul Sundaram - 0.2.3-1 Pull new upstream. Drop obsoleted patch and fix defattr m17n-lib-1.5.2-1.fc10 --------------------- * Thu Jul 3 18:00:00 2008 Parag Nemade -1.5.2-1 - Update to new upstream release 1.5.2 mesa-7.1-0.37.fc10 ------------------ * Fri Jun 27 18:00:00 2008 Adam Jackson 7.1-0.37 - Drop mesa-source subpackage. Man that feels good. * Fri Jun 27 18:00:00 2008 Adam Jackson 7.1-0.36 - Today's snapshot. - Package swrast_dri for the new X world order. - Split DRI drivers to their own subpackage. mod_nss-1.0.7-6.fc10 -------------------- * Wed Jul 2 18:00:00 2008 Rob Crittenden - 1.0.7-6 - Update the patch for FIPS to include fixes for nss_pcache, enforce the security policy and properly initialize the FIPS token. mod_wsgi-2.1-1.fc10 ------------------- * Wed Jul 2 18:00:00 2008 James Bowes 2.1-1 - Update to 2.1 mtd-utils-1.2.0-1.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 David Woodhouse - 1.2.0-1 - Update to 1.2.0 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.1.0-3 - Autorebuild for GCC 4.3 multiget-1.2.0-3.fc10 --------------------- * Thu Jun 12 18:00:00 2008 Guido Ledermann - 1.2.0-3 - remove patch for Makefile.in, fixed spec to follow Packaging Guidelines * Thu Jun 12 18:00:00 2008 Guido Ledermann - 1.2.0-2 - remove patch for Makefile and added patch for Makefile.ini, fixed spec * Thu Jun 5 18:00:00 2008 Guido Ledermann - 1.2.0-1 - Fixed for 1.2.0 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.1.4-8 - Autorebuild for GCC 4.3 ogre-1.4.9-1.fc10 ----------------- * Wed Jul 2 18:00:00 2008 Hans de Goede 1.4.9-1 - New upstream release 1.4.9 openldap-2.4.10-2.fc10 ---------------------- * Wed Jul 2 18:00:00 2008 Jan Safranek 2.4.10-2 - fix CVE-2008-2952 (#453728) patchutils-0.3.0-1.fc10 ----------------------- * Wed Jul 2 18:00:00 2008 Tim Waugh 0.3.0-1 - 0.3.0. perl-5.10.0-33.fc10 ------------------- * Tue Jul 1 18:00:00 2008 Marcela Maslanova 4:5.10.0-33 - 451078 update Test::Harness to 3.12 for more testing. Removed verbose test, new Test::Harness has possibly verbose output, but updated package has a lot of features f.e. TAP::Harness. Carefully watched all new bugs related to tests! perl-CPAN-DistnameInfo-0.07-1.fc10 ---------------------------------- * Wed Jul 2 18:00:00 2008 Steven Pritchard 0.07-1 - Update to 0.07. - Improve Summary. - Drop our copies of COPYING and Artistic. perl-Test-WWW-Mechanize-Catalyst-0.42-1.fc10 -------------------------------------------- * Tue Jul 1 18:00:00 2008 Chris Weyl 0.42-1 - update to 0.42 pl-5.6.57-2.fc10 ---------------- * Wed Jul 2 18:00:00 2008 Mary Ellen Foster - 5.6.57-2 - Build using any Java - Include patch from SWI for Turkish locale (thanks to Keri Harris) policycoreutils-2.0.52-1.fc10 ----------------------------- * Wed Jul 2 18:00:00 2008 Dan Walsh 2.0.52-1 - Default prefix to "user" pygoocanvas-0.10.0-2.fc10 ------------------------- * Wed Jul 2 18:00:00 2008 Bernard Johnson - 0.10.0-2 - package package config file (.pc) into package (don't want separate devel) * Sun Jun 29 18:00:00 2008 Bernard Johnson - 0.10.0-1 - v 0.10.0 qt3-3.3.8b-13.fc9 ----------------- * Fri May 23 18:00:00 2008 Than Ngo - 3.3.8b-13 - fix rh#448027, qt3's PATH not set properly unless qt3-devel is installed rpcbind-0.1.5-5.fc10 -------------------- * Wed Jul 2 18:00:00 2008 Steve Dickson 0.1.5-5 - Fixed SYNOPSIS section in the rpcinfo man page (bz 453729) sblim-cmpi-base-1.5.5-2.fc10 ---------------------------- * Wed Jul 2 18:00:00 2008 Vitezslav Crhonek - 1.5.5-2 - Fix testsuite dependency schroedinger-1.0.3-2.fc10 ------------------------- * Wed Jul 2 18:00:00 2008 Jeffrey C. Ollie - 1.0.3-2 - Devel subpackage needs to require liboil-devel. selinux-policy-3.4.2-10.fc10 ---------------------------- * Wed Jul 2 18:00:00 2008 Dan Walsh 3.4.2-10 - Allow all system domains and application domains to append to any log file * Sun Jun 29 18:00:00 2008 Dan Walsh 3.4.2-9 - Allow gdm to read rpm database - Allow nsplugin to read mplayer config files snort-2.8.1-5.fc10 ------------------ squid-3.0.STABLE7-1.fc10 ------------------------ * Wed Jul 2 18:00:00 2008 Jiri Skala - 7:3.0.STABLE7-1 - update to latest upstream - fix #453214 subversion-1.5.0-6 ------------------ * Wed Jul 2 18:00:00 2008 Joe Orton 1.5.0-6 - build with OpenJDK * Wed Jul 2 18:00:00 2008 Joe Orton 1.5.0-5 - fix files list * Wed Jul 2 18:00:00 2008 Joe Orton 1.5.0-4 - swig-perl test suite fix for Perl 5.10 (upstream r31546) * Tue Jul 1 18:00:00 2008 Joe Orton 1.5.0-3 - attempt build without java bits * Thu Jun 26 18:00:00 2008 Joe Orton 1.5.0-2 - update to 1.5.0 sysusage-2.6-4.fc10 ------------------- * Wed Jul 2 18:00:00 2008 Rob Myers 0:2.6-4 - include missing versioned MODULE_COMPAT Requires (#453586) tcl-8.5.2-3.fc10 ---------------- * Wed Jul 2 18:00:00 2008 Marcela Maslanova - 1:8.5.2-3 - tclConfig.sh was fixed again with symlink into libdir/tcl8.5. Many packages are looking in /usr/lib, because tcl dir is versioned. vegastrike-0.5.0-3.fc10 ----------------------- * Wed Jul 2 18:00:00 2008 Hans de Goede 0.5.0-3 - Rebuild for new ogre vnc-4.1.2-32.fc10 ----------------- * Tue Jul 1 18:00:00 2008 Adam Tkac 4.1.2-32 - enabled XKEYBOARD extension (#450033) - icons have correct permissions (#453495) * Mon Jun 2 18:00:00 2008 Adam Tkac 4.1.2-31.1 - minor cleanup in IPv6 patch xenner-0.38-1.fc10 ------------------ * Wed Jul 2 18:00:00 2008 Gerd Hoffmann - 0.38-1.fc10 - update to version 0.38 xfce4-datetime-plugin-0.6.0-1.fc10 ---------------------------------- * Thu Jul 3 18:00:00 2008 Christoph Wickert - 0.6.0-1 - Update to 0.6.0 - BuildRequire intltool - No longer BuildRequire dbus-devel (requirement dropped upstream) xfce4-screenshooter-plugin-1.2.0-1.fc10 --------------------------------------- * Thu Jul 3 18:00:00 2008 Christoph Wickert - 1.2.0-1 - Update to 1.2.0 - Include new xfce4-screenshooter manpage * Sun Jun 22 18:00:00 2008 Christoph Wickert - 1.1.0-1 - Update to 1.1.0 - BR gettext xorg-x11-server-1.4.99.905-2.20080701.fc10 ------------------------------------------ * Wed Jul 2 18:00:00 2008 Adam Tkac 1.4.99.905-2.20080701 - build with -rdynamic to make dri_swrast happy * Mon Jun 30 18:00:00 2008 Adam Jackson 1.4.99.905-1.20080701 - 1.5RC5. Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 64 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.i386 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-8.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-8.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-8.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- alienarena-data-20080603-1.fc10.noarch requires libc.so.6 alienarena-data-20080603-1.fc10.noarch requires libc.so.6(GLIBC_2.1) alienarena-data-20080603-1.fc10.noarch requires libc.so.6(GLIBC_2.1.3) alienarena-data-20080603-1.fc10.noarch requires libc.so.6(GLIBC_2.0) alienarena-data-20080603-1.fc10.noarch requires libc.so.6(GLIBC_2.3) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-8.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From foss.mailinglists at gmail.com Thu Jul 3 10:47:28 2008 From: foss.mailinglists at gmail.com (=?UTF-8?B?IlNhbmthcnNoYW4gKOCmuOCmmeCnjeCmleCmsOCnjeCmt+Cmoyki?=) Date: Thu, 03 Jul 2008 16:17:28 +0530 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215033267.5130.49.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <1215033267.5130.49.camel@perihelion> Message-ID: <486CAE40.2030801@gmail.com> Jon Masters wrote: > Ok then let me just say it. I think the default should be permissive or > disabled by default. I was hoping to not have to say that - but I think > it's a lot safer on the mass userbase of Fedora than thrusting a fully > enforcing SELinux policy set upon them. If I'm having to hack on the > policy files on my laptop, there's no hope for a desktop user. One can argue that the path to an objective where everything just works with SELinux 'on' begins by forcing the bitter syrup down the throats. To extend your reasoning, if it were disabled by default, how would one move towards just works ? -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work From sundaram at fedoraproject.org Thu Jul 3 11:37:56 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 Jul 2008 17:07:56 +0530 Subject: Easy reviews? Message-ID: <486CBA14.7060202@fedoraproject.org> Hi, I am trying to gather a list of packages that are easy to review on the long review queue since there are people interested in getting started on this. Any pointers? Rahul From rdieter at math.unl.edu Thu Jul 3 11:47:19 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Jul 2008 06:47:19 -0500 Subject: spicebird Provides pollution References: <20080703103432.7290e736.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: > spicebird Provides pollution Thanks Michael, https://bugzilla.redhat.com/show_bug.cgi?id=453936 -- Rex From kwizart at gmail.com Thu Jul 3 12:11:24 2008 From: kwizart at gmail.com (KH KH) Date: Thu, 3 Jul 2008 14:11:24 +0200 Subject: spicebird Provides pollution In-Reply-To: References: <20080703103432.7290e736.mschwendt@gmail.com> Message-ID: 2008/7/3 Rex Dieter : > Michael Schwendt wrote: > >> spicebird Provides pollution > > Thanks Michael, > https://bugzilla.redhat.com/show_bug.cgi?id=453936 > The conflicting soname as sense, since spicebird built it's own internal xulrunner. Shoudn't we prevent that ? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From prarit at redhat.com Thu Jul 3 13:13:42 2008 From: prarit at redhat.com (Prarit Bhargava) Date: Thu, 03 Jul 2008 09:13:42 -0400 Subject: Fedora 9 ia64 now available Message-ID: <486CD086.1050503@redhat.com> = Release notes for F9-beta on ia64 = == Welcome == Welcome to the F9 beta Fedora for ia64. F9 is the first Fedora release to be officially supported on ia64. This ia64 build of fedora is the first to be released under the "secondary architectures" project. We have made efforts to make sure that the ia64 release is equal to the release of Fedora for x86, x86_64, ppc and ppc64, however there are some differences that should be noted. General information on the Fedora-ia64 project can be found at: http://fedoraproject.org/wiki/Architectures/IA64 For more information about the secondary architectures project for Fedora see: http://fedoraproject.org/wiki/Architectures == Download location == The beta can be downloaded from: http://download.fedoraproject.org/pub/fedora-secondary/releases/9/ This will redirect you to one of the available mirrors for this content. However, at this point there is only 1 public mirror. We encourage anyone who managers a public mirror site to mirror the secondary arch Fedora bits. Info on how to become a Fedora mirror can be found at: http://fedoraproject.org/wiki/Infrastructure/Mirroring See the section with special information on secondary arch mirroring. The mirroring system also allows for setting up a private mirror only visible to clients connecting from a specific range of ip addresses (useful for users inside of large corporations). == SRPM location == Since the ia64 release was not done in sync with the other architectures it does not contain identical versions on all packages. Since the fedora MirrorManager assumes that SRPMs are identical for all arches downloading sources using yumdownloader will sometimes get a different version of the sources than was built for ia64. The entire tree containing binaries and the exact sources used for this release are kept together in the tree. == Bug reporting == Open source software survives on defect reports from end users. We would appreciate bugs reports if you find problems. Bugs should be filed at: http://bugzilla.redhat.com/ Use the component "Fedora" and the version "9" when you file a bug aginst this beta release. Please add fedora-ia64-committee at redhat.com to the CC list so we can investigate if it is specific to our ia64 build. Also, please include the full version of the package that contains the bug (such as anaconda-11.4.0.75-1 or kernel-2.6.25-1.fc9) since the versions in the ia64 beta often do not match the version that was shipped with the beta for other arches. == No live image == We do not yet have live DVD images for ia64. We hope to have this for Fedora 10. == Known issues and workarounds == There are some known issues with this release. An updated list along with workarounds can be found at: http://fedoraproject.org/wiki/Architectures/IA64/Workarounds Known issues at the time of this writing are: === /boot/efi must be "efi" type not "vfat" === Manually partitioning fails if /boot/efi is selected as "vfat" filesystem type. The workaround is to select "efi" from the list of filesystem types. This issue is also seen when trying to reuse an existing /boot/efi partition. When re-using an existing /boot/efi partition the installation will fail unless you specify to reformat it. === HP Smart Array boot failures === Occasional boot failures on HP Smart Array (aka "cciss") devices. This is still under investigation and it is unclear what the root cause is. Users who have seen this report good results by booting with selinux disabled (selinux=0). === Anaconda crash on HP Smart Array with no disks === When installing on a system that has an HP Smart Array card that has no disks configured, anaconda will crash. The workaround is to: * Step 1: When you get the warning "Unable to determine geometry ..." choose "Ignore". * Step 2: When you are asked "The partition table on device cciss/c1d0 was unreadable .... Would you like to initialize this drive, erasing ALL DATA?" choose "No" From bruno at wolff.to Thu Jul 3 13:16:24 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 3 Jul 2008 08:16:24 -0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <3da3b5b40807030150q54b564c0oacac8b961abbb526@mail.gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> <3da3b5b40807030150q54b564c0oacac8b961abbb526@mail.gmail.com> Message-ID: <20080703131624.GA32034@wolff.to> On Thu, Jul 03, 2008 at 11:50:59 +0300, Ahmed Kamal wrote: > Another suggestion, is when something breaks because of selinux, and I get a > balloon about it. However, I am unable to modify selinux policy to > "correctly" fix that problem. The suggestion is to allow the user a audit2allow can be used to let the program run. As far as "correctly" fixing things, that isn't going to be automated. In a lot of cases its the program that is broken, not the policy. Someone needs to look at what is happening and figure out what the real problem is. From txtoth at gmail.com Thu Jul 3 13:19:31 2008 From: txtoth at gmail.com (Ted X Toth) Date: Thu, 03 Jul 2008 08:19:31 -0500 Subject: SLiM problem Message-ID: <486CD1E3.8010804@gmail.com> I've installed slim and edited /etc/sysconfig/desktop to specify slim-dynwm but on boot I don't get a slim login screen. I've looked at the slim log and there is a complaint about not being able to load the default theme and also if I ssh in I don't see an X server running. Any idea what's going wrong? Ted From jmorris at namei.org Thu Jul 3 13:34:39 2008 From: jmorris at namei.org (James Morris) Date: Thu, 3 Jul 2008 23:34:39 +1000 (EST) Subject: Request to re-add option to disable SELinux In-Reply-To: <20080703082955.GA25619@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> Message-ID: On Thu, 3 Jul 2008, Alan Cox wrote: > As to Setroubleshoot it would be nicer if it spoke more "end user" ese and > could prompt/fix common mislabelling (eg html files) The good thing about setroubleshoot is that it has a plugin architecture, so people can write better/more plugins. What's lacking are obvious documents explaining how to do it, alas. - James -- James Morris From mschwendt at gmail.com Thu Jul 3 13:48:24 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 3 Jul 2008 15:48:24 +0200 Subject: Fedora 9 ia64 now available In-Reply-To: <486CD086.1050503@redhat.com> References: <486CD086.1050503@redhat.com> Message-ID: <20080703154824.047ecc67.mschwendt@gmail.com> On Thu, 03 Jul 2008 09:13:42 -0400, Prarit Bhargava wrote: > Since the ia64 release was not done in sync with the other > architectures Why not? Where you differ from stock Fedora 9, did you do anything to get your changes/patches be applied on F-9 and devel branches in cvs? Is the ia64 Everything repo complete compared with the other arches? From jmorris at namei.org Thu Jul 3 13:53:16 2008 From: jmorris at namei.org (James Morris) Date: Thu, 3 Jul 2008 23:53:16 +1000 (EST) Subject: Request to re-add option to disable SELinux In-Reply-To: <1215063368.4735.6.camel@optimus> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <20080702210958.GA27060@devserv.devel.redhat.com> <1215063368.4735.6.camel@optimus> Message-ID: On Thu, 3 Jul 2008, Dave Airlie wrote: > That's all nice and all, but really SELinux on by default has never > worked on a Fedora gold release, there is always some path through some > program that didn't get tested, how about you guys try and come up with > a way to solve those problems in advance or at least give developers > some tools so regressions in SELinux policy can be tracked. > > Like we have rpmdiff and that other internal rpm thingy for RHEL, > perhaps SELinux team could construct a similiar tool that says your new > package is going to violate policy where your old package didn't. I'm not sure that's feasible -- if it were that simple, the policy would write itself. Possibly something can be done, but it won't make up for lack of testing. I know of several major packages which cannot possibly have been tested with SELinux before being shipped. Even if all people do is enable SELinux for ten minutes at some stage prior to release, and file the audit logs into a bz, that would probably fix most of these issues. Perhaps we should be thinking in terms of establishing the practice of developers doing all development with SELinux enabled and in enforcing mode, providing tools to support that. e.g. implement a wrapper for automated policy module generation for devel use only, and the developer submits the generated module to the SELinux team at some point, like during an alpha release, and an "official" policy module is developed from that and committed to rawhide. i.e. incorporate SELinux policy development into the overall development process with the package developers involved from the start and getting assistance from the SELinux folk. - James -- James Morris From tibbs at math.uh.edu Thu Jul 3 15:24:17 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2008 10:24:17 -0500 Subject: Easy reviews? In-Reply-To: <486CBA14.7060202@fedoraproject.org> References: <486CBA14.7060202@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Hi, I am trying to gather a list of packages that are easy to RS> review on the long review queue since there are people interested RS> in getting started on this. Any pointers? I wasn't aware that there were others interested in this; I don't recall seeing much activity lately in that area either on-list or on IRC. In any case, I fear we've mostly scoured the list of really easy things; perl modules tend to be very simple since most of them are mechanically generated; python modules are almost as easy. But they tend to get taken care of pretty quickly, so folks should search down at the end of the list: http://fedoraproject.org/PackageReviewStatus/NEW.html Honestly if people want to get started with reviews, the easiest thing for them to do is to ignore the merge reviews and do some basic triage on the rest. Verify that the submitted package links are still good, very that the packages build in mock or koji, provide rpmlint output and perhaps some pointers on what needs to be fixed (which isn't always easy to understand; people are welcome to ask me about particularly confusing rpmlint complaints, and we can try to get them documented). This will help to weed out those tickets where the submitter has gone away, and can pave the way for a more experienced reviewer to come in and do a complete check. Note also that it's not at all required that anyone be sponsored in order to do this. - J< From mike at miketc.com Thu Jul 3 15:42:05 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 03 Jul 2008 10:42:05 -0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080703082955.GA25619@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> Message-ID: <1215099725.8001.17.camel@scrappy.miketc.com> On Thu, 2008-07-03 at 04:29 -0400, Alan Cox wrote: > Sorry if I sound fed up of all of this but I spent 9 months fighting people > years back to get firewalling enabled by default, and that had all the same > arguments. Today nobody (even Microsoft) would propose otherwise. > > This is the same thing .. > > As to Setroubleshoot it would be nicer if it spoke more "end user" ese and > could prompt/fix common mislabelling (eg html files) I agree with Alan here, that if selinux is indeed a great program to help secure the OS and anything else, it at least needs to be a LOT more user friendly. Ok, don't give me this MS to linux compare bit on what I am comparing next, it's the comparing of wording and concept it's done in, not details and stuff LOL. Anyway, Vista came out with that (I forget the damn program name) program that when certain programs/files run, you get a dialog box that you have to continue (to allow it to run) or cancel. Now, no this isn't exactly the same, but it is in a way. They both provide a little better security than with out it. BUT, in Vista, the user doesn't have to relabel something, or go to the CLI, or whatever. They get a little question stating this program wants to run, do you give it permission. That's it, nothing else (might not like that dialog all the time though, I am sure). And that is what I am trying to say for selinux, that it needs to allow things to do what they need, and if not, a simple little question or whatever to allow it. The user should NOT have to go to the CLI for anything. They shouldn't have to do this command or that command, JUST HIT YES OR NO!! Well anyway, not ranting or raving. Just trying to maybe help clarify what Jon was talking about, and what Alan was saying. SELinux I am sure is a wonderful thing, and just needs to be I guess, dumbed down or whatever so the user clearly understands what it is doing or not doing and to present the user with simple to do questions/answers/buttons or whatever to push/answer. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From doug.chapman at hp.com Thu Jul 3 15:58:18 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 03 Jul 2008 11:58:18 -0400 Subject: Fedora 9 ia64 now available In-Reply-To: <20080703154824.047ecc67.mschwendt@gmail.com> References: <486CD086.1050503@redhat.com> <20080703154824.047ecc67.mschwendt@gmail.com> Message-ID: <1215100698.3227.22.camel@oberon> On Thu, 2008-07-03 at 15:48 +0200, Michael Schwendt wrote: > On Thu, 03 Jul 2008 09:13:42 -0400, Prarit Bhargava wrote: > > > Since the ia64 release was not done in sync with the other > > architectures > > Why not? This is the first "secondary arch" release to be available and we are still working out how to do things. I expect by F10 we should be releasing within a day and hopefully with all identical package versions as the primary arches. > > Where you differ from stock Fedora 9, did you do anything to get your > changes/patches be applied on F-9 and devel branches in cvs? All changes we needed for ia64 are in Fedora CVS so there are no special ia64 patches floating around for ia64. > > Is the ia64 Everything repo complete compared with the other arches? Not quite, I think we have about 98% of the packages building on ia64. Back at F8 I think we had about 80% or so. Also F8 was built completely from SRPMs outside of koji with hacked up scripts. We now build under koji/CVS just as the primary arches except for ours is a separate koji server. There has been major progress over the past 6 months. - Doug From doug.chapman at hp.com Thu Jul 3 15:58:12 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 03 Jul 2008 11:58:12 -0400 Subject: Fedora 9 ia64 now available In-Reply-To: <486CD086.1050503@redhat.com> References: <486CD086.1050503@redhat.com> Message-ID: <1215100692.3227.20.camel@oberon> On Thu, 2008-07-03 at 09:13 -0400, Prarit Bhargava wrote: > = Release notes for F9-beta on ia64 = ^^^^ the "beta" was accidentally left in from the beta release notes. This is the final GA version of F9 for ia64. - Doug From smooge at gmail.com Thu Jul 3 16:14:01 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 3 Jul 2008 10:14:01 -0600 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080703082955.GA25619@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> Message-ID: <80d7e4090807030914j3535e6ecsb2f87ea82cb67dd0@mail.gmail.com> On Thu, Jul 3, 2008 at 2:29 AM, Alan Cox wrote: > On Wed, Jul 02, 2008 at 05:20:50PM -0400, Jon Masters wrote: >> I think the only way to "fix" it for the foreseeable future is to >> simplify policy, so that only a very limited set of services are >> confined. Then, when the graphical tools and user experience have >> eventually caught up, it'll be trivial to switch policy again. > > How will you know you have "fixed" it if you have the bits in question > turned off - you won't. You have no meaningful way to make progress. > > Sorry if I sound fed up of all of this but I spent 9 months fighting people > years back to get firewalling enabled by default, and that had all the same > arguments. Today nobody (even Microsoft) would propose otherwise. > Alan probably also remembers the same arguments being used for DAC security (I remember them from gnu.* and comp.unix*) from long ago. 15+ years ago there were lots of systems that had the root password in the motd because well DAC got in the way of getting stuff done that was normally done and you might as well have the root password if you wanted to 'fix' it. Several of these systems usually also had a short hand script that would setuid the program you wanted and setuid it back to the old permissions after you ran it. They also usually also had files with all the social security numbers, etc of every student etc.. The number of desktops and servers where I find firewalls turned off at install is still staggering. Most of them are the ones where they ran into some problem, googled and saw turn it off as the answer and did so. The number of desktops where the person runs everything as root is also amazing.. and boy do they now get ticked at that "You are running things at root" message. In the end, I don't see a fix.. people want things like their car. Turn the key, go, in the same way every car they ever liked driving has been. They hate it when they find the car has a governor to keep it from going 150+, ABS to change braking behaviour, airbags, front-wheel versus rear-wheel, transmission gearing changes, etc etc. They really don't care one-whit if any of those changes make them safer because they can't perceive it (and if any of those safety devices go 'wrong' are more adamant that it was a wrong idea in the first place, etc etc.) > This is the same thing .. > > As to Setroubleshoot it would be nicer if it spoke more "end user" ese and > could prompt/fix common mislabelling (eg html files) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From cdahlin at redhat.com Thu Jul 3 16:52:06 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 03 Jul 2008 12:52:06 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <486D03B6.9040202@redhat.com> Jon Masters wrote: > Hi folks, > > I'd like to see the re-introduction of an option during (or shortly > after, i.e. during firstboot) installation to disable SELinux, or set it > to be permissive. My reason for making this request includes: > > *). A number of activities are not possible today, with SE Linux enabled > and enforcing on a default F9 installation. I can give examples - > downloading an ISO image and expecting to use it in virt-manager, > creating a virtual machine in a non-standard location, etc. > > Well we should fix these issues then, shouldn't we? > *). Policy changes will randomly stop things from working that used to > work. Especially on the Desktop, where many possible code paths (SE > Linux works by denying until an exception is found and added to the > policy...requiring all code paths to be exercised) exist to do > something. I found this last week when VPNC randomly broke. > > Yes. This is very true. By the same token, we should stop shipping the kernel as well since config changes can break things. Or we could just do our job and release better updates. > *). Tools like nautilus do not support labeling of files via the > right-click properties dialog (gnome VFS, etc.) so there is no easy way > for an end user who even understands part of this to fix context. This > is the number one reason why SELinux should not be enabled by default, > except on systems where there is an admin who can use chcon. > > Nautilus is deficient in many ways for administration. We can fix all of them. Personally I think the first thing to fix in nautilus is the "Permission denied" errors when operating as an unprivileged user and trying to access files to which you don't have permission. We should be offering to elevate the user through policy kit in these situations. > But there are numerous other justifications I could give, including my > personal belief that it's absolutely nuts to thrust SE Linux upon > unsuspecting Desktop users (who don't know what it is anyway) without > giving them the choice to turn it off. > > These unsuspecting desktop users who don't know what SELinux is will then be able to turn it off and freely run virtual machines to continue their clustering simulations and live migration tests. I have enough civility in me to carry out any discourse politely...once. This is about the 950th "SELinux ate my baby, let's turn it off" thread. What's supposed to be different THIS time? --CJD From cdahlin at redhat.com Thu Jul 3 16:55:20 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 03 Jul 2008 12:55:20 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <486CAE40.2030801@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <1215033267.5130.49.camel@perihelion> <486CAE40.2030801@gmail.com> Message-ID: <486D0478.6040109@redhat.com> Sankarshan (????????) wrote: > Jon Masters wrote: > >> Ok then let me just say it. I think the default should be permissive or >> disabled by default. I was hoping to not have to say that - but I think >> it's a lot safer on the mass userbase of Fedora than thrusting a fully >> enforcing SELinux policy set upon them. If I'm having to hack on the >> policy files on my laptop, there's no hope for a desktop user. > > One can argue that the path to an objective where everything just > works with SELinux 'on' begins by forcing the bitter syrup down the > throats. > > To extend your reasoning, if it were disabled by default, how would > one move towards just works ? > > Agreed. To put it more directly, why am I reading about your issues on fedora-devel and not in bugzilla? --CJD From nicolas.mailhot at laposte.net Thu Jul 3 17:17:32 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 03 Jul 2008 19:17:32 +0200 Subject: Easy reviews? In-Reply-To: References: <486CBA14.7060202@fedoraproject.org> Message-ID: <1215105452.32479.2.camel@rousalka.okg> Le jeudi 03 juillet 2008 ? 10:24 -0500, Jason L Tibbitts III a ?crit : > In any case, I fear we've mostly scoured the list of really easy > things; perl modules tend to be very simple since most of them are > mechanically generated; python modules are almost as easy. Fonts are also rather easy to review (and often to package, the hard work is finding correctly licensed fonts, or dumping problems on legal), but there are not a lot of people working on http://fedoraproject.org/wiki/Category:Font_wishlist -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ssorce at redhat.com Thu Jul 3 17:30:38 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2008 13:30:38 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215099725.8001.17.camel@scrappy.miketc.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> <1215099725.8001.17.camel@scrappy.miketc.com> Message-ID: <1215106238.353.178.camel@localhost.localdomain> On Thu, 2008-07-03 at 10:42 -0500, Mike Chambers wrote: > And that is what I am trying to say > for selinux, that it needs to allow things to do what they need, and > if > not, a simple little question or whatever to allow it. The user > should > NOT have to go to the CLI for anything. They shouldn't have to do > this > command or that command, JUST HIT YES OR NO!! This nice program you just download from the interweb is trying to access your keyring file directly to access your passwords: do you want to allow it? YES / NO I bet 90% of the people would hit yes. This is the reason why the Vista approach is just a pain and a failure at the same time and should never been taken as an example. Simo. -- Simo Sorce * Red Hat, Inc * New York From lordmorgul at gmail.com Thu Jul 3 17:32:10 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jul 2008 10:32:10 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215099725.8001.17.camel@scrappy.miketc.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> <1215099725.8001.17.camel@scrappy.miketc.com> Message-ID: <486D0D1A.4090402@gmail.com> Mike Chambers wrote: > On Thu, 2008-07-03 at 04:29 -0400, Alan Cox wrote: > >> Sorry if I sound fed up of all of this but I spent 9 months fighting people >> years back to get firewalling enabled by default, and that had all the same >> arguments. Today nobody (even Microsoft) would propose otherwise. >> >> This is the same thing .. >> >> As to Setroubleshoot it would be nicer if it spoke more "end user" ese and >> could prompt/fix common mislabelling (eg html files) > > I agree with Alan here, that if selinux is indeed a great program to > help secure the OS and anything else, it at least needs to be a LOT more > user friendly. > > Ok, don't give me this MS to linux compare bit on what I am comparing > next, it's the comparing of wording and concept it's done in, not > details and stuff LOL. Anyway, Vista came out with that (I forget the > damn program name) program that when certain programs/files run, you get > a dialog box that you have to continue (to allow it to run) or cancel. > Now, no this isn't exactly the same, but it is in a way. They both > provide a little better security than with out it. BUT, in Vista, the > user doesn't have to relabel something, or go to the CLI, or whatever. > They get a little question stating this program wants to run, do you > give it permission. That's it, nothing else (might not like that dialog > all the time though, I am sure). And that is what I am trying to say > for selinux, that it needs to allow things to do what they need, and if > not, a simple little question or whatever to allow it. The user should > NOT have to go to the CLI for anything. They shouldn't have to do this > command or that command, JUST HIT YES OR NO!! Working to add a simple 'press yes or no' is an exercise in futility... general users unquestioningly press yes and go on with their business whether they should have or not. There is no effective difference from turning SELinux off. If/When a program misbehaves and represents a security risk the user will have no means to know whether it should or should not be allowed... and training to say yes just because its an action they 'initiated by clicking' is horrible. I would agree that some GUI tools would be a great fix, but not in the way Vista has chosen to do them, because that is a fake and pointless security comfort blanket and nothing more. For these actions the user should at minimum have to type an administrator password (for instance any user/pass combo that has adequate PolicyKit authorization to make selinux policy changes). > Well anyway, not ranting or raving. Just trying to maybe help clarify > what Jon was talking about, and what Alan was saying. SELinux I am sure > is a wonderful thing, and just needs to be I guess, dumbed down or > whatever so the user clearly understands what it is doing or not doing > and to present the user with simple to do questions/answers/buttons or > whatever to push/answer. The problem is that the general user does NOT understand even with the explanation given. I've been struggling to understand selinux myself for several years and it is far from clear what is happening and why all the time. What is more difficult is knowing whether that application should have been allowed to do what it tried to do, and I'm far from a general desktop user. SETroubleshoot is a great step forward for helping users know why selinux denials occur, but a simple dialog box will NEVER be adequate for a general user to know whether the application is doing something inappropriate, and whether they should force it to be allowed or not. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From frank-buettner at gmx.net Thu Jul 3 18:03:27 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Thu, 03 Jul 2008 20:03:27 +0200 Subject: Co maintainer wanted Message-ID: <486D146F.7050609@gmx.net> Hello, for my packages I seek some co maintainer, because of to less time at now to do the job alone. Here my packages: ctapi-common ctapi-cyberjack muParser nas qt4-qsa qtiplot qwt qwt-doc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From dwalsh at redhat.com Thu Jul 3 18:05:00 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 14:05:00 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215031068.5130.30.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> Message-ID: <486D14CC.70406@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Masters wrote: > On Wed, 2008-07-02 at 16:29 -0400, Jon Masters wrote: > >> I think what's needed is a nice little paragraph summarizing what >> SELinux is aiming to do, and then the old option of setting permissive >> or disabling - users can then set permissive if they prefer to. > > Note that when I say this, I'm one of the users who might well turn it > off (well, set permissive) again on future installs. I've lived with > SELinux enforcing on F9 for under two weeks and have found it highly > inhibitive to performing many regular everyday tasks I'm used to. > > I wasted about 6 hours on Sunday evening[0] figuring out why an SELinux > policy update in F9 had randomly stopped VPNC from working in a policy > update - that came following days of denials trying to do even simple > stuff. I can't possibly see how thrusting this default upon masses of > otherwise unsuspecting users is a good idea. I'm not saying SELinux > isn't a fantastic idea in certain cases, just not on "the desktop". > > Dan, et al, no offense, but we need the option to come back :) > > Jon. > > [0] It had been almost ten years since I last read through all that > documentation. So although I learned a lot about our current policy, and > what has changed over the years in SELinux, so that I could understand > the current targeted policy source, this isn't something regular Fedora > users should have to do in order to be using their computers :) > > But you were running a vpnc from the command line not the one launched by network manager which was not broken. I don't know of many desktop users who would do this. So saying it should not be enabled for someone on the desktop because they would be unable to chcon is contradicted by your statement. The other problem you talked about is virtmanager also not that likely to be run by your standard desktop user. We are working with the virt team to make this simpler. libvirtd is not unconfined and running qemu as a user is unconfined. Running qemu from libvirtd is still confined and is fixed by correct labeling. Hopefully the virt-manager people will assign an appropriate context at creation time, and/or default virtual machines to /var/lib/libvirt/images where they will be labeled correctly automatically. The only confinement we have on real "Desktop users" by default. IE Users that do not know the root password, is the executable memory checks. These have been a pain in the past but they are getting better. They usually are caused by badly written programs or bad labels on programs that require java, wine, mono. But these checks can successfully stop buffer overflow attacks. So they are important. Other places where user confinement hits is through the use of PolicyKit/Hal/dbus applications where code gets run as root on the users behalf. PolicyKit/Hal/Dbus are great steps forward in usability for users but should be treated as potential threats to the security of the system. As a bug in anyone of these new apps could lead to a root exploit. So SELinux needs to be used to confine the new desktop apps. In Rawhide and Fedora 9 you can now actually confine the user using some of the stuff I have been talking about in my blogs and presentations so if you have a managed desktop user, someone who does not know the root password, you can use these to really lock down the user on a system. guest, xguest, user and staff are all available in Fedora 9 as well as the unconfined user. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtFMwACgkQrlYvE4MpobN83wCgjsh+UHp5znNJ2j16chxg4yuj ORUAniY8bZ8qru/SFWyn023fpQUfe2Zt =RMsb -----END PGP SIGNATURE----- From berrange at redhat.com Thu Jul 3 18:12:21 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 3 Jul 2008 19:12:21 +0100 Subject: Request to re-add option to disable SELinux In-Reply-To: <486D14CC.70406@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215030560.5130.21.camel@perihelion> <1215031068.5130.30.camel@perihelion> <486D14CC.70406@redhat.com> Message-ID: <20080703181221.GA19881@redhat.com> On Thu, Jul 03, 2008 at 02:05:00PM -0400, Daniel J Walsh wrote: > > The other problem you talked about is virtmanager also not that likely > to be run by your standard desktop user. We are working with the virt > team to make this simpler. libvirtd is not unconfined and running qemu > as a user is unconfined. Running qemu from libvirtd is still confined > and is fixed by correct labeling. Hopefully the virt-manager people > will assign an appropriate context at creation time, and/or default > virtual machines to /var/lib/libvirt/images where they will be labeled > correctly automatically. An update to F9 post GA set the default location to this directory. For F10 we hope to fix the problem permanently by making use of libvirt's new storage management capabilities for manipulating disks / files which will ensure the correct context is always set. 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 surenkarapetyan at gmail.com Thu Jul 3 18:15:00 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 03 Jul 2008 23:15:00 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215029424.5130.13.camel@perihelion> References: <1215029424.5130.13.camel@perihelion> Message-ID: <1215108900.17420.34.camel@roadrunner.itnet.am> On Wed, 2008-07-02 at 16:10 -0400, Jon Masters wrote: > Hi folks, > > I'd like to see the re-introduction of an option during (or shortly > after, i.e. during firstboot) installation to disable SELinux, or set it > to be permissive. My reason for making this request includes: > > *). A number of activities are not possible today, with SE Linux enabled > and enforcing on a default F9 installation. I can give examples - > downloading an ISO image and expecting to use it in virt-manager, > creating a virtual machine in a non-standard location, etc. > > *). Policy changes will randomly stop things from working that used to > work. Especially on the Desktop, where many possible code paths (SE > Linux works by denying until an exception is found and added to the > policy...requiring all code paths to be exercised) exist to do > something. I found this last week when VPNC randomly broke. > > *). Tools like nautilus do not support labeling of files via the > right-click properties dialog (gnome VFS, etc.) so there is no easy way > for an end user who even understands part of this to fix context. This > is the number one reason why SELinux should not be enabled by default, > except on systems where there is an admin who can use chcon. > > But there are numerous other justifications I could give, including my > personal belief that it's absolutely nuts to thrust SE Linux upon > unsuspecting Desktop users (who don't know what it is anyway) without > giving them the choice to turn it off. > > Cheers, > > Jon. > > I just can't understand why it was removed. If the answer is "to make it more secure" maybe we should also set root fs encryption on by default and remove the checkbox? It will become more secure... From Jochen at herr-schmitt.de Thu Jul 3 18:19:51 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 03 Jul 2008 20:19:51 +0200 Subject: Co maintainer wanted In-Reply-To: <486D146F.7050609@gmx.net> References: <486D146F.7050609@gmx.net> Message-ID: <486D1847.9090106@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank B?ttner schrieb: > Hello, > for my packages I seek some co maintainer, because of to less time > at now to do the job alone. > Here my packages: > ctapi-common > ctapi-cyberjack > muParser > nas > qt4-qsa > qtiplot > qwt > qwt-doc > I am willing for co-maintainership of qt4-qsa. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtGDQACgkQT2AHK6txfgy0/ACgxcQoWFxj7fNceE8xImCsTDjq uFAAniQmHxKMjQsuZlMcYXqcpZ1ZZ7Sf =C6aK -----END PGP SIGNATURE----- From maillist at diffingo.com Thu Jul 3 18:47:10 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 03 Jul 2008 14:47:10 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <486D03B6.9040202@redhat.com> References: <1215029424.5130.13.camel@perihelion> <486D03B6.9040202@redhat.com> Message-ID: <1215110830.24708.13.camel@Diffingo.localdomain> On Thu, 2008-07-03 at 12:52 -0400, Casey Dahlin wrote: > This is about the 950th "SELinux ate my baby, let's turn it off" thread. > What's supposed to be different THIS time? > > --CJD Nothing. But all these threads have summed up two major points: * New users don't know what SELinux is, does, or why their app isn't working or has stopped working. Moreover, many more users don't know how to find the source of the problem and report it. So overall that makes Fedora look broken in _stable releases_. * SELinux is an important aspect to security on a Linux PC and it _will not_ be disabled on new installs. If it's broken, then it's the solution isn't to disable SELinux but to fix the bug in the policy. If we could get the documentation for setroubleshoot online, I'd be interested in helping write a plugin that allowed users to report audit denials similar to how kerneloops does. setroubleshoot then bridges the gap between new users and fixing the policy, and it could be done with stats to see what areas need work on. Naturally it would only report the denials the user requests to be submitted, so no "calling home" stuff. Stewart From chris.stone at gmail.com Thu Jul 3 19:45:50 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 3 Jul 2008 12:45:50 -0700 Subject: Having problems with koji builds using mesa-libGL-devel Message-ID: Hi, I am getting X crashes on one of my applications. It seems that all it needs is a recompile, however, it needs to recompile against mesa-libGL-devel 7.1-0.35.fc9. This is all good when I do a build using mock, however when I try to build using koji it picks up version 7.1-0.37.fc9 and I continue to get the X crashes. http://kojipkgs.fedoraproject.org/packages/xwnc/0.3.3/5.fc9/data/logs/x86_64/root.log Why does koji use the .37 version of mesa-ligGL-devel instead of the .35 version like mock does? From tcallawa at redhat.com Thu Jul 3 19:53:20 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 03 Jul 2008 15:53:20 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215110830.24708.13.camel@Diffingo.localdomain> References: <1215029424.5130.13.camel@perihelion> <486D03B6.9040202@redhat.com> <1215110830.24708.13.camel@Diffingo.localdomain> Message-ID: <1215114800.20165.69.camel@localhost.localdomain> On Thu, 2008-07-03 at 14:47 -0400, Stewart Adam wrote: > setroubleshoot online I misread this and thought, what a great idea! The selinux equivalent to "kerneloops" would be really useful. :) ~spot From tibbs at math.uh.edu Thu Jul 3 19:57:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jul 2008 14:57:53 -0500 Subject: Having problems with koji builds using mesa-libGL-devel In-Reply-To: References: Message-ID: >>>>> "CS" == Christopher Stone writes: CS> Why does koji use the .37 version of mesa-ligGL-devel instead of CS> the .35 version like mock does? "koji list-tagged dist-f9-override" will show that mesa-7.1-0.37.fc9 is tagged that way. Someone made a request to rel-eng that the new mesa package be tagged that way so that more f9 updates could be built against it. - J< From jkeating at redhat.com Thu Jul 3 19:58:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 03 Jul 2008 15:58:45 -0400 Subject: Having problems with koji builds using mesa-libGL-devel In-Reply-To: References: Message-ID: <1215115125.17856.49.camel@localhost.localdomain> On Thu, 2008-07-03 at 12:45 -0700, Christopher Stone wrote: > > Why does koji use the .37 version of mesa-ligGL-devel instead of the > .35 version like mock does? Because ajax needs to build against the newer mesa for an upcoming X update -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 caillon at redhat.com Thu Jul 3 20:08:46 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 03 Jul 2008 16:08:46 -0400 Subject: spicebird Provides pollution In-Reply-To: <20080703103432.7290e736.mschwendt@gmail.com> References: <20080703103432.7290e736.mschwendt@gmail.com> Message-ID: <486D31CE.9010203@redhat.com> Michael Schwendt wrote: > Spicebird in rawhide provides 46 sonames, which are provided by > the following other packages: You need http://cvs.fedoraproject.org/viewcvs/rpms/thunderbird/F-9/find-external-requires?rev=1.1&view=log From dwalsh at redhat.com Thu Jul 3 20:10:13 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jul 2008 16:10:13 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215114800.20165.69.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <486D03B6.9040202@redhat.com> <1215110830.24708.13.camel@Diffingo.localdomain> <1215114800.20165.69.camel@localhost.localdomain> Message-ID: <486D3225.4010603@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Thu, 2008-07-03 at 14:47 -0400, Stewart Adam wrote: >> setroubleshoot online > > I misread this and thought, what a great idea! The selinux equivalent to > "kerneloops" would be really useful. :) > > ~spot > I think this is exactly what we need. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhtMiUACgkQrlYvE4MpobMvIACdHZs8NReUAe+yJyZZeDjIiPOQ WQkAoImMALCaj1Q7jlDKv0/S2ZdJftb8 =AEPW -----END PGP SIGNATURE----- From dwmw2 at infradead.org Thu Jul 3 20:14:30 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 03 Jul 2008 21:14:30 +0100 Subject: Fedora 9 ia64 now available In-Reply-To: <486CD086.1050503@redhat.com> References: <486CD086.1050503@redhat.com> Message-ID: <1215116070.10393.665.camel@pmac.infradead.org> On Thu, 2008-07-03 at 09:13 -0400, Prarit Bhargava wrote: > == Download location == > > The beta can be downloaded from: > > http://download.fedoraproject.org/pub/fedora-secondary/releases/9/ Hm, why is the URL so different from the primary architectures? Mirrors choose which architecture(s) they want to carry already; it's presumably not to make the mirroring easier? Wouldn't it be better to have it the same as the others? -- dwmw2 From jkeating at redhat.com Thu Jul 3 20:19:39 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 03 Jul 2008 16:19:39 -0400 Subject: Fedora 9 ia64 now available In-Reply-To: <1215116070.10393.665.camel@pmac.infradead.org> References: <486CD086.1050503@redhat.com> <1215116070.10393.665.camel@pmac.infradead.org> Message-ID: <1215116379.17856.51.camel@localhost.localdomain> On Thu, 2008-07-03 at 21:14 +0100, David Woodhouse wrote: > Hm, why is the URL so different from the primary architectures? Mirrors > choose which architecture(s) they want to carry already; it's presumably > not to make the mirroring easier? Wouldn't it be better to have it the > same as the others? Well, partly because it's not on Fedora's master mirror. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 dwmw2 at infradead.org Thu Jul 3 20:25:56 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 03 Jul 2008 21:25:56 +0100 Subject: Fedora 9 ia64 now available In-Reply-To: <1215116379.17856.51.camel@localhost.localdomain> References: <486CD086.1050503@redhat.com> <1215116070.10393.665.camel@pmac.infradead.org> <1215116379.17856.51.camel@localhost.localdomain> Message-ID: <1215116756.10393.673.camel@pmac.infradead.org> On Thu, 2008-07-03 at 16:19 -0400, Jesse Keating wrote: > On Thu, 2008-07-03 at 21:14 +0100, David Woodhouse wrote: > > Hm, why is the URL so different from the primary architectures? Mirrors > > choose which architecture(s) they want to carry already; it's presumably > > not to make the mirroring easier? Wouldn't it be better to have it the > > same as the others? > > Well, partly because it's not on Fedora's master mirror. Gulp. That's even worse... -- dwmw2 From lordmorgul at gmail.com Thu Jul 3 20:27:39 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jul 2008 13:27:39 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215108900.17420.34.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> Message-ID: <486D363B.9010201@gmail.com> Suren Karapetyan wrote: > I just can't understand why it was removed. > If the answer is "to make it more secure" maybe we should also set root > fs encryption on by default and remove the checkbox? > It will become more secure... You cannot immediately and easily turn that off after installation; you can with selinux, so these are nowhere near the same thing. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From maillist at diffingo.com Thu Jul 3 20:30:22 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 03 Jul 2008 16:30:22 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215114800.20165.69.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <486D03B6.9040202@redhat.com> <1215110830.24708.13.camel@Diffingo.localdomain> <1215114800.20165.69.camel@localhost.localdomain> Message-ID: <1215117022.27244.8.camel@Diffingo.localdomain> > > setroubleshoot online > > I misread this and thought, what a great idea! The selinux equivalent to > "kerneloops" would be really useful. :) > > ~spot That's what I meant by "?report audit denials similar to how kerneloops does" ;) Stewart From notting at redhat.com Thu Jul 3 20:31:09 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Jul 2008 16:31:09 -0400 Subject: Fedora 9 ia64 now available In-Reply-To: <1215116756.10393.673.camel@pmac.infradead.org> References: <486CD086.1050503@redhat.com> <1215116070.10393.665.camel@pmac.infradead.org> <1215116379.17856.51.camel@localhost.localdomain> <1215116756.10393.673.camel@pmac.infradead.org> Message-ID: <20080703203109.GA9208@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > > Well, partly because it's not on Fedora's master mirror. > > Gulp. That's even worse... Well, it's somewhat intentional - there is/was a lack of space for it on the master. Bill From surenkarapetyan at gmail.com Thu Jul 3 20:54:12 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 04 Jul 2008 01:54:12 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <486D363B.9010201@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> Message-ID: <1215118452.8182.7.camel@roadrunner.itnet.am> On Thu, 2008-07-03 at 13:27 -0700, Andrew Farris wrote: > Suren Karapetyan wrote: > > I just can't understand why it was removed. > > If the answer is "to make it more secure" maybe we should also set root > > fs encryption on by default and remove the checkbox? > > It will become more secure... > > You cannot immediately and easily turn that off after installation; you can with > selinux, so these are nowhere near the same thing. If You're smart enough to edit /etc/sysconfig/selinux and turn it off You're not far from decrypting the system. Anyway that wasn't even my main point. Whom did that damned combo box upset so much it needed to be thrown away? EVERYBODY who used to disable SELinux when the combo-box was there will STILL disable it. We didn't get ANYTHING from removing that *feature*. It just makes the lives of some of us harder. > > -- > Andrew Farris www.lordmorgul.net > gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 > From surenkarapetyan at gmail.com Thu Jul 3 20:56:05 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 04 Jul 2008 01:56:05 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215117022.27244.8.camel@Diffingo.localdomain> References: <1215029424.5130.13.camel@perihelion> <486D03B6.9040202@redhat.com> <1215110830.24708.13.camel@Diffingo.localdomain> <1215114800.20165.69.camel@localhost.localdomain> <1215117022.27244.8.camel@Diffingo.localdomain> Message-ID: <1215118565.8182.8.camel@roadrunner.itnet.am> On Thu, 2008-07-03 at 16:30 -0400, Stewart Adam wrote: > > > setroubleshoot online > > > > I misread this and thought, what a great idea! The selinux equivalent to > > "kerneloops" would be really useful. :) > > > > ~spot > That's what I meant by "?report audit denials similar to how kerneloops does" ;) > > Stewart > > It would be great :) From lordmorgul at gmail.com Thu Jul 3 21:50:11 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jul 2008 14:50:11 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215118452.8182.7.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> Message-ID: <486D4993.3030700@gmail.com> Suren Karapetyan wrote: > On Thu, 2008-07-03 at 13:27 -0700, Andrew Farris wrote: >> Suren Karapetyan wrote: >>> I just can't understand why it was removed. >>> If the answer is "to make it more secure" maybe we should also set root >>> fs encryption on by default and remove the checkbox? >>> It will become more secure... >> You cannot immediately and easily turn that off after installation; you can with >> selinux, so these are nowhere near the same thing. > If You're smart enough to edit /etc/sysconfig/selinux and turn it off > You're not far from decrypting the system. > > Anyway that wasn't even my main point. > Whom did that damned combo box upset so much it needed to be thrown > away? > > EVERYBODY who used to disable SELinux when the combo-box was there will > STILL disable it. We didn't get ANYTHING from removing that *feature*. > It just makes the lives of some of us harder. I agree it should be there once installed, but I don't think it needs to be there before/during installation. Installation should be simple and selinux is anything but; asking whether to turn it on or off there makes no sense. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From gjalves at gjalves.com.br Thu Jul 3 22:53:36 2008 From: gjalves at gjalves.com.br (Gustavo Alves) Date: Thu, 3 Jul 2008 19:53:36 -0300 Subject: Option to add files on mkinitrd Message-ID: <69e11d1f0807031553q34a9a5eex6d7fdcded3642e0b@mail.gmail.com> After the problem on bug 454027, I was thinking on add an option on mkinitrd to include arbitrary files on initrd images. In this case, I need to add a firmware file on it. An option like mkinitrd --file will be enough to do it. What do you think about it? Thanks and regards -- Gustavo Junior Alves GJAlves Tecnologia Tel: +55 19 9223-0500 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbarnes at virtuousgeek.org Thu Jul 3 23:37:11 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 3 Jul 2008 16:37:11 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807021754.52422.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807021754.52422.jbarnes@virtuousgeek.org> Message-ID: <200807031637.11351.jbarnes@virtuousgeek.org> On Wednesday, July 02, 2008 5:54 pm Jesse Barnes wrote: > Thanks for packaging this stuff, I really hope the MAPI Akonadi code works; > I'd *love* to ditch Outlook (it's the next best thing to escaping the > Exchange ghetto). Ok, started building kdepim today, but ran into quite a few problems: - profile*.cpp in openchange resource need to include KLocale - samba-4.0/events.h shouldn't use C++ keywords as variable names - lots of errors building openchange after fixing those things, along the lines of: ome/jbarnes/working/rpmbuild/BUILD/kdepim-4.0.84/x86_64-redhat-linux-gnu/akonadi/resources/openchange/akonadi_oc_resource_automoc.cpp In file included from /usr/include/QtCore/qdebug.h:53, from /usr/include/QtCore/QDebug:2, from /home/jbarnes/working/rpmbuild/BUILD/kdepim-4.0.84/akonadi/resources/openchange/ocresource.cpp:26: /usr/include/QtCore/qtextstream.h:105: error: expected unqualified-id before '(' token /usr/include/QtCore/qtextstream.h:106: error: expected unqualified-id before '(' token /usr/include/QtCore/qtextstream.h:107: error: expected unqualified-id before '(' token /usr/include/QtCore/qtextstream.h:124: error: expected unqualified-id before '(' token which again looks like a possible missing header problem? Dunno yet... Jesse From linuxkernel at edcint.co.nz Fri Jul 4 00:52:28 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Fri, 04 Jul 2008 10:52:28 +1000 Subject: Packaging of Nagios In-Reply-To: <486BD617.9070201@gmx.de> References: <48642DDD.9000508@edcint.co.nz> <486BD617.9070201@gmx.de> Message-ID: <486D744C.60401@edcint.co.nz> I can test these RPMs if I can get them from somewhere Robert M. Albrecht wrote: > Hi, > > I have working packages for Nagios 3.0.3 and Nagios PlugIns 1.4.12. > > I nearly finished with pnp4nagios, check-multi and nagvis. > > https://bugzilla.redhat.com/show_bug.cgi?id=452424 > https://bugzilla.redhat.com/show_bug.cgi?id=453330 > > cu romal > > www.romal.de > blog.romal.de > From Matt_Domsch at dell.com Fri Jul 4 04:28:57 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 3 Jul 2008 23:28:57 -0500 Subject: Please fix your FTBFS bugs, Alpha freeze 7/15 approaching Message-ID: <20080704042857.GB4261@auslistsprd01.us.dell.com> I spent a good bit of time today de-duplicating a whole lot of bugs on the FTBFS blocker list. I apologize for any duplicates my scripts caused; turns out I got bit by a bug in bugzilla[1] which was returning a truncated list of dependent bugs, so my scripts didn't see there was already a bug open against many failed packages. Those 245 that remain open are listed here: https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1 I've also started a full rawhide rebuild using today's tree, with hope that more can be closed with the current packages. With luck it'll be done over the long weekend. As per the FTBFS policy enacted by FESCo a few weeks ago, packages with remaining FTBFS bugs, and no line-of-sight to resolution, may be considered for removal following the F10 Alpha release (Alpha freeze is slated for 7/15). Please give your packages the love and feeding they need to avoid this fate. [1] https://bugzilla.redhat.com/show_bug.cgi?id=453902 Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From lemenkov at gmail.com Fri Jul 4 08:47:45 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 4 Jul 2008 12:47:45 +0400 Subject: Java status? Message-ID: Hello All! Currently we have 3 java implementations - GCJ, OpenJDK/IcedTea, ecj. Even more, we got java-1.6.0-sun for EPEL. Could someone summarize current status of these realizations (fortunately, there is a dedicated wiki-page: http://fedoraproject.org/wiki/Java )? Capabilities, standards compliance, other pros and cons. I'm interested because some packages still built with GCJ, and I'm curious why they still not rebuild with (for example) OpenJDK? Another question - what's the future of GCJ/ECJ in Fedora? Will they be superseded by OpenJDK? -- With best regards! From aph at redhat.com Fri Jul 4 09:49:26 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 04 Jul 2008 10:49:26 +0100 Subject: Java status? In-Reply-To: References: Message-ID: <486DF226.1090400@redhat.com> Peter Lemenkov wrote: > Currently we have 3 java implementations - GCJ, OpenJDK/IcedTea, ecj. > Even more, we got java-1.6.0-sun for EPEL. > > Could someone summarize current status of these realizations > (fortunately, there is a dedicated wiki-page: > http://fedoraproject.org/wiki/Java )? Capabilities, standards > compliance, other pros and cons. > > I'm interested because some packages still built with GCJ, and I'm > curious why they still not rebuild with (for example) OpenJDK? Why not? > Another question - what's the future of GCJ/ECJ in Fedora? Will they > be superseded by OpenJDK? It's a big job to answer all that. Ultimately it will be limited by the number of people available to do the work, and we're trying to plan all that. Be aware that full OpenJDK support is only available on a few platforms, so there are gaps to fill. I'll try to get all the status updates done soon. We've only just completed JCK certification for OpenJDK in Fedora, and that ought to be plenty for a little while. If I haven't updated the web page in two weeks please bug me about it. Andrew. From nicolas.mailhot at laposte.net Fri Jul 4 09:56:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 04 Jul 2008 11:56:26 +0200 Subject: Fonts packaging amendment Message-ID: <1215165386.3777.6.camel@rousalka.okg> Hi, I'm proposing the following amendment: http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles to our fonts packaging policy: http://fedoraproject.org/wiki/Packaging/FontsPolicy (official page, broken by the wiki migration) http://fedoraproject.org/wiki/Fonts_packaging_policy (unofficial cleaned-up font page ; I hope someone will the right accesses picks it up) Nothing earth-shattering, just a write-up of our current unwritten rules Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kevin.kofler at chello.at Fri Jul 4 09:57:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 4 Jul 2008 09:57:33 +0000 (UTC) Subject: Java status? References: <486DF226.1090400@redhat.com> Message-ID: Andrew Haley redhat.com> writes: > Be aware that full OpenJDK support is only > available on a few platforms, so there are gaps to fill. Speaking on OpenJDK's platform support, are there any plans to do anything with twisti's Cacao work or is Shark the way to go? Kevin Kofler From lemenkov at gmail.com Fri Jul 4 10:00:52 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 4 Jul 2008 14:00:52 +0400 Subject: Java status? In-Reply-To: <486DF226.1090400@redhat.com> References: <486DF226.1090400@redhat.com> Message-ID: 2008/7/4 Andrew Haley : [skipped] >> I'm interested because some packages still built with GCJ, and I'm >> curious why they still not rebuild with (for example) OpenJDK? > Why not? Is it the only reason? >> Another question - what's the future of GCJ/ECJ in Fedora? Will they >> be superseded by OpenJDK? > It's a big job to answer all that. Ultimately it will be limited > by the number of people available to do the work, and we're trying > to plan all that. Be aware that full OpenJDK support is only > available on a few platforms, so there are gaps to fill. What gaps? > I'll try to get all the status updates done soon. We've only just > completed JCK certification for OpenJDK in Fedora, and that ought > to be plenty for a little while. > > If I haven't updated the web page in two weeks please bug me about > it. Thanks! Will wait for updates in our Wiki. -- With best regards! From nphilipp at redhat.com Fri Jul 4 10:08:09 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 04 Jul 2008 12:08:09 +0200 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215118452.8182.7.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> Message-ID: <1215166089.26858.1.camel@gibraltar.str.redhat.com> On Fri, 2008-07-04 at 01:54 +0500, Suren Karapetyan wrote: > EVERYBODY who used to disable SELinux when the combo-box was there will > STILL disable it. We didn't get ANYTHING from removing that *feature*. Please don't confuse features with workarounds. I think it's acceptable to kindly guide people into employing that workaround only if and when they run into problems. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From surenkarapetyan at gmail.com Fri Jul 4 10:19:28 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 04 Jul 2008 15:19:28 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215166089.26858.1.camel@gibraltar.str.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> Message-ID: <1215166768.2321.7.camel@roadrunner.itnet.am> On Fri, 2008-07-04 at 12:08 +0200, Nils Philippsen wrote: > On Fri, 2008-07-04 at 01:54 +0500, Suren Karapetyan wrote: > > EVERYBODY who used to disable SELinux when the combo-box was there will > > STILL disable it. We didn't get ANYTHING from removing that *feature*. > > Please don't confuse features with workarounds. I need ?neither SELinux nor encrypted rootfs on my desktop (at least now). So I'm not trying to workaround SELinux related problems. I just don't need it/them. > I think it's acceptable > to kindly guide people into employing that workaround only if and when > they run into problems. ??The border between kindly guiding and forcing is a bit too thin. > > Nils > -- > Nils Philippsen / Red Hat / nphilipp at redhat.com > "Those who would give up Essential Liberty to purchase a little Temporary > Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > From rawhide at fedoraproject.org Fri Jul 4 10:51:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 4 Jul 2008 10:51:45 +0000 (UTC) Subject: rawhide report: 20080704 changes Message-ID: <20080704105145.582D8209D8A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080703/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080704/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package R-RSQLite SQLite database interface for R New package prelude-correlator Real time correlator of events received by Prelude Manager Updated Packages: alienarena-data-20080603-2.fc10 ------------------------------- * Thu Jul 3 18:00:00 2008 Tom "spot" Callaway 20080603-2 - get rid of prebuilt so file anaconda-11.4.1.12-1 -------------------- * Thu Jul 3 18:00:00 2008 Peter Jones - 11.4.1.12-1 - Add dmraid-libs to PACKAGES so new dmraid won't break installs. * Thu Jul 3 18:00:00 2008 Peter Jones - 11.4.1.11-1 - Fix double free in setupCdrom - Fix missing psudo->pseudo spelling fix (katzj, #453843) - Include missing X libraries in stage2.img apr-api-docs-1.3.2-2.fc10 ------------------------- * Fri Jul 4 18:00:00 2008 Bojan Smojver 1.3.2-2 - %{_arch} is set to noarch, cannot use that, include all headers * Wed Jul 2 18:00:00 2008 Bojan Smojver 1.3.2-1 - Bump up to 1.3.2 * Wed Jun 11 18:00:00 2008 Bojan Smojver 1.3.0-1 - Align with latest apr/apr-util audit-1.7.4-2.fc10 ------------------ * Thu Jul 3 18:00:00 2008 Steve Grubb 1.7.4-2 - Move ausearch-expression to main package (#453437) bluez-gnome-0.27-1.fc10 ----------------------- * Thu Jul 3 18:00:00 2008 - Bastien Nocera - 0.27-1 - Update to 0.27 bluez-libs-3.35-1.fc10 ---------------------- * Thu Jul 3 18:00:00 2008 - Bastien Nocera - 3.35-1 - Update to 3.35 bluez-utils-3.35-1.fc10 ----------------------- * Thu Jul 3 18:00:00 2008 - Bastien Nocera - 3.35-1 - Update to 3.35 bridge-utils-1.2-6.fc10 ----------------------- * Thu Jul 3 18:00:00 2008 David Woodhouse 1.2-6 - Fix location of bridge parameters in sysfs * Wed Mar 5 17:00:00 2008 David Woodhouse 1.2-5 - Fix handling of bridge named 'bridge' (#436120) collectd-4.4.1-4.fc10 --------------------- * Thu Jul 3 18:00:00 2008 Lubomir Rintel 4.4.1-4 - Fix a typo introduced by previous change that prevented building in el5 * Thu Jul 3 18:00:00 2008 Lubomir Rintel 4.4.1-3 - Make this compile with older perl package - Turn dependencies on packages to dependencies on Perl modules - Add default attributes for files digikam-0.9.4-0.4.rc2.fc10 -------------------------- * Thu Jul 3 18:00:00 2008 Rex Dieter - 0.9.4-0.4.rc2 - digikam-0.9.4-rc2 dmraid-1.0.0.rc14-8.fc10 ------------------------ * Thu Jul 3 18:00:00 2008 Alasdair Kergon - 1.0.0.rc14-8 - Move library into libs subpackage. - Fix summary and licence tags. - Replace static build with symlink. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.0.0.rc14-7 - Autorebuild for GCC 4.3 gdb-6.8-13.fc10 --------------- * Thu Jul 3 18:00:00 2008 Jan Kratochvil - 6.8-13 - Support transparent debugging of inlined functions for an optimized code. gdm-2.22.0-9.fc10 ----------------- * Thu Jul 3 18:00:00 2008 Jon McCann - 1:2.22.0-9 - Check for a null filesystem type gl-117-1.3.2-7.fc10 ------------------- * Thu Jul 3 18:00:00 2008 Steven Pritchard 1.3.2-7 - Fix BZ#304841. - Use opengl-game-wrapper. - Update .desktop file. - Drop "--add-category X-Fedora". * Thu Jul 3 18:00:00 2008 Steven Pritchard 1.3.2-6 - Update License tag. - Drop -lSDLmain. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.3.2-5 - Autorebuild for GCC 4.3 glib2-2.17.3-3.fc10 ------------------- * Thu Jul 3 18:00:00 2008 Matthias Clasen - 2.17.3-3 - Fix a stupid crash * Wed Jul 2 18:00:00 2008 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 glibc-2.8.90-8 -------------- * Thu Jul 3 18:00:00 2008 Jakub Jelinek 2.8.90-8 - update from trunk - watch even resolv.conf in nscd using inotify - some nscd fixes gnome-sharp-2.20.0-1.fc10 ------------------------- * Thu Jul 3 18:00:00 2008 Xavier Lamien - 2.20.0 - Update release. imsettings-0.101.3-1.fc10 ------------------------- * Thu Jul 3 18:00:00 2008 Akira TAGOH - 0.101.3-1 - New upstream release. - Use the system-wide xinputrc if .xinputrc is a dangling symlink. (#453358) inn-2.4.5-1.fc10 ---------------- * Thu Jul 3 18:00:00 2008 Ondrej Vasik - 2.4.5-1 - new upstream release 2.4.5 jabbim-0.4.3-1.fc10 ------------------- * Thu Jul 3 18:00:00 2008 Michal Schmidt - 0.4.3-1 - Upstream release 0.4.3. - Dropped the tune plugin patch, now merged. - Simplified the autoupdate plugin patch. Thanks to upstream changes, it's now sufficient to only changes default config values. kernel-2.6.26-0.107.rc8.git2.fc10 --------------------------------- * Thu Jul 3 18:00:00 2008 Jeremy Katz - Disable the garmin_gps driver; programs are using libusb for this now - Make padlock warnings quieter * Thu Jul 3 18:00:00 2008 Chuck Ebbert - Fix EFI boot. - Export account_system_vtime on IA64. * Wed Jul 2 18:00:00 2008 Chuck Ebbert - Re-enable the snd-pcsp driver (#452748) libvirt-cim-0.5-1.fc10 ---------------------- * Tue Jun 3 18:00:00 2008 Dan Smith - 0.5-1 - Updated to latest upstream source m17n-contrib-1.1.7-2.fc10 ------------------------- * Fri Jul 4 18:00:00 2008 Parag Nemade -1.1.7-2 - Resolves: rh#453910: [kn_IN]Include latest kn- kgp.mim againist the latest build * Thu Jul 3 18:00:00 2008 Parag Nemade -1.1.7-1 - Update to new upstream release 1.1.7 m17n-db-1.5.2-1.fc10 -------------------- * Thu Jul 3 18:00:00 2008 Parag Nemade -1.5.2-1 - Update to new upstream release 1.5.2 manedit-1.1.1-2.fc10 -------------------- * Thu Jul 3 18:00:00 2008 Mamoru Tasaka - 1.1.1-2 - Modify tmpdir.patch: to fix segv on the exit of manview - Fix segv on refresh on manview when one item is selected minirpc-0.3.2-1.fc10 -------------------- * Thu Jul 3 18:00:00 2008 Adam Goode - 0.3.2-1 - New release nfs-utils-1.1.2-12.fc10 ----------------------- * Wed Jul 2 18:00:00 2008 Steve Dickson 1.1.2-12 - Changed the default directories for sm-notify (bz 435480) - Added 'condstop' to init scripts so service are not started when nfs-utils is removed. nss_compat_ossl-0.9.2-5.fc9 --------------------------- * Mon Jun 2 18:00:00 2008 Rob Crittenden 0.9.2-5 - Fix BIO NSPR layer (#453651) perl-5.10.0-34.fc10 ------------------- * Thu Jul 3 18:00:00 2008 Stepan Kasal 4:5.10.0-34 - 453646 use -DPERL_USE_SAFE_PUTENV. Without fail some modules f.e. readline. perl-HTML-Encoding-0.60-1.fc10 ------------------------------ * Thu Jul 3 18:00:00 2008 Ville Skytt?? - 0.60-1 - 0.60. perl-Module-Find-0.06-1.fc10 ---------------------------- * Wed Jul 2 18:00:00 2008 Chris Weyl 0.06-1 - update to 0.06 - add examples/ perl-SGML-Parser-OpenSP-0.994-1.fc10 ------------------------------------ * Thu Jul 3 18:00:00 2008 Ville Skytt?? - 0.994-1 - 0.994. policycoreutils-2.0.52-2.fc10 ----------------------------- python-2.5.1-26.fc9 ------------------- * Sun Jun 15 18:00:00 2008 James Antill - 2.5.1-26 - Fix sporadic listdir problem - Resolves: bug#451494 python-augeas-0.2.1-1.fc10 -------------------------- * Thu Jul 3 18:00:00 2008 Harald Hoyer 0.2.1-1 - version 0.2.1 * Wed Jun 11 18:00:00 2008 Harald Hoyer 0.2.0-1 - switched to noarch, dlopen/ python bindings python-pycurl-7.18.2-1.fc10 --------------------------- * Thu Jul 3 18:00:00 2008 Jeffrey C. Ollie - 7.18.2-1 - Update to 7.18.2 - Thanks to Ville Skytt?? re-enable the tests and fix a minor problem with the setup.py. (Bug # 45400) remctl-2.11-7.fc10 ------------------ * Tue Jun 3 18:00:00 2008 Simon Wilkinson 2.11-7 - Update to catch new perl version, and fix perl dependencies (#453579) sectool-0.8.0-1.fc10 -------------------- * Thu Jul 3 18:00:00 2008 Peter Vrabec - 0.8.0-1 - upgrade stardict-3.0.1-9.fc9 -------------------- * Fri Jun 27 18:00:00 2008 Caius Chance - 3.0.1-9.fc9 - Fixed broken dependency by gucharmap. subtitleeditor-0.21.3-1.fc10 ---------------------------- * Thu Jul 3 18:00:00 2008 Martin Sourada - 0.21.3-1 - New upstream release - Add option -f --file for open a file - Add MimeType in desktop file. - Update Czech translation - Fix: Play/Pause button - Fix: #10494 (upstream) subversion-1.5.0-7 ------------------ * Thu Jul 3 18:00:00 2008 Joe Orton 1.5.0-7 - add svnmerge and wcgrep to docdir (Edward Rudd, #451932) - drop neon version overrides system-switch-java-1.1.3-1.fc10 ------------------------------- * Thu Jul 3 18:00:00 2008 Thomas Fitzsimmons - 1.1.3-1 - Import system-switch-java 1.1.3. - Remove desktop file patch. - Remove Fedora 7 obsoletes. - Resolves: rhbz#453625 * Wed Jun 11 18:00:00 2008 Thomas Fitzsimmons - 1.1.2-3 - Update URL and source tags to point to Fedora Hosted. * Mon Apr 14 18:00:00 2008 Thomas Fitzsimmons - 1.1.2-2 - Require libuser-python in place of libuser. - Require newt-python in place of newt. - Resolves: rhbz#251352 telepathy-glib-0.7.11-1.fc10 ---------------------------- * Thu Jul 3 18:00:00 2008 Brian Pepple - 0.7.11-1 - Update to 0.7.11. tkimg-1.3-0.11.20080505svn.fc10 ------------------------------- * Thu Jul 3 18:00:00 2008 Tom "spot" Callaway - 1.3-0.11.200805005svn - fix configure to use --with-tcl=%{tcl_sitearch} ustr-1.0.4-7.fc9 ---------------- * Fri Jun 13 18:00:00 2008 James Antill - 1.0.4-7 - Fix c99 inline problems, newer GCC vnc-4.1.2-33.fc10 ----------------- * Thu Jul 3 18:00:00 2008 Adam Tkac 4.1.2-33 - build with -rdynamic to make swrast_dri driver happy xwnc-0.3.3-5.fc10 ----------------- * Thu Jul 3 18:00:00 2008 Christopher Stone 0.3.3-5 - Rebuild for new Mesa zsh-4.3.4-8.fc9 --------------- * Thu May 15 18:00:00 2008 James Antill - 4.3.4-8 - Re-tweak zshrc and zprofile for ZDOTDIR - Resolves: rhbz#430665 Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 48 Broken deps for i386 ---------------------------------------------------------- banshee-1.0.0-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-evolution-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 hardinfo-0.4.2.3-5.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.i386 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- banshee-1.0.0-1.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-evolution-0.3.7-6.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 hardinfo-0.4.2.3-5.fc9.x86_64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tomboy-0.11.0-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- banshee-1.0.0-1.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 beagle-evolution-0.3.7-6.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 hardinfo-0.4.2.3-5.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) hardinfo-0.4.2.3-5.fc9.ppc64 requires libgnutls.so.13()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From alexl at users.sourceforge.net Fri Jul 4 11:17:53 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 04:17:53 -0700 Subject: many broken mono packages because of gnome-sharp update (was Re: rawhide report: 20080704 changes) In-Reply-To: <20080704105145.582D8209D8A@releng1.fedora.phx.redhat.com> (rawhide@fedoraproject.org's message of "Fri\, 4 Jul 2008 10\:51\:45 +0000 \(UTC\)") References: <20080704105145.582D8209D8A@releng1.fedora.phx.redhat.com> Message-ID: <41k5g1x5i6.fsf@allele2.eebweb.arizona.edu> This update to gnome-sharp: > gnome-sharp-2.20.0-1.fc10 > * Thu Jul 3 18:00:00 2008 Xavier Lamien > - 2.20.0 - Update release. which should have been pre-announced to give time for other maintainers to rebuild their packages has caused the breakage of a large number of mono apps, including major apps like f-spot, beagle and tomboy: Broken deps for i386 ---------------------------------------------------------- banshee-1.0.0-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-evolution-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 beagle-gnome-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 Could maintainers please be more aware of the number of packages that their package can affect; co-ordinate with other maintainers so they can rebuild immediately the new package is available (or at least very soon after); and give a fair warning on fedora-devel-list (as was done with the gnutls update) before going ahead with such a major soname bump. I know this is rawhide, but it could be made a tad bit smoother for testers if there was a bit more co-ordination between maintainers. A. From rjones at redhat.com Fri Jul 4 11:33:05 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 4 Jul 2008 12:33:05 +0100 Subject: Fedora 9 ia64 now available In-Reply-To: <486CD086.1050503@redhat.com> References: <486CD086.1050503@redhat.com> Message-ID: <20080704113305.GA3374@amd.home.annexia.org> Sorry if this is a stupid question, but you mention that there are builders on that IA64 page, but I don't see any option to build (eg Rawhide packages) against IA64 in Koji. 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 paul at city-fan.org Fri Jul 4 11:43:21 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 04 Jul 2008 12:43:21 +0100 Subject: Fedora 9 ia64 now available In-Reply-To: <20080704113305.GA3374@amd.home.annexia.org> References: <486CD086.1050503@redhat.com> <20080704113305.GA3374@amd.home.annexia.org> Message-ID: <486E0CD9.3020404@city-fan.org> Richard W.M. Jones wrote: > Sorry if this is a stupid question, but you mention that there are > builders on that IA64 page, but I don't see any option to build (eg > Rawhide packages) against IA64 in Koji. Build for ia64: $ koji --weburl=http://ia64.koji.fedoraproject.org/koji \ --server=http://ia64.koji.fedoraproject.org/kojihub \ build --scratch dist-f10 some.rpm/cvstag Build for sparc: $ koji --weburl=http://sparc.koji.fedoraproject.org/koji \ --server=http://sparc.koji.fedoraproject.org/kojihub \ build --scratch dist-f10 some.rpm/cvstag At least, that's what I did when fixing build failures on these architectures that I got emails about. Paul. From dan at danny.cz Fri Jul 4 11:51:51 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 04 Jul 2008 13:51:51 +0200 Subject: Fedora 9 ia64 now available In-Reply-To: <20080704113305.GA3374@amd.home.annexia.org> References: <486CD086.1050503@redhat.com> <20080704113305.GA3374@amd.home.annexia.org> Message-ID: <1215172311.3472.2.camel@eagle.danny.cz> Richard W.M. Jones p??e v P? 04. 07. 2008 v 12:33 +0100: > Sorry if this is a stupid question, but you mention that there are > builders on that IA64 page, but I don't see any option to build (eg > Rawhide packages) against IA64 in Koji. You should have configs for secondary architectures in $HOME/.koji. They are created by current version of fedora-packager-setup, I think. Dan -- Fedora and Red Hat package maintainer From Matt_Domsch at dell.com Fri Jul 4 12:15:17 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 4 Jul 2008 07:15:17 -0500 Subject: Fedora 9 ia64 now available In-Reply-To: <1215116070.10393.665.camel@pmac.infradead.org> References: <486CD086.1050503@redhat.com> <1215116070.10393.665.camel@pmac.infradead.org> Message-ID: <20080704121517.GC4261@auslistsprd01.us.dell.com> On Thu, Jul 03, 2008 at 09:14:30PM +0100, David Woodhouse wrote: > On Thu, 2008-07-03 at 09:13 -0400, Prarit Bhargava wrote: > > == Download location == > > > > The beta can be downloaded from: > > > > http://download.fedoraproject.org/pub/fedora-secondary/releases/9/ > > Hm, why is the URL so different from the primary architectures? Mirrors > choose which architecture(s) they want to carry already; it's presumably > not to make the mirroring easier? Wouldn't it be better to have it the > same as the others? The URL: http://download.fedoraproject.org/pub/fedora/linux/releases/9/Fedora/ia64/ works fine, just like the primary arches. http://fedoraproject.org/wiki/Infrastructure/Mirroring describes how to mirror secondary arch content. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rjones at redhat.com Fri Jul 4 12:15:34 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 4 Jul 2008 13:15:34 +0100 Subject: Fedora 9 ia64 now available In-Reply-To: <1215172311.3472.2.camel@eagle.danny.cz> References: <486CD086.1050503@redhat.com> <20080704113305.GA3374@amd.home.annexia.org> <1215172311.3472.2.camel@eagle.danny.cz> Message-ID: <20080704121534.GA3643@amd.home.annexia.org> On Fri, Jul 04, 2008 at 01:51:51PM +0200, Dan Hor?k wrote: > > Richard W.M. Jones p??e v P? 04. 07. 2008 v 12:33 +0100: > > Sorry if this is a stupid question, but you mention that there are > > builders on that IA64 page, but I don't see any option to build (eg > > Rawhide packages) against IA64 in Koji. > > You should have configs for secondary architectures in $HOME/.koji. They > are created by current version of fedora-packager-setup, I think. So I'm still pretty unclear about this. 'make build' can be persuaded to build on secondary architectures? 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 dan at danny.cz Fri Jul 4 12:33:29 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 04 Jul 2008 14:33:29 +0200 Subject: Fedora 9 ia64 now available In-Reply-To: <20080704121534.GA3643@amd.home.annexia.org> References: <486CD086.1050503@redhat.com> <20080704113305.GA3374@amd.home.annexia.org> <1215172311.3472.2.camel@eagle.danny.cz> <20080704121534.GA3643@amd.home.annexia.org> Message-ID: <1215174809.3472.19.camel@eagle.danny.cz> Richard W.M. Jones p??e v P? 04. 07. 2008 v 13:15 +0100: > On Fri, Jul 04, 2008 at 01:51:51PM +0200, Dan Hor?k wrote: > > > > Richard W.M. Jones p??e v P? 04. 07. 2008 v 12:33 +0100: > > > Sorry if this is a stupid question, but you mention that there are > > > builders on that IA64 page, but I don't see any option to build (eg > > > Rawhide packages) against IA64 in Koji. > > > > You should have configs for secondary architectures in $HOME/.koji. They > > are created by current version of fedora-packager-setup, I think. > > So I'm still pretty unclear about this. 'make build' can be persuaded > to build on secondary architectures? Now you could theoretically use 'KOJI_FLAGS="-c ~/.koji/s390-config" make build' to override the default config and build for s390. But I have not tried it yet. Dan -- Fedora and Red Hat package maintainer From laxathom at fedoraproject.org Fri Jul 4 12:35:37 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 14:35:37 +0200 Subject: many broken mono packages because of gnome-sharp update (was Re: rawhide report: 20080704 changes) In-Reply-To: <41k5g1x5i6.fsf@allele2.eebweb.arizona.edu> References: <20080704105145.582D8209D8A@releng1.fedora.phx.redhat.com> <41k5g1x5i6.fsf@allele2.eebweb.arizona.edu> Message-ID: <62bc09df0807040535i5a20b66bmf8ab406bb4dccaea@mail.gmail.com> On Fri, Jul 4, 2008 at 1:17 PM, Alex Lancaster wrote: > This update to gnome-sharp: > > > gnome-sharp-2.20.0-1.fc10 > > * Thu Jul 3 18:00:00 2008 Xavier Lamien > > - 2.20.0 - Update release. > > which should have been pre-announced to give time for other > maintainers to rebuild their packages has caused the breakage of a > large number of mono apps, including major apps like f-spot, beagle > and tomboy: > > Broken deps for i386 > ---------------------------------------------------------- > banshee-1.0.0-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > banshee-1.0.0-1.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 > beagle-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0: > 2.16.0.0 > beagle-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > beagle-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 > beagle-evolution-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0: > 2.16.0.0 > beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-sharp) = 0: > 2.16.0.0 > beagle-gnome-0.3.7-6.fc10.i386 requires mono(gnome-vfs-sharp) = 0: > 2.16.0.0 > beagle-gnome-0.3.7-6.fc10.i386 requires mono(gconf-sharp) = 0: > 2.16.0.0 > f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0: > 2.16.0.0 > f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0: > 2.16.0.0 > f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 > gbrainy-0.70-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0: > 2.16.0.0 > gnome-subtitles-0.8-3.fc10.i386 requires mono(gnome-sharp) = 0: > 2.16.0.0 > gnome-subtitles-0.8-3.fc10.i386 requires mono(gconf-sharp) = 0: > 2.16.0.0 > gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = > 0:2.16.0.0 > tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 > tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0: > 2.16.0.0 > > > Could maintainers please be more aware of the number of packages that > their package can affect; co-ordinate with other maintainers so they > can rebuild immediately the new package is available (or at least very > soon after); and give a fair warning on fedora-devel-list (as was done > with the gnutls update) before going ahead with such a major soname > bump. > > I know this is rawhide, but it could be made a tad bit smoother for > testers if there was a bit more co-ordination between maintainers. > > A. ho, sorry all for that. I was bug'ed about the fact that gnome-sharp2.20 is required for many packages. Just let me know if there is any other trouble. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Fri Jul 4 12:55:49 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 14:55:49 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 Message-ID: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> Hello mono's packages maintainers, I plan to update gnome-sharp to version 2.20.0 and gtk-sharp2 to version 2.12.0 on the next days for the current fedora release F-9. Those packages will for first be pushed to test (also until all of you will have a look on your related mono packages). Let me know if you have any trouble. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Fri Jul 4 13:01:02 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 04 Jul 2008 14:01:02 +0100 Subject: Java status? In-Reply-To: References: <486DF226.1090400@redhat.com> Message-ID: <486E1F0E.305@redhat.com> Kevin Kofler wrote: > Andrew Haley redhat.com> writes: >> Be aware that full OpenJDK support is only >> available on a few platforms, so there are gaps to fill. > > Speaking on OpenJDK's platform support, are there any plans to do anything with > twisti's Cacao work or is Shark the way to go? I have Cacao as a back-burner project and I'll be investigating it through the summer. It looks very interesting, and it now seems to be stabilizing enough to be more than just an experimental curiosity. All help is welcome, of course: simply building Cacao + OpenJDK on one of the secondary arches and reporting back on how well it works would be massively useful. Andrew. From aph at redhat.com Fri Jul 4 13:03:28 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 04 Jul 2008 14:03:28 +0100 Subject: Java status? In-Reply-To: References: <486DF226.1090400@redhat.com> Message-ID: <486E1FA0.8080401@redhat.com> Peter Lemenkov wrote: > 2008/7/4 Andrew Haley : > > [skipped] > >>> I'm interested because some packages still built with GCJ, and I'm >>> curious why they still not rebuild with (for example) OpenJDK? > >> Why not? > > Is it the only reason? They already build perfectly well with gcj, so I can't see anything to be gained by changing them. >>> Another question - what's the future of GCJ/ECJ in Fedora? Will they >>> be superseded by OpenJDK? > >> It's a big job to answer all that. Ultimately it will be limited >> by the number of people available to do the work, and we're trying >> to plan all that. Be aware that full OpenJDK support is only >> available on a few platforms, so there are gaps to fill. > > What gaps? Most non-x86 platforms. We have an interpreter-only port of OpenJDK for other platforms, which works well but is rather slow. Andrew. From jkeating at redhat.com Fri Jul 4 13:07:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 04 Jul 2008 09:07:55 -0400 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> Message-ID: <1215176875.17856.76.camel@localhost.localdomain> On Fri, 2008-07-04 at 14:55 +0200, Xavier Lamien wrote: > > Hello mono's packages maintainers, > > I plan to update gnome-sharp to version 2.20.0 and gtk-sharp2 to version > 2.12.0 on the next days for the current fedora release F-9. > Those packages will for first be pushed to test (also until all of you will > have a look on your related mono packages). > > Let me know if you have any trouble. Given the number of things this broke in devel, I really don't think this is a good idea for the stable Fedora 9 release. Please please please keep a thought to keeping stable releases stable, and not do version bumping all over the place just for fun, especially on a highly dependent package like the above listed. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 smparrish at shallowcreek.net Fri Jul 4 13:14:05 2008 From: smparrish at shallowcreek.net (Steven M. Parrish) Date: Fri, 4 Jul 2008 09:14:05 -0400 Subject: spicebird Provides pollution In-Reply-To: <486D31CE.9010203@redhat.com> References: <20080703103432.7290e736.mschwendt@gmail.com> <486D31CE.9010203@redhat.com> Message-ID: <200807040914.12236.smparrish@shallowcreek.net> On Thursday 03 July 2008 04:08:46 pm Christopher Aillon wrote: > Michael Schwendt wrote: > > Spicebird in rawhide provides 46 sonames, which are provided by > > the following other packages: > > You need > http://cvs.fedoraproject.org/viewcvs/rpms/thunderbird/F-9/find-external-req >uires?rev=1.1&view=log The problem is the spicebird folks have patched xulrunner to work with their app. I've checked upstream and this is still the case, it will not build against a stock xulrunner. For this reason I am pulling the package until this is resolved. -------------- 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 laxathom at fedoraproject.org Fri Jul 4 13:21:42 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 15:21:42 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <1215176875.17856.76.camel@localhost.localdomain> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> Message-ID: <62bc09df0807040621o414fca7bh5589c456cc5c03bb@mail.gmail.com> 2008/7/4 Jesse Keating : > On Fri, 2008-07-04 at 14:55 +0200, Xavier Lamien wrote: > > > > Hello mono's packages maintainers, > > > > I plan to update gnome-sharp to version 2.20.0 and gtk-sharp2 to version > > 2.12.0 on the next days for the current fedora release F-9. > > Those packages will for first be pushed to test (also until all of you > will > > have a look on your related mono packages). > > > > Let me know if you have any trouble. > > Given the number of things this broke in devel, I really don't think > this is a good idea for the stable Fedora 9 release. Please please > please keep a thought to keeping stable releases stable, and not do > version bumping all over the place just for fun, especially on a highly > dependent package like the above listed. I'm not really do update just for fun jesse ;) (i have too work to do already) Hm... Steven Garrity if you read us, please have a closer look. i currently broken many mono packages dependencies on rawhide due to this update. you will have to wait to update gnome-do to 0.5 in F-9. > -- > Jesse Keating > Fedora -- Freedom? is a feature! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Fri Jul 4 13:27:21 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jul 2008 18:57:21 +0530 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807040621o414fca7bh5589c456cc5c03bb@mail.gmail.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <62bc09df0807040621o414fca7bh5589c456cc5c03bb@mail.gmail.com> Message-ID: <486E2539.3050705@fedoraproject.org> Xavier Lamien wrote: > > I'm not really do update just for fun jesse ;) Then would you mind stating the reason? That should have been done in the announcement itself. Rahul From drago01 at gmail.com Fri Jul 4 13:33:32 2008 From: drago01 at gmail.com (drago01) Date: Fri, 4 Jul 2008 15:33:32 +0200 Subject: gnutls upgrade in rawhide to 2.4.0 and license change In-Reply-To: <1213967520.25242.8.camel@vespa.frost.loc> References: <1213967520.25242.8.camel@vespa.frost.loc> Message-ID: On Fri, Jun 20, 2008 at 3:12 PM, Tomas Mraz wrote: > hardinfo-0.4.2.3-5.fc9.src.rpm I got annoyed by the broken deps mail and just submitted a new build. From laxathom at fedoraproject.org Fri Jul 4 13:58:56 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 15:58:56 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <486E2539.3050705@fedoraproject.org> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <62bc09df0807040621o414fca7bh5589c456cc5c03bb@mail.gmail.com> <486E2539.3050705@fedoraproject.org> Message-ID: <62bc09df0807040658j535191e1t6112f30867c79f3a@mail.gmail.com> On Fri, Jul 4, 2008 at 3:27 PM, Rahul Sundaram wrote: > Xavier Lamien wrote: > > I'm not really do update just for fun jesse ;) >> > > Then would you mind stating the reason? That should have been done in the > announcement itself. The maintainer of gnome-do needs gnome-sharp-2.20.0 in order to update gnome-do to 0.5 (bug dependency in bugzilla) which seems shipped with some critical bugs fixed and improvements. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at nigelj.com Fri Jul 4 14:00:11 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 05 Jul 2008 02:00:11 +1200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <1215176875.17856.76.camel@localhost.localdomain> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> Message-ID: <486E2CEB.7060608@nigelj.com> Jesse Keating wrote: > On Fri, 2008-07-04 at 14:55 +0200, Xavier Lamien wrote: > >> Hello mono's packages maintainers, >> >> I plan to update gnome-sharp to version 2.20.0 and gtk-sharp2 to version >> 2.12.0 on the next days for the current fedora release F-9. >> Those packages will for first be pushed to test (also until all of you will >> have a look on your related mono packages). >> >> Let me know if you have any trouble. >> > > Given the number of things this broke in devel, I really don't think > this is a good idea for the stable Fedora 9 release. Please please > please keep a thought to keeping stable releases stable, and not do > version bumping all over the place just for fun, especially on a highly > dependent package like the above listed. > +1 too much collateral damage at the moment, I'd sooner see us wait until everything in Rawhide is fixed and then a while, at least 2 weeks. - Nigel From drago01 at gmail.com Fri Jul 4 14:14:36 2008 From: drago01 at gmail.com (drago01) Date: Fri, 4 Jul 2008 16:14:36 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <486E2CEB.7060608@nigelj.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> Message-ID: Tryed to rebuild beagle in rawhide failed with: http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log From sundaram at fedoraproject.org Fri Jul 4 14:19:29 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jul 2008 19:49:29 +0530 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807040658j535191e1t6112f30867c79f3a@mail.gmail.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <62bc09df0807040621o414fca7bh5589c456cc5c03bb@mail.gmail.com> <486E2539.3050705@fedoraproject.org> <62bc09df0807040658j535191e1t6112f30867c79f3a@mail.gmail.com> Message-ID: <486E3171.7040806@fedoraproject.org> Xavier Lamien wrote: > > The maintainer of gnome-do needs gnome-sharp-2.20.0 in order to update > gnome-do to 0.5 (bug dependency in bugzilla) > which seems shipped with some critical bugs fixed and improvements. Would be useful to get a look at the improvements and see if they are really worth it for Fedora 9. Also wait for the rebuilds in rawhide to be tested completely before pushing it to updates testing repository. Bodhi allows cancelling a push. Rahul From fedora at matbooth.co.uk Fri Jul 4 14:47:50 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 4 Jul 2008 15:47:50 +0100 Subject: Java status? In-Reply-To: <486E1FA0.8080401@redhat.com> References: <486DF226.1090400@redhat.com> <486E1FA0.8080401@redhat.com> Message-ID: <9497e9990807040747j2bcb624h78af0f6c206f4131@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jul 4, 2008 at 2:03 PM, Andrew Haley wrote: > Peter Lemenkov wrote: >> 2008/7/4 Andrew Haley : >> >> [skipped] >> >>>> I'm interested because some packages still built with GCJ, and I'm >>>> curious why they still not rebuild with (for example) OpenJDK? >> >>> Why not? >> >> Is it the only reason? > > They already build perfectly well with gcj, so I can't see anything > to be gained by changing them. > I should think they will continue to be built with GCJ until OpenJDK supports ahead-of-time compiling. - -- Mat Booth www.matbooth.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkhuN/IACgkQKfdzh3zDrvALfwCffcHT8pQgDxCbxKu0/CXDnJyP NmMAn3V2Cz7OQ4HvPKCzua4b8e/OA/VH =vJUQ -----END PGP SIGNATURE----- From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 4 15:10:06 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 05 Jul 2008 00:10:06 +0900 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> Message-ID: <486E3D4E.4010006@ioa.s.u-tokyo.ac.jp> drago01 wrote, at 07/04/2008 11:14 PM +9:00: > Tryed to rebuild beagle in rawhide failed with: > http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log Seems pkgconfig .pc file in gnome-sharp-devel-2.20.0-1.fc10 are all broken (libdir is not set, and also perhaps prefix is wrong). Xavier, would you fix them? Mamoru From laxathom at fedoraproject.org Fri Jul 4 15:18:30 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 17:18:30 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <486E3D4E.4010006@ioa.s.u-tokyo.ac.jp> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <486E3D4E.4010006@ioa.s.u-tokyo.ac.jp> Message-ID: <62bc09df0807040818j135bba08i592eecb99d113c05@mail.gmail.com> On Fri, Jul 4, 2008 at 5:10 PM, Mamoru Tasaka wrote: > drago01 wrote, at 07/04/2008 11:14 PM +9:00: > >> Tryed to rebuild beagle in rawhide failed with: >> http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log >> > > Seems pkgconfig .pc file in gnome-sharp-devel-2.20.0-1.fc10 are all > broken (libdir is not set, and also perhaps prefix is wrong). Xavier, would > you fix them? i'm already working on it. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Fri Jul 4 16:09:51 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 18:09:51 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> Message-ID: <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> On Fri, Jul 4, 2008 at 4:14 PM, drago01 wrote: > Tryed to rebuild beagle in rawhide failed with: > http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log > Fixed, Could you give a try with those packages http://koji.fedoraproject.org/koji/taskinfo?taskID=696567 -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From lordmorgul at gmail.com Fri Jul 4 16:59:22 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 04 Jul 2008 09:59:22 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215166768.2321.7.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> Message-ID: <486E56EA.9080002@gmail.com> Suren Karapetyan wrote: > On Fri, 2008-07-04 at 12:08 +0200, Nils Philippsen wrote: >> On Fri, 2008-07-04 at 01:54 +0500, Suren Karapetyan wrote: >>> EVERYBODY who used to disable SELinux when the combo-box was there will >>> STILL disable it. We didn't get ANYTHING from removing that *feature*. >> Please don't confuse features with workarounds. > I need ?neither SELinux nor encrypted rootfs on my desktop (at least > now). So I'm not trying to workaround SELinux related problems. I just > don't need it/them. I think its unfortunate that so many people believe SELinux is something 'for the server' and not needed 'on the desktop'. That probably comes from the first policy being deployed for server processes (if my memory serves correctly). I'm not attacking your own position on this point Suren, but it is hard to understand why you would think this unless not really understanding what SELinux is meant to prevent. The core developers working on SELinux have many times said the desktop is precisely where it is most needed, especially confining browsers and plugins. I think my personal information on my laptop is worth the extra security. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From surenkarapetyan at gmail.com Fri Jul 4 17:45:11 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 04 Jul 2008 22:45:11 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <486E56EA.9080002@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> Message-ID: <1215193511.3816.14.camel@roadrunner.itnet.am> On Fri, 2008-07-04 at 09:59 -0700, Andrew Farris wrote: > Suren Karapetyan wrote: > > On Fri, 2008-07-04 at 12:08 +0200, Nils Philippsen wrote: > >> On Fri, 2008-07-04 at 01:54 +0500, Suren Karapetyan wrote: > >>> EVERYBODY who used to disable SELinux when the combo-box was there will > >>> STILL disable it. We didn't get ANYTHING from removing that *feature*. > >> Please don't confuse features with workarounds. > > I need ?neither SELinux nor encrypted rootfs on my desktop (at least > > now). So I'm not trying to workaround SELinux related problems. I just > > don't need it/them. > > I think its unfortunate that so many people believe SELinux is something 'for > the server' and not needed 'on the desktop'. That probably comes from the first > policy being deployed for server processes (if my memory serves correctly). I'm > not attacking your own position on this point Suren, but it is hard to > understand why you would think this unless not really understanding what SELinux > is meant to prevent. > > The core developers working on SELinux have many times said the desktop is > precisely where it is most needed, especially confining browsers and plugins. I > think my personal information on my laptop is worth the extra security. > > -- > Andrew Farris www.lordmorgul.net > gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 > I'm no expert of SELinux, but I do have a good understanding of what it does (at least currently). And I agree: it's much more useful on the desktop than (BTW. don't laugh at me when I mess with then/than) on the server (tune at a bit and it can prevent social engineering). But it's not useful to me. And I understand I'm not the only user and it's OK if I don't like something, others may like/want/need it. But Fedora is about Freedom... freedom of choice among others. And we are making increasingly harder to make non-standard choice. The option to disable SELinux didn't create problems for anyone. Experienced users knew what to do. And people not knowing what it is just clicked 'Next'. From overholt at redhat.com Fri Jul 4 17:49:58 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 4 Jul 2008 13:49:58 -0400 Subject: Java status? In-Reply-To: <9497e9990807040747j2bcb624h78af0f6c206f4131@mail.gmail.com> References: <486DF226.1090400@redhat.com> <486E1FA0.8080401@redhat.com> <9497e9990807040747j2bcb624h78af0f6c206f4131@mail.gmail.com> Message-ID: <20080704174958.GA25575@redhat.com> * Mat Booth [2008-07-04 10:48]: > On Fri, Jul 4, 2008 at 2:03 PM, Andrew Haley wrote: > > Peter Lemenkov wrote: > >> 2008/7/4 Andrew Haley : > >> > >> [skipped] > >> > >>>> I'm interested because some packages still built with GCJ, and I'm > >>>> curious why they still not rebuild with (for example) OpenJDK? > > > > [...] > > > > They already build perfectly well with gcj, so I can't see anything > > to be gained by changing them. > > I should think they will continue to be built with GCJ until OpenJDK > supports ahead-of-time compiling. No, the AOT compilation was a GCJ-specific thing. In the JIT (HotSpot in the OpenJDK case) world, the need for AOT compilation goes away. Andrew From aph at redhat.com Fri Jul 4 18:07:14 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 04 Jul 2008 19:07:14 +0100 Subject: Java status? In-Reply-To: <20080704174958.GA25575@redhat.com> References: <486DF226.1090400@redhat.com> <486E1FA0.8080401@redhat.com> <9497e9990807040747j2bcb624h78af0f6c206f4131@mail.gmail.com> <20080704174958.GA25575@redhat.com> Message-ID: <486E66D2.9030007@redhat.com> Andrew Overholt wrote: > * Mat Booth [2008-07-04 10:48]: >> On Fri, Jul 4, 2008 at 2:03 PM, Andrew Haley wrote: >>> Peter Lemenkov wrote: >>>> 2008/7/4 Andrew Haley : >>>> >>>> [skipped] >>>> >>>>>> I'm interested because some packages still built with GCJ, and I'm >>>>>> curious why they still not rebuild with (for example) OpenJDK? >>> [...] >>> >>> They already build perfectly well with gcj, so I can't see anything >>> to be gained by changing them. >> I should think they will continue to be built with GCJ until OpenJDK >> supports ahead-of-time compiling. > > No, the AOT compilation was a GCJ-specific thing. In the JIT (HotSpot > in the OpenJDK case) world, the need for AOT compilation goes away. Well, kinda-sorta. Modern JITs undoubtedly do a terrific job, but there are some environments for which they are a little too heavyweight. I still think there's some benefit to be had from gcj, but probably not on high-powered desktop boxes. Andrew. From ssorce at redhat.com Fri Jul 4 18:34:38 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 14:34:38 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215193511.3816.14.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> Message-ID: <1215196478.353.243.camel@localhost.localdomain> On Fri, 2008-07-04 at 22:45 +0500, Suren Karapetyan wrote: > The option to disable SELinux didn't create problems for anyone. > Experienced users knew what to do. And people not knowing what it is > just clicked 'Next'. Wrong, it added yet another annoying mysterious choice for everybody. You have all the tools to disable it later, it's not like we took away the possibility to disable it, we just don't ask for it at installation like we do not ask for other gazzilion configuration option at installation time. Everyone have some specific setting they change for the default right after installation, should everyone get an option for it into the install screen? Let's be less selfish guys and look at the bigger picture. If you know you don't need SELinux for whatever reason you can simply disable it after installation (or in kickstart if you do automated installations). If you are a Fedora developer and disable it by default to "develop" packages than I honestly think you are poorly executing your task. You should set it to permissive only when you get some "access denied" problem while testing the specific changes, and as soon as you are happy with it and ready to push a new package, you should FIRST set? SELinux back to Enalbled and (working with Dan if necessary) make sure your package pass again all your tests. Not doing so you are making a disservice to the Fedora community, because if you don't test with SELinux on then you don't know if your stuff will work with it enabled, and you will create a bad experience for other developers and users. Simo. -- Simo Sorce * Red Hat, Inc * New York From surenkarapetyan at gmail.com Fri Jul 4 19:19:14 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 05 Jul 2008 00:19:14 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215196478.353.243.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> Message-ID: <1215199155.3816.33.camel@roadrunner.itnet.am> On Fri, 2008-07-04 at 14:34 -0400, Simo Sorce wrote: > On Fri, 2008-07-04 at 22:45 +0500, Suren Karapetyan wrote: > > The option to disable SELinux didn't create problems for anyone. > > Experienced users knew what to do. And people not knowing what it is > > just clicked 'Next'. > > Wrong, it added yet another annoying mysterious choice for everybody. And because of that "?annoying mysterious choice" "everybody" just couldn't install Fedora cause they didn't know what to do (i.e. click Next) That's the most horrible direction of reasoning. With that we can easily remove every option from installation process. (What's the point in asking what packages You want... You can install/remove later... What's the point in changing default partitioning... it's OK). > > You have all the tools to disable it later, it's not like we took away > the possibility to disable it, we just don't ask for it at installation > like we do not ask for other gazzilion configuration option at > installation time. We're just make it harder to disable. And we're doing it cause non-technical people don't like seeing something they don't understand (and if You're not technical it will happen quite often when working with PCs) > > Everyone have some specific setting they change for the default right > after installation, should everyone get an option for it into the > install screen? SELinux isn't just a specific setting... It's a bit too big. It's a feature 38.7% of systems in smolt have disabled... Removing that combobox is like telling this 38.7% (203150) "know what... the other 61.3% (321879) don't like *seeing* choice of disabling SELinux during install... You'll have to do it after install." > > Let's be less selfish guys and look at the bigger picture. That's what I do. :) > > If you know you don't need SELinux for whatever reason you can simply > disable it after installation (or in kickstart if you do automated > installations). > > If you are a Fedora developer and disable it by default to "develop" > packages than I honestly think you are poorly executing your task. > You should set it to permissive only when you get some "access denied" > problem while testing the specific changes, and as soon as you are happy > with it and ready to push a new package, you should FIRST set? SELinux > back to Enalbled and (working with Dan if necessary) make sure your > package pass again all your tests. > Not doing so you are making a disservice to the Fedora community, > because if you don't test with SELinux on then you don't know if your > stuff will work with it enabled, and you will create a bad experience > for other developers and users. Agree. It's like building a package and not checking if it works on x86... But I'm not a Fedora developer (yet). > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From alexl at users.sourceforge.net Fri Jul 4 20:45:38 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 13:45:38 -0700 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> (Xavier Lamien's message of "Fri\, 4 Jul 2008 18\:09\:51 +0200") References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> Message-ID: >>>>> "XL" == Xavier Lamien writes: XL> On Fri, Jul 4, 2008 at 4:14 PM, drago01 wrote: >> Tryed to rebuild beagle in rawhide failed with: >> http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log >> XL> Fixed, Could you give a try with those packages XL> http://koji.fedoraproject.org/koji/taskinfo?taskID=696567 I have the same issue with compiling f-spot: configure: error: Package requirements (libgnome-2.0 >= 2.2 libgnomeui-2.0 >= 2.2 libexif >= 0.5.7 libexif < 0.7.0 glade-sharp-2.0 >= 2.8 gnome-vfs-sharp-2.0 >= 2.8 gtk+-2.0 >= 2.6 mono >= 1.1.7 mono-cairo >= 1.2.4) were not met: Variable 'libdir' not defined in '/usr/lib64/pkgconfig/gnome-vfs-sharp-2.0.pc' http://koji.fedoraproject.org/koji/taskinfo?taskID=696144 Since the version of gnome-sharp in rawhide is already broken, can you just do a standard (non-scratch) build of gnome-sharp so it available for other packages to build against? Otherwise you'd need to download the scratch build, and do a local mock build and replace the gnome-sharp package locally which is a bit of pain. Thanks, Alex From alan at redhat.com Fri Jul 4 20:57:07 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 4 Jul 2008 16:57:07 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215199155.3816.33.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> <1215199155.3816.33.camel@roadrunner.itnet.am> Message-ID: <20080704205707.GA14103@devserv.devel.redhat.com> On Sat, Jul 05, 2008 at 12:19:14AM +0500, Suren Karapetyan wrote: > That's the most horrible direction of reasoning. Its a very sane one > With that we can easily remove every option from installation process. > (What's the point in asking what packages You want... You can > install/remove later... What's the point in changing default > partitioning... it's OK). The partitioning needs to be queried because the layout cannot easily be adjusted. The packages likewise although it is become less so and as the post install tools get better there is a good argument for pushing that choice ot later. > SELinux isn't just a specific setting... It's a bit too big. > It's a feature 38.7% of systems in smolt have disabled... > Removing that combobox is like telling this 38.7% (203150) > "know what... the other 61.3% (321879) don't like *seeing* choice of That's meaningless. What percentage of those systems are running with the correct choice for their system ? From surenkarapetyan at gmail.com Fri Jul 4 21:03:24 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 05 Jul 2008 02:03:24 +0500 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080704205707.GA14103@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> <1215199155.3816.33.camel@roadrunner.itnet.am> <20080704205707.GA14103@devserv.devel.redhat.com> Message-ID: <1215205404.3816.39.camel@roadrunner.itnet.am> On Fri, 2008-07-04 at 16:57 -0400, Alan Cox wrote: > On Sat, Jul 05, 2008 at 12:19:14AM +0500, Suren Karapetyan wrote: > > That's the most horrible direction of reasoning. > > Its a very sane one > > > With that we can easily remove every option from installation process. > > (What's the point in asking what packages You want... You can > > install/remove later... What's the point in changing default > > partitioning... it's OK). > > The partitioning needs to be queried because the layout cannot easily be > adjusted. The packages likewise although it is become less so and as the > post install tools get better there is a good argument for pushing that > choice ot later. > > > SELinux isn't just a specific setting... It's a bit too big. > > It's a feature 38.7% of systems in smolt have disabled... > > Removing that combobox is like telling this 38.7% (203150) > > "know what... the other 61.3% (321879) don't like *seeing* choice of > > That's meaningless. What percentage of those systems are running with > the correct choice for their system ? > That's a classic case of deciding what's best for the user instead of asking him... Anyway... I tried to explain why I think the option must be there. I'm done now. ;-) From laxathom at fedoraproject.org Fri Jul 4 21:22:12 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 4 Jul 2008 23:22:12 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> Message-ID: <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> On Fri, Jul 4, 2008 at 10:45 PM, Alex Lancaster wrote: > >>>>> "XL" == Xavier Lamien writes: > > XL> On Fri, Jul 4, 2008 at 4:14 PM, drago01 wrote: > >> Tryed to rebuild beagle in rawhide failed with: > >> http://koji.fedoraproject.org/koji/getfile?taskID=696312&name=build.log > >> > > XL> Fixed, Could you give a try with those packages > XL> http://koji.fedoraproject.org/koji/taskinfo?taskID=696567 > > I have the same issue with compiling f-spot: > > configure: error: Package requirements (libgnome-2.0 >= 2.2 > libgnomeui-2.0 >= 2.2 libexif >= 0.5.7 libexif < 0.7.0 glade-sharp-2.0 >= > 2.8 gnome-vfs-sharp-2.0 >= 2.8 gtk+-2.0 >= 2.6 mono >= 1.1.7 mono-cairo >= > 1.2.4) were not met: > Variable 'libdir' not defined in > '/usr/lib64/pkgconfig/gnome-vfs-sharp-2.0.pc' > > http://koji.fedoraproject.org/koji/taskinfo?taskID=696144 > > Since the version of gnome-sharp in rawhide is already broken, can you > just do a standard (non-scratch) build of gnome-sharp so it available > for other packages to build against? > Done -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at redhat.com Fri Jul 4 23:36:05 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 05 Jul 2008 01:36:05 +0200 Subject: Request to re-add option to disable SELinux References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <20080702210958.GA27060@devserv.devel.redhat.com> <1215063368.4735.6.camel@optimus> Message-ID: <5oo2k5x847.ln2@ppp1053.in.ipex.cz> On 2008-07-03, 05:36 GMT, Dave Airlie wrote: > Relying on users to mail us the contents of some pop-up dialog > box is ass. Ask Dr. Watson. With the XML-RPC being available, I would think that something similar to what bug-buddy does -- i.e., automatical creation of a bug by pressing one button, should be possible. Of course, it requires some bug triaging before Dan even sees the bug, but it should be doable. Best, Mat?j From mcepl at redhat.com Fri Jul 4 23:43:30 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 05 Jul 2008 01:43:30 +0200 Subject: Request to re-add option to disable SELinux References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> <1215099725.8001.17.camel@scrappy.miketc.com> Message-ID: <26p2k5x847.ln2@ppp1053.in.ipex.cz> On 2008-07-03, 15:42 GMT, Mike Chambers wrote: > They get a little question stating this program wants to run, > do you give it permission. And yes, that's the reason why Vista is still totally broken security-wise. Before even thinking about yes/no dialog, read http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf and other things on http://www.cs.auckland.ac.nz/~pgut001/ Best, Mat?j From arjan at infradead.org Fri Jul 4 23:51:16 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 4 Jul 2008 16:51:16 -0700 Subject: Request to re-add option to disable SELinux In-Reply-To: <5oo2k5x847.ln2@ppp1053.in.ipex.cz> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <20080702210958.GA27060@devserv.devel.redhat.com> <1215063368.4735.6.camel@optimus> <5oo2k5x847.ln2@ppp1053.in.ipex.cz> Message-ID: <20080704165116.61f93bec@infradead.org> On Sat, 05 Jul 2008 01:36:05 +0200 Matej Cepl wrote: > On 2008-07-03, 05:36 GMT, Dave Airlie wrote: > > Relying on users to mail us the contents of some pop-up dialog > > box is ass. Ask Dr. Watson. > > With the XML-RPC being available, I would think that something > similar to what bug-buddy does -- i.e., automatical creation of > a bug by pressing one button, should be possible. Of course, it > requires some bug triaging before Dan even sees the bug, but it > should be doable. > sounds like something similar to kerneloops.org could be in place.... -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From alexl at users.sourceforge.net Sat Jul 5 00:42:44 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 17:42:44 -0700 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> (Xavier Lamien's message of "Fri\, 4 Jul 2008 23\:22\:12 +0200") References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> Message-ID: >>>>> "XL" == Xavier Lamien writes: [...] >> http://koji.fedoraproject.org/koji/taskinfo?taskID=696144 >> Since the version of gnome-sharp in rawhide is already broken, can >> you just do a standard (non-scratch) build of gnome-sharp so it >> available for other packages to build against? XL> Done Xavier, thanks. That fixes the .pc file issue, but f-spot still won't compile against gnome-sharp-2.20, because for some reason it doesn't provide gtkhtml anymore: checking for GTKHTML_SHARP... configure: error: Package requirements (gtkhtml-sharp-3.14 >= 2.19.90) were not met: No package 'gtkhtml-sharp-3.14' found http://koji.fedoraproject.org/koji/getfile?taskID=697279&name=build.log Looking at the provides for the new package. It appears that gtkhtml is now longer provided. gnome-sharp = 2.20.0-2.fc10 libgnomesharpglue-2.so mono(art-sharp) = 2.20.0.0 mono(gconf-sharp) = 2.20.0.0 mono(gconf-sharp-peditors) = 2.20.0.0 mono(gconfsharp-schemagen) = 0.0.0.0 mono(gnome-sharp) = 2.20.0.0 mono(gnome-vfs-sharp) = 2.20.0.0 mono(policy.2.16.art-sharp) = 0.0.0.0 mono(policy.2.16.gconf-sharp) = 0.0.0.0 mono(policy.2.16.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.16.gnome-sharp) = 0.0.0.0 mono(policy.2.16.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.4.art-sharp) = 0.0.0.0 mono(policy.2.4.gconf-sharp) = 0.0.0.0 mono(policy.2.4.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.4.gnome-sharp) = 0.0.0.0 mono(policy.2.4.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.6.art-sharp) = 0.0.0.0 mono(policy.2.6.gconf-sharp) = 0.0.0.0 mono(policy.2.6.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.6.gnome-sharp) = 0.0.0.0 mono(policy.2.6.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.8.art-sharp) = 0.0.0.0 mono(policy.2.8.gconf-sharp) = 0.0.0.0 mono(policy.2.8.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.8.gnome-sharp) = 0.0.0.0 mono(policy.2.8.gnome-vfs-sharp) = 0.0.0.0 (http://koji.fedoraproject.org/koji/rpminfo?rpmID=647543) Is this intentional? Or gtkhtml now provided by a different package? In the 2.16 gnome-sharp package gtkhtml was provided: gnome-sharp = 2.16.1-3.fc10 libgnomesharpglue-2.so libvtesharpglue-2.so mono(art-sharp) = 2.16.0.0 mono(gconf-sharp) = 2.16.0.0 mono(gconf-sharp-peditors) = 2.16.0.0 mono(gconfsharp-schemagen) = 0.0.0.0 mono(gnome-sharp) = 2.16.0.0 mono(gnome-vfs-sharp) = 2.16.0.0 mono(gtkhtml-sharp) = 2.16.0.0 mono(policy.2.4.art-sharp) = 0.0.0.0 mono(policy.2.4.gconf-sharp) = 0.0.0.0 mono(policy.2.4.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.4.gnome-sharp) = 0.0.0.0 mono(policy.2.4.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.4.gtkhtml-sharp) = 0.0.0.0 mono(policy.2.4.rsvg-sharp) = 0.0.0.0 mono(policy.2.4.vte-sharp) = 0.0.0.0 mono(policy.2.6.art-sharp) = 0.0.0.0 mono(policy.2.6.gconf-sharp) = 0.0.0.0 mono(policy.2.6.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.6.gnome-sharp) = 0.0.0.0 mono(policy.2.6.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.6.gtkhtml-sharp) = 0.0.0.0 mono(policy.2.6.rsvg-sharp) = 0.0.0.0 mono(policy.2.6.vte-sharp) = 0.0.0.0 mono(policy.2.8.art-sharp) = 0.0.0.0 mono(policy.2.8.gconf-sharp) = 0.0.0.0 mono(policy.2.8.gconf-sharp-peditors) = 0.0.0.0 mono(policy.2.8.gnome-sharp) = 0.0.0.0 mono(policy.2.8.gnome-vfs-sharp) = 0.0.0.0 mono(policy.2.8.gtkhtml-sharp) = 0.0.0.0 mono(policy.2.8.rsvg-sharp) = 0.0.0.0 mono(policy.2.8.vte-sharp) = 0.0.0.0 mono(rsvg-sharp) = 2.16.0.0 mono(vte-sharp) = 2.16.0.0 (http://koji.fedoraproject.org/koji/rpminfo?rpmID=601424) If gtkhtml-sharp isn't packaged we need to get it into review pronto. Alex From gnomeuser at gmail.com Sat Jul 5 01:24:24 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 5 Jul 2008 03:24:24 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> Message-ID: <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> 2008/7/5 Alex Lancaster : > > If gtkhtml-sharp isn't packaged we need to get it into review pronto. Agreed, provide me with the review ticket and I will waste no time. I am happy to see work going on to improve Mono on Fedora. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at users.sourceforge.net Sat Jul 5 01:30:36 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 18:30:36 -0700 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: (Alex Lancaster's message of "Fri\, 04 Jul 2008 17\:42\:44 -0700") References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> Message-ID: >>>>> "AL" == Alex Lancaster writes: [...] AL> Is this intentional? Or gtkhtml now provided by a different AL> package? In the 2.16 gnome-sharp package gtkhtml was provided: AL> If gtkhtml-sharp isn't packaged we need to get it into review AL> pronto. OK, looking into the .spec file and the sources for gnome-sharp, it seems that gtkhtml has been moved to a new package: gnome-desktop-sharp. This kind of things really should be noted in your %changelog as well as in the spec file as it makes a big difference for other packages, in addition the description: %description This package provides a library that allows you to build fully native graphical GNOME applications using Mono. gnome-sharp extends gtk-sharp2 and adds bindings for gconf, libgnome, gnome-vfs, libart, gtkhtml, librsvg, and vte. should be modified to remove gtkhtml and anything else that has been moved into gnome-desktop-sharp. This is why it's critical when you upgrade a core component of a mono stack in a major API/ABI bump (e.g. from 2.16 -> 2.20) that it needs to be announced in advance and co-ordinated amongst the set of maintainers of the mono "stack". This is much like KDE, GNOME, the whole stack needs to be updated as group because there is so much intermodule dependencies. Unfortunately (unlike GNOME) it appears that there are currently no Red Hat engineers assigned to maintain the mono stack as a group (probably because it isn't shipped in RHEL), nor is there a community SIG like there is for KDE. So maintaining the core mono stack currently seems to be done in an adhoc way, maintainer by maintainer, package by package. Alex From alexl at users.sourceforge.net Sat Jul 5 01:46:16 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 18:46:16 -0700 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> (David Nielsen's message of "Sat\, 5 Jul 2008 03\:24\:24 +0200") References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> Message-ID: >>>>> "DN" == David Nielsen writes: DN> 2008/7/5 Alex Lancaster : >> >> If gtkhtml-sharp isn't packaged we need to get it into review >> pronto. DN> Agreed, provide me with the review ticket and I will waste no DN> time. I am happy to see work going on to improve Mono on Fedora. There's no package review for gnome-desktop-sharp (which is actually where gtkhtml was moved to after 2.19/2.20) submitted by anyone as yet. If you want to put together a package (I don't really use mono myself much), I'll be happy to review it. This package was created only after gnome-sharp-2.20 was released. Source here: http://ftp.gnome.org/pub/gnome/sources/gnome-desktop-sharp/2.20/ Alex From alexl at users.sourceforge.net Sat Jul 5 04:59:07 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 21:59:07 -0700 Subject: f-spot is orphaned: in danger of being removed from Fedora Message-ID: f-spot is currently orphaned and is scheduled to be deleted if it doesn't build from source: https://bugzilla.redhat.com/show_bug.cgi?id=449506 One of the reasons it's currently failing to build is because of the gnome-sharp issue detailed in this thread: http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html I'm working on getting this to build because it requires a new unpackaged gnome-desktop-sharp package But in the long-term I don't have time to be the primary maintainer, so if somebody else would like to step up to be primary maintainer that would be great. Alex From dev at nigelj.com Sat Jul 5 05:08:44 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 05 Jul 2008 17:08:44 +1200 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: References: Message-ID: <486F01DC.4090008@nigelj.com> Alex Lancaster wrote: > f-spot is currently orphaned and is scheduled to be deleted if it > doesn't build from source: > > https://bugzilla.redhat.com/show_bug.cgi?id=449506 > > One of the reasons it's currently failing to build is because of the > gnome-sharp issue detailed in this thread: > > http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html > > I'm working on getting this to build because it requires a new > unpackaged gnome-desktop-sharp package But in the long-term I don't > have time to be the primary maintainer, so if somebody else would like > to step up to be primary maintainer that would be great. > Actually, I'd noticed this too, I'm willing to be a primary maintainer, and I was actually looking at getting gnome-desktop-sharp done, but if you already have that's fine by me. - Nigel > Alex > > > > From alexl at users.sourceforge.net Sat Jul 5 05:14:43 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jul 2008 22:14:43 -0700 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: <486F01DC.4090008@nigelj.com> (Nigel Jones's message of "Sat\, 05 Jul 2008 17\:08\:44 +1200") References: <486F01DC.4090008@nigelj.com> Message-ID: >>>>> "NJ" == Nigel Jones writes: [...] NJ> Alex Lancaster wrote: >> I'm working on getting this to build because it requires a new >> unpackaged gnome-desktop-sharp package But in the long-term I don't >> have time to be the primary maintainer, so if somebody else would >> like to step up to be primary maintainer that would be great. >> NJ> Actually, I'd noticed this too, I'm willing to be a primary NJ> maintainer, and I was actually looking at getting NJ> gnome-desktop-sharp done, but if you already have that's fine by NJ> me. I was only going package gnome-desktop-sharp myself as a last resort. Actually, I would prefer just to review it if you could package it, that would be great. I've reviewed a few mono packages but I don't really use mono myself, so that's why I'd prefer that somebody else be the maintainer. Alex From laxathom at fedoraproject.org Sat Jul 5 06:16:58 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 5 Jul 2008 08:16:58 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <1215176875.17856.76.camel@localhost.localdomain> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> Message-ID: <62bc09df0807042316p3a639d19o8b6816761479c222@mail.gmail.com> On Sat, Jul 5, 2008 at 3:46 AM, Alex Lancaster wrote: > >>>>> "DN" == David Nielsen writes: > > DN> 2008/7/5 Alex Lancaster : > >> > >> If gtkhtml-sharp isn't packaged we need to get it into review > >> pronto. > > DN> Agreed, provide me with the review ticket and I will waste no > DN> time. I am happy to see work going on to improve Mono on Fedora. > > There's no package review for gnome-desktop-sharp (which is actually > where gtkhtml was moved to after 2.19/2.20) submitted by anyone as > yet. If you want to put together a package (I don't really use mono > myself much), I'll be happy to review it. > > This package was created only after gnome-sharp-2.20 was released. > Source here: > > http://ftp.gnome.org/pub/gnome/sources/gnome-desktop-sharp/2.20/ > > Correct, gtkhtml has been removed from gnome-sharp and it is noted in the spec file as well but, yeah not in the changelog, my bad to also forget added it in the changelog. I'm already work to provide gnome-desktop-sharp quickly to fix this. the review request will be spawn in the next few hours. Feel free to bug me on this. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnomeuser at gmail.com Sat Jul 5 09:10:37 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 5 Jul 2008 11:10:37 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <62bc09df0807042316p3a639d19o8b6816761479c222@mail.gmail.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <486E2CEB.7060608@nigelj.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> <62bc09df0807042316p3a639d19o8b6816761479c222@mail.gmail.com> Message-ID: <1dedbbfc0807050210v68a27580i8df7b5b2c59eb523@mail.gmail.com> 5. jul. 2008 08.16 skrev Xavier Lamien : > > Correct, > gtkhtml has been removed from gnome-sharp and it is noted in the spec file > as well but, > yeah not in the changelog, my bad to also forget added it in the changelog. > I'm already work to provide gnome-desktop-sharp quickly to fix this. the > review request will be spawn in the next few hours. > > Feel free to bug me on this. > This would probably have been good information to have in the mail announcing this version bump so maintainers would have minimal trouble. Regardless it seems to me that we are starting to need a Mono SIG to coordinate all this. I have previously offered free reviews for Mono packages, that offer still stands, I don't however feel I am a good maintainer so I would rather not take that role. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sat Jul 5 09:25:11 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 5 Jul 2008 09:25:11 +0000 (UTC) Subject: rawhide report: 20080705 changes Message-ID: <20080705092511.8F1F9209D8E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080704/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080705/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package dbus-java Java implementation of the DBus protocol New package gnome-lirc-properties Infrared Remote Controls setup tool New package libfonts TrueType Font Layouting New package lxterminal Desktop-independent VTE-based terminal emulator New package perl-AnyEvent Framework for multiple event loops New package perl-Term-ReadLine-Gnu Perl extension for the GNU Readline/History Library New package s3cmd Tool for accessing Amazon Simple Storage Service New package sleuthkit The Sleuth Kit (TSK) Updated Packages: afflib-3.2.3-1.fc10 ------------------- * Fri Jul 4 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.3-1 - Update to 3.2.3 * Thu Jun 26 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.1-4 - Explicitely disable s3 * Thu Jun 26 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.1-3 - Disable s3 autoconf-2.62-4.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Stepan Kasal 2.62-4 - add a quick fix for #449944 - remove Requires: mktemp, imake, grep; these are required by the generated configure, but not by Autoconf. - switch on make check beagle-0.3.7-7.fc10 ------------------- * Fri Jul 4 18:00:00 2008 Adel Gadllah - 0.3.7-7 - Rebuild for new gnome-sharp bluez-utils-3.35-2.fc10 ----------------------- * Fri Jul 4 18:00:00 2008 - Bastien Nocera - 3.35-2 - Re-add hidd cairo-dock-1.6.1-0.1.svn1172_trunk.fc10 --------------------------------------- * Sat Jul 5 18:00:00 2008 Mamoru Tasaka - rev. 1172 coreutils-6.12-5.fc10 --------------------- * Fri Jul 4 18:00:00 2008 Ondrej Vasik - 6.12-5 - fix authors for basename and echo - fix who info pages, print last runlevel only for printable chars curl-7.18.2-3.fc10 ------------------ * Fri Jul 4 18:00:00 2008 Jindrich Novy 7.18.2-3 - enable support for libssh2 (#453958) dblatex-0.2.9-2.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Alex Lancaster - 0.2.9-2 - BR: texlive-xetex -> tex(xetex) for F-10 and later fbida-2.07-2.fc10 ----------------- * Fri Jul 4 18:00:00 2008 Adrian Reber - 2.07-2 - applied patch from Ville Skytt?? to fix "fbida: empty debuginfo package" (#453998) fbpanel-4.12-6.fc10 ------------------- * Fri Jul 4 18:00:00 2008 Stefan Posdzich - 4.12-6 - Add icon.patch to bring the Fedora icon to the panel - Modified the existing apps in the Panel (like emacs -> gedit) ffcall-1.10-2.20080704cvs.fc10 ------------------------------ * Fri Jul 4 18:00:00 2008 Gerard Milmeister - 1.10-2.20080704cvs - update to cvs 20080704 - support for ppc64 fuse-smb-0.8.7-4.fc10 --------------------- * Thu Jul 3 18:00:00 2008 Marcin Zajaczkowski - 0.8.7-4 - added workaround for problem with multi-threaded operations and samba 3.2 (F9+) - bug 445978 glibmm24-2.17.0-1.fc10 ---------------------- * Thu Jul 3 18:00:00 2008 Denis Leroy - 2.17.0-1 - Update to unstable branch 2.17 gnome-sharp-2.20.0-2.fc10 ------------------------- gtkimageview-1.6.1-1.fc10 ------------------------- * Fri Jul 4 18:00:00 2008 Nils Philippsen - 1.6.1-1 - version 1.6.1 gtkmm24-2.13.1-1.fc10 --------------------- * Fri Jul 4 18:00:00 2008 Denis Leroy - 2.13.1-1 - Update to version 2.13.1 hardinfo-0.4.2.3-6.fc10 ----------------------- * Fri Jul 4 18:00:00 2008 Adel Gadllah 0.4.2.3-6 - Rebuild for new gnutls jd-2.0.0-0.7.svn2170_trunk.fc10 ------------------------------- * Sat Jul 5 18:00:00 2008 Mamoru Tasaka - rev 2170 jetty-5.1.14-1jpp.2.fc10 ------------------------ * Fri Jul 4 18:00:00 2008 Jeff Johnston 5.1.14-1jpp.2 - Security patch - Resolves #417401, #417411, #417391 * Wed Jun 25 18:00:00 2008 Jeff Johnston 5.1.14-1jpp.1 - Upgrade to 5.1.14 source tarball for Fedora libprelude-0.9.17.2-1.fc10 -------------------------- * Fri Jul 4 18:00:00 2008 Steve Grubb - 0.9.17.2-1 - Update to latest upstream and update perl bindings generation (#453932) libpreludedb-0.9.14.1-4.fc10 ---------------------------- * Fri Jul 4 18:00:00 2008 Steve Grubb - 0.9.14.1-4 - Fix perl bindings (#453935) librdmacm-1.0.7-1.fc10 ---------------------- lxpanel-0.3.8-1.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Sebastian Vahl 0.3.8-1 - new upstream version: 0.3.8 - new BR in this version: intltool namazu-2.0.18-4.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Akira TAGOH - 2.0.18-4 - Add nkf, kakasi and mecab to BR. (#449186) ocaml-bitmatch-1.9.4-1.fc10 --------------------------- * Fri Jul 4 18:00:00 2008 Richard W.M. Jones - 1.9.4-1 - New upstream release 1.9.4. * Fri Jul 4 18:00:00 2008 Richard W.M. Jones - 1.9.3-2 - New upstream release 1.9.3. - Don't build CIL tools unless we have CIL. * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 1.9.2-3 - +BR ocaml-extlib-devel. * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 1.9.2-2 - Force rebuild, forgot sources first time. * Tue Jul 1 18:00:00 2008 Richard W.M. Jones - 1.9.2-1 - New upstream release 1.9.2. - Include C tools (requiring CIL) in a separate subpackage. pcre-7.3-4.fc10 --------------- * Fri Jul 4 18:00:00 2008 Tomas Hoger - 7.3-4 - Apply Tavis Ormandy's patch for CVE-2008-2371. python-html2text-2.30-1.1 ------------------------- * Fri Jul 4 18:00:00 2008 Thorsten Leemhuis - 2.30-1 - update to 2.30 (GPLv3 now) python-pyblock-0.31-4 --------------------- * Fri Jul 4 18:00:00 2008 Peter Jones - 0.31-4 - Move dmraid dep to point at dmraid-libs. * Thu Apr 17 18:00:00 2008 Jeremy Katz - 0.31-3 - Own the doc dir (#363351) qlandkarte-0.7.3-1.fc10 ----------------------- * Fri Jul 4 18:00:00 2008 Dan Horak 0.7.3-1 - upgrade to 0.7.3 rss2email-2.63-1.1 ------------------ * Fri Jul 4 18:00:00 2008 Thorsten Leemhuis - 2.63-1 - update to 2.63 (GPLv3 now) selinux-policy-3.4.2-11.fc10 ---------------------------- * Thu Jul 3 18:00:00 2008 Dan Walsh 3.4.2-11 - Allow ypbind apps to net_bind_service sgml-common-0.6.3-25.fc10 ------------------------- * Tue Jul 1 18:00:00 2008 Ondrej Vasik 0.6.3-25 - mark xmlcatalog config(noreplace) to prevent overwriting of the content, move it to sysconfdir and make symlink for it to silence rpmlint sudo-1.6.9p17-1.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Peter Vrabec 1.6.9p17-1 - upgrade trac-spamfilter-plugin-0.2.1-0.2.20080603svn6990.fc10 ----------------------------------------------------- * Fri Jul 4 18:00:00 2008 Jesse Keating - 0.2.1-0.2.20080603svn6990 - R spambayes ufraw-0.13-6.fc10 ----------------- * Fri Jul 4 18:00:00 2008 Nils Philippsen - 0.13-6 - rebuild with gtkimageview-1.6.1 Summary: Added Packages: 8 Removed Packages: 0 Modified Packages: 35 Broken deps for i386 ---------------------------------------------------------- banshee-1.0.0-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.i386 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.i386 requires fonts-chinese rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- banshee-1.0.0-1.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.x86_64 requires fonts-chinese rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tomboy-0.11.0-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- banshee-1.0.0-1.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 banshee-1.0.0-1.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gbrainy-0.70-1.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 gnome-subtitles-0.8-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc requires fonts-chinese rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:openoffice.org-langpack-ko_KR-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-korean 1:openoffice.org-langpack-zh_CN-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese 1:openoffice.org-langpack-zh_TW-3.0.0-0.0.20.1.fc10.ppc64 requires fonts-chinese perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From dev at nigelj.com Sat Jul 5 09:33:31 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 05 Jul 2008 21:33:31 +1200 Subject: rawhide report: 20080705 changes In-Reply-To: <20080705092511.8F1F9209D8E@releng1.fedora.phx.redhat.com> References: <20080705092511.8F1F9209D8E@releng1.fedora.phx.redhat.com> Message-ID: <486F3FEB.5020900@nigelj.com> Rawhide wrote: > Broken deps for i386 > ---------------------------------------------------------- > banshee-1.0.0-1.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 > banshee-1.0.0-1.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 > (and other arches), looks like I just missed the mashing of today's rawhide, but it has been rebuilt :) - Nigel From laxathom at fedoraproject.org Sat Jul 5 09:49:13 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 5 Jul 2008 11:49:13 +0200 Subject: F-9 Updates : gnome-sharp and gtk-sharp2 In-Reply-To: <1dedbbfc0807050210v68a27580i8df7b5b2c59eb523@mail.gmail.com> References: <62bc09df0807040555s22636656s525e39b265da872d@mail.gmail.com> <62bc09df0807040909j63517a39p72937f5adf375b7c@mail.gmail.com> <62bc09df0807041422s3b1c13ecqd2f00d949eca27de@mail.gmail.com> <1dedbbfc0807041824m78963492ldf470f95a392c884@mail.gmail.com> <62bc09df0807042316p3a639d19o8b6816761479c222@mail.gmail.com> <1dedbbfc0807050210v68a27580i8df7b5b2c59eb523@mail.gmail.com> Message-ID: <62bc09df0807050249k7c1c1c0eqb1333a335a798930@mail.gmail.com> 2008/7/5 David Nielsen : > > > 5. jul. 2008 08.16 skrev Xavier Lamien : > >> >> Correct, >> gtkhtml has been removed from gnome-sharp and it is noted in the spec file >> as well but, >> yeah not in the changelog, my bad to also forget added it in the >> changelog. >> I'm already work to provide gnome-desktop-sharp quickly to fix this. the >> review request will be spawn in the next few hours. >> >> Feel free to bug me on this. >> > > This would probably have been good information to have in the mail > announcing this version bump so maintainers would have minimal trouble. > Agreed Regardless it seems to me that we are starting to need a Mono SIG to coordinate all this. +1 > I have previously offered free reviews for Mono packages, that offer still > stands, I don't however feel I am a good maintainer so I would rather not > take that role. > > Gnome-desktop-sharp is now available for review at : https://bugzilla.redhat.com/show_bug.cgi?id=454134 it shipped with all optional assemblies (including nautilusburn, wnck, vte, etc) -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From caolanm at redhat.com Sat Jul 5 10:16:12 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 05 Jul 2008 11:16:12 +0100 Subject: packaging a package with a duplicate name ? Message-ID: <1215252972.24189.5.camel@vain.rhgalway> I'm packaging jfreereport and one of the dependencies is a java package called "libxml", i.e. ?http://sourceforge.net/project/showfiles.php?group_id=51669 "LibXML is a namespace aware SAX-Parser" and is no relation to the c libxml/libxml2. What's an acceptable name for the package given that "libxml" is taken, libxml-java ? libxml-jfreereport ? C. From dwmw2 at infradead.org Sat Jul 5 11:47:24 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Jul 2008 12:47:24 +0100 Subject: [PATCH] cross-compilation for binutils. Message-ID: <1215258444.3189.87.camel@shinybook.infradead.org> Jakub, please could we apply this patch to the binutils specfile? It provides an optional %{binutils_target} macro which, when defined, will generate a cross-binutils package. But when it's _not_ defined, as it won't be for your builds or in the build system, it just builds a native binutils as before. This will make it easier for people to build cross-binutils based exactly on the the Fedora binutils packages. We'll then want to look at how best to get a set of cross-binutils packages into Fedora, without adversely affecting your workflow on the native binutils. The na?ve approach is just to _copy_ the binutils package to various new $ARCH-binutils packages. But hopefully the the infrastructure folks can come up with some trick in package CVS or in koji which will make it simpler than that. Index: binutils.spec =================================================================== RCS file: /cvs/pkgs/rpms/binutils/F-9/binutils.spec,v retrieving revision 1.132 diff -u -r1.132 binutils.spec --- binutils.spec 8 Apr 2008 14:06:03 -0000 1.132 +++ binutils.spec 5 Jul 2008 11:39:42 -0000 @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.18.50.0.6 Release: 2 License: GPLv3+ @@ -54,7 +62,7 @@ to consider using libelf instead of BFD. %prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -68,7 +76,7 @@ %patch7 -p0 -b .version~ %patch8 -p0 -b .pclmul~ -# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i\[3-7\]86/i[34567]86/g' */conf* @@ -80,24 +88,37 @@ sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure %build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +echo target is %{binutils_target} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target}" + SYSROOT="--with-sysroot=/usr/%{binutils_target}" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror \ + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info @@ -110,8 +131,9 @@ %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info* @@ -133,10 +155,6 @@ # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la -# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include ~;}' \ %ifarch %{ix86} x86_64 @@ -154,22 +172,36 @@ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h +%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang %clean rm -rf %{buildroot} +%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -200,12 +232,14 @@ if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native -%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if %isnative %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -215,8 +249,12 @@ %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native %changelog +* Sat Jul 5 2008 David Woodhouse 2.18.50.0.6-3 +- Add %%{binutils_target} macro to support building cross-binutils + * Tue Apr 8 2008 Jakub Jelinek 2.18.50.0.6-2 - backport .clmul -> .pclmul renaming -- dwmw2 @linux.intel.com From ivazqueznet at gmail.com Sat Jul 5 12:46:58 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 05 Jul 2008 08:46:58 -0400 Subject: packaging a package with a duplicate name ? In-Reply-To: <1215252972.24189.5.camel@vain.rhgalway> References: <1215252972.24189.5.camel@vain.rhgalway> Message-ID: <1215262018.6489.15.camel@ignacio.lan> On Sat, 2008-07-05 at 11:16 +0100, Caolan McNamara wrote: > I'm packaging jfreereport and one of the dependencies is a java package > called "libxml", > i.e. ?http://sourceforge.net/project/showfiles.php?group_id=51669 > "LibXML is a namespace aware SAX-Parser" and is no relation to the c > libxml/libxml2. What's an acceptable name for the package given that > "libxml" is taken, libxml-java ? libxml-jfreereport ? That's unfortunate that they decided to stomp on someone else's name. jfreereport-xml -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 5 12:53:21 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Jul 2008 14:53:21 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215258444.3189.87.camel@shinybook.infradead.org> (David Woodhouse's message of "Sat, 05 Jul 2008 12:47:24 +0100") References: <1215258444.3189.87.camel@shinybook.infradead.org> Message-ID: <87od5csda6.fsf@sheridan.bigo.ensc.de> David Woodhouse writes: > -CARGS=--enable-targets=i386-linux > +case %{binutils_target} in > + sparc*|ppc*|s390*) > + CARGS=--enable-64-bit-bfd > + ;; > + ia64*) > + CARGS=--enable-targets=i386-linux > + ;; > +esac Something like | --enable-targets=%_host should be added everytime to allow e.g. 'strip' to work on both native and on target binaries. This is required when building cross-rpms which are providing target and native binaries. > + SYSROOT="--with-sysroot=/usr/%{binutils_target}" Sysroot should be '/usr/%binutils_target/sys-root' (which is the value assumed by gcc). E.g. native binaries (e.g. the cross gcc) are usually under /usr/%binutils_target/bin and your sysroot would conflict with it. Enrico From dan at danny.cz Sat Jul 5 12:57:17 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 05 Jul 2008 14:57:17 +0200 Subject: packaging a package with a duplicate name ? In-Reply-To: <1215262018.6489.15.camel@ignacio.lan> References: <1215252972.24189.5.camel@vain.rhgalway> <1215262018.6489.15.camel@ignacio.lan> Message-ID: <1215262637.3473.6.camel@eagle.danny.cz> Ignacio Vazquez-Abrams p??e v So 05. 07. 2008 v 08:46 -0400: > On Sat, 2008-07-05 at 11:16 +0100, Caolan McNamara wrote: > > I'm packaging jfreereport and one of the dependencies is a java package > > called "libxml", > > i.e. ?http://sourceforge.net/project/showfiles.php?group_id=51669 > > "LibXML is a namespace aware SAX-Parser" and is no relation to the c > > libxml/libxml2. What's an acceptable name for the package given that > > "libxml" is taken, libxml-java ? libxml-jfreereport ? > > That's unfortunate that they decided to stomp on someone else's name. > > jfreereport-xml maybe all the libs from this project should be placed into the "jfreereport-" namespace Dan From dwmw2 at infradead.org Sat Jul 5 13:32:25 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Jul 2008 14:32:25 +0100 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <87od5csda6.fsf@sheridan.bigo.ensc.de> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> Message-ID: <1215264745.10393.837.camel@pmac.infradead.org> On Sat, 2008-07-05 at 14:53 +0200, Enrico Scholz wrote: > David Woodhouse writes: > > > -CARGS=--enable-targets=i386-linux > > +case %{binutils_target} in > > + sparc*|ppc*|s390*) > > + CARGS=--enable-64-bit-bfd > > + ;; > > + ia64*) > > + CARGS=--enable-targets=i386-linux > > + ;; > > +esac > > Something like > > | --enable-targets=%_host > > should be added everytime to allow e.g. 'strip' to work on both native > and on target binaries. This is required when building cross-rpms which > are providing target and native binaries. Is it really? You already have to use the appropriate compiler and linker for native vs. target binaries -- why can't you use the appropriate version of 'strip', too? And even if you _do_ need it, it sounds like that's a job for a 'binutils-multi' configured with --enable-targets=all. I'm not sure that, e.g., my i686-redhat-linux-gcc should also be able to strip native PowerPC binaries. > > > + SYSROOT="--with-sysroot=/usr/%{binutils_target}" > > Sysroot should be '/usr/%binutils_target/sys-root' (which is the value > assumed by gcc). E.g. native binaries (e.g. the cross gcc) are usually > under /usr/%binutils_target/bin and your sysroot would conflict with it. OK, I'll fix that. -- dwmw2 From snecklifter at gmail.com Sat Jul 5 13:32:51 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 5 Jul 2008 14:32:51 +0100 Subject: Kernel 2.6.25 (F8/F9) problem In-Reply-To: <200807021204.54804.jwilson@redhat.com> References: <1214991659.4240.32.camel@lesca.home.solinos.it> <200807021204.54804.jwilson@redhat.com> Message-ID: <364d303b0807050632t3b5c2d5dn77465624fb687051@mail.gmail.com> 2008/7/2 Jarod Wilson : > On Wednesday 02 July 2008 05:40:59 am Dario Lesca wrote: >> On this kind of server (HP ProLiant DL380 G5) >> >> > http://www.smolts.org/client/show/pub_e04ad1d7-e691-4b54-a3b6-1a5ff974d5b >> >d >> >> It's NOT possible install then use F9 and F8+update. >> >> This is a HP common server, since there is the problem for over a month, >> means that no one is using Fedora 8 + update or Fedora 9 on this kind of >> server. >> >> If someone was able to run Fedora 8 + Updates or Fedora 9 on these >> servers, please let me know how to do. > > Please file a bug. We do have DL380 G5 hardware here in the lab. It typically > gets used for RHEL testing, but I'm sure someone can get Fedora on one and > see what they can see. This hardware definitely needs to work come RHEL6 > time, so fixing it in Fedora sooner than later would be good... Please feel > free to add me (jwilson at redhat.com) to the cc list when you open the bug. With all due respect, the hardware _definitely_ needs to work with Fedora 9. I would suggest CC'ing the fedora unity bods (Bob & Karanrip) about this as and when it gets resolved so they can pull it into a re-spin. Regards -- Christopher Brown http://www.chruz.com From dwmw2 at infradead.org Sat Jul 5 13:33:49 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Jul 2008 14:33:49 +0100 Subject: packaging a package with a duplicate name ? In-Reply-To: <1215262018.6489.15.camel@ignacio.lan> References: <1215252972.24189.5.camel@vain.rhgalway> <1215262018.6489.15.camel@ignacio.lan> Message-ID: <1215264829.10393.840.camel@pmac.infradead.org> On Sat, 2008-07-05 at 08:46 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2008-07-05 at 11:16 +0100, Caolan McNamara wrote: > > I'm packaging jfreereport and one of the dependencies is a java package > > called "libxml", > > i.e. ?http://sourceforge.net/project/showfiles.php?group_id=51669 > > "LibXML is a namespace aware SAX-Parser" and is no relation to the c > > libxml/libxml2. What's an acceptable name for the package given that > > "libxml" is taken, libxml-java ? libxml-jfreereport ? > > That's unfortunate that they decided to stomp on someone else's name. It's unfortunate that Java folks feel they have to reimplement the world, regardless of the nomenclature they use. -- dwmw2 From dwmw2 at infradead.org Sat Jul 5 13:35:28 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Jul 2008 14:35:28 +0100 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <87od5csda6.fsf@sheridan.bigo.ensc.de> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> Message-ID: <1215264928.10393.842.camel@pmac.infradead.org> On Sat, 2008-07-05 at 14:53 +0200, Enrico Scholz wrote: > building cross-rpms which are providing target and native binaries. Oh, and... why in $DEITY's name would you be doing that? :) -- dwmw2 From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 5 14:10:51 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Jul 2008 16:10:51 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215264745.10393.837.camel@pmac.infradead.org> (David Woodhouse's message of "Sat, 05 Jul 2008 14:32:25 +0100") References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> Message-ID: <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> David Woodhouse writes: >> Something like >> >> | --enable-targets=%_host >> >> should be added everytime to allow e.g. 'strip' to work on both native >> and on target binaries. This is required when building cross-rpms which >> are providing target and native binaries. > > Is it really? You already have to use the appropriate compiler and > linker for native vs. target binaries -- why can't you use the > appropriate version of 'strip', too? rpm magic; final %__spec_install_post makes something like + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive arm-iwmmxt-linux-gnueabi-strip + /usr/lib/rpm/redhat/brp-strip-comment-note arm-iwmmxt-linux-gnueabi-strip arm-iwmmxt-linux-gnueabi-objdump + and does not differ between target and native binaries. > And even if you _do_ need it, it sounds like that's a job for a > 'binutils-multi' configured with --enable-targets=all. I'm not sure > that, e.g., my i686-redhat-linux-gcc should also be able to strip > native PowerPC binaries. There seems to be some overhead when adding 64 bit target support for 32 bit hosts https://bugzilla.redhat.com/show_bug.cgi?id=63618 Enrico From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 5 14:21:29 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 05 Jul 2008 16:21:29 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215264928.10393.842.camel@pmac.infradead.org> (David Woodhouse's message of "Sat, 05 Jul 2008 14:35:28 +0100") References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264928.10393.842.camel@pmac.infradead.org> Message-ID: <87fxqos97a.fsf@sheridan.bigo.ensc.de> David Woodhouse writes: >> building cross-rpms which are providing target and native binaries. > > Oh, and... why in $DEITY's name would you be doing that? :) For the same reasons why I prefer RPM based distributions to e.g. Gentoo. See https://www.cvg.de/people/ensc/cross/ for a cross-rpm with full dependencies. Enrico From dwmw2 at infradead.org Sat Jul 5 14:52:27 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 Jul 2008 15:52:27 +0100 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> Message-ID: <1215269547.10393.848.camel@pmac.infradead.org> On Sat, 2008-07-05 at 16:10 +0200, Enrico Scholz wrote: > David Woodhouse writes: > > >> Something like > >> > >> | --enable-targets=%_host > >> > >> should be added everytime to allow e.g. 'strip' to work on both native > >> and on target binaries. This is required when building cross-rpms which > >> are providing target and native binaries. > > > > Is it really? You already have to use the appropriate compiler and > > linker for native vs. target binaries -- why can't you use the > > appropriate version of 'strip', too? > > rpm magic; final %__spec_install_post makes something like > > + /usr/lib/rpm/redhat/brp-compress > + /usr/lib/rpm/redhat/brp-strip-static-archive arm-iwmmxt-linux-gnueabi-strip > + /usr/lib/rpm/redhat/brp-strip-comment-note arm-iwmmxt-linux-gnueabi-strip arm-iwmmxt-linux-gnueabi-objdump > + > > and does not differ between target and native binaries. Hm, OK. I suppose it doesn't hurt much. Updated patch then... Index: binutils.spec =================================================================== RCS file: /cvs/pkgs/rpms/binutils/F-9/binutils.spec,v retrieving revision 1.132 diff -u -r1.132 binutils.spec --- binutils.spec 8 Apr 2008 14:06:03 -0000 1.132 +++ binutils.spec 5 Jul 2008 14:51:20 -0000 @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.18.50.0.6 Release: 2 License: GPLv3+ @@ -54,7 +62,7 @@ to consider using libelf instead of BFD. %prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -68,7 +76,7 @@ %patch7 -p0 -b .version~ %patch8 -p0 -b .pclmul~ -# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i\[3-7\]86/i[34567]86/g' */conf* @@ -80,24 +88,37 @@ sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure %build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +echo target is %{binutils_target} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target} --enable-targets=%_host" + SYSROOT="--with-sysroot=/usr/%{binutils_target}/sys-root" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror \ + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info @@ -110,8 +131,9 @@ %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info* @@ -133,10 +155,6 @@ # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la -# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include ~;}' \ %ifarch %{ix86} x86_64 @@ -154,22 +172,36 @@ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h +%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang %clean rm -rf %{buildroot} +%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -200,12 +232,14 @@ if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native -%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if %isnative %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -215,8 +249,12 @@ %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native %changelog +* Sat Jul 5 2008 David Woodhouse 2.18.50.0.6-3 +- Add %%{binutils_target} macro to support building cross-binutils + * Tue Apr 8 2008 Jakub Jelinek 2.18.50.0.6-2 - backport .clmul -> .pclmul renaming -- dwmw2 From nicolas.mailhot at laposte.net Sat Jul 5 15:33:49 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 05 Jul 2008 17:33:49 +0200 Subject: packaging a package with a duplicate name ? In-Reply-To: <1215264829.10393.840.camel@pmac.infradead.org> References: <1215252972.24189.5.camel@vain.rhgalway> <1215262018.6489.15.camel@ignacio.lan> <1215264829.10393.840.camel@pmac.infradead.org> Message-ID: <1215272029.26901.1.camel@rousalka.okg> Le samedi 05 juillet 2008 ? 14:33 +0100, David Woodhouse a ?crit : > On Sat, 2008-07-05 at 08:46 -0400, Ignacio Vazquez-Abrams wrote: > > On Sat, 2008-07-05 at 11:16 +0100, Caolan McNamara wrote: > > > I'm packaging jfreereport and one of the dependencies is a java package > > > called "libxml", > > > i.e. ?http://sourceforge.net/project/showfiles.php?group_id=51669 > > > "LibXML is a namespace aware SAX-Parser" and is no relation to the c > > > libxml/libxml2. What's an acceptable name for the package given that > > > "libxml" is taken, libxml-java ? libxml-jfreereport ? > > > > That's unfortunate that they decided to stomp on someone else's name. > > It's unfortunate that Java folks feel they have to reimplement the > world, regardless of the nomenclature they use. You mean, unlike the perl or lisp guys? There is a lot of bad things to be said about Java but this particular failure is not Java-specific. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From alan at redhat.com Sat Jul 5 15:43:13 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 5 Jul 2008 11:43:13 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215205404.3816.39.camel@roadrunner.itnet.am> References: <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> <1215199155.3816.33.camel@roadrunner.itnet.am> <20080704205707.GA14103@devserv.devel.redhat.com> <1215205404.3816.39.camel@roadrunner.itnet.am> Message-ID: <20080705154313.GA20937@devserv.devel.redhat.com> On Sat, Jul 05, 2008 at 02:03:24AM +0500, Suren Karapetyan wrote: > > That's meaningless. What percentage of those systems are running with > > the correct choice for their system ? > > > That's a classic case of deciding what's best for the user instead of > asking him... No. That was not the question I asked. I asked what percentage of those systems are running the correct choice for the system. The point I'm trying to make is that most users have no idea what the correct risk/convenience trade off is for their system. They do not have the information or take the time to think systemically about it and make an informed decision. You can give users all the choice in the world but if they are confronted at install time with questions that they do not know the answer to then the result is not choice, it is randomness and a feeling of helplessness and embarrasment on the part of the user. Anyone with sufficient knowledge to make the assesment (and lots without) know how to turn it off later. Alan From shenson at redhat.com Sat Jul 5 16:39:12 2008 From: shenson at redhat.com (Scott Henson) Date: Sat, 05 Jul 2008 12:39:12 -0400 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: <486F01DC.4090008@nigelj.com> References: <486F01DC.4090008@nigelj.com> Message-ID: Nigel Jones wrote: > Alex Lancaster wrote: >> f-spot is currently orphaned and is scheduled to be deleted if it >> doesn't build from source: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=449506 >> >> One of the reasons it's currently failing to build is because of the >> gnome-sharp issue detailed in this thread: >> >> http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html >> >> I'm working on getting this to build because it requires a new >> unpackaged gnome-desktop-sharp package But in the long-term I don't >> have time to be the primary maintainer, so if somebody else would like >> to step up to be primary maintainer that would be great. >> > Actually, I'd noticed this too, I'm willing to be a primary maintainer, > and I was actually looking at getting gnome-desktop-sharp done, but if > you already have that's fine by me. > I would be willing to comaintain if you need some help. From ssorce at redhat.com Sat Jul 5 16:43:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 05 Jul 2008 12:43:20 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <20080705154313.GA20937@devserv.devel.redhat.com> References: <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> <1215199155.3816.33.camel@roadrunner.itnet.am> <20080704205707.GA14103@devserv.devel.redhat.com> <1215205404.3816.39.camel@roadrunner.itnet.am> <20080705154313.GA20937@devserv.devel.redhat.com> Message-ID: <1215276200.9532.59.camel@localhost.localdomain> On Sat, 2008-07-05 at 11:43 -0400, Alan Cox wrote: > On Sat, Jul 05, 2008 at 02:03:24AM +0500, Suren Karapetyan wrote: > > > That's meaningless. What percentage of those systems are running with > > > the correct choice for their system ? > > > > > That's a classic case of deciding what's best for the user instead of > > asking him... > > No. That was not the question I asked. I asked what percentage of those systems > are running the correct choice for the system. > > The point I'm trying to make is that most users have no idea what the correct > risk/convenience trade off is for their system. They do not have the information > or take the time to think systemically about it and make an informed decision. > > You can give users all the choice in the world but if they are confronted > at install time with questions that they do not know the answer to then the > result is not choice, it is randomness and a feeling of helplessness and > embarrasment on the part of the user. > > Anyone with sufficient knowledge to make the assesment (and lots without) > know how to turn it off later. I fully agree with this line of reasoning. Let's also try to make an example that should be easy to understand. A choice must always be (as much as possible) something that the user at least understand, the user may not care about, but understanding the question makes him confident he knows what he is doing. So if I ask: do you prefer apples or oranges ? The specific user may not care, or may not have a preference, but he clearly will understand the question and the problem space. In this case a random choice is acceptable. (For someone that is allergic to oranges or apples, the question is truly important too, and he knows exactly what to choose). Now if I ask: do you prefer foo or bar ? How can someone answer to this ? The only choice is random and not only the user feel confused about it, and helpless, he will also probably feel anxious about what is the right choice to make. The SELinux question is like the latter for most people, and although usually it seem bad to say, we actually know better what is the right default choice (security over all is most important). Power users that know what SELinux is, are the only one that would know how to answer properly and consciously, they can easily make their choice later and go disable SELinux, like a normal user instead would go and change the desktop background to his liking. Security by default is the best choice (and I wouldn't even ask about the firewall assuming we still do it). Simo. -- Simo Sorce * Red Hat, Inc * New York From debarshi.ray at gmail.com Sat Jul 5 16:50:58 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 5 Jul 2008 22:20:58 +0530 Subject: fish uses old xsel Message-ID: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> The fish package is using xsel-0.9.6 [1] that is provided as an uncompressed tar archive inside the upstream fish tarball. However the latest xsel version is 1.2.0. Is there any reason for doing this? Also, xsel is not a separate package in Fedora. Any reason for this? Happy hacking, Debarshi [1] http://www.vergenet.net/~conrad/software/xsel/ From tibbs at math.uh.edu Sat Jul 5 17:53:45 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jul 2008 12:53:45 -0500 Subject: fish uses old xsel In-Reply-To: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> References: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi Ray writes: DR> Also, xsel is not a separate package in Fedora. Any reason for DR> this? It hasn't completed review yet. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=416471 For some reason that ticket is assigned, but not marked as being under review. I don't know what's up there. - J< From nphilipp at redhat.com Sat Jul 5 18:13:36 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 05 Jul 2008 20:13:36 +0200 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215166768.2321.7.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> Message-ID: <1215281616.1666.47.camel@gibraltar.str.redhat.com> On Fri, 2008-07-04 at 15:19 +0500, Suren Karapetyan wrote: > On Fri, 2008-07-04 at 12:08 +0200, Nils Philippsen wrote: > > On Fri, 2008-07-04 at 01:54 +0500, Suren Karapetyan wrote: > > > EVERYBODY who used to disable SELinux when the combo-box was there will > > > STILL disable it. We didn't get ANYTHING from removing that *feature*. > > > > Please don't confuse features with workarounds. > I need ?neither SELinux nor encrypted rootfs on my desktop (at least > now). Ironically, you'll only ever know whether you really need these two when it's too late to make any decisions about it ;-). > So I'm not trying to workaround SELinux related problems. I just > don't need it/them. The same could be said about backups, firewalls, file permissions... or just about anything else that has the potential of standing in your way if something goes wrong with it. > > I think it's acceptable > > to kindly guide people into employing that workaround only if and when > > they run into problems. > ??The border between kindly guiding and forcing is a bit too thin. Nobody is forcing anybody here, after all you can easily switch it off after installation. Or rather assist in improving it, even if you're not entirely convinced of its usefulness for you personally ;-). On Sat, 2008-07-05 at 02:03 +0500, Suren Karapetyan wrote: > On Fri, 2008-07-04 at 16:57 -0400, Alan Cox wrote: > > On Sat, Jul 05, 2008 at 12:19:14AM +0500, Suren Karapetyan wrote: > [...] > > SELinux isn't just a specific setting... It's a bit too big. > > > It's a feature 38.7% of systems in smolt have disabled... > > > Removing that combobox is like telling this 38.7% (203150) > > > "know what... the other 61.3% (321879) don't like *seeing* choice of > > > > That's meaningless. What percentage of those systems are running with > > the correct choice for their system ? > > > That's a classic case of deciding what's best for the user instead of > asking him... "Do you want to reduce the level of protection against malware and computer criminals?" -- I'd say providing a good level of security by default is objectively in the best interest of the user. Part of a developer's job is actually making these decisions. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From debarshi.ray at gmail.com Sat Jul 5 18:30:11 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 6 Jul 2008 00:00:11 +0530 Subject: fish uses old xsel In-Reply-To: References: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> Message-ID: <3170f42f0807051130o16a8911bk30310c88e87163de@mail.gmail.com> Ok. In the meantime it looks like the tarred xsel in fish is a reason for the FTBFS bug #440724. I tried building fish on my GCC 4.3 tainted Fedora 8 system and it found a missing header for sigsetjmp in xsel. Any idea how we are supposed to patch an uncompressed tar archive shipped inside a compressed one? Happy hacking, Debarshi From dvanassche at gmail.com Sat Jul 5 19:58:52 2008 From: dvanassche at gmail.com (David Van Assche) Date: Sat, 5 Jul 2008 21:58:52 +0200 Subject: trying to build rpm for google gears Message-ID: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> Hi there, I'm working with OLPC (one laptop per child) and am trying to port Google Gears to Sugar (running on Fedora 9) so that we can start working on some offline web based apps (like Offline Moodle.) Ive managed to get a subversion checkout of the source code for google gears, and managed to successfully compile it, noting down required dependencies and the like. It was suggested to me that I should post here to see if someone doesn't have some suggestions on building an rpm for mozilla (xulrunner 1.9) based extensions... I am aware that gears is normally packaed as a .xpi, but that wont work for the XO laptops... it must be a rpm that I can install system wide from the command line. Any help is much appreciated. I'm pretty new to building rpms, as I come from a debian based background, but I'm sure its not all that different from building debs... Kind Regards, David Van Assche OLE Nepal and OLPC -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Sat Jul 5 20:19:30 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Sat, 5 Jul 2008 14:19:30 -0600 Subject: source file audit - 2008-07-05 Message-ID: <20080705141930.5f42d27f@ohm.scrye.com> Here's attached another run of my sources/patches url checker. - There are 649 lines in this run. Up from 642 last run. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt 660 sourcecheck-20080501.txt 642 sourcecheck-20080603.txt - I hope to email maintainers this time about their packages. I didn't get to it last time. You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20080705.txt And also attached to this mail. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. kevin -- abompard:BADURL:glest_data_3.1.2.zip:glest-data aconway:BADURL:rhm-0.2.2060.tar.gz:rhm adalloz:BADURL:pan-0.132.tar.bz2:pan adrian:BADURL:xlockmore-5.25.tar.bz2:xlockmore ajax:BADURL:pyxf86config-0.3.37.tar.bz2:pyxf86config akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx alexlan:BADSOURCE:coverart.py:picard alexlan:BADSOURCE:discnumber.py:picard alexlan:BADSOURCE:featartist.py:picard alexlan:BADSOURCE:__init__.py:picard andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio arbiter:BADURL:automoc4-0.9.83.tar.bz2:automoc ascii:BADURL:fish-1.23.0.tar.bz2:fish asheesh:BADURL:liblicense-0.7.0.tar.gz:liblicense athimm:BADSOURCE:po4a-0.32.tar.gz:po4a athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:fakeroot_1.6.4.tar.gz:fakeroot athimm:BADURL:greylistd_0.8.3.2.tar.gz:greylistd atkac:BADURL:rexec-1.5.tar.gz:rsh atkac:BADURL:vnc-4_1_2-unixsrc.tar.gz:vnc atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout ausil:BADSOURCE:silo-1.4.13.tar.bz2:silo ausil:BADSOURCE:usb8388-5.110.22.p14.bin.md5:libertas-usb8388-firmware ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools ausil:BADURL:snort-2.8.1.tar.gz:snort awjb:BAD_CVS_SOURCE:wmweather+-2.9.tar.gz:wmweather+ awjb:BADURL:atitvout_0.4-2.diff.gz:atitvout awjb:BADURL:claws-mail-3.5.0.tar.bz2:claws-mail awjb:BADURL:claws-mail-extra-plugins-3.5.0.tar.bz2:claws-mail-plugins awjb:BADURL:libdynamite-0.1.1.tar.gz:dynamite awjb:BADURL:libetpan-0.54.tar.gz:libetpan awjb:BADURL:librapi2-0.11.1.tar.gz:librapi awjb:BADURL:librra-0.11.1.tar.gz:librra awjb:BADURL:libsynce-0.11.1.tar.gz:libsynce awjb:BADURL:odccm-0.11.1.tar.gz:odccm awjb:BADURL:synce-gnomevfs-0.11.1.tar.gz:synce-gnomevfs awjb:BADURL:sync-engine-0.11.1.tar.gz:synce-sync-engine awjb:BADURL:synce-trayicon-0.11.tar.gz:synce-trayicon awjb:BADURL:treecc-0.3.8.tar.gz:treecc awjb:BADURL:unshield-0.5.1.tar.gz:unshield awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker :BADURL:adonthell-0.3.5.tar.gz:adonthell belegdol:BAD_CVS_SOURCE:museek+-0.1.13.tar.bz2:museek+ belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa belegdol:BADURL:gchempaint-0.8.7.tar.bz2:gchempaint belegdol:BADURL:gnome-chemistry-utils-0.8.7.tar.bz2:gnome-chemistry-utils belegdol:BADURL:goffice-0.4.3.tar.bz2:goffice04 ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31 bjensen:BADSOURCE:xnec2c-1.0b5.tar.gz:xnec2c bjensen:BADURL:fldigi-2.10.3.tar.gz:fldigi bjensen:BADURL:gpsk31-0.3.tar.gz:gpsk31 bjensen:BADURL:xfhell-1.4.tar.gz:xfhell bojan:BADURL:libapreq2-2.09.tar.gz:libapreq2 bos:BADSOURCE:gtk2hs-0.9.12.1.tar.gz:gtk2hs bouska:BADURL:kitsune2.0.tar.gz:kitsune bpeck:BADURL:conmux-493svn.tar.gz:conmux bpepple:BADURL:evolution-brutus-1.2.17.tar.gz:evolution-brutus bpepple:BADURL:freeciv-2.1.5.tar.bz2:freeciv bpepple:BADURL:ggz-gtk-client-0.0.14.1.tar.gz:ggz-gtk-client bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter bpepple:BADURL:swfdec-gnome-2.22.0.tar.bz2:swfdec-gnome bpostle:BADURL:hugin-0.7.0.tar.gz:hugin buc:BADURL:enca-1.9.tar.bz2:enca caolanm:BADSOURCE:catalan.tar.gz:hunspell-ca caolanm:BADSOURCE:lp_solve_5.5.0.12_source.tar.gz:lpsolve caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de caolanm:BADURL:evolocal.odb:openoffice.org caolanm:BADURL:sjp-myspell-pl-20080614.zip:hunspell-pl cchance:BADSOURCE:emesene-1.0.tar.gz:emesene cchance:BADURL:nhpf-1.42.tar.gz:nhpf cgrau:BADURL:frotz-2.43.tar.gz:frotz cgrau:BADURL:ifm-5.1.tar.gz:ifm chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome chitlesh:BADURL:26521-kio_resources-0.2.tar.bz2:kio_resources chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal chitlesh:BADURL:geda-docs-1.4.0.tar.gz:geda-docs chitlesh:BADURL:geda-examples-1.4.0.tar.gz:geda-examples chitlesh:BADURL:geda-gattrib-1.4.0.tar.gz:geda-gattrib chitlesh:BADURL:geda-gnetlist-1.4.0.tar.gz:geda-gnetlist chitlesh:BADURL:geda-gschem-1.4.0.tar.gz:geda-gschem chitlesh:BADURL:geda-gsymcheck-1.4.0.tar.gz:geda-gsymcheck chitlesh:BADURL:geda-symbols-1.4.0.tar.gz:geda-symbols chitlesh:BADURL:geda-utils-1.4.0.tar.gz:geda-utils chitlesh:BADURL:guile-1.6.7.tar.gz:compat-guile-16 chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc chitlesh:BADURL:ktechlab-0.3.69.tar.bz2:ktechlab chitlesh:BADURL:libgeda-1.4.0.tar.gz:libgeda chitlesh:BADURL:liborigin-20080225.tar.gz:liborigin chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito clumens:BADURL:gnu-efi-3.0d.tar.gz:gnu-efi clumens:BADURL:rhpxl-1.9.tar.gz:rhpxl coldwell:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs corsepiu:BADURL:Mail-GnuPG-0.15.tar.gz:perl-Mail-GnuPG cr33dog:BADURL:fontypython-0.2.0.tar.gz:fontypython cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym cweyl:BADURL:Gtk2-Sexy-0.03.tar.gz:perl-Gtk2-Sexy cweyl:BADURL:Hash-Case-1.003.tar.gz:perl-Hash-Case cweyl:BADURL:MooseX-Object-Pluggable-0.0005.tar.gz:perl-MooseX-Object-Pluggable cweyl:BADURL:POE-0.9999.tar.gz:perl-POE cweyl:BADURL:POE-Component-IRC-5.29.tar.gz:perl-POE-Component-IRC cweyl:BADURL:POE-Component-Server-SimpleHTTP-1.23.tar.gz:perl-POE-Component-Server-SimpleHTTP cweyl:BADURL:POE-Component-SSLify-0.08.tar.gz:perl-POE-Component-SSLify cweyl:BADURL:POE-Filter-Zlib-1.8.tar.gz:perl-POE-Filter-Zlib cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym cweyl:BADURL:WWW-Myspace-0.60.tar.gz:perl-WWW-Myspace cwickert:BADURL:xfce4-minicmd-plugin-0.4.tar.bz2:xfce4-minicmd-plugin danken:BADURL:bidiv-1.5.tgz:bidiv danken:BADURL:hspell-1.0.tar.gz:hspell danms:BADSOURCE:libcmpiutil-0.4.tar.gz:libcmpiutil davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival davidz:BADURL:hal-info-20080607.tar.gz:hal-info davidz:BADURL:notification-daemon-0.3.7.90.tar.bz2:notification-daemon dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator dbhole:BADURL:lucene-2.3.1-src.tar.gz:lucene dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound dcbw:BADURL:plague-0.4.4.1.tar.bz2:plague dchen:BADSOURCE:scim-array-1.0.0.tar.gz:scim-array dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration deji:BADSOURCE:gruler-latest.tar.gz:gruler deji:BADURL:gparted-0.3.7.tar.bz2:gparted denis:BADURL:hamlib-1.2.7.tar.gz:hamlib denis:BADURL:libpanelappletmm-2.22.0.tar.bz2:libpanelappletmm denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite devrim:BADSOURCE:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja dionysos:BAD_CVS_SOURCE:gtk+extra-2.1.1.tar.gz:gtk+extra dionysos:BADURL:eurofont.tar.gz:tetex-eurofont dionysos:BADURL:kbackup-0.5.3.tar.bz2:kbackup dionysos:BADURL:kicad-sources--2007-07-09.zip:kicad drago01:BADSOURCE:iotop-0.2.tar.bz2:iotop drago01:BADURL:compiz-bcop-0.7.6.tar.bz2:compiz-bcop drago01:BADURL:compiz-fusion-plugins-extra-0.7.6.tar.bz2:compiz-fusion-extras drago01:BADURL:compiz-fusion-plugins-main-0.7.6.tar.bz2:compiz-fusion dwalsh:BADSOURCE:checkpolicy-2.0.16.tgz:checkpolicy dwalsh:BADSOURCE:libsemanage-2.0.25.tgz:libsemanage dwalsh:BADSOURCE:selinux-doc-1.26.tgz:selinux-doc dwalsh:BADURL:libselinux-2.0.67.tgz:libselinux dwalsh:BADURL:libsepol-2.0.31.tgz:libsepol dwalsh:BADURL:mcstrans-0.2.11.tgz:mcstrans dwalsh:BADURL:policycoreutils-2.0.50.tgz:policycoreutils dwalsh:BADURL:sepolgen-1.0.12.tgz:policycoreutils dwmw2:BADSOURCE:petitboot-0.0.1.tar.gz:petitboot dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot dwmw2:BADURL:apmud-1.0.0.tgz:apmud dwmw2:BADURL:callweaver-RC-1.1.99.20071230.tar.gz:callweaver dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot dwmw2:BADURL:nano-2.0.6.tar.gz:nano ecik:BADURL:ZSI-2.0.tar.gz:python-ZSI edhill:BADSOURCE:cdo.pdf:cdo edhill:BADSOURCE:cdo_refcard.pdf:cdo edhill:BADURL:wifiroamd-1.14.tar.gz:wifiroamd ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder ensc:BADURL:hunt-1.5.tgz:hunt errr:BADURL:pekwm-0.1.5.tar.bz2:pekwm errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg faucamp:BADURL:12956-knemo-0.4.7.tar.bz2:knemo firewing:BADSOURCE:fwbackups-1.43.2rc2.tar.gz:fwbackups firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab fitzsim:BADSOURCE:icedtea-1.6.tar.gz:java-1.7.0-icedtea fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail frankb:BAD_CVS_SOURCE:nasd.init:nas frankb:BADURL:nas-1.9.1.src.tar.gz:nas gemi:BADSOURCE:cook-2.30.tar.gz:cook gemi:BADSOURCE:curry-0.9.11.tar.gz:curry gemi:BADSOURCE:SmartEiffel-2-3.tar.bz2:smarteiffel gemi:BADURL:ffcall-1.10.tar.gz:ffcall gemi:BADURL:scons-0.98.4.tar.gz:scons gemi:BADURL:skencil-0.6.tar.gz:skencil georgiou:BADURL:ganglia-3.1.0.1399.tar.gz:ganglia gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm glommer:BADURL:kvm-70.tar.gz:kvm green:BADURL:libffi-3.0.1.tar.gz:libffi green:BADURL:liblo-0.24.tar.gz:liblo grenier:BADSOURCE:testdisk-6.9.tar.bz2:testdisk hadess:BADURL:nautilus-sendto-1.0.0.tar.bz2:nautilus-sendto hadess:BADURL:totem-pl-parser-2.23.2.tar.bz2:totem-pl-parser hman-it:BADSOURCE:themonospot-0.7.0.1.tar.gz:themonospot homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class icon:BADURL:cvs2svn-2.1.1.tar.gz:cvs2svn icon:BADURL:gazpacho-0.7.2.tar.bz2:gazpacho icon:BADURL:libxml++-2.22.0.tar.bz2:libxml++ icon:BADURL:PhpDocumentor-1.4.2.tgz:php-pear-PhpDocumentor icon:BADURL:verbiste-0.1.23.tar.gz:verbiste ixs:BADURL:commoncpp2-1.6.1.tar.gz:commoncpp2 ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel ixs:BADURL:scmxx-0.9.0.tar.bz2:scmxx ixs:BADURL:ser-0.9.6_src.tar.gz:ser jafo:BADURL:python-memcached-1.39.tar.gz:python-memcached jakub:BADURL:prelink-20071009.tar.bz2:prelink jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen jamatos:BADURL:pygsl-0.9.3.tar.gz:pygsl jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib james:BADURL:zsh-4.3.4.tar.gz:zsh jcm:BADSOURCE:module-init-tools-3.4.tar.bz2:module-init-tools jcm:BADSOURCE:module-init-tools-3.4.tar.bz2.sign:module-init-tools jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis jcollie:BADURL:sofia-sip-1.12.9.tar.gz:sofia-sip jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2 jgarzik:BADURL:reiserfsprogs-3.6.19.tar.gz:reiserfs-utils jgu:BADURL:dvipdfmx-20080617.tar.gz:dvipdfmx jgu:BADURL:ebib-1.5.2.tar.gz:emacs-common-ebib jima:BADURL:videodog0.31.tar.gz:videodog jjh:BADURL:tinyproxy-1.6.4.tar.gz:tinyproxy jjohnstn:BADURL:eclipse-changelog-src-2.6.1.zip:eclipse-changelog jkeating:BADSOURCE:email2trac.tar.gz:email2trac jlaska:BADURL:snake-0.11-0.7.tar.bz2:snake jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate jlayton:BADURL:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd jmoskovc:BADURL:rdate-1.4.tar.gz:rdate jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats jmrcpn:BADURL:clement-2.1-241.tar.gz:clement jnovy:BAD_CVS_SOURCE:patch.4.6.21.1:db4 jnovy:BADSOURCE:db-4.2.52.tar.gz:compat-db jnovy:BADSOURCE:db-4.3.29.tar.gz:compat-db jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive jnovy:BADURL:mc-4.6.2-pre1.tar.gz:mc jnovy:BADURL:platex209.tar.bz2:texlive-texmf joost:BADURL:lazarus-0.9.24-0.tar.gz:lazarus jorge:BADSOURCE:mimetex.zip:mimetex jorton:BADURL:imap-2004g.tar.Z:libc-client jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx jsteffan:BADURL:revisor-2.1.1.tar.gz:revisor jwb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard jwb:BADSOURCE:blacklists.tar.gz:squidGuard jwboyer:BADURL:ctrlproxy-3.0.6.tar.gz:ctrlproxy jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt jwilson:BADURL:firecontrol-0.2.tar.gz:firecontrol kanarip:BADURL:pyjigdo-0.3.0.tar.gz:pyjigdo karlik:BADURL:warzone2100-2.1_beta2.tar.bz2:warzone2100 karsten:BADURL:libcap-2.10.tar.bz2:libcap kasal:BADURL:Business-ISBN-Data-1.15.tar.gz:perl-Business-ISBN-Data kasal:BADURL:gdbm-1.8.0.tar.gz:gdbm kasal:BADURL:IO-Zlib-1.07.tar.gz:perl-IO-Zlib kasal:BADURL:Text-CSV_XS-0.30.tar.gz:perl-Text-CSV_XS kasal:BADURL:transfig.3.2.5.tar.gz:transfig kasal:BADURL:Xaw3d-1.3.tar.gz:Xaw3d kasal:BADURL:xfig.3.2.5.full.tar.gz:xfig kasal:BADURL:XML-Grove-0.46alpha.tar.bz2:perl-XML-Grove katzj:BADSOURCE:pyusb-0.4.1.tar.gz:pyusb kevin:BADSOURCE:Inconsolata.sfd:inconsolata-fonts kevin:BADSOURCE:twinkle-1.2.tar.gz:twinkle kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf kevin:BADURL:munin_1.2.6.tar.gz:munin kwizart:BADURL:aqsis-1.2.0.tar.gz:aqsis kwizart:BADURL:GLC_Player_src_1.0.2.zip:GLC_Player kwizart:BADURL:oyranos-repack-0.1.7.tar.bz2:oyranos kylev:BADURL:Mail-DKIM-0.32.tar.gz:perl-Mail-DKIM kzak:BADURL:collectl-2.6.4-1.src.tar.gz:collectl kzak:BADURL:lslk_1.29_W.tar.gz:lslk kzak:BADURL:vlock-1.3.tar.gz:vlock lennart:BADSOURCE:pavucontrol-0.9.6.tar.gz:pavucontrol lennart:BADURL:pulseaudio-0.9.11.git20080626.tar.gz:pulseaudio leo:BADURL:pcmanx-gtk2.tar.gz:pcmanx-gtk2 linville:BADURL:b43-fwcutter-011.tar.bz2:b43-fwcutter liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak lkundrak:BADURL:HTML-Template-Pro-0.69.tar.gz:perl-HTML-Template-Pro lkundrak:BADURL:String-Random-0.22.tar.gz:perl-String-Random lkundrak:BADURL:Test-WWW-Selenium-0.15.tar.gz:perl-Test-WWW-Selenium llim:BAD_CVS_SOURCE:lsb-release-2.0.tar.gz:redhat-lsb lmacken:BADSOURCE:TurboFlot-0.1.1.tar.bz2:python-turboflot lmacken:BADURL:configobj-4.5.3.zip:python-configobj lmacken:BADURL:deskbar-applet-2.23.2.tar.bz2:deskbar-applet lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears lucilanga:BADSOURCE:fuse-0.9.0.tar.gz:fuse-emulator lvm-team:BADURL:dmraid-1.0.0.rc14.tar.bz2:dmraid maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine mbarabas:BADURL:system-config-vsftpd-0.5.1.tar.gz:system-config-vsftpd mbarnes:BADURL:yelp-2.23.1.tar.bz2:yelp mccann:BADURL:gnome-screensaver-2.23.3.tar.bz2:gnome-screensaver mebourne:BADSOURCE:ZoneMinder-1.22.3.tar.gz:zoneminder mebrown:BADSOURCE:libsmbios-2.0.1.tar.gz:libsmbios meme:BADSOURCE:vultures-2.1.0-full.tar.bz2:nethack-vultures mfleming:BADURL:mod-cband-0.9.7.5.tgz:mod_cband mgarski:BADSOURCE:linuxdcpp-1.0.1.tar.bz2:linuxdcpp mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV misa:BADURL:pyOpenSSL-0.6.tar.gz:pyOpenSSL mlichvar:BADSOURCE:setlayout.c:openbox mmahut:BADURL:cmunipack-1.1.24.tar.gz:munipack mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart mmaslano:BADURL:cronie-1.2.tar.gz:cronie mmcgrath:BADURL:phpMyAdmin-2.11.7-all-languages.tar.bz2:phpMyAdmin mmcgrath:BADURL:SOAP-Lite-0.710.07.tar.gz:perl-SOAP-Lite mpg:BADURL:hulahop-0.4.0.tar.bz2:hulahop mtasaka:BADURL:cairo-dock-sources-svn1162_trunk.tar.bz2:cairo-dock mtasaka:BADURL:gnome-commander-1.2.7-svn1862_trunk.tar.bz2:gnome-commander mtasaka:BADURL:jd-2.0.0-svn2159_trunk.tgz:jd mtasaka:BADURL:kazehakase-0.5.4-svn3506_trunk.tar.gz:kazehakase mtasaka:BADURL:mfiler3-1.1.1.tgz:mfiler3 mtasaka:BADURL:wallpapoz-0.4.1-svn87_trunk.tar.bz2:wallpapoz muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras mwiriadi:BADURL:gpicview-0.1.9.tar.gz:gpicview mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend mwringe:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler mwringe:BADURL:nekohtml-0.9.5.tar.gz:nekohtml nalin:BADURL:nss_db-2.2.tar.gz:nss_db nalin:BADURL:nss_ldap-259.tar.gz:nss_ldap nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap nbecker:BADURL:unuran-1.2.4p1.tar.gz:unuran ngompa:BADURL:oggconvert-0.3.0.tar.gz:oggconvert nhorman:BADURL:cscope-15.6.tar.gz:cscope nhorman:BADURL:numactl-2.0.0.tar.gz:numactl nigelj:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice nim:BADSOURCE:GFS_DIDOTCLASS_OT.zip:gfs-didot-classic-fonts nixaff4:BADURL:knotify-plugin_0.1.tar.gz:pidgin-knotify nmurray:BADURL:giflib-4.1.3.tar.bz2:giflib nmurray:BADURL:ImageMagick-6.4.0-10.tar.bz2:ImageMagick nomis80:BADURL:camstream-0.26.3.tar.gz:camstream nphilipp:BADSOURCE:gtkimageview-1.5.0.tar.gz:gtkimageview nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp ondrejj:BADSOURCE:sagator-1.0.0.tar.bz2:sagator orion:BADSOURCE:GSHHS1.10_coast.tar.bz2:GMT-coastlines orion:BADSOURCE:GSHHS1.10_full.tar.bz2:GMT-coastlines orion:BADSOURCE:GSHHS1.10_high.tar.bz2:GMT-coastlines orion:BADURL:ncarg_src-4.4.2.tar.gz:ncarg orphan:BADSOURCE:FreeWnn-1.1.1-a021.tar.bz2:FreeWnn orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins orphan:BADSOURCE:kbiof-0.3.tar.gz:kbiof orphan:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago orphan:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog orphan:BADURL:gnome-ppp-0.3.23.tar.bz2:gnome-ppp orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum orphan:BADURL:new-1.3.9.tar.gz:new orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script otaylor:BADURL:mugshot-1.2.1.tar.gz:mugshot ovasik:BADSOURCE:docbook-slides-3.4.0.tar.gz:docbook-slides ovasik:BADURL:gnome-bluetooth-0.11.0.tar.bz2:gnome-bluetooth ovasik:BADURL:passivetex-1.25.zip:passivetex ovasik:BADURL:xmltex-1.9.tar.gz:xmltex owentl:BADSOURCE:GoodWeather-0.3.tar.gz:gdesklets-goodweather pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit pertusus:BADURL:lesstif2_0.95.0-2.diff.gz:lesstif petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk pfj:BADSOURCE:CastPodder-5.0.tar.bz2:CastPodder pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o pfj:BADSOURCE:mono-tools-1.9.tar.bz2:mono-tools pfj:BADURL:gDeskCal-1.01.tar.gz:gdeskcal pfj:BADURL:gtksourceview2-sharp-89788.tar.bz2:gtksourceview2-sharp pfj:BADURL:gtksourceview-sharp-2.0-0.12.tar.bz2:gtksourceview-sharp pfj:BADURL:ikvm-0.22.tar.gz:ikvm pfj:BADURL:mod_mono-1.9.tar.bz2:mod_mono pfj:BADURL:mono-debugger-0.60.tar.bz2:mono-debugger pfj:BADURL:monodoc-1.9.zip:monodoc pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks pgordon:BADURL:deluge-0.5.9.3.tar.gz:deluge pgordon:BADURL:empathy-0.23.3.tar.bz2:empathy pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth pgordon:BADURL:libtorrent-0.12.1.tar.gz:rb_libtorrent phuang:BADSOURCE:scim-1.4.7.tar.gz:scim phuang:BADSOURCE:scim-python-0.1.12.tar.gz:scim-python pknirsch:BADSOURCE:ipmitool-1.8.9.tar.gz:OpenIPMI pmachata:BADSOURCE:tbb21_20080605oss_src.tgz:tbb pnemade:BADSOURCE:iso-codes-2.1.tar.bz2:iso-codes pnemade:BADSOURCE:ne_NP_dict.zip:hunspell-ne pwouters:BADURL:ks3switch-0.1.tar.gz:ks3switch pwouters:BADURL:s3ssrc.zip:s3switch qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas rafalzaq:BADURL:htop-0.7.tar.gz:htop rajeeshknambiar:BADSOURCE:ooo-hunspell-ml-0.1.tar.bz2:hunspell-ml rathann:BADURL:crm114-20070810-BlameTheSegfault.src.tar.gz:crm114 rathann:BADURL:libnemesi-0.6.4-rc2.tar.bz2:libnemesi rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2 rbhalera:BADURL:Madan.ttf:madan-fonts rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview rdieter:BADSOURCE:Macaulay2-1.1-src.tar.gz:Macaulay2 rdieter:BADURL:libofa-0.9.3.tar.gz:libofa rdieter:BADURL:macref.pdf:maxima rdieter:BADURL:mtextralic.htm:mathml-fonts rdieter:BADURL:pinentry-0.7.4.tar.gz:pinentry rdieter:BADURL:pinentry-0.7.4.tar.gz.sig:pinentry rezso:BAD_CVS_SOURCE:proj.copyright:proj rezso:BADURL:ogdi-3.2.0.beta2.tar.gz:ogdi rishi:BADSOURCE:httrack-3.42.tar.gz:httrack rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP rnorwood:BADURL:gnome-packagekit-0.2.3-20080618.tar.gz:gnome-packagekit rnorwood:BADURL:PackageKit-0.2.3-20080618.tar.gz:PackageKit robert:BADURL:idn_1.2b.tar.gz:php-idn robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish roland:BADURL:lcov-1.6.tar.gz:lcov rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd rrakus:BADURL:cleanfeed-0.95.7b.tar.gz:cleanfeed rrelyea:BADSOURCE:ccid-1.2.1.tar.gz:ccid rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 rstrode:BADURL:GConf-2.23.1.tar.bz2:GConf2 rvokal:BADURL:gaim-guifications-2.13beta6.tar.bz2:gaim-guifications rvokal:BADURL:pidgin-guifications-2.14.tar.bz2:pidgin-guifications ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender s4504kr:BADURL:inadyn.v1.96.2.zip:inadyn s4504kr:BADURL:lightning-1.2.tar.gz:lightning s4504kr:BADURL:stellarium_user_guide-0.9.0-1.pdf:stellarium s4504kr:BADURL:suck-4.3.2.tar.gz:suck salimma:BADSOURCE:Falcon-0.8.10.tar.gz:Falcon salimma:BADSOURCE:fbreader-sources-0.8.12.tgz:fbreader sandeen:BADURL:blktrace-git-20080103162505.tar.gz:blktrace sergiopr:BADURL:cpl-4.1.0.tar.gz:cpl sergiopr:BADURL:ds9.5.2.tar.gz:ds9 sergiopr:BADURL:esorex-3.6.8.tar.gz:esorex sergiopr:BADURL:qfits-6.2.0.tar.gz:qfits sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools sgrubb:BADURL:libprelude-0.9.17.1.tar.gz:libprelude sgrubb:BADURL:prelude-manager-0.9.13.tar.gz:prelude-manager shahms:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols sharkcz:BADSOURCE:tinyerp-client-4.2.2.tar.gz:tinyerp sharkcz:BADSOURCE:tinyerp-server-4.2.2.tar.gz:tinyerp sheltren:BADURL:cfengine-2.2.7.tar.gz:cfengine sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod sheltren:BADURL:fortune-tao.tar.gz:fortune-mod sheltren:BADURL:osfortune.tar.gz:fortune-mod simo:BADURL:rsync-3.0.3.tar.gz:rsync simo:BADURL:rsync-patches-3.0.3.tar.gz:rsync sindrepb:BADURL:DBIx-SQLite-Simple-0.34.tar.gz:perl-DBIx-SQLite-Simple sindrepb:BADURL:gnome-do-0.4.2.0.tar.gz:gnome-do sindrepb:BADURL:nikto-1.36.tar.bz2:nikto sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib snecker:BADURL:jokosher-20080216svn.tar.gz:jokosher snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim snirkel:BADURL:njb-sharp-0.3.0.tar.bz2:njb-sharp splinux:BADURL:gdmap-0.7.5.tar.gz:gdmap splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm splinux:BADURL:pessulus-2.16.2.tar.bz2:pessulus spot:BADSOURCE:mpiblacs.tgz:blacs spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware spot:BADSOURCE:srecord-1.39.tar.gz:srecord spot:BADURL:asymptote-1.43.src.tgz:asymptote spot:BADURL:Class-Data-Inheritable-0.06.tar.gz:perl-Class-Data-Inheritable spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg spot:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI spot:BADURL:IO-CaptureOutput-1.06.tar.gz:perl-IO-CaptureOutput spot:BADURL:libgdamm-3.0.0.tar.bz2:libgdamm spot:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record spot:BADURL:rx-1.5.tar.bz2:librx spot:BADURL:Scalar-Properties-0.13.tar.gz:perl-Scalar-Properties spot:BADURL:Tree-DAG_Node-1.06.tar.gz:perl-Tree-DAG_Node spot:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile steve:BADURL:cpanspec-1.77.tar.gz:cpanspec steve:BADURL:eperl_2.2.14-13.diff.gz:perl-eperl steved:BADURL:nfs.doc.tar.gz:nfs-utils stransky:BADURL:awesfx-0.5.0d.tar.gz:awesfx stransky:BADURL:gu11-rom.zip:awesfx sundaram:BADURL:gyachi-1.1.35.tar.gz:gyachi svahl:BADURL:kcoloredit-4.0.80.tar.bz2:kcoloredit sxw:BADURL:kstart-3.11.tar.gz:kstart tagoh:BADSOURCE:anthy-9100e.tar.gz:anthy tagoh:BADSOURCE:Canna37p3.tar.bz2:Canna tagoh:BADSOURCE:mplus_bitmap_fonts-2.2.4.tar.gz:fonts-japanese tagoh:BADSOURCE:nkf-2.0.8b.tar.gz:nkf tagoh:BADSOURCE:scim-anthy-1.2.4.tar.gz:scim-anthy tagoh:BADURL:k14-oldkanji.tar.gz:fonts-japanese tagoh:BADURL:mew-6.1.tar.gz:mew tbzatek:BADSOURCE:tuxcmd-modules-0.6.36.tar.bz2:tuxcmd tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql tgl:BADURL:jpegsrc.v6b.tar.bz2:libjpeg tgl:BADURL:mysql-5.0.51a.tar.gz:mysql tgl:BADURL:mysql-connector-odbc-3.51.24r1071.tar.gz:mysql-connector-odbc tgl:BADURL:pg_filedump-8.3.0.tar:rhdb-utils tgl:BADURL:postgresql-8.3.3-US.pdf:postgresql tgl:BADURL:psqlodbc-08.03.0100.tar.gz:postgresql-odbc than:BAD_CVS_SOURCE:French.txt:wordtrans than:BADSOURCE:css.tar.bz2:kdewebdev than:BADSOURCE:html.tar.bz2:kdewebdev than:BADSOURCE:javascript.tar.bz2:kdewebdev than:BADURL:arts-1.5.9.tar.bz2:arts than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R than:BADURL:efax-0.9a-001114.tar.gz:efax than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils than:BADURL:kde-i18n-ar-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bg-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ca-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-cs-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-da-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-de-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-el-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-en_GB-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-es-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-et-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-he-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hu-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-is-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-it-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ja-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ko-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-lt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nb-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pa-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt_BR-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ro-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ru-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sv-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ta-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-tr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-uk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_CN-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_TW-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-l10n-ar-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-be-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ca-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-cs-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-csb-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-da-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-de-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-el-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-en_GB-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-eo-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-es-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-et-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-eu-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-fi-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-fr-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ga-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-gl-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-hi-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-hu-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-it-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ja-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-km-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ko-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-lv-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-mk-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-nb-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-nds-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ne-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-nl-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-nn-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-pa-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-pl-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt_BR-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ru-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-se-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-sl-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-sv-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-ta-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-th-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-tr-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-uk-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-wa-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_CN-4.0.83.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_TW-4.0.83.tar.bz2:kde-l10n than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R than:BADURL:mozplugger-1.10.1.tar.gz:mozplugger than:BADURL:rp-pppoe-3.8.tar.gz:rp-pppoe than:BADURL:urw-fonts-1.0.7pre44.tar.bz2:urw-fonts than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans thias:BADSOURCE:libcaca-0.99.beta11.tar.gz:libcaca thias:BADSOURCE:Nevow-0.9.29.tar.gz:python-nevow thias:BADURL:DirectFB-1.0.0.tar.gz:directfb thias:BADURL:tagpy-0.94.1.tar.gz:python-tag thomasvs:BADSOURCE:libannodex-0.7.3.tar.gz:libannodex thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime timj:BADURL:rapidsvn-0.9.6.tar.gz:rapidsvn timj:BADURL:rpl_1.5.3.tar.gz:rpl tmraz:BAD_CVS_SOURCE:Linux-PAM-1.0.1.tar.bz2.sign:pam tmraz:BADURL:db-4.6.19.tar.gz:cyrus-sasl tmraz:BADURL:galculator-1.3.1.tar.bz2:galculator tmraz:BADURL:ipsec-tools-0.7.tar.bz2:ipsec-tools tmraz:BADURL:Linux-PAM-1.0.1.tar.bz2:pam toshio:BADURL:ToscaWidgets-0.9.1.tar.gz:python-toscawidgets tuxbrewr:BADURL:liferea-1.4.16b.tar.gz:liferea tuxbrewr:BADURL:powerman-2.1.tar.bz2:powerman twaugh:BADSOURCE:ppa-0.8.6.tar.gz:pnm2ppa twaugh:BADURL:cups-1.3.7-source.tar.bz2:cups twaugh:BADURL:foomatic-db-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-engine-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-hpijs-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-filters-3.0-20080507.tar.gz:foomatic twaugh:BADURL:libieee1284-0.2.11.tar.bz2:libieee1284 varekova:BADURL:acct-6.3.2.tar.gz:psacct varekova:BADURL:gzip-1.3.12.tar.gz:gzip varekova:BADURL:mailx-12.3.tar.bz2:mailx varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl varekova:BADURL:mpfr-2.3.0.tar.bz2:mpfr varekova:BADURL:unzip552.tar.gz:unzip varekova:BADURL:zcrypt29.tar.gz:zip varekova:BADURL:zip231.tar.gz:zip vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect vcrhonek:BADURL:pegasus-2.7.0.tar.gz:tog-pegasus vcrhonek:BADURL:sblim-cmpi-base-1.5.4.tar.bz2:sblim-cmpi-base veillard:BADURL:libxml2-2.6.32.tar.gz:libxml2 veillard:BADURL:opal-2.2.11.tar.gz:opal veillard:BADURL:pwlib-1.10.10.tar.gz:pwlib vlg:BADURL:granule-1.3.0.tar.gz:granule walters:BADURL:desktop-data-model-1.2.4.tar.bz2:desktop-data-model walters:BADURL:online-desktop-0.2.29.tar.gz:online-desktop wtogami:BADURL:IO-Socket-INET6-2.54.tar.gz:perl-IO-Socket-INET6 xgl-maint:BADURL:font-util-1.0.1.tar.bz2:xorg-x11-font-utils xgl-maint:BADURL:xf86-video-vesa-20080404.tar.bz2:xorg-x11-drv-vesa zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar zmc:BADSOURCE:pyspi-0.6.1.tar.gz:pyspi zprikryl:BADURL:eject-2.1.5.tar.gz:eject zprikryl:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wolfy at nobugconsulting.ro Sat Jul 5 20:34:13 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 05 Jul 2008 23:34:13 +0300 Subject: fish uses old xsel In-Reply-To: <3170f42f0807051130o16a8911bk30310c88e87163de@mail.gmail.com> References: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> <3170f42f0807051130o16a8911bk30310c88e87163de@mail.gmail.com> Message-ID: <486FDAC5.2030903@nobugconsulting.ro> On 07/05/2008 09:30 PM, Debarshi Ray wrote: > Ok. > > In the meantime it looks like the tarred xsel in fish is a reason for > the FTBFS bug #440724. I tried building fish on my GCC 4.3 tainted > Fedora 8 system and it found a missing header for sigsetjmp in xsel. > Any idea how we are supposed to patch an uncompressed tar archive > shipped inside a compressed one? > 1.using a private version of another piece of software is definitely a no-no for fedora. either submit it separately, or arrange for the existing one to be patched. and make use of the blocker bugs to notify that one bug blocks/is blocked by another one 2. untar, patch, use. (and add a comment in the spec) From alexl at users.sourceforge.net Sat Jul 5 21:05:35 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jul 2008 14:05:35 -0700 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: (Scott Henson's message of "Sat\, 05 Jul 2008 12\:39\:12 -0400") References: <486F01DC.4090008@nigelj.com> Message-ID: >> Alex Lancaster wrote: >> f-spot is currently orphaned and is scheduled to be deleted if it >>> doesn't build from source: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=449506 >>> >>> One of the reasons it's currently failing to build is because of >>> the gnome-sharp issue detailed in this thread: >>> >>> http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html >>> I'm working on getting this to build because it requires a new >>> unpackaged gnome-desktop-sharp package But in the long-term I >>> don't have time to be the primary maintainer, so if somebody else >>> would like to step up to be primary maintainer that would be >>> great. SH> Nigel Jones wrote: >> Actually, I'd noticed this too, I'm willing to be a primary >> maintainer, and I was actually looking at getting >> gnome-desktop-sharp done, but if you already have that's fine by >> me. >>>>> "SH" == Scott Henson writes: SH> I would be willing to comaintain if you need some help. OK, so now that gnome-desktop-sharp has been passed, it gets passed the gtktml dependency check, but now fails due to some mono error, which maybe just beyond my mono skills to diagnose/fix. I see a series of error messages like the following: error CS0136: A local variable named `result' cannot be declared in this scope because it would give a different meaning to `result', which is already used in a `method argument' scope to denote something else generated/VolumeAdapter.cs(152,72): (Location of the symbol related to previous error) error CS0136: A local variable named `result' cannot be declared in this scope because it would give a different meaning to `result', which is already used in a `method argument' scope to denote something else generated/VolumeAdapter.cs(183,72): (Location of the symbol related to previous error) Compilation failed: 12 error(s), 0 warnings See this for more details: http://koji.fedoraproject.org/koji/getfile?taskID=698211&name=build.log http://koji.fedoraproject.org/koji/taskinfo?taskID=698211 Any help from any mono hackers out there gratefully appreciated! Alex From Bl0ngo067 at aim.com Sat Jul 5 23:42:54 2008 From: Bl0ngo067 at aim.com (brad longo) Date: Sat, 05 Jul 2008 19:42:54 -0400 Subject: trying to build rpm for google gears In-Reply-To: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> References: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> Message-ID: <487006FE.9080305@aim.com> David Van Assche wrote: > Hi there, > I'm working with OLPC (one laptop per child) and am trying to port > Google Gears to Sugar (running on Fedora 9) so that we can start > working on some offline web based apps (like Offline Moodle.) Ive > managed to get a subversion checkout of the source code for google > gears, and managed to successfully compile it, noting down required > dependencies and the like. It was suggested to me that I should post > here to see if someone doesn't have some suggestions on building an > rpm for mozilla (xulrunner 1.9) based extensions... > I am aware that gears is normally packaed as a .xpi, but that wont > work for the XO laptops... it must be a rpm that I can install system > wide from the command line. Any help is much appreciated. I'm pretty > new to building rpms, as I come from a debian based background, but > I'm sure its not all that different from building debs... > > Kind Regards, > David Van Assche > OLE Nepal and OLPC I don't know much about building an rpm for mozilla based extensions, but if you need a place to start on familiarizing yourself with rpm's I wrote a tutorial in my blog recently on how to create one. I learned how to package rpms myself from rpm.org . If you know how to make a deb package you shouldn't have too much trouble. Good luck. -- Brad From Bl0ngo067 at aim.com Sat Jul 5 23:49:56 2008 From: Bl0ngo067 at aim.com (brad longo) Date: Sat, 05 Jul 2008 19:49:56 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <26p2k5x847.ln2@ppp1053.in.ipex.cz> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <1215031595.5130.38.camel@perihelion> <20080702211610.GC27060@devserv.devel.redhat.com> <1215033650.5130.57.camel@perihelion> <20080703082955.GA25619@devserv.devel.redhat.com> <1215099725.8001.17.camel@scrappy.miketc.com> <26p2k5x847.ln2@ppp1053.in.ipex.cz> Message-ID: <487008A4.8000101@aim.com> Matej Cepl wrote: > On 2008-07-03, 15:42 GMT, Mike Chambers wrote: > >> They get a little question stating this program wants to run, >> do you give it permission. >> > > And yes, that's the reason why Vista is still totally broken > security-wise. Before even thinking about yes/no dialog, read > http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf and other > things on http://www.cs.auckland.ac.nz/~pgut001/ > > Best, > > Mat?j > > Is disabling selinux yourself really that difficult? Also I know from experience that selinux wasn't that great in the past, and since I started using Fedora I have always disabled it without thinking whenever I updated. Recently though when I updated to Fedora 9 I just left it alone, and now I sometimes even forget that its there. I have had no issues with it at all. The way I see it, if its not broken why touch it? It only increases security. --Brad From kevin.kofler at chello.at Sun Jul 6 00:04:15 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 6 Jul 2008 00:04:15 +0000 (UTC) Subject: f-spot is orphaned: in danger of being removed from Fedora References: <486F01DC.4090008@nigelj.com> Message-ID: Alex Lancaster users.sourceforge.net> writes: > error CS0136: A local variable named `result' cannot be declared in this > scope because it would give a different meaning to `result', which is already > used in a `method argument' scope to denote something else > generated/VolumeAdapter.cs(152,72): (Location of the symbol related to > previous error) This error message says you have a variable in an inner scope shadowing a variable in an outer scope. This is allowed in "the programmer is always right" type languages like C or C++, but not in "let's try to prevent common mistakes by banning the constructs which cause them" type languages like Java or C#. (The potential mistake in this case is of course confusing the variables with the same name, i.e. trying to refer to the outer "result" variable and getting the inner one instead.) The obvious fix is of course to rename the local "result" variable to something non-conflicting. Given that this code appears to be automatically generated, the patch will probably have to be applied to the generator. Kevin Kofler From gnomeuser at gmail.com Sun Jul 6 00:35:04 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 6 Jul 2008 02:35:04 +0200 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: References: <486F01DC.4090008@nigelj.com> Message-ID: <1dedbbfc0807051735h3dfca2a9g3b3cb80ed2bc01a5@mail.gmail.com> 2008/7/6 Kevin Kofler : > Alex Lancaster users.sourceforge.net> writes: > > error CS0136: A local variable named `result' cannot be declared in this > > scope because it would give a different meaning to `result', which is > already > > used in a `method argument' scope to denote something else > > generated/VolumeAdapter.cs(152,72): (Location of the symbol related to > > previous error) > > This error message says you have a variable in an inner scope shadowing a > variable in an outer scope. This is allowed in "the programmer is always > right" > type languages like C or C++, but not in "let's try to prevent common > mistakes > by banning the constructs which cause them" type languages like Java or C#. > (The potential mistake in this case is of course confusing the variables > with > the same name, i.e. trying to refer to the outer "result" variable and > getting > the inner one instead.) > > The obvious fix is of course to rename the local "result" variable to > something > non-conflicting. Given that this code appears to be automatically > generated, > the patch will probably have to be applied to the generator. The more disturbing thing, if I read the output correctly is that it happens while compiling gio-sharp.dll which definitely shouldn't be in f-spot. I haven't had time to take a stab at the offending code but it feels like it is including gnome-desktop-sharp stuff. In that case the correct fix would be making it use the system libraries. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at users.sourceforge.net Sun Jul 6 00:40:58 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jul 2008 17:40:58 -0700 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: (Kevin Kofler's message of "Sun\, 6 Jul 2008 00\:04\:15 +0000 \(UTC\)") References: <486F01DC.4090008@nigelj.com> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> Alex Lancaster users.sourceforge.net> writes: >> error CS0136: A local variable named `result' cannot be declared in >> this scope because it would give a different meaning to `result', >> which is already used in a `method argument' scope to denote >> something else generated/VolumeAdapter.cs(152,72): (Location of the >> symbol related to previous error) KK> This error message says you have a variable in an inner scope KK> shadowing a variable in an outer scope. This is allowed in "the KK> programmer is always right" type languages like C or C++, but not KK> in "let's try to prevent common mistakes by banning the constructs KK> which cause them" type languages like Java or C#. (The potential KK> mistake in this case is of course confusing the variables with the KK> same name, i.e. trying to refer to the outer "result" variable and KK> getting the inner one instead.) KK> The obvious fix is of course to rename the local "result" variable KK> to something non-conflicting. Given that this code appears to be KK> automatically generated, the patch will probably have to be KK> applied to the generator. OK, thanks for the explanation, but my mono skills are weak to non-existent so I'm not about to go try patching the generator... hopefully somebody else will jump in. The next question is why did this appear now and not in previous releases of f-spot/mono? What changed? Is the version of mono now in rawhide more picky or did f-spot introduce an error? I suspect that f-spot 0.4.4 introduced an error because this didn't occur with the previous version of f-spot: 0.4.3, but it's odd that it hasn't come up on the f-spot mailing list and several people have been building from source there. I'll take it up on the f-spot list/IRC channel, but if anybody knows anything more about f-spot please let me know. Alex From alexl at users.sourceforge.net Sun Jul 6 00:51:29 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jul 2008 17:51:29 -0700 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: <1dedbbfc0807051735h3dfca2a9g3b3cb80ed2bc01a5@mail.gmail.com> (David Nielsen's message of "Sun\, 6 Jul 2008 02\:35\:04 +0200") References: <486F01DC.4090008@nigelj.com> <1dedbbfc0807051735h3dfca2a9g3b3cb80ed2bc01a5@mail.gmail.com> Message-ID: >>>>> "DN" == David Nielsen writes: [...] DN> The more disturbing thing, if I read the output correctly is that DN> it happens while compiling gio-sharp.dll which definitely DN> shouldn't be in f-spot. I haven't had time to take a stab at the DN> offending code but it feels like it is including DN> gnome-desktop-sharp stuff. In that case the correct fix would be DN> making it use the system libraries. This is an ongoing issue with f-spot, I had tracked down a number of these issues previously and with some help from the Debian maintainer had patched them to use system libraries, but perhaps f-spot has gone and done it again. See: https://bugzilla.redhat.com/show_bug.cgi?id=442343 Although I did notice that the configure script does check for the presence of gnome-desktop-sharp, the absence of which was causing the builds to originally fail. The question is if it tries to detect it, why doesn't it use it? Alex From jwilson at redhat.com Sun Jul 6 02:52:26 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 5 Jul 2008 22:52:26 -0400 Subject: Kernel 2.6.25 (F8/F9) problem In-Reply-To: <364d303b0807050632t3b5c2d5dn77465624fb687051@mail.gmail.com> References: <1214991659.4240.32.camel@lesca.home.solinos.it> <200807021204.54804.jwilson@redhat.com> <364d303b0807050632t3b5c2d5dn77465624fb687051@mail.gmail.com> Message-ID: <200807052252.26592.jwilson@redhat.com> On Saturday 05 July 2008 09:32:51 am Christopher Brown wrote: > 2008/7/2 Jarod Wilson : > > On Wednesday 02 July 2008 05:40:59 am Dario Lesca wrote: > >> On this kind of server (HP ProLiant DL380 G5) > >> > >> > http://www.smolts.org/client/show/pub_e04ad1d7-e691-4b54-a3b6-1a5ff974 > >> >d5b d > >> > >> It's NOT possible install then use F9 and F8+update. > >> > >> This is a HP common server, since there is the problem for over a month, > >> means that no one is using Fedora 8 + update or Fedora 9 on this kind of > >> server. > >> > >> If someone was able to run Fedora 8 + Updates or Fedora 9 on these > >> servers, please let me know how to do. > > > > Please file a bug. We do have DL380 G5 hardware here in the lab. It > > typically gets used for RHEL testing, but I'm sure someone can get Fedora > > on one and see what they can see. This hardware definitely needs to work > > come RHEL6 time, so fixing it in Fedora sooner than later would be > > good... Please feel free to add me (jwilson at redhat.com) to the cc list > > when you open the bug. > > With all due respect, the hardware _definitely_ needs to work with Fedora > 9. Oh, I completely agree that it needs to work in F9 as well, didn't mean to suggest it wouldn't get fixed in F9. The RHEL reference was because I work in the RHEL kernel group, and if there's a clear need to fix it for RHEL's sake, its easier for me to justify spending any time during work hours working on it. :) -- Jarod Wilson jwilson at redhat.com From gnomeuser at gmail.com Sun Jul 6 03:08:48 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 6 Jul 2008 05:08:48 +0200 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: References: <486F01DC.4090008@nigelj.com> <1dedbbfc0807051735h3dfca2a9g3b3cb80ed2bc01a5@mail.gmail.com> Message-ID: <1dedbbfc0807052008p795d6810j3cf9ed242b40a4d0@mail.gmail.com> 2008/7/6 Alex Lancaster : > >>>>> "DN" == David Nielsen writes: > > [...] > > DN> The more disturbing thing, if I read the output correctly is that > DN> it happens while compiling gio-sharp.dll which definitely > DN> shouldn't be in f-spot. I haven't had time to take a stab at the > DN> offending code but it feels like it is including > DN> gnome-desktop-sharp stuff. In that case the correct fix would be > DN> making it use the system libraries. > > This is an ongoing issue with f-spot, I had tracked down a number of > these issues previously and with some help from the Debian maintainer > had patched them to use system libraries, but perhaps f-spot has gone > and done it again. See: > > https://bugzilla.redhat.com/show_bug.cgi?id=442343 > > Although I did notice that the configure script does check for the > presence of gnome-desktop-sharp, the absence of which was causing the > builds to originally fail. The question is if it tries to detect it, > why doesn't it use it? The programmer works in mysterious ways, most likely if this is the cause it is code added in the interim between now and when distributions have packages available. If you need the functionality, often the desire to wait for a package or a tarball release is low as it can set you back months for no good reason. At least it does not seem that they are using a pre compiled binary this time which is a step in the right direction. I think we should see it as a sign to be more proactive about getting support libraries into Fedora and keeping them updated.. I suspect though that repeating this will, once again, fall on deaf ears. Now back to the desire to create a Mono SIG, this would alliviate the problem for Mono packages a little. Currently I ping pong a bit with Paul to get new Mono libraries into Fedora but Paul unfortunately has a tendency to disappear for months at the time due to real world constraints (pesky real life). E.g. he currently has the dependencies (3 packages) that would allow us to ship MonoDevelop 1.0 in review but has let them sit for 2 months without providing updates to pending comments. Having more hands would definitely help both him and Fedora as a whole, and a more coordinated approach to our Mono stack wouldn't hurt either. So consider this a call to arms. We need a clear agenda, there is still much great Mono software not in Fedora. What we have is maintained by very few people, leaving us with problems relating to maintainer burnout or outright disappearance. We clearly have problems staying current and ensuring that downstream has access to the libraries they need, nor do we have a process which can be used to streamline the introduction of said software (and just look at how fast we can be when we want to, gnome-desktop-sharp was in Fedora within a day). The packaging guidelines probably need a review as well, surely there is room for improvement. So who is with me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sun Jul 6 09:23:29 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 6 Jul 2008 09:23:29 +0000 (UTC) Subject: rawhide report: 20080706 changes Message-ID: <20080706092329.4FD43209D8E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080705/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080706/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gnome-desktop-sharp .NET language binding for mono New package mm3d 3D model editor New package xdialog X11 drop in replacement for cdialog Updated Packages: asunder-1.6-1.fc10 ------------------ * Tue Jul 1 18:00:00 2008 Marcin Zajaczkowski - 1.6-1 - updated to 1.6 - removed explicit libcddb dependency - broken too long desciption line banshee-1.0.0-2.fc10 -------------------- * Fri Jul 4 18:00:00 2008 Nigel Jones - 1.0.0-2 - Bump for new gnome-sharp cairo-dock-1.6.1-0.1.svn1173_trunk.fc10 --------------------------------------- * Sun Jul 6 18:00:00 2008 Mamoru Tasaka - rev. 1173 centerim-4.22.6-0.1.20080705git.fc10 ------------------------------------ * Sat Jul 5 18:00:00 2008 Lubomir Kundrak - 1:4.22.6-0.1.20080705git - Update to mobshot to exclude files with problematic copyright * Mon Apr 14 18:00:00 2008 Lubomir Kundrak - 1:4.22.5-1 - 4.22.5 with fixes for various Yahoo protocol crashes eric-4.1.6-1.fc10 ----------------- * Sat Jul 5 18:00:00 2008 Johan Cwiklinski 4.1.6-1 - 4.1.6 gbrainy-0.70-3.fc10 ------------------- * Sat Jul 5 18:00:00 2008 Beno??t Marcelin 0.70-3 - Rebuild with gnome-sharp-2.20 .pc fix * Fri Jul 4 18:00:00 2008 Beno??t Marcelin 0.70-2 - Rebuild for new gnome-sharp gfs-didot-classic-fonts-20080702-1.fc10 --------------------------------------- * Sun Jul 6 18:00:00 2008 Nicolas Mailhot - 20080702-1 ?? Upstream stealth update gnome-subtitles-0.8-4.fc10 -------------------------- * Sat Jul 5 18:00:00 2008 Julian Sikorski - 0.8-4 - Another rebuild - Patched SMP build failure grass-6.3.0-5.fc10 ------------------ * Sat Jul 5 18:00:00 2008 Balint Cristian 6.3.0-5 - address bz#454146 (wxPython miss) gtk2-2.13.4-1.fc10 ------------------ * Sat Jul 5 18:00:00 2008 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 icu-4.0-1.fc10 -------------- * Sat Jul 5 18:00:00 2008 Caolan McNamara - 4.0-1 - final release isomaster-1.3.3-1.fc10 ---------------------- * Tue Jul 1 18:00:00 2008 Marcin Zajaczkowski - 1.3.3-1 - updated to 1.3.3 * Sun Jun 29 18:00:00 2008 Marcin Zajaczkowski - 1.3.2-1 - updated to 1.3.2 jd-2.0.0-0.7.svn2175_trunk.fc10 ------------------------------- * Sun Jul 6 18:00:00 2008 Mamoru Tasaka - rev 2175 linuxdcpp-1.0.2-1.fc10 ---------------------- * Sun Jul 6 18:00:00 2008 Marcin Garski 1.0.2-1 - Update to 1.0.2 - Drop all patches (all upstream now) mapserver-5.0.3-3.fc10 ---------------------- * Sat Jul 5 18:00:00 2008 Balint Cristian 5.0.3-3 - address bz#453925 mysql++-3.0.4-1.fc10 -------------------- * Sat Jul 5 18:00:00 2008 Remi Collet 3.0.4-1 - update to 3.0.4 openoffice.org-3.0.0-0.0.22.1.fc10 ---------------------------------- * Tue Jul 1 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.22-1 - next version - drop integrated pseudoworkspace.valgrind1.patch - drop integrated openoffice.org-2.2.0.ooo73863.vcl.imcommit.patch - add workspace.cairo06.patch - add workspace.ab55.patch - Resolves: rhbz#453487 some font packages now gone openswan-2.6.15-1.fc10 ---------------------- * Sat Jul 5 18:00:00 2008 Steve Grubb - 2.6.15-1 - new upstream release perl-Module-Starter-1.470-1.fc10 -------------------------------- * Sat Jul 5 18:00:00 2008 Chris Weyl 1.470-1 - update to 1.470 pilot-link-0.12.3-14.fc10 ------------------------- * Sun Jun 15 18:00:00 2008 Kevin Page - 2:0.12.3-14 - corrected documentation for visor module use python-biopython-1.47-1.fc10 ---------------------------- * Fri Jul 4 18:00:00 2008 Alex Lancaster - 1.47-1 - Update to latest upstream (1.47) quassel-0.2.0-0.1.rc1.fc10 -------------------------- * Fri Jul 4 18:00:00 2008 Steven Parrish 0.1.rc1 - New upstream release. Now uses cmake instead of qmake shorewall-4.0.12-2.fc10 ----------------------- * Sat Jul 5 18:00:00 2008 Jonathan G. Underwood - 4.0.12-2 - Apply patch-perl-4.0.12.1 from upstream Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 23 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tomboy-0.11.0-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From guido.ledermann at googlemail.com Sun Jul 6 12:09:31 2008 From: guido.ledermann at googlemail.com (Guido Ledermann) Date: Sun, 6 Jul 2008 14:09:31 +0200 Subject: f-spot is orphaned: in danger of being removed from Fedora In-Reply-To: <1dedbbfc0807052008p795d6810j3cf9ed242b40a4d0@mail.gmail.com> References: <486F01DC.4090008@nigelj.com> <1dedbbfc0807051735h3dfca2a9g3b3cb80ed2bc01a5@mail.gmail.com> <1dedbbfc0807052008p795d6810j3cf9ed242b40a4d0@mail.gmail.com> Message-ID: <4ee84c5f0807060509u7a269c66xe18c103dc6c01a41@mail.gmail.com> 2008/7/6 David Nielsen : > So who is with me? Me! I would like to see mono and monodevelop and the libs as up to date as possible. I also can help with mono programs because c# & vb.net are currently my primary programming languages. Just give me a call. Guido From hun at n-dimensional.de Sun Jul 6 13:02:52 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 06 Jul 2008 15:02:52 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <484848A1.2030600@n-dimensional.de> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> Message-ID: <4870C27C.7020504@n-dimensional.de> A short reminder what this is about: %if "%{?fedora}" > "7" %endif This fails to work as intended in rawhide/devel/F10 and later and should be fixed. Summary for 2008-07-06 ---------------------- devel: 58 string comparisons in 32 spec files F-9: 78 string comparisons in 46 spec files F-8: 109 string comparisons in 56 spec files F-7: 118 string comparisons in 62 spec files The packages in rawhide will definitely be affected by this, might already be breaking stuff, and really should be fixed: http://ndim.fedorapeople.org/stuff/rpm/string-comp-devel.log Graphing the numbers over time shows a definite decrease in devel/rawhide/F10, but nothing approaching zero for a long time: http://ndim.fedorapeople.org/stuff/rpm/ -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Sun Jul 6 14:29:35 2008 From: paul at city-fan.org (Paul Howarth) Date: Sun, 6 Jul 2008 15:29:35 +0100 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <4870C27C.7020504@n-dimensional.de> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> <4870C27C.7020504@n-dimensional.de> Message-ID: <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> On Sun, 06 Jul 2008 15:02:52 +0200 Hans Ulrich Niedermann wrote: > A short reminder what this is about: > > %if "%{?fedora}" > "7" > > %endif > > This fails to work as intended in rawhide/devel/F10 and later and > should be fixed. > > Summary for 2008-07-06 > ---------------------- > devel: 58 string comparisons in 32 spec files > F-9: 78 string comparisons in 46 spec files > F-8: 109 string comparisons in 56 spec files > F-7: 118 string comparisons in 62 spec files > > The packages in rawhide will definitely be affected by this, might > already be breaking stuff, and really should be fixed: > > http://ndim.fedorapeople.org/stuff/rpm/string-comp-devel.log > > Graphing the numbers over time shows a definite decrease in > devel/rawhide/F10, but nothing approaching zero for a long time: > > http://ndim.fedorapeople.org/stuff/rpm/ > Some false positives here: lat lat.spec:14:%if "%{?fedora}" == "5" lat.spec:42:%if "%{?fedora}" == "5" lat.spec:111:%if "%{?fedora}" == "5" These are not a problem. Paul. From nicolas.mailhot at laposte.net Sun Jul 6 15:13:18 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 06 Jul 2008 17:13:18 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> <4870C27C.7020504@n-dimensional.de> <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> Message-ID: <1215357198.30824.10.camel@rousalka.okg> Le dimanche 06 juillet 2008 ? 15:29 +0100, Paul Howarth a ?crit : > Some false positives here: > > lat > lat.spec:14:%if "%{?fedora}" == "5" > lat.spec:42:%if "%{?fedora}" == "5" > lat.spec:111:%if "%{?fedora}" == "5" > > These are not a problem. Actually since FC5 has been EOLed for a long time, some legacy baggage cleaning up is in order. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From peter at thecodergeek.com Sun Jul 6 15:25:46 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 06 Jul 2008 08:25:46 -0700 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> <4870C27C.7020504@n-dimensional.de> <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> Message-ID: <1215357946.5346.2.camel@tuxhugs> On Sun, 2008-07-06 at 15:29 +0100, Paul Howarth wrote: > Some false positives here: > > lat > lat.spec:14:%if "%{?fedora}" == "5" > lat.spec:42:%if "%{?fedora}" == "5" > lat.spec:111:%if "%{?fedora}" == "5" > > These are not a problem. > Maybe not, but FC5 is long-since dead. Conditional cruft like that should probably just be outright removed. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 hun at n-dimensional.de Sun Jul 6 16:08:29 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 06 Jul 2008 18:08:29 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <1215357198.30824.10.camel@rousalka.okg> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> <4870C27C.7020504@n-dimensional.de> <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> <1215357198.30824.10.camel@rousalka.okg> Message-ID: <4870EDFD.5090002@n-dimensional.de> Nicolas Mailhot wrote: > Le dimanche 06 juillet 2008 ? 15:29 +0100, Paul Howarth a ?crit : > >> Some false positives here: >> >> lat >> lat.spec:14:%if "%{?fedora}" == "5" >> lat.spec:42:%if "%{?fedora}" == "5" >> lat.spec:111:%if "%{?fedora}" == "5" >> >> These are not a problem. > > Actually since FC5 has been EOLed for a long time, some legacy baggage > cleaning up is in order. Well, it is still useful at least as documentation for people wanting to build newer packages on older systems. Enterprise disto derivates, and standalone lab boxes running Fedora spring to mind. Apropos... I am not checking for improper %{epel} or %{rhel} usage, but some spec files contain conditionals with them. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From vpivaini at cs.helsinki.fi Sun Jul 6 16:21:07 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 6 Jul 2008 19:21:07 +0300 Subject: trying to build rpm for google gears In-Reply-To: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> References: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> Message-ID: <200807061921.08891.vpivaini@cs.helsinki.fi> David Van Assche wrote: > It > was suggested to me that I should post here to see if someone doesn't have > some suggestions on building an rpm for mozilla (xulrunner 1.9) based > extensions... > I am aware that gears is normally packaed as a .xpi, but that wont work > for the XO laptops... it must be a rpm that I can install system wide from > the command line. Hi, I don't know that much about Xulrunner and even less about the OLPC software stack, but I have packaged one xulrunner-based Firefox extension, which is currently under review. The spec file is at . >From the website I understood that Google Gears is a Firefox extension on the client side. Does the OLPC actually use Firefox or some other Mozilla based browser? The .xpi file is basically "just" a renamed zip file, so you need to extract it and then install the files to the "correct" location, which depends on the browser used. In the case of the mozvoikko extension I use %{_libdir}/mozilla/extensions/%{firefox_app_id}/%{firefox_ext_id}, where %{firefox_app_id} is ec8030f7-c20a-464f-9b0e-13a3a9e97384 (Firefox's ID) and %{firefox_ext_id} is the ID of the extension (ok, the naming is a bit misleading here ;). I hope this helps, at least a little. -- Ville-Pekka Vainio From hun at n-dimensional.de Sun Jul 6 16:21:08 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 06 Jul 2008 18:21:08 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> <483BCE11.7060804@n-dimensional.de> <484848A1.2030600@n-dimensional.de> <4870C27C.7020504@n-dimensional.de> <20080706152935.1d81ba4d@metropolis.intra.city-fan.org> Message-ID: <4870F0F4.3020701@n-dimensional.de> Paul Howarth wrote: > On Sun, 06 Jul 2008 15:02:52 +0200 > Hans Ulrich Niedermann wrote: >> Summary for 2008-07-06 >> ---------------------- >> devel: 58 string comparisons in 32 spec files >> F-9: 78 string comparisons in 46 spec files >> F-8: 109 string comparisons in 56 spec files >> F-7: 118 string comparisons in 62 spec files > Some false positives here: > > lat > lat.spec:14:%if "%{?fedora}" == "5" > lat.spec:42:%if "%{?fedora}" == "5" > lat.spec:111:%if "%{?fedora}" == "5" > > These are not a problem. Technically speaking, they are not a problem, right. Until someone gets the idea that he wants >= instead of ==. Whetever, strictly requiring a < or > in the conditional, the situation changes to the following: Summary for 2008-07-06 ---------------------- devel: 48 string comparisons in 28 spec files F-9: 68 string comparisons in 42 spec files F-8: 91 string comparisons in 53 spec files F-7: 95 string comparisons in 58 spec files Updated details, diagrams, etc. on http://ndim.fedorapeople.org/stuff/rpm/ -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Sun Jul 6 16:31:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 06 Jul 2008 18:31:00 +0200 Subject: Easy reviews? In-Reply-To: <1215105452.32479.2.camel@rousalka.okg> References: <486CBA14.7060202@fedoraproject.org> <1215105452.32479.2.camel@rousalka.okg> Message-ID: <1215361860.30824.12.camel@rousalka.okg> Le jeudi 03 juillet 2008 ? 19:17 +0200, Nicolas Mailhot a ?crit : > Le jeudi 03 juillet 2008 ? 10:24 -0500, Jason L Tibbitts III a ?crit : > > > In any case, I fear we've mostly scoured the list of really easy > > things; perl modules tend to be very simple since most of them are > > mechanically generated; python modules are almost as easy. > > Fonts are also rather easy to review (and often to package, the hard > work is finding correctly licensed fonts, or dumping problems on legal), > but there are not a lot of people working on > http://fedoraproject.org/wiki/Category:Font_wishlist Some more easy reviews: https://bugzilla.redhat.com/show_bug.cgi?id=454171 https://bugzilla.redhat.com/show_bug.cgi?id=454172 https://bugzilla.redhat.com/show_bug.cgi?id=454174 https://bugzilla.redhat.com/show_bug.cgi?id=454175 https://bugzilla.redhat.com/show_bug.cgi?id=454176 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kevin.kofler at chello.at Sun Jul 6 19:49:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 6 Jul 2008 19:49:33 +0000 (UTC) Subject: f-spot is orphaned: in danger of being removed from Fedora References: <486F01DC.4090008@nigelj.com> Message-ID: Alex Lancaster users.sourceforge.net> writes: > OK, thanks for the explanation, but my mono skills are weak to > non-existent so I'm not about to go try patching the > generator... hopefully somebody else will jump in. Basically you or whoever is going to fix this only has to locate the string "result" and change it to something else. Kevin Kofler From jeff at ocjtech.us Sun Jul 6 20:05:50 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sun, 6 Jul 2008 15:05:50 -0500 Subject: source file audit - 2008-07-05 In-Reply-To: <20080705141930.5f42d27f@ohm.scrye.com> References: <20080705141930.5f42d27f@ohm.scrye.com> Message-ID: <935ead450807061305h4f2e2580j99c7d761ab4c0c34@mail.gmail.com> 2008/7/5 Kevin Fenzi : > > jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr > jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis These two packages have been marked as dead and have been blocked from rawhide, I'm not sure why these are still being checked. > jcollie:BADURL:sofia-sip-1.12.9.tar.gz:sofia-sip I'm not sure why this is marked as having a bad URL, as I was able to download the source tarball just fine. Is it because the source url differs from the "canonical" sourceforge URL? Jeff From dvanassche at gmail.com Sun Jul 6 20:32:42 2008 From: dvanassche at gmail.com (David Van Assche) Date: Sun, 6 Jul 2008 22:32:42 +0200 Subject: trying to build rpm for google gears In-Reply-To: <200807061921.08891.vpivaini@cs.helsinki.fi> References: <8cc423ef0807051258jece8dc8w575667714f10f650@mail.gmail.com> <200807061921.08891.vpivaini@cs.helsinki.fi> Message-ID: <8cc423ef0807061332qcc16d82r8cee8baa6cffd293@mail.gmail.com> Hi Ville-Pekka Vainio, It does indeed. A thousand thanks... I've managed to compile the build from an subversion source on both Fedora and Ubuntu now, and looking at the files, there are way more in the build than there are in an unzipped gears.xpi. But I'm sure I've got enough to work on now. The XO browser (called browse) is actually very closely related to Firefox 3 (and uses XULRunner 1.9) so using its id as u mention should work... Thanks, David Van Assche On Sun, Jul 6, 2008 at 6:21 PM, Ville-Pekka Vainio wrote: > David Van Assche wrote: > > It > > was suggested to me that I should post here to see if someone doesn't > have > > some suggestions on building an rpm for mozilla (xulrunner 1.9) based > > extensions... > > I am aware that gears is normally packaed as a .xpi, but that wont > work > > for the XO laptops... it must be a rpm that I can install system wide > from > > the command line. > > Hi, > > I don't know that much about Xulrunner and even less about the OLPC > software > stack, but I have packaged one xulrunner-based Firefox extension, which is > currently under review. The spec file is at > . > > >From the website I understood that Google Gears is a Firefox extension on > the > client side. Does the OLPC actually use Firefox or some other Mozilla based > browser? > > The .xpi file is basically "just" a renamed zip file, so you need to > extract > it and then install the files to the "correct" location, which depends on > the > browser used. In the case of the mozvoikko extension I > use %{_libdir}/mozilla/extensions/%{firefox_app_id}/%{firefox_ext_id}, > where %{firefox_app_id} is ec8030f7-c20a-464f-9b0e-13a3a9e97384 (Firefox's > ID) and %{firefox_ext_id} is the ID of the extension (ok, the naming is a > bit > misleading here ;). I hope this helps, at least a little. > > > -- > Ville-Pekka Vainio > > -- > 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 davej at redhat.com Sun Jul 6 21:36:54 2008 From: davej at redhat.com (Dave Jones) Date: Sun, 6 Jul 2008 17:36:54 -0400 Subject: kernel build failures. Message-ID: <20080706213654.GB14554@redhat.com> The kernel build started failing a few days ago, but due to the holidays, I only just got around to looking at it. Here's how it's failing.. + make mandocs DOCPROC Documentation/DocBook/wanbook.xml MAN Documentation/DocBook/wanbook.9 xmlto: input does not validate (status 3) /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> ^ warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" Document /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml does not validate I believe what's happening here is that the builders don't have access to the internet, so it's failing to download the DTD. This has been the case always though, so I'm not sure why it started failing now. Perhaps xmlto only recently started trying to retrieve the DTD ? I'm not sure how to go about fixing this. I could just add a copy of the dtd to cvs, and edit the .xml files to point to the local copies instead of trying to retrieve online ones, but this sucks because - it's one more thing to keep track of to make sure it's kept up to date - it's one more set of patches that we'll perpetually have to carry against the kernel that won't go upstream. The only other alternative I see is to stop building the man pages, which also sucks, given it was a fairly recent (and worthwhile) addition. Any thoughts? Dave -- http://www.codemonkey.org.uk From mrsam at courier-mta.com Sun Jul 6 22:32:06 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 06 Jul 2008 18:32:06 -0400 Subject: kernel build failures. References: <20080706213654.GB14554@redhat.com> Message-ID: Dave Jones writes: > + make mandocs > DOCPROC Documentation/DocBook/wanbook.xml > MAN Documentation/DocBook/wanbook.9 > xmlto: input does not validate (status 3) > /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> > ^ > warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > Document /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml does not validate > > > I believe what's happening here is that the builders don't have access to the internet, > so it's failing to download the DTD. I do not believe that this is the problem. It looks like xmlto always invokes xsltproc with the --nonet parameter, and xsltproc was always able to load the locally-installed Docbook DTDS, just fine. A brief look reveals that this looks like a recent breakage between the xml-common and docbook-dtds rpms. When the docbook-dtds rpm gets installed, it adds all the Docbook DTDs to /usr/share/sgml/docbook/xmlcatalog, in its %post script. Unfortunately, an update to xml-common was pushed out last week, which reinstalled a completely empty /usr/share/sgml/docbook/xmlcatalog file. * Splat * -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From promac at gmail.com Sun Jul 6 23:27:03 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 6 Jul 2008 20:27:03 -0300 Subject: pm-utils for F8 and Advanced power management Message-ID: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> I am trying to fix the Load_Cycle_Count bug that is increasing at a very fast pace each day on my laptop running F8. Suddenly, I realized that apparently the version of pm-utils for F9 has a kook to deal with it: 99hd-apm-restore.hook and /etc/pm-utils-hd-apm-restore.conf Why was not this ported to F8? The problem, as I understand, is quiet serious, and can kill the drive in one or two years. F8 is still maintained, right? -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ottohaliburton at tx.rr.com Sun Jul 6 23:48:54 2008 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Sun, 6 Jul 2008 18:48:54 -0500 Subject: kernel build failures. In-Reply-To: <20080706213654.GB14554@redhat.com> References: <20080706213654.GB14554@redhat.com> Message-ID: <4944ABA5374F44EFAB2BFEB506B9A9D4@ottoPC> here is a suggestion, check previous kernel builds to see if they have started to fail, if not then the problem is isolated to the current kernel, else something has been brokien elsewhere ----- Original Message ----- From: "Dave Jones" To: Sent: Sunday, July 06, 2008 4:36 PM Subject: kernel build failures. > The kernel build started failing a few days ago, but due > to the holidays, I only just got around to looking at it. > Here's how it's failing.. > > + make mandocs > DOCPROC Documentation/DocBook/wanbook.xml > MAN Documentation/DocBook/wanbook.9 > xmlto: input does not validate (status 3) > /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml:3: > warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> > ^ > warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > validity error : Could not load the external subset > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > Document > /builddir/build/BUILD/kernel-2.6.25/linux-2.6.25.noarch/Documentation/DocBook/wanbook.xml > does not validate > > > I believe what's happening here is that the builders don't have access to > the internet, > so it's failing to download the DTD. This has been the case always > though, so I'm > not sure why it started failing now. Perhaps xmlto only recently started > trying to > retrieve the DTD ? > > I'm not sure how to go about fixing this. > I could just add a copy of the dtd to cvs, and edit the .xml files > to point to the local copies instead of trying to retrieve online ones, > but this sucks because > - it's one more thing to keep track of to make sure it's kept up to date > - it's one more set of patches that we'll perpetually have to carry > against > the kernel that won't go upstream. > > The only other alternative I see is to stop building the man pages, which > also > sucks, given it was a fairly recent (and worthwhile) addition. > > Any thoughts? > > Dave > > -- > http://www.codemonkey.org.uk > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From bruno at wolff.to Mon Jul 7 02:20:07 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 6 Jul 2008 21:20:07 -0500 Subject: kernel build failures. In-Reply-To: <20080706213654.GB14554@redhat.com> References: <20080706213654.GB14554@redhat.com> Message-ID: <20080707022007.GA9073@wolff.to> On Sun, Jul 06, 2008 at 17:36:54 -0400, Dave Jones wrote: > The kernel build started failing a few days ago, but due > to the holidays, I only just got around to looking at it. > Here's how it's failing.. > > I believe what's happening here is that the builders don't have access to the internet, > so it's failing to download the DTD. This has been the case always though, so I'm > not sure why it started failing now. Perhaps xmlto only recently started trying to > retrieve the DTD ? I don't think it is supposed to do that. I had a similar problem rendering some other document and I think my catalog entries were messed up so that it wasn't find the local copies. I would suggest checking the corrent xml package(s) is installed and that the catalog looks OK. From bruno at wolff.to Mon Jul 7 02:25:37 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 6 Jul 2008 21:25:37 -0500 Subject: kernel build failures. In-Reply-To: References: <20080706213654.GB14554@redhat.com> Message-ID: <20080707022537.GB9073@wolff.to> On Sun, Jul 06, 2008 at 18:32:06 -0400, Sam Varshavchik wrote: > Dave Jones writes: > > I do not believe that this is the problem. It looks like xmlto always > invokes xsltproc with the --nonet parameter, and xsltproc was always able > to load the locally-installed Docbook DTDS, just fine. > > A brief look reveals that this looks like a recent breakage between the > xml-common and docbook-dtds rpms. > > When the docbook-dtds rpm gets installed, it adds all the Docbook DTDs to > /usr/share/sgml/docbook/xmlcatalog, in its %post script. It would be nice if this was redesigned so that each package put its data in a separate file rather than mixing stuff. That is the direction most config files have been going when multiple packages need to add data. The current system doesn't let you tell if the docbook stuff is installed correctly (using rpm -V) because of the files that multiple packages update. From jmorris at namei.org Mon Jul 7 02:42:52 2008 From: jmorris at namei.org (James Morris) Date: Mon, 7 Jul 2008 12:42:52 +1000 (EST) Subject: Request to re-add option to disable SELinux In-Reply-To: <1215199155.3816.33.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <1215196478.353.243.camel@localhost.localdomain> <1215199155.3816.33.camel@roadrunner.itnet.am> Message-ID: On Sat, 5 Jul 2008, Suren Karapetyan wrote: > SELinux isn't just a specific setting... It's a bit too big. > It's a feature 38.7% of systems in smolt have disabled... > Removing that combobox is like telling this 38.7% (203150) > "know what... the other 61.3% (321879) don't like *seeing* choice of > disabling SELinux during install... You'll have to do it after install." Don't believe everything you read. The 61.3% figure is probably lower than the real figure (by quite a lot) because many systems reported in before SELinux was part of the smolt stats and are counted as "disabled". (It would be nice to have a disclaimer on that page...) > > > > Let's be less selfish guys and look at the bigger picture. > That's what I do. :) > > > > If you know you don't need SELinux for whatever reason you can simply > > disable it after installation (or in kickstart if you do automated > > installations). > > > > If you are a Fedora developer and disable it by default to "develop" > > packages than I honestly think you are poorly executing your task. > > You should set it to permissive only when you get some "access denied" > > problem while testing the specific changes, and as soon as you are happy > > with it and ready to push a new package, you should FIRST set?? SELinux > > back to Enalbled and (working with Dan if necessary) make sure your > > package pass again all your tests. > > Not doing so you are making a disservice to the Fedora community, > > because if you don't test with SELinux on then you don't know if your > > stuff will work with it enabled, and you will create a bad experience > > for other developers and users. > Agree. It's like building a package and not checking if it works on > x86... > But I'm not a Fedora developer (yet). > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > -- James Morris From moe at blagblagblag.org Mon Jul 7 05:32:06 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 02:32:06 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215030141.17856.30.camel@localhost.localdomain> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> Message-ID: <4871AA56.3000302@blagblagblag.org> >> But there are numerous other justifications I could give, including my >> personal belief that it's absolutely nuts to thrust SE Linux upon >> unsuspecting Desktop users (who don't know what it is anyway) without >> giving them the choice to turn it off. > > If they don't know what it is, how are they supposed to decide to shut > it off or not? Perhaps by way of a compromise it could be noted in the installation docs if you want to disable SELinux you should add "linux selinux=0" to the boot: line of the install CD. This would make the option available the same way that xfs/reiserfs/jfs are available. The user isn't confronted with it, but Linus[1] can then easily disable it at install time. For this to work, anaconda would have to then pass the selinux=0 to grub. Benefits: * Users aren't confronted with dialog box they don't understand * Power users that "know" they don't need/want selinux still have it available * Only needs small change to anaconda * All win Drawbacks: * Nonewhatsoever ;) -Jeff [1] https://bugzilla.redhat.com/show_bug.cgi?id=439858 From nphilipp at redhat.com Mon Jul 7 07:42:39 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 07 Jul 2008 09:42:39 +0200 Subject: source file audit - 2008-07-05 In-Reply-To: <20080705141930.5f42d27f@ohm.scrye.com> References: <20080705141930.5f42d27f@ohm.scrye.com> Message-ID: <1215416559.23660.10.camel@wombat.tiptoe.de> On Sat, 2008-07-05 at 14:19 -0600, Kevin Fenzi wrote: > nphilipp:BADSOURCE:gtkimageview-1.5.0.tar.gz:gtkimageview The problem with that source is that it is an attachment to a Trac wiki page. The real URL for it is: http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/gtkimageview-%{version}.tar.gz?format=raw while this one... http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/gtkimageview-%{version}.tar.gz ... lets only offers an explanation why it can't display the file directly and a link to download it. For the time being I've changed the source to not being a URL at all. Panu, are there any plans in rpmbuild to ignore the CGI-variable stuff from source/patch URLs? Then I could just use the real URL, as ugly as it is ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From sundaram at fedoraproject.org Mon Jul 7 07:58:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 07 Jul 2008 13:28:40 +0530 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4871AA56.3000302@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> Message-ID: <4871CCB0.6030508@fedoraproject.org> jeff wrote: >>> But there are numerous other justifications I could give, including my >>> personal belief that it's absolutely nuts to thrust SE Linux upon >>> unsuspecting Desktop users (who don't know what it is anyway) without >>> giving them the choice to turn it off. >> >> If they don't know what it is, how are they supposed to decide to shut >> it off or not? > > Perhaps by way of a compromise it could be noted in the installation > docs if you want to disable SELinux you should add "linux selinux=0" to > the boot: line of the install CD. This would make the option available > the same way that xfs/reiserfs/jfs are available. The user isn't > confronted with it, but Linus[1] can then easily disable it at install > time. The policy has already been fixed and swfdec isn't installed by default so there is no need to do that. It is already documented in the SELinux FAQ now but installation guide can have a reference too. File a RFE. Rahul From maximilianbianco at gmail.com Mon Jul 7 08:32:29 2008 From: maximilianbianco at gmail.com (max bianco) Date: Mon, 7 Jul 2008 04:32:29 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4871CCB0.6030508@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: On Mon, Jul 7, 2008 at 3:58 AM, Rahul Sundaram wrote: > jeff wrote: >>>> >>>> But there are numerous other justifications I could give, including my >>>> personal belief that it's absolutely nuts to thrust SE Linux upon >>>> unsuspecting Desktop users (who don't know what it is anyway) without >>>> giving them the choice to turn it off. >>> >>> If they don't know what it is, how are they supposed to decide to shut >>> it off or not? >> >> Perhaps by way of a compromise it could be noted in the installation docs >> if you want to disable SELinux you should add "linux selinux=0" to the boot: >> line of the install CD. This would make the option available the same way >> that xfs/reiserfs/jfs are available. The user isn't confronted with it, but >> Linus[1] can then easily disable it at install time. > > The policy has already been fixed and swfdec isn't installed by default so > there is no need to do that. It is already documented in the SELinux FAQ now > but installation guide can have a reference too. File a RFE. > > Rahul > Can an option to completely disable the ability to disable SELinux be added? I'd rather there was no way to turn it off at all. Max -- If opinions were really like assholes we'd each have just one From nicolas.mailhot at laposte.net Mon Jul 7 08:42:24 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jul 2008 10:42:24 +0200 (CEST) Subject: kernel build failures. In-Reply-To: <20080706213654.GB14554@redhat.com> References: <20080706213654.GB14554@redhat.com> Message-ID: <38230.192.54.193.59.1215420144.squirrel@rousalka.dyndns.org> Le Dim 6 juillet 2008 23:36, Dave Jones a ?crit : > > I believe what's happening here is that the builders don't have access > to the internet, so it's failing to download the DTD. > This has been the case always though, so I'm > not sure why it started failing now. Perhaps xmlto only recently > started trying to retrieve the DTD ? > > I'm not sure how to go about fixing this. The correct way is to have a local copy which is referenced in an xml catalog and used by the xml tools. Documentation sources need not be modified if the XML tools are written properly. (Auto-downloading is generally considered a tool bug.) The docbook dtds are packaged in Fedora so you only need to add this package to BRs, and use XML tools smart enough to use the XML catalog entries this package installs. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Jul 7 08:48:16 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jul 2008 10:48:16 +0200 (CEST) Subject: kernel build failures. In-Reply-To: <20080707022537.GB9073@wolff.to> References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> Message-ID: <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> Le Lun 7 juillet 2008 04:25, Bruno Wolff III a ?crit : > It would be nice if this was redesigned so that each package put its > data in a separate file rather than mixing stuff. That's mostly the case today. The catalog is just an index file with 1-line references to package-specific data -- Nicolas Mailhot From thomas.moschny at gmail.com Mon Jul 7 08:57:27 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Mon, 7 Jul 2008 10:57:27 +0200 Subject: kernel build failures. In-Reply-To: <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> Message-ID: 2008/7/7 Nicolas Mailhot : > > Le Lun 7 juillet 2008 04:25, Bruno Wolff III a ?crit : > >> It would be nice if this was redesigned so that each package put its >> data in a separate file rather than mixing stuff. > > That's mostly the case today. The catalog is just an index file with > 1-line references to package-specific data But unless there's an easy way to cleanly rebuild this index from scratch, that's still as bad as embedding (mixing) all data in one single file. The DTDs/schemas are not found when not mentioned in the catalog, right? - Thomas From dominik at greysector.net Mon Jul 7 08:59:41 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 Jul 2008 10:59:41 +0200 Subject: openbabel SO version bump Message-ID: <20080707085941.GA11342@mokona.greysector.net> Having packaged 2.2.0 beta, I wanted to update to 2.2.0 release when it was released. However, I didn't notice the SO version bump (libopenbabel.so.2 -> libopenbabel.so.3), so the new version is already in rawhide. I'm sorry about that. There shouldn't be any problems with rebuilding applications against the full 2.2.0 release, so please do just that. Affected packages: gchempaint gnome-chemistry-utils kdeedu xdrawchem I'll handle xdrawchem myself. I can also rebuild the other packages if their respective maintainers don't do that by Sunday. I'd like to update F-9's openbabel, too. An updated build is available in koji (I've revoked the request to push the update to testing for now). http://koji.fedoraproject.org/koji/buildinfo?buildID=54966 I ask the maintainers of the above packages to test if their F-9 packages build and work with openbabel-2.2.0 (they should). I'd like to have a combined update ready by Sunday, too. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rawhide at fedoraproject.org Mon Jul 7 09:04:34 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 7 Jul 2008 09:04:34 +0000 (UTC) Subject: rawhide report: 20080707 changes Message-ID: <20080707090434.87C8E209D30@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080706/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080707/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package ikiwiki A wiki compiler New package trustyrc Fully modular IRC robot Updated Packages: echo-icon-theme-0.3.89.0-0.6.git2e822bf.fc10 -------------------------------------------- * Sun Jul 6 18:00:00 2008 Martin Sourada - 0.3.89.0-0.6.git2e822bf - New git snapshot electronics-menu-1.0-2.fc10 --------------------------- * Sun Jul 6 18:00:00 2008 Chitlesh Goorah - 1.0-2 - Corrected yum install with requires(pre) erlang-R12B-3.1.fc10 -------------------- * Sun Jul 6 18:00:00 2008 Gerard Milmeister - R12B-3.1 - new release R12B-3 fatsort-0.9.8.2-2.fc10 ---------------------- * Mon Jul 7 18:00:00 2008 Till Maas - 0.9.8.2-2 - Fix CFLAGS handling in the Makefile (Red Hat Bug #454212) frozen-bubble-2.1.0-9.fc10 -------------------------- * Sun Jul 6 18:00:00 2008 Hans de Goede 2.1.0-9 - Fix audio on bigendian archs (bz 454109), patch by Ian Chapman jd-2.0.0-0.7.svn2179_trunk.fc10 ------------------------------- * Mon Jul 7 18:00:00 2008 Mamoru Tasaka - rev 2179 libao-0.8.8-5.fc10 ------------------ * Sun Jul 6 18:00:00 2008 Hans de Goede - 0.8.8-5 - Fix pulseaudio sound output on bigendian archs (bz 454165), patch by Ian Chapman libusb1-0.9.1-1.fc10 -------------------- * Sun Jul 6 18:00:00 2008 - Bastien Nocera - 0.9.1 - Update to 0.9.1 openbabel-2.2.0-1.fc10 ---------------------- * Sun Jul 6 18:00:00 2008 Dominik Mierzejewski 2.2.0-1 - updated to 2.2.0 - new URL - dropped Python binding split patch (broken, reverted upstream) - fixed testsuite and disabled inchi tests temporarily - added strict perl version requirements (patch by Paul Howarth, bug #453120) - fixed some rpmlint warnings - merged a sed call into -rpm patch python-tempita-0.2-2.fc10 ------------------------- * Mon Jul 7 18:00:00 2008 Ricky Zhou - 0.2-2 - Add %check section. sipp-3.1-2.fc10 --------------- * Sun Jul 6 18:00:00 2008 Peter Lemenkov 3.1-2 - CVE-2008-2085 xemacs-21.5.28-8.fc10 --------------------- * Sun Jul 6 18:00:00 2008 Ville Skytt?? - 21.5.28-8 - Apply upstream fix for detection of 3D Athena widget sets. * Sun Jul 6 18:00:00 2008 Ville Skytt?? - 21.5.28-7 - Fix build with autoconf >= 2.62 (#449626). Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 12 Broken deps for i386 ---------------------------------------------------------- bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.i386 requires libgnutls.so.13 buoh-0.8.2-4.fc9.i386 requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.i386 requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gchempaint-0.8.7-2.fc9.i386 requires libopenbabel.so.2 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-chemistry-utils-0.8.7-1.fc9.i386 requires libopenbabel.so.2 gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.i386 requires libopenbabel.so.2 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 kdeedu-4.0.84-1.fc10.i386 requires libopenbabel.so.2 kdeedu-devel-4.0.84-1.fc10.i386 requires libopenbabel.so.2 kdeedu-libs-4.0.84-1.fc10.i386 requires libopenbabel.so.2 libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.i386 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xdrawchem-1.9.9-10.fc10.i386 requires libopenbabel.so.2 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.x86_64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gchempaint-0.8.7-2.fc9.x86_64 requires libopenbabel.so.2()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-chemistry-utils-0.8.7-1.fc9.i386 requires libopenbabel.so.2 gnome-chemistry-utils-0.8.7-1.fc9.x86_64 requires libopenbabel.so.2()(64bit) gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.x86_64 requires libopenbabel.so.2()(64bit) gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 kdeedu-4.0.84-1.fc10.i386 requires libopenbabel.so.2 kdeedu-4.0.84-1.fc10.x86_64 requires libopenbabel.so.2()(64bit) kdeedu-devel-4.0.84-1.fc10.i386 requires libopenbabel.so.2 kdeedu-devel-4.0.84-1.fc10.x86_64 requires libopenbabel.so.2()(64bit) kdeedu-libs-4.0.84-1.fc10.i386 requires libopenbabel.so.2 kdeedu-libs-4.0.84-1.fc10.x86_64 requires libopenbabel.so.2()(64bit) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.i386 requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.x86_64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tomboy-0.11.0-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.x86_64 requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xdrawchem-1.9.9-10.fc10.x86_64 requires libopenbabel.so.2()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) bitlbee-1.2-1.fc9.ppc requires libgnutls.so.13 buoh-0.8.2-4.fc9.ppc requires libgnutls.so.13 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 drivel-2.1.1-0.5.20071130svn.fc9.ppc requires libgnutls.so.13 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gchempaint-0.8.7-2.fc9.ppc requires libopenbabel.so.2 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-chemistry-utils-0.8.7-1.fc9.ppc requires libopenbabel.so.2 gnome-chemistry-utils-0.8.7-1.fc9.ppc64 requires libopenbabel.so.2()(64bit) gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.ppc requires libopenbabel.so.2 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 kdeedu-4.0.84-1.fc10.ppc requires libopenbabel.so.2 kdeedu-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) kdeedu-devel-4.0.84-1.fc10.ppc requires libopenbabel.so.2 kdeedu-devel-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) kdeedu-libs-4.0.84-1.fc10.ppc requires libopenbabel.so.2 kdeedu-libs-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13(GNUTLS_1_3) libsoup22-2.2.105-2.fc9.ppc requires libgnutls.so.13 libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tomboy-0.11.0-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 tomboy-0.11.0-3.fc10.ppc requires mono(gconf-sharp-peditors) = 0:2.16.0.0 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xdrawchem-1.9.9-10.fc10.ppc requires libopenbabel.so.2 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13()(64bit) bitlbee-1.2-1.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) buoh-0.8.2-4.fc9.ppc64 requires libgnutls.so.13()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires libgnutls.so.13()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gchempaint-0.8.7-2.fc9.ppc64 requires libopenbabel.so.2()(64bit) gnome-chemistry-utils-0.8.7-1.fc9.ppc64 requires libopenbabel.so.2()(64bit) gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.ppc64 requires libopenbabel.so.2()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) kdeedu-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) kdeedu-devel-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) kdeedu-libs-4.0.84-1.fc10.ppc64 requires libopenbabel.so.2()(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) libsoup22-2.2.105-2.fc9.ppc64 requires libgnutls.so.13()(64bit) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xdrawchem-1.9.9-10.fc10.ppc64 requires libopenbabel.so.2()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From mail at robertoragusa.it Mon Jul 7 09:12:18 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 07 Jul 2008 11:12:18 +0200 Subject: Why is relatime immune to remount? Message-ID: <4871DDF2.5040102@robertoragusa.it> Hi, my root filesystem is mounted with the option relatime for some reason (I just have defaults in /etc/fstab). Any attempt to temporarily disable the option fails, even with norelatime, which appears to be a valid option. Is this expected or a bug? (fedora 9 with 2.6.25.3-18) [root at thinkpad ~]# cat /proc/mounts |grep /dev/root /dev/root / reiserfs rw,relatime 0 0 [root at thinkpad ~]# mount / -o remount,norelatime [root at thinkpad ~]# cat /proc/mounts |grep /dev/root /dev/root / reiserfs rw,relatime 0 0 [root at thinkpad ~]# mount / -o remount,atime [root at thinkpad ~]# cat /proc/mounts |grep /dev/root /dev/root / reiserfs rw,relatime 0 0 [root at thinkpad ~]# mount / -o remount,noatime [root at thinkpad ~]# cat /proc/mounts |grep /dev/root /dev/root / reiserfs rw,noatime,relatime 0 0 [root at thinkpad ~]# mount / -o remount,atime [root at thinkpad ~]# cat /proc/mounts |grep /dev/root /dev/root / reiserfs rw,relatime 0 0 [root at thinkpad ~]# mount / -o remount,nonononononorelatime mount: / not mounted already, or bad option -- Roberto Ragusa mail at robertoragusa.it From sundaram at fedoraproject.org Mon Jul 7 09:27:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 07 Jul 2008 14:57:58 +0530 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: <4871E19E.7070007@fedoraproject.org> max bianco wrote: > Can an option to completely disable the ability to disable SELinux be > added? I'd rather there was no way to turn it off at all. Sure, there is. Refer https://fedoraproject.org/wiki/SELinux/FAQ Rahul From rjones at redhat.com Mon Jul 7 09:47:04 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 10:47:04 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG Message-ID: <20080707094704.GA5497@amd.home.annexia.org> I would like to propose a new SIG for Fedora: https://fedoraproject.org/wiki/SIGs/MinGW The mission is to provide a MinGW-based cross-compiler and some common libraries so that Fedora users will be able to cross-compile software targeting Windows. The aim will be that, just using a Fedora host and completely free software, you will be able to produce Windows *.DLLs and *.EXEs. The three initial contributors, myself, Dan Berrange and Daniel Veillard, are primarily interested in providing a libvirt client library and some libvirt-based tools for Windows users (so that they will be able to manage Linux systems running libvirtd remotely). However we think that a cross-compiler could have much wider interest in the Fedora community. Debian provide the MinGW cross-compiler & binutils already. We are proposing to go further, by providing not just the cross-compiler & binutils, but common libraries too. For example, building libvirt requires GnuTLS and libxml2. In doing this we would like to leverage the work done already by Callum Lerwick (http://www.haxxed.com/rpms/). We believe that there is no other viable alternative to the cross-compiler (eg. using a 'Windows secondary arch') since any alternatives would require non-free software. Note that this requires shipping Windows DLLs (built from free software, NOT proprietary DLLs). AIUI it is not possible to build (eg.) libvirt.dll unless gnutls.dll was available already. Many aspects of this are open for discussion - eg. naming conventions for RPMs, paths for DLLs, name of the compiler & binutils, should we only target i686, etc etc. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Mon Jul 7 10:03:23 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 11:03:23 +0100 Subject: Broken deps in F8/F9 Message-ID: <20080707100323.GA5561@amd.home.annexia.org> Recently it was brought to my attention that some OCaml packages had broken deps in Fedora 8. True enough, and once it was pointed out to me I fixed them straightaway. However, is there a way to get an email / 'Rawhide' report to identify broken deps automatically in non-Rawhide branches of Fedora? 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 denis at poolshark.org Mon Jul 7 10:16:39 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 07 Jul 2008 12:16:39 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: <4871ED07.7050904@poolshark.org> max bianco wrote: > Can an option to completely disable the ability to disable SELinux be > added? I'd rather there was no way to turn it off at all. that doesn't make *any* sense From ingvar at linpro.no Mon Jul 7 10:33:32 2008 From: ingvar at linpro.no (Ingvar Hagelund) Date: Mon, 7 Jul 2008 12:33:32 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4871CCB0.6030508@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: <85960DB4-AED4-4CB1-90E5-D04F70307B6B@linpro.no> This would need a bit more hacking to Anaconda, but what about an "Expert security settings" dialog with a note that most users should leave these untouched. In this dialog, experienced sysadmins may switch off selinux, tweak or disable the firewall, and praps other stuff too. Ingvar -- Buddha wears an iPod Den 7. juli. 2008 kl. 09.58 skrev Rahul Sundaram : > jeff wrote: >>>> But there are numerous other justifications I could give, >>>> including my >>>> personal belief that it's absolutely nuts to thrust SE Linux upon >>>> unsuspecting Desktop users (who don't know what it is anyway) >>>> without >>>> giving them the choice to turn it off. >>> >>> If they don't know what it is, how are they supposed to decide to >>> shut >>> it off or not? >> Perhaps by way of a compromise it could be noted in the >> installation docs if you want to disable SELinux you should add >> "linux selinux=0" to the boot: line of the install CD. This would >> make the option available the same way that xfs/reiserfs/jfs are >> available. The user isn't confronted with it, but Linus[1] can then >> easily disable it at install time. > > The policy has already been fixed and swfdec isn't installed by > default so there is no need to do that. It is already documented in > the SELinux FAQ now but installation guide can have a reference too. > File a RFE. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jonathan.underwood at gmail.com Mon Jul 7 10:54:18 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 Jul 2008 11:54:18 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707094704.GA5497@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> Message-ID: <645d17210807070354m29cb3dddvbba6175b13510153@mail.gmail.com> 2008/7/7 Richard W.M. Jones : > I would like to propose a new SIG for Fedora: > > https://fedoraproject.org/wiki/SIGs/MinGW > > The mission is to provide a MinGW-based cross-compiler and some common > libraries so that Fedora users will be able to cross-compile software > targeting Windows. The aim will be that, just using a Fedora host and > completely free software, you will be able to produce Windows *.DLLs > and *.EXEs. > > The three initial contributors, myself, Dan Berrange and Daniel > Veillard, are primarily interested in providing a libvirt client > library and some libvirt-based tools for Windows users (so that they > will be able to manage Linux systems running libvirtd remotely). > However we think that a cross-compiler could have much wider interest > in the Fedora community. > [...] I would very much love to see this, as I always end up rolling my own tool chain to cross compile for windows anyway, largely for GSL and other scientific libraries. I would be happy to help out in the "package monkey" sense if the SIG could identify tasks they need help with. Jonathan. From kevin.kofler at chello.at Mon Jul 7 10:57:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 10:57:42 +0000 (UTC) Subject: openbabel SO version bump References: <20080707085941.GA11342@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > I'd like to update F-9's openbabel, too. And to give a reason: we need this version for kdeedu 4.1. > An updated build is available in koji (I've revoked the request to push the > update to testing for now). Can we please get this tagged dist-f9-override so packages can be rebuilt against it? Kevin Kofler From rjones at redhat.com Mon Jul 7 11:02:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 12:02:20 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <645d17210807070354m29cb3dddvbba6175b13510153@mail.gmail.com> References: <20080707094704.GA5497@amd.home.annexia.org> <645d17210807070354m29cb3dddvbba6175b13510153@mail.gmail.com> Message-ID: <20080707110220.GA6186@amd.home.annexia.org> On Mon, Jul 07, 2008 at 11:54:18AM +0100, Jonathan Underwood wrote: > I would very much love to see this, as I always end up rolling my own > tool chain to cross compile for windows anyway, largely for GSL and > other scientific libraries. I would be happy to help out in the > "package monkey" sense if the SIG could identify tasks they need help > with. Well we could certainly do with your experience in that case, because there are loads of unanswered issues ... I've started a list of packages that we would like to see (just for libvirt) on the SIG page: https://fedoraproject.org/wiki/SIGs/MinGW 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 kevin.kofler at chello.at Mon Jul 7 11:09:22 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 11:09:22 +0000 (UTC) Subject: openbabel SO version bump References: <20080707085941.GA11342@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > I'd like to update F-9's openbabel, too. An updated build is available > in koji (I've revoked the request to push the update to testing for now). > http://koji.fedoraproject.org/koji/buildinfo?buildID=54966 I just asked rel-eng to tag this dist-f9-override. Kevin Kofler From dominik at greysector.net Mon Jul 7 11:15:22 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 Jul 2008 13:15:22 +0200 Subject: openbabel SO version bump In-Reply-To: References: <20080707085941.GA11342@mokona.greysector.net> Message-ID: <20080707111522.GC11342@mokona.greysector.net> On Monday, 07 July 2008 at 13:09, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > I'd like to update F-9's openbabel, too. An updated build is available > > in koji (I've revoked the request to push the update to testing for now). > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54966 > > I just asked rel-eng to tag this dist-f9-override. Me too. :) R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bruno at wolff.to Mon Jul 7 11:38:13 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 7 Jul 2008 06:38:13 -0500 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: <20080707113813.GA5406@wolff.to> On Mon, Jul 07, 2008 at 04:32:29 -0400, max bianco wrote: > > Can an option to completely disable the ability to disable SELinux be > added? I'd rather there was no way to turn it off at all. You can already do this post install, so that the only way to disable involves rebooting. And you can make it so that someone has to physically touch the box and do something extreme (pull a disk, the cmos battery or something similar) to be able to disable it. From buc at odusz.so-cdu.ru Mon Jul 7 12:01:33 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 07 Jul 2008 16:01:33 +0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <1215193511.3816.14.camel@roadrunner.itnet.am> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> Message-ID: <4872059D.10509@odu.neva.ru> Suren Karapetyan wrote: > I'm no expert of SELinux, but I do have a good understanding of what it > does (at least currently). > And I agree: it's much more useful on the desktop than (BTW. don't laugh > at me when I mess with then/than) on the server (tune at a bit and it > can prevent social engineering). > But it's not useful to me. > And I understand I'm not the only user and it's OK if I don't like > something, others may like/want/need it. > But Fedora is about Freedom... The real life is more prosaic. Fedora is more "sponsored by Red Hat" rather than "totally" Freedom. And since RH had decided to promote SELinux, we are compelled to follow them in this. In other words -- It is not useful (for now) to propose an ability for the average or even end user to install Fedora without SELinux. The useful thing you can do is to write a faq or a wiki page with description how to disable SELinux after install (and why it might be useful at all), then point people to this resource (fe. at http://www.fedorafaq.org ) ... > And we are making increasingly harder to make non-standard choice. > Let's imagine a community of users, who need such a non-standard choices in general. Could such a community be capable to provide their own Linux distro, suitable for production environments? Seems no. It requires some sponsor (or some commercial basis) for success. Most cases the commerce in Linux is the support of users. And certainly such a commerce "wants" the users to be as typical as possible. Hence it seems not a good idea to allow them a lot of possible options, which they could occasionally set and complicate the life of their supporting engineer... Certainly having the ability of non-standard choice is the good idea, but the market does not like it... :-/ ~buc From sundaram at fedoraproject.org Mon Jul 7 12:08:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 07 Jul 2008 17:38:05 +0530 Subject: Request to re-add option to disable SELinux In-Reply-To: <4872059D.10509@odu.neva.ru> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <4872059D.10509@odu.neva.ru> Message-ID: <48720725.40003@fedoraproject.org> Dmitry Butskoy wrote: > Certainly having the ability of non-standard choice is the good idea, > but the market does not like it... :-/ Maybe but there is certainly a market for things like software appliances and custom spins. http://fedoraproject.org/wiki/CustomSpins. Create your own distribution and have fun. Rahul From jwilson at redhat.com Mon Jul 7 13:29:21 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 7 Jul 2008 09:29:21 -0400 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215258444.3189.87.camel@shinybook.infradead.org> References: <1215258444.3189.87.camel@shinybook.infradead.org> Message-ID: <200807070929.21830.jwilson@redhat.com> On Saturday 05 July 2008 07:47:24 am David Woodhouse wrote: > +* Sat Jul ?5 2008 David Woodhouse I can hear PowerBook's the world over gently weeping... ;) -- Jarod Wilson jwilson at redhat.com From ssorce at redhat.com Mon Jul 7 13:31:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 09:31:07 -0400 Subject: Request to re-add option to disable SELinux In-Reply-To: <4872059D.10509@odu.neva.ru> References: <1215029424.5130.13.camel@perihelion> <1215108900.17420.34.camel@roadrunner.itnet.am> <486D363B.9010201@gmail.com> <1215118452.8182.7.camel@roadrunner.itnet.am> <1215166089.26858.1.camel@gibraltar.str.redhat.com> <1215166768.2321.7.camel@roadrunner.itnet.am> <486E56EA.9080002@gmail.com> <1215193511.3816.14.camel@roadrunner.itnet.am> <4872059D.10509@odu.neva.ru> Message-ID: <1215437467.3554.9.camel@localhost.localdomain> On Mon, 2008-07-07 at 16:01 +0400, Dmitry Butskoy wrote: > Let's imagine a community of users, who need such a non-standard choices > in general. Could such a community be capable to provide their own Linux > distro, suitable for production environments? Seems no. It requires some > sponsor (or some commercial basis) for success. Debian does it without sponsors, heck they even almost voted to forbid sponsorship at least once. > Most cases the commerce in Linux is the support of users. And certainly > such a commerce "wants" the users to be as typical as possible. Hence it > seems not a good idea to allow them a lot of possible options, which > they could occasionally set and complicate the life of their supporting > engineer... Given Red Hat does not provide support for Fedora, you are completely off the mark here. These choice are made on technical grounds by Fedora developers and security conscious people. > Certainly having the ability of non-standard choice is the good idea, > but the market does not like it... :-/ It's not about Market or Red Hat, its about making a distribution that can actually be used without going back to Linux From scratch, where you have to build and configure each single piece of software on your own. Simo. -- Simo Sorce * Red Hat, Inc * New York From jwboyer at gmail.com Mon Jul 7 13:48:22 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 07 Jul 2008 09:48:22 -0400 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <200807070929.21830.jwilson@redhat.com> References: <1215258444.3189.87.camel@shinybook.infradead.org> <200807070929.21830.jwilson@redhat.com> Message-ID: <1215438502.20774.44.camel@weaponx> On Mon, 2008-07-07 at 09:29 -0400, Jarod Wilson wrote: > On Saturday 05 July 2008 07:47:24 am David Woodhouse wrote: > > +* Sat Jul 5 2008 David Woodhouse > > I can hear PowerBook's the world over gently weeping... ;) Those are the users you hear, not the machines. Oh, and me. Loudly. josh From maximilianbianco at gmail.com Mon Jul 7 13:54:41 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 07 Jul 2008 09:54:41 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4871ED07.7050904@poolshark.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> Message-ID: <48722021.5020908@gmail.com> Denis Leroy wrote: > max bianco wrote: >> Can an option to completely disable the ability to disable SELinux be >> added? I'd rather there was no way to turn it off at all. > > that doesn't make *any* sense > It make as much sense as the rest of this thread and what it proposes. Yes I realize this is extreme but no more extreme in my view than disabled by default or offering the option at install time. There is already a way to disable it if you know enough and if you don't then you need it on anyway. For crying out loud my girlfriend uses Fedora, her use is much closer to average than any of the rest of us and SELinux has *never* caused her a problem. My mother, as computer illiterate as they come( no disrespect intended Mom) does not have any problems. This conversation is pointless, I see a hundred posts about people complaining about people discussing things like the GPL on a developer's list, a subject quite relevant in my view, but when the idea of disabling practically the only security present on the system is brought up , it actually gets entertained? Disable it?!?What?!? It seems to me that entirely too many people have their priorities seriously out of whack. In today's world, security better be the first consideration. The internet is a war zone. Any scum bag with a linux box can make a snazzy web page and lure in the unsuspecting. I don't think anyone is claiming SELinux is the be-all end-all of security tools but considering its one of the very few *real* security tools available I don't see how this thread has managed to get this long. I've said my bit. Max From mschwendt at gmail.com Mon Jul 7 14:34:45 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 07 Jul 2008 14:34:45 -0000 Subject: Broken dependencies in Fedora 9 - 2008-07-07 Message-ID: <20080707143445.32556.57325@faldor.intranet> Summary of broken packages (by owner): berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch dcbw AT redhat.com 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 dwmw2 AT infradead.org ppc64-utils-0.14-2.fc9.ppc64 ebmunson AT us.ibm.com lsvpd-1.6.4-1.fc9.i386 lsvpd-1.6.4-1.fc9.ppc lsvpd-1.6.4-1.fc9.ppc64 lsvpd-1.6.4-1.fc9.x86_64 katzj AT redhat.com livecd-tools-017.1-1.fc9.ppc64 oliver AT linux-kernel.at syck-php-0.61-4.3.fc9.i386 syck-php-0.61-4.3.fc9.ppc syck-php-0.61-4.3.fc9.ppc64 syck-php-0.61-4.3.fc9.x86_64 overholt AT redhat.com emma-2.0-0.5312.2jpp.3.fc9.noarch steve AT thefoxhome.net libhugetlbfs-test-1.1-6.fc9.ppc libhugetlbfs-test-1.1-6.fc9.ppc64 libhugetlbfs-test-1.1-6.fc9.x86_64 sundaram AT redhat.com gyachi-plugin-photosharing-1.1.0-7.fc9.i386 gyachi-plugin-photosharing-1.1.0-7.fc9.ppc gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64 gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64 wart AT kobold.org cyphesis-selinux-0.5.15-6.fc9.i386 cyphesis-selinux-0.5.15-6.fc9.ppc cyphesis-selinux-0.5.15-6.fc9.ppc64 cyphesis-selinux-0.5.15-6.fc9.x86_64 ====================================================================== Broken packages in fedora-9-i686: cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 gyachi-plugin-photosharing-1.1.0-7.fc9.i386 requires gyachi = 0:1.1.0-7.fc9 syck-php-0.61-4.3.fc9.i386 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc64: cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64 requires gyachi = 0:1.1.0-7.fc9 libhugetlbfs-test-1.1-6.fc9.ppc64 requires libhugetlbfs = 0:1.1-6.fc9 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot syck-php-0.61-4.3.fc9.ppc64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc: cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 gyachi-plugin-photosharing-1.1.0-7.fc9.ppc requires gyachi = 0:1.1.0-7.fc9 libhugetlbfs-test-1.1-6.fc9.ppc requires libhugetlbfs = 0:1.1-6.fc9 syck-php-0.61-4.3.fc9.ppc requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-x86_64: 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 requires NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64 requires gyachi = 0:1.1.0-7.fc9 libhugetlbfs-test-1.1-6.fc9.x86_64 requires libhugetlbfs = 0:1.1-6.fc9 syck-php-0.61-4.3.fc9.x86_64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-updates-9-i686: lsvpd-1.6.4-1.fc9.i386 requires libvpd_cxx-2.0.so.1 ====================================================================== Broken packages in fedora-updates-9-ppc64: emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 livecd-tools-017.1-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc9.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) ====================================================================== Broken packages in fedora-updates-9-ppc: lsvpd-1.6.4-1.fc9.ppc requires libvpd_cxx-2.0.so.1 ====================================================================== Broken packages in fedora-updates-9-x86_64: lsvpd-1.6.4-1.fc9.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) From mschwendt at gmail.com Mon Jul 7 14:35:29 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 07 Jul 2008 14:35:29 -0000 Subject: Broken dependencies in Fedora 8 - 2008-07-07 Message-ID: <20080707143529.32558.59871@faldor.intranet> Summary of broken packages (by owner): akahl AT iconmobile.com bmpx-extension-0.40.13-8.fc8.i386 bmpx-extension-0.40.13-8.fc8.ppc bmpx-extension-0.40.13-8.fc8.ppc64 bmpx-extension-0.40.13-8.fc8.x86_64 berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch braden AT endoframe.com openvrml-xembed-0.17.6-3.fc8.i386 openvrml-xembed-0.17.6-3.fc8.ppc openvrml-xembed-0.17.6-3.fc8.ppc64 openvrml-xembed-0.17.6-3.fc8.x86_64 cooly AT gnome.eu.org evolution-rss-0.0.8-9.fc8.i386 evolution-rss-0.0.8-9.fc8.ppc evolution-rss-0.0.8-9.fc8.ppc64 evolution-rss-0.0.8-9.fc8.x86_64 dcbw AT redhat.com 1:NetworkManager-0.7.0-0.6.7.svn3370.fc8.i386 dev AT nigelj.com mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch ianweller AT gmail.com mediawiki-HNP-1.1.2-1.fc8.noarch mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch mediawiki-StubManager-1.2.0-1.fc8.noarch konrad AT tylerc.org joda-time-1.5.2-6.tzdata2008c.fc8.noarch kwizart AT gmail.com perl-AnyEvent-4.161-1.fc8.noarch mtasaka AT ioa.s.u-tokyo.ac.jp cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.i386 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.ppc cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.ppc64 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.x86_64 oliver AT linux-kernel.at syck-php-0.61-2.fc8.i386 syck-php-0.61-2.fc8.ppc syck-php-0.61-2.fc8.ppc64 syck-php-0.61-2.fc8.x86_64 rjones AT redhat.com ocaml-json-static-0.9.6-5.fc8.i386 ocaml-json-static-0.9.6-5.fc8.ppc ocaml-json-static-0.9.6-5.fc8.x86_64 rmeggins AT redhat.com idm-console-framework-1.1.1-3.fc8.noarch rpm AT timj.co.uk alsa-firmware-1.0.16-1.fc8.noarch skvidal AT linux.duke.edu yum-tmprepo-1.1.14-4.fc8.noarch yum-verify-1.1.14-4.fc8.noarch steve AT thefoxhome.net libhugetlbfs-test-1.1-4.fc8.i386 libhugetlbfs-test-1.1-4.fc8.ppc libhugetlbfs-test-1.1-4.fc8.ppc64 libhugetlbfs-test-1.1-4.fc8.x86_64 ====================================================================== Broken packages in fedora-8-i686: libhugetlbfs-test-1.1-4.fc8.i386 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.i386 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc64: libhugetlbfs-test-1.1-4.fc8.ppc64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc: libhugetlbfs-test-1.1-4.fc8.ppc requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-x86_64: libhugetlbfs-test-1.1-4.fc8.x86_64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.x86_64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-updates-8-i686: alsa-firmware-1.0.16-1.fc8.noarch requires alsa-tools-firmware >= 0:1.0.16 bmpx-extension-0.40.13-8.fc8.i386 requires bmpx = 0:0.40.13-8.fc8 bmpx-extension-0.40.13-8.fc8.i386 requires firefox = 0:2.0.0.12 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.i386 requires gecko-libs = 0:1.8.1.14 evolution-rss-0.0.8-9.fc8.i386 requires gecko-libs = 0:1.8.1.14 openvrml-xembed-0.17.6-3.fc8.i386 requires gecko-libs = 0:1.8.1.14 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-ppc64: alsa-firmware-1.0.16-1.fc8.noarch requires alsa-tools-firmware >= 0:1.0.16 bmpx-extension-0.40.13-8.fc8.ppc64 requires bmpx = 0:0.40.13-8.fc8 bmpx-extension-0.40.13-8.fc8.ppc64 requires firefox = 0:2.0.0.12 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.ppc64 requires gecko-libs = 0:1.8.1.14 evolution-rss-0.0.8-9.fc8.ppc64 requires gecko-libs = 0:1.8.1.14 idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-6.tzdata2008c.fc8.noarch requires java > 0:1.5.0 mediawiki-HNP-1.1.2-1.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch requires mediawiki < 0:1.11 mediawiki-StubManager-1.2.0-1.fc8.noarch requires mediawiki >= 0:1.10 openvrml-xembed-0.17.6-3.fc8.ppc64 requires gecko-libs = 0:1.8.1.14 perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch requires darcs >= 0:1.0.0 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-ppc: alsa-firmware-1.0.16-1.fc8.noarch requires alsa-tools-firmware >= 0:1.0.16 bmpx-extension-0.40.13-8.fc8.ppc requires bmpx = 0:0.40.13-8.fc8 bmpx-extension-0.40.13-8.fc8.ppc requires firefox = 0:2.0.0.12 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.ppc requires gecko-libs = 0:1.8.1.14 evolution-rss-0.0.8-9.fc8.ppc requires gecko-libs = 0:1.8.1.14 idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-6.tzdata2008c.fc8.noarch requires java > 0:1.5.0 openvrml-xembed-0.17.6-3.fc8.ppc requires gecko-libs = 0:1.8.1.14 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-x86_64: 1:NetworkManager-0.7.0-0.6.7.svn3370.fc8.i386 requires NetworkManager-glib = 1:0.7.0-0.6.7.svn3370.fc8 alsa-firmware-1.0.16-1.fc8.noarch requires alsa-tools-firmware >= 0:1.0.16 bmpx-extension-0.40.13-8.fc8.x86_64 requires bmpx = 0:0.40.13-8.fc8 bmpx-extension-0.40.13-8.fc8.x86_64 requires firefox = 0:2.0.0.12 cairo-dock-plug-ins-gecko-1.6.0.2-1.date20080621.fc8.x86_64 requires gecko-libs = 0:1.8.1.14 evolution-rss-0.0.8-9.fc8.x86_64 requires gecko-libs = 0:1.8.1.14 openvrml-xembed-0.17.6-3.fc8.x86_64 requires gecko-libs = 0:1.8.1.14 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-testing-8-i686: ocaml-json-static-0.9.6-5.fc8.i386 requires ocaml-json-wheel ====================================================================== Broken packages in fedora-updates-testing-8-ppc64: perl-AnyEvent-4.161-1.fc8.noarch requires perl(Event::Lib) ====================================================================== Broken packages in fedora-updates-testing-8-ppc: ocaml-json-static-0.9.6-5.fc8.ppc requires ocaml-json-wheel ====================================================================== Broken packages in fedora-updates-testing-8-x86_64: ocaml-json-static-0.9.6-5.fc8.x86_64 requires ocaml-json-wheel From denis at poolshark.org Mon Jul 7 14:39:20 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 07 Jul 2008 16:39:20 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48722021.5020908@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> Message-ID: <48722A98.10405@poolshark.org> max wrote: > Denis Leroy wrote: >> max bianco wrote: >>> Can an option to completely disable the ability to disable SELinux be >>> added? I'd rather there was no way to turn it off at all. >> >> that doesn't make *any* sense >> > It make as much sense as the rest of this thread and what it proposes. > Yes I realize this is extreme but no more extreme in my view than > disabled by default or offering the option at install time. There is > already a way to disable it if you know enough and if you don't then you > need it on anyway. For crying out loud my girlfriend uses Fedora, her > use is much closer to average than any of the rest of us and SELinux has > *never* caused her a problem. My mother, as computer illiterate as they > come( no disrespect intended Mom) does not have any problems. This > conversation is pointless, I see a hundred posts about people > complaining about people discussing things like the GPL on a developer's > list, a subject quite relevant in my view, but when the idea of > disabling practically the only security present on the system is brought > up , it actually gets entertained? Disable it?!?What?!? It seems to me > that entirely too many people have their priorities seriously out of > whack. you are COMPLETELY missing the point. In some context, security is irrelevant. Like that Fedora system we use in our lab at work for bringup testing: it doesn't even have a network card. some people thing that criticizing SELinux installation policy (not SELinux itself mind you, which is a useful thing) == saying "security is not important". This is ridiculous. The only scenario I can think of where SELinux disabled installation would be forcefully prohibited would be, say, a custom Fedora spin targeted at employees or students where you don't want some smart guy to disable it (because that would mean your job)... From ajax at redhat.com Mon Jul 7 14:37:57 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 07 Jul 2008 10:37:57 -0400 Subject: Having problems with koji builds using mesa-libGL-devel In-Reply-To: References: Message-ID: <1215441477.24769.292.camel@localhost.localdomain> On Thu, 2008-07-03 at 12:45 -0700, Christopher Stone wrote: > Hi, I am getting X crashes on one of my applications. It seems that > all it needs is a recompile, however, it needs to recompile against > mesa-libGL-devel 7.1-0.35.fc9. This is all good when I do a build > using mock, however when I try to build using koji it picks up version > 7.1-0.37.fc9 and I continue to get the X crashes. > > http://kojipkgs.fedoraproject.org/packages/xwnc/0.3.3/5.fc9/data/logs/x86_64/root.log > > Why does koji use the .37 version of mesa-ligGL-devel instead of the > .35 version like mock does? And the fix for your package will be the same as was done for Xvnc: link the server with -Wl,--export-dynamic. I was only vaguely aware that this package existed. I'm happy to see that it's got cvsextras+, so in the future when the X build system changes I'll try to remember to include it in the rebuilds. - ajax -------------- 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 Mon Jul 7 15:06:38 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 15:06:38 +0000 (UTC) Subject: openbabel SO version bump References: <20080707085941.GA11342@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > Affected packages: > kdeedu Rebuilds just fine, build completed successfully. Kevin Kofler From ajax at redhat.com Mon Jul 7 15:02:24 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 07 Jul 2008 11:02:24 -0400 Subject: source file audit - 2008-07-05 In-Reply-To: <20080705141930.5f42d27f@ohm.scrye.com> References: <20080705141930.5f42d27f@ohm.scrye.com> Message-ID: <1215442944.24769.297.camel@localhost.localdomain> On Sat, 2008-07-05 at 14:19 -0600, Kevin Fenzi wrote: > ajax:BADURL:pyxf86config-0.3.37.tar.bz2:pyxf86config > xgl-maint:BADURL:font-util-1.0.1.tar.bz2:xorg-x11-font-utils > xgl-maint:BADURL:xf86-video-vesa-20080404.tar.bz2:xorg-x11-drv-vesa Fixed. - ajax -------------- 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 dr.diesel at gmail.com Mon Jul 7 15:21:33 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 7 Jul 2008 10:21:33 -0500 Subject: Install dies at waiting for hardware to init - sorta Message-ID: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> Attempting to install F9 I386 on a system with two HighPoint RocketRaid 2220 8-Port devices. During the very first part of the install (installing from a USB DVD-ROM) the install hangs for ~10 minutes on the waiting for hardware to initialize. Once done it pops up with a messing asking me to define which driver to use for the install media, it can't see/find any devices, even the MB IDE/SATA or USB DVD. I'm guessing it gets really confused during the hardware init somehow. The first part of the install works, just forgets where it was installing from! Any work-a-rounds or is this a bug? I'd like to learn how to do this without pulling the HighPoint cards for the install? Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From maximilianbianco at gmail.com Mon Jul 7 15:28:58 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 07 Jul 2008 11:28:58 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48722A98.10405@poolshark.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> Message-ID: <4872363A.9070509@gmail.com> Denis Leroy wrote: > max wrote: >> Denis Leroy wrote: >>> max bianco wrote: >>>> Can an option to completely disable the ability to disable SELinux be >>>> added? I'd rather there was no way to turn it off at all. >>> >>> that doesn't make *any* sense >>> >> It make as much sense as the rest of this thread and what it proposes. >> Yes I realize this is extreme but no more extreme in my view than >> disabled by default or offering the option at install time. There is >> already a way to disable it if you know enough and if you don't then >> you need it on anyway. For crying out loud my girlfriend uses Fedora, >> her use is much closer to average than any of the rest of us and >> SELinux has *never* caused her a problem. My mother, as computer >> illiterate as they come( no disrespect intended Mom) does not have any >> problems. This conversation is pointless, I see a hundred posts about >> people complaining about people discussing things like the GPL on a >> developer's list, a subject quite relevant in my view, but when the >> idea of disabling practically the only security present on the system >> is brought up , it actually gets entertained? Disable it?!?What?!? It >> seems to me that entirely too many people have their priorities >> seriously out of whack. > > you are COMPLETELY missing the point. In some context, security is > irrelevant. Like that Fedora system we use in our lab at work for > bringup testing: it doesn't even have a network card. > The last time I looked a computer without internet access is completely useless to the average user. What do you think the majority of people are doing with their computers? playing solitaire? No network card is not the norm. Anyway what's to stop some disgruntled employee from quietly loading a program onto your test box that will have you scratching your head for days because you can't imagine what might be wrong. I think you have missed my point, probably because I failed to express it adequately so I will drop it. This insanity isn't worth discussing anyway. From alan at redhat.com Mon Jul 7 15:30:00 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 7 Jul 2008 11:30:00 -0400 Subject: Install dies at waiting for hardware to init - sorta In-Reply-To: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> References: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> Message-ID: <20080707153000.GA4706@devserv.devel.redhat.com> On Mon, Jul 07, 2008 at 10:21:33AM -0500, Dr. Diesel wrote: > Any work-a-rounds or is this a bug? I'd like to learn how to do this > without pulling the HighPoint cards for the install? You will probably need to pull the rocketraid cards, and you'll almost certainly need to avoid putting Linux anywhere near them. To quote Mark Lord on the kernel list "And the Highpoint RocketRAID cards are a similarly dubious choice, as their onboard BIOS is known to corrupt filesystems before Linux is even booted. In particular, an "unconfigured" drive -- just plugged into a RR card without entering the BIOS setup to configure a RAID -- gets sector 8 overwritten by the BIOS. This will destroy GRUB if it was installed. And for drives which *have* been configured in the RR BIOS, it overwrites a sector at the end of the final full GB on the drive, for holding RR metadata." ~ From dr.diesel at gmail.com Mon Jul 7 15:44:13 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 7 Jul 2008 10:44:13 -0500 Subject: Install dies at waiting for hardware to init - sorta In-Reply-To: <20080707153000.GA4706@devserv.devel.redhat.com> References: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> <20080707153000.GA4706@devserv.devel.redhat.com> Message-ID: <2a28d2ab0807070844j7a24bfc5h6ede138cf78ea36a@mail.gmail.com> Really? These have been running fine in F6 for a long time now. When I attempted to install F9 with the drives already configured it didn't "appear" to do any harm as they again booted with F6 when I swapped the drive back in... But big thanks for the information, wonder how/who (maybe Mark) could shed more light on how this works? My hope is maybe some of their older cards only had this problem? Thanks Andy On Mon, Jul 7, 2008 at 10:30 AM, Alan Cox wrote: > On Mon, Jul 07, 2008 at 10:21:33AM -0500, Dr. Diesel wrote: >> Any work-a-rounds or is this a bug? I'd like to learn how to do this >> without pulling the HighPoint cards for the install? > > You will probably need to pull the rocketraid cards, and you'll almost > certainly need to avoid putting Linux anywhere near them. > > To quote Mark Lord on the kernel list > > "And the Highpoint RocketRAID cards are a similarly dubious choice, > as their onboard BIOS is known to corrupt filesystems before Linux > is even booted. > > In particular, an "unconfigured" drive -- just plugged into a RR card > without entering the BIOS setup to configure a RAID -- gets sector 8 overwritten by the BIOS. This will destroy GRUB if it was installed. > And for drives which *have* been configured in the RR BIOS, > it overwrites a sector at the end of the final full GB on the drive, > for holding RR metadata." > > > ~ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From pemboa at gmail.com Mon Jul 7 15:57:44 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 7 Jul 2008 10:57:44 -0500 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872363A.9070509@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> Message-ID: <16de708d0807070857o1b37c33bh8ce3f201c7193a0e@mail.gmail.com> On Mon, Jul 7, 2008 at 10:28 AM, max wrote: > Denis Leroy wrote: >> >> max wrote: >>> >>> Denis Leroy wrote: >>>> >>>> max bianco wrote: >>>>> >>>>> Can an option to completely disable the ability to disable SELinux be >>>>> added? I'd rather there was no way to turn it off at all. >>>> >>>> that doesn't make *any* sense >>>> >>> It make as much sense as the rest of this thread and what it proposes. >>> Yes I realize this is extreme but no more extreme in my view than disabled >>> by default or offering the option at install time. There is already a way to >>> disable it if you know enough and if you don't then you need it on anyway. >>> For crying out loud my girlfriend uses Fedora, her use is much closer to >>> average than any of the rest of us and SELinux has *never* caused her a >>> problem. My mother, as computer illiterate as they come( no disrespect >>> intended Mom) does not have any problems. This conversation is pointless, I >>> see a hundred posts about people complaining about people discussing things >>> like the GPL on a developer's list, a subject quite relevant in my view, but >>> when the idea of disabling practically the only security present on the >>> system is brought up , it actually gets entertained? Disable it?!?What?!? It >>> seems to me that entirely too many people have their priorities seriously >>> out of whack. >> >> you are COMPLETELY missing the point. In some context, security is >> irrelevant. Like that Fedora system we use in our lab at work for bringup >> testing: it doesn't even have a network card. >> > > The last time I looked a computer without internet access is completely > useless to the average user. What do you think the majority of people are > doing with their computers? playing solitaire? No network card is not the > norm. Anyway what's to stop some disgruntled employee from quietly loading a > program onto your test box that will have you scratching your head for days > because you can't imagine what might be wrong. I think you have missed my > point, probably because I failed to express it adequately so I will drop > it. This insanity isn't worth discussing anyway. I like SELinux due to the fact that is has personally saved my sorry ass at least once. However, I feel that users should be given the opportunity to disable SELinux at will. In my case, I disable SELinux on my firewalled, natted desktop. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Mon Jul 7 16:00:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 7 Jul 2008 08:00:02 -0800 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872363A.9070509@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> Message-ID: <604aa7910807070900v25b8bc81v7f5ed4894296c02d@mail.gmail.com> On Mon, Jul 7, 2008 at 7:28 AM, max wrote: > The last time I looked a computer without internet access is completely > useless to the average user. What do you think the majority of people are > doing with their computers? playing solitaire? No the are playing Liquid War! -jef"I should get the wii-mote working as an input on my laptop and hack liquidwar to use it as an input device"spaleta From bthomas21 at zoominternet.net Mon Jul 7 12:24:28 2008 From: bthomas21 at zoominternet.net (Brandon Thomas) Date: Mon, 07 Jul 2008 08:24:28 -0400 Subject: Faster boot time Message-ID: <1215433468.20418.12.camel@bts-laptop> So last night I hibernated my laptop and when I came in today it booted pretty close to instantly. I very seldomly hibernate my laptop because I frankly just don't see the same performance as after I boot cleanly from a full shutdown. But I got to thinking... What if some/all services were able to be configured to "hibernate" during shutdown, then at single program or service called by rhgb brought these programs back to life? I think it would be helpful to reduce the number of services that start during boot for my laptop (httpd, mysqld, vsftpd, etc.). Is such a feat possible? Could there even be a decrease in boot time? Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Mon Jul 7 16:39:47 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 7 Jul 2008 17:39:47 +0100 Subject: Faster boot time In-Reply-To: <1215433468.20418.12.camel@bts-laptop> References: <1215433468.20418.12.camel@bts-laptop> Message-ID: <20080707163947.GF16400@redhat.com> On Mon, Jul 07, 2008 at 08:24:28AM -0400, Brandon Thomas wrote: > So last night I hibernated my laptop and when I came in today it booted > pretty close to instantly. I very seldomly hibernate my laptop because > I frankly just don't see the same performance as after I boot cleanly > from a full shutdown. But I got to thinking... If you can get a reproducable test to show that its slower after resume from hibernate then file a BZ so this can be fixed. The possible cause is that after resume some of your apps/their data are still on swap so the first time you access them will be slower as they're paged in. > What if some/all services were able to be configured to "hibernate" > during shutdown, then at single program or service called by rhgb > brought these programs back to life? I think it would be helpful to > reduce the number of services that start during boot for my laptop > (httpd, mysqld, vsftpd, etc.). Is such a feat possible? Could there > even be a decrease in boot time? This is just re-inventing hibernate again with even more work which is not a good use of developer time as compared to fixing any bugs which actaully exist in hibernate/resume. 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 lemenkov at gmail.com Mon Jul 7 16:41:31 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 7 Jul 2008 20:41:31 +0400 Subject: noarch and %{_libdir} issues on 64-bit platforms Message-ID: Hello All! If someone tries to package executable script (arch-neytral) which must be placed into %{_libdir}/something (for example, nagios-plugin which must go into %{_libdir}/nagios/plugins ), he quickly founds that he actually can't mark package as noarch, because on both 32- and 64-bit systems %{_libdir} points to /usr/lib . There is an obvious workaround - not to mark the package as noarch. How to overcome this issue and package utility as noarch? See details: * https://bugzilla.redhat.com/show_bug.cgi?id=423821#c5 * noarch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=696176 * build w/o "BuildArch: noarch": http://koji.fedoraproject.org/koji/taskinfo?taskID=696178 -- With best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Mon Jul 7 16:50:06 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 07 Jul 2008 18:50:06 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872363A.9070509@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> Message-ID: <4872493E.6040306@poolshark.org> max wrote: > The last time I looked a computer without internet access is completely > useless to the average user. What do you think the majority of people > are doing with their computers? playing solitaire? No network card is > not the norm. Anyway what's to stop some disgruntled employee from > quietly loading a program onto your test box that will have you > scratching your head for days because you can't imagine what might be > wrong. I have a media server here with Fedora on it. Just a storage box with MP3s on it. It has no direct connectivity to the net, as such it has no root password, no firewall and no SELinux. Adding any of these would be a complete waste of time and disk space since they offer no protection against an intruder with direct physical access and a screwdriver. OTOH, the filesystem is encrypted. I'm not sure what you're arguing for. You're saying security is important. I fully agree. You're saying SELinux is important. I fully agree. You're saying SELinux should be enabled by default on our Desktop installation. I fully agree. Fedora is probably (? does anyone know for sure) the only desktop distro that does this by default. However sabotaging the installer to make it impossible for people to disable it at installation, now that's where I say "that doesn't make any sense", cf my original email. From steven.moix at axianet.ch Mon Jul 7 16:55:03 2008 From: steven.moix at axianet.ch (Steven Moix) Date: Mon, 07 Jul 2008 18:55:03 +0200 Subject: Faster boot time In-Reply-To: <1215433468.20418.12.camel@bts-laptop> References: <1215433468.20418.12.camel@bts-laptop> Message-ID: <1215449703.5394.2.camel@hp6710.axianet.ch> On Mon, 2008-07-07 at 08:24 -0400, Brandon Thomas wrote: > I think it would be helpful to reduce the number of services that > start during boot for my laptop (httpd, mysqld, vsftpd, etc.). Is > such a feat possible? Could there even be a decrease in boot time? > Brandon ?I see one big problem with that: rebooting is often use to get a fresh start after you made some experimental configuration changes. By "hibernating" services, you couldn't guarantee that anymore. Steven From hughsient at gmail.com Mon Jul 7 17:08:30 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 07 Jul 2008 18:08:30 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon Message-ID: <1215450510.7472.11.camel@hughsie-work> I've built ?new builds of PackageKit ?and gnome-packagekit and moved them into updates-testing. The new major version is hopefully much better from a UI perspective and hopefully much more stable but is an API break from 0.1.x. The builds for F9 are here: http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 Please test these packages, and report any bugs on email (reply to this thread please), rather than the admin update page. When we've got quite a bit of testing and ironed out and regressions then I'll push to stable. >From a speed point of view it shouldn't be a lot quicker just yet. I've spent most of last week profiling yum and working around different slow paths in the API. All this work I've been doing in git master, but I'll backport that to 0.2.x in good time as it's essentially the same as in the 0.2.x branch. For instance, the group list used to take 14 seconds on my machine, and now completes in less than a tenth of a second using master. If you want to test this new code, jump onto the packagekit mailing list and I'll give you instructions on how to build master. Thanks, Richard. From skvidal at fedoraproject.org Mon Jul 7 17:15:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 07 Jul 2008 13:15:06 -0400 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215450510.7472.11.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> Message-ID: <1215450906.14926.40.camel@rosebud> On Mon, 2008-07-07 at 18:08 +0100, Richard Hughes wrote: > I've built ?new builds of PackageKit ?and gnome-packagekit and moved > them into updates-testing. The new major version is hopefully much > better from a UI perspective and hopefully much more stable but is an > API break from 0.1.x. > > The builds for F9 are here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 > > Please test these packages, and report any bugs on email (reply to this > thread please), rather than the admin update page. When we've got quite > a bit of testing and ironed out and regressions then I'll push to > stable. > > >From a speed point of view it shouldn't be a lot quicker just yet. I've > spent most of last week profiling yum and working around different slow > paths in the API. All this work I've been doing in git master, but I'll > backport that to 0.2.x in good time as it's essentially the same as in > the 0.2.x branch. > > For instance, the group list used to take 14 seconds on my machine, and > now completes in less than a tenth of a second using master. If you want > to test this new code, jump onto the packagekit mailing list and I'll > give you instructions on how to build master. That code is not a good idea and will go bananas when we change the db format/version. I've implemented a searchNames() method to pkgSack in yum which will let you search very quickly for multiple package names. directly accessing the sqlite dbs without going through yums' layers is going to break in odd ways. In much the same way that going directly to the rpmdb w/o accessing it via rpm's layer will break in odd ways. yum 3.2.17 which will be out this week will have searchNames() to help your group case. -sv From drago01 at gmail.com Mon Jul 7 17:18:22 2008 From: drago01 at gmail.com (drago01) Date: Mon, 7 Jul 2008 19:18:22 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215450510.7472.11.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> Message-ID: On Mon, Jul 7, 2008 at 7:08 PM, Richard Hughes wrote: > I've built ?new builds of PackageKit ?and gnome-packagekit and moved > them into updates-testing. The new major version is hopefully much > better from a UI perspective and hopefully much more stable but is an > API break from 0.1.x. > > The builds for F9 are here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 I have been testing them since I saw them in koji. 1) Seems to be better than 0.1.x branch UI wise Some things that needs to be improved: 1) The "getting information" applet shouldn't show up unless there are updates or work being done, but the "getting information" after login / connecting to a network is pointless. 2) I tryed to delete multple package at once but after pressing the apply button it started to resolve deps in the background without showing any feedback to the user for ~30 sec (the user might think it did nothing and keep clicking on the apply button), 3) The rpm post script is noisy (some media stuff can't remember) From gnomeuser at gmail.com Mon Jul 7 17:19:25 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 7 Jul 2008 19:19:25 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215450510.7472.11.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> Message-ID: <1dedbbfc0807071019gccf0877p8a41a47b04473fff@mail.gmail.com> 2008/7/7 Richard Hughes : > I've built ?new builds of PackageKit ?and gnome-packagekit and moved > them into updates-testing. The new major version is hopefully much > better from a UI perspective and hopefully much more stable but is an > API break from 0.1.x. > > The builds for F9 are here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 > > Please test these packages, and report any bugs on email (reply to this > thread please), rather than the admin update page. When we've got quite > a bit of testing and ironed out and regressions then I'll push to > stable. > > >From a speed point of view it shouldn't be a lot quicker just yet. I've > spent most of last week profiling yum and working around different slow > paths in the API. All this work I've been doing in git master, but I'll > backport that to 0.2.x in good time as it's essentially the same as in > the 0.2.x branch. > > For instance, the group list used to take 14 seconds on my machine, and > now completes in less than a tenth of a second using master. If you want > to test this new code, jump onto the packagekit mailing list and I'll > give you instructions on how to build master. > > Thanks, > > Richard. I've been running these for a while now and I see no stability or performance problems. So far they have survived installing/removing software and performing several system updates without issue. Excellent work Richard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Mon Jul 7 17:27:31 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 7 Jul 2008 18:27:31 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215450510.7472.11.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> Message-ID: <20080707172731.GG16400@redhat.com> On Mon, Jul 07, 2008 at 06:08:30PM +0100, Richard Hughes wrote: > I've built ???new builds of PackageKit ???and gnome-packagekit and moved > them into updates-testing. The new major version is hopefully much > better from a UI perspective and hopefully much more stable but is an > API break from 0.1.x. > > The builds for F9 are here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 > > Please test these packages, and report any bugs on email (reply to this > thread please), rather than the admin update page. When we've got quite > a bit of testing and ironed out and regressions then I'll push to > stable. Biggest problem is that it has broken ABI in the .so without changing the .so version. So the automatically ELF library dependancies added by RPM don't protect you during update. Before upgrade: # rpm -q PackageKit-libs PackageKit-libs-0.1.12-13.20080522.fc9.x86_64 # rpm -q --provides PackageKit-libs | grep libpackage libpackagekit.so.3()(64bit) After the upgrade # rpm -q PackageKit-libs PackageKit-libs-0.2.3-2.fc9.x86_64 # rpm -q --provides PackageKit-libs | grep libpackage libpackagekit.so.3()(64bit) Same soname version, different ABI :-( And since gnome-packagekit versioning is done on the soname: # rpm -q --requires gnome-packagekit | grep libpackage libpackagekit.so.3()(64bit) You can update PackageKit-libs without updating gnome-packagekit and get a broken install due to the ABI change: # gpk-application gpk-application: symbol lookup error: gpk-application: undefined symbol: pk_enum_list_new So if you want to push this to F9 you'll need to make sure that the new PackageKit-libs RPM, has a Conflicts: gnome-packagekit < 0.2.3-3.fc9 or re-spin the upstream release to increment the .soname version 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 martin.sourada at gmail.com Mon Jul 7 17:52:05 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 07 Jul 2008 19:52:05 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215450510.7472.11.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> Message-ID: <1215453125.3206.114.camel@pc-notebook> On Mon, 2008-07-07 at 18:08 +0100, Richard Hughes wrote: > Please test these packages, and report any bugs on email (reply to this > thread please), rather than the admin update page. When we've got quite > a bit of testing and ironed out and regressions then I'll push to > stable. > I've been using rawhide snapshots for a while and when I noticed these upgrades in koji, I "downgraded" to the F9 version. So far seems stable, no real issues noticed, only some not-so-intuitive behaviour during installing local rpms: * It always asks for authentication and there is no option to remember the authentication when it discovers thath the package is not signed. Is it intentional? * The window with update progress closes itself after I give the needed permissions to install and as a result I am not notified of the update result. I can reopen the window via the notify icon though... Hm... come to think of it, I just remembered it does not say the installation failed if some pre/post-install scriplet failed. I noticed it while upgrading broken intel driver package multiple times, until finally discovering in command line (yum update), that actually some scriplet was giving and error. Btw. the said package was fixed rather promptly. Yum seems to be OK with failing scriplets (i.e. finishes the update/install/remove of other packages and marks the installation as success), so this might not be PackageKit fault. Martin -------------- 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 skvidal at fedoraproject.org Mon Jul 7 17:54:52 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 07 Jul 2008 13:54:52 -0400 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215453125.3206.114.camel@pc-notebook> References: <1215450510.7472.11.camel@hughsie-work> <1215453125.3206.114.camel@pc-notebook> Message-ID: <1215453292.14926.46.camel@rosebud> On Mon, 2008-07-07 at 19:52 +0200, Martin Sourada wrote: > On Mon, 2008-07-07 at 18:08 +0100, Richard Hughes wrote: > > Please test these packages, and report any bugs on email (reply to this > > thread please), rather than the admin update page. When we've got quite > > a bit of testing and ironed out and regressions then I'll push to > > stable. > > > > I've been using rawhide snapshots for a while and when I noticed these > upgrades in koji, I "downgraded" to the F9 version. So far seems stable, > no real issues noticed, only some not-so-intuitive behaviour during > installing local rpms: > > * It always asks for authentication and there is no option to remember > the authentication when it discovers thath the package is not signed. Is > it intentional? > > * The window with update progress closes itself after I give the needed > permissions to install and as a result I am not notified of the update > result. I can reopen the window via the notify icon though... > > Hm... come to think of it, I just remembered it does not say the > installation failed if some pre/post-install scriplet failed. I noticed > it while upgrading broken intel driver package multiple times, until > finally discovering in command line (yum update), that actually some > scriplet was giving and error. Btw. the said package was fixed rather > promptly. Yum seems to be OK with failing scriplets (i.e. finishes the > update/install/remove of other packages and marks the installation as > success), so this might not be PackageKit fault. > s/yum/rpm/ some failing scriptlets are not fatal to the transaction. -sv From kevin at scrye.com Mon Jul 7 19:05:56 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 7 Jul 2008 13:05:56 -0600 Subject: IRC support meeting - 2008-07-10 at 18:00 UTC Message-ID: <20080707130556.5e803959@ohm.scrye.com> We would like to have another meeting of folks interested in #fedora and IRC support this thursday at 18:00 UTC (right after the FESCo meeting). Topics: - Code of conduct for IRC support channels. - Scheduling timeperiods for helpers - Recruiting more helpers. - Decide if we should be a SIG or not. - Any other topics folks would like to discuss... All interested parties are welcome to join us! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From konrad at tylerc.org Mon Jul 7 19:12:04 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Mon, 7 Jul 2008 12:12:04 -0700 Subject: noarch and %{_libdir} issues on 64-bit platforms In-Reply-To: References: Message-ID: <200807071212.04607.konrad@tylerc.org> Quoth Peter Lemenkov: > Hello All! > > If someone tries to package executable script (arch-neytral) which must be > placed into %{_libdir}/something (for example, nagios-plugin which must go > into %{_libdir}/nagios/plugins ), he quickly founds that he actually can't > mark package as noarch, because on both 32- and 64-bit systems %{_libdir} > points to /usr/lib . There is an obvious workaround - not to mark the > package as noarch. > > How to overcome this issue and package utility as noarch? > > See details: > * https://bugzilla.redhat.com/show_bug.cgi?id=423821#c5 > > * noarch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=696176 > * build w/o "BuildArch: noarch": > http://koji.fedoraproject.org/koji/taskinfo?taskID=696178 If it goes in /usr/lib and /usr/lib64 depending on arch, it's not noarch. I think. People who are more confident about this ought to reply. Regards, -- Conrad Meyer -------------- 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 at scrye.com Mon Jul 7 19:14:31 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 7 Jul 2008 13:14:31 -0600 Subject: Why is relatime immune to remount? In-Reply-To: <4871DDF2.5040102@robertoragusa.it> References: <4871DDF2.5040102@robertoragusa.it> Message-ID: <20080707131431.220a6a11@ohm.scrye.com> On Mon, 07 Jul 2008 11:12:18 +0200 mail at robertoragusa.it (Roberto Ragusa) wrote: > Hi, > > my root filesystem is mounted with the option relatime for > some reason (I just have defaults in /etc/fstab). > > Any attempt to temporarily disable the option fails, > even with norelatime, which appears to be a valid option. > Is this expected or a bug? > > (fedora 9 with 2.6.25.3-18) > > [root at thinkpad ~]# cat /proc/mounts |grep /dev/root > /dev/root / reiserfs rw,relatime 0 0 > [root at thinkpad ~]# mount / -o remount,norelatime > [root at thinkpad ~]# cat /proc/mounts |grep /dev/root > /dev/root / reiserfs rw,relatime 0 0 > [root at thinkpad ~]# mount / -o remount,atime > [root at thinkpad ~]# cat /proc/mounts |grep /dev/root > /dev/root / reiserfs rw,relatime 0 0 > [root at thinkpad ~]# mount / -o remount,noatime > [root at thinkpad ~]# cat /proc/mounts |grep /dev/root > /dev/root / reiserfs rw,noatime,relatime 0 0 > [root at thinkpad ~]# mount / -o remount,atime > [root at thinkpad ~]# cat /proc/mounts |grep /dev/root > /dev/root / reiserfs rw,relatime 0 0 > [root at thinkpad ~]# mount / -o remount,nonononononorelatime > mount: / not mounted already, or bad option > Yeah, confusingly that doesn't work. You have to: echo 0 > /proc/sys/fs/default_relatime and then mount/remount with 'atime' and it should work. Even the patch in the kernel src.rpm has incorrect docs on it. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jul 7 19:15:25 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jul 2008 21:15:25 +0200 (CEST) Subject: noarch and %{_libdir} issues on 64-bit platforms In-Reply-To: References: Message-ID: <47270.192.54.193.58.1215458125.squirrel@rousalka.dyndns.org> Le Lun 7 juillet 2008 18:41, Peter Lemenkov a ?crit : > Hello All! > > If someone tries to package executable script (arch-neytral) which > must be placed into %{_libdir}/something If it's really arch-neutral its place is in /usr/share/sotmething not libdir -- Nicolas Mailhot From moe at blagblagblag.org Mon Jul 7 19:24:56 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 16:24:56 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4871CCB0.6030508@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> Message-ID: <48726D88.7020407@blagblagblag.org> Rahul Sundaram wrote: > jeff wrote: >>>> But there are numerous other justifications I could give, including my >>>> personal belief that it's absolutely nuts to thrust SE Linux upon >>>> unsuspecting Desktop users (who don't know what it is anyway) without >>>> giving them the choice to turn it off. >>> >>> If they don't know what it is, how are they supposed to decide to shut >>> it off or not? >> >> Perhaps by way of a compromise it could be noted in the installation >> docs if you want to disable SELinux you should add "linux selinux=0" >> to the boot: line of the install CD. This would make the option >> available the same way that xfs/reiserfs/jfs are available. The user >> isn't confronted with it, but Linus[1] can then easily disable it at >> install time. > > The policy has already been fixed Which policy? The no dialog box in anaconda? I'm not saying it should be restored. I'm offering a workaround with *no* dialog box, default installs get SELinux, but users that *know* they don't want SELinux still have an option for it at install time. > and swfdec isn't installed by default so there is no need to do that. I didn't mean to drag swfdec into this--I pointed at that bug for this quote (which I should have made more clear): torvalds at linux-foundation.org wrote[1]: "Normally I just turn selinux off" > It is already documented in the SELinux > FAQ now but installation guide can have a reference too. Well, it would require *slightly* more than just that: like a couple lines in anaconda to make sure that selinux=0 got passed to grub.conf. That's it though. Very very unobtrusive. > File a RFE. Done. https://bugzilla.redhat.com/show_bug.cgi?id=454338 -Jeff [1] https://bugzilla.redhat.com/show_bug.cgi?id=439858#c31 From sundaram at fedoraproject.org Tue Jul 8 01:02:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Jul 2008 06:32:44 +0530 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48726D88.7020407@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> Message-ID: <4872BCB4.5020402@fedoraproject.org> jeff wrote: >> The policy has already been fixed > > Which policy? SELinux policy of course. The bug your referenced has more details. > I didn't mean to drag swfdec into this--I pointed at that bug for this > quote (which I should have made more clear): Developers frequently do turn off on all sort of security measures including firewalls just to avoid having to debug such issues. It is not very relevant for regular users. Rahul From ville.skytta at iki.fi Mon Jul 7 19:34:18 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 7 Jul 2008 22:34:18 +0300 Subject: noarch and %{_libdir} issues on 64-bit platforms In-Reply-To: <47270.192.54.193.58.1215458125.squirrel@rousalka.dyndns.org> References: <47270.192.54.193.58.1215458125.squirrel@rousalka.dyndns.org> Message-ID: <200807072234.19212.ville.skytta@iki.fi> On Monday 07 July 2008, Nicolas Mailhot wrote: > Le Lun 7 juillet 2008 18:41, Peter Lemenkov a ?crit : > > Hello All! > > > > If someone tries to package executable script (arch-neytral) which > > must be placed into %{_libdir}/something > > If it's really arch-neutral its place is in /usr/share/sotmething not > libdir Somewhere in %{_libexecdir} would work too. From sonar_guy at c-ccom.com Mon Jul 7 19:34:29 2008 From: sonar_guy at c-ccom.com (Scott Glaser) Date: Mon, 07 Jul 2008 15:34:29 -0400 Subject: IRC support meeting - 2008-07-10 at 18:00 UTC In-Reply-To: <20080707130556.5e803959@ohm.scrye.com> References: <20080707130556.5e803959@ohm.scrye.com> Message-ID: <1215459269.3269.0.camel@localhost.localdomain> On Mon, 2008-07-07 at 13:05 -0600, Kevin Fenzi wrote: > We would like to have another meeting of folks interested in #fedora > and IRC support this thursday at 18:00 UTC (right after the FESCo > meeting). > > Topics: > > - Code of conduct for IRC support channels. > - Scheduling timeperiods for helpers > - Recruiting more helpers. > - Decide if we should be a SIG or not. > - Any other topics folks would like to discuss... > > All interested parties are welcome to join us! > > kevin > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Count me in I will be there. Scott Glaser Fedora Unity Founder From moe at blagblagblag.org Mon Jul 7 19:37:29 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 16:37:29 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872BCB4.5020402@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> Message-ID: <48727079.60304@blagblagblag.org> Rahul Sundaram wrote: > jeff wrote: >>> The policy has already been fixed >> >> Which policy? > > SELinux policy of course. The bug your referenced has more details. Well, that's a broad policy. I'm just talking about the ability to disable it, not removing it altogether or whatever. The policy isn't "no one should be able to disable this" is it? I think not. The current policy is to allow users to disable it if they want, correct? Currently this is only available post-install. There are many users that want it at install time too, which was previously available. I'm not asking for a change to selinux policy. >> I didn't mean to drag swfdec into this--I pointed at that bug for this >> quote (which I should have made more clear): > > Developers frequently do turn off on all sort of security measures > including firewalls just to avoid having to debug such issues. It is not > very relevant for regular users. I'm not talking about regular users. I'm talking about users that also use things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux. -Jeff From sundaram at fedoraproject.org Tue Jul 8 01:16:37 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Jul 2008 06:46:37 +0530 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48727079.60304@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> Message-ID: <4872BFF5.7010500@fedoraproject.org> jeff wrote: > Well, that's a broad policy. I'm just talking about the ability to > disable it, not removing it altogether or whatever. That wasn't clear from your reference to the bugzilla report which was very specifically due to the interactions between swfdec being installed by default and issues with SELinux policy which has subsequently been fixed. > I'm not talking about regular users. I'm talking about users that also > use things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux. All filesystems that support extended attributes including the above does support SELinux too so that choice shouldn't matter much. If users prefer to disable it for other reasons, that should be supported which the RFE you filed should cover. Rahul From moe at blagblagblag.org Mon Jul 7 19:55:01 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 16:55:01 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872BFF5.7010500@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> Message-ID: <48727495.9070603@blagblagblag.org> Rahul Sundaram wrote: > jeff wrote: >> Well, that's a broad policy. I'm just talking about the ability to >> disable it, not removing it altogether or whatever. > > That wasn't clear from your reference to the bugzilla report which was > very specifically due to the interactions between swfdec being installed > by default and issues with SELinux policy which has subsequently been > fixed. I'm not trying to talk about swfdec *AT ALL*. I referenced that bug report to show that even Linus Torvalds himself typically disables selinux (along with probably hundreds of thousands of other people). >> I'm not talking about regular users. I'm talking about users that also >> use things like reiserfs/jfs/xfs/etc. and *know* they don't want selinux. > > All filesystems that support extended attributes including the above > does support SELinux too so that choice shouldn't matter much. If users > prefer to disable it for other reasons, that should be supported which > the RFE you filed should cover. Sorry I'm not being very clear. I'm not trying to talk about how those filesystems and selinux interact. I was merely pointing out reiserfs/jfs/xfs since they are supported in a similar way that I think disabling selinux could be supported. I simply meant, "Hey, there are obscure filesystem setups which are supported for power users via the 'boot:' line--we could do something similar with selinux". But the proposal is getting confused with these side topics. The proposal is simply to satisfy the people that want SELinux by default and the people that don't want SELinux at install time. It meets the needs of both with minimal changes to fedora. -Jeff From gnomeuser at gmail.com Mon Jul 7 19:57:47 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 7 Jul 2008 21:57:47 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48727495.9070603@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> Message-ID: <1dedbbfc0807071257p4939da95x94328be5b43e6bcc@mail.gmail.com> 2008/7/7 jeff : > Rahul Sundaram wrote: > >> jeff wrote: >> >>> Well, that's a broad policy. I'm just talking about the ability to >>> disable it, not removing it altogether or whatever. >>> >> >> That wasn't clear from your reference to the bugzilla report which was >> very specifically due to the interactions between swfdec being installed by >> default and issues with SELinux policy which has subsequently been fixed. >> > > I'm not trying to talk about swfdec *AT ALL*. I referenced that bug report > to show that even Linus Torvalds himself typically disables selinux (along > with probably hundreds of thousands of other people). Because Linus Torvalds perfectly describes our average user? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Tue Jul 8 01:32:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Jul 2008 07:02:51 +0530 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48727495.9070603@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> Message-ID: <4872C3C3.50303@fedoraproject.org> jeff wrote: > I'm not trying to talk about swfdec *AT ALL*. I referenced that bug > report to show that even Linus Torvalds himself typically disables > selinux (along with probably hundreds of thousands of other people). What Linus does hardly represents the case for the average end user and citing him as an example makes no sense to me as I explained earlier. We all don't choose our text editor, desktop environment or system architecture based on that either. > Sorry I'm not being very clear. > > The proposal is simply to satisfy the people that want SELinux by > default and the people that don't want SELinux at install time. It > meets the needs of both with minimal changes to fedora. Alright. Rahul From moe at blagblagblag.org Mon Jul 7 20:02:29 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 17:02:29 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1dedbbfc0807071257p4939da95x94328be5b43e6bcc@mail.gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <1dedbbfc0807071257p4939da95x94328be5b43e6bcc@mail.gmail.com> Message-ID: <48727655.9060902@blagblagblag.org> David Nielsen wrote: > > > 2008/7/7 jeff >: > > Rahul Sundaram wrote: > > jeff wrote: > > Well, that's a broad policy. I'm just talking about the > ability to disable it, not removing it altogether or whatever. > > > That wasn't clear from your reference to the bugzilla report > which was very specifically due to the interactions between > swfdec being installed by default and issues with SELinux policy > which has subsequently been fixed. > > > I'm not trying to talk about swfdec *AT ALL*. I referenced that bug > report to show that even Linus Torvalds himself typically disables > selinux (along with probably hundreds of thousands of other people). > > > Because Linus Torvalds perfectly describes our average user? Again, I'm not talking about the average user. I'm talking about the same class of users that also know that they want things like xfs/jfs/reiserfs. Or is Fedora only for the "average user"? I would presume fedora would also want to satisfy non-average users, such as developers. You comment is pure noise. -Jeff From alan at redhat.com Mon Jul 7 20:08:09 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 7 Jul 2008 16:08:09 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872C3C3.50303@fedoraproject.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> Message-ID: <20080707200809.GA17236@devserv.devel.redhat.com> On Tue, Jul 08, 2008 at 07:02:51AM +0530, Rahul Sundaram wrote: > What Linus does hardly represents the case for the average end user and > citing him as an example makes no sense to me as I explained earlier. We > all don't choose our text editor, desktop environment or system > architecture based on that either. "Don't bother shipping CVS I'll just write my own version control" ;) From moe at blagblagblag.org Mon Jul 7 20:12:13 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 17:12:13 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <20080707200809.GA17236@devserv.devel.redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> Message-ID: <4872789D.80006@blagblagblag.org> Alan Cox wrote: > On Tue, Jul 08, 2008 at 07:02:51AM +0530, Rahul Sundaram wrote: >> What Linus does hardly represents the case for the average end user and >> citing him as an example makes no sense to me as I explained earlier. We >> all don't choose our text editor, desktop environment or system >> architecture based on that either. > > "Don't bother shipping CVS I'll just write my own version control" ;) Heh. And thank god he did! /me git ;) But my proposal threadlet now has 9 posts but zero comments on the actual proposal. Everything has been about side issues and such. Mr. Cox, do you see and *technical* problems with the selinux=0 passed to anaconda passed to grub.conf proposal? Thanks, -Jeff From drago01 at gmail.com Mon Jul 7 20:32:59 2008 From: drago01 at gmail.com (drago01) Date: Mon, 7 Jul 2008 22:32:59 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872789D.80006@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> Message-ID: The whole discussion is pointless ... the option is not gone you *can* disable it after install if you want. Let me repeat this again you *can* still disable it if you want, nobody is forcing you to use it. Asking everything at install time is just wrong and confusing for average users. Add adding some hidden anaconda option only to save 1-2min for people that want to disable something doesn't make sense to me. If you know what selinux is, and have reasons to disable it isn't hard to do so. From bpepple at fedoraproject.org Mon Jul 7 20:34:32 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 07 Jul 2008 16:34:32 -0400 Subject: FESCo Meeting Summary for 2008-07-03 Message-ID: <1215462872.5070.5.camel@kennedy> == Members == === Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Josh Boyer (jwb) * Tom Callaway (spot) === Absent === * Christopher Aillon (caillon) * Christian Iseli (c4chris) * Jeremy Katz (jeremy) == Summary == === Feature Process === * FESCo approved the following proposals to the Feature process: * http://fedoraproject.org/wiki/Features/F10PolicyReview#Tracking_Bugs * http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans * http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections * http://fedoraproject.org/wiki/Features/F10PolicyReview#Feedback_for_incomplete_feature_pages IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-03.html Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Mon Jul 7 20:40:02 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 07 Jul 2008 16:40:02 -0400 Subject: [Reminder] FESCo Election Nominations Message-ID: <1215463202.5070.12.camel@kennedy> Hi all, This is a reminder that the nomination period for the upcoming FESCo election is currently underway, and lasts until July 13th, 2008 0:00 UTC. If you wish to run for FESCo, please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From moe at blagblagblag.org Mon Jul 7 20:43:52 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 17:43:52 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> Message-ID: <48728008.2050705@blagblagblag.org> drago01 wrote: > The whole discussion is pointless ... the option is not gone you *can* > disable it after install if you want. You *could* disable it at install time too, easily. It would likely install faster as well. > Let me repeat this again you *can* still disable it if you want, > nobody is forcing you to use it. Yes, I know that. > Asking everything at install time is just wrong and confusing for average users. I agree. That's why my proposal doesn't ask anything at install time, thus the average user doesn't have to confront the issue. As a parallel example, I offer how xfs/jfs/reiserfs are available, but the user isn't prompted. In my solution the average user wouldn't be confused at all because they wouldn't see it--just like they don't see xfs/jfs/reiserfs options. > Add adding some hidden anaconda option only to save 1-2min for people > that want to disable something doesn't make sense to me. Well, it would actually save more than 1-2 min. And it really isn't a hidden anaconda option, it's just having anaconda pass that to grub. Anaconda already has some support for this, it just doesn't pass it to grub. It may be a simple one-liner in anaconda. -Jeff From opensource at till.name Mon Jul 7 21:10:39 2008 From: opensource at till.name (Till Maas) Date: Mon, 7 Jul 2008 23:10:39 +0200 Subject: noarch and %{_libdir} issues on 64-bit platforms In-Reply-To: References: Message-ID: <200807072310.48514.opensource@till.name> On Monday 07 July 2008 18:41:31 Peter Lemenkov wrote: > If someone tries to package executable script (arch-neytral) which must be > placed into %{_libdir}/something (for example, nagios-plugin which must go > How to overcome this issue and package utility as noarch? I guess the problem here is that you want to put the executable below %{_libdir}, afaik executables should go below %{_libexecdir}. But I guess that nagios needs to be patched to use %{_libexecdir}, which is the same for i386 and x86_64 afaik and should not hurt, because %{_bindir} is also the same on both archs. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rjones at redhat.com Mon Jul 7 21:15:54 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 22:15:54 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707094704.GA5497@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> Message-ID: <20080707211554.GA8320@amd.home.annexia.org> I've got a self-building, mostly working set of Fedora packages for the MinGW cross-compiler (no optional libraries yet). You can get the spec files and instructions by doing: hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel Please read the README file first. 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 drago01 at gmail.com Mon Jul 7 21:28:48 2008 From: drago01 at gmail.com (drago01) Date: Mon, 7 Jul 2008 23:28:48 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48728008.2050705@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <48728008.2050705@blagblagblag.org> Message-ID: On Mon, Jul 7, 2008 at 10:43 PM, jeff wrote: > drago01 wrote: >> >> The whole discussion is pointless ... the option is not gone you *can* >> disable it after install if you want. > > You *could* disable it at install time too, easily. It would likely install > faster as well. You could set stuff like display resolution at install time too .. and we got rid of it, which is a good thing imho. Why should it be faster? >> Let me repeat this again you *can* still disable it if you want, >> nobody is forcing you to use it. > > Yes, I know that. Fine, where is the problem than? >> Asking everything at install time is just wrong and confusing for average >> users. > > I agree. That's why my proposal doesn't ask anything at install time, thus > the average user doesn't have to confront the issue. As a parallel example, > I offer how xfs/jfs/reiserfs are available, but the user isn't prompted. > > In my solution the average user wouldn't be confused at all because they > wouldn't see it--just like they don't see xfs/jfs/reiserfs options. Which shouldn't be the case but that's a different topic. >> Add adding some hidden anaconda option only to save 1-2min for people >> that want to disable something doesn't make sense to me. > > Well, it would actually save more than 1-2 min. Well changing one line in /etc/selinux/config can't take much longer ;) > And it really isn't a hidden > anaconda option, it's just having anaconda pass that to grub. Anaconda > already has some support for this, it just doesn't pass it to grub. It may > be a simple one-liner in anaconda. Well the options get passed to the kernel not to anaconda, it just parses (abuses) the kernel cmdline for stuff like this. (which isn't a bad thing in general) From moe at blagblagblag.org Mon Jul 7 21:33:31 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 18:33:31 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <48728008.2050705@blagblagblag.org> Message-ID: <48728BAB.3050109@blagblagblag.org> drago01 wrote: >> And it really isn't a hidden >> anaconda option, it's just having anaconda pass that to grub. Anaconda >> already has some support for this, it just doesn't pass it to grub. It may >> be a simple one-liner in anaconda. > Well the options get passed to the kernel not to anaconda, it just > parses (abuses) the kernel cmdline for stuff like this. (which isn't a > bad thing in general) I agree. And anaconda could just take one more step and add it to grub.conf ala anaconda.id.bootloader.args.append. Voila, done. I don't think it is doing this already, but I may be mistaken. -Jeff From Matt_Domsch at dell.com Mon Jul 7 21:34:43 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jul 2008 16:34:43 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 Message-ID: <20080707163443.A8909@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 Based on the tree as of Thu Jul 3 2008. While I'm waiting on a bugzilla fix, I don't have all bugzilla numbers for existing FTBFS bugs. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5873 Number failed to build: 260 Number expected to fail due to ExclusiveArch or ExcludeArch: 38 Leaving: 222 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... aiksaurus-1.2.1-15.fc6 (build/make) uwog anjuta-2.4.1-1.fc10 (build/make) rishi apr-api-docs-1.2.12-1.fc9 (build/make) bojan ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astyle-1.21-6.fc8 (build/make) addutko,mtasaka audacious-plugin-fc-0.2-6 (build/make) mschwendt axis-1.2.1-3jpp.9.fc10 (build/make) pcheung bes-3.5.3-3.fc9 (build/make) pertusus blacs-1.1-26.fc9.1 (build/make) spot blam-1.8.3-13.fc9 (build/make) alexlan,sindrepb bodhi-0.4.10-3.fc9 (build/make) lmacken,toshio,timlau brutus-keyring-0.9.0-6.fc8 (build/make) bpepple,colding buoh-0.8.2-4.fc9 (build/make) chabotc callweaver-1.2-0.4.rc5.20071230.fc9 (build/make) dwmw2 camstream-0.26.3-12.fc8 (build/make) nomis80 claws-mail-3.4.0-1.fc10 (build/make) awjb compat-db-4.5.20-5.fc9 (build/make) jnovy condor-7.0.0-8.fc9 (build/make) matt conexusmm-0.5.0-3.fc7 (build/make) rvinyard crossfire-1.10.0-4.fc9 (build/make) wart dap-freeform_handler-3.7.7-2.fc9 (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 (build/make) pertusus dar-2.3.6-3.fc9 (build/make) xris db4-4.6.21-6.fc9 (build/make) jnovy dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha drivel-2.1.1-0.5.20071130svn.fc9 (build/make) pfrields dvdauthor-0.6.14-5.fc9 (build/make) scop eclipse-3.3.2-12.fc9 (build/make) overholt,oliver,overholt elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig freefem++-2.24-2.fc9 (build/make) rathann gdesklets-0.36-1.fc9 (build/make) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux genius-1.0.2-3.fc9 (build/make) gemi gimmix-0.4.2-3.fc9 (build/make) awjb gl-117-1.3.2-4.fc7 (build/make) steve glade2-2.12.2-2.fc9 (build/make) mclasen gnome-applet-tvn24-0.2.8-3.fc9 (build/make) orphan gpsim-0.22.0-5.fc8 (build/make) dionysos gstm-1.2-6.fc7 (build/make) splinux gtk+-1.2.10-61.fc9 (build/make) rdieter gtk2hs-0.9.12.1-8.fc9 (build/make) bos,petersen gtk-sharp-1.0.10-12.fc7 (build/make) pfj httpd-2.2.8-3 (build/make) jorton inkscape-0.46-2.fc9 (build/make) lkundrak,lkundrak ipa-1.1.0-2.fc10 (build/make) rcritten,simo itpp-4.0.0-2.fc9 (build/make) edhill javasqlite-20080420-1.fc10 (build/make) scop jgroups-2.2.9.2-3jpp.2 (build/make) dbhole k3b-1.0.5-2.fc10 (build/make) rrakus,rdieter kdesvn-0.14.4-1.fc10 (build/make) orion kdevelop-3.5.2-2.fc10 (build/make) than,rdieter,kkofler,ltinkl ktechlab-0.3.69-5.fc8 (build/make) chitlesh libapreq2-2.09-0.17.rc2.fc10 (build/make) bojan libdap-3.7.10-2.fc9 (build/make) pertusus libgnomecups-0.2.3-3.fc9 (build/make) davidz libgtksourceviewmm-0.3.1-1.fc8 (build/make) splinux libnc-dap-3.7.0-9.fc9 (build/make) pertusus librra-0.11-2.fc9 (build/make) awjb,abompard libtomoe-gtk-0.6.0-3.fc9 (build/make) ryo,petersen lineakd-0.9-5.fc6 (build/make) xris lineak-defaultplugin-0.9-2.fc6 (build/make) xris lineak-xosdplugin-0.9-2.fc6 (build/make) xris lsdvd-0.16-7.fc9 (build/make) thias mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mimetic-0.9.3-2.fc8 (build/make) ensc mod_python-3.3.1-7 (build/make) jorton moto4lin-0.3-6.fc7 (build/make) jafo mx-2.0.6-3 (build/make) misa mx4j-3.0.1-6jpp.4 (build/make) fnasser MyPasswordSafe-0.6.7-4.20061216.fc9 (build/make) ertzing nethack-vultures-2.1.0-10.fc8 (build/make) meme oooqs2-1.0-3.fc6 (build/make) ausil openbabel-2.2.0-0.5.b5.fc10 (build/make) rathann pan-0.132-2.fc8 (build/make) adalloz,mpeters pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo pekwm-0.1.5-5.fc7 (build/make) errr perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-DateTime-Format-Strptime-1.0702-2.fc9 (build/make) steve,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-MooseX-Object-Pluggable-0.0005-2.fc9 (build/make) cweyl,perl-sig perl-Pugs-Compiler-Rule-0.28-2.fc9 (build/make) steve,perl-sig perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig perl-Test-AutoBuild-1.2.2-3.fc9 (build/make) berrange petitboot-0.0.1-7.fc8 (build/make) dwmw2,jwboyer pl-5.6.57-2.fc10 (build/make) gemi,mef podsleuth-0.6.0-5.fc10 (build/make) nigelj ppl-0.9-19.fc9 (build/make) bagnara pwlib-1.10.10-6.fc9 (build/make) veillard pysvn-1.5.3-1.fc10 (build/make) ravenoak python-durus-3.5-3.fc7 (build/make) shahms python-reportlab-2.1-2.fc9 (build/make) bpepple python-tgcaptcha-0.11-3.fc10 (build/make) lmacken python-turboflot-0.1.1-1.fc10 (build/make) lmacken python-TurboMail-2.1-3.fc9 (build/make) lmacken pywbxml-0.1-3.fc9 (build/make) awjb qgo-1.5.4r2-1.fc9 (build/make) kaboom qps-1.9.19-0.2.b.fc7 (build/make) makghosh qt4-theme-quarticurve-0.0-0.11.beta7.fc9 (build/make) kkofler qtiplot-0.9-8.fc9 (build/make) frankb R-RScaLAPACK-0.5.1-11.fc9.2 (build/make) spot ruby-bdb-0.6.0-1.fc7 (build/make) errr rudeconfig-5.0.5-1.fc7 (build/make) homeless scalapack-1.7.5-2.fc9 (build/make) spot scim-skk-0.5.2-8.fc6 (build/make) ryo scim-tomoe-0.6.0-3.fc10 (build/make) ryo,petersen setools-3.3.4-1.fc9 (build/make) pebenito,dwalsh smarteiffel-2.3-2.fc9 (build/make) gemi spicebird-0.4-5.fc8 (build/make) tuxbrewr stardict-3.0.1-8.fc9 (build/make) cchance,zhu subcommander-1.9.93-2.fc10 (build/make) s4504kr subversion-api-docs-1.4.6-1.fc9 (build/make) bojan sugar-journal-79-3.fc9 (build/make) ausil supertux-0.3.1-1.fc9 (build/make) steve swfdec-gnome-2.22.0-1.fc9 (build/make) bpepple tachyon-0.98-0.6.20070319.fc9 (build/make) rathann tuxcmd-0.6.36-3.fc10 (build/make) tbzatek vtk-5.0.4-21.fc9 (build/make) athimm,orion wyrd-1.4.4-1.fc9 (build/make) till xemacs-21.5.28-6.fc9 (build/make) scop xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xscorch-0.2.0-12.fc8 (build/make) mgarski xsupplicant-1.2.8-7.fc10 (build/make) spot amanda-2.5.2p1-10.fc9 ['449479 NEW'] (build/make) rbrich aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 ASSIGNED'] (build/make) ixs,mmcgrath bitbake-1.8.8-1.fc8 ['440562 ASSIGNED'] (build/make) ixs bmpx-0.40.14-5.fc9 ['449431 NEW'] (build/make) akahl brltty-3.9-2.2.fc9 ['449446 NEW'] (build/make) kasal contacts-0.8-3.fc10 ['449603 NEW'] (build/make) jkeating coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias dxpc-3.9.1-0.3.b1.fc9 ['449644 NEW'] (build/make) guthrie ekg2-0.2-0.1.rc1.fc10 ['449637 NEW'] (build/make) rathann erlang-R12B-1.1.fc9 ['449432 NEW'] (build/make) gemi fakechroot-2.5-13.fc9 ['449447 NEW'] (build/make) athimm fakeroot-1.6.4-16.fc9 ['449659 NEW'] (build/make) athimm firewalk-5.0-2.fc9 ['449546 NEW'] (build/make) sindrepb fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gauche-0.8.13-1.fc9 ['449627 NEW'] (build/make) gemi gauche-gl-0.4.4-3.fc9 ['449490 NEW'] (build/make) gemi gauche-gtk-0.4.1-17.fc9 ['449421 NEW'] (build/make) gemi gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gcombust-0.1.55-13 ['449413 NEW'] (build/make) thias geronimo-specs-1.0-1.M2.2jpp.12 ['449610 NEW'] (build/make) fnasser glib-1.2.10-29.fc9 ['449582 NEW'] (build/make) rdieter gnome-specimen-0.3-1.fc8 ['440868 NEW'] (build/make) splinux gnupg2-2.0.9-1.fc9 ['449574 NEW'] (build/make) rdieter,nalin gpgme-1.1.6-3.fc9 ['449416 NEW'] (build/make) rdieter graphviz-2.16.1-0.5.fc9 ['449410 NEW'] (build/make) jima gridengine-6.1u4-1.fc10 ['449526 ASSIGNED'] (build/make) orion ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa kdebluetooth-1.0-0.41.beta8.fc9 ['449604 ASSIGNED'] (build/make) gilboa,scop kickpim-0.5.3-14.fc9 ['449538 ASSIGNED'] (build/make) rdieter klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal ladspa-1.12-9.fc9 ['449542 NEW'] (build/make) thomasvs libFoundation-1.1.3-11.fc9 ['440564 ASSIGNED'] (build/make) athimm libfwbuilder-2.1.16-2.fc9 ['449591 NEW'] (build/make) ertzing libgii-1.0.2-6.fc9 ['449484 NEW'] (build/make) kwizart libidn-0.6.14-7 ['449440 NEW'] (build/make) jorton libopensync-0.36-2.fc9 ['449510 ASSIGNED'] (build/make) awjb libsigsegv-2.4-6.fc9 ['449607 NEW'] (build/make) rdieter libstroke-0.5.1-17.fc9 ['449516 NEW'] (build/make) chitlesh libzzub-0.2.3-12.fc9 ['449661 NEW'] (build/make) akahl,mtasaka lilypond-2.10.33-1.fc8 ['440826 NEW'] (build/make) qspencer linpsk-0.9-3.fc9 ['440778 ASSIGNED'] (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 ['449613 NEW'] (build/make) dwmw2 lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux mod_suphp-0.6.3-1.fc9 ['449578 NEW'] (build/make) ixs monodevelop-0.19-6.fc9 ['449441 NEW'] (build/make) pfj muine-0.8.8-9.fc9 ['449567 NEW'] (build/make) sindrepb mysql-connector-java-3.1.12-5.fc9 ['449529 NEW'] (build/make) ifoox mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW'] (build/make) ausil nco-3.9.3-1.fc9 ['449408 NEW'] (build/make) edhill,pertusus ntfs-config-1.0-0.6.rc5.fc9 ['449585 NEW'] (build/make) laxathom ntl-5.4.2-2.fc9 ['449523 NEW'] (build/make) rdieter oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa pam_abl-0.2.3-4.fc9 ['449429 NEW'] (build/make) adalloz,tmraz pdsh-2.11-6.fc9 ['440811 NEEDINFO'] (build/make) kg6fnk perl-Class-MethodMaker-2.10-3.fc9 ['449442 NEW'] (build/make) dgregor,perl-sig perl-Crypt-Simple-0.06-5.fc9 ['449495 NEW'] (needs_perl_ExtUtils_MakeMaker) allisson perl-Gnome2-GConf-1.044-3.fc9 ['449470 NEW'] (build/make) cweyl,perl-sig perl-MIME-Lite-3.01-6.fc9 ['449558 NEW'] (build/make) mmcgrath,perl-sig perl-Net-CUPS-0.55-4.fc9 ['449469 NEW'] (build/make) cweyl,perl-sig perl-Net-Packet-3.25-3.fc9 ['449473 NEW'] (build/make) sindrepb perl-Net-Write-1.00-3.fc9 ['449620 NEW'] (build/make) sindrepb perl-Text-CharWidth-0.04-4.fc9 ['449483 NEW'] (build/make) athimm perl-Text-WrapI18N-0.06-3.fc9 ['449435 NEW'] (build/make) athimm perl-XML-LibXSLT-1.63-5.fc9 ['449544 ASSIGNED'] (build/make) shishz,perl-sig pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa plague-0.4.4.1-4.fc7 ['440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar plplot-5.9.0-1.fc9 ['449488 ASSIGNED'] (build/make) orion python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms pyzor-0.4.0-11.fc7 ['440790 ASSIGNED'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qcad-2.0.5.0-8.fc9 ['449636 NEW'] (build/make) gemi qmmp-0.1.5-2.fc9 ['449658 ASSIGNED'] (build/make) kvolny,jwrdegoede qscintilla-2.2-1.fc10 ['449423 NEW'] (build/make) rdieter qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando rapidsvn-0.9.6-1.fc9 ['449500 NEW'] (build/make) timj R-Matrix-0.999375-4.fc9 ['449530 NEW'] (build/make) tmoertel scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip svnmailer-1.0.8-3.fc7 ['449666 ASSIGNED'] (build/make) mfleming tomcat5-5.5.26-1jpp.2.fc9 ['449618 NEW'] (build/make) devrim,devrim xlhtml-0.5-8.fc9 ['449476 NEW'] (build/make) abompard xmms-cdread-0.14-13.fc9 ['449468 NEW'] (build/make) jsoeterb yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa ---------------------------------- Packages by owner: abompard: librra,xlhtml adalloz: pam_abl,pan addutko: astyle agk: dmraid akahl: bmpx,libzzub alexlan: blam allisson: perl-Crypt-Simple ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mysql-gui-tools,oooqs2,sugar-journal awjb: aterm,claws-mail,gimmix,koffice-langpack,libopensync,librra,pywbxml,scribus bagnara: ppl berrange: perl-Test-AutoBuild bjensen: linpsk bmr: dmraid bojan: apr-api-docs,libapreq2,subversion-api-docs bos: gtk2hs bpepple: brutus-keyring,python-reportlab,swfdec-gnome cchance: stardict chabotc: buoh chitlesh: ktechlab,libstroke colding: brutus-keyring cr33dog: fontypython cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-Gnome2-GConf,perl-MooseX-Object-Pluggable,perl-Net-CUPS,perl-RRD-Simple davidz: libgnomecups dbhole: jgroups dcbw: plague devrim: tomcat5,tomcat5 dgregor: perl-Class-MethodMaker dionysos: gpsim dwalsh: setools dwmw2: callweaver,linux-atm,petitboot dwysocha: dmraid edhill: itpp,nco ensc: mimetic errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fnasser: geronimo-specs,mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython frankb: qtiplot gemi: erlang,gauche,gauche-gl,gauche-gtk,genius,pl,qcad,smarteiffel gilboa: kdebluetooth green: ardour guthrie: dxpc hguemar: plotmm homeless: rudeconfig iburrell: perl-SVN-Mirror icon: gazpacho ifoox: ht2html,mysql-connector-java ixs: bacula,bitbake,mod_suphp,pyzor jafo: moto4lin,python-memcached,python-pydns,python-pyspf jima: graphviz jkeating: contacts jmagne: coolkey jnovy: compat-db,db4 jorton: httpd,libidn,mod_python jsoeterb: xmms-cdread jwboyer: petitboot jwrdegoede: ardour,qmmp kaboom: qgo kasal: brltty kg6fnk: pdsh kkofler: kdevelop,qt4-theme-quarticurve kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra,libgii,perl-Event-Lib laxathom: ntfs-config leo: pcmanx-gtk2 lkundrak: inkscape,inkscape lmacken: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot ltinkl: kdevelop luya: gdesklets lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbroz: dmraid mclasen: glade2 mef: pl meme: nethack-vultures mfleming: svnmailer mgarski: xscorch misa: mx mmcgrath: bacula,perl-MIME-Lite mornfall: dmraid mpeters: pan mschwendt: audacious-plugin-fc mtasaka: astyle,libzzub mwiriadi: mediatomb nalin: gnupg2 nando: qsynth navid: sos ngompa: oggconvert nigelj: podsleuth nomis80: camstream oliver: eclipse,fish orion: gridengine,kdesvn,plplot,vtk orphan: gnome-applet-tvn24 overholt: eclipse,eclipse owentl: gdesklets pcheung: axis pebenito: setools perl-sig: perl-Catalyst-Plugin-ConfigLoader,perl-Class-MethodMaker,perl-DateTime-Format-Strptime,perl-Event-Lib,perl-Gnome2-GConf,perl-MIME-Lite,perl-MooseX-Object-Pluggable,perl-Net-CUPS,perl-Pugs-Compiler-Rule,perl-RRD-Simple,perl-SVN-Mirror,perl-XML-LibXSLT pertusus: bes,dap-freeform_handler,dap-hdf4_handler,elektra,libdap,libnc-dap,nco petersen: gtk2hs,libtomoe-gtk,scim-tomoe pfj: gtk-sharp,monodevelop pfrields: drivel pknirsch: freeipmi qspencer: lilypond rathann: ekg2,freefem++,openbabel,tachyon ravenoak: pysvn rbrich: amanda rcritten: ipa rdieter: glib,gnupg2,gpgme,gtk+,k3b,kdevelop,kickpim,libsigsegv,ntl,qscintilla rishi: anjuta roozbeh: fonttools rrakus: k3b rrelyea: coolkey rvinyard: conexusmm ryo: libtomoe-gtk,scim-skk,scim-tomoe s4504kr: subcommander sconklin: linpsk scop: dvdauthor,javasqlite,kdebluetooth,xemacs shahms: python-durus,python-simpletal,python-tpg shishz: perl-XML-LibXSLT simo: ipa sindrepb: blam,firewalk,linpsk,muine,perl-Net-Packet,perl-Net-Write splinux: gdmap,gnome-specimen,gstm,libgtksourceviewmm,lostirc,lostirc spot: R-RScaLAPACK,blacs,scalapack,xsupplicant steve: gl-117,perl-DateTime-Format-Strptime,perl-Pugs-Compiler-Rule,supertux subhodip: straw tbzatek: tuxcmd than: kdevelop thias: djvulibre,gcombust,lsdvd thomasvs: ladspa till: wyrd timj: rapidsvn timlau: bodhi tmoertel: R-Matrix tmraz: pam_abl toshio: bodhi,qa-assistant trasher: klear tuxbrewr: spicebird uwog: aiksaurus veillard: pwlib wart: crossfire xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd zhu: stardict -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Mon Jul 7 21:35:41 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jul 2008 16:35:41 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-07-03 Message-ID: <20080707163541.A8977@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 Based on the tree as of Thu Jul 3 2008. While I'm waiting on a bugzilla fix, I don't have all bugzilla numbers for existing FTBFS bugs. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5874 Number failed to build: 225 Number expected to fail due to ExclusiveArch or ExcludeArch: 13 Leaving: 212 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... aiksaurus-1.2.1-15.fc6 (build/make) uwog anjuta-2.4.1-1.fc10 (buildroot) rishi apr-api-docs-1.2.12-1.fc9 (build/make) bojan ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astyle-1.21-6.fc8 (build/make) addutko,mtasaka atlas-3.6.0-15.fc10 (build/make) qspencer audacious-plugin-fc-0.2-6 (build/make) mschwendt bes-3.5.3-3.fc9 (build/make) pertusus blacs-1.1-26.fc9.1 (build/make) spot blam-1.8.3-13.fc9 (build/make) alexlan,sindrepb bodhi-0.4.10-3.fc9 (build/make) lmacken,toshio,timlau brutus-keyring-0.9.0-6.fc8 (build/make) bpepple,colding buoh-0.8.2-4.fc9 (build/make) chabotc callweaver-1.2-0.4.rc5.20071230.fc9 (build/make) dwmw2 camstream-0.26.3-12.fc8 (build/make) nomis80 claws-mail-3.4.0-1.fc10 (build/make) awjb compat-db-4.5.20-5.fc9 (build/make) jnovy condor-7.0.0-8.fc9 (build/make) matt conexusmm-0.5.0-3.fc7 (build/make) rvinyard crossfire-1.10.0-4.fc9 (build/make) wart dap-freeform_handler-3.7.7-2.fc9 (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 (build/make) pertusus dar-2.3.6-3.fc9 (build/make) xris db4-4.6.21-6.fc9 (build/make) jnovy dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha drivel-2.1.1-0.5.20071130svn.fc9 (build/make) pfrields dvdauthor-0.6.14-5.fc9 (build/make) scop eclipse-3.3.2-12.fc9 (build/make) overholt,oliver,overholt eclipse-subclipse-1.2.4-9.fc9 (build/make) robmv elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig freefem++-2.24-2.fc9 (build/make) rathann gdesklets-0.36-1.fc9 (build/make) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux genius-1.0.2-3.fc9 (build/make) gemi gimmix-0.4.2-3.fc9 (build/make) awjb gl-117-1.3.2-4.fc7 (build/make) steve glade2-2.12.2-2.fc9 (build/make) mclasen gnome-applet-tvn24-0.2.8-3.fc9 (build/make) orphan gpsim-0.22.0-5.fc8 (build/make) dionysos gstm-1.2-6.fc7 (build/make) splinux gtk+-1.2.10-61.fc9 (build/make) rdieter gtk2hs-0.9.12.1-8.fc9 (build/make) bos,petersen gtk-sharp-1.0.10-12.fc7 (build/make) pfj httpd-2.2.8-3 (build/make) jorton inkscape-0.46-2.fc9 (build/make) lkundrak,lkundrak ipa-1.1.0-2.fc10 (build/make) rcritten,simo itpp-4.0.0-2.fc9 (build/make) edhill java-1.6.0-openjdk-1.6.0.0-0.16.b09.fc10 (build/make) fitzsim,lkundrak,langel,mjw jgroups-2.2.9.2-3jpp.2 (build/make) dbhole k3b-1.0.5-2.fc10 (build/make) rrakus,rdieter kdesvn-0.14.4-1.fc10 (build/make) orion kdevelop-3.5.2-2.fc10 (build/make) than,rdieter,kkofler,ltinkl ktechlab-0.3.69-5.fc8 (build/make) chitlesh libapreq2-2.09-0.17.rc2.fc10 (build/make) bojan libdap-3.7.10-2.fc9 (build/make) pertusus libgnomecups-0.2.3-3.fc9 (build/make) davidz libgtksourceviewmm-0.3.1-1.fc8 (build/make) splinux libnc-dap-3.7.0-9.fc9 (build/make) pertusus librra-0.11-2.fc9 (build/make) awjb,abompard libtomoe-gtk-0.6.0-3.fc9 (build/make) ryo,petersen lineakd-0.9-5.fc6 (build/make) xris lineak-defaultplugin-0.9-2.fc6 (build/make) xris lineak-xosdplugin-0.9-2.fc6 (build/make) xris lsdvd-0.16-7.fc9 (build/make) thias mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mimetic-0.9.3-2.fc8 (build/make) ensc mod_python-3.3.1-7 (build/make) jorton moto4lin-0.3-6.fc7 (build/make) jafo mx-2.0.6-3 (build/make) misa mx4j-3.0.1-6jpp.4 (build/make) fnasser MyPasswordSafe-0.6.7-4.20061216.fc9 (build/make) ertzing nethack-vultures-2.1.0-10.fc8 (build/make) meme oooqs2-1.0-3.fc6 (build/make) ausil openbabel-2.2.0-0.5.b5.fc10 (build/make) rathann pan-0.132-2.fc8 (build/make) adalloz,mpeters pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo pekwm-0.1.5-5.fc7 (build/make) errr perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-DateTime-Format-Strptime-1.0702-2.fc9 (build/make) steve,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-MooseX-Object-Pluggable-0.0005-2.fc9 (build/make) cweyl,perl-sig perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig perl-Test-AutoBuild-1.2.2-3.fc9 (build/make) berrange petitboot-0.0.1-7.fc8 (build/make) dwmw2,jwboyer podsleuth-0.6.0-5.fc10 (build/make) nigelj ppl-0.9-19.fc9 (build/make) bagnara pwlib-1.10.10-6.fc9 (build/make) veillard pysvn-1.5.3-1.fc10 (build/make) ravenoak python-durus-3.5-3.fc7 (build/make) shahms python-tgcaptcha-0.11-3.fc10 (build/make) lmacken python-turboflot-0.1.1-1.fc10 (build/make) lmacken python-TurboMail-2.1-3.fc9 (build/make) lmacken pywbxml-0.1-3.fc9 (build/make) awjb qgo-1.5.4r2-1.fc9 (build/make) kaboom qps-1.9.19-0.2.b.fc7 (build/make) makghosh qt4-theme-quarticurve-0.0-0.11.beta7.fc9 (build/make) kkofler qtiplot-0.9-8.fc9 (build/make) frankb R-RScaLAPACK-0.5.1-11.fc9.2 (build/make) spot ruby-bdb-0.6.0-1.fc7 (build/make) errr rudeconfig-5.0.5-1.fc7 (build/make) homeless scalapack-1.7.5-2.fc9 (build/make) spot scim-skk-0.5.2-8.fc6 (build/make) ryo scim-tomoe-0.6.0-3.fc10 (build/make) ryo,petersen setools-3.3.4-1.fc9 (build/make) pebenito,dwalsh smarteiffel-2.3-2.fc9 (build/make) gemi spicebird-0.4-5.fc8 (build/make) tuxbrewr stardict-3.0.1-8.fc9 (build/make) cchance,zhu subcommander-1.9.93-2.fc10 (build/make) s4504kr subversion-api-docs-1.4.6-1.fc9 (build/make) bojan sugar-journal-79-3.fc9 (build/make) ausil supertux-0.3.1-1.fc9 (build/make) steve swfdec-gnome-2.22.0-1.fc9 (build/make) bpepple tachyon-0.98-0.6.20070319.fc9 (build/make) rathann tuxcmd-0.6.36-3.fc10 (build/make) tbzatek vtk-5.0.4-21.fc9 (build/make) athimm,orion wyrd-1.4.4-1.fc9 (build/make) till xemacs-21.5.28-6.fc9 (build/make) scop xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xscorch-0.2.0-12.fc8 (build/make) mgarski xsupplicant-1.2.8-7.fc10 (build/make) spot amanda-2.5.2p1-10.fc9 ['449479 NEW'] (build/make) rbrich aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 ASSIGNED'] (build/make) ixs,mmcgrath bitbake-1.8.8-1.fc8 ['440562 ASSIGNED'] (build/make) ixs bmpx-0.40.14-5.fc9 ['449431 NEW'] (build/make) akahl brltty-3.9-2.2.fc9 ['449446 NEW'] (build/make) kasal contacts-0.8-3.fc10 ['449603 NEW'] (build/make) jkeating coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias dxpc-3.9.1-0.3.b1.fc9 ['449644 NEW'] (build/make) guthrie ekg2-0.2-0.1.rc1.fc10 ['449637 NEW'] (build/make) rathann erlang-R12B-1.1.fc9 ['449432 NEW'] (build/make) gemi fakechroot-2.5-13.fc9 ['449447 NEW'] (build/make) athimm fakeroot-1.6.4-16.fc9 ['449659 NEW'] (build/make) athimm fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gcl-2.6.7-18.fc9 ['440913 NEW'] (build/make) gemi,green glib-1.2.10-29.fc9 ['449582 NEW'] (build/make) rdieter gnupg2-2.0.9-1.fc9 ['449574 NEW'] (build/make) rdieter,nalin gpgme-1.1.6-3.fc9 ['449416 NEW'] (build/make) rdieter graphviz-2.16.1-0.5.fc9 ['449410 NEW'] (build/make) jima HelixPlayer-1.0.9-2.fc9 ['449474 NEW'] (build/make) abompard ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa kdebluetooth-1.0-0.41.beta8.fc9 ['449604 ASSIGNED'] (build/make) gilboa,scop kickpim-0.5.3-14.fc9 ['449538 ASSIGNED'] (build/make) rdieter klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal ladspa-1.12-9.fc9 ['449542 NEW'] (build/make) thomasvs libFoundation-1.1.3-11.fc9 ['440564 ASSIGNED'] (build/make) athimm libfwbuilder-2.1.16-2.fc9 ['449591 NEW'] (build/make) ertzing libidn-0.6.14-7 ['449440 NEW'] (build/make) jorton libopensync-0.36-2.fc9 ['449510 ASSIGNED'] (build/make) awjb libsigsegv-2.4-6.fc9 ['449607 NEW'] (build/make) rdieter libzzub-0.2.3-12.fc9 ['449661 NEW'] (build/make) akahl,mtasaka lilypond-2.10.33-1.fc8 ['440826 NEW'] (build/make) qspencer linpsk-0.9-3.fc9 ['440778 ASSIGNED'] (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 ['449613 NEW'] (build/make) dwmw2 lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux lrmi-0.10-4.fc9 ['449509 NEW'] (build/make) pwouters mod_suphp-0.6.3-1.fc9 ['449578 NEW'] (build/make) ixs monodevelop-0.19-6.fc9 ['449441 NEW'] (build/make) pfj mosml-2.01-11.fc9 ['449445 NEW'] (build/make) gemi muine-0.8.8-9.fc9 ['449567 NEW'] (build/make) sindrepb muine-scrobbler-0.1.8-5.fc9 ['449482 NEW'] (build/make) sindrepb mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW'] (build/make) ausil nco-3.9.3-1.fc9 ['449408 NEW'] (build/make) edhill,pertusus ntfs-config-1.0-0.6.rc5.fc9 ['449585 NEW'] (build/make) laxathom ntl-5.4.2-2.fc9 ['449523 NEW'] (build/make) rdieter oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa pam_abl-0.2.3-4.fc9 ['449429 NEW'] (build/make) adalloz,tmraz pdsh-2.11-6.fc9 ['440811 NEEDINFO'] (build/make) kg6fnk perl-Class-MethodMaker-2.10-3.fc9 ['449442 NEW'] (build/make) dgregor,perl-sig perl-Crypt-Simple-0.06-5.fc9 ['449495 NEW'] (needs_perl_ExtUtils_MakeMaker) allisson perl-Gnome2-GConf-1.044-3.fc9 ['449470 NEW'] (build/make) cweyl,perl-sig perl-MIME-Lite-3.01-6.fc9 ['449558 NEW'] (build/make) mmcgrath,perl-sig perl-Net-CUPS-0.55-4.fc9 ['449469 NEW'] (build/make) cweyl,perl-sig perl-Net-Packet-3.25-3.fc9 ['449473 NEW'] (build/make) sindrepb perl-Net-Write-1.00-3.fc9 ['449620 NEW'] (build/make) sindrepb perl-Text-CharWidth-0.04-4.fc9 ['449483 NEW'] (build/make) athimm perl-Text-WrapI18N-0.06-3.fc9 ['449435 NEW'] (build/make) athimm perl-XML-LibXSLT-1.63-5.fc9 ['449544 ASSIGNED'] (build/make) shishz,perl-sig pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa plague-0.4.4.1-4.fc7 ['440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar plplot-5.9.0-1.fc9 ['449488 ASSIGNED'] (build/make) orion python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms pyzor-0.4.0-11.fc7 ['440790 ASSIGNED'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qcad-2.0.5.0-8.fc9 ['449636 NEW'] (build/make) gemi qmmp-0.1.5-2.fc9 ['449658 ASSIGNED'] (build/make) kvolny,jwrdegoede qscintilla-2.2-1.fc10 ['449423 NEW'] (build/make) rdieter qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando rapidsvn-0.9.6-1.fc9 ['449500 NEW'] (build/make) timj R-Matrix-0.999375-4.fc9 ['449530 NEW'] (build/make) tmoertel scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip svnmailer-1.0.8-3.fc7 ['449666 ASSIGNED'] (build/make) mfleming yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa zhcon-0.2.6-8.fc9 ['449625 NEW'] (build/make) dchen ---------------------------------- Packages by owner: abompard: HelixPlayer,librra adalloz: pam_abl,pan addutko: astyle agk: dmraid akahl: bmpx,libzzub alexlan: blam allisson: perl-Crypt-Simple ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mysql-gui-tools,oooqs2,sugar-journal awjb: aterm,claws-mail,gimmix,koffice-langpack,libopensync,librra,pywbxml,scribus bagnara: ppl berrange: perl-Test-AutoBuild bjensen: linpsk bmr: dmraid bojan: apr-api-docs,libapreq2,subversion-api-docs bos: gtk2hs bpepple: brutus-keyring,swfdec-gnome cchance: stardict chabotc: buoh chitlesh: ktechlab colding: brutus-keyring cr33dog: fontypython cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-Gnome2-GConf,perl-MooseX-Object-Pluggable,perl-Net-CUPS,perl-RRD-Simple davidz: libgnomecups dbhole: jgroups dcbw: plague dchen: zhcon dgregor: perl-Class-MethodMaker dionysos: gpsim dwalsh: setools dwmw2: callweaver,linux-atm,petitboot dwysocha: dmraid edhill: itpp,nco ensc: mimetic errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fitzsim: java-1.6.0-openjdk fnasser: mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython frankb: qtiplot gemi: erlang,gcl,genius,mosml,qcad,smarteiffel gilboa: kdebluetooth green: ardour,gcl guthrie: dxpc hguemar: plotmm homeless: rudeconfig iburrell: perl-SVN-Mirror icon: gazpacho ifoox: ht2html ixs: bacula,bitbake,mod_suphp,pyzor jafo: moto4lin,python-memcached,python-pydns,python-pyspf jima: graphviz jkeating: contacts jmagne: coolkey jnovy: compat-db,db4 jorton: httpd,libidn,mod_python jwboyer: petitboot jwrdegoede: ardour,qmmp kaboom: qgo kasal: brltty kg6fnk: pdsh kkofler: kdevelop,qt4-theme-quarticurve kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra,perl-Event-Lib langel: java-1.6.0-openjdk laxathom: ntfs-config leo: pcmanx-gtk2 lkundrak: inkscape,inkscape,java-1.6.0-openjdk lmacken: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot ltinkl: kdevelop luya: gdesklets lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbroz: dmraid mclasen: glade2 meme: nethack-vultures mfleming: svnmailer mgarski: xscorch misa: mx mjw: java-1.6.0-openjdk mmcgrath: bacula,perl-MIME-Lite mornfall: dmraid mpeters: pan mschwendt: audacious-plugin-fc mtasaka: astyle,libzzub mwiriadi: mediatomb nalin: gnupg2 nando: qsynth navid: sos ngompa: oggconvert nigelj: podsleuth nomis80: camstream oliver: eclipse,fish orion: kdesvn,plplot,vtk orphan: gnome-applet-tvn24 overholt: eclipse,eclipse owentl: gdesklets pebenito: setools perl-sig: perl-Catalyst-Plugin-ConfigLoader,perl-Class-MethodMaker,perl-DateTime-Format-Strptime,perl-Event-Lib,perl-Gnome2-GConf,perl-MIME-Lite,perl-MooseX-Object-Pluggable,perl-Net-CUPS,perl-RRD-Simple,perl-SVN-Mirror,perl-XML-LibXSLT pertusus: bes,dap-freeform_handler,dap-hdf4_handler,elektra,libdap,libnc-dap,nco petersen: gtk2hs,libtomoe-gtk,scim-tomoe pfj: gtk-sharp,monodevelop pfrields: drivel pknirsch: freeipmi pwouters: lrmi qspencer: atlas,lilypond rathann: ekg2,freefem++,openbabel,tachyon ravenoak: pysvn rbrich: amanda rcritten: ipa rdieter: glib,gnupg2,gpgme,gtk+,k3b,kdevelop,kickpim,libsigsegv,ntl,qscintilla rishi: anjuta robmv: eclipse-subclipse roozbeh: fonttools rrakus: k3b rrelyea: coolkey rvinyard: conexusmm ryo: libtomoe-gtk,scim-skk,scim-tomoe s4504kr: subcommander sconklin: linpsk scop: dvdauthor,kdebluetooth,xemacs shahms: python-durus,python-simpletal,python-tpg shishz: perl-XML-LibXSLT simo: ipa sindrepb: blam,linpsk,muine,muine-scrobbler,perl-Net-Packet,perl-Net-Write splinux: gdmap,gstm,libgtksourceviewmm,lostirc,lostirc spot: R-RScaLAPACK,blacs,scalapack,xsupplicant steve: gl-117,perl-DateTime-Format-Strptime,supertux subhodip: straw tbzatek: tuxcmd than: kdevelop thias: djvulibre,lsdvd thomasvs: ladspa till: wyrd timj: rapidsvn timlau: bodhi tmoertel: R-Matrix tmraz: pam_abl toshio: bodhi,qa-assistant trasher: klear tuxbrewr: spicebird uwog: aiksaurus veillard: pwlib wart: crossfire xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd zhu: stardict -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From cra at WPI.EDU Mon Jul 7 21:35:57 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 7 Jul 2008 17:35:57 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48728BAB.3050109@blagblagblag.org> References: <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <48728008.2050705@blagblagblag.org> <48728BAB.3050109@blagblagblag.org> Message-ID: <20080707213557.GC32483@angus.ind.WPI.EDU> On Mon, Jul 07, 2008 at 06:33:31PM -0300, jeff wrote: > drago01 wrote: >>> And it really isn't a hidden >>> anaconda option, it's just having anaconda pass that to grub. Anaconda >>> already has some support for this, it just doesn't pass it to grub. It may >>> be a simple one-liner in anaconda. >> Well the options get passed to the kernel not to anaconda, it just >> parses (abuses) the kernel cmdline for stuff like this. (which isn't a >> bad thing in general) > > I agree. And anaconda could just take one more step and add it to grub.conf > ala anaconda.id.bootloader.args.append. Voila, done. I don't think it is > doing this already, but I may be mistaken. You could always Ctrl-Alt-F2 and edit /mnt/sysimage/etc/selinux/config or /mnt/sysimage/boot/grub/grub.conf after the install is complete but before the system reboots. From kevin.kofler at chello.at Mon Jul 7 21:45:18 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 21:45:18 +0000 (UTC) Subject: FESCo Meeting Summary for 2008-07-03 References: <1215462872.5070.5.camel@kennedy> Message-ID: Brian Pepple fedoraproject.org> writes: >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections Ugh, developers _already_ struggle with filling in all the sections, which sometimes simply don't apply to the feature, how is even more bureaucracy going to help? Let me take a past feature as an example (for lack of ability to predict the future): try writing a complete detailed test plan for FeatureKDE4... And no, you don't have 3 years to write it and I don't think the wiki will scale to megabytes of text in a single feature page. ;-) And in addition to sections just not relevant to the specific feature, there's also the issue of developer time being wasted on bureaucracy, time which not all developers have: the FeatureKDE4 page ended up as complete as it now is because we spent lots of time on it, some feature pages are in a much worse state, and I don't think pressure like the above "process improvements" is going to help, because this isn't laziness, it's genuine lack of time. Kevin Kofler From blc at redhat.com Mon Jul 7 21:53:14 2008 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 07 Jul 2008 15:53:14 -0600 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707094704.GA5497@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> Message-ID: <4872904A.9050600@redhat.com> Richard W.M. Jones wrote: > I would like to propose a new SIG for Fedora: > > https://fedoraproject.org/wiki/SIGs/MinGW > > The mission is to provide a MinGW-based cross-compiler and some common > libraries so that Fedora users will be able to cross-compile software > targeting Windows. The aim will be that, just using a Fedora host and > completely free software, you will be able to produce Windows *.DLLs > and *.EXEs. Hi Rich, Any particular reason to go with MinGW rather than Cygwin? Is there room for both in the SIG? -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From bojan at rexursive.com Mon Jul 7 22:10:42 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 08 Jul 2008 08:10:42 +1000 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 In-Reply-To: <20080707163443.A8909@humbolt.us.dell.com> References: <20080707163443.A8909@humbolt.us.dell.com> Message-ID: <1215468642.2819.8.camel@shrek.rexursive.com> On Mon, 2008-07-07 at 16:34 -0500, Matt Domsch wrote: > bojan: apr-api-docs,libapreq2,subversion-api-docs Looking into libapreq2. The other two were already fixed. -- Bojan From berrange at redhat.com Mon Jul 7 22:14:53 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 7 Jul 2008 23:14:53 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <4872904A.9050600@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> Message-ID: <20080707221453.GD15537@redhat.com> On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > Richard W.M. Jones wrote: > >I would like to propose a new SIG for Fedora: > > > > https://fedoraproject.org/wiki/SIGs/MinGW > > > >The mission is to provide a MinGW-based cross-compiler and some common > >libraries so that Fedora users will be able to cross-compile software > >targeting Windows. The aim will be that, just using a Fedora host and > >completely free software, you will be able to produce Windows *.DLLs > >and *.EXEs. > > Any particular reason to go with MinGW rather than Cygwin? Is there > room for both in the SIG? For libvirt the show stopper is licensing. CYGWIN1.DLL is intentionally under the GPL and all Cygwin programs must link to it. libvirt is under the LGPL because we want to enable the widest possible use by open and closed source programs. Having the library GPL-only on Windows isn't desirable. 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 moe at blagblagblag.org Mon Jul 7 22:18:22 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 07 Jul 2008 19:18:22 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <48728BAB.3050109@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <48728008.2050705@blagblagblag.org> <48728BAB.3050109@blagblagblag.org> Message-ID: <4872962E.50101@blagblagblag.org> jeff wrote: > drago01 wrote: >>> And it really isn't a hidden >>> anaconda option, it's just having anaconda pass that to grub. Anaconda >>> already has some support for this, it just doesn't pass it to grub. >>> It may >>> be a simple one-liner in anaconda. >> Well the options get passed to the kernel not to anaconda, it just >> parses (abuses) the kernel cmdline for stuff like this. (which isn't a >> bad thing in general) > > I agree. And anaconda could just take one more step and add it to > grub.conf ala anaconda.id.bootloader.args.append. Voila, done. I don't > think it is doing this already, but I may be mistaken. I just tested this on a stock F9 install: if you do selinux=0 at the boot: line (the kernel cmdline) it doesn't get passed to the final installed grub.conf. -Jeff From bojan at rexursive.com Mon Jul 7 22:31:05 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 08 Jul 2008 08:31:05 +1000 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 In-Reply-To: <1215468642.2819.8.camel@shrek.rexursive.com> References: <20080707163443.A8909@humbolt.us.dell.com> <1215468642.2819.8.camel@shrek.rexursive.com> Message-ID: <1215469865.2819.13.camel@shrek.rexursive.com> On Tue, 2008-07-08 at 08:10 +1000, Bojan Smojver wrote: > Looking into libapreq2. OK, fixed too. If anyone has broken packages related to apr-util going 1.3.x, it may be due to what apu-1-config --libs returns, which contains LDAP libraries by default. Try using apu-1-config --avoid-ldap --libs instead (order of options is important). -- Bojan From hughsient at gmail.com Mon Jul 7 22:29:05 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 07 Jul 2008 23:29:05 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215453125.3206.114.camel@pc-notebook> References: <1215450510.7472.11.camel@hughsie-work> <1215453125.3206.114.camel@pc-notebook> Message-ID: <1215469745.7472.14.camel@hughsie-work> On Mon, 2008-07-07 at 19:52 +0200, Martin Sourada wrote: > * It always asks for authentication and there is no option to remember > the authentication when it discovers thath the package is not signed. Is > it intentional? Yup, there's a security hole (potentially) if we allow the auth to be retained for unsigned files. > * The window with update progress closes itself after I give the needed > permissions to install and as a result I am not notified of the update > result. I can reopen the window via the notify icon though... How did you launch the update? Using the icon or using the Update software tool? > Yum seems to be OK with failing scriplets (i.e. finishes the > update/install/remove of other packages and marks the installation as > success), so this might not be PackageKit fault. Hmm. If you can reproduce, could you run "pkcon update" in the console please, and post the output. Thanks, Richard. From hughsient at gmail.com Mon Jul 7 22:30:19 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 07 Jul 2008 23:30:19 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <20080707172731.GG16400@redhat.com> References: <1215450510.7472.11.camel@hughsie-work> <20080707172731.GG16400@redhat.com> Message-ID: <1215469819.7472.16.camel@hughsie-work> On Mon, 2008-07-07 at 18:27 +0100, Daniel P. Berrange wrote: > So if you want to push this to F9 you'll need to make sure that the > new PackageKit-libs RPM, has a Conflicts: gnome-packagekit < 0.2.3-3.fc9 > or re-spin the upstream release to increment the .soname version Ooops, thanks for catching this. I'll respin a 0.2.4 release upstream to address this. Thanks. Richard. From hughsient at gmail.com Mon Jul 7 22:30:50 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 07 Jul 2008 23:30:50 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1dedbbfc0807071019gccf0877p8a41a47b04473fff@mail.gmail.com> References: <1215450510.7472.11.camel@hughsie-work> <1dedbbfc0807071019gccf0877p8a41a47b04473fff@mail.gmail.com> Message-ID: <1215469850.7472.18.camel@hughsie-work> On Mon, 2008-07-07 at 19:19 +0200, David Nielsen wrote: > I've been running these for a while now and I see no stability or > performance problems. So far they have survived installing/removing > software and performing several system updates without issue. > Excellent work Thanks, cheers for the positive response. Richard. From kevin.kofler at chello.at Mon Jul 7 22:33:52 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 22:33:52 +0000 (UTC) Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 References: <20080707163443.A8909@humbolt.us.dell.com> <1215468642.2819.8.camel@shrek.rexursive.com> <1215469865.2819.13.camel@shrek.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > If anyone has broken packages related to apr-util going 1.3.x, it may be > due to what apu-1-config --libs returns, which contains LDAP libraries > by default. Try using apu-1-config --avoid-ldap --libs instead (order of > options is important). I ran into the same thing with KDevelop (it builds a kioslave for svn), I just added a BR openldap-devel. IMHO apr-devel should Require openldap-devel. Kevin Kofler From hughsient at gmail.com Mon Jul 7 22:32:50 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 07 Jul 2008 23:32:50 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: References: <1215450510.7472.11.camel@hughsie-work> Message-ID: <1215469970.7472.22.camel@hughsie-work> On Mon, 2008-07-07 at 19:18 +0200, drago01 wrote: > On Mon, Jul 7, 2008 at 7:08 PM, Richard Hughes wrote: > > I've built ?new builds of PackageKit ?and gnome-packagekit and moved > > them into updates-testing. The new major version is hopefully much > > better from a UI perspective and hopefully much more stable but is an > > API break from 0.1.x. > > > > The builds for F9 are here: > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 > > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 > > I have been testing them since I saw them in koji. > 1) Seems to be better than 0.1.x branch UI wise > > Some things that needs to be improved: > 1) The "getting information" applet shouldn't show up unless there are > updates or work being done, but the "getting information" after login > / connecting to a network is pointless. Sometimes it takes a while to get the update list if we have to download new files - do you get the applet icon otherwise? > 2) I tryed to delete multple package at once but after pressing the > apply button it started to resolve deps in the background without > showing any feedback to the user for ~30 sec > (the user might think it did nothing and keep clicking on the apply button), Valid. Could you file a bug in RH bugzilla please (so I remember), and I'll sort it in 0.2.4 after I get back from GUADEC. > 3) The rpm post script is noisy (some media stuff can't remember) Right, I'll take a look at that too. Thanks for the help, Richard. From jspaleta at gmail.com Mon Jul 7 22:39:44 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 7 Jul 2008 14:39:44 -0800 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707094704.GA5497@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> Message-ID: <604aa7910807071539w85eb620ved17e3712a28be29@mail.gmail.com> On Mon, Jul 7, 2008 at 1:47 AM, Richard W.M. Jones wrote: > The three initial contributors, myself, Dan Berrange and Daniel > Veillard, are primarily interested in providing a libvirt client > library and some libvirt-based tools for Windows users (so that they > will be able to manage Linux systems running libvirtd remotely). > However we think that a cross-compiler could have much wider interest > in the Fedora community. Which of our contributors had developed the liveusb creator tool for windows? I'm sure they'd be interested in making use of this toolchain, maybe helping with it. I think Lmacken is one of them. I was also talking to someone on irc about bringing a wubi-alike application to install and run Fedora as a windows application. I forget exactly who I was talking to..sorry... but the conversation did touch on needing the minGW cross-compiler to build the application. Once we have a viable cross compiler toolchain available as part of our project, have we thought about how we can expose it so we can build and host 'official' project tools meant to be used on windows? As the liveusb-creator experience has shown, there is a place for window executables in the project's binary offerings. As long as we can build them in an open build system, we shouldn't have any fundamental policy problems generating more tool of that nature.. but have we thought about how we would want to setup the build system and distribution of such executables? -jef From kevin.kofler at chello.at Mon Jul 7 22:37:39 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jul 2008 22:37:39 +0000 (UTC) Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 References: <20080707163443.A8909@humbolt.us.dell.com> Message-ID: Matt Domsch dell.com> writes: > kdevelop-3.5.2-2.fc10 (build/make) than,rdieter,kkofler,ltinkl Fixed. apr-devel has a -lldap in its config stuff, but is missing a dependency on openldap-devel, so I added that to kdevelop for now. > qt4-theme-quarticurve-0.0-0.11.beta7.fc9 (build/make) kkofler Fixed. This one is entirely my fault, the .pro file (which I wrote) tries to autodetect _kde4_appsdir and fails at it (because of a recent kdelibs bugfix), for now I'm explicitly setting it from the specfile. Kevin Kofler From rjones at redhat.com Mon Jul 7 22:43:21 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 23:43:21 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <4872904A.9050600@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> Message-ID: <20080707224321.GA8543@amd.home.annexia.org> On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > Any particular reason to go with MinGW rather than Cygwin? Is there > room for both in the SIG? Cygwin has a licensing issue -- namely that it is GPL and so prevents any proprietary development on top of our libraries. This isn't necessarily a problem for the 'MinGW' SIG, but it is a bit of a problem for libvirt. 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 rjones at redhat.com Mon Jul 7 22:46:37 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 23:46:37 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <604aa7910807071539w85eb620ved17e3712a28be29@mail.gmail.com> References: <20080707094704.GA5497@amd.home.annexia.org> <604aa7910807071539w85eb620ved17e3712a28be29@mail.gmail.com> Message-ID: <20080707224637.GB8543@amd.home.annexia.org> On Mon, Jul 07, 2008 at 02:39:44PM -0800, Jeff Spaleta wrote: > Once we have a viable cross compiler toolchain available as part of > our project, have we thought about how we can expose it so we can > build and host 'official' project tools meant to be used on windows? Please do jump in and try out the tools I've been building. I don't know if they can be used for anything beyond simple POSIX libraries (which is my main focus so far) but I guess you can try. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From martin.sourada at gmail.com Mon Jul 7 22:51:00 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 08 Jul 2008 00:51:00 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215469745.7472.14.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> <1215453125.3206.114.camel@pc-notebook> <1215469745.7472.14.camel@hughsie-work> Message-ID: <1215471060.3206.142.camel@pc-notebook> On Mon, 2008-07-07 at 23:29 +0100, Richard Hughes wrote: > On Mon, 2008-07-07 at 19:52 +0200, Martin Sourada wrote: > > * It always asks for authentication and there is no option to remember > > the authentication when it discovers thath the package is not signed. Is > > it intentional? > > Yup, there's a security hole (potentially) if we allow the auth to be > retained for unsigned files. > Thanks for clarifying. > > * The window with update progress closes itself after I give the needed > > permissions to install and as a result I am not notified of the update > > result. I can reopen the window via the notify icon though... > > How did you launch the update? Using the icon or using the Update > software tool? > As I said, it's about local rpms, which means I launched it by double-clicking on the rpm. Normal updates (launched either by the Update software or from notify) does not suffer that issue. IIRC the same happens for installing (i.e. when the some other version of the package is not installed yet) local packages via the Package Installer tool. The window closes right after the authenticating is done. > Hmm. If you can reproduce, could you run "pkcon update" in the console > please, and post the output. > That would probably require me to find the broken package (if it's still in koji), downgrade to some previous version, disable the updates and updates-testing repo, create local repo, enable it, put that package into it and try the update. Hehe, a lot of work, I'll see what I can do (tomorrow) :) > Thanks, > > Richard. Martin -------------- 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 drago01 at gmail.com Mon Jul 7 22:57:49 2008 From: drago01 at gmail.com (drago01) Date: Tue, 8 Jul 2008 00:57:49 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215469970.7472.22.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> <1215469970.7472.22.camel@hughsie-work> Message-ID: On Tue, Jul 8, 2008 at 12:32 AM, Richard Hughes wrote: > On Mon, 2008-07-07 at 19:18 +0200, drago01 wrote: >> On Mon, Jul 7, 2008 at 7:08 PM, Richard Hughes wrote: >> > I've built ?new builds of PackageKit ?and gnome-packagekit and moved >> > them into updates-testing. The new major version is hopefully much >> > better from a UI perspective and hopefully much more stable but is an >> > API break from 0.1.x. >> > >> > The builds for F9 are here: >> > >> > http://koji.fedoraproject.org/koji/buildinfo?buildID=54830 >> > http://koji.fedoraproject.org/koji/buildinfo?buildID=54886 >> >> I have been testing them since I saw them in koji. >> 1) Seems to be better than 0.1.x branch UI wise >> >> Some things that needs to be improved: >> 1) The "getting information" applet shouldn't show up unless there are >> updates or work being done, but the "getting information" after login >> / connecting to a network is pointless. > > Sometimes it takes a while to get the update list if we have to download > new files - do you get the applet icon otherwise? Yeah but for the periodic update check why should the user care? pupplet wasn't displaying the I am "doing something" notification but only "there are updates". So I suggest only showing it when the user manually request for it to check for updates but not after login / connection to the network while performing the automatic check. >> 2) I tryed to delete multple package at once but after pressing the >> apply button it started to resolve deps in the background without >> showing any feedback to the user for ~30 sec >> (the user might think it did nothing and keep clicking on the apply button), > > Valid. Could you file a bug in RH bugzilla please (so I remember), and > I'll sort it in 0.2.4 after I get back from GUADEC. Sure, will do later today (its 0:56 am now ;) ) >> 3) The rpm post script is noisy (some media stuff can't remember) > > Right, I'll take a look at that too. OK, thanks. > Thanks for the help, np. From rjones at redhat.com Mon Jul 7 22:55:14 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Jul 2008 23:55:14 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707211554.GA8320@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> Message-ID: <20080707225514.GC8543@amd.home.annexia.org> I've got as far as building GnuTLS + dependent libraries. As before, you can try out the work from the fedora-mingw repository: hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel 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 mschwendt at gmail.com Mon Jul 7 23:18:30 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 8 Jul 2008 01:18:30 +0200 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 In-Reply-To: <20080707163443.A8909@humbolt.us.dell.com> References: <20080707163443.A8909@humbolt.us.dell.com> Message-ID: <20080708011830.7ea73c73.mschwendt@gmail.com> On Mon, 7 Jul 2008 16:34:43 -0500, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > Based on the tree as of Thu Jul 3 2008. > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > audacious-plugin-fc-0.2-6 (build/make) mschwendt There's some external breakage somewhere. In libSAD, whatever that is. It is not a direct dependency of audacious-plugin-fc. libSAD ought not (better MUST NOT) include a header with the name "config.h" in a public API: g++ -DHAVE_CONFIG_H -I. -I. -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/libmowgli -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/freetype2 -MT Main.lo -MD -MP -MF .deps/Main.Tpo -c Main.cpp -fPIC -DPIC -o .libs/Main.o In file included from /usr/include/libSAD/libSAD.h:23 , from /usr/include/audacious/util.h:41 , from configure.c:2 : /usr/include/libSAD/common.h:38:21: error: config.h: No such file or directory From bojan at rexursive.com Mon Jul 7 23:23:38 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 7 Jul 2008 23:23:38 +0000 (UTC) Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 References: <20080707163443.A8909@humbolt.us.dell.com> <1215468642.2819.8.camel@shrek.rexursive.com> <1215469865.2819.13.camel@shrek.rexursive.com> Message-ID: Kevin Kofler chello.at> writes: > I ran into the same thing with KDevelop (it builds a kioslave for svn), I just > added a BR openldap-devel. IMHO apr-devel should Require openldap-devel. New apr-util should not require openldap-devel, as long as you are not using LDAP APIs directly. LDAP libraries are returned by apu-1-config --libs to obey by project's versioning rules (as noted by Joe Orton). However, the new option --avoid-ldap should be used (before --libs) in order to get actually required libraries for the builds that load LDAP support on request (i.e. as DSO). See: http://svn.apache.org/viewvc?view=rev&revision=659666 -- Bojan From mclasen at redhat.com Mon Jul 7 23:27:47 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 07 Jul 2008 19:27:47 -0400 Subject: FESCo Meeting Summary for 2008-07-03 In-Reply-To: References: <1215462872.5070.5.camel@kennedy> Message-ID: <1215473267.3293.2.camel@localhost.localdomain> On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote: > Brian Pepple fedoraproject.org> writes: > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections > > Ugh, developers _already_ struggle with filling in all the sections, which > sometimes simply don't apply to the feature, how is even more bureaucracy going > to help? Let me take a past feature as an example (for lack of ability to > predict the future): try writing a complete detailed test plan for > FeatureKDE4... And no, you don't have 3 years to write it and I don't think the > wiki will scale to megabytes of text in a single feature page. ;-) And in > addition to sections just not relevant to the specific feature, there's also > the issue of developer time being wasted on bureaucracy, time which not all > developers have: the FeatureKDE4 page ended up as complete as it now is because > we spent lots of time on it, some feature pages are in a much worse state, and > I don't think pressure like the above "process improvements" is going to help, > because this isn't laziness, it's genuine lack of time. Think about it this way: it means that there will be no features ready for approval when the time comes. So as a side-effect it achieves the "Reduce FESco overhead" goal... From hughsient at gmail.com Mon Jul 7 23:26:32 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 Jul 2008 00:26:32 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: References: <1215450510.7472.11.camel@hughsie-work> <1215469970.7472.22.camel@hughsie-work> Message-ID: <1215473192.7472.27.camel@hughsie-work> On Tue, 2008-07-08 at 00:57 +0200, drago01 wrote: > Yeah but for the periodic update check why should the user care? > pupplet wasn't displaying the I am "doing something" notification but > only "there are updates". > So I suggest only showing it when the user manually request for it to > check for updates but not after login / connection to the network > while performing the automatic check. Sure, it appears so you know it's doing something... for me the hard drive light goes on and the CPU goes up to 100% for a few seconds, and it's nice to know what's going on. Maybe this is insane. Comments welcome. > >> 2) I tryed to delete multple package at once but after pressing the > >> apply button it started to resolve deps in the background without > >> showing any feedback to the user for ~30 sec > >> (the user might think it did nothing and keep clicking on the apply button), > > > > Valid. Could you file a bug in RH bugzilla please (so I remember), and > > I'll sort it in 0.2.4 after I get back from GUADEC. > > Sure, will do later today (its 0:56 am now ;) ) 2:28am -- I win! :-) Richard From hughsient at gmail.com Mon Jul 7 23:28:13 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 Jul 2008 00:28:13 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215471060.3206.142.camel@pc-notebook> References: <1215450510.7472.11.camel@hughsie-work> <1215453125.3206.114.camel@pc-notebook> <1215469745.7472.14.camel@hughsie-work> <1215471060.3206.142.camel@pc-notebook> Message-ID: <1215473293.7472.30.camel@hughsie-work> On Tue, 2008-07-08 at 00:51 +0200, Martin Sourada wrote: > As I said, it's about local rpms, which means I launched it by > double-clicking on the rpm. Normal updates (launched either by the > Update software or from notify) does not suffer that issue. IIRC the > same happens for installing (i.e. when the some other version of the > package is not installed yet) local packages via the Package Installer > tool. The window closes right after the authenticating is done. I've not tested that -- could you open a bug in RH bugzilla please, and I'll check it out tomorrow. I think we're just setting the wrong interactivity flags on these helper tools. Richard. From hughsient at gmail.com Mon Jul 7 23:41:00 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 Jul 2008 00:41:00 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215471060.3206.142.camel@pc-notebook> References: <1215450510.7472.11.camel@hughsie-work> <1215453125.3206.114.camel@pc-notebook> <1215469745.7472.14.camel@hughsie-work> <1215471060.3206.142.camel@pc-notebook> Message-ID: <1215474060.7472.33.camel@hughsie-work> On Tue, 2008-07-08 at 00:51 +0200, Martin Sourada wrote: > The window closes right after the authenticating is done. Yup, I've found the problem. The default interaction mode of a GpkClient is GPK_CLIENT_INTERACT_NEVER, and we don't change this on the gpk-install-foo helpers. I've added a call of: gpk_client_set_interaction (gclient, GPK_CLIENT_INTERACT_ALWAYS); to the gpk-install-foo.c files and now it seems to do the right thing for me. I've committed to master, and will pull into the 0.2.x branch. Thanks for catching this one. Richard. From jwboyer at gmail.com Tue Jul 8 01:35:51 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 07 Jul 2008 21:35:51 -0400 Subject: FESCo Meeting Summary for 2008-07-03 In-Reply-To: <1215473267.3293.2.camel@localhost.localdomain> References: <1215462872.5070.5.camel@kennedy> <1215473267.3293.2.camel@localhost.localdomain> Message-ID: <1215480951.20774.68.camel@weaponx> On Mon, 2008-07-07 at 19:27 -0400, Matthias Clasen wrote: > On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote: > > Brian Pepple fedoraproject.org> writes: > > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans > > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections > > > > Ugh, developers _already_ struggle with filling in all the sections, which > > sometimes simply don't apply to the feature, how is even more bureaucracy going > > to help? Let me take a past feature as an example (for lack of ability to > > predict the future): try writing a complete detailed test plan for > > FeatureKDE4... And no, you don't have 3 years to write it and I don't think the > > wiki will scale to megabytes of text in a single feature page. ;-) And in > > addition to sections just not relevant to the specific feature, there's also > > the issue of developer time being wasted on bureaucracy, time which not all > > developers have: the FeatureKDE4 page ended up as complete as it now is because > > we spent lots of time on it, some feature pages are in a much worse state, and > > I don't think pressure like the above "process improvements" is going to help, > > because this isn't laziness, it's genuine lack of time. > > Think about it this way: it means that there will be no features ready > for approval when the time comes. So as a side-effect it achieves the > "Reduce FESco overhead" goal... While I realize you were making a sarcastic remark, I would like to point out that we (FESCo) didn't even discuss that "goal" during the meeting. John added that right before the meeting trying to be nice to us and we didn't even think it worth discussing because of other points brought up by the other goals and the fact that Features are decided FESCo's _job_. josh From jwboyer at gmail.com Tue Jul 8 01:42:16 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 07 Jul 2008 21:42:16 -0400 Subject: FESCo Meeting Summary for 2008-07-03 In-Reply-To: References: <1215462872.5070.5.camel@kennedy> Message-ID: <1215481336.20774.76.camel@weaponx> On Mon, 2008-07-07 at 21:45 +0000, Kevin Kofler wrote: > Brian Pepple fedoraproject.org> writes: > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans > >http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections > > Ugh, developers _already_ struggle with filling in all the sections, which > sometimes simply don't apply to the feature, how is even more bureaucracy going > to help? Let me take a past feature as an example (for lack of ability to It will help FESCo decide if the Feature is a) worthwhile, b) even testable at all, and c) provide us with some kind of QA plan so we aren't touting a Feature that is totally broken. > predict the future): try writing a complete detailed test plan for > FeatureKDE4... And no, you don't have 3 years to write it and I don't think the > wiki will scale to megabytes of text in a single feature page. ;-) And in We aren't asking you to document the testcase in it's entirety, and obviously some Features will be able to more clearly state their test plans than others. > addition to sections just not relevant to the specific feature, there's also > the issue of developer time being wasted on bureaucracy, time which not all > developers have: the FeatureKDE4 page ended up as complete as it now is because > we spent lots of time on it, some feature pages are in a much worse state, and > I don't think pressure like the above "process improvements" is going to help, > because this isn't laziness, it's genuine lack of time. KDE4 was (and still is) an exception to most of the Features we see due to it's broad scope and large complexity. The fact that you documented your Feature page as well as you did is a testament to you and your SIG's dedication to see the Feature thrive in Fedora. If the some of the other Feature owners did even 1/2 that, it would be an improvement. Look at it this way, FESCo doesn't like to add overhead just for fun. We really hate it to be honest. However, we aren't the developers of these Features, and we have to have some way of understanding the impacts of it, why it should be a Feature, and how we (the Fedora project) are going to ensure it's not totally broken. If you have better suggestions on how to do that, then please suggest them! This is the best proposal we've seen to date and it contains the information in a single place. (And no, hounding people on IRC or via private/public email isn't really an option.) josh From roopesh.majeti at gmail.com Tue Jul 8 02:01:24 2008 From: roopesh.majeti at gmail.com (roopesh majeti) Date: Tue, 8 Jul 2008 07:31:24 +0530 Subject: IRC support meeting - 2008-07-10 at 18:00 UTC In-Reply-To: <20080707130556.5e803959@ohm.scrye.com> References: <20080707130556.5e803959@ohm.scrye.com> Message-ID: <599059470807071901na90e4a9m917bbcc98eef7301@mail.gmail.com> Hi Kevin, Sorry to spam and ask. I am new to Fedora and very much intertested to contribute. I would like to attend the meeting. But just would like to know, if the meetings can be sheduled at a little bit early time, as meeting the time in my time-zone is around midnight [ 23:30 ]. Thanks Roopesh. On 7/8/08, Kevin Fenzi wrote: > > We would like to have another meeting of folks interested in #fedora > and IRC support this thursday at 18:00 UTC (right after the FESCo > meeting). > > Topics: > > - Code of conduct for IRC support channels. > - Scheduling timeperiods for helpers > - Recruiting more helpers. > - Decide if we should be a SIG or not. > - Any other topics folks would like to discuss... > > All interested parties are welcome to join us! > > kevin > > > > -- > 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 greno at verizon.net Tue Jul 8 02:57:06 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 07 Jul 2008 22:57:06 -0400 Subject: mobile broadband support Message-ID: <4872D782.3000002@verizon.net> I have a Novatel Wireless S720 mobile broadband card. It's working, but does anyone know how to get a signal strength displayed for it? I'm flying blind with it. I can't tune my external antenna except by gauging the relative speed of downloads between one antenna position and another. Rather primitive. I've been googling this but haven't found anything yet. Thanks, Gerry From poelstra at redhat.com Tue Jul 1 20:46:27 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 01 Jul 2008 13:46:27 -0700 Subject: Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008 Message-ID: <486A97A3.6090506@redhat.com> I'm sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Fedora uses this instance of bugilla too. Please forward this on to people or groups I missed. Thank you, John ------------------------------- Greetings, The Red Hat Bugzilla team is happy to announce that the release of the next version of Red Hat Bugzilla will occur on July 26th, 2008. The next version will be based on the upcoming upstream 3.2 code base soon to be released. For previewing the next release please go to: https://partner-bugzilla.redhat.com We encourage everyone to please go to the above site and provide any final testing and feedback where possible. Please verify that the features you have come to reply on day to day in our current Bugzilla are still available and working properly. Please use the new UI and make sure that you can accomplish the same tasks. Do not worry about making changes, this is a test snapshot and is not live data. Also emails will not be sent for changes so do what you like. Also please make sure your stored queries/reports/whines still work and display as expected. Some notable changes since 2.18: Ajax optimizations on searching and displaying bug Improved needinfo actor support Changed guided bug entry UI enhancements XMLRPC API: New API plus compatibility with old API. (please verify your scripts that use XMLRPC against the test system before the release date) There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 2.18 is possible in the new system. There are also numerous new features/fixes that are part of the upcoming 3.2 release provided by the upstream Bugzilla community. For more detailed information on what has changed since the last release, check out the Release Notes. We have done extensive work at laying out what we feel the requirements are to maintain feature parity with our current system as well as compiled a list of feature enhancements that people would like to see in the next release. Our goal is to deliver a working bugzilla with the bare essential requirements similar to what is currently being used in our current 2.18 system. After that we will begin work on enhancements as time and resources permit. To view the final release requirements list please refer to our Bugzilla 3 Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=406071. Please file any enhancement requests or bug reports in our current Bugzilla system at bugzilla.redhat.com. File them under the Bugzilla product and relevant component with the version 3.2. Also send questions to bugzilla-owner at redhat.com. With everyone's help we can make this a great release. Thanks The Red Hat Bugzilla Team _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From wtogami at redhat.com Mon Jul 7 21:06:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 17:06:26 -0400 Subject: Rawhide Orphanarium Purge: June 18th Message-ID: <48728552.3040706@redhat.com> Please review the following packages. This is roughly the list of current orphans in rawhide. If they are not claimed by June 18th then they may be removed from rawhide by the F10 Alpha freeze. libical python-libgmail python-libgmail-docs pygtkglext system-summary lipstik rafkill xdms xeuphoric skencil emerald connect-proxy gnome-applet-tvn24 aasaver kbiof osmo nautilus-share ruby-amazon PyOpenGL AGReader tripwire emerald-themes perl-Net-Telnet multitail gnome-ppp fuse-gmailfs libgringotts 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 kagesenshi.87 at gmail.com Tue Jul 8 03:38:18 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Tue, 8 Jul 2008 11:38:18 +0800 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: On Tue, Jul 8, 2008 at 5:06 AM, Warren Togami wrote: > Please review the following packages. This is roughly the list of current > orphans in rawhide. If they are not claimed by June 18th then they may be > removed from rawhide by the F10 Alpha freeze. [snip] did u mean July 18 ? i'll take connect-proxy -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From wtogami at redhat.com Tue Jul 8 03:39:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Jul 2008 23:39:21 -0400 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: References: <48728552.3040706@redhat.com> Message-ID: <4872E169.8090605@redhat.com> Izhar Firdaus wrote: > On Tue, Jul 8, 2008 at 5:06 AM, Warren Togami wrote: >> Please review the following packages. This is roughly the list of current >> orphans in rawhide. If they are not claimed by June 18th then they may be >> removed from rawhide by the F10 Alpha freeze. > [snip] > > > did u mean July 18 ? > > i'll take connect-proxy > Doh, yes July 18th. I was in a rush when I sent that. Warren From fdinitto at redhat.com Tue Jul 8 03:53:51 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Tue, 08 Jul 2008 05:53:51 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <1215489231.3210.14.camel@daitarn-fedora.int.fabbione.net> On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: > Please review the following packages. This is roughly the list of > current orphans in rawhide. If they are not claimed by June 18th then > they may be removed from rawhide by the F10 Alpha freeze. > multitail I will take this one since i use it on a daily base. Thanks Fabio From ivazqueznet at gmail.com Tue Jul 8 03:49:52 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 07 Jul 2008 23:49:52 -0400 Subject: IRC support meeting - 2008-07-10 at 18:00 UTC In-Reply-To: <20080707130556.5e803959@ohm.scrye.com> References: <20080707130556.5e803959@ohm.scrye.com> Message-ID: <1215488992.20804.15.camel@ignacio.lan> On Mon, 2008-07-07 at 13:05 -0600, Kevin Fenzi wrote: > We would like to have another meeting of folks interested in #fedora > and IRC support this thursday at 18:00 UTC (right after the FESCo > meeting). Unfortunately I will probably not be able to attend this meeting. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 8 04:02:33 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 08 Jul 2008 13:02:33 +0900 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <4872E6D9.1000703@ioa.s.u-tokyo.ac.jp> Warren Togami wrote, at 07/08/2008 06:06 AM +9:00: > ruby-amazon I maintained this, which is completely obsoletes by ruby-aws (due to Amazon side change), so this can be removed any time. By the way, I already put dead.package on CVS and released the ownership of ruby-amazon on Apr 2008, so I expected that this package was already removed from rawhide tree. Would you tell me if I missed anything? Mamoru From peter at thecodergeek.com Tue Jul 8 04:11:48 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 07 Jul 2008 21:11:48 -0700 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <4872E6D9.1000703@ioa.s.u-tokyo.ac.jp> References: <48728552.3040706@redhat.com> <4872E6D9.1000703@ioa.s.u-tokyo.ac.jp> Message-ID: <1215490308.7060.0.camel@tuxhugs> On Tue, 2008-07-08 at 13:02 +0900, Mamoru Tasaka wrote: > By the way, I already put dead.package on CVS and released > the ownership of ruby-amazon on Apr 2008, so I expected that > this package was already removed from rawhide tree. > Would you tell me if I missed anything? You need to explicitly email releng at fedoraproject.org and ask them to remove it from the rawhide composes. (I hit this with a couple of my now-defunct packages too. XD) -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 8 04:12:34 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 08 Jul 2008 13:12:34 +0900 Subject: Please don't fill up package-review mailing list!! Message-ID: <4872E932.5050103@ioa.s.u-tokyo.ac.jp> Hello, all. What is happening now on fedora-packaging-review mailing list? The a mass trivial changes like product fixes seems to be proceeding and it is filling up fedora-packaging-review mailing list unneededly!! Actually I have already received more than 600 mails in a short time. Please don't do that!! Regards, Mamoru From peter at thecodergeek.com Tue Jul 8 04:26:45 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 07 Jul 2008 21:26:45 -0700 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <1215490308.7060.0.camel@tuxhugs> References: <48728552.3040706@redhat.com> <4872E6D9.1000703@ioa.s.u-tokyo.ac.jp> <1215490308.7060.0.camel@tuxhugs> Message-ID: <1215491205.7060.2.camel@tuxhugs> On Mon, 2008-07-07 at 21:11 -0700, Peter Gordon wrote: > You need to explicitly email releng at fedoraproject.org [...] Er, the correct address is with a hyphen: "rel-eng at fedoraproject.org". Apologies for any confusion/inconvenience this may have caused. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 debarshi.ray at gmail.com Tue Jul 8 04:37:42 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 8 Jul 2008 10:07:42 +0530 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <3170f42f0807072137mf4a6f42yad1eab4c2549741d@mail.gmail.com> > tripwire I found this file in the CVS for tripwire: http://cvs.fedoraproject.org/viewcvs/rpms/tripwire/devel/License-Issues?view=markup Is tripwire safe to be included in Fedora? Cheers, Debarshi From debarshi.ray at gmail.com Tue Jul 8 05:02:43 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 8 Jul 2008 10:32:43 +0530 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <3170f42f0807072202h1ba99b1ay3e83e2166b780916@mail.gmail.com> I took these three since they are all inter-related: > libical > osmo > libgringotts Happy hacking, Debarshi From dev at nigelj.com Tue Jul 8 05:15:13 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 08 Jul 2008 17:15:13 +1200 Subject: Please don't fill up package-review mailing list!! In-Reply-To: <4872E932.5050103@ioa.s.u-tokyo.ac.jp> References: <4872E932.5050103@ioa.s.u-tokyo.ac.jp> Message-ID: <4872F7E1.2000803@nigelj.com> Mamoru Tasaka wrote: > Hello, all. > > What is happening now on fedora-packaging-review mailing list? > The a mass trivial changes like product fixes seems to be proceeding > and it is filling up fedora-packaging-review mailing list > unneededly!! > > Actually I have already received more than 600 mails in a short time. > Please don't do that!! > I suspect this might be to do with the upcoming Bugzilla update (drop all old components), note that the account changing the bugs is infact bugzilla at rh.c although I must say, I thought they generally made it so these changes were only mailed out if a human made an actual change to the bug. 1912 BZ e-mails so far in a month is a bit crazy though I must admit. - Nigel From rc040203 at freenet.de Tue Jul 8 06:07:52 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Jul 2008 08:07:52 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707224321.GA8543@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> Message-ID: <1215497272.2809.209.camel@beck.corsepiu.local> On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote: > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > > Any particular reason to go with MinGW rather than Cygwin? Is there > > room for both in the SIG? > > Cygwin has a licensing issue -- namely that it is GPL and so prevents > any proprietary development on top of our libraries. How can a toolchain not supporting proprietary development be an issue to Fedora? It may-be sufficient reason for some users not use Cygwin, but this his hardly Fedora's problem. Ralf From mike at miketc.com Tue Jul 8 06:28:39 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 08 Jul 2008 01:28:39 -0500 Subject: Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008 In-Reply-To: <486A97A3.6090506@redhat.com> References: <486A97A3.6090506@redhat.com> Message-ID: <1215498519.14769.1.camel@scrappy.miketc.com> On Tue, 2008-07-01 at 13:46 -0700, John Poelstra wrote: Has anyone else received this email about 3-5 times now or more? Don't know if it's my problem or mailing list/server problem? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From pingou at pingoured.fr Tue Jul 8 06:30:21 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Tue, 08 Jul 2008 08:30:21 +0200 Subject: Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008 In-Reply-To: <1215498519.14769.1.camel@scrappy.miketc.com> References: <486A97A3.6090506@redhat.com> <1215498519.14769.1.camel@scrappy.miketc.com> Message-ID: <4873097D.6020608@pingoured.fr> Mike Chambers wrote: > On Tue, 2008-07-01 at 13:46 -0700, John Poelstra wrote: > > Has anyone else received this email about 3-5 times now or more? I did Regards, P.Yves From djuran at redhat.com Tue Jul 8 06:58:45 2008 From: djuran at redhat.com (David Juran) Date: Tue, 08 Jul 2008 09:58:45 +0300 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <1215500325.4584.26.camel@dhcppc2> On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: > Please review the following packages. This is roughly the list of > current orphans in rawhide. If they are not claimed by June 18th then > they may be removed from rawhide by the F10 Alpha freeze. > perl-Net-Telnet perl-Net-Telnet is required by several of the fencing agents included in the cman rpm. -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fdinitto at redhat.com Tue Jul 8 06:59:54 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Tue, 08 Jul 2008 08:59:54 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <1215500325.4584.26.camel@dhcppc2> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> Message-ID: <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> On Tue, 2008-07-08 at 09:58 +0300, David Juran wrote: > On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: > > Please review the following packages. This is roughly the list of > > current orphans in rawhide. If they are not claimed by June 18th then > > they may be removed from rawhide by the F10 Alpha freeze. > > > perl-Net-Telnet > > perl-Net-Telnet is required by several of the fencing agents included in > the cman rpm. > Oh I missed this one.. I will take it if nobody else wants it. Fabio From rjones at redhat.com Tue Jul 8 07:16:44 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 08:16:44 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <1215497272.2809.209.camel@beck.corsepiu.local> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> Message-ID: <20080708071644.GA15324@amd.home.annexia.org> On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote: > On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote: > > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > > > Any particular reason to go with MinGW rather than Cygwin? Is there > > > room for both in the SIG? > > > > Cygwin has a licensing issue -- namely that it is GPL and so prevents > > any proprietary development on top of our libraries. > How can a toolchain not supporting proprietary development be an issue > to Fedora? It may-be sufficient reason for some users not use Cygwin, > but this his hardly Fedora's problem. If you didn't selectively quote me, you'd see I said it's not a problem for the MinGW SIG (ie. Fedora), but it is a problem for the libvirt project. 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 walters at verbum.org Tue Jul 8 07:28:09 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 8 Jul 2008 03:28:09 -0400 Subject: mobile broadband support In-Reply-To: <4872D782.3000002@verizon.net> References: <4872D782.3000002@verizon.net> Message-ID: On Mon, Jul 7, 2008 at 10:57 PM, Gerry Reno wrote: > I have a Novatel Wireless S720 mobile broadband card. It's working, but > does anyone know how to get a signal strength displayed for it? I'm flying > blind with it. I can't tune my external antenna except by gauging the > relative speed of downloads between one antenna position and another. > Rather primitive. I've been googling this but haven't found anything yet. > This list is for development; your best bet for questions about the networking stack is: http://mail.gnome.org/archives/networkmanager-list/ (I believe the answer is that the signal strength requires card-specific logic which isn't documented, so this isn't easy to implement) -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Tue Jul 8 07:55:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 08:55:27 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <1215497272.2809.209.camel@beck.corsepiu.local> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> Message-ID: <20080708075527.GA24934@redhat.com> On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote: > On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote: > > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > > > Any particular reason to go with MinGW rather than Cygwin? Is there > > > room for both in the SIG? > > > > Cygwin has a licensing issue -- namely that it is GPL and so prevents > > any proprietary development on top of our libraries. > How can a toolchain not supporting proprietary development be an issue > to Fedora? It may-be sufficient reason for some users not use Cygwin, > but this his hardly Fedora's problem. You are in essense saying that only GPL software is allowed in Fedora which is utter nonsense. We want to use MinGW so that we can provide LGPL software, since Cygwin is GPL only, which is a perfectly legitimate choice to make. 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 jorton at redhat.com Tue Jul 8 08:01:59 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Jul 2008 09:01:59 +0100 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 In-Reply-To: <1215469865.2819.13.camel@shrek.rexursive.com> References: <20080707163443.A8909@humbolt.us.dell.com> <1215468642.2819.8.camel@shrek.rexursive.com> <1215469865.2819.13.camel@shrek.rexursive.com> Message-ID: <20080708080159.GA5275@redhat.com> On Tue, Jul 08, 2008 at 08:31:05AM +1000, Bojan Smojver wrote: > On Tue, 2008-07-08 at 08:10 +1000, Bojan Smojver wrote: > > > Looking into libapreq2. > > OK, fixed too. > > If anyone has broken packages related to apr-util going 1.3.x, it may be > due to what apu-1-config --libs returns, which contains LDAP libraries > by default. Try using apu-1-config --avoid-ldap --libs instead (order of > options is important). apr-util-devel dropped the "Requires: openldap-devel" - this is still needed for the same source compat problems as upstream. I've restored this and am building -5. Individual packages *can* switch to using --avoid-ldap but builds should not be broken without that. joe From bojan at rexursive.com Tue Jul 8 08:12:13 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 8 Jul 2008 08:12:13 +0000 (UTC) Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 References: <20080707163443.A8909@humbolt.us.dell.com> <1215468642.2819.8.camel@shrek.rexursive.com> <1215469865.2819.13.camel@shrek.rexursive.com> <20080708080159.GA5275@redhat.com> Message-ID: Joe Orton redhat.com> writes: > apr-util-devel dropped the "Requires: openldap-devel" - this is still > needed for the same source compat problems as upstream. Right, I missed that bit :-( > Individual packages *can* switch to using > --avoid-ldap but builds should not be broken without that. libapreq2 trunk and 2_10 have had --avoid-ldap committed today, for APU that has that option. -- Bojan From rc040203 at freenet.de Tue Jul 8 08:32:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Jul 2008 10:32:53 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708075527.GA24934@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> <20080708075527.GA24934@redhat.com> Message-ID: <1215505973.2809.294.camel@beck.corsepiu.local> On Tue, 2008-07-08 at 08:55 +0100, Daniel P. Berrange wrote: > On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote: > > On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote: > > > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote: > > > > Any particular reason to go with MinGW rather than Cygwin? Is there > > > > room for both in the SIG? > > > > > > Cygwin has a licensing issue -- namely that it is GPL and so prevents > > > any proprietary development on top of our libraries. > > How can a toolchain not supporting proprietary development be an issue > > to Fedora? It may-be sufficient reason for some users not use Cygwin, > > but this his hardly Fedora's problem. > > You are in essense saying that only GPL software is allowed in Fedora > which is utter nonsense. Absolute not - I am actually saying the opposite: * The fact Cygwin appears to be GPL'ed only, is an issue to Cygwin users, because it may prevent them from using Cygwin for proprietary packages/development (must not link against non-GPL'ed libs). * The fact Cygwin appears to be GPL'ed only, is not an issue to Fedora. There is no reason for not including Fedora->Cygwin cross-compilers into Fedora. > We want to use MinGW so that we can provide > LGPL software, since Cygwin is GPL only, which is a perfectly legitimate > choice to make. Of cause, ... Ralf From drago01 at gmail.com Tue Jul 8 09:11:16 2008 From: drago01 at gmail.com (drago01) Date: Tue, 8 Jul 2008 11:11:16 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215473192.7472.27.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> <1215469970.7472.22.camel@hughsie-work> <1215473192.7472.27.camel@hughsie-work> Message-ID: On Tue, Jul 8, 2008 at 1:26 AM, Richard Hughes wrote: > On Tue, 2008-07-08 at 00:57 +0200, drago01 wrote: >> Yeah but for the periodic update check why should the user care? >> pupplet wasn't displaying the I am "doing something" notification but >> only "there are updates". >> So I suggest only showing it when the user manually request for it to >> check for updates but not after login / connection to the network >> while performing the automatic check. > > Sure, it appears so you know it's doing something... for me the hard > drive light goes on and the CPU goes up to 100% for a few seconds, and > it's nice to know what's going on. Maybe this is insane. Comments > welcome. Yeah but if every app that does something in the background adds something to the panel that would be ... I still suggest that it should only show up when it wants stuff from the user or to inform the user that automatic update (not searching for update but appling them) is happening. Also it does not take that long to check for updates. >> >> 2) I tryed to delete multple package at once but after pressing the >> >> apply button it started to resolve deps in the background without >> >> showing any feedback to the user for ~30 sec >> >> (the user might think it did nothing and keep clicking on the apply button), >> > >> > Valid. Could you file a bug in RH bugzilla please (so I remember), and >> > I'll sort it in 0.2.4 after I get back from GUADEC. >> >> Sure, will do later today (its 0:56 am now ;) ) > > 2:28am -- I win! :-) ;) Bug filled: https://bugzilla.redhat.com/show_bug.cgi?id=454399 From gnomeuser at gmail.com Tue Jul 8 09:22:08 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 8 Jul 2008 11:22:08 +0200 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1215469850.7472.18.camel@hughsie-work> References: <1215450510.7472.11.camel@hughsie-work> <1dedbbfc0807071019gccf0877p8a41a47b04473fff@mail.gmail.com> <1215469850.7472.18.camel@hughsie-work> Message-ID: <1dedbbfc0807080222o21194bb1m5de0496dcd533386@mail.gmail.com> 2008/7/8 Richard Hughes : > On Mon, 2008-07-07 at 19:19 +0200, David Nielsen wrote: > > I've been running these for a while now and I see no stability or > > performance problems. So far they have survived installing/removing > > software and performing several system updates without issue. > > Excellent work > > Thanks, cheers for the positive response. One little UI problem I hit earlier, when installing a unsigned package such as from koji PackageKit throws up a dialog calling it an error, this should probably be a warning instead as it's non fatal to the requested operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Tue Jul 8 09:41:18 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 8 Jul 2008 09:41:18 +0000 (UTC) Subject: rawhide report: 20080708 changes Message-ID: <20080708094118.BBAD3209D2C@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080707/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080708/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package automaton A Java finite state automata/regular expression library New package netstiff A powerful Web and FTP site update checker New package pytrainer A tool to log all your sport excursions Removed package fonts-indic Removed package spicebird Updated Packages: HelixPlayer-1.0.9-4.fc10 ------------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1:1.0.9-4 - fix conditional comparison * Tue May 20 18:00:00 2008 Tom "spot" Callaway - 1:1.0.9-3 - fix license tag R-2.7.1-1.fc10 -------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway 2.7.1-1 - update to 2.7.1 agave-0.4.2-8.fc10 ------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.4.2-8 - fix conditional comparison autoconf-2.62-5.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Karsten Hopp 2.62-5 - fix multiline variables (p.e. #449467) bitlbee-1.2.1-1.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Robert Scheck 1.2.1-1 - Upgrade to 1.2.1 (thanks to Mat??j Cepl) buoh-0.8.2-5.fc10 ----------------- * Tue Jun 24 18:00:00 2008 Tomas Mraz - 0.8.2-5 - rebuild with new gnutls cairo-dock-1.6.1-0.1.svn1179_trunk.fc10 --------------------------------------- * Tue Jul 8 18:00:00 2008 Mamoru Tasaka - rev. 1179 cobbler-1.0.3-1.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Michael DeHaan - 1.0.3-1 - Upstream changes (see CHANGELOG) * Mon Jun 9 18:00:00 2008 Michael DeHaan - 1.0.2-1 - Upstream changes (see CHANGELOG) dbmail-2.2.9-2.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 2.2.9-2 - fix conditional comparison dbus-java-2.5-3.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Omair Majid - 2.5-3 - Added a patch to fix the htlatex environment - added -j1 to make to fix the race condition in makefile dbxml-perl-2.003-5.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Milan Zazrivec - 0.19.1-2 - Rebuild, just to keep up with F9 package. dirac-0.10.0-2.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway 0.10.0-2 - fix conditional comparison drivel-2.1.1-0.6.20071130svn.fc10 --------------------------------- * Mon Jul 7 18:00:00 2008 Tomas Mraz - 2.1.1-0.6.20071130svn - rebuild with new gnutls dxpc-3.9.1-0.3.b1.fc10.1 ------------------------ * Mon Jul 7 18:00:00 2008 Adam Jackson 3.9.1-0.3.b1.1 - Fix %fedora string comparison to be integer comparison. e2fsprogs-1.41-0.2.WIP.0707.fc10 -------------------------------- * Mon Jul 7 18:00:00 2008 Eric Sandeen 1.41-0.2.WIP.0707 - Fix release macro snafu * Mon Jul 7 18:00:00 2008 Eric Sandeen 1.41-0.1.WIP.0707 - New upstream snapshot release echo-icon-theme-0.3.89.0-0.7.git1f550b3.fc10 -------------------------------------------- eclipse-slide-1.3.9-1.fc10 -------------------------- * Mon Jun 16 18:00:00 2008 Dave Sugar - 1.3.9-1 - updates to support CDS Framework development - downgrade policycoreutils requirements for RHEL support elfutils-0.135-2.fc10 --------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.135-2 - fix conditional comparison exaile-0.2.13-2.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.2.13-2 - fix conditional comparison - add sparc64 to 64bit arch check flashrom-0-0.11.20080607svn3418.fc10 ------------------------------------ * Sun Jul 6 18:00:00 2008 Peter Lemenkov 0-0.11.20080607svn3418 - AMIC A29002 - flashing system with Nvidia MCP67 - PCI IDs for EPIA-CN - VIA SPI controller on VT8237S - ICH7 SPI support - support for AMIC Technology A49LF040A - Board enable and autodetection for GIGABYTE GA-7VT600 - Add support for Amic Technology A29040B flash chip - Board enable and autodetection for BioStar P4M80-M4 - Add support for the ASUS P4B266 board - Add support for Amic A25L40P SPI flash * Fri Jun 6 18:00:00 2008 Peter Lemenkov 0-0.10.20080517svn3332 - Exclude sparc64 fpm2-0.72-1.fc10 ---------------- * Mon Jul 7 18:00:00 2008 Ale?? Koval - 0.72-1 - Update to 0.72 gchempaint-0.8.7-3.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Julian Sikorski - 0.8.7-3 - Rebuilt for new openbabel gdeskcal-1.01-2.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1.01-2 - fix license tag - fix conditional comparison geda-examples-20080127-2.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 20080127-2 - fix conditional comparison geda-utils-20080127-2.fc10 -------------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 20080127-2 - fix conditional comparison gnome-applet-timer-2.0.1-4.fc10 ------------------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway 2.0.1-4 - use proper conditional * Mon Jul 7 18:00:00 2008 Adam Jackson 2.0.1-3 - %fedora is an int, not a string. gnome-chemistry-utils-0.8.7-2.fc10 ---------------------------------- * Mon Jul 7 18:00:00 2008 Julian Sikorski - 0.8.7-2 - Rebuilt for new openbabel graphviz-2.16.1-0.6.fc10 ------------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway 2.16.1-0.6 - fix conditional comparison gt5-1.4.0-5.fc10 ---------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1.4.0-5 - fix conditional comparison gtk-vnc-0.3.6-3.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.3.6-3 - fix conditional comparison gtkimageview-1.6.1-2.fc10 ------------------------- * Mon Jul 7 18:00:00 2008 Nils Philippsen - 1.6.1-2 - don't use URL for source since it doesn't download the source directly hal-cups-utils-0.6.17-1.fc10 ---------------------------- * Mon Jul 7 18:00:00 2008 Tim Waugh 0.6.17-1 - 0.6.17. Requires system-config-printer-libs >= 1.0.3. hunspell-ca-0.20080706-1.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Caolan McNamara - 0.20080706-1 - latest version hunspell-da-1.7.22-1.fc10 ------------------------- * Mon Jul 7 18:00:00 2008 Caolan McNamara - 1.7.22-1 - latest version hunspell-fo-0.2.33-1.fc10 ------------------------- * Mon Jul 7 18:00:00 2008 Caolan McNamara - 0.2.33-1 - latest version hunspell-pt-0.20080705-1.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Caolan McNamara - 0.20080705-1 - latest version jd-2.0.0-0.7.svn2183_trunk.fc10 ------------------------------- * Tue Jul 8 18:00:00 2008 Mamoru Tasaka - rev 2183 jpackage-utils-1.7.5-1jpp.3.fc10 -------------------------------- * Mon Jul 7 18:00:00 2008 Deepak Bhole 1.7.5-1jpp.3 - Own mavendepmapfragdir as well. * Mon Jul 7 18:00:00 2008 Deepak Bhole 1.7.5-1jpp.2 - Add ownership of maven directories kdeedu-4.0.84-2.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Kevin Kofler 4.0.84-2 - rebuild for new OpenBabel kdelibs-4.0.85-1.fc10 --------------------- * Sun Jul 6 18:00:00 2008 Rex Dieter 4.0.85-1 - 4.0.85 kdevelop-3.5.2-3.fc10 --------------------- * Mon Jul 7 18:00:00 2008 Kevin Kofler - 9:3.5.2-3 - fix FTBFS (add BR openldap-devel to work around missing dep in apr-devel) kernel-2.6.26-0.115.rc9.git2.fc10 --------------------------------- * Mon Jul 7 18:00:00 2008 Dave Jones - 2.6.26-rc9-git2 * Mon Jul 7 18:00:00 2008 Dave Jones - 2.6.26-rc9-git1 * Mon Jul 7 18:00:00 2008 Chuck Ebbert - Skip building the kernel-doc package due to breakage somewhere in rawhide XML land. * Sun Jul 6 18:00:00 2008 Dave Jones - 2.6.26-rc9 * Sat Jul 5 18:00:00 2008 Dave Jones - 2.6.26-rc8-git5 * Fri Jul 4 18:00:00 2008 Dave Jones - 2.6.26-rc8-git4 lesstif-0.95.0-26.fc10 ---------------------- * Mon Jul 7 18:00:00 2008 Patrice Dumas 0.95.0-26 - debian lesstif2_0.95.0-2.1 lib3ds-1.3.0-3.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1.3.0-3 - fix conditional comparison libapreq2-2.09-0.18.rc2.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Bojan Smojver - 2.09-0.18.rc2 - add patch to use --avoid-ldap with apu-1-config libdv-1.0.0-5.fc10 ------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway 1.0.0-5 - fix conditional comparison libgphoto2-2.4.1-6.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Jindrich Novy 2.4.1-6 - increase maximal number of entries in the camera list (#454245) liboggz-0.9.8-1.fc10 -------------------- * Mon Jul 7 18:00:00 2008 Michel Alexandre Salim - 0.9.8-1 - Update to 0.9.8 libsepol-2.0.32-1.fc10 ---------------------- * Mon Jul 7 18:00:00 2008 Dan Walsh 2.0.32-1 - Upgrade to latest from NSA * Allow require then declare in the source policy from Joshua Brindle. libsoup22-2.2.105-3.fc10 ------------------------ * Tue Jun 24 18:00:00 2008 Tomas Mraz - 2.2.105-3 - rebuild with new gnutls mkinitrd-6.0.55-1.fc10 ---------------------- * Mon Jul 7 18:00:00 2008 Jeremy Katz - 6.0.55-1 - Make plymouth work with live initrds - Strip out BOOT_IMAGE= as an argument to init so that things don't break if you do init=/bin/bash from syslinux multitail-5.2.2-1.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Fabio M. Di Nitto - 5.2.2-1 - New upstream release - Fix licence tag - Fix documentation encoding to UTF8 - Install some examples in doc dir ncurses-5.6-18.20080628.fc10 ---------------------------- * Mon Jul 7 18:00:00 2008 Miroslav Lichvar 5.6-18.20080628 - update to patch 20080628 - move mlterm and screen.* entries to -base - change kbs to ^? in rxvt and screen entries nexuiz-2.4.2-2.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Jon Ciesla - 2.4.2-2 - Fix debuginfo, BZ 454141. ocaml-cil-1.3.6-6.fc10 ---------------------- * Mon Jul 7 18:00:00 2008 Richard W.M. Jones - 1.3.6-6 - Fix Perl paths (rhbz#453759). perl-Crypt-RSA-1.97-1.fc10 -------------------------- * Mon Jul 7 18:00:00 2008 Paul Howarth 1.97-1 - Update to 1.97 * Mon Jul 7 18:00:00 2008 Paul Howarth 1.96-1 - Update to 1.96 - Convert "Changes" to UTF-8 - Shellbangs no longer need removing - Module is now UTF-8 and doesn't need converting - Need manual perl(Class::Loader) dep due to move to use of "use base", as rpm auto-dep-finder doesn't spot it perl-Crypt-Simple-0.06-6.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.06-6 - fix conditional comparison ppc64-utils-0.14-3.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Roman Rakus - 0.14-3 - Requires yaboot only for ppc arch pspp-0.6.0-7.fc10 ----------------- * Mon Jul 7 18:00:00 2008 Matej Cepl 0.6.0-7 - Fix BuildRequires. python-basemap-0.99-1.fc10 -------------------------- * Wed Jul 2 18:00:00 2008 Jef Spaleta 0.99-1 - Update to match latest matplotlib python-openid-2.2.1-1.fc10 -------------------------- * Mon Jul 7 18:00:00 2008 Jeffrey C. Ollie - 2.2.1-1 - Update to 2.2.1 * Fri Jun 6 18:00:00 2008 Jeffrey C. Ollie - 2.2.0-1 - Update to 2.2.0 python-paramiko-1.7.4-1.fc10 ---------------------------- * Sun Jul 6 18:00:00 2008 Jeffrey C. Ollie - 1.7.4-1 - Update to 1.7.4 qpidc-0.2.667603-2.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Nuno Santos - 0.2.667603-2 - MRG GA release * Fri Jun 13 18:00:00 2008 Justin Ross - 0.2.667603-1 - Update to source revision 667603 * Thu Jun 12 18:00:00 2008 Nuno Santos - 0.2.666138-5 - add missing doc files * Thu Jun 12 18:00:00 2008 Justin Ross - 0.2.667253-1 - Update to source revision 667253 * Wed Jun 11 18:00:00 2008 Justin Ross - 0.2.666138-3 - Added directories for modules and pid files to install script * Wed May 28 18:00:00 2008 David Sommerseth - 0.2.663761-1 - Added perftest utilities * Thu May 22 18:00:00 2008 Nuno Santos - 0.2.656926-4 - Additional build flags for i686 * Tue May 20 18:00:00 2008 Nuno Santos - 0.2.656926-3 - BZ 432872: remove examples, which are being packaged separately * Tue May 20 18:00:00 2008 Justin Ross -0.2.656926-2 - Drop build requirements for graphviz and help2man qt3-3.3.8b-14.fc10 ------------------ * Mon Jul 7 18:00:00 2008 Rex Dieter - 3.3.8b-14 - QTDIR isn't set in ppc64 buildroot (#454313) - /etc/profile.d/qt.sh leaks variable ARCH (#454260) qt4-theme-quarticurve-0.0-0.12.beta7.fc10 ----------------------------------------- * Mon Jul 7 18:00:00 2008 Kevin Kofler - 0.0-0.12.beta7 - Explicitly set KDE4_APPSDIR to work around broken autodetection for now (fixes FTBFS). rapidsvn-0.9.6-3.fc10 --------------------- * Mon Jul 7 18:00:00 2008 Tim Jackson 0.9.6-3 - Add missing BR on openldap-devel * Tue Jun 3 18:00:00 2008 Tim Jackson 0.9.6-2 - Fix spec file to build using latest RPM version - Remove filename suffix from icon in desktop file as per standards selinux-policy-3.4.2-12.fc10 ---------------------------- * Mon Jul 7 18:00:00 2008 Dan Walsh 3.4.2-12 - Allow amanda to read tape - Allow prewikka cgi to use syslog, allow audisp_t to signal cgi - Add support for netware file systems ser-0.9.6-15.fc10 ----------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.9.6-15 - fix conditional comparison - fix license tag - fix unnecessary file deps subversion-api-docs-1.5.0-1.fc10 -------------------------------- * Tue Jul 8 18:00:00 2008 Bojan Smojver 1.5.0-1 - bump up to 1.5.0 tomboy-0.11.0-4.fc10 -------------------- * Sun Jul 6 18:00:00 2008 Michel Alexandre Salim - 0.11.0-4 - rebuild for mono dependencies virt-viewer-0.0.3-3.fc10 ------------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.0.3-3.fc10 - fix conditional comparison - remove file dep wildmidi-0.2.2-5.fc10 --------------------- * Mon Jul 7 18:00:00 2008 Hans de Goede 0.2.2-5 - Fix wildmidi cmdline player sound output on bigendian archs (bz 454198), patch by Ian Chapman wordwarvi-0.18-1.fc10 --------------------- * Mon Jul 7 18:00:00 2008 Hans de Goede 0.18-1 - New upstream release 0.18 xdrawchem-1.9.9-11.fc10 ----------------------- * Mon Jul 7 18:00:00 2008 Dominik Mierzejewski 1.9.9-11 - rebuild for new openbabel xfce4-mailwatch-plugin-1.0.1-10.fc10 ------------------------------------ * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1.0.1-10 - fix conditional comparison xfce4-xkb-plugin-0.4.3-5.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 0.4.3-5 - fix conditional comparison xorg-x11-drv-vesa-2.0.0-1.fc10 ------------------------------ * Tue Jul 1 18:00:00 2008 Adam Jackson 2.0.0-1 - vesa 2.0.0 xorg-x11-font-utils-7.2-5.fc10 ------------------------------ * Mon Jul 7 18:00:00 2008 Adam Jackson 7.2-5 - Fix Source url for font-util. zabbix-1.4.5-4.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Dan Horak - 1.4.5-4 - add LSB headers into init scripts - disable internal log rotation Summary: Added Packages: 3 Removed Packages: 2 Modified Packages: 80 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 rpy-1.0.3-1.fc10.i386 requires R = 0:2.7.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 rpy-1.0.3-1.fc10.x86_64 requires R = 0:2.7.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 rpy-1.0.3-1.fc10.ppc requires R = 0:2.7.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 rpy-1.0.3-1.fc10.ppc64 requires R = 0:2.7.0 scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From smparrish at shallowcreek.net Tue Jul 8 12:04:59 2008 From: smparrish at shallowcreek.net (Steven M. Parrish) Date: Tue, 8 Jul 2008 08:04:59 -0400 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <3170f42f0807072137mf4a6f42yad1eab4c2549741d@mail.gmail.com> References: <48728552.3040706@redhat.com> <3170f42f0807072137mf4a6f42yad1eab4c2549741d@mail.gmail.com> Message-ID: <200807080805.06239.smparrish@shallowcreek.net> On Tuesday 08 July 2008 12:37:42 am Debarshi Ray wrote: > > tripwire > > I found this file in the CVS for tripwire: > http://cvs.fedoraproject.org/viewcvs/rpms/tripwire/devel/License-Issues?vie >w=markup Is tripwire safe to be included in Fedora? > > Cheers, > Debarshi According to the referenced Debian bug the issues were resolved years ago. Looks like the file should be removed from CVS. I'll take over maintainance of it. 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 limb at jcomserv.net Tue Jul 8 12:32:39 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 8 Jul 2008 07:32:39 -0500 (CDT) Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <48728552.3040706@redhat.com> References: <48728552.3040706@redhat.com> Message-ID: <30473.198.175.55.5.1215520359.squirrel@mail.jcomserv.net> > Please review the following packages. This is roughly the list of > current orphans in rawhide. If they are not claimed by June 18th then > they may be removed from rawhide by the F10 Alpha freeze. > > xdms Rescued. > > 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 > -- novus ordo absurdum From dtimms at iinet.net.au Tue Jul 8 13:08:08 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 08 Jul 2008 23:08:08 +1000 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> Message-ID: <487366B8.2060306@iinet.net.au> A long, long time ago, Kulbir Saini wrote: > Thank a lot for noting down all those points. They helped me to have > a more clear idea of InstantMirror. And thanks for the encouragement > as well :) Hi, wondering what is considered _the_ current approach for making an internal Fedora proxy mirror ? Does the MirrorManager 0.4 code actually work, eg for 5 PC's ? Did something else {other than full rsync mirroring} emerge to solve this type of problem ? I was wondering if an automated way to get the clients to use the proxy / cache would by to implement dns entries for the real yum server names, that point to your internal ~mirror server; and hence bypass requiring individual machine proxy setup ? Regards, DaveT. From sgrubb at redhat.com Tue Jul 8 13:10:00 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 8 Jul 2008 09:10:00 -0400 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <3170f42f0807072137mf4a6f42yad1eab4c2549741d@mail.gmail.com> References: <48728552.3040706@redhat.com> <3170f42f0807072137mf4a6f42yad1eab4c2549741d@mail.gmail.com> Message-ID: <200807080910.01153.sgrubb@redhat.com> On Tuesday 08 July 2008 00:37:42 Debarshi Ray wrote: > > tripwire > > I found this file in the CVS for tripwire: > http://cvs.fedoraproject.org/viewcvs/rpms/tripwire/devel/License-Issues?vie >w=markup Is tripwire safe to be included in Fedora? I think its safe, but its very old code. We've spent time working on aide which is a simple program that does the same thing and adding support to it for modern hashes, extended attributes, and sending results to the audit logs. I'd say that there would be significant work to bring tripwire up to par, and then I doubt that upstream could take the patch since the commercial code has likely changed. I'd vote for letting this one die. -Steve From surenkarapetyan at gmail.com Tue Jul 8 13:16:09 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Tue, 08 Jul 2008 15:16:09 +0200 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <487366B8.2060306@iinet.net.au> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> Message-ID: <1215522969.4888.35.camel@roadrunner.itnet.am> On Tue, 2008-07-08 at 23:08 +1000, David Timms wrote: > A long, long time ago, Kulbir Saini wrote: > > Thank a lot for noting down all those points. They helped me to have > > a more clear idea of InstantMirror. And thanks for the encouragement > > as well :) > > Hi, wondering what is considered _the_ current approach for making an > internal Fedora proxy mirror ? > Does the MirrorManager 0.4 code actually work, eg for 5 PC's ? > > Did something else {other than full rsync mirroring} emerge to solve > this type of problem ? > > I was wondering if an automated way to get the clients to use the proxy > / cache would by to implement dns entries for the real yum server names, > that point to your internal ~mirror server; and hence bypass requiring > individual machine proxy setup ? > > Regards, DaveT. > Even with all it's weeknesses InstantMirror could be used with MirrorManager to do transparent caching/mirroring... Take a system with enough HDD space, install instantmirror, go to mirror manager admin page, create a new site, add your ips, and the mirror. The get the mirror reporting script and make it run with cron :) It isn't perfect but it's much berrer than nothing From sundaram at fedoraproject.org Tue Jul 8 13:18:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Jul 2008 18:48:23 +0530 Subject: Broken dependencies in Fedora 9 - 2008-07-07 In-Reply-To: <20080707143445.32556.57325@faldor.intranet> References: <20080707143445.32556.57325@faldor.intranet> Message-ID: <4873691F.9060704@fedoraproject.org> Michael Schwendt wrote: > > sundaram AT redhat.com > gyachi-plugin-photosharing-1.1.0-7.fc9.i386 > gyachi-plugin-photosharing-1.1.0-7.fc9.ppc > gyachi-plugin-photosharing-1.1.0-7.fc9.ppc64 > gyachi-plugin-photosharing-1.1.0-7.fc9.x86_64 This is a missing obsolete in a new build from my co-maintainer that is getting fixed now. Thanks. Rahul From berrange at redhat.com Tue Jul 8 13:30:10 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 14:30:10 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080707211554.GA8320@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> Message-ID: <20080708133010.GR24934@redhat.com> On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote: > I've got a self-building, mostly working set of Fedora packages for > the MinGW cross-compiler (no optional libraries yet). You can get the > spec files and instructions by doing: > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel What primarily concerns me is that plan around keeping this in sync with patches/updates to the main gcc, binutils, libpng, libgcrypt, gnutls, etc RPMS already in Fedora. The idea of maintaining 2 near identical specs & builds for all these packages isn't that nice, particularly since many of these are security sensitive packages 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 greno at verizon.net Tue Jul 8 14:15:43 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 08 Jul 2008 10:15:43 -0400 Subject: mobile broadband support In-Reply-To: References: <4872D782.3000002@verizon.net> Message-ID: <4873768F.2080100@verizon.net> Colin Walters wrote: > > (I believe the answer is that the signal strength requires > card-specific logic which isn't documented, so this isn't easy to > implement) > I finally located an area in the wiki for this: https://fedoraproject.org/wiki/Features/NetworkManager-MobileBroadband "Signal strength while connected is not supported at this time because most cards use proprietary protocols to retrieve signal strength while connected." and this was for Fedora 9 release. So maybe some work will happen for Fedora 10 that would start to add signal strength display for these cards. Regards, Gerry From debarshi.ray at gmail.com Tue Jul 8 14:18:00 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 8 Jul 2008 19:48:00 +0530 Subject: fish uses old xsel In-Reply-To: <486FDAC5.2030903@nobugconsulting.ro> References: <3170f42f0807050950s7a5f9eecvecab66f19c1b62e3@mail.gmail.com> <3170f42f0807051130o16a8911bk30310c88e87163de@mail.gmail.com> <486FDAC5.2030903@nobugconsulting.ro> Message-ID: <3170f42f0807080718m742d220dr1eb8a8201229d01d@mail.gmail.com> > 1.using a private version of another piece of software is definitely a no-no > for fedora. either submit it separately, or arrange for the existing one to > be patched. and make use of the blocker bugs to notify that one bug > blocks/is blocked by another one So are the fish maintainers (CC'ed) interested in taking up xsel? Cheerio, Debarshi From lakshmipathi.g at gmail.com Tue Jul 8 14:22:51 2008 From: lakshmipathi.g at gmail.com (lakshmi pathi) Date: Tue, 8 Jul 2008 19:52:51 +0530 Subject: Do we have Deep Freeze/Clean Slate like tool? Message-ID: Hi all, Recently i came across Deep Freeze/Clean slate in a linux forum.Do we have open source alternative to these tools? Is that really helpful tool for linux user? Please share your thoughts. Cheers, Lakshmipathi.G My projects: http://sourceforge.net/projects/giis http://sourceforge.net/projects/exthide http://sourceforge.net/projects/ext3crave From pbrobinson at gmail.com Tue Jul 8 14:42:28 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 8 Jul 2008 15:42:28 +0100 Subject: mobile broadband support In-Reply-To: <4873768F.2080100@verizon.net> References: <4872D782.3000002@verizon.net> <4873768F.2080100@verizon.net> Message-ID: <5256d0b0807080742v743c4912jc650919a8f550245@mail.gmail.com> >> (I believe the answer is that the signal strength requires card-specific >> logic which isn't documented, so this isn't easy to implement) >> > I finally located an area in the wiki for this: > https://fedoraproject.org/wiki/Features/NetworkManager-MobileBroadband > > "Signal strength while connected is not supported at this time because > most cards use proprietary protocols to retrieve signal strength while > connected." > > and this was for Fedora 9 release. So maybe some work will happen for > Fedora 10 that would start to add signal strength display for these cards. I think part of the problem is that you need two serial ports/control ports to be able to get signal at the same time as being connected and not all cards have the two ports to do that. There's umtsmon but I'm not sure it works at the same time as NetworkManager http://umtsmon.sourceforge.net/ Peter From kevin.kofler at chello.at Tue Jul 8 14:47:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 8 Jul 2008 14:47:53 +0000 (UTC) Subject: Do we have Deep Freeze/Clean Slate like tool? References: Message-ID: lakshmi pathi gmail.com> writes: > Recently i came across Deep Freeze/Clean slate in a linux forum.Do we > have open source alternative to these tools? Boot from a live CD or from a USB key without a persistency overlay to get exactly that effect. You can also use the same setup (I believe it's unionfs with ramfs) on a HDD. Kevin Kofler From rjones at redhat.com Tue Jul 8 14:46:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 15:46:40 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708133010.GR24934@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> Message-ID: <20080708144640.GA16785@amd.home.annexia.org> On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote: > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote: > > I've got a self-building, mostly working set of Fedora packages for > > the MinGW cross-compiler (no optional libraries yet). You can get the > > spec files and instructions by doing: > > > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel > > What primarily concerns me is that plan around keeping this in sync > with patches/updates to the main gcc, binutils, libpng, libgcrypt, > gnutls, etc RPMS already in Fedora. > > The idea of maintaining 2 near identical specs & builds for all these > packages isn't that nice, particularly since many of these are security > sensitive packages So there's a bit of confusion going around, partly my own. Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408) starts with a forked version of binutils maintained by mingw. They have their own release schedule for this so I'm not sure how viable it is to have a single binutils SPEC file generating both the normal binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether or not the Fedora binutils maintainer is even interested in this). Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts from plain gcc 4.3.1 source, so combining these into Fedora's gcc package might be more hopeful. However there are some nasty dependencies (mingw-runtime and mingw-w32api, neither of which can be built ab initio because of circular dependencies) and I suspect that any time there is any sort of mingw related trouble with this package, the gcc-mingw subpackage will be the first to be dropped. I don't want this. As for the remainder we get into asking question like -- should we generate the mingw-gnutls library (as an example) from the main gnutls SPEC file? There are going to be dozens of such libraries and we'll have to coordinate with a large number of existing Fedora contributors to make this happen. 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 rc040203 at freenet.de Tue Jul 8 15:05:51 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Jul 2008 17:05:51 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708144640.GA16785@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> Message-ID: <1215529551.2809.347.camel@beck.corsepiu.local> On Tue, 2008-07-08 at 15:46 +0100, Richard W.M. Jones wrote: > On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote: > > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote: > > > I've got a self-building, mostly working set of Fedora packages for > > > the MinGW cross-compiler (no optional libraries yet). You can get the > > > spec files and instructions by doing: > > > > > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel > > > > What primarily concerns me is that plan around keeping this in sync > > with patches/updates to the main gcc, binutils, libpng, libgcrypt, > > gnutls, etc RPMS already in Fedora. > > > > The idea of maintaining 2 near identical specs & builds for all these > > packages isn't that nice, particularly since many of these are security > > sensitive packages > > So there's a bit of confusion going around, partly my own. > > Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408) > starts with a forked version of binutils maintained by mingw. They > have their own release schedule for this so I'm not sure how viable it > is to have a single binutils SPEC file generating both the normal > binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether > or not the Fedora binutils maintainer is even interested in this). >From my experience, using a unified spec is non-viable. All it does is to add avoidable package deps and unnecessarily complicates things, because a MinGW-binutils is widely independent from Linux (and Fedora). Furthermore, binutils is comparatively small, easy to package and easy to maintain - GCC is a completely different matter. > Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts > from plain gcc 4.3.1 source, so combining these into Fedora's gcc > package might be more hopeful. I would not do this - MinGW is a different OS, suffers from different issues and has a different upstream (RH-branch vs. FSF-trunk vs. MinGW hacked GCC). > However there are some nasty > dependencies (mingw-runtime and mingw-w32api, neither of which can be > built ab initio because of circular dependencies) and I suspect that > any time there is any sort of mingw related trouble with this package, > the gcc-mingw subpackage will be the first to be dropped. I don't > want this. > As for the remainder we get into asking question like -- should we > generate the mingw-gnutls library (as an example) from the main gnutls > SPEC file? Same as above. I would not want to merge any MinGW package's specs with Linux/Fedoras. They share a common upstream somewhere, but MinGW's upstream isn't necessarily identical to Fedora. > There are going to be dozens of such libraries and we'll > have to coordinate with a large number of existing Fedora contributors > to make this happen. Only if you merge them. IMO, this is not useful for cross-toolchains, because you actually will want to use their sources, not Fedoras. For my own cross-toolchains, I even go one step further - I repackage a cross-toolchain's library-binaries, and only build the cross-tools, because only a target's binaries are guaranteed to be compatible with the "native upstream". Ralf From berrange at redhat.com Tue Jul 8 15:13:56 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 16:13:56 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708144640.GA16785@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> Message-ID: <20080708151356.GA13117@redhat.com> On Tue, Jul 08, 2008 at 03:46:40PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote: > > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote: > > > I've got a self-building, mostly working set of Fedora packages for > > > the MinGW cross-compiler (no optional libraries yet). You can get the > > > spec files and instructions by doing: > > > > > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel > > > > What primarily concerns me is that plan around keeping this in sync > > with patches/updates to the main gcc, binutils, libpng, libgcrypt, > > gnutls, etc RPMS already in Fedora. > > > > The idea of maintaining 2 near identical specs & builds for all these > > packages isn't that nice, particularly since many of these are security > > sensitive packages > > So there's a bit of confusion going around, partly my own. > > Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408) > starts with a forked version of binutils maintained by mingw. They > have their own release schedule for this so I'm not sure how viable it > is to have a single binutils SPEC file generating both the normal > binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether > or not the Fedora binutils maintainer is even interested in this) It is rather a shame Mingw can't submit their changes upstream, or at least provide patches against upstream rather than re-spinning the entire tar.gz. But since that's the way they've done it I guess we have no choice but to work with it as a forked package in the short term. > Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts > from plain gcc 4.3.1 source, so combining these into Fedora's gcc > package might be more hopeful. However there are some nasty > dependencies (mingw-runtime and mingw-w32api, neither of which can be > built ab initio because of circular dependencies) and I suspect that > any time there is any sort of mingw related trouble with this package, > the gcc-mingw subpackage will be the first to be dropped. I don't > want this. I must say the complexity of the existing GCC RPM in Fedora is pretty scary, and more to the point seems to want pretty strict versions of binutils which given the fork'ing of binutils by MinGW is a pain point. > As for the remainder we get into asking question like -- should we > generate the mingw-gnutls library (as an example) from the main gnutls > SPEC file? There are going to be dozens of such libraries and we'll > have to coordinate with a large number of existing Fedora contributors > to make this happen. This is where it gets non-scalable if we have a forked SPEC for every library we want to build for mingw. We need to make it easy for the maintainence of all the libs to be devolved to the existing maintainers of the libraries, preferably with little-to-no extra work for these maintainers. We shouldn't get into the world of maintaining two independant copies of things like GNUTLS, libpng, libvirt, etc. If we can get away with only having mingw custom packages for gcc,binutils, and the runtime, and then sub-RPM for all the other bits I'd be reasonably satisfied. 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 wtogami at redhat.com Tue Jul 8 15:14:33 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Jul 2008 11:14:33 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <1215522969.4888.35.camel@roadrunner.itnet.am> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> Message-ID: <48738459.4030808@redhat.com> Suren Karapetyan wrote: > On Tue, 2008-07-08 at 23:08 +1000, David Timms wrote: >> A long, long time ago, Kulbir Saini wrote: >>> Thank a lot for noting down all those points. They helped me to have >>> a more clear idea of InstantMirror. And thanks for the encouragement >>> as well :) >> Hi, wondering what is considered _the_ current approach for making an >> internal Fedora proxy mirror ? >> Does the MirrorManager 0.4 code actually work, eg for 5 PC's ? >> >> Did something else {other than full rsync mirroring} emerge to solve >> this type of problem ? >> >> I was wondering if an automated way to get the clients to use the proxy >> / cache would by to implement dns entries for the real yum server names, >> that point to your internal ~mirror server; and hence bypass requiring >> individual machine proxy setup ? >> >> Regards, DaveT. >> > > Even with all it's weeknesses InstantMirror could be used with > MirrorManager to do transparent caching/mirroring... > Take a system with enough HDD space, install instantmirror, > go to mirror manager admin page, create a new site, add your ips, and > the mirror. > The get the mirror reporting script and make it run with cron :) > It isn't perfect but it's much berrer than nothing > > I personally use squid in reverse proxy mode instead of InstantMirror. The main drawback of squid is the cache cannot be shared for other protocols (like rsync), but it is otherwise better because it handles cleanup and respects whatever maximum amount of storage you set. InstantMirror will keep growing and growing until it exhausts all space. InstantMirror also poorly handles concurrent clients. Warren From rjones at redhat.com Tue Jul 8 15:13:42 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 16:13:42 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708151356.GA13117@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> Message-ID: <20080708151342.GB16863@amd.home.annexia.org> On Tue, Jul 08, 2008 at 04:13:56PM +0100, Daniel P. Berrange wrote: > This is where it gets non-scalable if we have a forked SPEC for every > library we want to build for mingw. We need to make it easy for the > maintainence of all the libs to be devolved to the existing maintainers > of the libraries, preferably with little-to-no extra work for these > maintainers. We shouldn't get into the world of maintaining two > independant copies of things like GNUTLS, libpng, libvirt, etc. > > If we can get away with only having mingw custom packages for gcc,binutils, > and the runtime, and then sub-RPM for all the other bits I'd be reasonably > satisfied. I think it's reasonable to have a 'sample' spec file snippet for existing maintainers to use & modify when they feel they want to add MinGW support. I'll give it a go with some existing libraries to see what they would look like. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From pemboa at gmail.com Tue Jul 8 15:25:04 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 8 Jul 2008 10:25:04 -0500 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <48738459.4030808@redhat.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> Message-ID: <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> On Tue, Jul 8, 2008 at 10:14 AM, Warren Togami wrote: > Suren Karapetyan wrote: >> >> On Tue, 2008-07-08 at 23:08 +1000, David Timms wrote: >>> >>> A long, long time ago, Kulbir Saini wrote: >>>> >>>> Thank a lot for noting down all those points. They helped me to >>>> have >>>> a more clear idea of InstantMirror. And thanks for the encouragement >>>> as well :) >>> >>> Hi, wondering what is considered _the_ current approach for making an >>> internal Fedora proxy mirror ? >>> Does the MirrorManager 0.4 code actually work, eg for 5 PC's ? >>> >>> Did something else {other than full rsync mirroring} emerge to solve this >>> type of problem ? >>> >>> I was wondering if an automated way to get the clients to use the proxy / >>> cache would by to implement dns entries for the real yum server names, that >>> point to your internal ~mirror server; and hence bypass requiring individual >>> machine proxy setup ? >>> >>> Regards, DaveT. >>> >> >> Even with all it's weeknesses InstantMirror could be used with >> MirrorManager to do transparent caching/mirroring... >> Take a system with enough HDD space, install instantmirror, >> go to mirror manager admin page, create a new site, add your ips, and >> the mirror. >> The get the mirror reporting script and make it run with cron :) >> It isn't perfect but it's much berrer than nothing >> >> > > I personally use squid in reverse proxy mode instead of InstantMirror. The > main drawback of squid is the cache cannot be shared for other protocols > (like rsync), but it is otherwise better because it handles cleanup and > respects whatever maximum amount of storage you set. InstantMirror will keep > growing and growing until it exhausts all space. InstantMirror also poorly > handles concurrent clients. I wanted to try InstantMirror, but was in a rush. I just used a basic squid setup. Are their any advantages of using it as a reverse mirror vs. regular squid usage? Arthur Pemberton -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From bruno at wolff.to Tue Jul 8 15:38:54 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 8 Jul 2008 10:38:54 -0500 Subject: Do we have Deep Freeze/Clean Slate like tool? In-Reply-To: References: Message-ID: <20080708153854.GA7828@wolff.to> On Tue, Jul 08, 2008 at 19:52:51 +0530, lakshmi pathi wrote: > Hi all, > Recently i came across Deep Freeze/Clean slate in a linux forum.Do we > have open source alternative to these tools? > Is that really helpful tool for linux user? Please share your thoughts. Have you looked at xguest? Depending on exactly what you are doing it might be suitable for your purpose. One note about customizing the profile is that sabayon has a couple of bugs that prevent doing some types of customization. But that may not be a show stopper for you. xguest is set up to do unauthenticated logins. There might be problems with giving unauthenticated access to the network, even if it is only through firefox. From hughsient at gmail.com Tue Jul 8 14:20:45 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 Jul 2008 15:20:45 +0100 Subject: New PackageKit and gnome-packagekit in F9 soon In-Reply-To: <1dedbbfc0807080222o21194bb1m5de0496dcd533386@mail.gmail.com> References: <1215450510.7472.11.camel@hughsie-work> <1dedbbfc0807071019gccf0877p8a41a47b04473fff@mail.gmail.com> <1215469850.7472.18.camel@hughsie-work> <1dedbbfc0807080222o21194bb1m5de0496dcd533386@mail.gmail.com> Message-ID: <1215526845.12330.15.camel@hughsie-work> On Tue, 2008-07-08 at 11:22 +0200, David Nielsen wrote: > One little UI problem I hit earlier, when installing a unsigned > package such as from koji PackageKit throws up a dialog calling it an > error, this should probably be a warning instead as it's non fatal to > the requested operation. Fixed, thanks. Richard. From wtogami at redhat.com Tue Jul 8 15:48:41 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Jul 2008 11:48:41 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> Message-ID: <48738C59.4000907@redhat.com> Arthur Pemberton wrote: > > I wanted to try InstantMirror, but was in a rush. I just used a basic > squid setup. > > Are their any advantages of using it as a reverse mirror vs. regular > squid usage? > Regular squid wont be able to effectively cache if MirrorManager is telling you to use random mirrors. If you use MirrorManager you could receive the same local (reverse proxy) mirror as the first mirror every time if yum is used from your network block. refresh_pattern repodata/.*$ 0 0% 0 refresh_pattern .*rpm$ 0 0% 0 Also with any squid.conf you will need these lines in order to guarantee that your repodata and RPMS stay consistent with your upstream source. This is because proxies do not handle data changing without changing the filename. Warren Togami wtogami at redhat.com From kevin at scrye.com Tue Jul 8 15:55:07 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 8 Jul 2008 09:55:07 -0600 Subject: IRC support meeting - 2008-07-10 at 18:00 UTC In-Reply-To: <599059470807071901na90e4a9m917bbcc98eef7301@mail.gmail.com> References: <20080707130556.5e803959@ohm.scrye.com> <599059470807071901na90e4a9m917bbcc98eef7301@mail.gmail.com> Message-ID: <20080708095507.51807d24@ohm.scrye.com> On Tue, 8 Jul 2008 07:31:24 +0530 "roopesh majeti" wrote: > Hi Kevin, > Sorry to spam and ask. No problem at all. > I am new to Fedora and very much intertested to contribute. I would > like to attend the meeting. But just would like to know, if the > meetings can be sheduled at a little bit early time, as meeting the > time in my time-zone is around midnight [ 23:30 ]. Well, not on thursday, as the FESCo meeting is right before it. ;( We will try and see if we can move to another day that has an eariler timeslot. > Thanks > Roopesh. kevin -- > On 7/8/08, Kevin Fenzi wrote: > > > > We would like to have another meeting of folks interested in #fedora > > and IRC support this thursday at 18:00 UTC (right after the FESCo > > meeting). > > > > Topics: > > > > - Code of conduct for IRC support channels. > > - Scheduling timeperiods for helpers > > - Recruiting more helpers. > > - Decide if we should be a SIG or not. > > - Any other topics folks would like to discuss... > > > > All interested parties are welcome to join us! > > > > kevin > > > > > > > > -- > > 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: not available URL: From mcepl at redhat.com Tue Jul 8 15:57:19 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 08 Jul 2008 17:57:19 +0200 Subject: Request to re-add option to disable SELinux - compromise References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <16de708d0807070857o1b37c33bh8ce3f201c7193a0e@mail.gmail.com> Message-ID: On 2008-07-07, 15:57 GMT, Arthur Pemberton wrote: > However, I feel that users should be given the opportunity to > disable SELinux at will. And your point is? You mean to say, that our users who are knowledgeable enough that they can decide whether they want to have SELinux disabled are not smart enough to change one line in /etc/selinux/config? Mat?j From pemboa at gmail.com Tue Jul 8 16:02:12 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 8 Jul 2008 11:02:12 -0500 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <48738C59.4000907@redhat.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> Message-ID: <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> On Tue, Jul 8, 2008 at 10:48 AM, Warren Togami wrote: > Arthur Pemberton wrote: >> >> I wanted to try InstantMirror, but was in a rush. I just used a basic >> squid setup. >> >> Are their any advantages of using it as a reverse mirror vs. regular >> squid usage? >> > > Regular squid wont be able to effectively cache if MirrorManager is telling > you to use random mirrors. If you use MirrorManager you could receive the > same local (reverse proxy) mirror as the first mirror every time if yum is > used from your network block. > > refresh_pattern repodata/.*$ 0 0% 0 > refresh_pattern .*rpm$ 0 0% 0 > > Also with any squid.conf you will need these lines in order to guarantee > that your repodata and RPMS stay consistent with your upstream source. This > is because proxies do not handle data changing without changing the > filename. > > Warren Togami > wtogami at redhat.com Ok thanks, what I did was comment out the mirror list url, and just use the base url. I'll add those refresh patterns, but doesn't the second one effectively turn of caching of *.rpm? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From nathanael at gnat.ca Tue Jul 8 16:08:08 2008 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 08 Jul 2008 10:08:08 -0600 Subject: Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008 In-Reply-To: <1215498519.14769.1.camel@scrappy.miketc.com> References: <486A97A3.6090506@redhat.com> <1215498519.14769.1.camel@scrappy.miketc.com> Message-ID: <487390E8.4030002@gnat.ca> Mike Chambers wrote: > On Tue, 2008-07-01 at 13:46 -0700, John Poelstra wrote: > > Has anyone else received this email about 3-5 times now or more? Don't > know if it's my problem or mailing list/server problem? > Only once here. -- Nathanael d. Noblet Gnat Solutions, Inc T: 403.875.4613 From wtogami at redhat.com Tue Jul 8 16:09:44 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Jul 2008 12:09:44 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <48738DF9.4030209@mlbassoc.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> <48738DF9.4030209@mlbassoc.com> Message-ID: <48739148.5030706@redhat.com> Gary Thomas wrote: > Warren Togami wrote: >> Arthur Pemberton wrote: >>> >>> I wanted to try InstantMirror, but was in a rush. I just used a basic >>> squid setup. >>> >>> Are their any advantages of using it as a reverse mirror vs. regular >>> squid usage? >>> >> >> Regular squid wont be able to effectively cache if MirrorManager is >> telling you to use random mirrors. If you use MirrorManager you could >> receive the same local (reverse proxy) mirror as the first mirror >> every time if yum is used from your network block. >> >> refresh_pattern repodata/.*$ 0 0% 0 >> refresh_pattern .*rpm$ 0 0% 0 >> >> Also with any squid.conf you will need these lines in order to >> guarantee that your repodata and RPMS stay consistent with your >> upstream source. This is because proxies do not handle data changing >> without changing the filename. > > Since you seem to have this all figured out, could you share > your squid.conf? > > Thanks > Unfortunately my squid.conf is a bit too complex to such a point that I don't understand how it works anymore. The reverse proxy configuration part is also different between squid in RHEL and the newer squid versions in Fedora. Search around for the magic options... Warren From wtogami at redhat.com Tue Jul 8 16:12:02 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Jul 2008 12:12:02 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> Message-ID: <487391D2.40009@redhat.com> Arthur Pemberton wrote: >> >> refresh_pattern repodata/.*$ 0 0% 0 >> refresh_pattern .*rpm$ 0 0% 0 >> >> Also with any squid.conf you will need these lines in order to guarantee >> that your repodata and RPMS stay consistent with your upstream source. This >> is because proxies do not handle data changing without changing the >> filename. >> >> Warren Togami >> wtogami at redhat.com > > > Ok thanks, what I did was comment out the mirror list url, and just > use the base url. I'll add those refresh patterns, but doesn't the > second one effectively turn of caching of *.rpm? > > Not exactly. It checks with the source server on every request if the data changed, but it doesn't re-download the entire thing. The only way we could do this without checking the upstream source is if all filenames on the mirrors changed every time their contents change. This is possible and we considered this for repodata, but decided against it because it would have broke earlier clients. This is also currently not possible with the RPMS themselves. Hence the need for refresh_pattern rules. refresh_pattern images/.*$ 0 0% 0 I just realized that you probably want this additional rule to provide the same guarantees for stage2.img and other stuff in that directory. Warren Togami wtogami at redhat.com From kwizart at gmail.com Tue Jul 8 16:15:23 2008 From: kwizart at gmail.com (KH KH) Date: Tue, 8 Jul 2008 18:15:23 +0200 Subject: kernel build failures. In-Reply-To: References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> Message-ID: 2008/7/7 Thomas Moschny : > 2008/7/7 Nicolas Mailhot : >> >> Le Lun 7 juillet 2008 04:25, Bruno Wolff III a ?crit : >> >>> It would be nice if this was redesigned so that each package put its >>> data in a separate file rather than mixing stuff. >> >> That's mostly the case today. The catalog is just an index file with >> 1-line references to package-specific data > > But unless there's an easy way to cleanly rebuild this index from > scratch, that's still as bad as embedding (mixing) all data in one > single file. > > The DTDs/schemas are not found when not mentioned in the catalog, right? Does this problem has been solved ? I have this package failing: (even if i add : %if 0%{?fedora} > 9 BuildRequires: docbook-dtds %endif ) http://koji.fedoraproject.org/koji/taskinfo?taskID=702885 /builddir/build/BUILD/lcdproc-0.5.2/docs/lcdproc-dev/lcdproc-dev.docbook:12: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" > - Thomas > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fche at redhat.com Tue Jul 8 16:17:47 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 08 Jul 2008 12:17:47 -0400 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708071644.GA15324@amd.home.annexia.org> (Richard W. M. Jones's message of "Tue, 8 Jul 2008 08:16:44 +0100") References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> <20080708071644.GA15324@amd.home.annexia.org> Message-ID: "Richard W.M. Jones" writes: > [...] I said it's not a problem for the MinGW SIG (ie. Fedora), but > it is a problem for the libvirt project. So it is that important to you to permit someone to distribute proprietary libvirt-based applications that run *on windows*? Is providing this sort of enablement important to Fedora? - FChE From pemboa at gmail.com Tue Jul 8 16:22:42 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 8 Jul 2008 11:22:42 -0500 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <487391D2.40009@redhat.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> <487391D2.40009@redhat.com> Message-ID: <16de708d0807080922m3b6538b7s1a81161fa7c3fa15@mail.gmail.com> On Tue, Jul 8, 2008 at 11:12 AM, Warren Togami wrote: > Arthur Pemberton wrote: >>> >>> refresh_pattern repodata/.*$ 0 0% 0 >>> refresh_pattern .*rpm$ 0 0% 0 >>> >>> Also with any squid.conf you will need these lines in order to guarantee >>> that your repodata and RPMS stay consistent with your upstream source. >>> This >>> is because proxies do not handle data changing without changing the >>> filename. >>> >>> Warren Togami >>> wtogami at redhat.com >> >> >> Ok thanks, what I did was comment out the mirror list url, and just >> use the base url. I'll add those refresh patterns, but doesn't the >> second one effectively turn of caching of *.rpm? >> >> > > Not exactly. It checks with the source server on every request if the data > changed, but it doesn't re-download the entire thing. The only way we could > do this without checking the upstream source is if all filenames on the > mirrors changed every time their contents change. This is possible and we > considered this for repodata, but decided against it because it would have > broke earlier clients. This is also currently not possible with the RPMS > themselves. Hence the need for refresh_pattern rules. > > refresh_pattern images/.*$ 0 0% 0 > > I just realized that you probably want this additional rule to provide the > same guarantees for stage2.img and other stuff in that directory. > > Warren Togami > wtogami at redhat.com > Okay thanks, I had apparently not completely understood how refresh patterns were used, I am clearer now. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dpquigl at tycho.nsa.gov Tue Jul 8 16:11:18 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Tue, 08 Jul 2008 12:11:18 -0400 Subject: Do we have Deep Freeze/Clean Slate like tool? In-Reply-To: <20080708153854.GA7828@wolff.to> References: <20080708153854.GA7828@wolff.to> Message-ID: <1215533478.4199.4.camel@moss-terrapins.epoch.ncsc.mil> On Tue, 2008-07-08 at 10:38 -0500, Bruno Wolff III wrote: > On Tue, Jul 08, 2008 at 19:52:51 +0530, > lakshmi pathi wrote: > > Hi all, > > Recently i came across Deep Freeze/Clean slate in a linux forum.Do we > > have open source alternative to these tools? > > Is that really helpful tool for linux user? Please share your thoughts. > > Have you looked at xguest? Depending on exactly what you are doing it might > be suitable for your purpose. One note about customizing the profile is that > sabayon has a couple of bugs that prevent doing some types of customization. > But that may not be a show stopper for you. xguest is set up to do > unauthenticated logins. There might be problems with giving unauthenticated > access to the network, even if it is only through firefox. > I was looking through the xguest package and as of right now it seems like it is setup just to deal with one user. However I'm sure it could be adapted such that the xguest init script can take a user that it wants to turn into an xguest account. The xguest package is a confined SELinux user (xguest_u) with an init script and specialized configuration data. If the script can be modified to take the user name you could probably use it to make arbitrary home directories into xguest accounts. I'm sure Dan has more to say about this since he is the author of the xguest package. Dave From dcbw at redhat.com Tue Jul 8 16:27:12 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 08 Jul 2008 12:27:12 -0400 Subject: mobile broadband support In-Reply-To: <5256d0b0807080742v743c4912jc650919a8f550245@mail.gmail.com> References: <4872D782.3000002@verizon.net> <4873768F.2080100@verizon.net> <5256d0b0807080742v743c4912jc650919a8f550245@mail.gmail.com> Message-ID: <1215534432.17812.18.camel@localhost.localdomain> On Tue, 2008-07-08 at 15:42 +0100, Peter Robinson wrote: > >> (I believe the answer is that the signal strength requires card-specific > >> logic which isn't documented, so this isn't easy to implement) > >> > > I finally located an area in the wiki for this: > > https://fedoraproject.org/wiki/Features/NetworkManager-MobileBroadband > > > > "Signal strength while connected is not supported at this time because > > most cards use proprietary protocols to retrieve signal strength while > > connected." > > > > and this was for Fedora 9 release. So maybe some work will happen for > > Fedora 10 that would start to add signal strength display for these cards. > > I think part of the problem is that you need two serial ports/control > ports to be able to get signal at the same time as being connected and > not all cards have the two ports to do that. There's umtsmon but I'm > not sure it works at the same time as NetworkManager > > http://umtsmon.sourceforge.net/ Unfortunately, umtsmon doesn't do CDMA devices. So it won't work for Gerry. And further, the S720 is one of those cards that uses proprietary protocols to deliver signal strength on the additional tty devices. So unless somebody figures out the protocol, or Novatel opens up the protocol, you'll never be able to get signal strength out of the card under Linux. Recent Sierra cards, some Huwei, and most Option cards are able to deliver signal strength using normal AT commands, which we'll support soon in NetworkManager. But for most old Sierra cards and most Novatel cards, you are simply SOL. Dan From berrange at redhat.com Tue Jul 8 16:29:21 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jul 2008 17:29:21 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> <20080708071644.GA15324@amd.home.annexia.org> Message-ID: <20080708162921.GE13117@redhat.com> On Tue, Jul 08, 2008 at 12:17:47PM -0400, Frank Ch. Eigler wrote: > > "Richard W.M. Jones" writes: > > > [...] I said it's not a problem for the MinGW SIG (ie. Fedora), but > > it is a problem for the libvirt project. > > So it is that important to you to permit someone to distribute > proprietary libvirt-based applications that run *on windows*? > Is providing this sort of enablement important to Fedora? IMHO, yes. We've had alot of feedback that people really like the libraries we provide for managing virtualized Fedora / Linux hosts, and they'd like to make use of our libraries in their existing closed source management tools. Not having Windows support for our management tools is a show-stopper for many potential users though. So by providing libvirt client bits on Windows we enable more people to deploy & manage virtualized Fedora hosts. This will increase the number of people using Fedora and virtualization which is a good thing for the Fedora community. It also helps the libvirt community which becomes a defacto standard open source managment API across platforms, at a time when all other virt vendors would rather their users were locked into proprietry custom APIs & tools. If we only provided GPL'd libraries for libvirt on Windows they simply won't use libvirt or Fedora virtualization, pushing more people towards closed source virt solutuons like VMWare 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 seg at haxxed.com Tue Jul 8 16:44:17 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 8 Jul 2008 11:44:17 -0500 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> Message-ID: <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> 2008/7/6 Paulo Cavalcanti : > I am trying to fix the Load_Cycle_Count > bug that is increasing at a very fast pace each day > on my laptop running F8. Suddenly, I realized that apparently the > version of pm-utils for F9 has a kook to deal with it: > > 99hd-apm-restore.hook and > /etc/pm-utils-hd-apm-restore.conf > > > Why was not this ported to F8? > > The problem, as I understand, is quiet serious, > and can kill the drive in one or two years. Model Family: Western Digital Scorpio family Device Model: WDC WD600VE-11KWT0 Firmware Version: 01.03K01 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 357 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 8 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 4414 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 199 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 192 193 Load_Cycle_Count 0x0032 065 065 000 Old_age Always - 406672 194 Temperature_Celsius 0x0022 110 077 000 Old_age Always - 33 196 Reallocated_Event_Count 0x0032 199 199 000 Old_age Always - 1 F-cking great. I don't think this drive is even a year old, and it's up to 400000 already! And has reallocated sectors? This is a plain, un-tweaked F9 on an eMachines m6805, which is run entirely off AC since the battery is no good. Shouldn't we do something about this? It would be easy enough to automatically detect a rapidly increasing Load_Cycle_Count and alert the user. Or just fix it automagically. I just put '/sbin/hdparm -B 254 /dev/sda' into my rc.local to control the damage. I shouldn't have to do this. No finger pointing, the plain fact is Fedora should Just Work, no matter what retarded things the BIOS vendor or HD manufacturer does. We really do need some kind of thing set up to monitor SMART and alert the user via notification-daemon. I already had to replace the drive in this thing because the previous one got toasted due to a failed CPU heatsink roasting the whole system. It sure would have been nice to get a "Warning! Your hard drive appears to be overheating!" alert. From nicolas.mailhot at laposte.net Tue Jul 8 17:36:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 08 Jul 2008 19:36:35 +0200 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <487391D2.40009@redhat.com> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> <487391D2.40009@redhat.com> Message-ID: <1215538595.27196.3.camel@rousalka.okg> Le mardi 08 juillet 2008 ? 12:12 -0400, Warren Togami a ?crit : > The only way > we could do this without checking the upstream source is if all > filenames on the mirrors changed every time their contents change. This > is possible and we considered this for repodata, but decided against it > because it would have broke earlier clients. So repodata is condemned to be broken with proxies just because it was designed broken ? Please reconsider. There are many places in the world where you can only access trhough proxies (for good reasons) and yum can not really be used right now. Just autogenerate to sets of metadata and deprecate the proxy-unfriendly version after a few years. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From opensource at till.name Tue Jul 8 17:44:34 2008 From: opensource at till.name (Till Maas) Date: Tue, 8 Jul 2008 19:44:34 +0200 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> Message-ID: <200807081944.50114.opensource@till.name> On Tuesday 08 July 2008 18:44:17 Callum Lerwick wrote: > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE > 193 Load_Cycle_Count 0x0032 065 065 000 Old_age > Always - 406672 > F-cking great. I don't think this drive is even a year old, and it's > up to 400000 already! And has reallocated sectors? This is a plain, Are you sure that you know what the value means? My drive reports this: 193 Load_Cycle_Count 0x0032 071 071 000 Old_age Always - 2990488599305 I do not believe that the value is exactly the number of load cycles that my drive already had. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Jul 8 18:08:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 08 Jul 2008 14:08:13 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <1215538595.27196.3.camel@rousalka.okg> References: <51813.172.17.8.175.1205188894.squirrel@students.iiit.ac.in> <544eb990803110408qe72e990t29a71df1c6307da@mail.gmail.com> <53994.172.17.8.175.1205253627.squirrel@students.iiit.ac.in> <487366B8.2060306@iinet.net.au> <1215522969.4888.35.camel@roadrunner.itnet.am> <48738459.4030808@redhat.com> <16de708d0807080825s5fa8dcfap31e6a6b4a4cfa1@mail.gmail.com> <48738C59.4000907@redhat.com> <16de708d0807080902w5cc27924o13f350175b257eae@mail.gmail.com> <487391D2.40009@redhat.com> <1215538595.27196.3.camel@rousalka.okg> Message-ID: <1215540493.21388.17.camel@localhost.localdomain> On Tue, 2008-07-08 at 19:36 +0200, Nicolas Mailhot wrote: > Le mardi 08 juillet 2008 ? 12:12 -0400, Warren Togami a ?crit : > > > The only way > > we could do this without checking the upstream source is if all > > filenames on the mirrors changed every time their contents change. This > > is possible and we considered this for repodata, but decided against it > > because it would have broke earlier clients. > > So repodata is condemned to be broken with proxies just because it was > designed broken ? Please reconsider. There are many places in the world > where you can only access trhough proxies (for good reasons) and yum can > not really be used right now. > > Just autogenerate to sets of metadata and deprecate the proxy-unfriendly > version after a few years. Repodata will very shortly have a unique name to it, rather than a static name. repomd.xml will remain unchanged though. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 chasd at silveroaks.com Tue Jul 8 18:20:18 2008 From: chasd at silveroaks.com (chasd) Date: Tue, 8 Jul 2008 13:20:18 -0500 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <20080708160007.1CDD68E092C@hormel.redhat.com> References: <20080708160007.1CDD68E092C@hormel.redhat.com> Message-ID: <3429E78A-7EC9-4C61-A9A7-AA36CAE9FCCD@silveroaks.com> Warren Togami wrote: > Arthur Pemberton wrote: >> >> I wanted to try InstantMirror, but was in a rush. I just used a basic >> squid setup. >> >> Are their any advantages of using it as a reverse mirror vs. regular >> squid usage? >> > > Regular squid wont be able to effectively cache if MirrorManager is > telling you to use random mirrors. If you use MirrorManager you could > receive the same local (reverse proxy) mirror as the first mirror > every > time if yum is used from your network block. > > refresh_pattern repodata/.*$ 0 0% 0 > refresh_pattern .*rpm$ 0 0% 0 > > Also with any squid.conf you will need these lines in order to > guarantee > that your repodata and RPMS stay consistent with your upstream source. > This is because proxies do not handle data changing without > changing the > filename. Um, from reading the comments in the squid config file relating to "refresh_pattern," don't those settings in effect negate caching, since that will always return STALE ? From the squid config file : > # Basically a cached object is: > # > # FRESH if expires < now, else STALE > # STALE if age > max > # FRESH if lm-factor < percent, else STALE > # FRESH if age < min > # else STALE Wouldn't you want squid to keep a file at least a couple of hours, if not a day ? Settings I use to better cache OS updates using squid : # Use more than the default 8 MB of RAM cache_mem 128 MB # Use 8 MB for the largest object in RAM cache instead of 8KB maximum_object_size_in_memory 8192 KB A large percentage of RPMs are less than 8 MB # Use 30GB for the cache instead of the default 100 MB cache_dir aufs /var/spool/squid 30000 48 512 If you have an update run that totals close to the default 100 MB, and you have multiple clients set to update via a cron script, the cache will thrash if you don't set that higher. Those settings above are hardware dependent, if you have more, let squid use more I also use an ext2 partition for where the cache lives since it seems the journaling of ext3 can impact squid performance, particularly on older PPC hardware kjournald will keep rising to the first line of "top" and squid can block on I / O. If the fs gets mangled, only the squid cache is on it so I can wipe it and re-init the cache # Use maximum object size of 120 MB not 4 MB - gotta cache openoffice fer sure. maximum_object_size 122880 KB That said, I use InstantMirror with a custom repo file for our Fedora needs. Charles Dostale From wtogami at redhat.com Tue Jul 8 18:34:03 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 08 Jul 2008 14:34:03 -0400 Subject: InstantMirror Redesign / current best /simplest way to achieve In-Reply-To: <3429E78A-7EC9-4C61-A9A7-AA36CAE9FCCD@silveroaks.com> References: <20080708160007.1CDD68E092C@hormel.redhat.com> <3429E78A-7EC9-4C61-A9A7-AA36CAE9FCCD@silveroaks.com> Message-ID: <4873B31B.2010705@redhat.com> chasd wrote: >> refresh_pattern repodata/.*$ 0 0% 0 >> refresh_pattern .*rpm$ 0 0% 0 >> >> Also with any squid.conf you will need these lines in order to guarantee >> that your repodata and RPMS stay consistent with your upstream source. >> This is because proxies do not handle data changing without changing the >> filename. > > Um, from reading the comments in the squid config file relating to > "refresh_pattern," don't those settings in effect negate caching, > since that will always return STALE ? From the squid config file : This was already discussed earlier in this thread. This doesn't expire the object from the cache entirely. It does check the upstream source for changes but it doesn't need to download the entire file again if it did not change. > If you have an update run that totals close to the default 100 MB, > and you have multiple clients set to update via a cron script, > the cache will thrash if you don't set that higher. Right, you need to adjust the cache_dir size and maximum object size. I personally use a maximum object size of like 4GB because my reverse proxy is used *only* for a Fedora mirror. > That said, I use InstantMirror with a custom repo file for our Fedora > needs. Note, InstantMirror behaves exactly as described above with the squid refresh_pattern rule. InstantMirror checks the original source files for changes upon every client request. Due to repodata/*, images/* and sometimes *.rpm files changing without their contents changing, running a caching proxy without such rules causes you to occasionally have metadata mismatch failures until the proxy server naturally refreshes itself sometime later. Warren Togami wtogami at redhat.com From erik at vanpienbroek.nl Tue Jul 8 19:09:05 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Tue, 08 Jul 2008 21:09:05 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708151342.GB16863@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> Message-ID: <1215544145.10640.22.camel@alguno.terneuzen.openftd.org> Op dinsdag 08-07-2008 om 16:13 uur [tijdzone +0100], schreef Richard W.M. Jones: > I think it's reasonable to have a 'sample' spec file snippet for > existing maintainers to use & modify when they feel they want to add > MinGW support. I'll give it a go with some existing libraries to see > what they would look like. First of all, great initiative! This sure looks interesting for me, because the packages I develop also need to run on Win32 environments and I hate to keep rebooting. I've just read your draft packaging guidelines and I think there also should be a pkg-config specific part. A lot of libraries use pkg-config nowadays. In order to prevent autoconf/configure scripts from using the host system headers and libraries, some additional preparation is required. The man-page of pkg-config says the following with regard to overriding the default search path: "By default, pkg-config looks in the directory prefix/lib/pkgconfig for these files; it will also look in the colon-separated (on Windows, semicolon-separated) list of directories specified by the PKG_CONFIG_PATH environment variable." So if a mingw package requires a library which uses pkg-config, the spec file should contain 'PKG_CONFIG_PATH= %{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig' right before calling the ./configure script. However, there's still another potential problem: according to the man-page of pkg-config, the default path (prefix/lib/pkgconfig) is also searched, which still can lead to conflicts. Maybe it is an idea to patch pkg-config so that depending on some environment variable the default path isn't searched. Regards, Erik van Pienbroek From gdk at redhat.com Tue Jul 8 19:08:33 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 8 Jul 2008 15:08:33 -0400 (EDT) Subject: Fedora, meet OLPC. OLPC, meet Fedora. Message-ID: Did you know that the OLPC project is the largest single "customer" of Fedora in the entire world? The rumours of OLPC's death have been greatly exaggerated. Despite some unfortunate statements by the project's erstwhile CEO, the OLPC project is still *extremely* focused on succeeding in its noble goal -- the education of the world's children -- with the use of free software as the central component of their software strategy. And they are, in fact, succeeding, even though the open source community has largely turned its collective back on that success. Which is, I think, a shame. Let me share some numbers with you. They might surprise you. I know they surprised me when I heard them a few weeks ago at FUDCon. OLPC has shipped over 300,000 units to kids around the world. They plan to ship at least another 50,000 more each month, and very likely more than that. It's entirely possible that by the end of 2008, there will be a million OLPC systems deployed worldwide. Of those systems, 100% of them currently run Fedora, and 0% of them currently run Windows -- despite the press clippings you may have read. The OLPC project is based on Fedora. The engineers at OLPC have invested thousands of person-hours in making Fedora a successful base for OLPC deployments. Fedora is now, and will continue to be, the base operating system for the OLPC project. Period. It's time for the Fedora community to step up and represent. * * * There will be many opportunities for members of the Fedora community and the OLPC communities to help one another in the coming months. I intend to spend most of my time identifying those opportunities and helping to making them happen. The first opportunities are for the Fedora packagers. This work can be done right now, today. Understandably, the OLPC folks want to focus their efforts on the challenges that are unique to the OLPC project. Which means that they should be shedding all work that can more easily be handled by others. Package maintenance is a perfect example of this kind of work. Here is a list of packages that are either badly needed by OLPC: http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist These packages are either unavailable in Fedora, or are currently being maintained, poorly, by overworked OLPC engineers who can't invest enough time to do them justice. There are lots of simple issues that even novice packagers could handle. Missing or broken dependencies. Creation of dead-simple activity packages. And so on. If there's one thing that Fedora community engineers do exceptionally well, it's package maintenance. If every current Fedora packager volunteered to own *one single package* that is crucial to OLPC, we would immediately free the core OLPC team for much more strategic work. It's a big, immediate win, and the entire OLPC team will be delighted to receive your help. Fedora packagers: please consider adopting one of these packages and giving it a loving home. I will keep asking. :) --g From promac at gmail.com Tue Jul 8 19:13:41 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 8 Jul 2008 16:13:41 -0300 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <200807081944.50114.opensource@till.name> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> Message-ID: <68720af30807081213y4cf750e2r5bc85436c834c5a5@mail.gmail.com> 2008/7/8 Till Maas : > On Tuesday 08 July 2008 18:44:17 Callum Lerwick wrote: > > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > > UPDATED WHEN_FAILED RAW_VALUE > > > 193 Load_Cycle_Count 0x0032 065 065 000 Old_age > > Always - 406672 > > > F-cking great. I don't think this drive is even a year old, and it's > > up to 400000 already! And has reallocated sectors? This is a plain, > > Are you sure that you know what the value means? My drive reports this: > > 193 Load_Cycle_Count 0x0032 071 071 000 Old_age > Always - 2990488599305 > > I do not believe that the value is exactly the number of load cycles that > my > drive already had. > My laptop is less than a month old, and it is running F8. 5 Reallocated_Sector_Ct 0x0033 100 100 024 Pre-fail Always - 8589934592000 9 Power_On_Minutes 0x0032 100 100 000 Old_age Always - 167h+02m 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 89 191 G-Sense_Error_Rate 0x0012 100 100 000 Old_age Always - 2 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 7 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 5325 The number of reallocated sectors is 000 (forget the high order bits for fujtisu). The load cycle 5325. This number is correct. When I started to use hdparm in rc.local and in /usr/lib/pm-utils/sleep.d/ (the parameter is lost when returning from hibernation and suspend mode), it just increments a single unit every time I shut down or suspend. This is the way it should be in my opinion. According to this post http://www.theinquirer.net/gb/inquirer/news/2007/10/31/ubuntu-eats-lappy-hard-drive (look at the end) the reason is that ext3 commits each 5 seconds, awaking the disk. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Tue Jul 8 19:32:26 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 20:32:26 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708151342.GB16863@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> Message-ID: <20080708193226.GA17810@amd.home.annexia.org> OK, here is a 'fragment'. What I have done is to take the current GnuTLS package from Fedora Rawhide and patch it so that it generates a mingw-gnutls subpackage. Attached to this message is the patch, and below I discuss the various parts of the patch. If you want to see the original vs modified spec files, go here: http://hg.et.redhat.com/misc/fedora-mingw--devel?cmd=manifest;manifest=91a808c59de63589367c7bd9750da1fca342c529;path=/gnutls-fragment/ Discussion of the patch follows below. Rich. +%define __os_install_post /usr/lib/rpm/brp-compress %{nil} Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't work, but actually corrupts the files. Therefore we must disable stripping. I'd love to know how to force RPM to either ignore files in certain directories, or to call the correct strip binary on them. The original SRPMs that I was working with contained a very long and hairy bit of code which apparently did this, but I wasn't daring enough to include it. +%package -n mingw-gnutls +Summary: MinGW Windows cross-compile of %{name} package +Group: Development/Libraries + +BuildRequires: mingw-gcc +BuildRequires: mingw-binutils +BuildRequires: mingw-libgpg-error +BuildRequires: mingw-libgcrypt + +Requires: mingw-runtime +Requires: mingw-libgpg-error +Requires: mingw-libgcrypt Main package definition. Note that we don't have any automatic find-requires working at the moment, so we need to define dependent packages explicitly. %build +mkdir build +pushd build +echo '../configure "$@"' > configure; chmod +x configure %configure --with-libtasn1-prefix=%{_prefix} \ --with-included-libcfg \ --disable-srp-authentication make +popd + +mkdir i686-pc-mingw32 +pushd i686-pc-mingw32 +CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector" \ +../configure \ + --build=%_build \ + --host=i686-pc-mingw32 \ + --prefix=%{_prefix}/i686-pc-mingw32/sys-root/mingw \ + --disable-cxx \ + --with-included-libtasn1 \ + --with-included-libcfg \ + --disable-srp-authentication +make +popd I've split the build by configuring & building in two subdirectories, ie. the general pattern is: pushd build ../configure &c popd pushd i686-pc-mingw32 ../configure --host=i686-pc-mingw32 &c popd Note the hack to make %configure work in a subdirectory. Any easier way? +%files -n mingw-gnutls +%defattr(-,root,root) +%{_prefix}/i686-pc-mingw32/sys-root/mingw/bin/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/include/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/aclocal/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/info/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man1/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man3/* This is the filelist for the mingw-specific files. -- 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 -------------- next part -------------- --- gnutls-original.spec 2008-07-08 18:45:02.000000000 +0100 +++ gnutls.spec 2008-07-08 20:08:19.000000000 +0100 @@ -1,7 +1,12 @@ +# XXX This prevents binaries from being stripped. Using ordinary 'strip' +# on a MinGW library actually corrupts the library, hence we must disable +# this action. However we would still like Fedora binaries to be stripped. +%define __os_install_post /usr/lib/rpm/brp-compress %{nil} + Summary: A TLS protocol implementation Name: gnutls Version: 2.4.1 -Release: 1%{?dist} +Release: 2%{?dist} # The libgnutls library is LGPLv2+, utilities and remaining libraries are GPLv3+ License: GPLv3+ and LGPLv2+ Group: System Environment/Libraries @@ -33,6 +38,20 @@ Group: Applications/System Requires: %{name} = %{version}-%{release} +%package -n mingw-gnutls +Summary: MinGW Windows cross-compile of %{name} package +Group: Development/Libraries + +BuildRequires: mingw-gcc +BuildRequires: mingw-binutils +BuildRequires: mingw-libgpg-error +BuildRequires: mingw-libgcrypt + +Requires: mingw-runtime +Requires: mingw-libgpg-error +Requires: mingw-libgcrypt + + %description GnuTLS is a project that aims to develop a library which provides a secure layer, over a reliable transport layer. Currently the GnuTLS library implements @@ -52,6 +71,14 @@ This package contains command line TLS client and server and certificate manipulation tools. +%description -n mingw-gnutls +GnuTLS is a project that aims to develop a library which provides a secure +layer, over a reliable transport layer. Currently the GnuTLS library implements +the proposed standards by the IETF's TLS working group. +This package contains a MinGW Windows cross-compiled library so that +you can build programs that depend on GnuTLS library for Windows from +a Fedora host. + %prep %setup -q %patch1 -p1 -b .nosrp @@ -61,13 +88,32 @@ done %build +mkdir build +pushd build +echo '../configure "$@"' > configure; chmod +x configure %configure --with-libtasn1-prefix=%{_prefix} \ --with-included-libcfg \ --disable-srp-authentication make +popd + +mkdir i686-pc-mingw32 +pushd i686-pc-mingw32 +CFLAGS="$RPM_OPT_FLAGS -fno-stack-protector" \ +../configure \ + --build=%_build \ + --host=i686-pc-mingw32 \ + --prefix=%{_prefix}/i686-pc-mingw32/sys-root/mingw \ + --disable-cxx \ + --with-included-libtasn1 \ + --with-included-libcfg \ + --disable-srp-authentication +make +popd %install rm -fr $RPM_BUILD_ROOT +pushd build %makeinstall rm -f $RPM_BUILD_ROOT%{_bindir}/srptool rm -f $RPM_BUILD_ROOT%{_bindir}/gnutls-srpcrypt @@ -78,9 +124,16 @@ rm -f $RPM_BUILD_ROOT%{_infodir}/dir rm -f $RPM_BUILD_ROOT%{_libdir}/*.la %find_lang %{name} +popd + +pushd i686-pc-mingw32 +make DESTDIR=$RPM_BUILD_ROOT install +popd %check +pushd build make check +popd %clean rm -fr $RPM_BUILD_ROOT @@ -99,7 +152,7 @@ /sbin/install-info --delete %{_infodir}/gnutls.info.gz %{_infodir}/dir || : fi -%files -f %{name}.lang +%files -f build/%{name}.lang %defattr(-,root,root,-) %{_libdir}/*.so.* %doc COPYING COPYING.LIB README AUTHORS @@ -122,7 +175,20 @@ %{_bindir}/gnutls* %{_mandir}/man1/* +%files -n mingw-gnutls +%defattr(-,root,root) +%{_prefix}/i686-pc-mingw32/sys-root/mingw/bin/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/lib/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/include/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/aclocal/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/info/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man1/* +%{_prefix}/i686-pc-mingw32/sys-root/mingw/share/man/man3/* + %changelog +* Tue Jul 8 2008 Richard W.M. Jones 2.4.1-2 +- Build mingw-gnutls subpackage. + * Tue Jul 1 2008 Tomas Mraz 2.4.1-1 - new upstream version - correct the license tag From rjones at redhat.com Tue Jul 8 19:34:00 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 20:34:00 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <1215544145.10640.22.camel@alguno.terneuzen.openftd.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <1215544145.10640.22.camel@alguno.terneuzen.openftd.org> Message-ID: <20080708193400.GB17810@amd.home.annexia.org> On Tue, Jul 08, 2008 at 09:09:05PM +0200, Erik van Pienbroek wrote: > I've just read your draft packaging guidelines and I think there also > should be a pkg-config specific part. A lot of libraries use pkg-config > nowadays. In order to prevent autoconf/configure scripts from using the > host system headers and libraries, some additional preparation is > required. [...] Yes, I think you're right about this. A good test case will be libvirt because at the moment the configure script in libvirt doesn't find the correct libxml2. (It finds the system libxml2, not the MinGW one). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jspaleta at gmail.com Tue Jul 8 19:55:11 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 8 Jul 2008 11:55:11 -0800 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> On Tue, Jul 8, 2008 at 11:08 AM, Greg Dekoenigsberg wrote: > These packages are either unavailable in Fedora, or are currently being > maintained, poorly, by overworked OLPC engineers who can't invest enough > time to do them justice. There are lots of simple issues that even novice > packagers could handle. Missing or broken dependencies. Creation of > dead-simple activity packages. And so on. I think we need an overriding goal. Can we get a Fedora Sugar Desktop Spin for standard pc hardware on the map and a SIG organized around that effort? Would that put the right people together in the same headspace to start working on packaging activities? -jef From pbrobinson at gmail.com Tue Jul 8 20:01:13 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 8 Jul 2008 21:01:13 +0100 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> Message-ID: <5256d0b0807081301k285a958djfd189177e8b322b3@mail.gmail.com> On Tue, Jul 8, 2008 at 8:55 PM, Jeff Spaleta wrote: > On Tue, Jul 8, 2008 at 11:08 AM, Greg Dekoenigsberg wrote: >> These packages are either unavailable in Fedora, or are currently being >> maintained, poorly, by overworked OLPC engineers who can't invest enough >> time to do them justice. There are lots of simple issues that even novice >> packagers could handle. Missing or broken dependencies. Creation of >> dead-simple activity packages. And so on. > > I think we need an overriding goal. Can we get a Fedora Sugar Desktop > Spin for standard pc hardware on the map and a SIG organized around > that effort? Would that put the right people together in the same > headspace to start working on packaging activities? A SIG wiki page in general would be good with things like a kickstart file to build the client version and the server version. It would allow easy testing for things like depedency creep for core packages and the like. Peter From walters at verbum.org Tue Jul 8 20:23:28 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 8 Jul 2008 16:23:28 -0400 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: On Tue, Jul 8, 2008 at 3:08 PM, Greg Dekoenigsberg wrote: > ...that can more easily be handled by others. or: ...that should be automated. There are plenty of developers working on non-OLPC things too that don't want to waste time copying and pasting things from the wiki, creating a hand summarization of the upstream website that gets stale, etc. to "package" something. We should look at every single step that creating a software package with a standard build system (autotools or whatever) requires beyond the upstream URL. For example, one of the OLPC packages there has a hand-rolled Makefile to sed specfiles: http://dev.laptop.org/git?p=projects/olpc-netutils;a=blob;f=Makefile.fedora;h=eb672a90e47ee7ed520b7431037ab7d502599be2;hb=master -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at when.com Tue Jul 8 20:58:20 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Tue, 08 Jul 2008 22:58:20 +0200 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <5256d0b0807081301k285a958djfd189177e8b322b3@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> <5256d0b0807081301k285a958djfd189177e8b322b3@mail.gmail.com> Message-ID: <4873D4EC.1050204@when.com> Peter Robinson wrote: > On Tue, Jul 8, 2008 at 8:55 PM, Jeff Spaleta wrote: >> On Tue, Jul 8, 2008 at 11:08 AM, Greg Dekoenigsberg wrote: >>> These packages are either unavailable in Fedora, or are currently being >>> maintained, poorly, by overworked OLPC engineers who can't invest enough >>> time to do them justice. There are lots of simple issues that even novice >>> packagers could handle. Missing or broken dependencies. Creation of >>> dead-simple activity packages. And so on. >> I think we need an overriding goal. Can we get a Fedora Sugar Desktop >> Spin for standard pc hardware on the map and a SIG organized around >> that effort? Would that put the right people together in the same >> headspace to start working on packaging activities? > > A SIG wiki page in general would be good with things like a kickstart > file to build the client version and the server version. It would > allow easy testing for things like depedency creep for core packages > and the like. > > Peter I just wanted to mention [1] and [2]: In our last meeting (which took already place some time ago, maybe we should have one very soon), the Education SIG talked about the possibility of having a sugar-based education spin - [1] is the log. I have drawn up a roadmap [2], which also lists that possibility. At the time we had this meeting, we did some testing, but there were quite few Sugar / OLPC packages in Fedora... maybe all this helps to improve the situation there. CU Sebastian [1] http://fedoraproject.org/wiki/SIGs/Education/Meetings/2008-05-09 [2] http://fedoraproject.org/wiki/SIGs/Education/Roadmap From kwade at redhat.com Tue Jul 8 21:30:58 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 08 Jul 2008 14:30:58 -0700 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <1215463202.5070.12.camel@kennedy> References: <1215463202.5070.12.camel@kennedy> Message-ID: <1215552658.3142.243.camel@calliope.phig.org> On Mon, 2008-07-07 at 16:40 -0400, Brian Pepple wrote: > Hi all, > > This is a reminder that the nomination period for the upcoming FESCo > election is currently underway, and lasts until July 13th, 2008 0:00 > UTC. If you wish to run for FESCo, please place your nomination on this > page in the wiki: > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Are you interested in trying to do open nominations this time? That is, allow people to nominate someone else. Naturally, that person would have to accept, signaled partially by filling out their nomination page. - Karsten > For more information regarding the election, please refer to: > http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections > > Thanks, > /B > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue Jul 8 21:56:45 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 Jul 2008 17:56:45 -0400 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-07-03 In-Reply-To: <20080707163443.A8909@humbolt.us.dell.com> References: <20080707163443.A8909@humbolt.us.dell.com> Message-ID: <1215554205.3214.80.camel@localhost.localdomain> On Mon, 2008-07-07 at 16:34 -0500, Matt Domsch wrote: > spot: R-RScaLAPACK,blacs,scalapack,xsupplicant Fixed these: R-RScaLAPACK-0.5.1-15.fc10 blacs-1.1-29.fc10 scalapack-1.7.5-3.fc10 xsupplicant-1.2.8-8.fc10 Folks playing along at home should note the following: - lam moved its libraries and headers to a new location - iwlib.h conflicts with a lot of other kernel headers now (but is much more self sufficient in userspace) ~spot From dennis at ausil.us Tue Jul 8 21:49:38 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 8 Jul 2008 16:49:38 -0500 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <200807081657.57857.dennis@ausil.us> On Tuesday 08 July 2008, Greg Dekoenigsberg wrote: > Did you know that the OLPC project is the largest single "customer" of > Fedora in the entire world? > > The rumours of OLPC's death have been greatly exaggerated. Despite some > unfortunate statements by the project's erstwhile CEO, the OLPC project is > still *extremely* focused on succeeding in its noble goal -- the education > of the world's children -- with the use of free software as the central > component of their software strategy. And they are, in fact, succeeding, > even though the open source community has largely turned its collective > back on that success. Which is, I think, a shame. > > Let me share some numbers with you. They might surprise you. I know they > surprised me when I heard them a few weeks ago at FUDCon. > > OLPC has shipped over 300,000 units to kids around the world. They plan to > ship at least another 50,000 more each month, and very likely more than > that. It's entirely possible that by the end of 2008, there will be a > million OLPC systems deployed worldwide. > > Of those systems, 100% of them currently run Fedora, and 0% of them > currently run Windows -- despite the press clippings you may have read. > > The OLPC project is based on Fedora. The engineers at OLPC have invested > thousands of person-hours in making Fedora a successful base for OLPC > deployments. Fedora is now, and will continue to be, the base operating > system for the OLPC project. Period. > > It's time for the Fedora community to step up and represent. > > * * * > > There will be many opportunities for members of the Fedora community and > the OLPC communities to help one another in the coming months. I intend to > spend most of my time identifying those opportunities and helping to > making them happen. > > The first opportunities are for the Fedora packagers. This work can be > done right now, today. > > Understandably, the OLPC folks want to focus their efforts on the > challenges that are unique to the OLPC project. Which means that they > should be shedding all work that can more easily be handled by others. > Package maintenance is a perfect example of this kind of work. > > Here is a list of packages that are either badly needed by OLPC: > > http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist > > These packages are either unavailable in Fedora, or are currently being > maintained, poorly, by overworked OLPC engineers who can't invest enough > time to do them justice. There are lots of simple issues that even novice > packagers could handle. Missing or broken dependencies. Creation of > dead-simple activity packages. And so on. > > If there's one thing that Fedora community engineers do exceptionally > well, it's package maintenance. If every current Fedora packager > volunteered to own *one single package* that is crucial to OLPC, we would > immediately free the core OLPC team for much more strategic work. It's a > big, immediate win, and the entire OLPC team will be delighted to receive > your help. > > Fedora packagers: please consider adopting one of these packages and > giving it a loving home. I will keep asking. :) Another thing that would be really good to have that ive not gotten to is adding support to livecd-tools to make jffs2 images. right now OLPC is using pilgrim to create its images. I would like to see that changed. there is no kickstart file for the xo images posted because one doesn't exist. Ill make sure that Martin posts the kickstart files for the school server. -- Dennis Gilmore -------------- 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 martin.langhoff at gmail.com Tue Jul 8 22:23:50 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 8 Jul 2008 19:23:50 -0300 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <200807081657.57857.dennis@ausil.us> References: <200807081657.57857.dennis@ausil.us> Message-ID: <46a038f90807081523t1b5faaf0tb39a9cfc38d95726@mail.gmail.com> 2008/7/8 Dennis Gilmore : > Ill make sure that Martin posts the kickstart files for the school server. Hola! The latest kickstart is here: http://dev.laptop.org/git?p=projects/xs-livecd;a=tree The SchoolServer (aka XS) is driven by a metapackage called xs-pkgs, the latest one at... http://dev.laptop.org/git?p=projects/xs-pkgs;a=tree And some (nasty!) configuration overrides done with http://dev.laptop.org/git?p=projects/xs-config;a=tree cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From lfarkas at lfarkas.org Tue Jul 8 22:27:11 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 09 Jul 2008 00:27:11 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708144640.GA16785@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> Message-ID: <4873E9BF.8060306@lfarkas.org> Richard W.M. Jones wrote: > On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote: >> On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote: >>> I've got a self-building, mostly working set of Fedora packages for >>> the MinGW cross-compiler (no optional libraries yet). You can get the >>> spec files and instructions by doing: >>> >>> hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel >> What primarily concerns me is that plan around keeping this in sync >> with patches/updates to the main gcc, binutils, libpng, libgcrypt, >> gnutls, etc RPMS already in Fedora. >> >> The idea of maintaining 2 near identical specs & builds for all these >> packages isn't that nice, particularly since many of these are security >> sensitive packages > > So there's a bit of confusion going around, partly my own. > > Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408) > starts with a forked version of binutils maintained by mingw. They > have their own release schedule for this so I'm not sure how viable it > is to have a single binutils SPEC file generating both the normal > binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether > or not the Fedora binutils maintainer is even interested in this). > > Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts > from plain gcc 4.3.1 source, so combining these into Fedora's gcc > package might be more hopeful. However there are some nasty > dependencies (mingw-runtime and mingw-w32api, neither of which can be > built ab initio because of circular dependencies) and I suspect that > any time there is any sort of mingw related trouble with this package, > the gcc-mingw subpackage will be the first to be dropped. I don't > want this. > > As for the remainder we get into asking question like -- should we > generate the mingw-gnutls library (as an example) from the main gnutls > SPEC file? There are going to be dozens of such libraries and we'll > have to coordinate with a large number of existing Fedora contributors > to make this happen. i hope you see these packages: http://mirzam.it.vu.nl/mingw/ i create packages based on these rpms for rhel too and used them for years. packages here: http://www.lfarkas.org/linux/packages/centos/5/ -- Levente "Si vis pacem para bellum!" From wart at kobold.org Tue Jul 8 22:32:36 2008 From: wart at kobold.org (Michael Thomas) Date: Tue, 08 Jul 2008 15:32:36 -0700 Subject: Setting up a Koji server Message-ID: <4873EB04.8040002@kobold.org> After 2 years of bitter complaining, I think I'm finally starting to convince our group's primary grid middleware provider to offer rpms as an alternative to the current ass-backwards packaging tool. The provider has ~360 packages for a bunch of things that are already in Fedora (like syslog-ng, tomcat, squid), but also many things that unforutnately can't be part of Fedora due to licensing restrictions. Obviously it would be best to use the native Fedora/RHEL/EPEL packages where possible, submit the missing OSS tools to Fedora/EPEL, and only repackage the OSS-challenged tools. I'll be meeting with this provider later this week to discuss some ideas to make sure this migration is as painless as possible. One of the things that I think they would benefit greatly from is a local koji installation. Is there any documentation on what it takes to set up an full koji environment with builders for 32- and 64-bit RHEL4, RHEL5, and Fedora, as well as configuring CVS to work with Koji? Regards, --Wart From seg at haxxed.com Tue Jul 8 22:49:33 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 8 Jul 2008 17:49:33 -0500 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <200807081944.50114.opensource@till.name> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> Message-ID: <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> 2008/7/8 Till Maas : > Are you sure that you know what the value means? My drive reports this: Yes I've monitored it, it increments every few seconds when the system is idle. If I do something to keep the disk active, it does not increment. If I set the power save level up to 254, it stops incrementing. I'm certain the value is accurate. > 193 Load_Cycle_Count 0x0032 071 071 000 Old_age > Always - 2990488599305 > > I do not believe that the value is exactly the number of load cycles that my > drive already had. Google the interwebs for more information. Some drives seem to report impossibly high, thus completely bogus numbers. It would appear yours is one of them. From bpepple at fedoraproject.org Tue Jul 8 23:12:08 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 08 Jul 2008 19:12:08 -0400 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <1215552658.3142.243.camel@calliope.phig.org> References: <1215463202.5070.12.camel@kennedy> <1215552658.3142.243.camel@calliope.phig.org> Message-ID: <1215558728.6976.14.camel@kennedy> On Tue, 2008-07-08 at 14:30 -0700, Karsten 'quaid' Wade wrote: > Are you interested in trying to do open nominations this time? > > That is, allow people to nominate someone else. Naturally, that person > would have to accept, signaled partially by filling out their nomination > page. FESCo did that in earlier elections, and we had people that we're nominated by someone else, and then after being elected decided they didn't want to serve on FESCo. If we can avoid that from occurring again, I don't have any objections. Does anyone else on FESCo have an opinion on this? Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From moe at blagblagblag.org Tue Jul 8 23:13:00 2008 From: moe at blagblagblag.org (jeff) Date: Tue, 08 Jul 2008 20:13:00 -0300 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <4873F47C.8030802@blagblagblag.org> Greg Dekoenigsberg wrote: > Here is a list of packages that are either badly needed by OLPC: > > http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist Some squeak packages here already for starters: http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-image-3.8.6665-2.fc9.src.rpm http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-sources-3.9-1.fc9.src.rpm http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-vm-3.10-1.2.fc9.src.rpm -Jeff From wart at kobold.org Tue Jul 8 23:16:27 2008 From: wart at kobold.org (Michael Thomas) Date: Tue, 08 Jul 2008 16:16:27 -0700 Subject: Setting up a Koji server In-Reply-To: <4873EB04.8040002@kobold.org> References: <4873EB04.8040002@kobold.org> Message-ID: <4873F54B.8090908@kobold.org> Michael Thomas wrote: > After 2 years of bitter complaining, I think I'm finally starting to > convince our group's primary grid middleware provider to offer rpms as > an alternative to the current ass-backwards packaging tool. The > provider has ~360 packages for a bunch of things that are already in > Fedora (like syslog-ng, tomcat, squid), but also many things that > unforutnately can't be part of Fedora due to licensing restrictions. > Obviously it would be best to use the native Fedora/RHEL/EPEL packages > where possible, submit the missing OSS tools to Fedora/EPEL, and only > repackage the OSS-challenged tools. > > I'll be meeting with this provider later this week to discuss some ideas > to make sure this migration is as painless as possible. One of the > things that I think they would benefit greatly from is a local koji > installation. Is there any documentation on what it takes to set up an > full koji environment with builders for 32- and 64-bit RHEL4, RHEL5, and > Fedora, as well as configuring CVS to work with Koji? This is where I tell myself to RTFW: http://fedoraproject.org/wiki/Koji/ServerHowTo --Wart From jspaleta at gmail.com Tue Jul 8 23:22:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 8 Jul 2008 15:22:54 -0800 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <5256d0b0807081301k285a958djfd189177e8b322b3@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> <5256d0b0807081301k285a958djfd189177e8b322b3@mail.gmail.com> Message-ID: <604aa7910807081622l6999292g5f62156c322ad7f8@mail.gmail.com> On Tue, Jul 8, 2008 at 12:01 PM, Peter Robinson wrote: > A SIG wiki page in general would be good with things like a kickstart > file to build the client version and the server version. It would > allow easy testing for things like depedency creep for core packages > and the like. easy testing is part of it... but we really need a reason to get those packages in the distribution for normal computer users who dont have access to the xo hardware. A usable Sugar Desktop running on standard computer hardware that interfaces well with the XO hardware would be a very..sellable...reason.. that I could talk about and get new contributors involved. I know I've talked to Denis about this a little bit. I think people still work by and large under the assumption that you need to have the XO hardware to help. You don't, but I think we need to get a Sugar Desktop..even a minimal one.. in front of people on their normal computers to get this to snowball. If we can identify a leader to point people at, I think we can make a push to attract new people to work on the packaging of things like activities. It's going to be a slow rolling snowball for a while, but it will be a snowball. -jef From jonstanley at gmail.com Tue Jul 8 23:43:16 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 8 Jul 2008 19:43:16 -0400 Subject: Setting up a Koji server In-Reply-To: <4873F54B.8090908@kobold.org> References: <4873EB04.8040002@kobold.org> <4873F54B.8090908@kobold.org> Message-ID: On Tue, Jul 8, 2008 at 7:16 PM, Michael Thomas wrote: > http://fedoraproject.org/wiki/Koji/ServerHowTo There is also fedora-buildsys-list at redhat.com for discussion of these types of things.... From jonstanley at gmail.com Tue Jul 8 23:53:40 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 8 Jul 2008 19:53:40 -0400 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <1215558728.6976.14.camel@kennedy> References: <1215463202.5070.12.camel@kennedy> <1215552658.3142.243.camel@calliope.phig.org> <1215558728.6976.14.camel@kennedy> Message-ID: 2008/7/8 Brian Pepple : > FESCo did that in earlier elections, and we had people that we're > nominated by someone else, and then after being elected decided they > didn't want to serve on FESCo. If we can avoid that from occurring > again, I don't have any objections. Speaking as a non-FESCo member, I wouldn't personally have a problem with this (nor for the Board or any other election for that matter). As was mentioned in the f-a-b thread, there are cultures and individuals that don't "feel right" self-nominating. Personally I would think that if the person did not want to serve, then they could say so prior to the nomination deadline and have their nomination withdrawn (or remove it from the wiki page themselves). There's also nothing wrong with a little nudge to whomever you have in mind - "I really think that you could be great on FESCo, why not consider nominating yourself?". $0.02 -Jon From paul at all-the-johnsons.co.uk Tue Jul 8 23:04:48 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 09 Jul 2008 00:04:48 +0100 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <1215558288.18922.0.camel@T7.Linux> Hi, > Fedora packagers: please consider adopting one of these packages and > giving it a loving home. I will keep asking. :) Having worked on csound, I can certainly say I'd help. Where can I grab the sources for the xo components? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 bojan at rexursive.com Wed Jul 9 01:32:23 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 09 Jul 2008 11:32:23 +1000 Subject: CVE-2008-1447 v. glibc Message-ID: <1215567143.2819.21.camel@shrek.rexursive.com> Is Fedora's glibc vulnerable to this? -- Bojan From jkeating at redhat.com Wed Jul 9 01:53:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 08 Jul 2008 21:53:10 -0400 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> Message-ID: <1215568390.4382.6.camel@localhost.localdomain> On Tue, 2008-07-08 at 17:49 -0500, Callum Lerwick wrote: > > Yes I've monitored it, it increments every few seconds when the system > is idle. If I do something to keep the disk active, it does not > increment. If I set the power save level up to 254, it stops > incrementing. I'm certain the value is accurate. In some testing tonight, the wakeups appear to be from kjournald, perhaps on the order of the atime updates. When I remount my / and /boot filesystems with noatime the very frequent writes go away. Now I only see writes every 20 seconds or so, caused by various parts of software that I'm trying to track down. I think it's really two things going on. 1) bioses are setting the harddrive to be very aggressive about parking, and 2) we're waking up the disk /way/ too frequently. If anybody would like to help me track down causes of 2 and file bugs, that would be awesome! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Wed Jul 9 01:54:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 08 Jul 2008 21:54:00 -0400 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <1215558728.6976.14.camel@kennedy> References: <1215463202.5070.12.camel@kennedy> <1215552658.3142.243.camel@calliope.phig.org> <1215558728.6976.14.camel@kennedy> Message-ID: <1215568440.4382.8.camel@localhost.localdomain> On Tue, 2008-07-08 at 19:12 -0400, Brian Pepple wrote: > Does anyone else on FESCo have an opinion on this? I'd be happy to see open nominations, provided that the nominee has to accept the nomination before being put on the ballot. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jeff at ocjtech.us Wed Jul 9 01:46:41 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 8 Jul 2008 20:46:41 -0500 Subject: CVE-2008-1447 v. glibc In-Reply-To: <1215567143.2819.21.camel@shrek.rexursive.com> References: <1215567143.2819.21.camel@shrek.rexursive.com> Message-ID: <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> On Tue, Jul 8, 2008 at 8:32 PM, Bojan Smojver wrote: > Is Fedora's glibc vulnerable to this? I think that the problem is mostly a server problem, which means BIND for the Fedora/RedHat world. I don't know if any of the other DNS servers in Fedora/RedHat are vulnerable. Listen to: https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conference.mp3 for more details. Jeff From bojan at rexursive.com Wed Jul 9 04:20:54 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 9 Jul 2008 04:20:54 +0000 (UTC) Subject: CVE-2008-1447 v. glibc References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> Message-ID: Jeffrey Ollie ocjtech.us> writes: > I think that the problem is mostly a server problem According to this: http://www.kb.cert.org/vuls/id/800113 It is not just a server problem: "These caching resolvers are the most common target for attackers; however, stub resolvers are also at risk." [...] "As mentioned above, stub resolvers are also vulnerable to these attacks. Stub resolvers that will issue queries in response to attacker behavior, and may receive packets from an attacker, should be patched. System administrators should be alert for patches to client operating systems that implement port randomization in the stub resolver." AFAIK, glibc is stub resolver on Fedora, hence the question. -- Bojan From debarshi.ray at gmail.com Wed Jul 9 04:54:16 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 9 Jul 2008 10:24:16 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <3170f42f0807082154wc465f6epc176602d9ca642e1@mail.gmail.com> > Here is a list of packages that are either badly needed by OLPC: > > http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist > > [...] > > Fedora packagers: please consider adopting one of these packages and giving > it a loving home. I will keep asking. :) I will take rssh. Happy hacking, Debarshi From debarshi.ray at gmail.com Wed Jul 9 05:03:37 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 9 Jul 2008 10:33:37 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> Message-ID: <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> >> These packages are either unavailable in Fedora, or are currently being >> maintained, poorly, by overworked OLPC engineers who can't invest enough >> time to do them justice. There are lots of simple issues that even novice >> packagers could handle. Missing or broken dependencies. Creation of >> dead-simple activity packages. And so on. > I think we need an overriding goal. Can we get a Fedora Sugar Desktop > Spin for standard pc hardware on the map and a SIG organized around > that effort? Would that put the right people together in the same > headspace to start working on packaging activities? Dumb question: Can someone running vanilla Fedora (8/9/etc.) without any physical access to the XO hardware maintain/use OLPC packages? Cheers, Debarshi From dennis at ausil.us Wed Jul 9 05:11:34 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 9 Jul 2008 00:11:34 -0500 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> Message-ID: <200807090011.49310.dennis@ausil.us> On Wednesday 09 July 2008, Debarshi Ray wrote: > >> These packages are either unavailable in Fedora, or are currently being > >> maintained, poorly, by overworked OLPC engineers who can't invest enough > >> time to do them justice. There are lots of simple issues that even > >> novice packagers could handle. Missing or broken dependencies. Creation > >> of dead-simple activity packages. And so on. > > > > I think we need an overriding goal. Can we get a Fedora Sugar Desktop > > Spin for standard pc hardware on the map and a SIG organized around > > that effort? Would that put the right people together in the same > > headspace to start working on packaging activities? > > Dumb question: > > Can someone running vanilla Fedora (8/9/etc.) without any physical > access to the XO hardware maintain/use OLPC packages? Yes, there is only a tiny handful of packages that are specific to the hardware/setup of the XO. the rest should always be applicable for use outside of the XO, sugar is in F-9 there is still some kinks in regards to the packaging that needs fixed. but if it doesnt work right on a normal fedora desktop its a bug and needs fixing. -- Dennis Gilmore -------------- 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 caillon at redhat.com Wed Jul 9 05:28:55 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 09 Jul 2008 01:28:55 -0400 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> Message-ID: <48744C97.5000904@redhat.com> Debarshi Ray wrote: > Dumb question: > > Can someone running vanilla Fedora (8/9/etc.) without any physical > access to the XO hardware maintain/use OLPC packages? Re-ask that question but with s/XO/PPC/ and you'll see that many people already do maintain packages without physical access to hardware. From debarshi.ray at gmail.com Wed Jul 9 05:54:52 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 9 Jul 2008 11:24:52 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <48744C97.5000904@redhat.com> References: <604aa7910807081255x6a48d9f4t6a0395e71a89ff1c@mail.gmail.com> <3170f42f0807082203tba3e9d1ocaec4a55488e3392@mail.gmail.com> <48744C97.5000904@redhat.com> Message-ID: <3170f42f0807082254h5afc2ac4y737268c6bc59f2a6@mail.gmail.com> > Re-ask that question but with s/XO/PPC/ and you'll see that many people > already do maintain packages without physical access to hardware. I was wondering whether there was difference between the Fedora running on the XO and the others like Fedora 8/9, because OLPC (like EL) has a separate branch in the CVS. But it now looks like one can manage just fine by installing Sugar on Fedora 9. Cheers, Debarshi From tgl at redhat.com Wed Jul 9 06:29:12 2008 From: tgl at redhat.com (Tom Lane) Date: Wed, 09 Jul 2008 02:29:12 -0400 Subject: CVE-2008-1447 v. glibc In-Reply-To: References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> Message-ID: <5646.1215584952@sss.pgh.pa.us> Bojan Smojver writes: > AFAIK, glibc is stub resolver on Fedora, hence the question. The normal configuration for a stub resolver is that it's only pointed to locally-controlled caching servers; so long as you've fixed those servers, you should be safe AFAICS. If this analysis is not correct, I'd like to be informed by some means more polite than breaking into my home machines ;-) regards, tom lane From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jul 9 06:39:02 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 09 Jul 2008 15:39:02 +0900 Subject: rpms/tomoe-gtk/devel tomoe-gtk.spec,NONE,1.1 sources,1.1,1.2 In-Reply-To: <200807090606.m6966IPa028305@cvs-int.fedora.redhat.com> References: <200807090606.m6966IPa028305@cvs-int.fedora.redhat.com> Message-ID: <48745D06.2060403@ioa.s.u-tokyo.ac.jp> Jens Petersen (petersen) wrote, at 07/09/2008 03:06 PM +9:00: > --- NEW FILE tomoe-gtk.spec --- > %define tomoe_ver 0.6.0 > > Name: tomoe-gtk > Version: 0.6.0 > Release: 4%{?dist} > > Requires: tomoe >= %{tomoe_ver} > Obsoletes: libtomoe-gtk < 0.6.0-4 > BuildRequires: tomoe-devel >= %{tomoe_ver}, gtk2-devel, > BuildRequires: gucharmap-devel, libgnomeui-devel, pygobject2-devel > BuildRequires: gettext Is the situation "Obsoletes but not Provides" intentional here? Mamoru From bojan at rexursive.com Wed Jul 9 07:00:00 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 9 Jul 2008 07:00:00 +0000 (UTC) Subject: CVE-2008-1447 v. glibc References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> <5646.1215584952@sss.pgh.pa.us> Message-ID: Tom Lane redhat.com> writes: > The normal configuration for a stub resolver is that it's only pointed > to locally-controlled caching servers; so long as you've fixed those > servers, you should be safe AFAICS. I'm not so much worried about my own configuration, but that of a random Fedora installation, that may be pointing to caching servers that are not locally controlled (e.g. that of ISP). That CERT VU#800113 talks about patching of stub resolvers: "Stub resolvers that will issue queries in response to attacker behavior, and may receive packets from an attacker, should be patched." So, it's more a general question about glibc and this CVE. -- Bojan From sundaram at fedoraproject.org Wed Jul 9 07:40:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 Jul 2008 13:10:14 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <48746B5E.3000100@fedoraproject.org> Greg Dekoenigsberg wrote: > > Here is a list of packages that are either badly needed by OLPC: > > http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist I am thinking of taking up rssh. If anyone else is interested, let me know. Rahul From mjg59 at srcf.ucam.org Wed Jul 9 07:57:58 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 9 Jul 2008 08:57:58 +0100 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <1215568390.4382.6.camel@localhost.localdomain> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> Message-ID: <20080709075758.GA14801@srcf.ucam.org> On Tue, Jul 08, 2008 at 09:53:10PM -0400, Jesse Keating wrote: > If anybody would like to help me track down causes of 2 and file bugs, > that would be awesome! Try echoing 1 >/proc/sys/vm/block_dump and then check dmesg. Stopping syslog before doing this might be a good plan for obvious reasons... -- Matthew Garrett | mjg59 at srcf.ucam.org From bojan at rexursive.com Wed Jul 9 09:36:11 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 9 Jul 2008 09:36:11 +0000 (UTC) Subject: CVE-2008-1447 v. glibc References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> <5646.1215584952@sss.pgh.pa.us> Message-ID: Bojan Smojver rexursive.com> writes: > So, it's more a general question about glibc and this CVE. I just got my answer: http://lwn.net/Articles/289206/ -- Bojan From benny+usenet at amorsen.dk Wed Jul 9 09:41:00 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 09 Jul 2008 11:41:00 +0200 Subject: CVE-2008-1447 v. glibc References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> <5646.1215584952@sss.pgh.pa.us> Message-ID: Tom Lane writes: > The normal configuration for a stub resolver is that it's only pointed > to locally-controlled caching servers; so long as you've fixed those > servers, you should be safe AFAICS. The attacker sends reply packets with the source-address of the locally-controlled caching server. Network firewalls and reverse path-checking can prevent this attack, but you cannot assume that all machines with Fedora are behind routers and firewalls set up to prevent the attack. > If this analysis is not correct, I'd like to be informed by some means > more polite than breaking into my home machines ;-) Don't worry, I won't tell anyone that your root password is 12345. /Benny From rawhide at fedoraproject.org Wed Jul 9 09:45:07 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 9 Jul 2008 09:45:07 +0000 (UTC) Subject: rawhide report: 20080709 changes Message-ID: <20080709094507.7F36C209D8A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080708/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080709/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package mono-tools The mono documentation system New package php-pear-propel_generator An Object Relational Mapping (ORM) framework for PHP5 New package php-pear-propel_runtime An Object Relational Mapping (ORM) framework for PHP5 New package xqf A server browser for many popular games Updated Packages: R-RScaLAPACK-0.5.1-15.fc10 -------------------------- * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 0.5.1-15 - look for mpi_comm_create_ not mpi_comm_create__ * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 0.5.1-14 - source /etc/profiles/modules.sh, then use module load * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 0.5.1-13 - ok, lets try this. * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 0.5.1-12 - fix compile against new lam apr-util-1.3.2-5.fc10 --------------------- * Tue Jul 8 18:00:00 2008 Joe Orton 1.3.2-5 - restore requires for openldap-devel from -devel bip-0.7.4-1.fc10 ---------------- * Sun Jun 8 18:00:00 2008 Lorenzo Villani - 0.7.4-1 - New version blacs-1.1-29.fc10 ----------------- * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 1.1-29 - fix lam paths * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 1.1-28 - rebuild * Tue May 13 18:00:00 2008 Tom "spot" Callaway - 1.1-27 - ia64 doesn't use /usr/lib64 bzflag-2.0.12-1.fc10 -------------------- * Tue Jul 8 18:00:00 2008 Nils Philippsen 2.0.12-1 - version 2.0.12 - fix source URL - drop plugin patch - use %bcond_with/_without macros cairo-dock-1.6.1-0.1.svn1181_trunk.fc10 --------------------------------------- * Wed Jul 9 18:00:00 2008 Mamoru Tasaka - rev. 1181 checkpolicy-2.0.16-3.fc10 ------------------------- * Mon Jul 7 18:00:00 2008 Dan Walsh - 2.0.16-3 - Rebuild with new libsepol collectl-3.0.0-1.fc10 --------------------- * Tue Jul 8 18:00:00 2008 Karel Zak 3.0.0-1 - upgrade to upstream version 3.0.0 connect-proxy-1.100-1.fc10 -------------------------- cscope-15.6-2.fc10 ------------------ * Tue Jul 8 18:00:00 2008 Neil Horman -15.6-2.dist - Grab upstream patch for -q rebuld (bz 436648) dvdauthor-0.6.14-6.fc10 ----------------------- * Tue Jul 8 18:00:00 2008 Ville Skytt?? - 0.6.14-6 - Fix build with changed libdvdread 4.1.3 header location. eclipse-subclipse-1.2.4-11.fc9 ------------------------------ * Mon Jul 7 18:00:00 2008 Robert Marcano 1.2.4-11 - Fix Bug 449533: FTBFS eclipse-subclipse-1.2.4-9.fc9 - Changed to use pdebuild script filezilla-3.0.11.1-1.fc10 ------------------------- * Tue Jul 8 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.11.1-1 - Update to 3.0.11.1 fluidsynth-1.0.8-1.fc10 ----------------------- * Tue Jul 8 18:00:00 2008 Anthony Green 1.0.8-1 - Upgrade source. gcc-4.3.1-4 ----------- * Tue Jul 8 18:00:00 2008 Jakub Jelinek 4.3.1-4 - update from gcc-4_3-branch - PRs c++/34963, c++/36662, fortran/36546, fortran/36657, fortran/36676, libstdc++/36612, libstdc++/36616, rtl-optimization/34744, target/34780, target/34856, target/36510, target/36634, target/36684, target/36698, target/36736, testsuite/36620, tree-optimization/36648 - fix -frepo (#448390, PR c++/36364) - improve OpenMP debug info (PRs debug/36617, middle-end/36726) gdb-6.8-14.fc10 --------------- * Tue Jul 8 18:00:00 2008 Jan Kratochvil - 6.8-14 - Fix crash due to calling an inferior function right after a watchpoint stop. gnome-panel-2.23.4-2.fc10 ------------------------- * Tue Jul 8 18:00:00 2008 Matthias Clasen - 2.23.4-2 - Fix debuginfo generation gnome-session-2.23.4.1-2.fc10 ----------------------------- * Tue Jul 8 18:00:00 2008 Matthias Clasen - 2.23.4.1-2 - Escape comments for markup gtksourceview2-2.2.2-1.fc9 -------------------------- * Tue Jul 1 18:00:00 2008 Matthias Clasen - 2.2.2-1 - Update to 2.2.2 gyachi-1.1.35-15.fc10 --------------------- * Tue Jul 8 18:00:00 2008 Gregory D Hosler - 1.1.35-15 - plugin-photo_album obsoletes plugin-photosharing * Fri Jun 20 18:00:00 2008 Gregory D Hosler - 1.1.35-8 - disabled libnotify, gpgme for RHEL4, changed libXt-devel and - libtool-ltdl-devel for RHEL4 * Fri Jun 20 18:00:00 2008 Gregory D Hosler - 1.1.35-12 - Changed jasper-libs back to jasper for el4/el5 hamlib-1.2.7-3.fc9 ------------------ * Mon Jul 7 18:00:00 2008 Steve Conklin - 1.2.7-3 - Applied suggested patch from Paul Howarth (thanks) * Mon Jul 7 18:00:00 2008 Steve Conklin - 1.2.7-2 - Rebuild to satisfy Perl dependency, add dependency httpd-2.2.9-2 ------------- * Tue Jul 8 18:00:00 2008 Joe Orton 2.2.9-2 - update to 2.2.9 - build event MPM too * Wed Jun 4 18:00:00 2008 Joe Orton 2.2.8-4 - correct UserDir directive in default config (#449815) hunspell-es-0.20051031-2.fc10 ----------------------------- * Tue Jul 8 18:00:00 2008 Caolan McNamara - 0.20051031-2 - add es_US hunspell-pt-0.20080707-1.fc10 ----------------------------- * Tue Jul 8 18:00:00 2008 Caolan McNamara - 0.20080707-1 - latest pt_BR version im-chooser-1.2.0-1.fc10 ----------------------- * Tue Jul 8 18:00:00 2008 Akira TAGOH - 1.2.0-1 - New upstream release. imsettings-0.101.3-2.fc10 ------------------------- * Tue Jul 8 18:00:00 2008 Akira TAGOH - 0.101.3-2 - rebuild. jpackage-utils-1.7.5-1jpp.4.fc10 -------------------------------- * Tue Jul 8 18:00:00 2008 Deepak Bhole 1.7.5-1jpp.4 - Update some macros to be based on other system macros. lapack-3.1.1-4.fc10 ------------------- * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway 3.1.1-4 - fix missing dependencies (bz 442915) libSM-1.1.0-1.fc9 ----------------- * Wed Jul 2 18:00:00 2008 Adam Jackson 1.1.0-1 - libSM 1.1.0 libffi-3.0.5-1.fc10 ------------------- * Tue Jul 8 18:00:00 2008 Anthony Green 3.0.5-1 - Upgrade to 3.0.5 libidn-0.6.14-8 --------------- * Tue Jun 10 18:00:00 2008 Joe Orton 0.6.14-8 - fix build with latest autoconf (#449440) libpciaccess-0.10.3-2.fc9 ------------------------- * Wed Jul 2 18:00:00 2008 Adam Jackson 0.10.3-2 - Fix file access mode in config fd cache. (#452910) * Tue Jul 1 18:00:00 2008 Adam Jackson 0.10.3-1 - libpciaccess 0.10.3 * Tue May 20 18:00:00 2008 Adam Jackson 0.10-3 - libpciaccess-no-pci-fix.patch: Fix init when /sys/bus/pci is empty or nonexistent. libselinux-2.0.67-3.fc10 ------------------------ * Tue Jul 8 18:00:00 2008 Dan Walsh - 2.0.67-3 - Rebuild for new libsepol libvirt-0.4.4-2.fc10 -------------------- * Tue Jul 8 18:00:00 2008 Daniel P. Berrange - 0.4.4-2.fc10 - Fix booting of CDROM images with KVM (rhbz #452355) lxpanel-0.3.8.1-1.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Sebastian Vahl 0.3.8.1-1 - new upstream version: 0.3.8.1 mxml-2.5-1.fc10 --------------- * Tue Jul 8 18:00:00 2008 Anthony Green 2.5 - Upgrade source. net-tools-1.60-88.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Radek Vok??l - 1.60-88 - netstat displays correct sctp statistics (#445535) nethogs-0.7-3.20080627cvs.fc10 ------------------------------ * Tue Jul 8 18:00:00 2008 Anderson Silva 0.7-3.20080627cvs - Fix for debuginfo package provided by Ville Skytta. nspluginwrapper-1.1.0-1.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Martin Stransky 1.1.0-1 - update to latest upstream version (1.1.0) * Mon May 5 18:00:00 2008 Martin Stransky 0.9.91.5-28 - link pluginwrapper with stdc++ lib nyquist-3.01-1.fc10 ------------------- * Mon Jul 7 18:00:00 2008 Gerard Milmeister - 3.01-1 - new release 3.01 openoffice.org-3.0.0-0.0.23.1.fc10 ---------------------------------- * Mon Jul 7 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.23-1 - next version - drop integrated openoffice.org-3.0.0.ooo90612.sd.insertpasswordedfile.patch - drop integrated openoffice.org-3.0.0.ooo90697.sd.a11ycrash.patch - drop integrated openoffice.org-2.4.0.ooo85429.sw.a11ycrash.patch - drop integrated openoffice.org-2.1.0.ooo73201.sw.a11yloadcrash.patch - Resolves: rhbz#452374 add openoffice.org-3.0.0.ooo86142.serbiannumbering.patch - split out arcane ScriptProviders out of core into optional extensions => bsh now only required by beanshell ScriptProvider - extend selinux bodge to m68k perl-Algorithm-CheckDigits-0.50-1.fc10 -------------------------------------- * Tue Jul 8 18:00:00 2008 Xavier Bachelot - 0.50-1 - Update to 0.50. perl-Calendar-Simple-1.20-1.fc10 -------------------------------- * Tue Jul 8 18:00:00 2008 Ralf Cors??pius - 1.20-1 - Upstream update. perl-Crypt-RSA-1.98-1.fc10 -------------------------- * Tue Jul 8 18:00:00 2008 Paul Howarth 1.98-1 - Update to 1.98 perl-DateTime-0.4302-2.fc10 --------------------------- * Tue Jul 8 18:00:00 2008 Steven Pritchard 1:0.4302-2 - Update to DateTime::TimeZone 0.7701. perl-DateTime-Format-Strptime-1.0702-3.fc10 ------------------------------------------- * Tue Jul 8 18:00:00 2008 Steven Pritchard 1.0702-3 - Patch t/004_locale_defaults.t to work around change in DateTime::Locale. perl-MooseX-Object-Pluggable-0.0007-2.fc10 ------------------------------------------ * Tue Jul 8 18:00:00 2008 Chris Weyl 0.0007-2 - ...and fix build failure * Tue Jul 8 18:00:00 2008 Chris Weyl 0.0007-1 - update to 0.0007 perl-MooseX-Params-Validate-0.05-1.fc10 --------------------------------------- * Tue Jul 8 18:00:00 2008 Chris Weyl 0.05-1 - update to 0.05 perl-Net-Telnet-3.03-7.fc10 --------------------------- * Fri May 23 18:00:00 2008 Fabio M. Di Nitto - 3.03-7 - Fix bug 226273: * Add dist tag. * Fix rpmlint errors for %description. * Remove MANIFEST from package. - General clean up of spec file. perl-Net-eBay-0.50-1.fc10 ------------------------- * Tue Jul 8 18:00:00 2008 Xavier Bachelot - 0.50-1 - Update to 0.50. perl-Params-Util-0.33-2.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Ralf Cors??pius - 0.33-2 - Unconditionally BR: perl(Test::CPAN::Meta). perl-Text-CSV_XS-0.52-2.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Lubomir Rintel - 0.52-2 - Actually solving the issue mentioned in previous change * Tue Jul 8 18:00:00 2008 Lubomir Rintel - 0.52-1 - Updated to 0.52 to solve an issue with perl 5.10 plymouth-0.5.0-3.fc10 --------------------- * Tue Jul 8 18:00:00 2008 Ray Strode - 0.5.0-3 - Fix populate script on ppc (bug 454353) policycoreutils-2.0.52-4.fc10 ----------------------------- * Tue Jul 8 18:00:00 2008 Dan Walsh 2.0.52-4 - Handle ranges of ports in gui * Tue Jul 8 18:00:00 2008 Dan Walsh 2.0.52-3 - Fix indent problems in seobject qjackctl-0.3.3-1.fc10 --------------------- * Tue Jul 8 18:00:00 2008 Anthony Green 0.3.3-1 - Upgrade source. raptor-1.4.18-1.fc10 -------------------- * Tue Jul 8 18:00:00 2008 Anthony Green 1.4.18-1 - Update sources. redhat-menus-8.9.11-4.fc10 -------------------------- * Tue Jul 8 18:00:00 2008 Matthias Clasen - 8.9.11-4 - Fix icons for menus rpy-1.0.3-2.fc10 ---------------- * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 1.0.3-2 - rebuild against R 2.7.1 scalapack-1.7.5-3.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway 1.7.5-3 - fix compile against new lam paths seamonkey-1.1.10-1.fc9 ---------------------- * Sun Jul 6 18:00:00 2008 Christopher Aillon - 1.1.10-1 - Update to 1.1.10 - Use bullet characters to match GTK+ selinux-policy-3.4.2-13.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Dan Walsh 3.4.2-13 - Allow unconfined_t to setfcap setroubleshoot-2.0.8-2.fc9 -------------------------- * Tue Jun 17 18:00:00 2008 John Dennis - 2.0.8-1 - fix capitalization of Socket module name in access_control.py * Fri May 16 18:00:00 2008 - 2.0.7-1 - fix bug with SO_PEERCRED for PPC arch - update po translations sugar-0.81.6-1.fc10 ------------------- * Tue Jul 8 18:00:00 2008 Simon Scahmpijer - 0.81.6 - 7438 sugar shuts down when you click Restart - 7365 Invites not working - 7248 Speaker device has inconsistent behavior - 7339 CPU Spins after starting an activity - 7015 Add proper alignment support to the tray control - 5613 Cannot set non-ASCII nick name - 7046 Deleting activity bundle with journal leaves it showing in Home list view until reboot - 7391 Make the search field in Home reveal the list view - 7248 Speaker device has inconsistent behavior - 7272 Notifications are redundant with new launching feedback - 7273 Activity icons remain colored after launch sugar-base-0.81.2-2.fc10 ------------------------ * Tue Jul 8 18:00:00 2008 Simon Schampijer - 0.81.2-2 - BuildRequires: perl-XML-Parser * Tue Jul 8 18:00:00 2008 Simon Schampijer - 0.81.2-1 - gained its own translation module and some languages have already been contributed sugar-datastore-0.8.3-1.fc10 ---------------------------- * Tue Jul 8 18:00:00 2008 Tomeu Vizoso - 0.8.3-1 - Update to 0.8.3 sugar-journal-94-1.fc10 ----------------------- * Tue Jul 8 18:00:00 2008 Tomeu Vizoso - 94-1 - New release sugar-presence-service-0.81.3-2.fc10 ------------------------------------ * Tue Jul 8 18:00:00 2008 Morgan Collett - 0.81.3-2 - Depends on telepathy-salut and telepathy-gabble * Tue Jul 8 18:00:00 2008 Morgan Collett - 0.81.3-1 - Update to 0.81.3 sugar-toolkit-0.81.6-2.fc10 --------------------------- * Tue Jul 8 18:00:00 2008 Simon Schampijer - 0.81.6-2 - add libSM-devel dependency * Tue Jul 8 18:00:00 2008 Simon Schampijer - 0.81.6-1 - 7015 Add proper alignment support to the tray control - 7054 Journal doesn't show correct colors for activity instances - 7046 Deleting activity bundle with journal leaves it showing in Home list view until reboot - 3939 Keep button should use XO colors - 7248 Speaker device has inconsistent behavior system-config-firewall-1.2.10-1.fc10 ------------------------------------ * Tue Jul 8 18:00:00 2008 Thomas Woerner 1.2.10-1 - lokkit: fixed path for system-config-firewall-tui (rhbz#454108) - updated translations for: it, fr, nl, ru, sr, sr at latin tzdata-2008d-1.fc10 ------------------- * Tue Jul 8 18:00:00 2008 Petr Machata - 2008d-1 - Upstream 2008d - Changes for Brazil and Mauritius whysynth-dssi-20080412-1.fc10 ----------------------------- * Mon Jul 7 18:00:00 2008 Anthony Green 20080412-1 - Upgrade sources. Add COPYING-patches. wireshark-1.0.1-1.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Radek Vok??l 1.0.1-1 - upgrade to 1.0.1 wyrd-1.4.4-2.fc10 ----------------- * Tue Jul 8 18:00:00 2008 Till Maas - 1.4.4-2 - fix BuildRequires, camlp4 is not needed/supported as BR anymore xastir-1.9.2-8.fc10 ------------------- * Tue Jul 8 18:00:00 2008 Lucian Langa - 1.9.2-8 - Rebuild against newer db4 headers xorg-x11-drv-evdev-2.0.1-1.fc9 ------------------------------ * Tue Jul 1 18:00:00 2008 Adam Jackson 2.0.1-1 - evdev 2.0.1 * Tue Jun 17 18:00:00 2008 Adam Jackson 2.0.0-1 - evdev 2.0.0 * Tue Jun 10 18:00:00 2008 Adam Jackson 1.99.4-1 - evdev 1.99.4 xorg-x11-drv-glint-1.2.1-1.fc9 ------------------------------ * Tue Jul 1 18:00:00 2008 Adam Jackson 1.2.1-1 - glint 1.2.1 xorg-x11-drv-i810-2.3.2-2.fc9 ----------------------------- * Wed Jul 2 18:00:00 2008 Adam Jackson 2.3.2-2 - Drop the %pre hack for the moment. * Tue Jul 1 18:00:00 2008 Adam Jackson 2.3.2-1 - intel 2.3.2 * Tue May 27 18:00:00 2008 Adam Jackson 2.2.1-25 - s/i810/intel/ in xorg.conf in %pre so we can eventuall stop installing the BC symlink. xorg-x11-drv-mga-1.4.9-1.fc9 ---------------------------- * Wed Jul 2 18:00:00 2008 Adam Jackson 1.4.9-1 - mga 1.4.9 xorg-x11-utils-7.4-1.fc9 ------------------------ * Wed Jul 2 18:00:00 2008 Adam Jackson 7.4-1 - xdpyinfo 1.0.3 - xprop 1.0.4 - xwininfo 1.0.4 xorg-x11-xtrans-devel-1.2.1-1.fc9 --------------------------------- * Wed Jul 2 18:00:00 2008 Adam Jackson 1.2.1-1 - xtrans 1.2.1 xsupplicant-1.2.8-8.fc10 ------------------------ * Tue Jul 8 18:00:00 2008 Tom "spot" Callaway - 1.2.8-8 - fix iwlib handling Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 81 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.i386 requires libgucharmap.so.6 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.i386 requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.i386 requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.i386 requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.x86_64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.x86_64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.x86_64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.x86_64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 libtomoe-gtk-0.6.0-3.fc9.ppc requires libgucharmap.so.6 libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 scim-tomoe-0.6.0-3.fc10.ppc requires libgucharmap.so.6 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-gtk-0.6.so.90 swfdec-gnome-2.22.0-1.fc9.ppc requires libswfdec-0.6.so.90 tor-core-0.1.2.19-1.fc9.ppc requires libevent-1.3e.so.1 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) libtomoe-gtk-0.6.0-3.fc9.ppc64 requires libgucharmap.so.6()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 scim-tomoe-0.6.0-3.fc10.ppc64 requires libgucharmap.so.6()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-gtk-0.6.so.90()(64bit) swfdec-gnome-2.22.0-1.fc9.ppc64 requires libswfdec-0.6.so.90()(64bit) tor-core-0.1.2.19-1.fc9.ppc64 requires libevent-1.3e.so.1()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From nigel.metheringham at dev.intechnology.co.uk Wed Jul 9 09:53:38 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 9 Jul 2008 10:53:38 +0100 Subject: CVE-2008-1447 v. glibc In-Reply-To: References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> <5646.1215584952@sss.pgh.pa.us> Message-ID: <04A382A1-952A-479B-8036-354BD0FC53FF@dev.intechnology.co.uk> On 9 Jul 2008, at 10:41, Benny Amorsen wrote: > Don't worry, I won't tell anyone that your root password is 12345. I'm OK - I used rot13 on it... oh... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From nphilipp at redhat.com Wed Jul 9 09:58:13 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 09 Jul 2008 11:58:13 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872493E.6040306@poolshark.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> Message-ID: <1215597493.29818.11.camel@wombat.tiptoe.de> On Mon, 2008-07-07 at 18:50 +0200, Denis Leroy wrote: > However sabotaging the installer to make it impossible for people to > disable it at installation, now that's where I say "that doesn't make > any sense", cf my original email. "Sabotaging"? For crying out loud... there is no immediate need to be able to do this at installation time, it can just as well be done afterwards (or you can use kickstart to do it). One question nobody has been able to answer to my satisfaction yet: Why would it be essential that SELinux can be disabled from the installer vs. from the installed system? Last time I checked, the plan was to get non-essential functionality out of anaconda. NB: zombo.com[1] lives on virtual console #2 for your SELinux disabling pleasure. [1]: http://www.zombo.com Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jnovy at redhat.com Wed Jul 9 10:22:07 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 9 Jul 2008 12:22:07 +0200 Subject: db-4.7.25 update heads-up Message-ID: <20080709102207.GA9149@dhcp-lab-186.brq.redhat.com> Hi all, this is just a small heads-up announcing upgrade of db4 to 4.7.25. If your package uses db4, then it should be linked with the new db4 after repos are refreshed. db-4.6.21 is now moved to compat-db so your packages dependent on older db4 without rebuild will become dependent on compat-db. Cheers, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From walters at verbum.org Wed Jul 9 10:32:16 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 9 Jul 2008 06:32:16 -0400 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080709075758.GA14801@srcf.ucam.org> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> Message-ID: On Wed, Jul 9, 2008 at 3:57 AM, Matthew Garrett wrote: > On Tue, Jul 08, 2008 at 09:53:10PM -0400, Jesse Keating wrote: > > > If anybody would like to help me track down causes of 2 and file bugs, > > that would be awesome! > > Try echoing 1 >/proc/sys/vm/block_dump and then check dmesg. Stopping > syslog before doing this might be a good plan for obvious reasons... Putting syslog on tmpfs by default and limiting the total size to something like 5MB would be something to evaluate for the default desktop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at redhat.com Wed Jul 9 10:51:15 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 13:51:15 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide Message-ID: At long last, we are about to get a brand new RPM version (alpha snapshot at the moment) into rawhide. The list of changes from 4.4.2.x is massive and a full summary needs a separate posting (will follow as time permits), this is just a heads-up of immediate consequences for Fedora packagers and rawhide consumers: Users: 1) BACKUP YOUR RPMDB, NOW! We're not aware of any baby-eating bugs in rpm but I'd be shocked if there were no new bugs at all... Better safe than sorry - do something like this before updating to the new rpm: # cp -avp /var/lib/rpm /var/lib/rpm-`date +%d%m%y` 2) Rebuilding the rpmdb is not a bad idea (if not strictly necessary): # rpm --rebuilddb 3) Watch out for regressions and please report immediately if found. Again, we're not aware of any baby-eating bugs but there has been an enormous amount of changes in the codebase... The python bindings are supposed to be entirely backwards compatible but there are some small differences with returned types (notably returning an empty list vs None) on tag data in some cases, this breaks rpmlint (patch is trivial, will send to maintainer). Packagers: 1) So-name bumb is involved, the API has changed a lot. Here's the list of involved packages according to repoquery and status, I'll be sending patches to package maintainers shortly: - gdb (needs update to locate build-id patch) - perl-RPM2 (needs some updating) - apt (needs major work, but this is my headache) - ruby-rpm (needs quite a bit of work) - deltarpm (just needs a rebuild apparently) - net-snmp (needs rebuild with -D_RPM_4_4_COMPAT) - rpmreaper (needs rebuild with -D_RPM_4_4_COMPAT) 2) rpmbuild uses --fuzz=0 parameter to patch by default. This will "break" many many packages as this is stricter than the default of patch command itself. Two possibilities: - Rediff your patches and check they're applying correctly. This is the best thing to do, patches applied with fuzz can and do cause strange and nasty bugs. - As a temporary action, adding "%define _default_patch_fuzz 2" to spec will force rpm to use fuzz level 2 which is the default for patch itself. 3) %{_topdir} now defaults to $(HOME)/rpmbuild/, /usr/src/redhat/ is no more. 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under %{_topdir}/BUILDROOT/ 5) Rpm now supports "arch dependencies", so eg. foo-devel dependencies can be expressed correctly. Please wait for FPC recommendations on the subject, this needs a mass rebuild to be usable. 6) Rpm now collects pkg-config and libtool dependencies automatically. Initially only provides will be created to avoid creating unsolvable dependencies though. 7) Two new macros, %{patches} and %{sources} are supported in rpmbuild. In other words, you can now do things like: for p in %{patches}; do ... done Just keep in mind that using these in your spec will make the it incompatible with rpm 4.4.x versions. P.S. The new rpm will be initially built against Berkeley DB 4.5.20 from compat-db to ensure easy downgrade path to rpm 4.4.x should something go terribly, horribly wrong. Newer BDB would require manual db conversion to downgrade. - Panu - From lakshmipathi.g at gmail.com Wed Jul 9 10:53:19 2008 From: lakshmipathi.g at gmail.com (lakshmi pathi) Date: Wed, 9 Jul 2008 16:23:19 +0530 Subject: Do we have Deep Freeze/Clean Slate like tool? In-Reply-To: <1215533478.4199.4.camel@moss-terrapins.epoch.ncsc.mil> References: <20080708153854.GA7828@wolff.to> <1215533478.4199.4.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: xguest..thanks guy i'll check it out and get back if i got any doubts ... Cheers, Lakshmipathi.G On Tue, Jul 8, 2008 at 9:41 PM, Dave Quigley wrote: > > On Tue, 2008-07-08 at 10:38 -0500, Bruno Wolff III wrote: >> On Tue, Jul 08, 2008 at 19:52:51 +0530, >> lakshmi pathi wrote: >> > Hi all, >> > Recently i came across Deep Freeze/Clean slate in a linux forum.Do we >> > have open source alternative to these tools? >> > Is that really helpful tool for linux user? Please share your thoughts. >> >> Have you looked at xguest? Depending on exactly what you are doing it might >> be suitable for your purpose. One note about customizing the profile is that >> sabayon has a couple of bugs that prevent doing some types of customization. >> But that may not be a show stopper for you. xguest is set up to do >> unauthenticated logins. There might be problems with giving unauthenticated >> access to the network, even if it is only through firefox. >> > I was looking through the xguest package and as of right now it seems > like it is setup just to deal with one user. However I'm sure it could > be adapted such that the xguest init script can take a user that it > wants to turn into an xguest account. The xguest package is a confined > SELinux user (xguest_u) with an init script and specialized > configuration data. If the script can be modified to take the user name > you could probably use it to make arbitrary home directories into xguest > accounts. I'm sure Dan has more to say about this since he is the author > of the xguest package. > > Dave > > From walters at verbum.org Wed Jul 9 10:59:16 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 9 Jul 2008 06:59:16 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: On Wed, Jul 9, 2008 at 6:51 AM, Panu Matilainen wrote: > > 2) rpmbuild uses --fuzz=0 parameter to patch by default. This will "break" > many many packages as this is stricter than the default of patch > command itself. Two possibilities: > When everyone is dealing with the vast amount of busywork this is going to entail, don't forget to double check that your patches are sent upstream if possible and add an appropriate comment: https://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Wed Jul 9 10:30:13 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jul 2008 12:30:13 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215597493.29818.11.camel@wombat.tiptoe.de> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> Message-ID: <1215599413.2809.477.camel@beck.corsepiu.local> On Wed, 2008-07-09 at 11:58 +0200, Nils Philippsen wrote: > One question nobody has been able to answer to my satisfaction yet: Why > would it be essential that SELinux can be disabled from the installer > vs. from the installed system? One point: Once SELinux had been active, it can cause problems, despite it had been disabled, afterwards: C.f.: https://bugzilla.redhat.com/show_bug.cgi?id=453365 Ralf From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jul 9 11:34:10 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 09 Jul 2008 20:34:10 +0900 Subject: Heads up: Experimental xscreensaver will hit rawhide Message-ID: <4874A232.6030208@ioa.s.u-tokyo.ac.jp> Hello, all: Tomorrow some experimental xscreensaver (versioned 5.05.90.3 on Fedora) will hitt rawhide tree. Some comments from the upstream developer: Please test out this alpha version of xscreensaver. There are extensive changes and it may be very unstable! Please see http://jwz.livejournal.com/908354.html for details about the things that need to be tested. In particular, stress-testing on Xinerama, RANDR and VidMode ViewPort-zoomed systems would be greatly appreciated. If you see any bugs on this new xscreensaver, please feel free to file bugs. Regards, Mamoru From atkac at redhat.com Wed Jul 9 11:38:38 2008 From: atkac at redhat.com (Adam Tkac) Date: Wed, 9 Jul 2008 13:38:38 +0200 Subject: CVE-2008-1447 v. glibc In-Reply-To: References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> Message-ID: <20080709113838.GA5110@traged.atkac.englab.brq.redhat.com> On Wed, Jul 09, 2008 at 04:20:54AM +0000, Bojan Smojver wrote: > Jeffrey Ollie ocjtech.us> writes: > > > I think that the problem is mostly a server problem > > According to this: > > http://www.kb.cert.org/vuls/id/800113 > > It is not just a server problem: > > "These caching resolvers are the most common target for attackers; however, stub > resolvers are also at risk." > > [...] > > "As mentioned above, stub resolvers are also vulnerable to these attacks. Stub > resolvers that will issue queries in response to attacker behavior, and may > receive packets from an attacker, should be patched. System administrators > should be alert for patches to client operating systems that implement port > randomization in the stub resolver." > > AFAIK, glibc is stub resolver on Fedora, hence the question. > > -- > Bojan In my opinion endpoint stub resolvers are not so vulnerable. If you want spoof DNS data to resolver you have to force that resolver to send query for name that you know - which is often impossible in glibc's resolver case (AFAIK only happen when attacker opens connection to some service and that service asks for attacker's reverse DNS record for example). Adam -- Adam Tkac, Red Hat, Inc. From buc at odusz.so-cdu.ru Wed Jul 9 11:50:23 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 09 Jul 2008 15:50:23 +0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215597493.29818.11.camel@wombat.tiptoe.de> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> Message-ID: <4874A5FF.10702@odu.neva.ru> Nils Philippsen wrote: > One question nobody has been able to answer to my satisfaction yet: Why > would it be essential that SELinux can be disabled from the installer > vs. from the installed system? When you disable SELinux under already installed system, you are compelled to reboot to take an effect of this change. Another things, suitable for the "first boot time", seem not require such an extra reboot. IMHO people want an option for Anaconda to avoid the need of extra rebooting. ~buc From dimi at lattica.com Wed Jul 9 12:14:23 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 09 Jul 2008 08:14:23 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <1215605663.27720.112.camel@dimi.lattica.com> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > At long last, we are about to get a brand new RPM version (alpha > snapshot at the moment) into rawhide. The list of changes from 4.4.2.x > is massive and a full summary needs a separate posting (will follow as > time permits) Thanks Panu, This is way cool! I'm glad to see so many needed changes being addressed. I'd be interested in the full list of changes, if you can find the time to put it together. -- Dimi Paun Lattica, Inc. From lesmikesell at gmail.com Wed Jul 9 12:38:52 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 09 Jul 2008 07:38:52 -0500 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215597493.29818.11.camel@wombat.tiptoe.de> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> Message-ID: <4874B15C.6000407@gmail.com> Nils Philippsen wrote: > >> However sabotaging the installer to make it impossible for people to >> disable it at installation, now that's where I say "that doesn't make >> any sense", cf my original email. > > "Sabotaging"? For crying out loud... there is no immediate need to be > able to do this at installation time, it can just as well be done > afterwards (or you can use kickstart to do it). It is sort of like a return to windows95 to be forced to reboot the machine to make your changes take effect... -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Wed Jul 9 13:03:35 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 9 Jul 2008 09:03:35 -0400 Subject: apport/breakpad and fedora In-Reply-To: References: Message-ID: I got a few moments to create a new Feature page for the breakpad/socorro plan: https://fedoraproject.org/wiki/Features/CrashHandling I didn't add any details about the littlebottom/kernel crash handling design since I don't know enough about it. But if we go for applications running in the desktop as an initial target it would still be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsof at nodata.co.uk Wed Jul 9 13:31:22 2008 From: lsof at nodata.co.uk (nodata) Date: Wed, 09 Jul 2008 15:31:22 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4874B15C.6000407@gmail.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <4874B15C.6000407@gmail.com> Message-ID: <1215610282.2934.2.camel@sb-home> Am Mittwoch, den 09.07.2008, 07:38 -0500 schrieb Les Mikesell: > Nils Philippsen wrote: > > > >> However sabotaging the installer to make it impossible for people to > >> disable it at installation, now that's where I say "that doesn't make > >> any sense", cf my original email. > > > > "Sabotaging"? For crying out loud... there is no immediate need to be > > able to do this at installation time, it can just as well be done > > afterwards (or you can use kickstart to do it). > > It is sort of like a return to windows95 to be forced to reboot the > machine to make your changes take effect... > > -- > Les Mikesell > lesmikesell at gmail.com > You can switch it to permissive.. From mschwendt at gmail.com Wed Jul 9 13:35:15 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 9 Jul 2008 15:35:15 +0200 Subject: libgtop2 - who owns it? Message-ID: <20080709153515.5e34d1d6.mschwendt@gmail.com> http://bugz.fedoraproject.org/libgtop2 shows two open bugs, which are assigned to S?ren Sandmann Pedersen, but the package changelog shows the names of other maintainers. One of the bug reports is one year old already. The other one is mine. Who owns libgtop2? From tcallawa at redhat.com Wed Jul 9 13:39:21 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Jul 2008 09:39:21 -0400 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <4873F47C.8030802@blagblagblag.org> References: <4873F47C.8030802@blagblagblag.org> Message-ID: <1215610761.10164.12.camel@localhost.localdomain> On Tue, 2008-07-08 at 20:13 -0300, jeff wrote: > Greg Dekoenigsberg wrote: > > Here is a list of packages that are either badly needed by OLPC: > > > > http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist > > Some squeak packages here already for starters: > http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-image-3.8.6665-2.fc9.src.rpm > http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-sources-3.9-1.fc9.src.rpm > http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-vm-3.10-1.2.fc9.src.rpm I haven't looked at these items, but if they're under the Squeak license, they can't go in Fedora, that license is non-free. ~spot From dsd at laptop.org Wed Jul 9 13:42:35 2008 From: dsd at laptop.org (Daniel Drake) Date: Wed, 09 Jul 2008 09:42:35 -0400 Subject: OLPC & package dependency growth Message-ID: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Hi, I'm working on OS-level issues at OLPC. I saw Greg Dekoenigsberg's mail about Fedora/OLPC collaboration (thanks Greg!) and have another point to raise: We're currently working on upgrading from F7 to F9 for our next major software release. One of the challenges here is that by upgrading, over 100 packages were added to the build as dependencies of packages we were already including. Examples: totem-gstreamer now depends on gvfs which pulls in samba. HAL now pulls in smbios-utils (entirely Dell-specific hence not relevant here) perl and associated packages are now pulled in by mtd-utils, ntp, gstreamer-plugins-base and libbonobo libgnome now depends on fedora-gnome-theme which pulls in a lot more theme stuff ... ?The XO has just 1GB flash so we need to keep the size of our build down. I guess some of these extra dependency chains are hard to predict/avoid but it would be good to raise awareness here. It would also be great if people could help us slim our F9 builds back to acceptable sizes, since we are nearing release-candidate phase. Some related links: http://dev.laptop.org/ticket/7353 http://dev.laptop.org/~bert/update.1-joyride.html - the top section shows all the packages added in joyride (F9) over update1 (F7) http://wiki.laptop.org/go/Distro_Version_Migration_Nastiness (we're forking some packages into the OLPC-3 disttag which have slimmed down dependencies, but obviously forking is not a great option) http://ausil.us/blog/olpc-fedora.html Thanks, Daniel From tcallawa at redhat.com Wed Jul 9 13:43:02 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Jul 2008 09:43:02 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <1215610982.10164.13.camel@localhost.localdomain> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > this is just a heads-up of immediate consequences for Fedora packagers > and rawhide consumers: Panu, Thanks! I'm excited at the opportunity to prune the packaging guidelines as a result. :) ~spot From sundaram at fedoraproject.org Wed Jul 9 13:43:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 Jul 2008 19:13:51 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <1215610761.10164.12.camel@localhost.localdomain> References: <4873F47C.8030802@blagblagblag.org> <1215610761.10164.12.camel@localhost.localdomain> Message-ID: <4874C097.6000506@fedoraproject.org> Tom "spot" Callaway wrote: > On Tue, 2008-07-08 at 20:13 -0300, jeff wrote: >> Greg Dekoenigsberg wrote: >>> Here is a list of packages that are either badly needed by OLPC: >>> >>> http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist >> Some squeak packages here already for starters: >> http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-image-3.8.6665-2.fc9.src.rpm >> http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-sources-3.9-1.fc9.src.rpm >> http://math.ifi.uzh.ch/fedora/9/i386/SRPMS.gemi/squeak-vm-3.10-1.2.fc9.src.rpm > > I haven't looked at these items, but if they're under the Squeak > license, they can't go in Fedora, that license is non-free. http://www.squeak.org/SqueakLicense/ Apparently there is an ongoing effort to relicense under Apache 2.0 but that process is not complete yet. People more familiar with the project should enquire the current status. Rahul From sundaram at fedoraproject.org Wed Jul 9 13:46:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 Jul 2008 19:16:10 +0530 Subject: OLPC & package dependency growth In-Reply-To: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Message-ID: <4874C122.9010203@fedoraproject.org> Daniel Drake wrote: > I guess some of these extra dependency chains are hard to predict/avoid > but it would be good to raise awareness here. It would also be great if > people could help us slim our F9 builds back to acceptable sizes, since > we are nearing release-candidate phase. If you have ideas on how they can split (along with any patches) they should be filed under Red Hat bugzilla with a tracker bug to keep track of them all. There are several other cases where more granular dependencies are a big help. Thanks for bringing this up. Rahul From limb at jcomserv.net Wed Jul 9 13:49:52 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 9 Jul 2008 08:49:52 -0500 (CDT) Subject: libgtop2 - who owns it? In-Reply-To: <20080709153515.5e34d1d6.mschwendt@gmail.com> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> Message-ID: <24028.198.175.55.5.1215611392.squirrel@mail.jcomserv.net> > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, > which are assigned to S??ren Sandmann Pedersen, but the package > changelog shows the names of other maintainers. One of the bug > reports is one year old already. The other one is mine. > > Who owns libgtop2? pkgdb says it's Soren, and there are lots of others with commit/watchcommit: https://admin.fedoraproject.org/pkgdb/packages/libgtop2 > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mclasen at redhat.com Wed Jul 9 13:51:51 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 09:51:51 -0400 Subject: libgtop2 - who owns it? In-Reply-To: <20080709153515.5e34d1d6.mschwendt@gmail.com> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> Message-ID: <1215611511.3233.5.camel@localhost.localdomain> On Wed, 2008-07-09 at 15:35 +0200, Michael Schwendt wrote: > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, > which are assigned to S?ren Sandmann Pedersen, but the package > changelog shows the names of other maintainers. One of the bug > reports is one year old already. The other one is mine. > > Who owns libgtop2? > Since you were already at bugz.fd.o, it wouldn't have cost you much to head over to https://admin.fedoraproject.org/pkgdb/packages/name/libgtop2 to find out. Soeren owns it. I do most of the version updates when I do mass updates. From kevin.kofler at chello.at Wed Jul 9 13:52:34 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 9 Jul 2008 13:52:34 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: Message-ID: Panu Matilainen redhat.com> writes: > Packagers: 8) Unnumbered Source: and Patch: are no longer accepted, you have to explicitly write Source0: resp. Patch: (unless I misunderstood this commit: http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commit;h=724b07bba5e802998b1b79b408c2401d2a238a3b ). I hope packages which FTBFS (only) due to this and/or the patch fuzz issue won't be considered for the FTFBS package elimination in a week, otherwise we'll end up with half the distro removed! :-( Kevin Kofler From skvidal at fedoraproject.org Wed Jul 9 13:54:44 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Jul 2008 09:54:44 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <1215611684.14926.90.camel@rosebud> On Wed, 2008-07-09 at 13:52 +0000, Kevin Kofler wrote: > I hope packages which FTBFS (only) due to this and/or the patch fuzz issue > won't be considered for the FTFBS package elimination in a week, otherwise > we'll end up with half the distro removed! :-( You say that like it is a bad thing... :) -sv From dwalsh at redhat.com Wed Jul 9 13:57:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Jul 2008 09:57:11 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215599413.2809.477.camel@beck.corsepiu.local> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1215599413.2809.477.camel@beck.corsepiu.local> Message-ID: <4874C3B7.7090603@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: | On Wed, 2008-07-09 at 11:58 +0200, Nils Philippsen wrote: | |> One question nobody has been able to answer to my satisfaction yet: Why |> would it be essential that SELinux can be disabled from the installer |> vs. from the installed system? | One point: Once SELinux had been active, it can cause problems, despite | it had been disabled, afterwards: | C.f.: https://bugzilla.redhat.com/show_bug.cgi?id=453365 | | Ralf | | This is a bug in code, and I am not sure this would not have happened if SELinux was disabled in the first place. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh0w7cACgkQrlYvE4MpobPVQACfeKeTPGdvykyNOdclQq/pdNUx j+MAn2v0no1EusfF+VsvAOUyN7ZBH6OY =lBlz -----END PGP SIGNATURE----- From mattdm at mattdm.org Wed Jul 9 13:58:53 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 9 Jul 2008 09:58:53 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <20080709135853.GA28488@jadzia.bu.edu> On Wed, Jul 09, 2008 at 01:51:15PM +0300, Panu Matilainen wrote: > 3) %{_topdir} now defaults to $(HOME)/rpmbuild/, /usr/src/redhat/ is > no more. This = I love you. > 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under > %{_topdir}/BUILDROOT/ This too. > 5) Rpm now supports "arch dependencies", so eg. foo-devel dependencies can > be expressed correctly. Please wait for FPC recommendations on the > subject, this needs a mass rebuild to be usable. And !!! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kevin.kofler at chello.at Wed Jul 9 13:56:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 9 Jul 2008 13:56:12 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: Message-ID: I wrote: > 8) Unnumbered Source: and Patch: are no longer accepted, you have to > explicitly write Source0: resp. Patch: I mean Patch0: here of course. ;-) Kevin Kofler From tcallawa at redhat.com Wed Jul 9 14:04:01 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Jul 2008 10:04:01 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <1215612241.10164.17.camel@localhost.localdomain> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under > %{_topdir}/BUILDROOT/ A few questions here: Is the BuildRoot from the spec ignored, or does it override the default buildroot? Is the default buildroot literally "%{_topdir}/BUILDROOT/" or is it something more complicated. I could easily see a case where two concurrent rpm builds could step on each other's buildroots. ~spot From jwilson at redhat.com Wed Jul 9 14:07:14 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 9 Jul 2008 10:07:14 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <200807091007.14587.jwilson@redhat.com> On Wednesday 09 July 2008 06:51:15 am Panu Matilainen wrote: > 7) Two new macros, %{patches} and %{sources} are supported in rpmbuild. > ? ? In other words, you can now do things like: > ? ? ? ?for p in %{patches}; do > ? ? ? ? ? ?... > ? ? ? ?done > ? ? Just keep in mind that using these in your spec will make the it > ? ? incompatible with rpm 4.4.x versions. Rock! The addition of %{patches} alone would reduce the size of the kernel spec by a pretty hefty amount. I've always hated having to specify every damned patch two times. Its annoying in the Fedora kernel specs, and outright obnoxious in RHEL, where the patches obviously add up a LOT over time... For example, RHEL5.2's kernel spec has like 1800 patches in it. 1800 less lines is a Very Good Thing. (Nb: I'm not suggesting this be backported to RHEL5, I was thinking more in terms of when RHEL6 rolls around). -- Jarod Wilson jwilson at redhat.com From mclasen at redhat.com Wed Jul 9 14:07:24 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 10:07:24 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Message-ID: <1215612444.3233.7.camel@localhost.localdomain> On Wed, 2008-07-09 at 09:42 -0400, Daniel Drake wrote: > I guess some of these extra dependency chains are hard to predict/avoid > but it would be good to raise awareness here. It would also be great if > people could help us slim our F9 builds back to acceptable sizes, since > we are nearing release-candidate phase. >From what I recall, we (or rather the olpc team) did quite a bit of dependency pruning back in the F7 timeframe to get the olpc image as small as it it. Realistically, you'll have to keep fighting this by filing bugs and pointing out package split candidates, since these deps have the tendency to grow back. Matthias From mschwendt at gmail.com Wed Jul 9 14:09:11 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 9 Jul 2008 16:09:11 +0200 Subject: libgtop2 - who owns it? In-Reply-To: <1215611511.3233.5.camel@localhost.localdomain> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> Message-ID: <20080709160911.fcb33243.mschwendt@gmail.com> On Wed, 09 Jul 2008 09:51:51 -0400, Matthias Clasen wrote: > On Wed, 2008-07-09 at 15:35 +0200, Michael Schwendt wrote: > > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, > > which are assigned to S?ren Sandmann Pedersen, but the package > > changelog shows the names of other maintainers. One of the bug > > reports is one year old already. The other one is mine. > > > > Who owns libgtop2? > > > > Since you were already at bugz.fd.o, it wouldn't have cost you much to > head over to > https://admin.fedoraproject.org/pkgdb/packages/name/libgtop2 > to find out. To find out what? None of the persons listed there have requested "watchbugzilla". > Soeren owns it. Last activity in %changelog has been in 2006. > I do most of the version updates when I do mass updates. As can be seen in the changelog, but that doesn't answer whether bugzilla might be the same as /dev/null. Instead, I queried bugzilla for old closed tickets and that didn't answer my question either. From kevin.kofler at chello.at Wed Jul 9 14:09:18 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 9 Jul 2008 14:09:18 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215611684.14926.90.camel@rosebud> Message-ID: seth vidal fedoraproject.org> writes: > On Wed, 2008-07-09 at 13:52 +0000, Kevin Kofler wrote: > > I hope packages which FTBFS (only) due to this and/or the patch fuzz issue > > won't be considered for the FTFBS package elimination in a week, otherwise > > we'll end up with half the distro removed! > > You say that like it is a bad thing... :) It is! Sorry, but in the real world, people want software, not some minor cleanups they couldn't care less about if they weren't forced by the latest RPM, GCC or whatever. ;-) And in this case, it would be even worse because this change is about to hit Rawhide now that the FTBFS deadline is looming and that several people are likely already on their summer vacation. So the fact that a package fails to build due to the new RPM is a very bad indicator of maintainer (non-)responsiveness at this point. Kevin Kofler From mclasen at redhat.com Wed Jul 9 14:11:03 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 10:11:03 -0400 Subject: libgtop2 - who owns it? In-Reply-To: <20080709160911.fcb33243.mschwendt@gmail.com> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> Message-ID: <1215612663.3233.8.camel@localhost.localdomain> On Wed, 2008-07-09 at 16:09 +0200, Michael Schwendt wrote: > > As can be seen in the changelog, but that doesn't answer whether > bugzilla might be the same as /dev/null. > True. But you didn't ask that question... From jkeating at redhat.com Wed Jul 9 14:17:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Jul 2008 10:17:21 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215611684.14926.90.camel@rosebud> Message-ID: <1215613041.3274.4.camel@localhost.localdomain> On Wed, 2008-07-09 at 14:09 +0000, Kevin Kofler wrote: > > And in this case, it would be even worse because this change is about to hit > Rawhide now that the FTBFS deadline is looming and that several people are > likely already on their summer vacation. So the fact that a package fails to > build due to the new RPM is a very bad indicator of maintainer > (non-)responsiveness at this point. The maintainer just has to make some effort, like noting in the bug that it's an rpm issue, and bam, no longer non-responsive. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 dan at danny.cz Wed Jul 9 14:20:05 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 09 Jul 2008 16:20:05 +0200 Subject: libgtop2 - who owns it? In-Reply-To: <20080709160911.fcb33243.mschwendt@gmail.com> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> Message-ID: <1215613205.3262.15.camel@localhost.localdomain> Michael Schwendt p??e v St 09. 07. 2008 v 16:09 +0200: > On Wed, 09 Jul 2008 09:51:51 -0400, Matthias Clasen wrote: > > > On Wed, 2008-07-09 at 15:35 +0200, Michael Schwendt wrote: > > > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, > > > which are assigned to S?ren Sandmann Pedersen, but the package > > > changelog shows the names of other maintainers. One of the bug > > > reports is one year old already. The other one is mine. > > > > > > Who owns libgtop2? > > > > > > > Since you were already at bugz.fd.o, it wouldn't have cost you much to > > head over to > > https://admin.fedoraproject.org/pkgdb/packages/name/libgtop2 > > to find out. > > To find out what? None of the persons listed there have requested > "watchbugzilla". > That's probably a relict of initial loading of pkgdb with packages from Fedora Core that were maintained by Red Hat engineers. More packages are affected by this (and even more non-logical) setup. Dan From mschwendt at gmail.com Wed Jul 9 14:21:43 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 9 Jul 2008 16:21:43 +0200 Subject: libgtop2 - who owns it? In-Reply-To: <1215612663.3233.8.camel@localhost.localdomain> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> <1215612663.3233.8.camel@localhost.localdomain> Message-ID: <20080709162143.d86d7958.mschwendt@gmail.com> On Wed, 09 Jul 2008 10:11:03 -0400, Matthias Clasen wrote: > > As can be seen in the changelog, but that doesn't answer whether > > bugzilla might be the same as /dev/null. > > > > True. > > But you didn't ask that question... No, but with the answer to my question I have got the confirmation that the current ownership is supposed to be accurate, up-to-date, correct. From dr.diesel at gmail.com Wed Jul 9 14:21:35 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 9 Jul 2008 10:21:35 -0400 Subject: Install dies at waiting for hardware to init - sorta In-Reply-To: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> References: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> Message-ID: <2a28d2ab0807090721j5786c54et5d2eea0b67a17b30@mail.gmail.com> Several messages to and from Mark Lord, the sata_mv driver is not what is causing the install to hang. Also the Highpoint problems of overwritten sectors seem to only be a problem if you boot/load grub/lilo on the array. Is it possible to boot with a kernel argument that bypassed sata_mv? Something like sata_mv=0 or something? I know I can blacklist it, but what can I do for an installation? Thanks Andy On Mon, Jul 7, 2008 at 11:21 AM, Dr. Diesel wrote: > Attempting to install F9 I386 on a system with two HighPoint > RocketRaid 2220 8-Port devices. During the very first part of the > install (installing from a USB DVD-ROM) the install hangs for ~10 > minutes on the waiting for hardware to initialize. Once done it pops > up with a messing asking me to define which driver to use for the > install media, it can't see/find any devices, even the MB IDE/SATA or > USB DVD. > > I'm guessing it gets really confused during the hardware init somehow. > The first part of the install works, just forgets where it was > installing from! > > Any work-a-rounds or is this a bug? I'd like to learn how to do this > without pulling the HighPoint cards for the install? > > Thanks > Andy > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From rc040203 at freenet.de Wed Jul 9 14:23:34 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jul 2008 16:23:34 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4874C3B7.7090603@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1215599413.2809.477.camel@beck.corsepiu.local> <4874C3B7.7090603@redhat.com> Message-ID: <1215613414.2809.501.camel@beck.corsepiu.local> On Wed, 2008-07-09 at 09:57 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ralf Corsepius wrote: > | On Wed, 2008-07-09 at 11:58 +0200, Nils Philippsen wrote: > | > |> One question nobody has been able to answer to my satisfaction yet: Why > |> would it be essential that SELinux can be disabled from the installer > |> vs. from the installed system? > | One point: Once SELinux had been active, it can cause problems, despite > | it had been disabled, afterwards: > | C.f.: https://bugzilla.redhat.com/show_bug.cgi?id=453365 > | > | Ralf > | > | > This is a bug in code, and I am not sure this would not have happened if > SELinux was disabled in the first place. Neither am I. My point is: kernel-/filesystem-side of SELinux apparently is not entirely transparent to applications and may disturb "arbitrary, known to work" applications, even if SELinux is off. In my case, I repeatedly had SELinux active on the machine exposing the issue from the BZ, and had encountered the broken "patch" after having switched SELinux off. Having a look into the patch, which seems to have fixed "patch", I am inclined to think the actual cause for this breakdown is inside of the kernel or the filesystem. Ralf From sundaram at fedoraproject.org Wed Jul 9 14:43:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 Jul 2008 20:13:50 +0530 Subject: OLPC & package dependency growth In-Reply-To: <1215612444.3233.7.camel@localhost.localdomain> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215612444.3233.7.camel@localhost.localdomain> Message-ID: <4874CEA6.8060108@fedoraproject.org> Matthias Clasen wrote: > On Wed, 2008-07-09 at 09:42 -0400, Daniel Drake wrote: > >> I guess some of these extra dependency chains are hard to predict/avoid >> but it would be good to raise awareness here. It would also be great if >> people could help us slim our F9 builds back to acceptable sizes, since >> we are nearing release-candidate phase. > >>From what I recall, we (or rather the olpc team) did quite a bit of > dependency pruning back in the F7 timeframe to get the olpc image as > small as it it. Realistically, you'll have to keep fighting this by > filing bugs and pointing out package split candidates, since these deps > have the tendency to grow back. Right. Live CD's tend to keep things somewhat in check but this is a ongoing process and constant struggle. Rahul From benny+usenet at amorsen.dk Wed Jul 9 14:51:05 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 09 Jul 2008 16:51:05 +0200 Subject: CVE-2008-1447 v. glibc References: <1215567143.2819.21.camel@shrek.rexursive.com> <935ead450807081846n2100bee5ycaff21fb78a7afd2@mail.gmail.com> <20080709113838.GA5110@traged.atkac.englab.brq.redhat.com> Message-ID: Adam Tkac writes: > In my opinion endpoint stub resolvers are not so vulnerable. If you want > spoof DNS data to resolver you have to force that resolver to > send query for name that you know This part is generally not a problem. I can think of several ways to achieve that, and I am sure that there are minds more devious than mine. /Benny From seg at haxxed.com Wed Jul 9 14:52:49 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 9 Jul 2008 09:52:49 -0500 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215597493.29818.11.camel@wombat.tiptoe.de> References: <1215029424.5130.13.camel@perihelion> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> Message-ID: <1218b5bc0807090752x8a73d62mbc4bdaf6056a91e0@mail.gmail.com> On Wed, Jul 9, 2008 at 4:58 AM, Nils Philippsen wrote: > On Mon, 2008-07-07 at 18:50 +0200, Denis Leroy wrote: > >> However sabotaging the installer to make it impossible for people to >> disable it at installation, now that's where I say "that doesn't make >> any sense", cf my original email. > > "Sabotaging"? For crying out loud... there is no immediate need to be > able to do this at installation time, it can just as well be done > afterwards (or you can use kickstart to do it). > > One question nobody has been able to answer to my satisfaction yet: Why > would it be essential that SELinux can be disabled from the installer > vs. from the installed system? Last time I checked, the plan was to get > non-essential functionality out of anaconda. Because booting with selinux enabled after installing onto a filesystem such as reiserfs that doesn't work with selinux results in epic fail. As in, you can not log in. Though you can get around this by booting with selinux=0 on the kernel command line... Though I haven't done this since something like FC6. I migrated to ext3 so I could use selinux. And while I'm at it, I'll provide a counterpoint and point out that I've run all my machines, including my wife's laptop, with selinux enabled since FC6. I've never, ever run in to any problem. Ever. I don't know what you people are doing, but you must be doing it wrong. From mclasen at redhat.com Wed Jul 9 14:57:56 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 10:57:56 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Message-ID: <1215615476.3233.12.camel@localhost.localdomain> Daniel, we are looking at splitting gvfs a bit more finegrained for F10, but doing such a split in the middle of a stable release is somewhat hard to do, so some forking may be necessary for F9. But if we work through these issues now, your F11 upgrade may be a lot easier... From cra at WPI.EDU Wed Jul 9 14:58:57 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 9 Jul 2008 10:58:57 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1218b5bc0807090752x8a73d62mbc4bdaf6056a91e0@mail.gmail.com> References: <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1218b5bc0807090752x8a73d62mbc4bdaf6056a91e0@mail.gmail.com> Message-ID: <20080709145857.GB3088@angus.ind.WPI.EDU> On Wed, Jul 09, 2008 at 09:52:49AM -0500, Callum Lerwick wrote: > Because booting with selinux enabled after installing onto a > filesystem such as reiserfs that doesn't work with selinux results in > epic fail. As in, you can not log in. Though you can get around this > by booting with selinux=0 on the kernel command line... I think reiserfs supports selinux now. > Though I haven't done this since something like FC6. I migrated to > ext3 so I could use selinux. > > And while I'm at it, I'll provide a counterpoint and point out that > I've run all my machines, including my wife's laptop, with selinux > enabled since FC6. I've never, ever run in to any problem. Ever. I > don't know what you people are doing, but you must be doing it wrong. Not wrong, just out of the norm. If you keep things in the standard directories and use mostly default configs, you generally don't have problems. From dwalsh at redhat.com Wed Jul 9 15:04:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Jul 2008 11:04:28 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215613414.2809.501.camel@beck.corsepiu.local> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1215599413.2809.477.camel@beck.corsepiu.local> <4874C3B7.7090603@redhat.com> <1215613414.2809.501.camel@beck.corsepiu.local> Message-ID: <4874D37C.5080305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: | On Wed, 2008-07-09 at 09:57 -0400, Daniel J Walsh wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Ralf Corsepius wrote: |> | On Wed, 2008-07-09 at 11:58 +0200, Nils Philippsen wrote: |> | |> |> One question nobody has been able to answer to my satisfaction yet: Why |> |> would it be essential that SELinux can be disabled from the installer |> |> vs. from the installed system? |> | One point: Once SELinux had been active, it can cause problems, despite |> | it had been disabled, afterwards: |> | C.f.: https://bugzilla.redhat.com/show_bug.cgi?id=453365 |> | |> | Ralf |> | |> | |> This is a bug in code, and I am not sure this would not have happened if |> SELinux was disabled in the first place. | | Neither am I. | | My point is: kernel-/filesystem-side of SELinux apparently is not | entirely transparent to applications and may disturb "arbitrary, known | to work" applications, even if SELinux is off. | | In my case, I repeatedly had SELinux active on the machine exposing the | issue from the BZ, and had encountered the broken "patch" after having | switched SELinux off. | | Having a look into the patch, which seems to have fixed "patch", I am | inclined to think the actual cause for this breakdown is inside of the | kernel or the filesystem. | | Ralf | | Well the problem was in the patch code, that did not check to see if SELinux was disabled or not. When it tried to SELinux stuff, with SELinux disabled it failed. Simple bug in the patch code. So this bug will happen whenever SELinux was disabled. Whether or not you disabled it during install or post install. So your example of why SELinux needs to be able to be disabled in Anaconda is flawed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh003wACgkQrlYvE4MpobNx5QCgpkyhXFAkQuiRQ5maL04chZnO otIAnRKecZmITBKhzDm+HBTAVNn8aQZp =q8No -----END PGP SIGNATURE----- From dennis at ausil.us Wed Jul 9 15:05:05 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 9 Jul 2008 10:05:05 -0500 Subject: OLPC & package dependency growth In-Reply-To: <1215615476.3233.12.camel@localhost.localdomain> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> Message-ID: <200807091005.19175.dennis@ausil.us> On Wednesday 09 July 2008, Matthias Clasen wrote: > Daniel, > > we are looking at splitting gvfs a bit more finegrained for F10, but > doing such a split in the middle of a stable release is somewhat hard to > do, so some forking may be necessary for F9. > > But if we work through these issues now, your F11 upgrade may be a lot > easier... Ive been taking steps so that OLPC will be able to track rawhide always. this should help make it easier to keep track of image bloat. hopefully there will be a F10 based build -- Dennis Gilmore -------------- 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 berrange at redhat.com Wed Jul 9 15:10:49 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 16:10:49 +0100 Subject: OLPC & package dependency growth In-Reply-To: <200807091005.19175.dennis@ausil.us> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> Message-ID: <20080709151049.GA14415@redhat.com> On Wed, Jul 09, 2008 at 10:05:05AM -0500, Dennis Gilmore wrote: > On Wednesday 09 July 2008, Matthias Clasen wrote: > > Daniel, > > > > we are looking at splitting gvfs a bit more finegrained for F10, but > > doing such a split in the middle of a stable release is somewhat hard to > > do, so some forking may be necessary for F9. > > > > But if we work through these issues now, your F11 upgrade may be a lot > > easier... > Ive been taking steps so that OLPC will be able to track rawhide always. > this should help make it easier to keep track of image bloat. hopefully there > will be a F10 based build We could sure use some scripts to anaylse RPM deps on a nightly basis and produces reports on interesting stats. eg disk footprint of the chain starting from package 'X', or list of dependancies from package 'X', or perhaps something that given a kickstart file can report the total size of the package set listed in the kickstart without actually going through the full livecd (or equiv) build process. We are fighting a similar battle to OLPC with the oVirt project which has a live CD we're trying to keep under 64 MB in size. Dainel -- |: 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 rc040203 at freenet.de Wed Jul 9 15:22:38 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jul 2008 17:22:38 +0200 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4874D37C.5080305@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1215599413.2809.477.camel@beck.corsepiu.local> <4874C3B7.7090603@redhat.com> <1215613414.2809.501.camel@beck.corsepiu.local> <4874D37C.5080305@redhat.com> Message-ID: <1215616958.2809.516.camel@beck.corsepiu.local> On Wed, 2008-07-09 at 11:04 -0400, Daniel J Walsh wrote: > So this bug will happen whenever SELinux was disabled. Note: This bug ... provided the fact SELinux is not transparent ... can you exclude other cases? > Whether or not > you disabled it during install or post install. So your example of why > SELinux needs to be able to be disabled in Anaconda is flawed. May-be, may-be not, ... I may be wrong in this particular case, but otherwise I disagree with you - I regret having to say this, but I've been too often hit issues with SELinux-policies in all the years SELinux is in Fedora to have grant it much trust. Anyway, another case: SELinux's run-time memory consumption is too big for some classes of (low end) HW. Related to it: I had experienced cases where selinux-policy updates took hours and occasionally caused kernel oops'es. Ralf From kanarip at kanarip.com Wed Jul 9 15:31:46 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 09 Jul 2008 17:31:46 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> Message-ID: <4874D9E2.7090807@kanarip.com> Fabio M. Di Nitto wrote: > On Tue, 2008-07-08 at 09:58 +0300, David Juran wrote: >> On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: >>> Please review the following packages. This is roughly the list of >>> current orphans in rawhide. If they are not claimed by June 18th then >>> they may be removed from rawhide by the F10 Alpha freeze. >>> perl-Net-Telnet >> perl-Net-Telnet is required by several of the fencing agents included in >> the cman rpm. >> > > Oh I missed this one.. I will take it if nobody else wants it. > I'm willing to (co-)maintain this... can we make it a group effort in keeping this in? Kind regards, Jeroen van Meeuwen -kanarip From sds at tycho.nsa.gov Wed Jul 9 15:43:05 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 09 Jul 2008 11:43:05 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <20080709145857.GB3088@angus.ind.WPI.EDU> References: <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1218b5bc0807090752x8a73d62mbc4bdaf6056a91e0@mail.gmail.com> <20080709145857.GB3088@angus.ind.WPI.EDU> Message-ID: <1215618185.31554.6.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-07-09 at 10:58 -0400, Chuck Anderson wrote: > On Wed, Jul 09, 2008 at 09:52:49AM -0500, Callum Lerwick wrote: > > Because booting with selinux enabled after installing onto a > > filesystem such as reiserfs that doesn't work with selinux results in > > epic fail. As in, you can not log in. Though you can get around this > > by booting with selinux=0 on the kernel command line... > > I think reiserfs supports selinux now. Unfortunately not. It did briefly, but then things broke again. reiserfs support has never been a priority for the selinux maintainers, and selinux support was never a priority for the reiserfs maintainers. I believe though that all of the other major filesystems should work with selinux these days (ext[2-4], jfs, xfs, jffs2, gfs2); if not, that's a bug that should be reported. > > Though I haven't done this since something like FC6. I migrated to > > ext3 so I could use selinux. > > > > And while I'm at it, I'll provide a counterpoint and point out that > > I've run all my machines, including my wife's laptop, with selinux > > enabled since FC6. I've never, ever run in to any problem. Ever. I > > don't know what you people are doing, but you must be doing it wrong. > > Not wrong, just out of the norm. If you keep things in the standard > directories and use mostly default configs, you generally don't have > problems. But these days users should be able to address such deviations from the norm by running a couple of semanage commands (or system-config-selinux if they prefer GUIs) and/or creating a local loadable policy module using audit2allow. -- Stephen Smalley National Security Agency From skvidal at fedoraproject.org Wed Jul 9 15:44:23 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Jul 2008 11:44:23 -0400 Subject: OLPC & package dependency growth In-Reply-To: <20080709151049.GA14415@redhat.com> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> Message-ID: <1215618263.14926.100.camel@rosebud> On Wed, 2008-07-09 at 16:10 +0100, Daniel P. Berrange wrote: > We could sure use some scripts to anaylse RPM deps on a nightly basis > and produces reports on interesting stats. eg disk footprint of the > chain starting from package 'X', or list of dependancies from package > 'X', or perhaps something that given a kickstart file can report > the total size of the package set listed in the kickstart without > actually going through the full livecd (or equiv) build process. We > are fighting a similar battle to OLPC with the oVirt project which > has a live CD we're trying to keep under 64 MB in size. Taking a list of pkgs, resolving out all of their deps then calculating installed size (not calculating vs an existing install, but raw installed size) shouldn't take too much code at all. I'll see what I can hack up today. It won't take into account overlaid files (like docs and manpages, nor multilib binaries) but it should give you a pretty good upper range (sort of). -sv From ovasik at redhat.com Wed Jul 9 15:54:57 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Wed, 09 Jul 2008 17:54:57 +0200 Subject: kernel build failures. In-Reply-To: References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> Message-ID: <1215618897.3934.6.camel@dhcp-lab-219.englab.brq.redhat.com> KH KH wrote: > 2008/7/7 Thomas Moschny : > > 2008/7/7 Nicolas Mailhot : > >> > >> Le Lun 7 juillet 2008 04:25, Bruno Wolff III a ?crit : > >> > >>> It would be nice if this was redesigned so that each package put its > >>> data in a separate file rather than mixing stuff. > >> > >> That's mostly the case today. The catalog is just an index file with > >> 1-line references to package-specific data > > > > But unless there's an easy way to cleanly rebuild this index from > > scratch, that's still as bad as embedding (mixing) all data in one > > single file. > > > > The DTDs/schemas are not found when not mentioned in the catalog, right? > > Does this problem has been solved ? > I have this package failing: (even if i add : > %if 0%{?fedora} > 9 > BuildRequires: docbook-dtds > %endif ) > http://koji.fedoraproject.org/koji/taskinfo?taskID=702885 > > /builddir/build/BUILD/lcdproc-0.5.2/docs/lcdproc-dev/lcdproc-dev.docbook:12: > warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" Sorry for troubles with xmlcatalog/docbook-dtds. Everything got broken once I got bugzilla about rpm -V complaints about sgml-common/xml-common catalog files. This caused broken xmlcatalog file in existing installation - as the xmlcatalog was modified and replaced full catalog of xml-dtd's with brand new empty one. I decided to mark it config(noreplace) to prevent such things in future. Because of policy no config(noreplace) in /usr/ I moved xmlcatalog to /etc/sgml/docbook/ and created symlink. But because entries from docbook-dtds were not with full path, they were not found. New docbook-dtds with full paths to xml-dtd's should solve the troubles. Sorry once more time... Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From berrange at redhat.com Wed Jul 9 16:03:21 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 9 Jul 2008 17:03:21 +0100 Subject: OLPC & package dependency growth In-Reply-To: <1215618263.14926.100.camel@rosebud> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> Message-ID: <20080709160321.GD14415@redhat.com> On Wed, Jul 09, 2008 at 11:44:23AM -0400, seth vidal wrote: > On Wed, 2008-07-09 at 16:10 +0100, Daniel P. Berrange wrote: > > We could sure use some scripts to anaylse RPM deps on a nightly basis > > and produces reports on interesting stats. eg disk footprint of the > > chain starting from package 'X', or list of dependancies from package > > 'X', or perhaps something that given a kickstart file can report > > the total size of the package set listed in the kickstart without > > actually going through the full livecd (or equiv) build process. We > > are fighting a similar battle to OLPC with the oVirt project which > > has a live CD we're trying to keep under 64 MB in size. > > Taking a list of pkgs, resolving out all of their deps then calculating > installed size (not calculating vs an existing install, but raw > installed size) shouldn't take too much code at all. I'll see what I can > hack up today. Extra points if you round up the sizes to 4k to take account of the typical ext3 blocksize which adds extra storage overhead for small files. Rolling nigh-to-night, or week-to-week diffs of size growth or shrinkage would be fun too 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 bpepple at fedoraproject.org Wed Jul 9 16:08:28 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 09 Jul 2008 12:08:28 -0400 Subject: Plan for tomorrows (20080710) FESCO meeting Message-ID: <1215619708.2519.4.camel@truman> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- Secondary Arches Releases and FESCo's role over them -- all /topic FESCo-Meeting -- Application approvals for cvsadmin - f13 /topic FESCo-Meeting -- F10 Feature - https://fedoraproject.org/wiki/Features/GoodHaskellSupport -- poelcat /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rhl+dale at riyescott.com Wed Jul 9 16:12:27 2008 From: rhl+dale at riyescott.com (Dale Stimson) Date: Wed, 9 Jul 2008 09:12:27 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <20080709161226.GA9444@cupro.opengvs.com> On Wed, Jul 09, 2008 at 01:51:15PM +0300, Panu Matilainen wrote: > At long last, we are about to get a brand new RPM version (alpha snapshot > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > and a full summary needs a separate posting (will follow as time > permits), this is just a heads-up of immediate consequences for Fedora > packagers and rawhide consumers: [snip] Something I would like to see standard in RPM is for the default for installation of source files from a .src.rpm file to be changed from %{_sourcedir} to %{_sourcedir}/%{name}-%{version} (The above example assumes the current definition of _sourcedir, which the suggested implementation below proposes be changed). With the above, multiple .src.rpm files could be installed simultaneously without mixing their files in SOURCES. Suggested implementation: Change the definition of _sourcedir from %_sourcedir %{_topdir}/SOURCES/ to %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} I've done this in my .rpmmacros file for a long time and am happy with it. From jwilson at redhat.com Wed Jul 9 16:28:00 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 9 Jul 2008 12:28:00 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080709161226.GA9444@cupro.opengvs.com> References: <20080709161226.GA9444@cupro.opengvs.com> Message-ID: <200807091228.00498.jwilson@redhat.com> On Wednesday 09 July 2008 12:12:27 pm Dale Stimson wrote: > On Wed, Jul 09, 2008 at 01:51:15PM +0300, Panu Matilainen wrote: > > At long last, we are about to get a brand new RPM version (alpha snapshot > > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > > and a full summary needs a separate posting (will follow as time > > permits), this is just a heads-up of immediate consequences for Fedora > > packagers and rawhide consumers: > > [snip] > > Something I would like to see standard in RPM is for the default for > installation of source files from a .src.rpm file to be changed from > %{_sourcedir} > to > %{_sourcedir}/%{name}-%{version} > > (The above example assumes the current definition of _sourcedir, > which the suggested implementation below proposes be changed). > > With the above, multiple .src.rpm files could be installed simultaneously > without mixing their files in SOURCES. > > Suggested implementation: > > Change the definition of _sourcedir from > %_sourcedir %{_topdir}/SOURCES/ > to > %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} > > I've done this in my .rpmmacros file for a long time and am happy with it. Been doing something similar myself for ages, but also dropping the spec file in with the source files. A directory full of specs and a directory full of sources for umpteen different packages is dumb. -- Jarod Wilson jwilson at redhat.com From rjones at redhat.com Wed Jul 9 16:29:47 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 9 Jul 2008 17:29:47 +0100 Subject: OLPC & package dependency growth In-Reply-To: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Message-ID: <20080709162947.GA23323@amd.home.annexia.org> On Wed, Jul 09, 2008 at 09:42:35AM -0400, Daniel Drake wrote: > I guess some of these extra dependency chains are hard to predict/avoid > but it would be good to raise awareness here. It would also be great if > people could help us slim our F9 builds back to acceptable sizes, since > we are nearing release-candidate phase. oVirt folk also have the same problem. 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 pmatilai at redhat.com Wed Jul 9 16:36:53 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 19:36:53 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: On Wed, 9 Jul 2008, Kevin Kofler wrote: > Panu Matilainen redhat.com> writes: >> Packagers: > 8) Unnumbered Source: and Patch: are no longer accepted, you have to explicitly > write Source0: resp. Patch: (unless I misunderstood this commit: > http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commit;h=724b07bba5e802998b1b79b408c2401d2a238a3b ). The commit message is a bit misleading, it's mostly about how rpmbuild deals with those internally. You're unlikely to notice anything at all, the change just makes some previously misleading errors more clear. > I hope packages which FTBFS (only) due to this and/or the patch fuzz issue > won't be considered for the FTFBS package elimination in a week, otherwise > we'll end up with half the distro removed! :-( Package maintainers can set a less strict fuzz for their packages if they see fit - or fedora buildsys can override the rpm default .. that's pretty much up to FPC and the like to decide. 0 is just the upstream default. - Panu - From pmatilai at redhat.com Wed Jul 9 16:41:20 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 19:41:20 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215612241.10164.17.camel@localhost.localdomain> References: <1215612241.10164.17.camel@localhost.localdomain> Message-ID: On Wed, 9 Jul 2008, Tom "spot" Callaway wrote: > On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: >> 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under >> %{_topdir}/BUILDROOT/ > > A few questions here: > > Is the BuildRoot from the spec ignored, or does it override the default > buildroot? BuildRoot from spec is completely ignored. > Is the default buildroot literally "%{_topdir}/BUILDROOT/" or is it > something more complicated. I could easily see a case where two > concurrent rpm builds could step on each other's buildroots. The default buildroot is currently defined literally this way: %buildrootdir %{_topdir}/BUILDROOT %buildroot %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch} Concurrent rpm builds shouldn't step on each others toes, unless you're sharing your %_topdir with other people (in which case you'd better know what you're doing anyway :) - Panu - From katzj at redhat.com Wed Jul 9 16:45:39 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 09 Jul 2008 12:45:39 -0400 Subject: OLPC & package dependency growth In-Reply-To: <20080709151049.GA14415@redhat.com> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> Message-ID: <1215621939.13098.37.camel@aglarond.local> On Wed, 2008-07-09 at 16:10 +0100, Daniel P. Berrange wrote: > We could sure use some scripts to anaylse RPM deps on a nightly basis > and produces reports on interesting stats. eg disk footprint of the > chain starting from package 'X', or list of dependancies from package > 'X', or perhaps something that given a kickstart file can report > the total size of the package set listed in the kickstart without > actually going through the full livecd (or equiv) build process. We > are fighting a similar battle to OLPC with the oVirt project which > has a live CD we're trying to keep under 64 MB in size. I basically do this with some scripts against the live cds which I build (nearly) daily. I could work on actually getting that information into a more consumable form rather than just doing it on an "I saw the livecd grew, what happened this time" basis Jeremy From cra at WPI.EDU Wed Jul 9 16:47:28 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 9 Jul 2008 12:47:28 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <200807091228.00498.jwilson@redhat.com> References: <20080709161226.GA9444@cupro.opengvs.com> <200807091228.00498.jwilson@redhat.com> Message-ID: <20080709164728.GD3088@angus.ind.WPI.EDU> On Wed, Jul 09, 2008 at 12:28:00PM -0400, Jarod Wilson wrote: > On Wednesday 09 July 2008 12:12:27 pm Dale Stimson wrote: > > On Wed, Jul 09, 2008 at 01:51:15PM +0300, Panu Matilainen wrote: > > > At long last, we are about to get a brand new RPM version (alpha snapshot > > > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > > > and a full summary needs a separate posting (will follow as time > > > permits), this is just a heads-up of immediate consequences for Fedora > > > packagers and rawhide consumers: > > > > [snip] > > > > Something I would like to see standard in RPM is for the default for > > installation of source files from a .src.rpm file to be changed from > > %{_sourcedir} > > to > > %{_sourcedir}/%{name}-%{version} > > > > (The above example assumes the current definition of _sourcedir, > > which the suggested implementation below proposes be changed). > > > > With the above, multiple .src.rpm files could be installed simultaneously > > without mixing their files in SOURCES. > > > > Suggested implementation: > > > > Change the definition of _sourcedir from > > %_sourcedir %{_topdir}/SOURCES/ > > to > > %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} > > > > I've done this in my .rpmmacros file for a long time and am happy with it. > > Been doing something similar myself for ages, but also dropping the spec file > in with the source files. A directory full of specs and a directory full of > sources for umpteen different packages is dumb. +1. This has been my .rpmmacros for years: %_topdir /home/cra/src/redhat %_ntopdir %{_topdir}/%{name}-%{version}-%{release} %_builddir %{_ntopdir} %_sourcedir %{_ntopdir} %_specdir %{_ntopdir} %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm %_rpmdir %{_topdir}/RPMS %_srcrpmdir %{_topdir}/SRPMS It does mean I have to mv the _ntopdir every time I bump the version/release in the spec, and also have to deal with the value of %{?dist} in the directory name, but I think these little things are worth it. From nikolay at vladimiroff.com Wed Jul 9 17:01:05 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 9 Jul 2008 20:01:05 +0300 Subject: swfdec-gnome Message-ID: <20080709170105.GA11497@marvin> Hi! I noticed that swfdec-gnome is broken in rawhide. It doesn't build with new swfdec-0.7.2. I contacted upstream and: On (09/07/08 16:13), Benjamin Otte wrote: > Hrm yeah, I didn't think about doing a new swfdec-gnome release. I > forgot that unstable distro branches depend on it being available. > I'm at GUADEC currently, so I'm not gonna do a release right now, but > expect one at the latest when we release 0.7.4. For now, your solution > of just patching configure.ac should work fine. > > Cheers, > Benjamin So if there are no objections I'll update swfdec-gnome and apply the patch. P.S. I'm not the package maintainer for swfdec-gnome. -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jspaleta at gmail.com Wed Jul 9 17:04:07 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 09:04:07 -0800 Subject: OLPC & package dependency growth In-Reply-To: <1215621939.13098.37.camel@aglarond.local> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215621939.13098.37.camel@aglarond.local> Message-ID: <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> On Wed, Jul 9, 2008 at 8:45 AM, Jeremy Katz wrote: > I basically do this with some scripts against the live cds which I build > (nearly) daily. I could work on actually getting that information into > a more consumable form rather than just doing it on an "I saw the livecd > grew, what happened this time" basis I would imagine this will be generally useful for anyone working on a spin. How automated can you make your scripts and can we tie them into the daily rawhide gearage? Would you be able to automate this to run daily against a collection of kickstart file targets to estimate total packageset size and then poop that out those number as a data point on a time history graph to be displayed at a fedoraproject url? -jef From bpepple at fedoraproject.org Wed Jul 9 17:04:06 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 09 Jul 2008 13:04:06 -0400 Subject: swfdec-gnome In-Reply-To: <20080709170105.GA11497@marvin> References: <20080709170105.GA11497@marvin> Message-ID: <1215623046.2519.6.camel@truman> On Wed, 2008-07-09 at 20:01 +0300, Nikolay Vladimirov wrote: > Hi! > I noticed that swfdec-gnome is broken in rawhide. > It doesn't build with new swfdec-0.7.2. I contacted upstream and: > > On (09/07/08 16:13), Benjamin Otte wrote: > > Hrm yeah, I didn't think about doing a new swfdec-gnome release. I > > forgot that unstable distro branches depend on it being available. > > I'm at GUADEC currently, so I'm not gonna do a release right now, but > > expect one at the latest when we release 0.7.4. For now, your solution > > of just patching configure.ac should work fine. > > > > Cheers, > > Benjamin > > So if there are no objections I'll update swfdec-gnome and apply the > patch. That's fine, it's on my list of things to work on. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Jul 9 17:06:39 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 09:06:39 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215612241.10164.17.camel@localhost.localdomain> Message-ID: <604aa7910807091006k2469bd94h7c0edd1188887901@mail.gmail.com> On Wed, Jul 9, 2008 at 8:41 AM, Panu Matilainen wrote: > Concurrent rpm builds shouldn't step on each others toes, unless you're > sharing your %_topdir with other people (in which case you'd better know > what you're doing anyway :) Speaking from complete and utter ignorance.... does this change impact how our build system works? -jef From pmatilai at redhat.com Wed Jul 9 17:07:27 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 20:07:27 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215605663.27720.112.camel@dimi.lattica.com> References: <1215605663.27720.112.camel@dimi.lattica.com> Message-ID: On Wed, 9 Jul 2008, Dimi Paun wrote: > > On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: >> At long last, we are about to get a brand new RPM version (alpha >> snapshot at the moment) into rawhide. The list of changes from 4.4.2.x >> is massive and a full summary needs a separate posting (will follow as >> time permits) > > Thanks Panu, > > This is way cool! I'm glad to see so many needed changes being > addressed. I'd be interested in the full list of changes, > if you can find the time to put it together. This is nowhere near complete, but it's a start: http://wiki.rpm.org/Releases/4.5.90 Wl'll be updating it as time permits, collecting over a years worth of development (over 2300 commits since 4.4.x was branched to maintenance mode) into something remotely structured and understandable is a non-trivial task :) - Panu - From billcrawford1970 at gmail.com Wed Jul 9 17:15:47 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 9 Jul 2008 18:15:47 +0100 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <200807091228.00498.jwilson@redhat.com> References: <20080709161226.GA9444@cupro.opengvs.com> <200807091228.00498.jwilson@redhat.com> Message-ID: <544eb990807091015x48f4e572mb6ff4872178bfa95@mail.gmail.com> 2008/7/9 Jarod Wilson : > On Wednesday 09 July 2008 12:12:27 pm Dale Stimson wrote: >> [snip] >> Something I would like to see standard in RPM is for the default for >> installation of source files from a .src.rpm file to be changed from >> %{_sourcedir} >> to >> %{_sourcedir}/%{name}-%{version} >> >> (The above example assumes the current definition of _sourcedir, >> which the suggested implementation below proposes be changed). [snip] >> %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} >> >> I've done this in my .rpmmacros file for a long time and am happy with it. > Been doing something similar myself for ages, but also dropping the spec file > in with the source files. A directory full of specs and a directory full of > sources for umpteen different packages is dumb. This breaks doing build-from-tarball, because until the spec is parsed, the version is unknown. From ville.skytta at iki.fi Wed Jul 9 17:16:05 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 9 Jul 2008 20:16:05 +0300 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <200807092016.05734.ville.skytta@iki.fi> On Wednesday 09 July 2008, Panu Matilainen wrote: > At long last, we are about to get a brand new RPM version (alpha snapshot > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > and a full summary needs a separate posting (will follow as time permits), > this is just a heads-up of immediate consequences for Fedora packagers and > rawhide consumers: Sounds great, thanks! From billcrawford1970 at gmail.com Wed Jul 9 17:17:43 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 9 Jul 2008 18:17:43 +0100 Subject: OLPC & package dependency growth In-Reply-To: <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215621939.13098.37.camel@aglarond.local> <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> Message-ID: <544eb990807091017l149041d3gaea11ce69be3797c@mail.gmail.com> 2008/7/9 Jeff Spaleta : > I would imagine this will be generally useful for anyone working on a spin. > How automated can you make your scripts and can we tie them into the > daily rawhide gearage? Would you be able to automate this to run daily > against a collection of kickstart file targets to estimate total > packageset size and then poop that out those number as a data point on > a time history graph to be displayed at a fedoraproject url? Wouldn't it be easiest to simply do the install to a VM and look at the actual disk usage? This avoids guesswork ... From pmatilai at redhat.com Wed Jul 9 17:19:02 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 20:19:02 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807091006k2469bd94h7c0edd1188887901@mail.gmail.com> References: <1215612241.10164.17.camel@localhost.localdomain> <604aa7910807091006k2469bd94h7c0edd1188887901@mail.gmail.com> Message-ID: On Wed, 9 Jul 2008, Jeff Spaleta wrote: > On Wed, Jul 9, 2008 at 8:41 AM, Panu Matilainen wrote: >> Concurrent rpm builds shouldn't step on each others toes, unless you're >> sharing your %_topdir with other people (in which case you'd better know >> what you're doing anyway :) > > Speaking from complete and utter ignorance.... > > does this change impact how our build system works? Unless the build system has some special arrangements for the previous %{_tmppath} having gobs more diskspace than %{_topdir} then it shouldn't affect anything. Certainly it "just works" in plain mock. - Panu - From jspaleta at gmail.com Wed Jul 9 17:27:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 09:27:50 -0800 Subject: OLPC & package dependency growth In-Reply-To: <544eb990807091017l149041d3gaea11ce69be3797c@mail.gmail.com> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215621939.13098.37.camel@aglarond.local> <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> <544eb990807091017l149041d3gaea11ce69be3797c@mail.gmail.com> Message-ID: <604aa7910807091027m8dcf570u7e82591369021ee2@mail.gmail.com> On Wed, Jul 9, 2008 at 9:17 AM, Bill Crawford wrote: > Wouldn't it be easiest to simply do the install to a VM and look at > the actual disk usage? This avoids guesswork ... that assumes that we have an installable image actually being built on a daily basis for each of the kickstart files which contributors are interested in tracking. I'm not sure that's a good assumption. In fact, moving forward I'm very sure that won't be a good assumption to make as we populate the kickstart pool with community contributed spins. I'd rather put some estimate information out there on a daily basis so people who have kickstart files to worry about, like community contributed spins in the Kickstart Pool, can get ahead of a dependency bloat problem, with enough time to communicate with maintainers on how to address it. http://fedoraproject.org/wiki/SIGs/Spins/KickstartPool -jef From wtogami at redhat.com Wed Jul 9 17:46:42 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Jul 2008 13:46:42 -0400 Subject: Rawhide Orphanarium Cleanup Status Message-ID: <4874F982.6010503@redhat.com> xffm xemacs-sumo v2strip tpctl tetex-lgrind tetex-font-tipa tetex-fontools tetex-armtex tetex-arabtex tdl system-switch-im system-config-control sodipodi silky search4files scribus-templates screem scim-chinese-standard rpmproc rpmDirectoryCheck repoml python-htmltmpl python-cvstoys polyxmass-doc polyxmass-data polyxmass-common perl-String-Ediff pam_script nucleo notemeister netdiag lvcool libzvt lcdf-typetools kxdocker-resources kxdocker jikes inti iiimf-le-simplehangul icmpdn hula htmltmpl htb-util Gtk-Perl gtkhtml36 gstreamer08-python gstreamer08-plugins gstreamer08 gnome-yum gnome-telnet gktools gfontview FreeWnn fedora-rpmdevtools edb doctorj diag-ether cvsup configure-thinkpad cfs cdiff brightside at-poke aspell-mi amaya These packages have had no builds since before FC7 (none in koji) and are currently orphaned. I have just blocked all of them. I *think* this shouldn't be a problem since koji didn't have any package to include in any repo. If you want to revive anything here please talk to Fedora releng. aasaver AGReader kbiof nautilus-share pygtkglext PyOpenGL python-libgmail-docs xeuphoric emerald emerald-themes fuse-gmailfs gnome-applet-tvn24 gnome-ppp lipstik python-libgmail ruby-amazon system-summary skencil This (I think) is a complete list of orphans that would be removed from rawhide unless somebody claims them by July 18th. Warren Togami wtogami at redhat.com From j.w.r.degoede at hhs.nl Wed Jul 9 17:59:40 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Jul 2008 19:59:40 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <4874D9E2.7090807@kanarip.com> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> <4874D9E2.7090807@kanarip.com> Message-ID: <4874FC8C.4090500@hhs.nl> Hi All, I've retaken PyOpenGL and pygtkglext again (they were mine I released them for someone to pick up, but that appearantly didn't happen. Regards, Hans From sandmann at redhat.com Wed Jul 9 17:54:12 2008 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 09 Jul 2008 13:54:12 -0400 Subject: libgtop2 - who owns it? In-Reply-To: <20080709160911.fcb33243.mschwendt@gmail.com> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> Message-ID: Michael Schwendt writes: > On Wed, 09 Jul 2008 09:51:51 -0400, Matthias Clasen wrote: > > > On Wed, 2008-07-09 at 15:35 +0200, Michael Schwendt wrote: > > > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, > > > which are assigned to S?ren Sandmann Pedersen, but the package > > > changelog shows the names of other maintainers. One of the bug > > > reports is one year old already. The other one is mine. > > > > > > Who owns libgtop2? > > > > > > > Since you were already at bugz.fd.o, it wouldn't have cost you much to > > head over to > > https://admin.fedoraproject.org/pkgdb/packages/name/libgtop2 > > to find out. > > To find out what? None of the persons listed there have requested > "watchbugzilla". > > > Soeren owns it. > > Last activity in %changelog has been in 2006. > > > I do most of the version updates when I do mass updates. > > As can be seen in the changelog, but that doesn't answer whether > bugzilla might be the same as /dev/null. Unfortunately, for some of the packages I own, including this one, bugzilla is essentially /dev/null until beta time, where I'll go over the bugs assigned to me and prioritize them. In general, it's often a better bet to file bugs against gnome packages directly upstream, unless it's a packaging bug. Soren From limb at jcomserv.net Wed Jul 9 18:05:04 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 9 Jul 2008 13:05:04 -0500 (CDT) Subject: libgtop2 - who owns it? In-Reply-To: References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> Message-ID: <51255.198.175.55.5.1215626704.squirrel@mail.jcomserv.net> > Michael Schwendt writes: > >> On Wed, 09 Jul 2008 09:51:51 -0400, Matthias Clasen wrote: >> >> > On Wed, 2008-07-09 at 15:35 +0200, Michael Schwendt wrote: >> > > http://bugz.fedoraproject.org/libgtop2 shows two open bugs, >> > > which are assigned to S??ren Sandmann Pedersen, but the package >> > > changelog shows the names of other maintainers. One of the bug >> > > reports is one year old already. The other one is mine. >> > > >> > > Who owns libgtop2? >> > > >> > >> > Since you were already at bugz.fd.o, it wouldn't have cost you much to >> > head over to >> > https://admin.fedoraproject.org/pkgdb/packages/name/libgtop2 >> > to find out. >> >> To find out what? None of the persons listed there have requested >> "watchbugzilla". >> >> > Soeren owns it. >> >> Last activity in %changelog has been in 2006. >> >> > I do most of the version updates when I do mass updates. >> >> As can be seen in the changelog, but that doesn't answer whether >> bugzilla might be the same as /dev/null. > > Unfortunately, for some of the packages I own, including this one, > bugzilla is essentially /dev/null until beta time, where I'll go over > the bugs assigned to me and prioritize them. > > In general, it's often a better bet to file bugs against gnome > packages directly upstream, unless it's a packaging bug. If this is the case, mightn't it be helpful if one or more of your many co-maintainers for this (and possibly other) packages add themselves to watchbugzilla? Takers? > > Soren > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mclasen at redhat.com Wed Jul 9 18:10:21 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 14:10:21 -0400 Subject: libgtop2 - who owns it? In-Reply-To: <51255.198.175.55.5.1215626704.squirrel@mail.jcomserv.net> References: <20080709153515.5e34d1d6.mschwendt@gmail.com> <1215611511.3233.5.camel@localhost.localdomain> <20080709160911.fcb33243.mschwendt@gmail.com> <51255.198.175.55.5.1215626704.squirrel@mail.jcomserv.net> Message-ID: <1215627021.23647.8.camel@localhost.localdomain> On Wed, 2008-07-09 at 13:05 -0500, Jon Ciesla wrote: > If this is the case, mightn't it be helpful if one or more of your many > co-maintainers for this (and possibly other) packages add themselves to > watchbugzilla? Takers? watchbugzilla doesn't really help if you are already getting more spam than you can read in a day, every day... I've looked at the patch and it certainly looks fine. If you or Michael want to go ahead and build and file an F8 update, that would cool. From fedora at leemhuis.info Wed Jul 9 18:12:58 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Jul 2008 20:12:58 +0200 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: References: Message-ID: <4874FFAA.3030902@leemhuis.info> On 09.07.2008 12:51, Panu Matilainen wrote: > At long last, we are about to get a brand new RPM version (alpha snapshot > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > and a full summary needs a separate posting (will follow as time permits), > this is just a heads-up of immediate consequences for Fedora packagers and > rawhide consumers: Sounds great, thanks Panu and others! Much appreciated and looked forward to. But this announcement made me wondering: We have a big and complicated Feature process [1] in Fedora that keeps a whole lot of people and committees (especially FESCo) busy. Afaics the new RPM version is something that can be considered a "feature" [2]. It was afaics not approved yet by FESCO [3] or even proposed [4]. I would expect going backwards to an older RPM in rawhide later will be next to impossible or very very hard. IOW: once it's in rawhide for a few days FESCO kind of has no other chance then to approve this feature, in case it ever comes up for a Feature vote in a FESCo meeting. So is the most of the Feature process (and especially FESCo's approval) useless overhead? It looks to me that the answer tends to be "yes" as long as big features like this can easily creep in without going through the established approval process, as long as the feature gets added to rawhide early enough in the devel cycle. Just wondering. No, I really don't want to stop the new RPM; there are likely other examples (say OpenOffice 3.0) in rawhide (but going backwards there as hard as with RPM). But I'm more and more wondering if the complex Feature process is worth all the trouble and effort. The best thing that came out of it in F9 IMHO were the good release notes and great "whats new" pages. But I'd say we can have that easier. CU knurd [1] https://fedoraproject.org/wiki/Features/Policy [2] https://fedoraproject.org/wiki/Features/Policy#Definition_of_a_Feature [3] https://fedoraproject.org/wiki/Releases/10/FeatureList https://fedoraproject.org/wiki/Category:AcceptedFedora10 [4] https://fedoraproject.org/wiki/Category:ProposedFedora10 https://fedoraproject.org/wiki/CategoryProposedFeature From nikolay at vladimiroff.com Wed Jul 9 18:21:21 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 9 Jul 2008 21:21:21 +0300 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <4874FC8C.4090500@hhs.nl> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> <4874D9E2.7090807@kanarip.com> <4874FC8C.4090500@hhs.nl> Message-ID: <20080709182121.GA17723@marvin> On (09/07/08 19:59), Hans de Goede wrote: > Hi All, > > I've retaken PyOpenGL and pygtkglext again (they were mine I released > them for someone to pick up, but that appearantly didn't happen. > > Regards, > > Hans > Greetings! I'm willing to maintain PyOpenGL and comaintain pygtkglext. Best Regards, -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jwboyer at gmail.com Wed Jul 9 18:26:50 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 09 Jul 2008 14:26:50 -0400 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <4874FFAA.3030902@leemhuis.info> References: <4874FFAA.3030902@leemhuis.info> Message-ID: <1215628010.32502.9.camel@weaponx> On Wed, 2008-07-09 at 20:12 +0200, Thorsten Leemhuis wrote: > On 09.07.2008 12:51, Panu Matilainen wrote: > > At long last, we are about to get a brand new RPM version (alpha snapshot > > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > > and a full summary needs a separate posting (will follow as time permits), > > this is just a heads-up of immediate consequences for Fedora packagers and > > rawhide consumers: > > Sounds great, thanks Panu and others! Much appreciated and looked > forward to. > > But this announcement made me wondering: We have a big and complicated > Feature process [1] in Fedora that keeps a whole lot of people and > committees (especially FESCo) busy. Afaics the new RPM version is > something that can be considered a "feature" [2]. It was afaics not > approved yet by FESCO [3] or even proposed [4]. I would expect going > backwards to an older RPM in rawhide later will be next to impossible or > very very hard. IOW: once it's in rawhide for a few days FESCO kind of > has no other chance then to approve this feature, in case it ever comes > up for a Feature vote in a FESCo meeting. Good point. > So is the most of the Feature process (and especially FESCo's approval) > useless overhead? I don't think so. I think the rpm example illustrates the weakest point of the process, and it should be worked on rather than be declared as useless. It does happen to be my biggest pet peeve of the Feature process, because this will now become a "Feature" that gets defacto approval simply because it's already in. I HATE doing that, because as you said it is largely a waste of time. So we need to be a bit more proactive about it. I'll argue that not every package upgrade is worth a Feature designation. But the major ones should be. Firefox 3 had one. I believe OpenOffice.org should have one. For a major rpm upgrade, there should be one as well. josh From nikolay at vladimiroff.com Wed Jul 9 18:28:06 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 9 Jul 2008 21:28:06 +0300 Subject: Rawhide Orphanarium Cleanup Status In-Reply-To: <4874F982.6010503@redhat.com> References: <4874F982.6010503@redhat.com> Message-ID: <20080709182806.GB17723@marvin> On (09/07/08 13:46), Warren Togami wrote: > skencil > > This (I think) is a complete list of orphans that would be removed from > rawhide unless somebody claims them by July 18th. > skencil looks dead: no website updates sice 2006 and no releases sice 2005. So it's probably a good idea to drop it . http://www.skencil.org/index.html -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nikolay at vladimiroff.com Wed Jul 9 19:21:21 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Wed, 9 Jul 2008 22:21:21 +0300 Subject: Rawhide Orphanarium Cleanup Status In-Reply-To: <4874F982.6010503@redhat.com> References: <4874F982.6010503@redhat.com> Message-ID: <20080709192121.GA19851@marvin> On (09/07/08 13:46), Warren Togami wrote: > emerald > emerald-themes I'm willing to take emerald and emerald-themes if nobody wants them. They are quite important( i think) for the whole compiz-3d-desktop stuff. -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From skvidal at fedoraproject.org Wed Jul 9 19:18:55 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Jul 2008 15:18:55 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215618263.14926.100.camel@rosebud> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> Message-ID: <1215631135.3327.1.camel@rosebud> On Wed, 2008-07-09 at 11:44 -0400, seth vidal wrote: > Taking a list of pkgs, resolving out all of their deps then calculating > installed size (not calculating vs an existing install, but raw > installed size) shouldn't take too much code at all. I'll see what I can > hack up today. > > It won't take into account overlaid files (like docs and manpages, nor > multilib binaries) but it should give you a pretty good upper range > (sort of). A start of what it should do. I'll fix up the kickstart parsing, among other things, later - once I get some confirmation is even remotely in the ballpark. http://skvidal.fedorapeople.org/misc/installed-size.py -sv From notting at redhat.com Wed Jul 9 19:23:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 15:23:36 -0400 Subject: [RFC Fedora 10] kill pam_console Message-ID: <20080709192336.GC7537@nostromo.devel.redhat.com> We've carried both pam_console and HAL-based ACL support for a while now. It's time to cut the cord and remove pam_console, so we only have one way of setting device permissions to worry about. Here's the list of packages that still contain pam_console configuration that would need migrated: pam (tmraz at redhat.com) /etc/security/console.perms.d/50-default.perms em8300 (ville.skytta at iki.fi) /etc/security/console.permbs.d/60-em8300.perms jfbterm (mtasaka at ioa.s.u-tokyo.ac.jp) /etc/security/console.perms.d/60-jfbterm.perms libmtp (triad at df.lth.se) /etc/security/console.perms.d/60-libmtp.perms libnjb (triad at df.lth.se) /etc/security/console.perms.d/60-libnjb.perms thinkfinger (silfreed at silfreed.net) /etc/security/console.perms.d/60-thinkfinger.perms vdr (ville.skytta at iki.fi) /etc/security/console.perms.d/95-vdr.perms dfu-programmer (weston_schmidt at alumni.purdue.edu) /etc/security/console.perms.d/dfu-programmer-at89c51.perms /etc/security/console.perms.d/dfu-programmer-at90usb.perms piklab (cgoorah at yahoo.com.au) /etc/security/console.perms.d/icd2.perms /etc/security/console.perms.d/pickit1.perms /etc/security/console.perms.d/pickit2.perms These all seem like they'd be reasonable to fix. Does anyone see this as a problem? Bill From jspaleta at gmail.com Wed Jul 9 19:26:01 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 11:26:01 -0800 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1215628010.32502.9.camel@weaponx> References: <4874FFAA.3030902@leemhuis.info> <1215628010.32502.9.camel@weaponx> Message-ID: <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> On Wed, Jul 9, 2008 at 10:26 AM, Josh Boyer wrote: > I'll argue that not every package upgrade is worth a Feature > designation. But the major ones should be. Firefox 3 had one. I > believe OpenOffice.org should have one. For a major rpm upgrade, there > should be one as well. Distill that feeling into a generally applicable statement that package maintainers can use as a conditional test as to whether or not they should file a feature. For example... the python-matplotlib that I just introduced into rawhide.. it has enhancements, and some internal api changes. Does it matter enough as a package to be a Fedora Feature? If I can get a new gdl built with the python module support enable..will that matter? I need a bright line test that makes sense that limits how much of my individual judgement has to be used for the packages that I maintain. I need a checklist or a scorecard....I need a Cosmo quiz. And its completely okay if the test/checklist/scorecard that we think is best can be fully created yet. For example.. if we feel that a packages "popularity" is important to rank something as a feature, then we put that on the checklist and we then go out and build whatever popularity metric is necessary to support that part of the checklist. -jef"is definitely not in favor of any popularity metric"spaleta From cmadams at hiwaay.net Wed Jul 9 19:32:35 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 9 Jul 2008 14:32:35 -0500 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709192336.GC7537@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> Message-ID: <20080709193234.GD1364182@hiwaay.net> Once upon a time, Bill Nottingham said: > We've carried both pam_console and HAL-based ACL support for a while > now. It's time to cut the cord and remove pam_console, so we only > have one way of setting device permissions to worry about. I am slow on the up-take here, but how do I use the "HAL-based ACL support" to replace pam_console? For example, on a system with serial ports used for accessing other consoles, I have a 10-serial.perms like: ######################################################################## =/dev/ttyS[0-9]* /dev/ttyUSB[0-9]* 0660 0660 root.uucp ######################################################################## How do I replace that? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwalsh at redhat.com Wed Jul 9 19:34:11 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 09 Jul 2008 15:34:11 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215616958.2809.516.camel@beck.corsepiu.local> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <1215599413.2809.477.camel@beck.corsepiu.local> <4874C3B7.7090603@redhat.com> <1215613414.2809.501.camel@beck.corsepiu.local> <4874D37C.5080305@redhat.com> <1215616958.2809.516.camel@beck.corsepiu.local> Message-ID: <487512B3.1030609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > On Wed, 2008-07-09 at 11:04 -0400, Daniel J Walsh wrote: > >> So this bug will happen whenever SELinux was disabled. > Note: This bug ... provided the fact SELinux is not transparent ... can > you exclude other cases? > >> Whether or not >> you disabled it during install or post install. So your example of why >> SELinux needs to be able to be disabled in Anaconda is flawed. > May-be, may-be not, ... I may be wrong in this particular case, but > otherwise I disagree with you - I regret having to say this, but I've > been too often hit issues with SELinux-policies in all the years SELinux > is in Fedora to have grant it much trust. > Yes, I understand this. And if bugs/problems in the past cause you to not run with SELinux, that is fine. But you have not given an example of why having/not having the option in Anaconda changes this. > Anyway, another case: SELinux's run-time memory consumption is too big > for some classes of (low end) HW. > For low end hardware you will probably need to do custom install anyways. But > Related to it: I had experienced cases where selinux-policy updates took > hours and occasionally caused kernel oops'es. > Depending on the size of a system if it needed to relabel a major portion it could take a very long time. Kernel oopses are regrettable. > Ralf > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh1ErIACgkQrlYvE4MpobOdUACgwIIIJNoptR7llUqHEmaSVi6X vZsAoJNvOMmlGIBXd2i0ajll9rHMrmAU =/HDX -----END PGP SIGNATURE----- From katzj at redhat.com Wed Jul 9 19:35:45 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 09 Jul 2008 15:35:45 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215631135.3327.1.camel@rosebud> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> Message-ID: <1215632145.13098.41.camel@aglarond.local> On Wed, 2008-07-09 at 15:18 -0400, seth vidal wrote: > On Wed, 2008-07-09 at 11:44 -0400, seth vidal wrote: > > Taking a list of pkgs, resolving out all of their deps then calculating > > installed size (not calculating vs an existing install, but raw > > installed size) shouldn't take too much code at all. I'll see what I can > > hack up today. > > > > It won't take into account overlaid files (like docs and manpages, nor > > multilib binaries) but it should give you a pretty good upper range > > (sort of). > > A start of what it should do. I'll fix up the kickstart parsing, among > other things, later - once I get some confirmation is even remotely in > the ballpark. > > http://skvidal.fedorapeople.org/misc/installed-size.py The thing which becomes important to see is growth (or shrinkage) in packages as well as what new packages/removed packages there are. Which involves fiddly questions of growth thresholds and human analysis of the output Jeremy From katzj at redhat.com Wed Jul 9 19:38:16 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 09 Jul 2008 15:38:16 -0400 Subject: OLPC & package dependency growth In-Reply-To: <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215621939.13098.37.camel@aglarond.local> <604aa7910807091004l4cc658cm7cddfca12972f917@mail.gmail.com> Message-ID: <1215632296.13098.44.camel@aglarond.local> On Wed, 2008-07-09 at 09:04 -0800, Jeff Spaleta wrote: > On Wed, Jul 9, 2008 at 8:45 AM, Jeremy Katz wrote: > > I basically do this with some scripts against the live cds which I build > > (nearly) daily. I could work on actually getting that information into > > a more consumable form rather than just doing it on an "I saw the livecd > > grew, what happened this time" basis > > I would imagine this will be generally useful for anyone working on a spin. > How automated can you make your scripts and can we tie them into the > daily rawhide gearage? There's not really a good way right now to tie "build a livecd" into the rawhide build process, much less "build a large set of livecds". Unless you want to make rawhide take far longer to build which seems like something we don't want. Plus, even then, it's a matter of human analysis, not just having the data > Would you be able to automate this to run daily > against a collection of kickstart file targets to estimate total > packageset size and then poop that out those number as a data point on > a time history graph to be displayed at a fedoraproject url? The total package set size isn't interesting with a live image because you then have the compression on top of that. So 20 megs of additional installed package size could end up only being 2 megs on the iso or it could end up being 20. Jeremy From Jochen at herr-schmitt.de Wed Jul 9 19:34:07 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 09 Jul 2008 21:34:07 +0200 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <4874FFAA.3030902@leemhuis.info> References: <4874FFAA.3030902@leemhuis.info> Message-ID: <0ML29c-1KGfQW1Aqp-0003mG@mrelayeu.kundenserver.de> On Wed, 09 Jul 2008 20:12:58 +0200, you wrote: >Just wondering. No, I really don't want to stop the new RPM; there are >likely other examples (say OpenOffice 3.0) in rawhide (but going >backwards there as hard as with RPM). But I'm more and more wondering if >the complex Feature process is worth all the trouble and effort. The >best thing that came out of it in F9 IMHO were the good release notes >and great "whats new" pages. But I'd say we can have that easier. I think the most issue of a new RPM release is the fact, that other package like yum may interfere from it, and that they may got issue during the installation/upgrade process of Fedora, so a Feature process may be require from my point of view. At last we new a failback or blocking strategy, if there should be any severe issue which block the release fo F-10. Best Regards: Jochen Schmitt From jwboyer at gmail.com Wed Jul 9 19:43:44 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 09 Jul 2008 15:43:44 -0400 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> References: <4874FFAA.3030902@leemhuis.info> <1215628010.32502.9.camel@weaponx> <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> Message-ID: <1215632624.32502.19.camel@weaponx> On Wed, 2008-07-09 at 11:26 -0800, Jeff Spaleta wrote: > On Wed, Jul 9, 2008 at 10:26 AM, Josh Boyer wrote: > > I'll argue that not every package upgrade is worth a Feature > > designation. But the major ones should be. Firefox 3 had one. I > > believe OpenOffice.org should have one. For a major rpm upgrade, there > > should be one as well. > > Distill that feeling into a generally applicable statement that > package maintainers can use as a conditional test as to whether or not > they should file a feature. Simplistic start of a checklist: 1) Is your package included in the default install of one of the main spins? 2) Is your package _the_ default application of it's type? 3) Is your package involved in the building of the entire distro? (E.g. rpm, gcc, glibc) 4) Are there a large number of packages that depend on your package that will be effected by an upgrade/change/etc ? 5) Are you trying to promote this package as a Feature for publicity reasons? 6) Does your package enable something that is highly end-user visible (e.g. magically working wireless, push button pony making) If yes to any of the above, please create a Feature page. If no, and or/you are still unsure, ask one of your FESCo representatives and they will guide you. josh From notting at redhat.com Wed Jul 9 19:53:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 15:53:03 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709193234.GD1364182@hiwaay.net> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> Message-ID: <20080709195303.GA11245@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > Once upon a time, Bill Nottingham said: > > We've carried both pam_console and HAL-based ACL support for a while > > now. It's time to cut the cord and remove pam_console, so we only > > have one way of setting device permissions to worry about. > > I am slow on the up-take here, but how do I use the "HAL-based ACL > support" to replace pam_console? For example, on a system with serial > ports used for accessing other consoles, I have a 10-serial.perms like: > > ######################################################################## > =/dev/ttyS[0-9]* /dev/ttyUSB[0-9]* > > 0660 0660 root.uucp > ######################################################################## > > How do I replace that? See /usr/share/hal/fdi/policy/10osvendor/00-thinkfinger.fdi for an example of something that does access control. What does lshal have for your serial devices? Bill From Christian.Iseli at unil.ch Wed Jul 9 20:05:08 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Wed, 9 Jul 2008 22:05:08 +0200 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <1215568440.4382.8.camel@localhost.localdomain> References: <1215463202.5070.12.camel@kennedy> <1215552658.3142.243.camel@calliope.phig.org> <1215558728.6976.14.camel@kennedy> <1215568440.4382.8.camel@localhost.localdomain> Message-ID: <20080709220508.07f879df@ludwig-alpha.unil.ch> On Tue, 08 Jul 2008 21:54:00 -0400, Jesse Keating wrote: > I'd be happy to see open nominations, provided that the nominee has to > accept the nomination before being put on the ballot. Agreed, C From pmatilai at redhat.com Wed Jul 9 20:34:26 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Wed, 9 Jul 2008 23:34:26 +0300 (EEST) Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <4874FFAA.3030902@leemhuis.info> References: <4874FFAA.3030902@leemhuis.info> Message-ID: On Wed, 9 Jul 2008, Thorsten Leemhuis wrote: > On 09.07.2008 12:51, Panu Matilainen wrote: >> At long last, we are about to get a brand new RPM version (alpha snapshot >> at the moment) into rawhide. The list of changes from 4.4.2.x is massive >> and a full summary needs a separate posting (will follow as time permits), >> this is just a heads-up of immediate consequences for Fedora packagers and >> rawhide consumers: > > Sounds great, thanks Panu and others! Much appreciated and looked forward to. > > But this announcement made me wondering: We have a big and complicated > Feature process [1] in Fedora that keeps a whole lot of people and committees > (especially FESCo) busy. Afaics the new RPM version is something that can be > considered a "feature" [2]. It was afaics not approved yet by FESCO [3] or > even proposed [4]. Hohum... fair point. Frankly, I've been so buried up in upstream rpm development for a good part of the last year the thought of the feature process never really so much as crossed my mind. My bad. The new RPM is not committed yet or built yet, partly due to other issues, partly to give time for any last regrets. Since we're obviously having some last regrets here... The simple-minded bass-player in me has just one practical question: what do we do about it? Sure we can go through the feature process, it'll just probably mean the new rpm will miss F10 alpha. Whether that's a good thing or not might depend on if you're in rel-eng or not ;) > I would expect going backwards to an older RPM in rawhide > later will be next to impossible or very very hard. IOW: once it's in rawhide > for a few days FESCO kind of has no other chance then to approve this > feature, in case it ever comes up for a Feature vote in a FESCo meeting. FWIW, having a safe back-out route is the very reason why it's going to be built with bdb-4.5.20 instead of "whatever's latest" - that version permits going back and forth between rpm 4.4.x and current one without any complicated db conversion procedures. > So is the most of the Feature process (and especially FESCo's approval) > useless overhead? It looks to me that the answer tends to be "yes" as long as > big features like this can easily creep in without going through the > established approval process, as long as the feature gets added to rawhide > early enough in the devel cycle. > > Just wondering. No, I really don't want to stop the new RPM; there are likely > other examples (say OpenOffice 3.0) in rawhide (but going backwards there as > hard as with RPM). But I'm more and more wondering if the complex Feature > process is worth all the trouble and effort. The best thing that came out of > it in F9 IMHO were the good release notes and great "whats new" pages. But > I'd say we can have that easier. One reason for missing out on the feature process is probably that I've found it somehow alien thing to begin with - I don't consider myself working on a "Fedora feature", I'm "working on rpm.org upstream" to get a much-needed update to the aging RPM version we have been living with for ages. Mind you, this is not an excuse for missing out on distro policies. The line between a "feature" and a "non-feature" is extremely obscure really, and I think the point of "if you're unsure, ask" has not been made sufficiently clear. Until perhaps now :) - Panu - From skvidal at fedoraproject.org Wed Jul 9 20:34:17 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Jul 2008 16:34:17 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215632145.13098.41.camel@aglarond.local> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> <1215632145.13098.41.camel@aglarond.local> Message-ID: <1215635657.3055.0.camel@rosebud> On Wed, 2008-07-09 at 15:35 -0400, Jeremy Katz wrote: > On Wed, 2008-07-09 at 15:18 -0400, seth vidal wrote: > > On Wed, 2008-07-09 at 11:44 -0400, seth vidal wrote: > > > Taking a list of pkgs, resolving out all of their deps then calculating > > > installed size (not calculating vs an existing install, but raw > > > installed size) shouldn't take too much code at all. I'll see what I can > > > hack up today. > > > > > > It won't take into account overlaid files (like docs and manpages, nor > > > multilib binaries) but it should give you a pretty good upper range > > > (sort of). > > > > A start of what it should do. I'll fix up the kickstart parsing, among > > other things, later - once I get some confirmation is even remotely in > > the ballpark. > > > > http://skvidal.fedorapeople.org/misc/installed-size.py > > The thing which becomes important to see is growth (or shrinkage) in > packages as well as what new packages/removed packages there are. Which > involves fiddly questions of growth thresholds and human analysis of the > output I can output a csv of the pkgs that would be installed. -sv From cmadams at hiwaay.net Wed Jul 9 20:57:15 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 9 Jul 2008 15:57:15 -0500 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709195303.GA11245@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> Message-ID: <20080709205715.GE1364182@hiwaay.net> Once upon a time, Bill Nottingham said: > Chris Adams (cmadams at hiwaay.net) said: > > I am slow on the up-take here, but how do I use the "HAL-based ACL > > support" to replace pam_console? For example, on a system with serial > > ports used for accessing other consoles, I have a 10-serial.perms like: > > > > ######################################################################## > > =/dev/ttyS[0-9]* /dev/ttyUSB[0-9]* > > > > 0660 0660 root.uucp > > ######################################################################## > > > > How do I replace that? > > See /usr/share/hal/fdi/policy/10osvendor/00-thinkfinger.fdi for an > example of something that does access control. What does lshal > have for your serial devices? One is old-style serial and one is USB: ######################################################################### udi = '/org/freedesktop/Hal/devices/pnp_PNP0501_0_serial_platform_1' info.capabilities = {'serial'} (string list) info.category = 'serial' (string) info.parent = '/org/freedesktop/Hal/devices/pnp_PNP0501_0' (string) info.product = '16550A-compatible COM port' (string) info.udi = '/org/freedesktop/Hal/devices/pnp_PNP0501_0_serial_platform_1' (string) linux.device_file = '/dev/ttyS1' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'tty' (string) linux.sysfs_path = '/sys/class/tty/ttyS1' (string) serial.device = '/dev/ttyS1' (string) serial.originating_device = '/org/freedesktop/Hal/devices/pnp_PNP0501_0' (string) serial.physical_device = '/org/freedesktop/Hal/devices/pnp_PNP0501_0' (string) serial.port = 1 (0x1) (int) serial.type = 'platform' (string) udi = '/org/freedesktop/Hal/devices/usb_device_50d_109_862270_if0_serial_usb_0' info.capabilities = {'serial'} (string list) info.category = 'serial' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_50d_109_862270_if0' (string) info.product = 'F5U109/F5U409 PDA Adapter' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_50d_109_862270_if0_serial_usb_0' (string) linux.device_file = '/dev/ttyUSB0' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'tty' (string) linux.sysfs_path = '/sys/class/tty/ttyUSB0' (string) serial.device = '/dev/ttyUSB0' (string) serial.originating_device = '/org/freedesktop/Hal/devices/usb_device_50d_109_862270_if0' (string) serial.physical_device = '/org/freedesktop/Hal/devices/usb_device_50d_109_862270_if0' (string) serial.port = 0 (0x0) (int) serial.type = 'usb' (string) ######################################################################### If I just wanted all serial ports assigned (like in my pam_console bit above), I guess something like this would work? ######################################################################### access_control linux.device_file serial ######################################################################### I have another system where I have multiple USB-to-RS232 adapters; one is used for outbound terminal sessions (console user gets access) and one for a modem (no console access). I differentiate between the two with a udev rule that adds a symlink (e.g. "term" and "modem") and then set the permissions with a pam_console match on the symlink. Is it possible to match something set from udev like that (so I don't have two places to keep track of hardare serial numbers and such for matching)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwilson at redhat.com Wed Jul 9 21:02:03 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 9 Jul 2008 17:02:03 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <544eb990807091015x48f4e572mb6ff4872178bfa95@mail.gmail.com> References: <200807091228.00498.jwilson@redhat.com> <544eb990807091015x48f4e572mb6ff4872178bfa95@mail.gmail.com> Message-ID: <200807091702.03174.jwilson@redhat.com> On Wednesday 09 July 2008 01:15:47 pm Bill Crawford wrote: > 2008/7/9 Jarod Wilson : > > On Wednesday 09 July 2008 12:12:27 pm Dale Stimson wrote: > >> [snip] > >> > >> Something I would like to see standard in RPM is for the default for > >> installation of source files from a .src.rpm file to be changed from > >> %{_sourcedir} > >> to > >> %{_sourcedir}/%{name}-%{version} > >> > >> (The above example assumes the current definition of _sourcedir, > >> which the suggested implementation below proposes be changed). > > [snip] > > >> %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} > >> > >> I've done this in my .rpmmacros file for a long time and am happy with > >> it. > > > > Been doing something similar myself for ages, but also dropping the spec > > file in with the source files. A directory full of specs and a directory > > full of sources for umpteen different packages is dumb. > > This breaks doing build-from-tarball, because until the spec is > parsed, the version is unknown. My "something similar" doesn't actually include %{version}, only %{name}. -- Jarod Wilson jwilson at redhat.com From notting at redhat.com Wed Jul 9 21:04:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 17:04:51 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709205715.GE1364182@hiwaay.net> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> <20080709205715.GE1364182@hiwaay.net> Message-ID: <20080709210451.GD11245@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > If I just wanted all serial ports assigned (like in my pam_console bit > above), I guess something like this would work? > > ######################################################################### > > > > > access_control > linux.device_file > serial > > > > ######################################################################### Something along those lines, yes. > I have another system where I have multiple USB-to-RS232 adapters; one > is used for outbound terminal sessions (console user gets access) and > one for a modem (no console access). I differentiate between the two > with a udev rule that adds a symlink (e.g. "term" and "modem") and then > set the permissions with a pam_console match on the symlink. Is it > possible to match something set from udev like that (so I don't have two > places to keep track of hardare serial numbers and such for matching)? This is a two-stage process. For examples see: /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi followed by: /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi The first looks at varying information in HAL (such as the driver being the ipaq driver, the USB vendor/product ids, and then adds the 'pda' capability to the device. The second file then adds ACL management to any device with 'pda' capabilities. So, you'd want to use whatever criteria you're using in udev to set a capability on the device, and then add the stanza to only apply ACLs to devices with that capability. (Depending on the criteria you're using in udev, you might be able to craft the match without adding a property.) Bill From jspaleta at gmail.com Wed Jul 9 21:11:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 13:11:37 -0800 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709210451.GD11245@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> <20080709205715.GE1364182@hiwaay.net> <20080709210451.GD11245@nostromo.devel.redhat.com> Message-ID: <604aa7910807091411w5ad84805pc29d4bb9900eb8dc@mail.gmail.com> On Wed, Jul 9, 2008 at 1:04 PM, Bill Nottingham wrote: > This is a two-stage process. For examples see: > > /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi > > followed by: > > /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi I that was the first explanation of how to do this sort of thing on how to generate new hardwar access control rules that I've actually followed. Do the changes you have described get automatically picked up so include new acl controlled hardware definitions in the authorizations gui? -jef From jkeating at redhat.com Wed Jul 9 21:12:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Jul 2008 17:12:08 -0400 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: References: <4874FFAA.3030902@leemhuis.info> Message-ID: <1215637928.3274.40.camel@localhost.localdomain> On Wed, 2008-07-09 at 23:34 +0300, Panu Matilainen wrote: > > The simple-minded bass-player in me has just one practical question: what > do we do about it? Sure we can go through the feature process, it'll just > probably mean the new rpm will miss F10 alpha. Whether that's a good thing > or not might depend on if you're in rel-eng or not ;) If we can dedicate a couple helpers to you, I bet we could get a feature page written up quickly, and I bet we could get FESCo approval in good faith on getting a suitable feature page up, after the package is built. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 bpepple at fedoraproject.org Wed Jul 9 21:09:33 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 09 Jul 2008 17:09:33 -0400 Subject: [Reminder] FESCo Election Nominations In-Reply-To: <20080709220508.07f879df@ludwig-alpha.unil.ch> References: <1215463202.5070.12.camel@kennedy> <1215552658.3142.243.camel@calliope.phig.org> <1215558728.6976.14.camel@kennedy> <1215568440.4382.8.camel@localhost.localdomain> <20080709220508.07f879df@ludwig-alpha.unil.ch> Message-ID: <1215637773.16459.10.camel@kennedy> On Wed, 2008-07-09 at 22:05 +0200, Christian Iseli wrote: > On Tue, 08 Jul 2008 21:54:00 -0400, Jesse Keating wrote: > > I'd be happy to see open nominations, provided that the nominee has to > > accept the nomination before being put on the ballot. > > Agreed, Ok, since we've had a couple of ack's and more importantly no objections to having open nominations, let's go ahead and do it. I've created a section on the page for people to nominate folks to FESCo, and if the nominee accepts it, they can move their information to the Candidates section (so I can easily know has accepted the nomination). https://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations#Nominations Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Jul 9 21:33:10 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 17:33:10 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <604aa7910807091411w5ad84805pc29d4bb9900eb8dc@mail.gmail.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> <20080709205715.GE1364182@hiwaay.net> <20080709210451.GD11245@nostromo.devel.redhat.com> <604aa7910807091411w5ad84805pc29d4bb9900eb8dc@mail.gmail.com> Message-ID: <20080709213310.GE11245@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > > /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi > > > > followed by: > > > > /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi > > I that was the first explanation of how to do this sort of thing on > how to generate new hardwar access control rules that I've actually > followed. Well, at least until David chimes in and tells me I'm doing this wrong. > Do the changes you have described get automatically picked up so > include new acl controlled hardware definitions in the authorizations > gui? This is independent of PolicyKit - AFAIK, there's no GUIs for this stuff. Bill From jspaleta at gmail.com Wed Jul 9 21:50:42 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 13:50:42 -0800 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709213310.GE11245@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> <20080709205715.GE1364182@hiwaay.net> <20080709210451.GD11245@nostromo.devel.redhat.com> <604aa7910807091411w5ad84805pc29d4bb9900eb8dc@mail.gmail.com> <20080709213310.GE11245@nostromo.devel.redhat.com> Message-ID: <604aa7910807091450m2932e9b6k133b1374155b99d8@mail.gmail.com> On Wed, Jul 9, 2008 at 1:33 PM, Bill Nottingham wrote: > This is independent of PolicyKit - AFAIK, there's no GUIs for this stuff. I thought the Authorization gui in F9 exposed the acl stuff for devices. Following the pda example you started in the Authorizations gui tree aka polkit-gnome-authorizations from a terminal cmdline org ->freedestop ->hal ->device-access ->"Directly access PDA devices" Doesn't that directly related to the acl settings for the devices marked with the pda capability? How would I go about getting another sort of device similarly listed in the gui under device-access? What if I wanted to define acls for 'serial' devices similar to what Chris wants to do, but expose them in the Authorizations gui as "Directly access Serial devices" similar to how the pda devices are in fact exposed currently... what's the black magic? -jef"I actually want to expose a USB to I2C bridge device that you probably don't have access to, but I won't confuse things by referencing pedantic niche hardware that you don't have access to"spaleta From davej at redhat.com Wed Jul 9 21:08:43 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 9 Jul 2008 17:08:43 -0400 Subject: make clean got noisy. Message-ID: <20080709210843.GA4817@redhat.com> In my cvs checkout of devel/ , I just cvs updated the common/ dir, and now every make clean I do in each package spews this.. $ make clean error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) Running the %clean script of the rpmbuild... error: Macro %dist has empty body error: Macro %dist has empty body error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) Dave -- http://www.codemonkey.org.uk From moe at blagblagblag.org Wed Jul 9 22:03:48 2008 From: moe at blagblagblag.org (jeff) Date: Wed, 09 Jul 2008 19:03:48 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215597493.29818.11.camel@wombat.tiptoe.de> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> Message-ID: <487535C4.9030704@blagblagblag.org> > One question nobody has been able to answer to my satisfaction yet: Why > would it be essential that SELinux can be disabled from the installer > vs. from the installed system? Last time I checked, the plan was to get > non-essential functionality out of anaconda. Essential may be a bit strong, but it may be "convenient". As I understand it, if you boot the install CD with selinux=0 the filesystem wont get labelled, making the install faster (and possibly less space?). I'd like to confirm that though. Post install it would require an additional reboot to disable it, unless you disabled it at boot: prompt. My previous suggestion seems to easily solve this for everyone involved though. 1) User types: "selinux=0" at boot: prompt of CD 2) anaconda parses this and installs without selinux, passing "selinux=0" to grub 3) First boot up, selinux is already disabled (ala selinux=0 passed via grub) The benefits are that people that do want SELinux are never confronted with extra dialog boxes, power users that want to disable it have an easy way to do so, and no rebooting and such ala windoz95. The only thing missing for this is to have anaconda pass "selinux=0" to grub. It already supports the rest. It would require a 1 or two line patch to anaconda: anaconda.id.bootloader.args.append("selinux=0") In other words, if you pass selinux=0 to anaconda install, it currently does *not* get passed to grub. It should, IMHO, and I don't see why it can't/shouldn't. -Jeff From jkeating at redhat.com Wed Jul 9 22:13:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Jul 2008 18:13:22 -0400 Subject: make clean got noisy. In-Reply-To: <20080709210843.GA4817@redhat.com> References: <20080709210843.GA4817@redhat.com> Message-ID: <1215641602.3274.46.camel@localhost.localdomain> On Wed, 2008-07-09 at 17:08 -0400, Dave Jones wrote: > In my cvs checkout of devel/ , I just cvs updated the common/ dir, > and now every make clean I do in each package spews this.. I think I see why, but out of curiosity what do you get for: rpm --eval %dist on this particular system? (hint, it should spit out something like .fc9 due to /etc/rpm/macros.dist which comes from fedora-release. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 notting at redhat.com Wed Jul 9 22:21:38 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 18:21:38 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <604aa7910807091450m2932e9b6k133b1374155b99d8@mail.gmail.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> <20080709205715.GE1364182@hiwaay.net> <20080709210451.GD11245@nostromo.devel.redhat.com> <604aa7910807091411w5ad84805pc29d4bb9900eb8dc@mail.gmail.com> <20080709213310.GE11245@nostromo.devel.redhat.com> <604aa7910807091450m2932e9b6k133b1374155b99d8@mail.gmail.com> Message-ID: <20080709222138.GA18586@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On Wed, Jul 9, 2008 at 1:33 PM, Bill Nottingham wrote: > > This is independent of PolicyKit - AFAIK, there's no GUIs for this stuff. > > I thought the Authorization gui in F9 exposed the acl stuff for devices. > > Following the pda example you started in the Authorizations gui tree > aka polkit-gnome-authorizations from a terminal cmdline > > org > ->freedestop > ->hal > ->device-access > ->"Directly access PDA devices" > > Doesn't that directly related to the acl settings for the devices > marked with the pda capability? Oops, yes it does. Shame on me. > How would I go about getting another sort of device similarly listed > in the gui under device-access? At a minimum, you'd need a policy file similar to /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy for the device class. I'm not sure if this needs specific HAL modifications to add new classes, though. Try it and find out? Bill From kzak at redhat.com Wed Jul 9 23:02:27 2008 From: kzak at redhat.com (Karel Zak) Date: Thu, 10 Jul 2008 01:02:27 +0200 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709192336.GC7537@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> Message-ID: <20080709230227.GH22331@nb.net.home> On Wed, Jul 09, 2008 at 03:23:36PM -0400, Bill Nottingham wrote: > We've carried both pam_console and HAL-based ACL support for a while > now. It's time to cut the cord and remove pam_console, so we only > have one way of setting device permissions to worry about. Right. I'd like to remove a support for Fedora/RHEL specific 'pamconsole' mount option from mount(8). Comments? Karel -- Karel Zak From stickster at gmail.com Wed Jul 9 23:27:24 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Jul 2008 23:27:24 +0000 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: References: <4874FFAA.3030902@leemhuis.info> Message-ID: <1215646044.31212.41.camel@victoria> On Wed, 2008-07-09 at 23:34 +0300, Panu Matilainen wrote: > On Wed, 9 Jul 2008, Thorsten Leemhuis wrote: > > Just wondering. No, I really don't want to stop the new RPM; there are likely > > other examples (say OpenOffice 3.0) in rawhide (but going backwards there as > > hard as with RPM). But I'm more and more wondering if the complex Feature > > process is worth all the trouble and effort. The best thing that came out of > > it in F9 IMHO were the good release notes and great "whats new" pages. But > > I'd say we can have that easier. > > One reason for missing out on the feature process is probably that I've > found it somehow alien thing to begin with - I don't consider myself > working on a "Fedora feature", I'm "working on rpm.org upstream" to get a > much-needed update to the aging RPM version we have been living with for > ages. Mind you, this is not an excuse for missing out on distro policies. > The line between a "feature" and a "non-feature" is extremely obscure > really, and I think the point of "if you're unsure, ask" has not been made > sufficiently clear. Until perhaps now :) Maybe it also helps to think of the Fedora feature process as leveraging what Fedora can provide for an upstream community. Two things that come to mind immediately are QA/testing and widespread publicizing of the feature. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Wed Jul 9 23:33:33 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 09 Jul 2008 16:33:33 -0700 Subject: new RPM version and Feature process In-Reply-To: <4874FFAA.3030902@leemhuis.info> References: <4874FFAA.3030902@leemhuis.info> Message-ID: <48754ACD.60200@redhat.com> Thorsten Leemhuis said the following on 07/09/2008 > But this announcement made me wondering: We have a big and complicated > Feature process [1] in Fedora that keeps a whole lot of people and > committees (especially FESCo) busy. Afaics the new RPM version is > something that can be considered a "feature" [2]. It was afaics not > approved yet by FESCO [3] or even proposed [4]. I would expect going > backwards to an older RPM in rawhide later will be next to impossible or > very very hard. IOW: once it's in rawhide for a few days FESCO kind of > has no other chance then to approve this feature, in case it ever comes > up for a Feature vote in a FESCo meeting. Just because something is in rawhide does not force FESCo's hand to accept (note that is "accept" not "approve") the feature page, thus officially advertising it as a feature of our next release. I agree the feature process is not perfect and we have tried to keep it as un-cumbersome as possible--which is why there is no blocking on getting FESCo acceptance to be added to rawhide, etc. Just last week we completed our second public review of the process which sadly only had suggested changes by three people. http://fedoraproject.org/wiki/Features/F10PolicyReview > > So is the most of the Feature process (and especially FESCo's approval) > useless overhead? It looks to me that the answer tends to be "yes" as > long as big features like this can easily creep in without going through > the established approval process, as long as the feature gets added to > rawhide early enough in the devel cycle. I think you've overlooked some of its benefits: http://fedoraproject.org/wiki/Features/Policy#Background including the HUGE amount of equivalent marketing dollars the pages help drive which Paul mentioned at FUDCon. I'd argue the return on investment is there. > Just wondering. No, I really don't want to stop the new RPM; there are > likely other examples (say OpenOffice 3.0) in rawhide (but going > backwards there as hard as with RPM). But I'm more and more wondering if > the complex Feature process is worth all the trouble and effort. The > best thing that came out of it in F9 IMHO were the good release notes > and great "whats new" pages. But I'd say we can have that easier. I'm all ears. What are your specific ideas for a more effective process so it is worth all the "trouble and effort"? We've spent a lot of time up until now trying to get to a useful process, including the public reviews of the process we have at the start of each release. More participation and concrete suggestions from people like you would be greatly appreciated :) John From stickster at gmail.com Wed Jul 9 23:41:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Jul 2008 23:41:58 +0000 Subject: new RPM version and Feature process In-Reply-To: <48754ACD.60200@redhat.com> References: <4874FFAA.3030902@leemhuis.info> <48754ACD.60200@redhat.com> Message-ID: <1215646918.31212.49.camel@victoria> On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote: > Thorsten Leemhuis said the following on 07/09/2008 > > So is the most of the Feature process (and especially FESCo's approval) > > useless overhead? It looks to me that the answer tends to be "yes" as > > long as big features like this can easily creep in without going through > > the established approval process, as long as the feature gets added to > > rawhide early enough in the devel cycle. > > I think you've overlooked some of its benefits: > http://fedoraproject.org/wiki/Features/Policy#Background > > including the HUGE amount of equivalent marketing dollars the pages help > drive which Paul mentioned at FUDCon. > > I'd argue the return on investment is there. On top of the measurable part, there were a very large proportion -- I'd say it was fully half, out of more than a dozen interviews I gave for the Fedora 9 release -- where journalists asked direct questions about specific features. They almost always prefaced it by saying, "I read the feature pages on the wiki, which were really good. I was hoping you could explain further...". > > Just wondering. No, I really don't want to stop the new RPM; there are > > likely other examples (say OpenOffice 3.0) in rawhide (but going > > backwards there as hard as with RPM). But I'm more and more wondering if > > the complex Feature process is worth all the trouble and effort. The > > best thing that came out of it in F9 IMHO were the good release notes > > and great "whats new" pages. But I'd say we can have that easier. > > I'm all ears. What are your specific ideas for a more effective process > so it is worth all the "trouble and effort"? > > We've spent a lot of time up until now trying to get to a useful > process, including the public reviews of the process we have at the > start of each release. More participation and concrete suggestions from > people like you would be greatly appreciated :) -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Jul 9 23:44:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jul 2008 15:44:46 -0800 Subject: new RPM version and Feature process In-Reply-To: <48754ACD.60200@redhat.com> References: <4874FFAA.3030902@leemhuis.info> <48754ACD.60200@redhat.com> Message-ID: <604aa7910807091644x753bbc8dm4395c6e0708bd45d@mail.gmail.com> On Wed, Jul 9, 2008 at 3:33 PM, John Poelstra wrote: > We've spent a lot of time up until now trying to get to a useful process, > including the public reviews of the process we have at the start of each > release. More participation and concrete suggestions from people like you > would be greatly appreciated :) I think the next big return on investment outside of with regard to feature tracking is going to involve the maturation of some of the ideas and tools the QA people are playing with. I don't completely get everything that a usable testopia will do for us as a project..but I have a sense that once we gain some communal experience using it, if we can tie it into the Feature process its going to magnify the value of the Feature process significantly. -jef From stickster at gmail.com Thu Jul 10 00:10:15 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 10 Jul 2008 00:10:15 +0000 Subject: Killing off drivel Message-ID: <1215648615.31212.68.camel@victoria> Upstream for drivel, a GNOME-based blogging tool, has been dead for at least a year and a half. I am planning on making this package EOL. I don't believe an announcement is technically required, but I thought I should at least let people know here. Thanks to Tom Mraz and Alex Lancaster, who rebuilt it a few times of late when my attention was diverted elsewhere. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hpillay at redhat.com Thu Jul 10 00:28:10 2008 From: hpillay at redhat.com (Harish Pillay 9v1hp) Date: Thu, 10 Jul 2008 08:28:10 +0800 Subject: Killing off drivel In-Reply-To: <1215648615.31212.68.camel@victoria> References: <1215648615.31212.68.camel@victoria> Message-ID: <4875579A.7060300@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Upstream for drivel, a GNOME-based blogging tool, has been dead for at > least a year and a half. I am planning on making this package EOL. I > don't believe an announcement is technically required, but I thought I > should at least let people know here. Thanks to Tom Mraz and Alex > Lancaster, who rebuilt it a few times of late when my attention was > diverted elsewhere. Since I am a regular user of Drivel and do like the tool, I guess I now need to find out what I could do to ensure that it does not EOL here :-). Let me check. Thanks for the heads up, Paul. - -- Harish Pillay 9v1hp hpillay at redhat.com +65.9636.9253 gpg id: 746809E3 gpg fingerprint: F7F5 5CCD 25B9 FC25 303E 3DA2 0F80 27DB 7468 09E3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh1V5oACgkQD4An23RoCeM19QCfQ5fmVm5wqGix1a6EoE2kv8r1 A48AnAtqgCcosTE8601PgcBDgmDlUVyg =unGX -----END PGP SIGNATURE----- From rnicholsNOSPAM at comcast.net Thu Jul 10 00:44:01 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Wed, 09 Jul 2008 19:44:01 -0500 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <487535C4.9030704@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <487535C4.9030704@blagblagblag.org> Message-ID: jeff wrote: >> One question nobody has been able to answer to my satisfaction yet: Why >> would it be essential that SELinux can be disabled from the installer >> vs. from the installed system? Last time I checked, the plan was to get >> non-essential functionality out of anaconda. > > Essential may be a bit strong, but it may be "convenient". As I > understand it, if you boot the install CD with selinux=0 the filesystem > wont get labelled, making the install faster (and possibly less space?). > I'd like to confirm that though. > > Post install it would require an additional reboot to disable it, unless > you disabled it at boot: prompt. > > > My previous suggestion seems to easily solve this for everyone involved > though. > > 1) User types: "selinux=0" at boot: prompt of CD > > 2) anaconda parses this and installs without selinux, passing > "selinux=0" to grub > > 3) First boot up, selinux is already disabled (ala selinux=0 passed via > grub) > > > > The benefits are that people that do want SELinux are never confronted > with extra dialog boxes, power users that want to disable it have an > easy way to do so, and no rebooting and such ala windoz95. > > The only thing missing for this is to have anaconda pass "selinux=0" to > grub. It already supports the rest. It would require a 1 or two line > patch to anaconda: > > anaconda.id.bootloader.args.append("selinux=0") > > > In other words, if you pass selinux=0 to anaconda install, it currently > does *not* get passed to grub. It should, IMHO, and I don't see why it > can't/shouldn't. Anaconda already allows you to add arbitrary kernel parameters when configuring the bootloader. I always add "vga=791" and "selinux=0". -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From seg at haxxed.com Thu Jul 10 01:41:31 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 9 Jul 2008 20:41:31 -0500 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <4874FFAA.3030902@leemhuis.info> References: <4874FFAA.3030902@leemhuis.info> Message-ID: <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> On Wed, Jul 9, 2008 at 1:12 PM, Thorsten Leemhuis wrote: > But this announcement made me wondering: We have a big and complicated > Feature process [1] in Fedora that keeps a whole lot of people and > committees (especially FESCo) busy. Afaics the new RPM version is something > that can be considered a "feature" [2]. It was afaics not approved yet by > FESCO [3] or even proposed [4]. I would expect going backwards to an older > RPM in rawhide later will be next to impossible or very very hard. IOW: once > it's in rawhide for a few days FESCO kind of has no other chance then to > approve this feature, in case it ever comes up for a Feature vote in a FESCo > meeting. > > So is the most of the Feature process (and especially FESCo's approval) > useless overhead? It looks to me that the answer tends to be "yes" as long > as big features like this can easily creep in without going through the > established approval process, as long as the feature gets added to rawhide > early enough in the devel cycle. > > Just wondering. No, I really don't want to stop the new RPM; there are > likely other examples (say OpenOffice 3.0) in rawhide (but going backwards > there as hard as with RPM). But I'm more and more wondering if the complex > Feature process is worth all the trouble and effort. The best thing that > came out of it in F9 IMHO were the good release notes and great "whats new" > pages. But I'd say we can have that easier. This is my understanding: The Feature process was implemented to be a conduit for the Engineering side of Fedora to collaborate with the Marketing side of Fedora, to allow the Marketing people to build up pre-release hype for new features without having to second-guess us notoriously busy, and quiet, engineering types. It allows the Marketing people to keep tabs on engineering activities and have reasonable certainty as to the status of the feature, specifically whether or not it is going to be finished in time for the final release. It is a stack of bureaucracy in which us Engineering people voluntarily participate, in order to improve our PR activities for the greater good of the project. "voluntary" being the key word here. No one should be forced to participate. However not going through the feature process discourages the Marketing people from advertising your work in pre-release hype. Am I wrong? Honestly, though the new RPM affects us package monkeys quite a bit, I don't think it means much to the majority of general Fedora users. It *shouldn't* mean anything. RPM should be the machinery that, when its doing its job right, quietly goes on doing its job without anyone but us package monkeys noticing. Though I do foresee *cough* certain people *cough* complaining about how their spec they've used unchanged since RHL 6.2 no longer builds, and accuses us of "breaking things" and "actively sabotaging" RPM... So this should probably get prominent notice in the release notes, at least. From notting at redhat.com Thu Jul 10 02:26:27 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jul 2008 22:26:27 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709230227.GH22331@nb.net.home> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709230227.GH22331@nb.net.home> Message-ID: <20080710022627.GA24665@nostromo.devel.redhat.com> Karel Zak (kzak at redhat.com) said: > On Wed, Jul 09, 2008 at 03:23:36PM -0400, Bill Nottingham wrote: > > We've carried both pam_console and HAL-based ACL support for a while > > now. It's time to cut the cord and remove pam_console, so we only > > have one way of setting device permissions to worry about. > > Right. I'd like to remove a support for Fedora/RHEL specific > 'pamconsole' mount option from mount(8). Comments? Considering: a) 'user' and 'owner' already exist b) most any recent desktop isn't doing fstab editing anyway I'm not sure it's needed. Bill From mclasen at redhat.com Thu Jul 10 02:54:49 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Jul 2008 22:54:49 -0400 Subject: new RPM version and Feature process In-Reply-To: <48754ACD.60200@redhat.com> References: <4874FFAA.3030902@leemhuis.info> <48754ACD.60200@redhat.com> Message-ID: <1215658489.3885.14.camel@localhost.localdomain> On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote: > > I'm all ears. What are your specific ideas for a more effective process > so it is worth all the "trouble and effort"? > > We've spent a lot of time up until now trying to get to a useful > process, including the public reviews of the process we have at the > start of each release. More participation and concrete suggestions from > people like you would be greatly appreciated :) > Here are some comments on my recent experience with the feature process: I've just 'gotten back' a ton of feature pages with the comment 'please complete section a, b, c...' - but there is no definition anywhere of what each section is supposed to contain, so how can I know what 'complete' means ? So, I have to fly blind and put something in each section in the hope that it passes the next time. But it feels like there is a lot of overlap between the (undefined) topics on the feature template: If I've already filled out the 'detailed description', why am I asked to provide more details in the 'summary' ? And if I've already listed a ton of packages that need changes under 'scope', whats supposed to be put in 'dependencies' ? etc... In general, I think this whole process might be more pleasant if it felt less like writing a paper and getting it graded and more like a collaborative process. E.g. if instead of 'please complete the user experience section' I got some questions back like: 'I didn't quite understand how to turn this on, will there be a menu item ?', 'does this also require changes to package foo ?'. Matthias From davej at redhat.com Thu Jul 10 03:01:56 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 9 Jul 2008 23:01:56 -0400 Subject: make clean got noisy. In-Reply-To: <1215641602.3274.46.camel@localhost.localdomain> References: <20080709210843.GA4817@redhat.com> <1215641602.3274.46.camel@localhost.localdomain> Message-ID: <20080710030156.GA10747@redhat.com> On Wed, Jul 09, 2008 at 06:13:22PM -0400, Jesse Keating wrote: > On Wed, 2008-07-09 at 17:08 -0400, Dave Jones wrote: > > In my cvs checkout of devel/ , I just cvs updated the common/ dir, > > and now every make clean I do in each package spews this.. > > I think I see why, but out of curiosity what do you get for: > > rpm --eval %dist > > on this particular system? (hint, it should spit out something > like .fc9 due to /etc/rpm/macros.dist which comes from fedora-release. yep. (23:01:33:davej at gelk:~)$ rpm --eval %dist .fc9 Dave -- http://www.codemonkey.org.uk From itamar at ispbrasil.com.br Thu Jul 10 03:18:53 2008 From: itamar at ispbrasil.com.br (Itamar - IspBrasil) Date: Thu, 10 Jul 2008 00:18:53 -0300 Subject: mysql ndbcluster on fedora Message-ID: <48757F9D.8010906@ispbrasil.com.br> why mysql shipped with fedora doesn't have ndbcluster support ? there are a bugzilla open since 2005 asking for this. https://bugzilla.redhat.com/show_bug.cgi?id=163758 -------------------- 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 skvidal at fedoraproject.org Thu Jul 10 03:36:16 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 09 Jul 2008 23:36:16 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215635657.3055.0.camel@rosebud> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> <1215632145.13098.41.camel@aglarond.local> <1215635657.3055.0.camel@rosebud> Message-ID: <1215660976.5041.1.camel@rosebud> On Wed, 2008-07-09 at 16:34 -0400, seth vidal wrote: > On Wed, 2008-07-09 at 15:35 -0400, Jeremy Katz wrote: > > On Wed, 2008-07-09 at 15:18 -0400, seth vidal wrote: > > > On Wed, 2008-07-09 at 11:44 -0400, seth vidal wrote: > > > > Taking a list of pkgs, resolving out all of their deps then calculating > > > > installed size (not calculating vs an existing install, but raw > > > > installed size) shouldn't take too much code at all. I'll see what I can > > > > hack up today. > > > > > > > > It won't take into account overlaid files (like docs and manpages, nor > > > > multilib binaries) but it should give you a pretty good upper range > > > > (sort of). > > > > > > A start of what it should do. I'll fix up the kickstart parsing, among > > > other things, later - once I get some confirmation is even remotely in > > > the ballpark. > > > > > > http://skvidal.fedorapeople.org/misc/installed-size.py > > > > The thing which becomes important to see is growth (or shrinkage) in > > packages as well as what new packages/removed packages there are. Which > > involves fiddly questions of growth thresholds and human analysis of the > > output > > I can output a csv of the pkgs that would be installed. > as we discussed in jabber - I've changed: ?http://skvidal.fedorapeople.org/misc/installed-size.py to output: size\tname.arch for all the pkgs in the requested trees. If the numbers look right-ish I'll work on getting it to take a ks.cfg as its input. -sv From fdinitto at redhat.com Thu Jul 10 03:56:13 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Thu, 10 Jul 2008 05:56:13 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <4874D9E2.7090807@kanarip.com> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> <4874D9E2.7090807@kanarip.com> Message-ID: <1215662173.15940.6.camel@daitarn-fedora.int.fabbione.net> On Wed, 2008-07-09 at 17:31 +0200, Jeroen van Meeuwen wrote: > Fabio M. Di Nitto wrote: > > On Tue, 2008-07-08 at 09:58 +0300, David Juran wrote: > >> On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: > >>> Please review the following packages. This is roughly the list of > >>> current orphans in rawhide. If they are not claimed by June 18th then > >>> they may be removed from rawhide by the F10 Alpha freeze. > >>> perl-Net-Telnet > >> perl-Net-Telnet is required by several of the fencing agents included in > >> the cman rpm. > >> > > > > Oh I missed this one.. I will take it if nobody else wants it. > > > > I'm willing to (co-)maintain this... can we make it a group effort in > keeping this in? Absolutely! I left the package open to cvsextras and you should have received the "spam" from pkgdb already :) Thanks Fabio PS I took it over mainly because I maintain cman/cluster that needs it and I can't allow it to disappear from the distro. You are absolutely welcome to maintain or co- it as much as you want. From abartlet at samba.org Thu Jul 10 05:46:11 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 10 Jul 2008 15:46:11 +1000 Subject: Copyright licence finder? In-Reply-To: <20080701211336.7c2abca6@infradead.org> References: <1214964972.6614.21.camel@naomi.s4.naomi.abartlet.net> <20080701211336.7c2abca6@infradead.org> Message-ID: <1215668771.3624.8.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-07-01 at 21:13 -0700, Arjan van de Ven wrote: > On Wed, 02 Jul 2008 12:16:12 +1000 > Andrew Bartlett wrote: > > > I wondered if, in auditing for licence tag correctness, if anybody had > > written a copyright/licence block finder? > > > > I'm thinking of a tool that looks for comment blocks in C code that > > look like copyright notices, and complies them together listing only > > unique licences. > > > > have you looked at fossology ? I've tried to set that up, but it seems very heavy-weight. I couldn't get it set up, on the debian unstable VM I tried. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Jul 10 06:09:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jul 2008 08:09:59 +0200 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1215632624.32502.19.camel@weaponx> References: <4874FFAA.3030902@leemhuis.info> <1215628010.32502.9.camel@weaponx> <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> <1215632624.32502.19.camel@weaponx> Message-ID: <20080710060959.GA2732@free.fr> On Wed, Jul 09, 2008 at 03:43:44PM -0400, Josh Boyer wrote: > > 5) Are you trying to promote this package as a Feature for publicity > reasons? I think that only this one should be relevant. That is is the packager willing to communicate the change. -- Pat From pmatilai at redhat.com Thu Jul 10 07:21:28 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Thu, 10 Jul 2008 10:21:28 +0300 (EEST) Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <20080710060959.GA2732@free.fr> References: <4874FFAA.3030902@leemhuis.info> <1215628010.32502.9.camel@weaponx> <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> <1215632624.32502.19.camel@weaponx> <20080710060959.GA2732@free.fr> Message-ID: On Thu, 10 Jul 2008, Patrice Dumas wrote: > On Wed, Jul 09, 2008 at 03:43:44PM -0400, Josh Boyer wrote: >> >> 5) Are you trying to promote this package as a Feature for publicity >> reasons? > > I think that only this one should be relevant. That is is the packager > willing to communicate the change. Heh, some of us could use LESS publicity, this already made it into LWN despite being just an early warning. - Panu - From pertusus at free.fr Thu Jul 10 07:46:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jul 2008 09:46:03 +0200 Subject: SLiM problem In-Reply-To: <486CD1E3.8010804@gmail.com> References: <486CD1E3.8010804@gmail.com> Message-ID: <20080710074603.GD2732@free.fr> On Thu, Jul 03, 2008 at 08:19:31AM -0500, Ted X Toth wrote: > I've installed slim and edited /etc/sysconfig/desktop to specify > slim-dynwm but on boot I don't get a slim login screen. I've looked at > the slim log and there is a complaint about not being able to load the > default theme and also if I ssh in I don't see an X server running. Any > idea what's going wrong? I think that this issue is better tracked in a bug report, so please file a bug if you haven't already. I'll try to have a look at this issue over the week-end. -- Pat From varekova at redhat.com Thu Jul 10 08:00:59 2008 From: varekova at redhat.com (Ivana Varekova) Date: Thu, 10 Jul 2008 10:00:59 +0200 Subject: new orphan package - man-pages-da Message-ID: <4875C1BB.10008@redhat.com> I just release the ownership of man-pages-da manpages - if here is anybody willing to take care about this package you grab it :). Thanks. Ivana Varekova From mschwendt at gmail.com Thu Jul 10 08:14:28 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 10 Jul 2008 10:14:28 +0200 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> References: <4874FFAA.3030902@leemhuis.info> <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> Message-ID: <20080710101428.99277133.mschwendt@gmail.com> On Wed, 9 Jul 2008 20:41:31 -0500, Callum Lerwick wrote: > Though I do foresee *cough* certain people *cough* complaining about > how their spec they've used unchanged since RHL 6.2 no longer builds, > and accuses us of "breaking things" and "actively sabotaging" RPM... > So this should probably get prominent notice in the release notes, at > least. Oh, that will get funny anyway if packagers start using the new features, such as %{patches}, and run into problems when mass-copying their %{dist}-poisoned spec files to older branches. ;) From aoliva at redhat.com Thu Jul 10 08:02:38 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 10 Jul 2008 05:02:38 -0300 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: (Greg Dekoenigsberg's message of "Tue\, 8 Jul 2008 15\:08\:33 -0400 \(EDT\)") References: Message-ID: On Jul 8, 2008, Greg Dekoenigsberg wrote: > -- the education of the world's children -- with the use of free > software as the central component of their software strategy. > The first opportunities are for the Fedora packagers. This work can be > done right now, today. Hey, can I help by keeping their kernel free from non-Free Software? As in, any reason why they wouldn't want to use linux-libre-based kernel packages? AFAIK they don't even need any of the firmwares that ship with Linus' Linux-non-libre. I'd be quite happy to do that. In fact, it's something that has been in my to-do list for a while. I installed the OLPC userland with linux-libre for my 4-year-old daughter on her (non-X0) notebook, about half a year ago, ninitially using Fedora non-Free kernels, more recently with freed-ora linux-libre builds, and she has a lot of fun (and learning :-) with it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From konrad at tylerc.org Thu Jul 10 08:24:21 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Thu, 10 Jul 2008 01:24:21 -0700 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <200807100124.22222.konrad@tylerc.org> Quoth Alexandre Oliva: > On Jul 8, 2008, Greg Dekoenigsberg wrote: > > > -- the education of the world's children -- with the use of free > > software as the central component of their software strategy. > > > > The first opportunities are for the Fedora packagers. This work can be > > done right now, today. > > Hey, can I help by keeping their kernel free from non-Free Software? > > As in, any reason why they wouldn't want to use linux-libre-based > kernel packages? AFAIK they don't even need any of the firmwares that > ship with Linus' Linux-non-libre. > > I'd be quite happy to do that. In fact, it's something that has been > in my to-do list for a while. I installed the OLPC userland with > linux-libre for my 4-year-old daughter on her (non-X0) notebook, about > half a year ago, ninitially using Fedora non-Free kernels, more > recently with freed-ora linux-libre builds, and she has a lot of fun > (and learning :-) with it. > > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} > FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Please stop, the horse hasn't even begun to recover yet. -- Conrad Meyer -------------- 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 j.w.r.degoede at hhs.nl Thu Jul 10 08:10:32 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jul 2008 10:10:32 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <20080709182121.GA17723@marvin> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> <4874D9E2.7090807@kanarip.com> <4874FC8C.4090500@hhs.nl> <20080709182121.GA17723@marvin> Message-ID: <4875C3F8.1090501@hhs.nl> Nikolay Vladimirov wrote: > On (09/07/08 19:59), Hans de Goede wrote: >> Hi All, >> >> I've retaken PyOpenGL and pygtkglext again (they were mine I released >> them for someone to pick up, but that appearantly didn't happen. >> >> Regards, >> >> Hans >> > > Greetings! > > I'm willing to maintain PyOpenGL and comaintain pygtkglext. > Ok, I've released PyOpenGL again, so its yours to take and if you request the necessary rights for pygtkglext I'll grant them. Regards, Hans From mschwendt at gmail.com Thu Jul 10 08:03:22 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 10 Jul 2008 10:03:22 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <200807091702.03174.jwilson@redhat.com> References: <200807091228.00498.jwilson@redhat.com> <544eb990807091015x48f4e572mb6ff4872178bfa95@mail.gmail.com> <200807091702.03174.jwilson@redhat.com> Message-ID: <20080710100322.d20ec0fb.mschwendt@gmail.com> On Wed, 9 Jul 2008 17:02:03 -0400, Jarod Wilson wrote: > > >> %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} > > >> > > >> I've done this in my .rpmmacros file for a long time and am happy with > > >> it. > > > > > > Been doing something similar myself for ages, but also dropping the spec > > > file in with the source files. A directory full of specs and a directory > > > full of sources for umpteen different packages is dumb. > > > > This breaks doing build-from-tarball, because until the spec is > > parsed, the version is unknown. > > My "something similar" doesn't actually include %{version}, only %{name}. Including %version breaks if a sub-package defines its own %version. From abartlet at samba.org Thu Jul 10 09:46:09 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 10 Jul 2008 19:46:09 +1000 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807021754.52422.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807021754.52422.jbarnes@virtuousgeek.org> Message-ID: <1215683169.3624.67.camel@naomi.s4.naomi.abartlet.net> On Wed, 2008-07-02 at 17:54 -0700, Jesse Barnes wrote: > On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > > for Fedora. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > > OpenChange) > > > > This will enable much better access to Microsoft Exchange servers from > > clients such as kdepim, and hopefully Evolution (pending a > > re-licensing). > > > > I've got a feature page for this here: > > > > https://fedoraproject.org/wiki/Features/OpenChange > > > > Now, the reason I'm posting here is that I would rather not do this > > alone, and would love some co-maintainers of the packagers above, or at > > least some help with the review and sponsorship, or advise on the best > > way forward. > > > > Any assistance gratefully received, > > Just pulled down the packages (including the alpha5 samba4 package) and > started building. I haven't got to the kde libraries yet (that build will > probably take awhile) but on the packages above, I found the following: > > heimdal: > - openssl-devel depends on krb5-devel, but heimdal-devel conflicts with > krb5-devel; should it provide it or do we need a virtual provides for > krb5? I'm not sure what the best way to handle this interaction is. This build (due to the OpenSSL licence) avoids using OpenSSL as a build depencency on Heimdal. I'm also not sure if the OpenSSL dependency on krb5 is useful anyway - but we might be stuck with it. (At one point it enabled an experimantal krb5-in-SSL hack, which only OpenSSL supported). > - heimdal seemed to be missing a file directive for the dir.gz info file > samba4: > - everything seems fine here so far... > libmapi: > - didn't list the popt requirement, so initially I built without it and the > packaging failed due to missing binaries (which required popt-devel) > - libmapi-devel should depend on libmapi-0.7... rather than > libmapi-libs-0.7...? Thanks. I'll look into it. > I've attached my spec file diffs in case you want to see (though now I see > you've already fixed the libmapi-libs problem I saw)... > > Thanks for packaging this stuff, I really hope the MAPI Akonadi code works; > I'd *love* to ditch Outlook (it's the next best thing to escaping the > Exchange ghetto). Now what I really need is a sponsor, or packager willing to take this effort over... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Thu Jul 10 10:17:03 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 10 Jul 2008 12:17:03 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215612241.10164.17.camel@localhost.localdomain> Message-ID: <1215685023.14041.3.camel@gibraltar.str.redhat.com> On Wed, 2008-07-09 at 19:41 +0300, Panu Matilainen wrote: > On Wed, 9 Jul 2008, Tom "spot" Callaway wrote: > > > On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > >> 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under > >> %{_topdir}/BUILDROOT/ > > > > A few questions here: > > > > Is the BuildRoot from the spec ignored, or does it override the default > > buildroot? > > BuildRoot from spec is completely ignored. > > > Is the default buildroot literally "%{_topdir}/BUILDROOT/" or is it > > something more complicated. I could easily see a case where two > > concurrent rpm builds could step on each other's buildroots. > > The default buildroot is currently defined literally this way: > %buildrootdir %{_topdir}/BUILDROOT > %buildroot %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch} Hmm, this could (possibly) clash in the (unlikely) case of building the same n-v-r.a concurrently as a real and scratch build in koji (or two or more scratch builds). Perhaps koji should set a unique %_buildrootdir as it does up to now with %_tmppath? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mjg59 at srcf.ucam.org Thu Jul 10 10:29:15 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Thu, 10 Jul 2008 11:29:15 +0100 Subject: pm-utils for F8 and Advanced power management In-Reply-To: References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> Message-ID: <20080710102915.GB5017@srcf.ucam.org> On Wed, Jul 09, 2008 at 06:32:16AM -0400, Colin Walters wrote: > Putting syslog on tmpfs by default and limiting the total size to something > like 5MB would be something to evaluate for the default desktop. I looked into this, and we're not actually doing too badly - our syslogd doesn't fsync() after every log entry. I'm broadly in favour of using tmpfs, though. There's an argument that certain priorities probably want to stay on disk, but otherwise we can simply sync the tmpfs to disk on shutdown or reboot. -- Matthew Garrett | mjg59 at srcf.ucam.org From berrange at redhat.com Thu Jul 10 11:05:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 Jul 2008 12:05:02 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708193226.GA17810@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <20080708193226.GA17810@amd.home.annexia.org> Message-ID: <20080710110502.GA10914@redhat.com> On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote: > > +%define __os_install_post /usr/lib/rpm/brp-compress %{nil} > > Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't > work, but actually corrupts the files. Therefore we must disable > stripping. I'd love to know how to force RPM to either ignore files > in certain directories, or to call the correct strip binary on them. > The original SRPMs that I was working with contained a very long and > hairy bit of code which apparently did this, but I wasn't daring > enough to include it. I think that %define will affect the main RPM, as well as mingw sub-RPM, so we can't simply set it to %{nil}. Couple of options that I see - Find out what's wrong with strip & fix it - Modify the default brp-compress script to avoid mingw files - Create a wrapper around default brp-compress script to filer mingw files and %define __os_install_post to use that > +BuildRequires: mingw-gcc > +BuildRequires: mingw-binutils > +BuildRequires: mingw-libgpg-error > +BuildRequires: mingw-libgcrypt > + > +Requires: mingw-runtime > +Requires: mingw-libgpg-error > +Requires: mingw-libgcrypt > > Main package definition. Note that we don't have any automatic > find-requires working at the moment, so we need to define dependent > packages explicitly. Doesn't the default ELF find-rquires already discover these ? I thought it would look for all ELF files no matter where they were installed ? > I've split the build by configuring & building in two subdirectories, > ie. the general pattern is: > > pushd build > ../configure &c > popd > pushd i686-pc-mingw32 > ../configure --host=i686-pc-mingw32 &c > popd > > Note the hack to make %configure work in a subdirectory. Any easier way? While this works for GNUTLS I don't think we can assume that all libs we want will support VPATH builds. IIRC the way the kernel deals with this is to have a completely separate source tree per build target. We could do this by changing %setup to %setup -c So the sources end up in rpm/BUILD/gnutls-2.4.1/gnutls-2.4.1 Then in the %build seciton we can copy the source tree for mingw cp -a %{name}-%{version} %{name}-%{version}-mingw pushd %{name}-%{version} %configure make popd pushd %{name}-%{version} %configure --host=i686-pc-mingw32 make popd Takes extra disk space during the build of course,but none of the things we're looking at are particularly large. Oh, we probably also want to have a %define with_mingw at the top of the spec files to allow the mingw sub-RPM to be turned on/off easily. This will speed up build times during regular package maintainer work. 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 buc at odusz.so-cdu.ru Thu Jul 10 11:07:24 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 10 Jul 2008 15:07:24 +0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709192336.GC7537@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> Message-ID: <4875ED6C.4040800@odu.neva.ru> Bill Nottingham wrote: > We've carried both pam_console and HAL-based ACL support for a while > now. It's time to cut the cord and remove pam_console, so we only > have one way of setting device permissions to worry about. > Just in case: I hope that pam_console will not be removed from the distribution at all. Besides the permission stuff in its "session" part, it also contains useful features in "auth" ... ~buc From jwboyer at gmail.com Thu Jul 10 11:24:07 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 10 Jul 2008 07:24:07 -0400 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <20080710060959.GA2732@free.fr> References: <4874FFAA.3030902@leemhuis.info> <1215628010.32502.9.camel@weaponx> <604aa7910807091226p1787e9f9l683e7a4878b2cda6@mail.gmail.com> <1215632624.32502.19.camel@weaponx> <20080710060959.GA2732@free.fr> Message-ID: <1215689047.14579.0.camel@weaponx> On Thu, 2008-07-10 at 08:09 +0200, Patrice Dumas wrote: > On Wed, Jul 09, 2008 at 03:43:44PM -0400, Josh Boyer wrote: > > > > 5) Are you trying to promote this package as a Feature for publicity > > reasons? > > I think that only this one should be relevant. That is is the packager > willing to communicate the change. I don't. Features aren't only about publicity. If they are large enough and could potentially break things, FESCo/QA/RelEng want to see test plans and fallback options. josh From harald at redhat.com Thu Jul 10 11:34:27 2008 From: harald at redhat.com (Harald Hoyer) Date: Thu, 10 Jul 2008 13:34:27 +0200 Subject: rakarrack - Guitar Effects Processor Message-ID: Anyone interested to maintain and add this to Fedora? ABOUT Rakarrack is a guitar effects processor for GNU / Linux simple and easy to use but it contains features that make it unique in this field of applications. It contains 17 effects: Linear Equalizer, Parametric Equalizer, Compressor, Distorsion, Overdrive, Echo, Chorus, Phaser, Flanger Reverb, WahWah, Alienwah, Harmonizer, NoiseGate, Musical Delay, Cabinet, AutoPan/Extra Stereo. It integrates a tuner and a MIDI converter. It can also be handled by an external MIDI controller. The settings designed by the user can be stored in presets and these presets can be used to create banks of effects. Dave Phillips has wrote an article about Rakarrack in the Linux Journal Magazine and described it as ?By far the best standalone guitar effects processor currently available for Linux? http://www.linuxjournal.com/content/rakarrack-guitar-fx-linux From harald at redhat.com Thu Jul 10 11:36:58 2008 From: harald at redhat.com (Harald Hoyer) Date: Thu, 10 Jul 2008 13:36:58 +0200 Subject: rakarrack - Guitar Effects Processor In-Reply-To: References: Message-ID: Harald Hoyer wrote: > Anyone interested to maintain and add this to Fedora? > > > ABOUT > Rakarrack is a guitar effects processor for GNU / Linux simple and easy > to use but it contains features that make it unique in this field of > applications. It contains 17 effects: Linear Equalizer, Parametric > Equalizer, Compressor, Distorsion, Overdrive, Echo, Chorus, Phaser, > Flanger Reverb, WahWah, Alienwah, Harmonizer, NoiseGate, Musical Delay, > Cabinet, AutoPan/Extra Stereo. It integrates a tuner and a MIDI > converter. It can also be handled by an external MIDI controller. The > settings designed by the user can be stored in presets and these presets > can be used to create banks of effects. > > > Dave Phillips has wrote an article about Rakarrack in the Linux Journal > Magazine and described it as ?By far the best standalone guitar effects > processor currently available for Linux? > http://www.linuxjournal.com/content/rakarrack-guitar-fx-linux > doh.. link to homepage missing.. http://rakarrack.sourceforge.net/ From harald at redhat.com Thu Jul 10 11:40:26 2008 From: harald at redhat.com (Harald Hoyer) Date: Thu, 10 Jul 2008 13:40:26 +0200 Subject: Audio SIG - Jacklab spin Message-ID: Anyone interested in an audio SIG? We could create a jacklab like spin ( http://jacklab.org/ ) with jackd as the main audio daemon. From j.w.r.degoede at hhs.nl Thu Jul 10 11:57:49 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jul 2008 13:57:49 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: <4875F93D.7050701@hhs.nl> Harald Hoyer wrote: > Anyone interested in an audio SIG? > > We could create a jacklab like spin ( http://jacklab.org/ ) with jackd > as the main audio daemon. > Actually I've been working (some time ago) on getting most of ccrnma into Fedora, I think that would be a good start. Unfortunately I've stopped part way through, due to lack of time. No if only someone would hire me to work on FOSS stuff fulltime Regards, Hans From kanarip at kanarip.com Thu Jul 10 12:03:03 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 10 Jul 2008 14:03:03 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: <4875FA77.1090208@kanarip.com> Harald Hoyer wrote: > Anyone interested in an audio SIG? > > We could create a jacklab like spin ( http://jacklab.org/ ) with jackd > as the main audio daemon. > Could you create a Feature page in Category ProposedFeatureF10, so we can keep track of developments? Also, as work continues on the kickstart, it might be worthwhile requesting membership to the gitspin-kickstarts FAS group so you have commit access to it's GIT repository at git://git.fedorahosted.org/spin-kickstarts.git (contributions for F10 should go to the master branch). Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Thu Jul 10 12:03:46 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 10 Jul 2008 14:03:46 +0200 Subject: Rawhide Orphanarium Purge: June 18th In-Reply-To: <1215662173.15940.6.camel@daitarn-fedora.int.fabbione.net> References: <48728552.3040706@redhat.com> <1215500325.4584.26.camel@dhcppc2> <1215500397.19181.2.camel@daitarn-fedora.int.fabbione.net> <4874D9E2.7090807@kanarip.com> <1215662173.15940.6.camel@daitarn-fedora.int.fabbione.net> Message-ID: <4875FAA2.5020202@kanarip.com> Fabio M. Di Nitto wrote: > On Wed, 2008-07-09 at 17:31 +0200, Jeroen van Meeuwen wrote: >> Fabio M. Di Nitto wrote: >>> On Tue, 2008-07-08 at 09:58 +0300, David Juran wrote: >>>> On Mon, 2008-07-07 at 17:06 -0400, Warren Togami wrote: >>>>> Please review the following packages. This is roughly the list of >>>>> current orphans in rawhide. If they are not claimed by June 18th then >>>>> they may be removed from rawhide by the F10 Alpha freeze. >>>>> perl-Net-Telnet >>>> perl-Net-Telnet is required by several of the fencing agents included in >>>> the cman rpm. >>>> >>> Oh I missed this one.. I will take it if nobody else wants it. >>> >> I'm willing to (co-)maintain this... can we make it a group effort in >> keeping this in? > > Absolutely! I left the package open to cvsextras and you should have > received the "spam" from pkgdb already :) > > Thanks Thank you ;-) > > PS I took it over mainly because I maintain cman/cluster that needs it > and I can't allow it to disappear from the distro. You are absolutely > welcome to maintain or co- it as much as you want. > I took it over since I'm heavily dependent on perl-Net-Telnet-Cisco for business, so if there's anything, I can afford to spend some paid-for time on the package. I'll request a EPEL-5 branch right-away as well, since some of the machines I use it on are running EL-5. Kind regards, Jeroen van Meeuwen -kanarip From stickster at gmail.com Thu Jul 10 12:50:00 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 10 Jul 2008 12:50:00 +0000 Subject: Killing off drivel In-Reply-To: <4875579A.7060300@redhat.com> References: <1215648615.31212.68.camel@victoria> <4875579A.7060300@redhat.com> Message-ID: <1215694200.31212.136.camel@victoria> On Thu, 2008-07-10 at 08:28 +0800, Harish Pillay 9v1hp wrote: > > Upstream for drivel, a GNOME-based blogging tool, has been dead for at > > least a year and a half. I am planning on making this package EOL. I > > don't believe an announcement is technically required, but I thought I > > should at least let people know here. Thanks to Tom Mraz and Alex > > Lancaster, who rebuilt it a few times of late when my attention was > > diverted elsewhere. > > Since I am a regular user of Drivel and do like the tool, I guess I > now need to find out what I could do to ensure that it does not EOL > here :-). > > Let me check. > > Thanks for the heads up, Paul. I think you can apply for maintainership in the PkgDB application: https://admin.fedoraproject.org/pkgdb http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb#Signing_up_for_packages I don't know whether you're already a package maintainer, but I'm happy to help you get started where I can. You'd be the sole maintainer of the drivel package if you accept. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmatilai at redhat.com Thu Jul 10 12:56:21 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Thu, 10 Jul 2008 15:56:21 +0300 (EEST) Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1215637928.3274.40.camel@localhost.localdomain> References: <4874FFAA.3030902@leemhuis.info> <1215637928.3274.40.camel@localhost.localdomain> Message-ID: On Wed, 9 Jul 2008, Jesse Keating wrote: > On Wed, 2008-07-09 at 23:34 +0300, Panu Matilainen wrote: >> >> The simple-minded bass-player in me has just one practical question: what >> do we do about it? Sure we can go through the feature process, it'll just >> probably mean the new rpm will miss F10 alpha. Whether that's a good thing >> or not might depend on if you're in rel-eng or not ;) > > If we can dedicate a couple helpers to you, I bet we could get a feature > page written up quickly, and I bet we could get FESCo approval in good > faith on getting a suitable feature page up, after the package is built. Well then, here you go: https://fedoraproject.org/wiki/Features/RPM4.6 The new rpm isn't committed or built yet, I'm going to wait for approval so nobody gets to complain we didn't go by the book. In the meanwhile, you can find the SRPMS for the new rpm and couple of more critical packages patched to build + work with it here: http://laiskiainen.org/rpm/srpms/ The rpm package is huge because it has db-4.5.20 tarball in it. This isn't the way it's going to be built for Fedora, it's just a temporary measure to make testing easier. - Panu - From jkeating at redhat.com Thu Jul 10 13:50:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jul 2008 09:50:00 -0400 Subject: make clean got noisy. In-Reply-To: <20080710030156.GA10747@redhat.com> References: <20080709210843.GA4817@redhat.com> <1215641602.3274.46.camel@localhost.localdomain> <20080710030156.GA10747@redhat.com> Message-ID: <1215697800.8454.3.camel@localhost.localdomain> On Wed, 2008-07-09 at 23:01 -0400, Dave Jones wrote: > > yep. > > (23:01:33:davej at gelk:~)$ rpm --eval %dist > .fc9 Hrm, I can't duplicate. Any chance I could get a shell on that system? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 notting at redhat.com Thu Jul 10 13:02:30 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Jul 2008 09:02:30 -0400 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710102915.GB5017@srcf.ucam.org> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> Message-ID: <20080710130230.GA29114@nostromo.devel.redhat.com> Matthew Garrett (mjg59 at srcf.ucam.org) said: > On Wed, Jul 09, 2008 at 06:32:16AM -0400, Colin Walters wrote: > > > Putting syslog on tmpfs by default and limiting the total size to something > > like 5MB would be something to evaluate for the default desktop. > > I looked into this, and we're not actually doing too badly - our syslogd > doesn't fsync() after every log entry. I'm broadly in favour of using > tmpfs, though. There's an argument that certain priorities probably want > to stay on disk, but otherwise we can simply sync the tmpfs to disk on > shutdown or reboot. Maybe I'm unusual, but I rarely reboot my laptop cleanly. I'm not sure I'd want X weeks of logs to go away. Are there any sorts of mechanisms to do per-directory or per-file writeback caching, so that /var/log/ could be set to 'sync only every 15 minutes', or similar? Bill From mschmidt at redhat.com Thu Jul 10 14:08:08 2008 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 10 Jul 2008 16:08:08 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: <20080710160808.7ef6423a@brian.englab.brq.redhat.com> On Thu, 10 Jul 2008 13:40:26 +0200 Harald Hoyer wrote: > Anyone interested in an audio SIG? > > We could create a jacklab like spin ( http://jacklab.org/ ) with > jackd as the main audio daemon. Would the absence of a real-time kernel variant in Fedora be a problem for such a spin? Fedora kernel only has voluntary preemption enabled. All the audio-specialized distributions I've heard about ship with an RT-patched kernel. Michal From davidz at redhat.com Thu Jul 10 14:08:30 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 10 Jul 2008 10:08:30 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709192336.GC7537@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> Message-ID: <1215698910.6152.4.camel@x61.fubar.dk> On Wed, 2008-07-09 at 15:23 -0400, Bill Nottingham wrote: > We've carried both pam_console and HAL-based ACL support for a while > now. It's time to cut the cord and remove pam_console, so we only > have one way of setting device permissions to worry about. The plan is actually to move this to ConsoleKit (HAL is going away and all that etc. etc.) but that's most likely F11 material. So suggest to hold off this feature for now. David From mjg59 at srcf.ucam.org Thu Jul 10 14:10:01 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Thu, 10 Jul 2008 15:10:01 +0100 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710130230.GA29114@nostromo.devel.redhat.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> <20080710130230.GA29114@nostromo.devel.redhat.com> Message-ID: <20080710141001.GA10449@srcf.ucam.org> On Thu, Jul 10, 2008 at 09:02:30AM -0400, Bill Nottingham wrote: > Maybe I'm unusual, but I rarely reboot my laptop cleanly. I'm not sure I'd > want X weeks of logs to go away. > > Are there any sorts of mechanisms to do per-directory or per-file writeback > caching, so that /var/log/ could be set to 'sync only every 15 minutes', > or similar? Not that I can think of. Implementing it in rsyslog might be the easiest option, though that would still leave apps that do their logging by hand. Maybe we should just fix them all up to use syslog when possible. -- Matthew Garrett | mjg59 at srcf.ucam.org From mmcgrath at redhat.com Thu Jul 10 14:34:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 10 Jul 2008 09:34:15 -0500 (CDT) Subject: Outage Notification - 2008-07-11 17:00 UTC Message-ID: There will be an outage starting at 2008-07-11 17: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 '2008-07-11 17:00 UTC' Affected Services: Websites CVS / Source Control Buildsystem Database DNS Mail Fedora Hosted Unaffected Services: Torrent Fedora People talk.fedoraproject.org Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/694 Reason for Outage: Many of our services were updated last week some of them need to be rebooted to take up a new kernel. Additionally I'll be on site in Phoenix working on a few things and will have to take a couple of services down while I make some network changes. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Thu Jul 10 15:00:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jul 2008 11:00:32 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215685023.14041.3.camel@gibraltar.str.redhat.com> References: <1215612241.10164.17.camel@localhost.localdomain> <1215685023.14041.3.camel@gibraltar.str.redhat.com> Message-ID: <1215702032.8454.13.camel@localhost.localdomain> On Thu, 2008-07-10 at 12:17 +0200, Nils Philippsen wrote: > > Hmm, this could (possibly) clash in the (unlikely) case of building the > same n-v-r.a concurrently as a real and scratch build in koji (or two or > more scratch builds). Perhaps koji should set a unique %_buildrootdir as > it does up to now with %_tmppath? Koji has completely unique chroots per build to begin with. There is almost 0 chance of two builds colliding in koji. (the only way I can see is if one build has in one of it's seconds a call to build itself again, which is all kinds of crack) -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 alan at redhat.com Thu Jul 10 15:05:24 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 10 Jul 2008 11:05:24 -0400 Subject: Install dies at waiting for hardware to init - sorta In-Reply-To: <2a28d2ab0807090721j5786c54et5d2eea0b67a17b30@mail.gmail.com> References: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> <2a28d2ab0807090721j5786c54et5d2eea0b67a17b30@mail.gmail.com> Message-ID: <20080710150524.GD15464@devserv.devel.redhat.com> On Wed, Jul 09, 2008 at 10:21:35AM -0400, Dr. Diesel wrote: > Several messages to and from Mark Lord, the sata_mv driver is not what > is causing the install to hang. Also the Highpoint problems of > Is it possible to boot with a kernel argument that bypassed sata_mv? I don't quite follow. You've established it isn't causing the hang you say so why do you want to bypass it ? From jkeating at redhat.com Thu Jul 10 15:06:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jul 2008 11:06:30 -0400 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> References: <4874FFAA.3030902@leemhuis.info> <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> Message-ID: <1215702390.8454.18.camel@localhost.localdomain> On Wed, 2008-07-09 at 20:41 -0500, Callum Lerwick wrote: > Am I wrong? Yes. As previously stated the feature pages are way more than just marketing fluff. Features have very real schedule impact, just consider this time around, RPM with a bunch of new features, and a new gcc coming at some point soon. Usually we want to rebuild for both of those. Without some high level coordination, how do we schedule so that we rebuild once for all of the right reasons instead of multiple times individually? How can releng/qa properly schedule timelines for testing and what should be tested based on the changes? How do we know when we should slip for specific features that are close but just haven't quite made it yet? The feature process allows greater visibility and coordination across the entire distribution, which is quite large. Fedora is a far cry from the RHL days when most everybody working on it was in the same room, and the few that weren't were easy to find on IRC. We're vastly different and larger and need these communication/coordination efforts to continue to be successful. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 dr.diesel at gmail.com Thu Jul 10 15:11:39 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 10 Jul 2008 10:11:39 -0500 Subject: Install dies at waiting for hardware to init - sorta In-Reply-To: <20080710150524.GD15464@devserv.devel.redhat.com> References: <2a28d2ab0807070821y5af0bae2g2e957fccf20c4d51@mail.gmail.com> <2a28d2ab0807090721j5786c54et5d2eea0b67a17b30@mail.gmail.com> <20080710150524.GD15464@devserv.devel.redhat.com> Message-ID: <2a28d2ab0807100811v27659159lc92aa1290c88fdcf@mail.gmail.com> On Thu, Jul 10, 2008 at 10:05 AM, Alan Cox wrote: > On Wed, Jul 09, 2008 at 10:21:35AM -0400, Dr. Diesel wrote: >> Several messages to and from Mark Lord, the sata_mv driver is not what >> is causing the install to hang. Also the Highpoint problems of > >> Is it possible to boot with a kernel argument that bypassed sata_mv? > > I don't quite follow. You've established it isn't causing the hang you say > so why do you want to bypass it ? > For confirmation and to reduce/eliminate the chance of the BIOS/Sector 8 etc problem you first enlightened me to. Any idea why it loses "sight" of the install media? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From sebastian at when.com Thu Jul 10 15:15:28 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Thu, 10 Jul 2008 17:15:28 +0200 Subject: Announcing the Fedora EDU Spin Preview Message-ID: <48762790.8060001@when.com> Hi all, the time has come... we've an education spin ready! Okay, it's just a preview, not yet an official spin and of course not bug-free - but I think it's still worth announcing it. Here are the announcements: [1] http://rdieter.livejournal.com/8549.html [2] http://sdziallas.joyeurs.com/blog/2008/07/fedora-edu-spin-preview-is-liv.html There are some things, one should know, which are also partly explained in the blog posts: Be prepared! The spin contains a KDE 4.1 preview and therefore uses the repos at kde-redhat. It also only focusses on mathematical apps - so don't expect *all* educational apps on it. But still, if you have any suggestions, questions or ideas, how to to improve, please don't hesitate to speak up. Having that said, here is the link to the download (currently i386 + torrent only): http://rdieter.fedorapeople.org/torrents/livecd-f9-edu-math-preview/ Thank you everybody, Sebastian Dziallas From jkeating at redhat.com Thu Jul 10 15:22:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jul 2008 11:22:59 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <48762790.8060001@when.com> References: <48762790.8060001@when.com> Message-ID: <1215703379.8454.19.camel@localhost.localdomain> On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: > The spin contains a KDE 4.1 preview and > therefore uses the repos at kde-redhat. BZZzzz! This makes it not Fedora, please to be removing trademarks or non Fedora packages. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 harald at redhat.com Thu Jul 10 15:40:02 2008 From: harald at redhat.com (Harald Hoyer) Date: Thu, 10 Jul 2008 17:40:02 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: <20080710160808.7ef6423a@brian.englab.brq.redhat.com> References: <20080710160808.7ef6423a@brian.englab.brq.redhat.com> Message-ID: Michal Schmidt wrote: > On Thu, 10 Jul 2008 13:40:26 +0200 > Harald Hoyer wrote: > >> Anyone interested in an audio SIG? >> >> We could create a jacklab like spin ( http://jacklab.org/ ) with >> jackd as the main audio daemon. > > Would the absence of a real-time kernel variant in Fedora be a problem > for such a spin? Fedora kernel only has voluntary preemption enabled. > All the audio-specialized distributions I've heard about ship with an > RT-patched kernel. > > Michal > Absence is no "problem" on a modern desktop (my desktop :-) ), though a real-time kernel would definitely improve the latency for slower systems. Maybe we could "maintain" a kernel-rt package or persuade our RHEL5 kernel team to provide a rt-kernel (with the benefit of more QA :) ). From rdieter at math.unl.edu Thu Jul 10 15:43:24 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 Jul 2008 10:43:24 -0500 Subject: Announcing the Fedora EDU Spin Preview References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: >> The spin contains a KDE 4.1 preview and >> therefore uses the repos at kde-redhat. > > BZZzzz! This makes it not Fedora, please to be removing trademarks or > non Fedora packages. bleh, I knew this was all too easy. :) OK, so is s/fedora-logos/generic-logos/ sufficient? Fwiw, these previews are only temporary until the final bits land (officially) in fedora (soonish ~3 weeks). -- Rex From jwboyer at gmail.com Thu Jul 10 15:45:27 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 10 Jul 2008 11:45:27 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <1215703379.8454.19.camel@localhost.localdomain> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> Message-ID: <1215704727.14579.3.camel@weaponx> On Thu, 2008-07-10 at 11:22 -0400, Jesse Keating wrote: > On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: > > The spin contains a KDE 4.1 preview and > > therefore uses the repos at kde-redhat. > > BZZzzz! This makes it not Fedora, please to be removing trademarks or > non Fedora packages. Yeah, shouldn't do that. I don't understand why you need to use the repos at kde-redhat anyway... Fedora rawhide already contains a preview of KDE 4.1 as I understand it. Also, you need to get Board/Spin SIG/Rel Eng approval to call a spin a Fedora spin. josh From caillon at redhat.com Thu Jul 10 15:49:44 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jul 2008 11:49:44 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <1215703379.8454.19.camel@localhost.localdomain> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> Message-ID: <48762F98.2080909@redhat.com> Jesse Keating wrote: > On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: >> The spin contains a KDE 4.1 preview and >> therefore uses the repos at kde-redhat. > > BZZzzz! This makes it not Fedora, please to be removing trademarks or > non Fedora packages. Also, you need to get approval from the Spin SIG and Board before you can call it a spin. https://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess From rdieter at math.unl.edu Thu Jul 10 15:51:40 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 Jul 2008 10:51:40 -0500 Subject: Announcing the Fedora EDU Spin Preview References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <1215704727.14579.3.camel@weaponx> Message-ID: Josh Boyer wrote: > On Thu, 2008-07-10 at 11:22 -0400, Jesse Keating wrote: >> On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: >> > The spin contains a KDE 4.1 preview and >> > therefore uses the repos at kde-redhat. >> >> BZZzzz! This makes it not Fedora, please to be removing trademarks or >> non Fedora packages. > > Yeah, shouldn't do that. > > I don't understand why you need to use the repos at kde-redhat anyway... > Fedora rawhide already contains a preview of KDE 4.1 as I understand it. The spin there is based on F-9 (atm anyway) -- Rex From skvidal at fedoraproject.org Thu Jul 10 15:49:54 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 10 Jul 2008 11:49:54 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> Message-ID: <1215704994.3020.0.camel@rosebud> On Thu, 2008-07-10 at 10:43 -0500, Rex Dieter wrote: > Jesse Keating wrote: > > > On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: > >> The spin contains a KDE 4.1 preview and > >> therefore uses the repos at kde-redhat. > > > > BZZzzz! This makes it not Fedora, please to be removing trademarks or > > non Fedora packages. > > bleh, I knew this was all too easy. :) > > OK, so is s/fedora-logos/generic-logos/ sufficient? > > Fwiw, these previews are only temporary until the final bits land > (officially) in fedora (soonish ~3 weeks). and don't call it fedora edu, i think. -sv From karsten at redhat.com Thu Jul 10 16:03:47 2008 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 10 Jul 2008 18:03:47 +0200 Subject: make clean got noisy. In-Reply-To: <1215697800.8454.3.camel@localhost.localdomain> References: <20080709210843.GA4817@redhat.com> <1215641602.3274.46.camel@localhost.localdomain> <20080710030156.GA10747@redhat.com> <1215697800.8454.3.camel@localhost.localdomain> Message-ID: <487632E3.2050909@redhat.com> Jesse Keating schrieb: > On Wed, 2008-07-09 at 23:01 -0400, Dave Jones wrote: >> yep. >> >> (23:01:33:davej at gelk:~)$ rpm --eval %dist >> .fc9 > > Hrm, I can't duplicate. Any chance I could get a shell on that system? > > It's easy to duplicate with p.e. cvs -d username at cvs.fedora.redhat.com:/cvs/extras co devel/vim cvs -d username at cvs.fedora.redhat.com:/cvs/extras co devel/common cd devel/vim make verrel I think I've written a mail about this over a month ago, pointing to a specific checkin that broke this. It's the change between revision 1.94 and 1.95 in Makefile.common Karsten From jwboyer at gmail.com Thu Jul 10 16:05:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 10 Jul 2008 12:05:30 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <1215704727.14579.3.camel@weaponx> Message-ID: <1215705930.14579.5.camel@weaponx> On Thu, 2008-07-10 at 10:51 -0500, Rex Dieter wrote: > Josh Boyer wrote: > > > On Thu, 2008-07-10 at 11:22 -0400, Jesse Keating wrote: > >> On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: > >> > The spin contains a KDE 4.1 preview and > >> > therefore uses the repos at kde-redhat. > >> > >> BZZzzz! This makes it not Fedora, please to be removing trademarks or > >> non Fedora packages. > > > > Yeah, shouldn't do that. > > > > I don't understand why you need to use the repos at kde-redhat anyway... > > Fedora rawhide already contains a preview of KDE 4.1 as I understand it. > > The spin there is based on F-9 (atm anyway) Right, which is another "problem". We _really_ want new Spins to be part of the release process, which means this should start at F10 if it wants to be an official spin. josh From rdieter at math.unl.edu Thu Jul 10 16:07:48 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 Jul 2008 11:07:48 -0500 Subject: Announcing the Fedora EDU Spin Preview References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: >> The spin contains a KDE 4.1 preview and >> therefore uses the repos at kde-redhat. > > BZZzzz! This makes it not Fedora, please to be removing trademarks or > non Fedora packages. Alrighy, I'll pull what's out there, until we can produce something that doesn't run awry of the rules. My bad, apologies. -- Rex From rdieter at math.unl.edu Thu Jul 10 16:08:43 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 10 Jul 2008 11:08:43 -0500 Subject: Announcing the Fedora EDU Spin Preview References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <1215704727.14579.3.camel@weaponx> <1215705930.14579.5.camel@weaponx> Message-ID: Josh Boyer wrote: >> The spin there is based on F-9 (atm anyway) > > Right, which is another "problem". We _really_ want new Spins to be > part of the release process, which means this should start at F10 if it > wants to be an official spin. That is/was the plan, this was to serve only as a preview for testing/feedback, nothing more. -- Rex From jspaleta at gmail.com Thu Jul 10 16:58:33 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jul 2008 08:58:33 -0800 Subject: Audio SIG - Jacklab spin In-Reply-To: References: <20080710160808.7ef6423a@brian.englab.brq.redhat.com> Message-ID: <604aa7910807100958m347d28eay564c8b4c0beb6ab4@mail.gmail.com> On Thu, Jul 10, 2008 at 7:40 AM, Harald Hoyer wrote: > Maybe we could "maintain" a kernel-rt package or persuade our RHEL5 kernel > team to provide a rt-kernel (with the benefit of more QA :) ). There is an extremely high bar to meet when it comes to kernels or kernel patches. There's been several round of discussion concerning kernel patches and alternative kernels. I think the precedent is deeply set in this area with regard to the insistence that new patchsets are upstreamed . You will absolutely fail to have a separate kernel package built as part of Fedora. You will most likely fail to get the current kernel package patched, unless you can demonstrate that the patches you want are making forward progress towards adoption in mainline and you have the manpower to help the current kernel maintainers to keep the patchset maintained in Fedora kernels until its mainlined. -jef From davidz at redhat.com Thu Jul 10 17:09:13 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 10 Jul 2008 13:09:13 -0400 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709230227.GH22331@nb.net.home> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709230227.GH22331@nb.net.home> Message-ID: <1215709753.18922.2.camel@x61.fubar.dk> On Thu, 2008-07-10 at 01:02 +0200, Karel Zak wrote: > On Wed, Jul 09, 2008 at 03:23:36PM -0400, Bill Nottingham wrote: > > We've carried both pam_console and HAL-based ACL support for a while > > now. It's time to cut the cord and remove pam_console, so we only > > have one way of setting device permissions to worry about. > > Right. I'd like to remove a support for Fedora/RHEL specific > 'pamconsole' mount option from mount(8). Comments? Should be fine with me - hasn't been used (except if users add it themselves) since FC5. David From jspaleta at gmail.com Thu Jul 10 17:16:57 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jul 2008 09:16:57 -0800 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <200807100124.22222.konrad@tylerc.org> References: <200807100124.22222.konrad@tylerc.org> Message-ID: <604aa7910807101016n472bbeffm3d6ab62ac3571fd8@mail.gmail.com> 2008/7/10 Konrad Meyer : > Please stop, the horse hasn't even begun to recover yet. I think you missed it, but I cast regenerate about 3 turns back, so the horse is as recovered as an un-dead horse freshly risen from the grave can be. -jef"if only the horse had been eat by a grue"spaleta From romal at gmx.de Thu Jul 10 18:31:49 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Thu, 10 Jul 2008 20:31:49 +0200 Subject: Packaging of Nagios In-Reply-To: <486D744C.60401@edcint.co.nz> References: <48642DDD.9000508@edcint.co.nz> <486BD617.9070201@gmx.de> <486D744C.60401@edcint.co.nz> Message-ID: <48765595.6010703@gmx.de> Hi, Nagios 3.0.3 is in Rawhide. cu romal Matthew Jurgens schrieb: > I can test these RPMs if I can get them from somewhere > > Robert M. Albrecht wrote: >> Hi, >> >> I have working packages for Nagios 3.0.3 and Nagios PlugIns 1.4.12. >> >> I nearly finished with pnp4nagios, check-multi and nagvis. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=452424 >> https://bugzilla.redhat.com/show_bug.cgi?id=453330 >> >> cu romal >> >> www.romal.de >> blog.romal.de >> > From jspaleta at gmail.com Thu Jul 10 20:27:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jul 2008 12:27:37 -0800 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <1215705930.14579.5.camel@weaponx> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <1215704727.14579.3.camel@weaponx> <1215705930.14579.5.camel@weaponx> Message-ID: <604aa7910807101327v61026635yf3c550dc5a9cfc90@mail.gmail.com> On Thu, Jul 10, 2008 at 8:05 AM, Josh Boyer wrote: > Right, which is another "problem". We _really_ want new Spins to be > part of the release process, which means this should start at F10 if it > wants to be an official spin. Just to be clear, there's no hard policy in place which would prevent spin creators to work against the current release and looking to get it into the kickstart pool and trademark approval.. is there? I can understand the need to get things built against the development tree as early in the pre-release process as possible if the goal is to have spins as part of the next release..with a hosting commitment for binaries that comes with that. The only significant problem here that I see is that they pushed ahead and used non-fedora binaries in what they published. Preview binaries are great, because it shows that these particular Spin developers are making their best effort to get this working and tested so when it comes time to approve things that conversation should go smoothly. This could just be a matter of..education...concerning how we expect people to go about doing this sort of pre-approval testing and reviewing The open question is, what is the best practices for spins in this pre-approval testing phase and how do we make sure people developing spins know about them. Obviously we need to make sure such spins make use of the generic logos. We don't want anyone out in the wild to get the idea that this is a baked concept. The generic logos are there specifically so we can do preview spins like this. The less obvious question is can we give people guidance as to what they should call these sorts of previews in the future. These sort of things are going to get created, with the intent of pushing tested versions through the approval process. -jef From poelstra at redhat.com Thu Jul 10 20:31:42 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 10 Jul 2008 13:31:42 -0700 Subject: new RPM version and Feature process In-Reply-To: <1215658489.3885.14.camel@localhost.localdomain> References: <4874FFAA.3030902@leemhuis.info> <48754ACD.60200@redhat.com> <1215658489.3885.14.camel@localhost.localdomain> Message-ID: <487671AE.6090901@redhat.com> Matthias Clasen said the following on 07/09/2008 07:54 PM Pacific Time: > On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote: > >> I'm all ears. What are your specific ideas for a more effective process >> so it is worth all the "trouble and effort"? >> >> We've spent a lot of time up until now trying to get to a useful >> process, including the public reviews of the process we have at the >> start of each release. More participation and concrete suggestions from >> people like you would be greatly appreciated :) >> > > Here are some comments on my recent experience with the feature process: > > I've just 'gotten back' a ton of feature pages with the comment 'please > complete section a, b, c...' - but there is no definition anywhere of > what each section is supposed to contain, so how can I know what > 'complete' means ? Fair enough. I believe in most cases requested information was for sections that were completely blank. Up until now I thought the section headings were self-explanatory--I believe you are the first to raise this point about needing definitions, which we can definitely address. I hope people will read them. > So, I have to fly blind and put something in each section in the hope > that it passes the next time. But it feels like there is a lot of > overlap between the (undefined) topics on the feature template: > If I've already filled out the 'detailed description', why am I asked to > provide more details in the 'summary' ? And if I've already listed a ton > of packages that need changes under 'scope', whats supposed to be put in > 'dependencies' ? etc... Good point. I can see where defining the sections would help for these. In terms of requesting more for the summary--that information gets listed on the overal summary page for all features so I thought it would be helpful to readers of the summary page if the summary for that particular features was more descriptive and talked in less technical terms. > > In general, I think this whole process might be more pleasant if it felt > less like writing a paper and getting it graded and more like a > collaborative process. E.g. if instead of 'please complete the user > experience section' I got some questions back like: 'I didn't quite > understand how to turn this on, will there be a menu item ?', 'does this > also require changes to package foo ?'. I agree that doesn't sound like fun and I apologize if that is how the reviews have come across. I confess that in most cases I don't have the full technical background or understanding of the feature (another reason why FESCo reviews them) to know whether information in one section of the form supplements another or appropriate technical issues that should be raised. In most cases I'm just trying to do a high level review to make sure the feature page is complete so that when FESCo reviews them it isn't a waste of their time as it was in the past when key sections of the form were blank and it had be discussed again at the next meeting. The feature policy does state this as a requriement, though I understand better now where you are coming from. The more positive collaborative process you are suggesting--which parties would that be between? Thanks for your feedback John From seg at haxxed.com Thu Jul 10 21:17:24 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 10 Jul 2008 16:17:24 -0500 Subject: new RPM version and Feature process (was: Re: Heads-up: brand new RPM version about to hit rawhide) In-Reply-To: <1215702390.8454.18.camel@localhost.localdomain> References: <4874FFAA.3030902@leemhuis.info> <1218b5bc0807091841w56f7d4fod18da6aac09cf581@mail.gmail.com> <1215702390.8454.18.camel@localhost.localdomain> Message-ID: <1218b5bc0807101417g510588acyf30473f8a39d2a3@mail.gmail.com> 2008/7/10 Jesse Keating : > On Wed, 2008-07-09 at 20:41 -0500, Callum Lerwick wrote: >> Am I wrong? > > Yes. As previously stated the feature pages are way more than just > marketing fluff. Features have very real schedule impact, just consider > this time around, RPM with a bunch of new features, and a new gcc coming > at some point soon. Usually we want to rebuild for both of those. > Without some high level coordination, how do we schedule so that we > rebuild once for all of the right reasons instead of multiple times > individually? Okay yes, I'm seeing the need for Release Engineering to keep tabs on invasive and risky changes. But I think we need to keep in mind that this and marketing are two similar but orthogonal problems, that happen to have a very similar solution. Thus we end up with two criteria: 1) The feature process is voluntary and optional. 2) Unless Release Engineering (not FESCo) deems a change is invasive enough to threaten the release schedule. Two problems, who's solution currently seems to be somewhat indistinctly mashed together in one process. Perhaps this should be clarified. From seg at haxxed.com Thu Jul 10 21:21:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 10 Jul 2008 16:21:53 -0500 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710141001.GA10449@srcf.ucam.org> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> <20080710130230.GA29114@nostromo.devel.redhat.com> <20080710141001.GA10449@srcf.ucam.org> Message-ID: <1218b5bc0807101421i64b39e79he5d00b87053ff24c@mail.gmail.com> On Thu, Jul 10, 2008 at 9:10 AM, Matthew Garrett wrote: > On Thu, Jul 10, 2008 at 09:02:30AM -0400, Bill Nottingham wrote: >> Maybe I'm unusual, but I rarely reboot my laptop cleanly. I'm not sure I'd >> want X weeks of logs to go away. >> >> Are there any sorts of mechanisms to do per-directory or per-file writeback >> caching, so that /var/log/ could be set to 'sync only every 15 minutes', >> or similar? > > Not that I can think of. Implementing it in rsyslog might be the easiest > option, though that would still leave apps that do their logging by > hand. Maybe we should just fix them all up to use syslog when possible. Maybe we should just get a full-blown laptop-mode working. The problem has already been solved. But we appear to not be using it. http://samwel.tk/laptop_mode/ From seg at haxxed.com Thu Jul 10 21:26:08 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 10 Jul 2008 16:26:08 -0500 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710102915.GB5017@srcf.ucam.org> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> Message-ID: <1218b5bc0807101426p32d8cbddh1bc631d178587d41@mail.gmail.com> On Thu, Jul 10, 2008 at 5:29 AM, Matthew Garrett wrote: > On Wed, Jul 09, 2008 at 06:32:16AM -0400, Colin Walters wrote: > >> Putting syslog on tmpfs by default and limiting the total size to something >> like 5MB would be something to evaluate for the default desktop. > > I looked into this, and we're not actually doing too badly - our syslogd > doesn't fsync() after every log entry. I'm broadly in favour of using > tmpfs, though. There's an argument that certain priorities probably want > to stay on disk, but otherwise we can simply sync the tmpfs to disk on > shutdown or reboot. Yeah that's just what we need, more VM pressure. My 1.25gb machine isn't swapping enough as it is. (Thanks to Firefox!) From dtimms at iinet.net.au Thu Jul 10 21:30:39 2008 From: dtimms at iinet.net.au (David Timms) Date: Fri, 11 Jul 2008 07:30:39 +1000 Subject: OLPC & package dependency growth - RFE! In-Reply-To: <1215660976.5041.1.camel@rosebud> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> <1215632145.13098.41.camel@aglarond.local> <1215635657.3055.0.camel@rosebud> <1215660976.5041.1.camel@rosebud> Message-ID: <48767F7F.4030902@iinet.net.au> seth vidal wrote: > as we discussed in jabber - I've changed: > ?http://skvidal.fedorapeople.org/misc/installed-size.py Cool, really fast and informative. 1. Could you add the sum total at the end ? ;) 2. candidate for split: 16026876 fedora-release-notes.noarch perhaps into raw html, and css/images ? 3. I mentioned to some list a while ago that Fedora install for default / minimal F9 got to about 650 out 950 packages before it actually installed the kernel. It was suggested that this could be due to needing to get tools to build initrd to be present before the kernel install could occur. The output of this tool with kernel as argument suggests only about 80 packages are needed to solve deps. Is this realistic ? 4. Actually could you add the package count as well ? 5. Is the list ordered ie are things further up the list items that are {in general} needed by things further down the list ? From jamatos at fc.up.pt Thu Jul 10 21:50:40 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Thu, 10 Jul 2008 22:50:40 +0100 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <604aa7910807101327v61026635yf3c550dc5a9cfc90@mail.gmail.com> References: <48762790.8060001@when.com> <1215705930.14579.5.camel@weaponx> <604aa7910807101327v61026635yf3c550dc5a9cfc90@mail.gmail.com> Message-ID: <200807102250.41107.jamatos@fc.up.pt> On Thursday 10 July 2008 21:27:37 Jeff Spaleta wrote: > Preview > binaries are great, because it shows that these particular Spin > developers are making their best effort to get this working and tested > so when it comes time to approve things that conversation should go > smoothly. The question is a sense more general than just spins, other than the kde packages from kde-redhat that I use I have previously used other repositories from packages intended to be previews of next version of Fedora but released to the current stable release. >From the top of my head I remember: - python 2.5 - texlive (to replace tetex) - emacs 22 (?) - kernel (Dave had his repository working for some time) I am sure that there were more, the funny part is that those repositories were not "official" - for any definition of official, although the maintainers were the Fedora maintainers of the respective packages. So the need of those repositories is understood but they are stealth as they fall out of the radar. I would have expected that by now we had some kind of mechanism to deal with such cases other than the non-official stance of every of those repositories. I am aware of the perils involved, the existence of another level of testing with the resulting lack of attention for rawhide, or even the inter- compatibility of said repositories (although this has never a concern in practice, any problem was quickly identified and fixed). So I would like to see a figure of separate projects that still fall under the umbrella of Fedora, that track experimental packages over the current stable version. The whole process should be run by FESCO on a basis to basis case. This would avoid the situation that we have now where we have hybrids (repositories) that are neither Fedora but they are created exclusively with the single purpose of testing packages for future inclusion in Fedora. Schizophrenic seems like a good description of the current behavior. ;-) -- Jos? Ab?lio From lmacken at redhat.com Thu Jul 10 22:41:42 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 10 Jul 2008 18:41:42 -0400 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <48762F98.2080909@redhat.com> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <48762F98.2080909@redhat.com> Message-ID: <20080710224142.GA477@x300> On Thu, Jul 10, 2008 at 11:49:44AM -0400, Christopher Aillon wrote: > Jesse Keating wrote: >> On Thu, 2008-07-10 at 17:15 +0200, Sebastian Dziallas wrote: >>> The spin contains a KDE 4.1 preview and therefore uses the repos at >>> kde-redhat. >> >> BZZzzz! This makes it not Fedora, please to be removing trademarks or >> non Fedora packages. > > > Also, you need to get approval from the Spin SIG and Board before you > can call it a spin. > > https://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess Sadly, this is more of a roadblock than a process at the moment, seeing as how it has been blocking on the creation of a fedora-spins mailing list for the past 3 months. Does someone with postfix/mailman knowledge want to help get this ball rolling ? luke From triad at df.lth.se Thu Jul 10 22:45:25 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 11 Jul 2008 00:45:25 +0200 (CEST) Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709192336.GC7537@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> Message-ID: On Wed, 9 Jul 2008, Bill Nottingham wrote: > libmtp (triad at df.lth.se) > /etc/security/console.perms.d/60-libmtp.perms > libnjb (triad at df.lth.se) > /etc/security/console.perms.d/60-libnjb.perms I *tried* fixing these in the past but didn't get very far with it. If any of you guys know exactly what needs to be done, please help. I sadly still don't get it... Linus From kanarip at kanarip.com Thu Jul 10 22:45:53 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 00:45:53 +0200 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <604aa7910807101327v61026635yf3c550dc5a9cfc90@mail.gmail.com> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <1215704727.14579.3.camel@weaponx> <1215705930.14579.5.camel@weaponx> <604aa7910807101327v61026635yf3c550dc5a9cfc90@mail.gmail.com> Message-ID: <48769121.6040004@kanarip.com> Jeff Spaleta wrote: > On Thu, Jul 10, 2008 at 8:05 AM, Josh Boyer wrote: >> Right, which is another "problem". We _really_ want new Spins to be >> part of the release process, which means this should start at F10 if it >> wants to be an official spin. > > Just to be clear, there's no hard policy in place which would prevent > spin creators to work against the current release and looking to get > it into the kickstart pool and trademark approval.. is there? > As far as I'm concerned, there is no hard policy against working against the current release. If this works well for technical review (kickstart pool) and trademark approval; the kickstart is going in the tree after technical approval to be able to continue development and'll go in the package after the board stamps it Fedora. This at least is how I see it. I asked Sebastian to send me the kickstart so I can take a glance at it, and he's already requested commit access to the repository. As soon as I see it fits in, he'll get the access and add the kickstart to the repository, from where we can create Feature pages for the spin. > I can understand the need to get things built against the development > tree as early in the pre-release process as possible if the goal is to > have spins as part of the next release..with a hosting commitment for > binaries that comes with that. > For sneak preview kinda-like things, we have the alpha and beta release (in public). Whatever else needs to be previewed can either be shared in private to (fedora?) people interested (with fedora-logos) or in public (with generic-logos). I don't see how this could work confusing for anyone since we all know including packages that are not in Fedora implies you cannot use the trademark, but it would be worthwhile to add it to the guidelines for composing a spin. In fact I'll propose to the spin sig to have the spin-kickstarts master branch use generic-logos (master branch is for development so basically anyone can do anything there). > (...snip...) > > -jef > Thanks for sharing your insights, I hadn't thought of generic-logos ;-) Kind regards, Jeroen van Meeuwen -kanarip From triad at df.lth.se Thu Jul 10 23:02:42 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 11 Jul 2008 01:02:42 +0200 (CEST) Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <20080709195303.GA11245@nostromo.devel.redhat.com> References: <20080709192336.GC7537@nostromo.devel.redhat.com> <20080709193234.GD1364182@hiwaay.net> <20080709195303.GA11245@nostromo.devel.redhat.com> Message-ID: On Wed, 9 Jul 2008, Bill Nottingham wrote: > See /usr/share/hal/fdi/policy/10osvendor/00-thinkfinger.fdi for an > example of something that does access control. I guess these two does the actual magic: linux.device_file thinkfinger But 20-acl-management already has: access_control audio-player @info.parent:linux.device_file and since libmtp and libnjb already has .fdi files that define them as portable_audio_player it would thus be as simple as to remove the pam console file altogether, since HAL already matches and fixes this. ..and it actually seems to work when I do that too, so problem solved I believe. Linus From kanarip at kanarip.com Thu Jul 10 23:16:35 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 01:16:35 +0200 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <20080710224142.GA477@x300> References: <48762790.8060001@when.com> <1215703379.8454.19.camel@localhost.localdomain> <48762F98.2080909@redhat.com> <20080710224142.GA477@x300> Message-ID: <48769853.1060600@kanarip.com> Luke Macken wrote: > On Thu, Jul 10, 2008 at 11:49:44AM -0400, Christopher Aillon wrote: >> Also, you need to get approval from the Spin SIG and Board before you >> can call it a spin. >> >> https://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess > > Sadly, this is more of a roadblock than a process at the moment, seeing > as how it has been blocking on the creation of a fedora-spins mailing > list for the past 3 months. Does someone with postfix/mailman knowledge > want to help get this ball rolling ? > I don't know what the problem is exactly... We have multiple mailing lists running in all kinds of locations... @redhat.com, @fedorahosted.org and @lists.fedoraproject.org... Not sure what's holding us back. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Thu Jul 10 23:37:45 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 10 Jul 2008 19:37:45 -0400 Subject: OLPC & package dependency growth - RFE! In-Reply-To: <48767F7F.4030902@iinet.net.au> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> <1215632145.13098.41.camel@aglarond.local> <1215635657.3055.0.camel@rosebud> <1215660976.5041.1.camel@rosebud> <48767F7F.4030902@iinet.net.au> Message-ID: <1215733065.13098.79.camel@aglarond.local> On Fri, 2008-07-11 at 07:30 +1000, David Timms wrote: > 2. candidate for split: > 16026876 fedora-release-notes.noarch > perhaps into raw html, and css/images ? What actually gets gained by splitting it? The majority of the size is actually the various forms of the release notes + translations > 3. I mentioned to some list a while ago that Fedora install for default > / minimal F9 got to about 650 out 950 packages before it actually > installed the kernel. It was suggested that this could be due to needing > to get tools to build initrd to be present before the kernel install > could occur. The output of this tool with kernel as argument suggests > only about 80 packages are needed to solve deps. Is this realistic ? That sounds plausible for just the kernel, but the ordering algorithm used is a bit more complex. See rpm/lib/depends.c:rpmtsOrder() if you want all of the grotty details. We don't do transaction splitting and if we're to do it, it needs to be done in a more general fashion rather than special-casing the kernel. Jeremy From bpepple at fedoraproject.org Thu Jul 10 23:51:47 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 10 Jul 2008 19:51:47 -0400 Subject: FESCo Meeting Summary for 2008-07-10 Message-ID: <1215733907.12099.4.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Josh Boyer (jwb) * Tom Callaway (spot) === Members Absent === * Christopher Aillon (caillon) * Christian Iseli (c4chris) * Jeremy Katz (jeremy) == Summary == === Secondary Arches === * FESCo asked to be contacted before a secondary arch is released, so that a brief sanity check can be made before any announcement. === Approvals for cvsadmin === * FESCo approved a proposal to allow the current admins of the cvsadmin group be the body that approves new members. === F10 Features === * FESCo approved the following Features for F10: ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport ** https://fedoraproject.org/wiki/Features/Fingerprint ** https://fedoraproject.org/wiki/Features/RPM4.6 === F10 Schedule === * FESCo approved the schedule for Fedora 10 presented by Release Engineering. ** http://poelstra.fedorapeople.org/schedules/f-10/f-10-all-tasks.html === Misc === * Spot mentioned that he will be purging any package under the Artistic 1.0 license only from Fedora before the Alpha. He will send out an e-mail to the list before this is done. * Fedora Packaging Committee (FPC) voted not to permit packages putting files under /srv. Spot will work with maintainers to resolve this before F10. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-10.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alexl at users.sourceforge.net Thu Jul 10 23:55:11 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 10 Jul 2008 16:55:11 -0700 Subject: kernel build failures. In-Reply-To: <1215618897.3934.6.camel@dhcp-lab-219.englab.brq.redhat.com> (=?utf-8?B?Ik9uZMWZZWogVmHFocOtayIncw==?= message of "Wed\, 09 Jul 2008 17\:54\:57 +0200") References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> <1215618897.3934.6.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <17d4llnvkw.fsf@allele2.eebweb.arizona.edu> >>>>> "OV" == Ond?ej Va??k writes: [...] >> Does this problem has been solved ? I have this package failing: >> (even if i add : %if 0%{?fedora} > 9 BuildRequires: docbook-dtds >> %endif ) http://koji.fedoraproject.org/koji/taskinfo?taskID=702885 >> >> /builddir/build/BUILD/lcdproc-0.5.2/docs/lcdproc-dev/lcdproc-dev.docbook:12: >> warning: failed to load external entity >> "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" OV> Sorry for troubles with xmlcatalog/docbook-dtds. Everything got OV> broken once I got bugzilla about rpm -V complaints about OV> sgml-common/xml-common catalog files. This caused broken OV> xmlcatalog file in existing installation - as the xmlcatalog was OV> modified and replaced full catalog of xml-dtd's with brand new OV> empty one. I decided to mark it config(noreplace) to prevent such OV> things in future. Because of policy no config(noreplace) in /usr/ OV> I moved xmlcatalog to /etc/sgml/docbook/ and created symlink. But OV> because entries from docbook-dtds were not with full path, they OV> were not found. New docbook-dtds with full paths to xml-dtd's OV> should solve the troubles. Sorry once more time... Hi, Is there an open bugzilla bug and/or timeframe on fixing this? Is the error in the docbook-dtds package? I couldn't find any relevant open bug in that component. I'm having difficulty in F-9 with resolving DTDs, it wants to download everything via the network. Alex From alexl at users.sourceforge.net Fri Jul 11 00:47:23 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 10 Jul 2008 17:47:23 -0700 Subject: kernel build failures. In-Reply-To: <17d4llnvkw.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's message of "Thu\, 10 Jul 2008 16\:55\:11 -0700") References: <20080706213654.GB14554@redhat.com> <20080707022537.GB9073@wolff.to> <62410.192.54.193.59.1215420496.squirrel@rousalka.dyndns.org> <1215618897.3934.6.camel@dhcp-lab-219.englab.brq.redhat.com> <17d4llnvkw.fsf@allele2.eebweb.arizona.edu> Message-ID: >>>>> "AL" == Alex Lancaster writes: >>>>> "OV" == Ond?ej Va??k writes: [...] OV> Sorry for troubles with xmlcatalog/docbook-dtds. Everything got OV> broken once I got bugzilla about rpm -V complaints about OV> sgml-common/xml-common catalog files. This caused broken OV> xmlcatalog file in existing installation - as the xmlcatalog was OV> modified and replaced full catalog of xml-dtd's with brand new OV> empty one. I decided to mark it config(noreplace) to prevent such OV> things in future. Because of policy no config(noreplace) in /usr/ OV> I moved xmlcatalog to /etc/sgml/docbook/ and created symlink. But OV> because entries from docbook-dtds were not with full path, they OV> were not found. New docbook-dtds with full paths to xml-dtd's OV> should solve the troubles. Sorry once more time... AL> Hi, AL> Is there an open bugzilla bug and/or timeframe on fixing this? Is AL> the error in the docbook-dtds package? I couldn't find any AL> relevant open bug in that component. It seems the original problem was only in rawhide and didn't affect F-9. I see docbook-dtds has been rebuilt for rawhide now: http://koji.fedoraproject.org/koji/buildinfo?buildID=55346 AL> I'm having difficulty in F-9 with resolving DTDs, it wants to AL> download everything via the network. In any case, I've filed my F-9 as a bug: https://bugzilla.redhat.com/show_bug.cgi?id=454952 Alex From jwilson at redhat.com Fri Jul 11 00:59:08 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jul 2008 20:59:08 -0400 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: <200807102059.08760.jwilson@redhat.com> On Thursday 10 July 2008 07:40:26 am Harald Hoyer wrote: > Anyone interested in an audio SIG? > > We could create a jacklab like spin ( http://jacklab.org/ ) with jackd as > the main audio daemon. Nb: there's a fedora-audio-list, where a few people are working on similar things, complete with trying to get ffado working (and then packaged) for firewire audio devices. I know jackd is one of the parts involved, so there's definitely some synergy there (Fernando of CCRMA is definitely over on that list, not sure if he's over here). -- Jarod Wilson jwilson at redhat.com From green at redhat.com Fri Jul 11 02:29:38 2008 From: green at redhat.com (Anthony Green) Date: Thu, 10 Jul 2008 19:29:38 -0700 Subject: Audio SIG - Jacklab spin In-Reply-To: <200807102059.08760.jwilson@redhat.com> References: <200807102059.08760.jwilson@redhat.com> Message-ID: <4876C592.1020102@redhat.com> Jarod Wilson wrote: > On Thursday 10 July 2008 07:40:26 am Harald Hoyer wrote: > >> Anyone interested in an audio SIG? >> >> We could create a jacklab like spin ( http://jacklab.org/ ) with jackd as >> the main audio daemon. >> > > Nb: there's a fedora-audio-list, Correction: fedora-music-list. http://www.redhat.com/mailman/listinfo/fedora-music-list AG > where a few people are working on similar > things, complete with trying to get ffado working (and then packaged) for > firewire audio devices. I know jackd is one of the parts involved, so there's > definitely some synergy there (Fernando of CCRMA is definitely over on that > list, not sure if he's over here). > > From poelstra at redhat.com Fri Jul 11 04:21:22 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 10 Jul 2008 21:21:22 -0700 Subject: FESCo Meeting Summary for 2008-07-10 In-Reply-To: <1215733907.12099.4.camel@kennedy> References: <1215733907.12099.4.camel@kennedy> Message-ID: <4876DFC2.6000302@redhat.com> Brian Pepple said the following on 07/10/2008 04:51 PM Pacific Time: > === Members Present === > * Brian Pepple (bpepple) > * Jason Tibbitts (tibbs) > * Bill Nottingham (notting) > * Kevin Fenzi (nirik) > * Dennis Gilmore (dgilmore) > * Warren Togami (warren) > * David Woodhouse (dwmw2) > * Jesse Keating (f13) > * Josh Boyer (jwb) > * Tom Callaway (spot) > > === Members Absent === > * Christopher Aillon (caillon) > * Christian Iseli (c4chris) > * Jeremy Katz (jeremy) > > == Summary == > === Secondary Arches === > * FESCo asked to be contacted before a secondary arch is released, so > that a brief sanity check can be made before any announcement. > > === Approvals for cvsadmin === > * FESCo approved a proposal to allow the current admins of the cvsadmin > group be the body that approves new members. > > === F10 Features === > * FESCo approved the following Features for F10: > ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport > ** https://fedoraproject.org/wiki/Features/Fingerprint > ** https://fedoraproject.org/wiki/Features/RPM4.6 > Can the minutes also state in the future a FULL record of the feature discussion including features that were NOT accepted? We wouldn't want the "rubber stamp contingent" to be working with bad information ;-) Today was a great example of what DID happen during the Fedora 9 feature cycle... good technical discussion surrounding the integration of different features. TWO features pages were deemed to be incomplete and in need of more information and as a result not accepted. John From poelstra at redhat.com Fri Jul 11 05:17:32 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 10 Jul 2008 22:17:32 -0700 Subject: Audio SIG - Jacklab spin In-Reply-To: <4875FA77.1090208@kanarip.com> References: <4875FA77.1090208@kanarip.com> Message-ID: <4876ECEC.2030002@redhat.com> Jeroen van Meeuwen said the following on 07/10/2008 05:03 AM Pacific Time: > Harald Hoyer wrote: >> Anyone interested in an audio SIG? >> >> We could create a jacklab like spin ( http://jacklab.org/ ) with jackd >> as the main audio daemon. >> > > Could you create a Feature page in Category ProposedFeatureF10, so we > can keep track of developments? > Unless it is really ready for FESCo acceptance, please put it in Category:ProposedFeature The purpose of this category is to collect ideas like this and not be tied to a particular release until they are ready. Thanks, John From kevin.kofler at chello.at Fri Jul 11 06:18:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 11 Jul 2008 06:18:14 +0000 (UTC) Subject: FESCo Meeting Summary for 2008-07-10 References: <1215733907.12099.4.camel@kennedy> Message-ID: Brian Pepple fedoraproject.org> writes: > ** https://fedoraproject.org/wiki/Features/Fingerprint >From the log: It's still going to block on libusb. Actually, there is already a libusb1 package in Rawhide. libusb 0.1 and 1.0 are fully parallel-installable, you might even get away with linking both into the same program (the functions have been renamed). There's a compat-libusb-0.1 provided with libusb 1.0 which implements the old API in terms of the new one, but the original libusb 0.1 can also be used. Kevin Kofler From j.w.r.degoede at hhs.nl Fri Jul 11 06:44:53 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jul 2008 08:44:53 +0200 Subject: Headsup new (soname changing) cegui on its way to rawhide Message-ID: <48770165.1060308@hhs.nl> Hi All, A new (soname changing) cegui is on its way to rawhide, according to repoquery the following packages depend upon this: [hans at localhost ~]$ repoquery -q --whatrequires --alldeps cegui chess-0:1.0-16.fc10.x86_64 TnL-0:071111-5.fc10.x86_64 crystalspace-0:1.2-6.fc10.i386 ogre-samples-0:1.4.9-1.fc10.x86_64 cegui-0:0.6.0-1.fc10.i386 cegui-devel-0:0.6.0-1.fc10.i386 cegui-devel-0:0.6.0-1.fc10.x86_64 crystalspace-demos-0:1.2-6.fc10.x86_64 crystalspace-0:1.2-6.fc10.x86_64 crystalspace-utils-0:1.2-6.fc10.x86_64 cegui-0:0.6.0-1.fc10.x86_64 These are all mine, so I'll take care of rebuilding them myself :) Regards, Hans From harald at redhat.com Fri Jul 11 08:17:49 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 11 Jul 2008 10:17:49 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: Harald Hoyer wrote: > Anyone interested in an audio SIG? > > We could create a jacklab like spin ( http://jacklab.org/ ) with jackd > as the main audio daemon. > Add yourself to https://fedoraproject.org/wiki/SIGs/Audio if you are interested From pmatilai at redhat.com Fri Jul 11 08:30:00 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 11 Jul 2008 11:30:00 +0300 (EEST) Subject: FESCo Meeting Summary for 2008-07-10 In-Reply-To: <1215733907.12099.4.camel@kennedy> References: <1215733907.12099.4.camel@kennedy> Message-ID: On Thu, 10 Jul 2008, Brian Pepple wrote: [...] > === F10 Features === > * FESCo approved the following Features for F10: [...] > ** https://fedoraproject.org/wiki/Features/RPM4.6 Wohoo :) Thank you FESCo for accepting it on such an extremely short notice! - Panu - From harald at redhat.com Fri Jul 11 08:40:24 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 11 Jul 2008 10:40:24 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: Message-ID: Harald Hoyer wrote: > Harald Hoyer wrote: >> Anyone interested in an audio SIG? >> >> We could create a jacklab like spin ( http://jacklab.org/ ) with jackd >> as the main audio daemon. >> > > Add yourself to > https://fedoraproject.org/wiki/SIGs/Audio > if you are interested > ok, there is already such a SIG called AudioCreation http://fedoraproject.org/wiki/SIGs/AudioCreation From rjones at redhat.com Fri Jul 11 08:48:13 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Jul 2008 09:48:13 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080710110502.GA10914@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <20080708193226.GA17810@amd.home.annexia.org> <20080710110502.GA10914@redhat.com> Message-ID: <20080711084813.GA31672@amd.home.annexia.org> On Thu, Jul 10, 2008 at 12:05:02PM +0100, Daniel P. Berrange wrote: > On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote: > > > > +%define __os_install_post /usr/lib/rpm/brp-compress %{nil} > > > > Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't > > work, but actually corrupts the files. Therefore we must disable > > stripping. I'd love to know how to force RPM to either ignore files > > in certain directories, or to call the correct strip binary on them. > > The original SRPMs that I was working with contained a very long and > > hairy bit of code which apparently did this, but I wasn't daring > > enough to include it. > > I think that %define will affect the main RPM, as well as mingw > sub-RPM, so we can't simply set it to %{nil}. Couple of options > that I see > > - Find out what's wrong with strip & fix it > - Modify the default brp-compress script to avoid mingw files > - Create a wrapper around default brp-compress script to filer > mingw files and %define __os_install_post to use that The original RPMs I'm working with do the latter. Very complicated but I'll see if it can be simplified somehow :-( > > +BuildRequires: mingw-gcc > > +BuildRequires: mingw-binutils > > +BuildRequires: mingw-libgpg-error > > +BuildRequires: mingw-libgcrypt > > + > > +Requires: mingw-runtime > > +Requires: mingw-libgpg-error > > +Requires: mingw-libgcrypt > > > > Main package definition. Note that we don't have any automatic > > find-requires working at the moment, so we need to define dependent > > packages explicitly. > > Doesn't the default ELF find-rquires already discover these ? I thought > it would look for all ELF files no matter where they were installed ? They're not ELF binaries, they are Windows binaries which are a perverted type of COFF. I can't see how one would discover requirements without specific Windows binutils being installed. Probably need to have custom find-requires/find-provides as we do with OCaml. > > I've split the build by configuring & building in two subdirectories, > > ie. the general pattern is: > > > > pushd build > > ../configure &c > > popd > > pushd i686-pc-mingw32 > > ../configure --host=i686-pc-mingw32 &c > > popd > > > > Note the hack to make %configure work in a subdirectory. Any easier way? > > While this works for GNUTLS I don't think we can assume that all libs > we want will support VPATH builds. IIRC the way the kernel deals with > this is to have a completely separate source tree per build target. > > We could do this by changing > > %setup > > to > > %setup -c > > So the sources end up in rpm/BUILD/gnutls-2.4.1/gnutls-2.4.1 OK, fair enough ... > Oh, we probably also want to have a %define with_mingw at the top of > the spec files to allow the mingw sub-RPM to be turned on/off easily. > This will speed up build times during regular package maintainer work. Yup. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rawhide at fedoraproject.org Fri Jul 11 09:21:28 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 11 Jul 2008 09:21:28 +0000 (UTC) Subject: rawhide report: 20080711 changes Message-ID: <20080711092128.6C093209D2C@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080710/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080711/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package R-biglm Bounded memory linear and generalized linear models Removed package libtomoe-gtk Removed package xfce4-dict-plugin Removed package xfce4-minicmd-plugin Updated Packages: apr-util-1.3.2-6.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 1.3.2-6 - rebuild for new db4-4.7 babl-0.0.22-1.fc10 ------------------ * Thu Jul 10 18:00:00 2008 Deji Akingunola - 0.0.22-1 - Update to latest release bluez-utils-3.35-3.fc10 ----------------------- * Wed Jul 9 18:00:00 2008 - Will Woods - 3.35-3 - Re-add hid2hci bogofilter-1.1.7-2.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 1.1.7-2 - rebuild against db4-4.7 - use make DESTDIR install - disable rpaths bzflag-2.0.12-3.fc10 -------------------- * Wed Jul 9 18:00:00 2008 Nils Philippsen 2.0.12-3 - build with SDL, but fix finding resolutions (#426011) cairo-dock-1.6.1-0.1.svn1188_trunk.fc10 --------------------------------------- cone-0.75-1.fc10 ---------------- * Thu Jul 10 18:00:00 2008 Steven Pritchard 0.75-1 - Update to 0.75. ctrlproxy-3.0.7-1.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Bernardo Innocenti 3.0.7-1 - Update to latest upstream drupal-6.3-1.fc10 ----------------- * Thu Jul 10 18:00:00 2008 Jon Ciesla - 6.3-1 - Upgrade to 6.3, upstream security fixes, SA-2008-044. dwdiff-1.4-1.fc10 ----------------- * Tue Jul 8 18:00:00 2008 Jakub Hrozek 1.4-1 - New upstream release, which BR: libicu-devel e2fsprogs-1.41.0-1.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Eric Sandeen 1.41-1 - New usptream release - ext4 capable emelfm2-0.4.1-1.fc10 -------------------- * Tue Jul 8 18:00:00 2008 Christoph Wickert - 0.4.1-1 - Update 0.4.1 - Revove hal_flags.patch (fixed upstream) - Remove HAL support until it really works. To enable rebuild "--with hal" enchant-1.4.2-3.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Marc Maurer 1:1.4.2-3 - Fix 426712: don't build static libs (patch from Michael Schwendt) evolution-data-server-2.23.4-2.fc10 ----------------------------------- * Thu Jul 3 18:00:00 2008 Matthew Barnes - 3.23.4-2.fc10 - Add patch for GNOME bug #534080 (fix attachment saving). foomatic-3.0.2-61.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Tim Waugh 3.0.2-61 - Updated db-hpijs to 20080710. - Updated db to 20080710. - Updated filters to 3.0-20080710. - Updated db-engine to 3.0-20080710. - Ship a defaultspooler file to avoid the need for spooler auto-detection (bug #454684). fwbackups-1.43.2-0.6.rc2.fc10 ----------------------------- * Thu Jul 10 18:00:00 2008 Stewart Adam 1.43.2-0.6.rc2 - Add patch to backend.py to fix errors with the rsync backend galeon-2.0.6-1.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Denis Leroy - 2.0.6-1 - Update to upstraem 2.0.6 - Reworked configure patch for libxul-embedding - Plugin patch update gdm-2.22.0-11.fc10 ------------------ * Thu Jul 10 18:00:00 2008 Matthias Clasen - 1:2.22.0-11 - Fix some broken icons on the login screen * Thu Jul 10 18:00:00 2008 Matthias Clasen - 1:2.22.0-10 - Improve rendering of languages gegl-0.0.18-1.fc10 ------------------ * Thu Jul 10 18:00:00 2008 Deji Akingunola - 0.0.18-1 - Update to latest release gnome-commander-1.2.7-0.1.svn1870_trunk.fc10 -------------------------------------------- * Fri Jul 11 18:00:00 2008 Mamoru Tasaka - try rev 1870 - ja.po is merged upstream gtk2-2.13.4-2.fc10 ------------------ * Thu Jul 10 18:00:00 2008 Matthias Clasen - 2.13.4-2 - Fix a segfault in the icon view a11y code gtkhtml3-3.23.4-2.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Matthew Barnes - 3.23.4-2.fc10 - Add patch for GNOME bug #538703 (load dictionaries on-demand). - Add patch for GNOME bug #539289 (stop using GtkType already!). halevt-0.1.2-1.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Patrice Dumas 0.1.2-1 - update to 0.1.2 hsqldb-1.8.0.10-1.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Jon Prindiville - 1:1.8.0.10-1 - Upgrade to 1.8.0.10 httpd-2.2.9-3 ------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 2.2.9-3 - rebuild against new db4 4.7 inn-2.4.5-2.fc10 ---------------- * Mon Jul 7 18:00:00 2008 Ondrej Vasik - 2.4.5-2 - do not use static libraries(changes by Jochen Schmitt,#453993) - own all dirs spawned by inn package(#448088) iproute-2.6.25-4.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 2.6.25-4 - rebuild for new db4-4.7 * Thu Jul 3 18:00:00 2008 Marcela Maslanova - 2.6.25-3 - 449933 fix segfault after non-existent combination of commands * Wed May 14 18:00:00 2008 Marcela Maslanova - 2.6.25-2 - allow replay setting, solve also 444724 jd-2.0.0-0.7.svn2188_trunk.fc10 ------------------------------- * Fri Jul 11 18:00:00 2008 Mamoru Tasaka - rev 2188 kdelibs-4.0.98-1.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 - omit proxy patch (for now, needswork) lcdproc-0.5.2-6.fc10 -------------------- * Tue Jul 8 18:00:00 2008 kwizart < kwizart at gmail.com > - 0.5.2-6 - Add BR on Fedora > 9 : docbook-dtds * Tue Jul 8 18:00:00 2008 kwizart < kwizart at gmail.com > - 0.5.2-5 - Fix RETVAL for LSB compliant initscripts - #246971 - Fix Default driver path - #454194 libgda-3.1.2-5.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 1:3.1.2-5 - Rebuild against new db4-4.7 libnjb-2.2.6-4.fc10 ------------------- * Fri Jul 11 18:00:00 2008 Linus Walleij 2.2.6-4 - Loose console permissions. See if docs build fine again. libtirpc-0.1.9-1.fc10 --------------------- * Wed Jul 9 18:00:00 2008 Steve Dickson 0.1.9-1 - Update to latest upstream version 0.1.9 link-grammar-4.3.5-2.fc10 ------------------------- * Thu Jul 10 18:00:00 2008 Marc Maurer 4.3.5-2 - Move the man-page from -devel to the main package * Thu Jul 10 18:00:00 2008 Marc Maurer 4.3.5-1 - New upstream version, fixes bug 434650 - Update URL - Package man-page nagios-3.0.3-6.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Robert M. Albrecht 3.0.3-6 - disabled conf.d in nagios.conf for now * Thu Jul 10 18:00:00 2008 Robert M. Albrecht 3.0.3-5 - Killed BuildRequirements for unsupported Fedora releases * Wed Jul 2 18:00:00 2008 Robert M. Albrecht 3.0.3-4 - renamed preconfigured passwd to .htpasswd to enable Apaches .ht* protection - added default .htpasswd with user nagiosadmin password nagiosadmin * Tue Jul 1 18:00:00 2008 Robert M. Albrecht 3.0.3-3 - Added Apache style conf.d - Added a working example config named internet.cfg - The object folder was created twice * Tue Jul 1 18:00:00 2008 Robert M. Albrecht 3.0.3-2 - Fixed folder /var/log/nagios/spool/checkresults - silenced rpmlint (tabs, spaces) - silenced rpmlint (configure missing libdir) * Sun Jun 29 18:00:00 2008 Robert M. Albrecht 3.0.3-1 - Upstream released 3.0.3 * Sun Jun 22 18:00:00 2008 Robert M. Albrecht 3.0.2-1 - Upstream released 3.0.2 nagios-plugins-1.4.12-3.fc10 ---------------------------- * Thu Jul 10 18:00:00 2008 Robert M. Albrecht 1.4.12-3 - Removed --with-extra-opts, does not build in Koji * Mon Jun 30 18:00:00 2008 Robert M. Albrecht 1.4.12-2 - Enabled --with-extra-opts * Sun Jun 29 18:00:00 2008 Robert M. Albrecht 1.4.12-1 - Upstream released version 1.4.12 - Removed patches ping_timeout.patch and pgsql-fix.patch nco-3.9.5-1.fc10 ---------------- * Thu Jul 10 18:00:00 2008 - Patrice Dumas - 3.9.5-1 - update to 3.9.5 ocaml-calendar-2.0.4-1.fc10 --------------------------- * Thu Jul 10 18:00:00 2008 Richard W.M. Jones - 2.0.4-1 - New upstream version 2.0.4 (rhbz #454789). - Fix non-UTF-8 characters in TODO. - *.cmx file moved to -devel subpackage as per packaging guidelines. ocaml-pgocaml-1.1-4.fc10 ------------------------ * Thu Jul 10 18:00:00 2008 Richard W.M. Jones - 1.1-4 - Rebuild against ocaml-calendar 2.0.4 pam_ccreds-7-3.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 7-3 - rebuild against db4-4.7 perl-5.10.0-36.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 4:5.10.0-36 - rebuild for new db4 4.7 perl-Array-Compare-1.16-1.fc10 ------------------------------ * Thu Jul 10 18:00:00 2008 Ralf Cors??pius - 1.16-1 - Upstream update. policycoreutils-2.0.52-5.fc10 ----------------------------- * Wed Jul 9 18:00:00 2008 Dan Walsh 2.0.52-5 - Additial cleanup of boolean handling for semanage pyicq-t-0.8-5.b.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Michael Fleming - 0.8-5.b - Fix typo in configuration python-2.5.1-27.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 2.5.1-27 - fix license tag - enable support for db4-4.7 redland-1.0.7-2.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 1.0.7-2 - rebuild for db4-4.7 referencer-1.1.3-1.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Deji Akingunola - 1.1.3-1 - Update to latest release regexp-1.5-2.2.fc10 ------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.5-2.2 - drop repotag relaxngDatatype-1.0-3.2.fc10 ---------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 1.0-3.2 - drop repotag revisor-2.1.1-6.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Jeroen van Meeuwen 2.1.1-6 - Latest rebuild - Minor bugfixes (#344 pkgorder traceback) - Add SELinux Check * Tue Jul 1 18:00:00 2008 Jeroen van Meeuwen 2.1.1-5 - Fix running GUI - Add check for architecture composing - Bugfixes in live media creation - Add bluray disc support - F-9 Release rhino-1.6-0.1.r5.1.3.fc10 ------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.6-0.1.r5.1.3 - drop repotag - fix license tag ruby-1.8.6.230-5.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 1.8.6.230-5 - rebuild against db4-4.7 sac-1.3-3.2.fc10 ---------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 1.3-3.2 - drop repotag sagator-1.1.1-0.beta1.fc10 -------------------------- * Sun Feb 17 17:00:00 2008 Jan ONDREJ (SAL) - 1.1.1-0.beta1 - added libclamav module - added pydspam module - selinux module moved to separate subpackage saxon-6.5.5-1.3.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:6.5.5-1.3 - drop repotag - fix license tag scim-tomoe-0.6.0-4.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Jens Petersen - 0.6.0-4.fc10 - libtomoe-gtk package was renamed to tomoe-gtk - rebuild also for gucharmap disabled now selinux-policy-3.4.2-14.fc10 ---------------------------- * Wed Jul 9 18:00:00 2008 Dan Walsh 3.4.2-14 - Add inotify support to nscd sendmail-8.14.2-5.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 8.14.2-5 - rebuild against db4-4.7 sound-juicer-2.23.0-2.fc10 -------------------------- * Thu Jul 10 18:00:00 2008 Matthias Clasen - 2.23.0-2 - There is need to BR hal anymore struts-1.2.9-5.11.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.2.9-5.11 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:1.2.9-5jpp.10 - fix license tag subversion-1.5.0-8 ------------------ * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 1.5.0-8 - rebuild against new db4-4.7 supertux-0.3.1-3.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Hans de Goede 0.3.1-3 - Fix building with gcc-4.3 (bz 434445) * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.3.1-2 - Autorebuild for GCC 4.3 system-config-printer-1.0.4-1.fc10 ---------------------------------- * Thu Jul 10 18:00:00 2008 Tim Waugh 1.0.4-1 - 1.0.4. - Applied upstream patch for pycups to fix getPrinterAttributes when requested_attributes is specified. tagsoup-1.0.1-2.2.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.0.1-2.2 - drop repotag - fix license tag tanukiwrapper-3.2.3-2.2.fc10 ---------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:3.2.3-2.2 - drop repotag tomcat5-5.5.26-1.4.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:5.5.26-1.4 - drop repotag * Fri May 23 18:00:00 2008 Todd Zullinger 0:5.5.26-1jpp.3 - fix license tag tomcat6-6.0.16-1.8.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:6.0.16-1.8 - drop repotag velocity-1.4-7.3.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.4-7.3 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:1.4-7jpp.2 - fix license tag werken-xpath-0.9.4-1.beta.12.3 ------------------------------ * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:0.9.4-1.beta.12.3 - drop repotag - fix license tag ws-jaxme-0.5.1-2.2.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:0.5.1-2.2 - drop repotag - fix license tag wsdl4j-1.5.2-5.4.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.5.2-5.4 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:1.5.2-5jpp.3 - fix license tag xalan-j2-2.7.0-7.3.fc10 ----------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:2.7.0-7.3 - drop repotag - fix license tag xdoclet-1.2.3-9.2.fc10 ---------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.2.3-9.2 - drop repotag - fix license tag xerces-j2-2.7.1-10.2.fc10 ------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:2.7.1-10.2 - drop repotag - fix license tag xfce4-verve-plugin-0.3.5-6.fc10 ------------------------------- * Thu Jul 10 18:00:00 2008 Christoph Wickert - 0.3.5-6 - Obsolte the xfce4-minicmd-plugin xjavadoc-1.1-5.5.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.1-5.5 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:1.1-5jpp.4 - fix license tag xml-commons-apis-1.3.04-1.2.fc10 -------------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.3.04-1.2 - drop repotag - fix license tag xml-commons-apis12-1.2.04-1.5.fc10 ---------------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.2.04-1.5 - drop repotag - fix license tag xml-commons-which-1.0-1.b2.0.3.fc10 ----------------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 1:1.0-1.b2.0.3 - drop repotag - fix license tag xmldb-api-0.1-0.2.20011111cvs.1.3.fc10 -------------------------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 1:0.1-0.2.20011111cvs.1.3 - drop repotag xmlrpc-2.0.1-4.5.fc10 --------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:2.0.1-4.5 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:2.0.1-4jpp.4 - fix license tag xmlrpc3-3.0-2.6.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway 3.0-2.6 - drop repotag - fix license tag xmlunit-1.0-6.2.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.0-6.2 - drop repotag xom-1.0-3.5.fc10 ---------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.0-3.5 - drop repotag - fix license tag xpp2-2.1.10-6.2.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:2.1.10-6.2 - drop repotag - fix license tag yum-3.2.17-2.fc10 ----------------- * Thu Jul 10 18:00:00 2008 Seth Vidal - 3.2.17-2 - add patch from upstream for bug in compare_providers Summary: Added Packages: 1 Removed Packages: 3 Modified Packages: 86 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.i386 requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.x86_64 requires libgnutls.so.13()(64bit) Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13(GNUTLS_1_3) xmlsec1-gnutls-1.2.9-10.1.ppc requires libgnutls.so.13 xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) xmlsec1-gnutls-1.2.9-10.1.ppc64 requires libgnutls.so.13()(64bit) From rc040203 at freenet.de Fri Jul 11 09:37:16 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Jul 2008 11:37:16 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080711084813.GA31672@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <20080708193226.GA17810@amd.home.annexia.org> <20080710110502.GA10914@redhat.com> <20080711084813.GA31672@amd.home.annexia.org> Message-ID: <1215769036.2809.612.camel@beck.corsepiu.local> On Fri, 2008-07-11 at 09:48 +0100, Richard W.M. Jones wrote: > On Thu, Jul 10, 2008 at 12:05:02PM +0100, Daniel P. Berrange wrote: > > On Tue, Jul 08, 2008 at 08:32:26PM +0100, Richard W.M. Jones wrote: > > > > > > +%define __os_install_post /usr/lib/rpm/brp-compress %{nil} > > > > > > Using ordinary /usr/bin/strip on MinGW lib*.a files not only doesn't > > > work, but actually corrupts the files. My hack to work around this issues (and others related to brp-* stuff) is this hack: ... %define _use_internal_dependency_generator 0 ... %build ... %install ... # Extract %%__os_install_post into os_install_post~ cat << \EOF > os_install_post~ %__os_install_post EOF # Generate customized brp-*scripts cat os_install_post~ | while read a x y; do case $a in # Prevent brp-strip* from trying to handle foreign binaries */brp-strip*) b=$(basename $a) sed -e 's,find $RPM_BUILD_ROOT,find $RPM_BUILD_ROOT%_bindir $RPM_BUILD_ROOT%_libexecdir,' $a > $b chmod a+x $b ;; # Fix up brp-compress to handle %%_prefix != /usr */brp-compress*) b=$(basename $a) sed -e 's,\./usr/,.%{_prefix}/,g' < $a > $b chmod a+x $b ;; esac done sed -e 's,^[ ]*/usr/lib/rpm.*/brp-strip,./brp-strip,' \ -e 's,^[ ]*/usr/lib/rpm.*/brp-compress,./brp-compress,' \ < os_install_post~ > os_install_post %define __os_install_post . ./os_install_post cat << EOF > %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides #!/bin/sh grep -E -v '^${RPM_BUILD_ROOT}%{_exec_prefix}/%tool_target/(lib|include|sys-root)' \ | grep -v '^${RPM_BUILD_ROOT}%{gcclib}/%tool_target/' | %__find_provides EOF chmod +x %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides %define __find_provides %{_builddir}/%{name}-%{gcc_rpmvers}/find-provides cat << EOF > %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires #!/bin/sh grep -E -v '^${RPM_BUILD_ROOT}%{_exec_prefix}/%tool_target/(lib|include|sys-root)' \ | grep -v '^${RPM_BUILD_ROOT}%{gcclib}/%tool_target/' | %__find_requires EOF chmod +x %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires %define __find_requires %{_builddir}/%{name}-%{gcc_rpmvers}/find-requires I know, this looks ugly (and it is), but guess you can get the idea: Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat files. Works quite well for me, even on non-Fedora-distros and non-RH-distros. Ralf From j.w.r.degoede at hhs.nl Fri Jul 11 09:47:18 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jul 2008 11:47:18 +0200 Subject: rpmbuild passes wrong --host option to configure Message-ID: <48772C26.6090808@hhs.nl> Hi all, I know bugzilla is my friend and I will put this in bugzilla, but I believe this needs many eyes, so hence I'm first discussing it here. Currently when building rpms on an i686 and using %configure in your specfile rpmbuild calls configure like this (non interesting stuff removed): ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu \ --target=i386-redhat-linux-gnu This is just plain wrong, this should be: ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu \ --target=i386-redhat-linux-gnu Or preferable just: ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu Here is a chapter of the autotools book describing the meaning of --build --target and --host: http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_259.html Normally one only needs to specify build and host: --build specifies the canonical name of the system on which the packages is build --host specifies the canonical name of the system on which the packages will run So clearly specifying a host of i686-pc-linux-gnu for .i386 rpms is wrong, as then some packages (ode for example) will unconditionally use i686 inline assembly, which of course won't work on an i386. At first I thought this was a bug in the upstream configure but it is not when --host says its an i686, unconditionally using i686 asm is fine, thus upstream is not to blame but our invocation of configure is to blame. For completeness sake, as said --target really should (normally) not be passed (it will then default to whatever --host is): --target specifies the canonical name of the system for which any code generated by the package when run should be generated So --target really only is relevant when building things like binutils and gcc and thus should not be specified by default. An example to hopefully make things clearer, lets say I'm building gcc on an i686 and I want to run the resulting gcc binaries on a powerpc using Fedora, and I want the gcc binaries to generate code for an arm, then I would specify: ./configure --build=i686-pc-linux-gnu --host=powerpc-redhat-linux-gnu \ --target=arm-redhat-linux-gnu (Yes that would be cross compiling a cross compiler). As said the correct invocation of ./configure on an i686 to build .i386 rpms would be: ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu There is one problem here though, now the --build and --host strings are not equal, so autoconf will assume we're cross-compiling which isn't really true. A solution for this would be to invoke configure like this: ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu Note this (with an unnecessary identical --target added) is currently what (luckily) happens in koji. But when doing a local test build using "make i386" configure gets invoked wrongly. Can we fix please this inconsistency between local rpmbuild's and koji? Thanks & Regards, Hans From rjones at redhat.com Fri Jul 11 09:41:17 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Jul 2008 10:41:17 +0100 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <1215769036.2809.612.camel@beck.corsepiu.local> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <20080708193226.GA17810@amd.home.annexia.org> <20080710110502.GA10914@redhat.com> <20080711084813.GA31672@amd.home.annexia.org> <1215769036.2809.612.camel@beck.corsepiu.local> Message-ID: <20080711094117.GA31872@amd.home.annexia.org> On Fri, Jul 11, 2008 at 11:37:16AM +0200, Ralf Corsepius wrote: > I know, this looks ugly (and it is), but guess you can get the idea: > Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat > files. Works quite well for me, even on non-Fedora-distros and > non-RH-distros. Yes, I was looking at this from your(?) original SRPMs. I'm going to look at if we can simplify this and/or centralize those scripts into one place. 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 rc040203 at freenet.de Fri Jul 11 09:57:20 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Jul 2008 11:57:20 +0200 Subject: rpmbuild passes wrong --host option to configure In-Reply-To: <48772C26.6090808@hhs.nl> References: <48772C26.6090808@hhs.nl> Message-ID: <1215770240.2809.624.camel@beck.corsepiu.local> On Fri, 2008-07-11 at 11:47 +0200, Hans de Goede wrote: > Hi all, > > I know bugzilla is my friend and I will put this in bugzilla, but I believe > this needs many eyes, so hence I'm first discussing it here. > > Currently when building rpms on an i686 and using %configure in your specfile > rpmbuild calls configure like this (non interesting stuff removed): > ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu \ > --target=i386-redhat-linux-gnu > > This is just plain wrong, this should be: > ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu \ > --target=i386-redhat-linux-gnu Both are wrong. Both use the wrong target The latter is worse: it trigger cross-compilation mode, because build != host. > Or preferable just: > ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu Preferable is ./configure, because then build and host will be autodetected. > Here is a chapter of the autotools book describing the meaning of --build > --target and --host: > http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_259.html > > > Normally one only needs to specify build and host: > --build specifies the canonical name of the system on which the packages is > build > --host specifies the canonical name of the system on which the packages will > run > > So clearly specifying a host of i686-pc-linux-gnu for .i386 rpms is wrong, Once more: no. The target-tuples actually specify the name of the canonicalized toolchain. I.e. configure scripts will pick up i686-pc-linux-gnu-gcc and set CC to it if --host=i686-pc-linux-gnu is given and if build != host. Whether this CC generates i386 or i686 is a matter of the CFLAGS being passed to the CC. However, I agree. Using i686-* as target tuple isn't necessarily a wise decision. > An example to hopefully make things clearer, lets say I'm building gcc on an > i686 and I want to run the resulting gcc binaries on a powerpc using Fedora, > and I want the gcc binaries to generate code for an arm, then I would specify: > ./configure --build=i686-pc-linux-gnu --host=powerpc-redhat-linux-gnu \ > --target=arm-redhat-linux-gnu > > (Yes that would be cross compiling a cross compiler). It would not be simple cross-compilation. Your example is a case of Canadian cross-compilation. It's one magnitude more difficult. > As said the correct invocation of ./configure on an i686 to build .i386 rpms > would be: > ./configure --build=i686-pc-linux-gnu --host=i386-redhat-linux-gnu No. > There is one problem here though, now the --build and --host strings are not > equal, so autoconf will assume we're cross-compiling which isn't really true. Correct. Your proposal triggers cross-compilation. > A solution for this would be to invoke configure like this: > ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu Correct. This would not trigger cross-compilation. Ralf From nphilipp at redhat.com Fri Jul 11 10:02:39 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Jul 2008 12:02:39 +0200 Subject: Easy reviews? In-Reply-To: <486CBA14.7060202@fedoraproject.org> References: <486CBA14.7060202@fedoraproject.org> Message-ID: <1215770559.3049.2.camel@gibraltar.str.redhat.com> On Thu, 2008-07-03 at 17:07 +0530, Rahul Sundaram wrote: > Hi, > > I am trying to gather a list of packages that are easy to review on the > long review queue since there are people interested in getting started > on this. Any pointers? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=454979 I'd also do a review in return ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rc040203 at freenet.de Fri Jul 11 10:10:07 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Jul 2008 12:10:07 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080711094117.GA31872@amd.home.annexia.org> References: <20080707094704.GA5497@amd.home.annexia.org> <20080707211554.GA8320@amd.home.annexia.org> <20080708133010.GR24934@redhat.com> <20080708144640.GA16785@amd.home.annexia.org> <20080708151356.GA13117@redhat.com> <20080708151342.GB16863@amd.home.annexia.org> <20080708193226.GA17810@amd.home.annexia.org> <20080710110502.GA10914@redhat.com> <20080711084813.GA31672@amd.home.annexia.org> <1215769036.2809.612.camel@beck.corsepiu.local> <20080711094117.GA31872@amd.home.annexia.org> Message-ID: <1215771007.2809.635.camel@beck.corsepiu.local> On Fri, 2008-07-11 at 10:41 +0100, Richard W.M. Jones wrote: > On Fri, Jul 11, 2008 at 11:37:16AM +0200, Ralf Corsepius wrote: > > I know, this looks ugly (and it is), but guess you can get the idea: > > Dynamically hackuping rpm's brp-* and find-* scripts to not mistreat > > files. Works quite well for me, even on non-Fedora-distros and > > non-RH-distros. > > Yes, I was looking at this from your(?) original SRPMs. My cross-toolchain rpms can be found inside of the src.rpms below ftp://www.rtems.org/pub/rtems/linux BTW: These specs are generated and therefore are not necessarily easily human readable. > I'm going to > look at if we can simplify this and/or centralize those scripts into > one place. My package are supposed to be add-on packages to distros (Fedora, CentOS, SuSE) and therefore support installation to outside of /usr (I use /opt/) Therefore, some of the ugliness can be removed when only considering installation to /usr (e.g. man-page compression (brp-compress). Apart of this aspect, I am not aware about much that could be removed. Ralf From valent.turkovic at gmail.com Fri Jul 11 12:00:55 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 11 Jul 2008 14:00:55 +0200 Subject: kernel bug - sound clicks Message-ID: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> Loud clicks from speakers (snd_intel_8x0): https://bugzilla.redhat.com/show_bug.cgi?id=450395 Can somebody please look at this? Cheers, Valent. -- 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 kanarip at kanarip.com Fri Jul 11 12:01:58 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 14:01:58 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: <4876ECEC.2030002@redhat.com> References: <4875FA77.1090208@kanarip.com> <4876ECEC.2030002@redhat.com> Message-ID: <48774BB6.7080103@kanarip.com> John Poelstra wrote: > Unless it is really ready for FESCo acceptance, please put it in > Category:ProposedFeature The purpose of this category is to collect > ideas like this and not be tied to a particular release until they are > ready. > Hmm, how or where does FESCo fit in the picture between proposal, Spin SIG, Board, Release Engineering and QA? Does the Spin also need to be approved by FESCo before inclusion to a release? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Fri Jul 11 12:15:27 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 08:15:27 -0400 Subject: Audio SIG - Jacklab spin In-Reply-To: <48774BB6.7080103@kanarip.com> References: <4875FA77.1090208@kanarip.com> <4876ECEC.2030002@redhat.com> <48774BB6.7080103@kanarip.com> Message-ID: <1215778527.3224.9.camel@localhost.localdomain> On Fri, 2008-07-11 at 14:01 +0200, Jeroen van Meeuwen wrote: > > Hmm, how or where does FESCo fit in the picture between proposal, Spin > SIG, Board, Release Engineering and QA? > > Does the Spin also need to be approved by FESCo before inclusion to a > release? I thought we had come to the conclusion that each spin was a feature and thus would go through the normal feature process, which means getting approval from FESCo as a feature. Having the spin already approved by the SIG/Releng/Board means that FESCo can avoid pondering the spin itself and concentrate more on the other parts of the feature process. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jwboyer at gmail.com Fri Jul 11 12:22:28 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 11 Jul 2008 08:22:28 -0400 Subject: kernel bug - sound clicks In-Reply-To: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> Message-ID: <1215778948.14579.7.camel@weaponx> On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: > Loud clicks from speakers (snd_intel_8x0): > https://bugzilla.redhat.com/show_bug.cgi?id=450395 > > Can somebody please look at this? There are currently 363 kernel bugs open for F9. 271 of those were submitted before yours. josh From valent.turkovic at gmail.com Fri Jul 11 12:29:27 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 11 Jul 2008 14:29:27 +0200 Subject: kernel bug - sound clicks In-Reply-To: <1215778948.14579.7.camel@weaponx> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> <1215778948.14579.7.camel@weaponx> Message-ID: <64b14b300807110529g69418982kb5842ed6a9b9ff63@mail.gmail.com> On Fri, Jul 11, 2008 at 2:22 PM, Josh Boyer wrote: > On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: >> Loud clicks from speakers (snd_intel_8x0): >> https://bugzilla.redhat.com/show_bug.cgi?id=450395 >> >> Can somebody please look at this? > > There are currently 363 kernel bugs open for F9. 271 of those were > submitted before yours. > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Ok, thank you for your reply. Valent. -- 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 kanarip at kanarip.com Fri Jul 11 12:49:10 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 14:49:10 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: <1215778527.3224.9.camel@localhost.localdomain> References: <4875FA77.1090208@kanarip.com> <4876ECEC.2030002@redhat.com> <48774BB6.7080103@kanarip.com> <1215778527.3224.9.camel@localhost.localdomain> Message-ID: <487756C6.3010706@kanarip.com> Jesse Keating wrote: > On Fri, 2008-07-11 at 14:01 +0200, Jeroen van Meeuwen wrote: >> Hmm, how or where does FESCo fit in the picture between proposal, Spin >> SIG, Board, Release Engineering and QA? >> >> Does the Spin also need to be approved by FESCo before inclusion to a >> release? > > I thought we had come to the conclusion that each spin was a feature and > thus would go through the normal feature process, which means getting > approval from FESCo as a feature. Having the spin already approved by > the SIG/Releng/Board means that FESCo can avoid pondering the spin > itself and concentrate more on the other parts of the feature process. > Right, that's what I wanted to verify ... ;-) Kind regards, Jeroen van Meeuwen -kanarip From dledford at redhat.com Fri Jul 11 14:18:25 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 10:18:25 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: Message-ID: <1215785905.4327.133.camel@firewall.xsintricity.com> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > At long last, we are about to get a brand new RPM version (alpha snapshot > at the moment) into rawhide. The list of changes from 4.4.2.x is massive > and a full summary needs a separate posting (will follow as time permits), > this is just a heads-up of immediate consequences for Fedora packagers and > rawhide consumers: [ snip ] This is great and all, but my first reaction was "Oh hell...what a colossal waste of time" referring to the fact that I've spent the last week or so pouring over rpm source code trying to see exactly what's needed to implement some things. So, that being said, if we are going to make this change in Fedora, especially one that involves all this "backup for rpmdb, rebuild your rpmdb, feed your rpmdb cake" stuff, can we make it a flag day and add a few new fields to the rpmdb schema and bump the rpmdb version? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 loupgaroublond at gmail.com Fri Jul 11 14:31:00 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 11 Jul 2008 16:31:00 +0200 Subject: Proposed SIG: Windows MinGW cross-compiler SIG In-Reply-To: <20080708162921.GE13117@redhat.com> References: <20080707094704.GA5497@amd.home.annexia.org> <4872904A.9050600@redhat.com> <20080707224321.GA8543@amd.home.annexia.org> <1215497272.2809.209.camel@beck.corsepiu.local> <20080708071644.GA15324@amd.home.annexia.org> <20080708162921.GE13117@redhat.com> Message-ID: <7f692fec0807110731j72698d8eo578d6cf8245143d8@mail.gmail.com> On Tue, Jul 8, 2008 at 6:29 PM, Daniel P. Berrange wrote: > If we only provided GPL'd libraries for libvirt on Windows they simply > won't use libvirt or Fedora virtualization, pushing more people towards > closed source virt solutuons like VMWare Actually, if you read the rationals for the LGPL vs. GPL, it's stated that the GPL is better in a situation where ther are no alternatives at all. It forces an otherwise new market to stick to being as Open as possible. Whereas in situations where there are already closed source solutions, the LGPL is an alternative since it is more flexible. While this isn't optimal, it's clearly a better license in this situation. +1 -Yaakov From skvidal at fedoraproject.org Fri Jul 11 14:32:56 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 11 Jul 2008 10:32:56 -0400 Subject: OLPC & package dependency growth - RFE! In-Reply-To: <48767F7F.4030902@iinet.net.au> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> <1215615476.3233.12.camel@localhost.localdomain> <200807091005.19175.dennis@ausil.us> <20080709151049.GA14415@redhat.com> <1215618263.14926.100.camel@rosebud> <1215631135.3327.1.camel@rosebud> <1215632145.13098.41.camel@aglarond.local> <1215635657.3055.0.camel@rosebud> <1215660976.5041.1.camel@rosebud> <48767F7F.4030902@iinet.net.au> Message-ID: <1215786776.3020.33.camel@rosebud> On Fri, 2008-07-11 at 07:30 +1000, David Timms wrote: > seth vidal wrote: > > as we discussed in jabber - I've changed: > > ?http://skvidal.fedorapeople.org/misc/installed-size.py > Cool, really fast and informative. > > 1. Could you add the sum total at the end ? ;) This is why I modified it to output size\tname.arch so you can use sort/uniq/etc to do whatever changes you want. You can even do fun things like import them into a spreadsheet and produce graphs or something equally ridiculous. :) > 4. Actually could you add the package count as well ? wc -l > 5. Is the list ordered ie are things further up the list items that are > {in general} needed by things further down the list ? sort -k1 -n If we have a firmer idea of the specific stats we're looking for it would make it easier, I think. -sv From kanarip at kanarip.com Fri Jul 11 14:40:01 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 16:40:01 +0200 Subject: Attention Spin Maintainers Message-ID: <487770C1.5020407@kanarip.com> Spin Maintainers, may I please have your attention. To be included in the Fedora 10 release cycle, you'll need a Feature page in category ProposedFeature (and change that to the ProposedFeatureF10 category when you feel the Spin Concept is ready for actual inclusion). This page should be ready (eg. prepared) before the Alpha freeze. The Feature Page for that spin should have a short description of the spin concept, it's target audience, any notes you want to write down on why it is you do foo or bar. It should also contain a link to the kickstart, but since a mailing list is still pending, I suggest you email it to fedora-livecd-list at redhat.com. The Spin SIG picks it up, does a technical review, and sends you the OK or comments. If the Spin SIG approves, your kickstart will be added to the GIT repository for the appropriate branch(es). At this point, it'll be forced to use "generic-logos", still. The Spin SIG will work with you to fit in the kickstart into the pool, get some things right or more right, and while you -by then at least-, should also have commit "access to the GIT repository"[1], the spin concept will continue it's path to the Board for trademark approval. Make sure that before this happens, you have some kind of strong argument in favor of the spin so they just can't say no. It makes all our lives easier ;-) Once you're kickstart (spin concept) has the almighty Board trademark approval stamp, we change "generic-logos" back to "fedora-logos". The kickstart should be built upon fedora-live-base.ks in the spin-kickstarts repository at: http://git.fedorahosted.org/git/?p=spin-kickstarts.git This GIT repository has several branches: master, and a very distinctive branch for each live release of Fedora out there. Naturally, the master branch is where development goes against rawhide, and the release specific branches is where you have a chance to maintain your spin concept for the duration of the lifecycle of that release. Basing on fedora-live-base.ks may be deferred from such as with the Electronic Lab DVD spin: it bases itself on the KDE CD spin so that minimal overhead in duplicate configuration and scripts is accomplished. You may do the same; as long as you make sure you tell us in your Feature page or technical review request. And if you don't tell us in your Feature page, I'll read it from the kickstart anyway. For now, you are requested to start filling out your spin's Feature page, get them to the Spin SIG (members are on [2]), request access to the gitspin-kickstarts group[1] in FAS, and start composing every two weeks or so, to verify rawhide hasn't changed too much. To watch commits to the spin-kickstarts GIT repository, subscribe to the spin-kickstarts-commits list[3] I'd love to see you all come back to me in the next week or so ;-) Thanks in advance, Kind regards, Jeroen van Meeuwen -kanarip [1] https://admin.fedoraproject.org/accounts/group/view/gitspin-kickstarts [2] http://fedoraproject.org/wiki/SIGs/Spins (members, guidelines, DOs and DONTs) [3] https://fedorahosted.org/mailman/listinfo/spin-kickstarts-commits From loupgaroublond at gmail.com Fri Jul 11 14:50:44 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 11 Jul 2008 16:50:44 +0200 Subject: FESCo Meeting Summary for 2008-07-10 In-Reply-To: <1215733907.12099.4.camel@kennedy> References: <1215733907.12099.4.camel@kennedy> Message-ID: <7f692fec0807110750w697daa5em8fca0a7a7220dc3@mail.gmail.com> 2008/7/11 Brian Pepple : > === F10 Features === > * FESCo approved the following Features for F10: > ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport The logs show questions about whether this is a feature or not. Being able to support a programming language and environment is definitely a feature. Being able to claim that we have the most up to date Python or Perl, compared to say Debian Stable is definitely a feature we gain. In this case, we've supported Haskell for a while, and the people involved have done a great job. The "Feature" is to provide much better library support so that we have a real platform for it. Once the guidelines are accepted, we can start including a wide variety of libraries. -Yaakov From pjones at redhat.com Fri Jul 11 15:06:32 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 11:06:32 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872789D.80006@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> Message-ID: <487776F8.3080405@redhat.com> jeff wrote: > Mr. Cox, do you see and *technical* problems with the selinux=0 passed > to anaconda passed to grub.conf proposal? If you pass selinux=0 to anaconda, you don't get selinux. It's been that way since 13-Apr-2004. Did we break it? It doesn't appear to have been broken intentionally, but I don't try it regularly either, since it's pretty much lunacy. -- Peter From rdieter at math.unl.edu Fri Jul 11 15:13:28 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 11 Jul 2008 10:13:28 -0500 Subject: Attention Spin Maintainers References: <487770C1.5020407@kanarip.com> Message-ID: Jeroen van Meeuwen wrote: > Spin Maintainers, may I please have your attention. > > To be included in the Fedora 10 release cycle, you'll need a Feature > page in category ProposedFeature (and change that to the > ProposedFeatureF10 category when you feel the Spin Concept is ready for > actual inclusion). This page should be ready (eg. prepared) before the > Alpha freeze. All or just new spins (ie, where to Desktop, KDE, and other existing ones fall)? -- Rex From chasd at silveroaks.com Fri Jul 11 15:24:50 2008 From: chasd at silveroaks.com (chasd) Date: Fri, 11 Jul 2008 10:24:50 -0500 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <20080710224154.0B86A6194AA@hormel.redhat.com> References: <20080710224154.0B86A6194AA@hormel.redhat.com> Message-ID: <3FF2F284-9DD6-4AA9-AF56-D124B5A3A404@silveroaks.com> Jos? Ab?lio wrote: > So I would like to see a figure of separate projects that still > fall under the > umbrella of Fedora, that track experimental packages over the > current stable > version. Fedora Labs ? Similar to Google Labs, Adobe Labs I suppose. The question is, what could be more raw than RawHide ? And what will it eat, because kittens and babies are reserved for RawHide. Charles Dostale From mclasen at redhat.com Fri Jul 11 15:30:29 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 11 Jul 2008 11:30:29 -0400 Subject: new RPM version and Feature process In-Reply-To: <487671AE.6090901@redhat.com> References: <4874FFAA.3030902@leemhuis.info> <48754ACD.60200@redhat.com> <1215658489.3885.14.camel@localhost.localdomain> <487671AE.6090901@redhat.com> Message-ID: <1215790229.4152.8.camel@localhost.localdomain> On Thu, 2008-07-10 at 13:31 -0700, John Poelstra wrote: > Fair enough. I believe in most cases requested information was for > sections that were completely blank. Up until now I thought the section > headings were self-explanatory--I believe you are the first to raise > this point about needing definitions, which we can definitely address. > I hope people will read them. Thanks, I believe it really will help. Also keep in mind that not everybody who writes a feature page is a native speaker, so what is self-explanatory and obvious to you may look different when you come from another culture... > > > So, I have to fly blind and put something in each section in the hope > > that it passes the next time. But it feels like there is a lot of > > overlap between the (undefined) topics on the feature template: > > If I've already filled out the 'detailed description', why am I asked to > > provide more details in the 'summary' ? And if I've already listed a ton > > of packages that need changes under 'scope', whats supposed to be put in > > 'dependencies' ? etc... > > Good point. I can see where defining the sections would help for these. > In terms of requesting more for the summary--that information gets > listed on the overal summary page for all features so I thought it would > be helpful to readers of the summary page if the summary for that > particular features was more descriptive and talked in less technical > terms. See, there you already have a great start for a one-paragraph explanation of what the summary is all about... > The more positive collaborative process you are suggesting--which > parties would that be between? >From the parties who would benefit from having the relevant sections fille out, I guess. E.g. I would expect some pointed questions from QA for better test cases, and questions from the docs guys about release notes. Of course, that is much easier later on, when the stuff is already in rawhide and the 'other parties' can just play around with it... From sundaram at fedoraproject.org Fri Jul 11 15:39:19 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 Jul 2008 21:09:19 +0530 Subject: Announcing the Fedora EDU Spin Preview In-Reply-To: <3FF2F284-9DD6-4AA9-AF56-D124B5A3A404@silveroaks.com> References: <20080710224154.0B86A6194AA@hormel.redhat.com> <3FF2F284-9DD6-4AA9-AF56-D124B5A3A404@silveroaks.com> Message-ID: <48777EA7.9000901@fedoraproject.org> chasd wrote: > > > Fedora Labs ? > Similar to Google Labs, Adobe Labs I suppose. > > The question is, what could be more raw than RawHide ? > > > And what will it eat, because kittens and babies are reserved for RawHide. Rawhide has in a way a high bar. You aren't supposed to put software in the branch unless you think it will be ready for the next general release. You are in that way limited for many experimental stuff. Alternative kernels, heavily patched upstream software, short term branches etc. Rahul From pmatilai at redhat.com Fri Jul 11 15:43:55 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 11 Jul 2008 18:43:55 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215785905.4327.133.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> Message-ID: On Fri, 11 Jul 2008, Doug Ledford wrote: > On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: >> At long last, we are about to get a brand new RPM version (alpha snapshot >> at the moment) into rawhide. The list of changes from 4.4.2.x is massive >> and a full summary needs a separate posting (will follow as time permits), >> this is just a heads-up of immediate consequences for Fedora packagers and >> rawhide consumers: > > [ snip ] > > This is great and all, but my first reaction was "Oh hell...what a > colossal waste of time" referring to the fact that I've spent the last > week or so pouring over rpm source code trying to see exactly what's > needed to implement some things. You could've just asked :) > So, that being said, if we are going to make this change in Fedora, > especially one that involves all this "backup for rpmdb, rebuild your > rpmdb, feed your rpmdb cake" stuff, can we make it a flag day and add a > few new fields to the rpmdb schema and bump the rpmdb version? What schema? :) The rpmdb isn't exactly like your average SQL database... What exactly do you want there? This is already a flag day of sorts, it's by far the biggest update to rpm in several years. We don't need any more excitement right now, we want to get a new non-4.4.x rpm in an settled. Then we can start looking at new stuff again... - Panu - From dledford at redhat.com Fri Jul 11 16:03:40 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 12:03:40 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> Message-ID: <1215792220.3687.9.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 18:43 +0300, Panu Matilainen wrote: > On Fri, 11 Jul 2008, Doug Ledford wrote: > > > On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: > >> At long last, we are about to get a brand new RPM version (alpha snapshot > >> at the moment) into rawhide. The list of changes from 4.4.2.x is massive > >> and a full summary needs a separate posting (will follow as time permits), > >> this is just a heads-up of immediate consequences for Fedora packagers and > >> rawhide consumers: > > > > [ snip ] > > > > This is great and all, but my first reaction was "Oh hell...what a > > colossal waste of time" referring to the fact that I've spent the last > > week or so pouring over rpm source code trying to see exactly what's > > needed to implement some things. > > You could've just asked :) Yeah, I know, I just didn't know a big update like this was in the works. > > So, that being said, if we are going to make this change in Fedora, > > especially one that involves all this "backup for rpmdb, rebuild your > > rpmdb, feed your rpmdb cake" stuff, can we make it a flag day and add a > > few new fields to the rpmdb schema and bump the rpmdb version? > > What schema? :) The rpmdb isn't exactly like your average SQL database... > What exactly do you want there? Something like: SCMType: {cvs|svn|git|hg|etc.} SCMRepo: SCMModule: SCMTag: SCMBranch: > This is already a flag day of sorts, it's by far the biggest update to rpm > in several years. We don't need any more excitement right now, we want to > get a new non-4.4.x rpm in an settled. Then we can start looking at new > stuff again... Does "then looking at new stuff again" imply F10? Or are you saying essentially table it until later? And IMO it's always best to have only a single flag day if possible. The additional rpmdb headers above (and subsequent new spec file tags to go along with them) are a flag day event. Doing one flag day instead of two would be preferable IMO. Anyway, the above fields are the essential elements necessary in order to be able to support exploded source repos and usage of exploded source repos as canonical source versions of binary packages. There's lots more you *could* do in rpm to make that support more integrated and nicer, but the rpmdb fields and spec fields are the absolute minimum. And, at least once those are in place, any additional support items can be added to rpm later at our convenience since everything beyond just the headers can be managed via scripts, macros, makefiles, build system changes, etc. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jwboyer at gmail.com Fri Jul 11 16:13:48 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 11 Jul 2008 12:13:48 -0400 Subject: FESCo Meeting Summary for 2008-07-10 In-Reply-To: <7f692fec0807110750w697daa5em8fca0a7a7220dc3@mail.gmail.com> References: <1215733907.12099.4.camel@kennedy> <7f692fec0807110750w697daa5em8fca0a7a7220dc3@mail.gmail.com> Message-ID: <1215792828.14579.17.camel@weaponx> On Fri, 2008-07-11 at 16:50 +0200, Yaakov Nemoy wrote: > 2008/7/11 Brian Pepple : > > > === F10 Features === > > * FESCo approved the following Features for F10: > > ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport > > > The logs show questions about whether this is a feature or not. Being > able to support a programming language and environment is definitely a > feature. Which is why we approved it. There was nothing that conclusively showed it _wasn't_ a Feature. For things like "Good Haskell Support", or "Better Bluetooth Support", or "The Best-est Erlang Support in the Universe!" (ok, I made that up) we at times question if there is really enough to promote it as a Feature. They are somewhat generic and nebulous by nature, so it's natural to question how visible that Feature can be and therefore if it's really a Feature. Inevitably though, we come back and approve it because there really isn't reason not to, and the publicity it generates is a good thing. josh From pmatilai at redhat.com Fri Jul 11 16:22:43 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 11 Jul 2008 19:22:43 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215792220.3687.9.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> Message-ID: On Fri, 11 Jul 2008, Doug Ledford wrote: > On Fri, 2008-07-11 at 18:43 +0300, Panu Matilainen wrote: >> On Fri, 11 Jul 2008, Doug Ledford wrote: >> >>> On Wed, 2008-07-09 at 13:51 +0300, Panu Matilainen wrote: >>>> At long last, we are about to get a brand new RPM version (alpha snapshot >>>> at the moment) into rawhide. The list of changes from 4.4.2.x is massive >>>> and a full summary needs a separate posting (will follow as time permits), >>>> this is just a heads-up of immediate consequences for Fedora packagers and >>>> rawhide consumers: >>> >>> [ snip ] >>> >>> This is great and all, but my first reaction was "Oh hell...what a >>> colossal waste of time" referring to the fact that I've spent the last >>> week or so pouring over rpm source code trying to see exactly what's >>> needed to implement some things. >> >> You could've just asked :) > > Yeah, I know, I just didn't know a big update like this was in the > works. > >>> So, that being said, if we are going to make this change in Fedora, >>> especially one that involves all this "backup for rpmdb, rebuild your >>> rpmdb, feed your rpmdb cake" stuff, can we make it a flag day and add a >>> few new fields to the rpmdb schema and bump the rpmdb version? >> >> What schema? :) The rpmdb isn't exactly like your average SQL database... >> What exactly do you want there? > > Something like: > > SCMType: {cvs|svn|git|hg|etc.} > SCMRepo: for cvs> > SCMModule: > SCMTag: > SCMBranch: later sources from the same product line branch instead of exact sources > of the installed package at the user's option> Right, these are just regular spec/header tags, rpmdb itself knows basically nothing about such things, it's all hidden inside headers which are more or less just "blob of stuff" to the database. Yes, if it were something like an SQL db, this would be a schema change, but not so in the case of rpmdb. >> This is already a flag day of sorts, it's by far the biggest update to rpm >> in several years. We don't need any more excitement right now, we want to >> get a new non-4.4.x rpm in an settled. Then we can start looking at new >> stuff again... > > Does "then looking at new stuff again" imply F10? Or are you saying > essentially table it until later? And IMO it's always best to have only > a single flag day if possible. The additional rpmdb headers above (and > subsequent new spec file tags to go along with them) are a flag day > event. Doing one flag day instead of two would be preferable IMO. Adding new tags is no flag day at all. The only incompatible part about such things is the spec syntax - any new tag there will mean older rpm's can be used to build such a spec. Old rpm's can however handle the resulting packages with new tags in the header just fine, assuming existing tag types (things like "32 bit integer", "string", "string array" etc) are used. > Anyway, the above fields are the essential elements necessary in order > to be able to support exploded source repos and usage of exploded source > repos as canonical source versions of binary packages. There's lots > more you *could* do in rpm to make that support more integrated and > nicer, but the rpmdb fields and spec fields are the absolute minimum. > And, at least once those are in place, any additional support items can > be added to rpm later at our convenience since everything beyond just > the headers can be managed via scripts, macros, makefiles, build system > changes, etc. Nod. This is post F10 material - just adding new tags is a total no-brainer but *doing* something with them is an entirely different question. I have all sorts of things in mind for enhancing rpmbuild and integrating with SCM tools and such, but they'll have to wait until we get this new release fully stabilized. I know. People have been waiting SO long for various things to happen in RPM that everybody's out of patience and wants their stuff in NOW. Please try to be patient a little bit longer: once this release stabilizes, RPM can move to a "normal" development-release cycle where folks will not have to wait 5+ years to get their changes in :) - Panu - From dledford at redhat.com Fri Jul 11 16:44:41 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 12:44:41 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> Message-ID: <1215794681.3687.22.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 19:22 +0300, Panu Matilainen wrote: > > Something like: > > > > SCMType: {cvs|svn|git|hg|etc.} > > SCMRepo: > for cvs> > > SCMModule: > > SCMTag: > > SCMBranch: > later sources from the same product line branch instead of exact sources > > of the installed package at the user's option> > > Right, these are just regular spec/header tags, rpmdb itself knows > basically nothing about such things, it's all hidden inside headers which > are more or less just "blob of stuff" to the database. Yes, if it were > something like an SQL db, this would be a schema change, but not so in the > case of rpmdb. OK, so that makes things *much* simpler. > Adding new tags is no flag day at all. The only incompatible part about > such things is the spec syntax - any new tag there will mean older rpm's > can be used to build such a spec. Old rpm's can however handle the > resulting packages with new tags in the header just fine, assuming > existing tag types (things like "32 bit integer", "string", "string array" > etc) are used. I assume you meant to say older rpms can't build the new spec based packages, but older rpms can handle the resulting binary rpms just fine. Which is fantastic. > > Anyway, the above fields are the essential elements necessary in order > > to be able to support exploded source repos and usage of exploded source > > repos as canonical source versions of binary packages. There's lots > > more you *could* do in rpm to make that support more integrated and > > nicer, but the rpmdb fields and spec fields are the absolute minimum. > > And, at least once those are in place, any additional support items can > > be added to rpm later at our convenience since everything beyond just > > the headers can be managed via scripts, macros, makefiles, build system > > changes, etc. > > Nod. This is post F10 material - just adding new tags is a total > no-brainer but *doing* something with them is an entirely different > question. I have all sorts of things in mind for enhancing rpmbuild and > integrating with SCM tools and such, but they'll have to wait until we get > this new release fully stabilized. > > I know. People have been waiting SO long for various things to happen in > RPM that everybody's out of patience and wants their stuff in NOW. Please > try to be patient a little bit longer: once this release stabilizes, RPM > can move to a "normal" development-release cycle where folks will not have > to wait 5+ years to get their changes in :) No offense, but as far as I'm concerned I'd trade your entire rpm update for the changes I listed above. Nothing in the list of rpm changes I saw was so earth shattering that it even comes close to the reality of being able to use a sane SCM as a canoncial source repo IMO. And people *have* been waiting *way* too long for this to happen...I was just sitting down to start working on writing the changes myself (I hadn't gotten to figuring out how the spec fields were handled in the rpmdb yet, but I had gone through the rpmbuild -b?|-t?|--rebuild|--recompile as well as the rpm -i processes looking for how to hook everything into the existing source code and what changes to make, etc.) because it's something that's so overdue. Now I find out that even though I've gotten so fed up that I was willing to put my own time in to make it happen (which is well out of my field as a kernel developer) that it doesn't even matter if I'm willing to do so, I'm blocked. That sucks in ways I can't even describe. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 hughsient at gmail.com Fri Jul 11 12:40:34 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 11 Jul 2008 13:40:34 +0100 Subject: kernel bug - sound clicks In-Reply-To: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> Message-ID: <1215780034.18964.2.camel@hughsie-work> On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: > Loud clicks from speakers (snd_intel_8x0): > https://bugzilla.redhat.com/show_bug.cgi?id=450395 > > Can somebody please look at this? Have a look at http://blogs.gnome.org/hughsie/2008/03/28/clicking-of-snd_hda_intel/ Richard. From skvidal at fedoraproject.org Fri Jul 11 16:57:19 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 11 Jul 2008 12:57:19 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215794681.3687.22.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> Message-ID: <1215795439.3020.39.camel@rosebud> On Fri, 2008-07-11 at 12:44 -0400, Doug Ledford wrote: > No offense, but as far as I'm concerned I'd trade your entire rpm update > for the changes I listed above. Nothing in the list of rpm changes I > saw was so earth shattering that it even comes close to the reality of > being able to use a sane SCM as a canoncial source repo IMO. And people > *have* been waiting *way* too long for this to happen...I was just > sitting down to start working on writing the changes myself (I hadn't > gotten to figuring out how the spec fields were handled in the rpmdb > yet, but I had gone through the rpmbuild -b?|-t?|--rebuild|--recompile > as well as the rpm -i processes looking for how to hook everything into > the existing source code and what changes to make, etc.) because it's > something that's so overdue. Now I find out that even though I've > gotten so fed up that I was willing to put my own time in to make it > happen (which is well out of my field as a kernel developer) that it > doesn't even matter if I'm willing to do so, I'm blocked. That sucks in > ways I can't even describe. > I could definitely care less about direct scm interaction in rpmbuild and care much more for cleaning up the rpm codebase and the fairly good sized changes to making the rpm interface more consistent and more hackable. So, I'm sure it's a shame that you didn't get what you want, but these things haven't been going on in secret. A look at the rpm git tree will show you that. rpm is in the middle of a good sized code reorg. You really can't expect them devels to drop everything to implement your feature, can you? -sv From pmatilai at redhat.com Fri Jul 11 17:12:10 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 11 Jul 2008 20:12:10 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215794681.3687.22.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> Message-ID: On Fri, 11 Jul 2008, Doug Ledford wrote: > On Fri, 2008-07-11 at 19:22 +0300, Panu Matilainen wrote: >>> Something like: >>> >>> SCMType: {cvs|svn|git|hg|etc.} >>> SCMRepo: >> for cvs> >>> SCMModule: >>> SCMTag: >>> SCMBranch: >> later sources from the same product line branch instead of exact sources >>> of the installed package at the user's option> >> >> Right, these are just regular spec/header tags, rpmdb itself knows >> basically nothing about such things, it's all hidden inside headers which >> are more or less just "blob of stuff" to the database. Yes, if it were >> something like an SQL db, this would be a schema change, but not so in the >> case of rpmdb. > > OK, so that makes things *much* simpler. > >> Adding new tags is no flag day at all. The only incompatible part about >> such things is the spec syntax - any new tag there will mean older rpm's >> can be used to build such a spec. Old rpm's can however handle the >> resulting packages with new tags in the header just fine, assuming >> existing tag types (things like "32 bit integer", "string", "string array" >> etc) are used. > > I assume you meant to say older rpms can't build the new spec based > packages, but older rpms can handle the resulting binary rpms just fine. > Which is fantastic. Yes, that's what I meant. > >>> Anyway, the above fields are the essential elements necessary in order >>> to be able to support exploded source repos and usage of exploded source >>> repos as canonical source versions of binary packages. There's lots >>> more you *could* do in rpm to make that support more integrated and >>> nicer, but the rpmdb fields and spec fields are the absolute minimum. >>> And, at least once those are in place, any additional support items can >>> be added to rpm later at our convenience since everything beyond just >>> the headers can be managed via scripts, macros, makefiles, build system >>> changes, etc. >> >> Nod. This is post F10 material - just adding new tags is a total >> no-brainer but *doing* something with them is an entirely different >> question. I have all sorts of things in mind for enhancing rpmbuild and >> integrating with SCM tools and such, but they'll have to wait until we get >> this new release fully stabilized. >> >> I know. People have been waiting SO long for various things to happen in >> RPM that everybody's out of patience and wants their stuff in NOW. Please >> try to be patient a little bit longer: once this release stabilizes, RPM >> can move to a "normal" development-release cycle where folks will not have >> to wait 5+ years to get their changes in :) > > No offense, but as far as I'm concerned I'd trade your entire rpm update > for the changes I listed above. Nothing in the list of rpm changes I > saw was so earth shattering that it even comes close to the reality of > being able to use a sane SCM as a canoncial source repo IMO. And people > *have* been waiting *way* too long for this to happen... Look, I know. It's just that there are like 50 similar "but we needed this two years ago" requests, they simply can't all happen at once no matter how much people yell at me. Package building is just one part of RPM functionality, the other parts have grave needs too. > I was just sitting down to start working on writing the changes myself > (I hadn't gotten to figuring out how the spec fields were handled in the > rpmdb yet, but I had gone through the rpmbuild > -b?|-t?|--rebuild|--recompile as well as the rpm -i processes looking > for how to hook everything into the existing source code and what > changes to make, etc.) because it's something that's so overdue. Now I > find out that even though I've gotten so fed up that I was willing to > put my own time in to make it happen (which is well out of my field as a > kernel developer) that it doesn't even matter if I'm willing to do so, > I'm blocked. That sucks in ways I can't even describe. If you feel like working on this, PLEASE do so! What I'm trying to say here is just that right now *my* priority number one is getting the new release stable so we have a place to put new developments into. The best way to accelerate introduction of something like this into rpm is to work on it, not getting angry at me ;) - Panu - From notting at redhat.com Fri Jul 11 17:18:11 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Jul 2008 13:18:11 -0400 Subject: Attention Spin Maintainers In-Reply-To: References: <487770C1.5020407@kanarip.com> Message-ID: <20080711171811.GC13166@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Jeroen van Meeuwen wrote: > > > Spin Maintainers, may I please have your attention. > > > > To be included in the Fedora 10 release cycle, you'll need a Feature > > page in category ProposedFeature (and change that to the > > ProposedFeatureF10 category when you feel the Spin Concept is ready for > > actual inclusion). This page should be ready (eg. prepared) before the > > Alpha freeze. > > All or just new spins (ie, where to Desktop, KDE, and other existing ones > fall)? >From talking to people, this is 'all spins which are not part of the 'normal' set (i.e., Fedora install set, Desktop live, KDE live.) Bill From a.badger at gmail.com Fri Jul 11 17:19:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 11 Jul 2008 10:19:14 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215794681.3687.22.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> Message-ID: <48779612.2050000@gmail.com> Doug Ledford wrote: > On Fri, 2008-07-11 at 19:22 +0300, Panu Matilainen wrote: >> I know. People have been waiting SO long for various things to happen in >> RPM that everybody's out of patience and wants their stuff in NOW. Please >> try to be patient a little bit longer: once this release stabilizes, RPM >> can move to a "normal" development-release cycle where folks will not have >> to wait 5+ years to get their changes in :) > > No offense, but as far as I'm concerned I'd trade your entire rpm update > for the changes I listed above. Nothing in the list of rpm changes I > saw was so earth shattering that it even comes close to the reality of > being able to use a sane SCM as a canoncial source repo IMO. And people > *have* been waiting *way* too long for this to happen...I was just > sitting down to start working on writing the changes myself (I hadn't > gotten to figuring out how the spec fields were handled in the rpmdb > yet, but I had gone through the rpmbuild -b?|-t?|--rebuild|--recompile > as well as the rpm -i processes looking for how to hook everything into > the existing source code and what changes to make, etc.) because it's > something that's so overdue. Now I find out that even though I've > gotten so fed up that I was willing to put my own time in to make it > happen (which is well out of my field as a kernel developer) that it > doesn't even matter if I'm willing to do so, I'm blocked. That sucks in > ways I can't even describe. > > There's absolutely nothing blocking you from sitting down with a checkout of current code and starting to make your changes so that you can submit some code against the updated branch to the rpm maintainers when the current release is out the door. No, it will not get into F10 but I highly doubt that Fedora Policy to allow using source control repos interchangably with tarballs would be approved in time for F10 either. -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 pmatilai at redhat.com Fri Jul 11 17:25:51 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 11 Jul 2008 20:25:51 +0300 (EEST) Subject: New RPM has landed... Message-ID: Ok then... rpm-4.5.90-0.git8426.5 finished building into rawhide a while ago just before maintenance outage (nice timing with the outage ;). Please pay extra attention to build results and once it actually hits public rawhide, any oddities in installation/updates etc. Oh and for now, please refrain from using the new spec features in Fedora to minimize the fuss in case disaster strikes and we need to go back to rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and use the new things as much as possible in private, just not yet in Fedora CVS. A further notification will be sent when the probation is over. - Panu - From j.w.r.degoede at hhs.nl Fri Jul 11 17:35:21 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jul 2008 19:35:21 +0200 Subject: kernel bug - sound clicks In-Reply-To: <1215780034.18964.2.camel@hughsie-work> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> <1215780034.18964.2.camel@hughsie-work> Message-ID: <487799D9.6020107@hhs.nl> Richard Hughes wrote: > On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: >> Loud clicks from speakers (snd_intel_8x0): >> https://bugzilla.redhat.com/show_bug.cgi?id=450395 >> >> Can somebody please look at this? > > Have a look at > http://blogs.gnome.org/hughsie/2008/03/28/clicking-of-snd_hda_intel/ > Hmm, We really should find a way to make this just work. How about adding a quirk list for this to hal and make hal set the powerdown timeout to like 5 minutes on affected laptops? So that people who don't have desktop sound effects enabled get the power managament advantages when not using sound, and those 2 do don't get the constant plopping (assuming they will do something causing set desktop sound effects atleast once every 5 minutes). Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 11 18:45:35 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 12 Jul 2008 03:45:35 +0900 Subject: koji rawhide ppc64 build failing due to strange error? Message-ID: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> Hello, all: After koji began to accept jobs again, all dist-f10 ppc64 builds seem to be failing due to some strange error? http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 None of them have build.log and root.log say: DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] DEBUG util.py:250: memory alloc (41 bytes) returned NULL. Would someone investigate what is happening here? Regards, Mamoru From jcm at redhat.com Fri Jul 11 19:15:52 2008 From: jcm at redhat.com (Jon Masters) Date: Fri, 11 Jul 2008 15:15:52 -0400 Subject: New RPM has landed... In-Reply-To: References: Message-ID: <1215803752.29584.2.camel@jcmlaptop.bos.redhat.com> On Fri, 2008-07-11 at 20:25 +0300, Panu Matilainen wrote: > Ok then... rpm-4.5.90-0.git8426.5 finished building into rawhide a while > ago just before maintenance outage (nice timing with the outage ;). Please > pay extra attention to build results and once it actually hits public > rawhide, any oddities in installation/updates etc. > > Oh and for now, please refrain from using the new spec features in Fedora > to minimize the fuss in case disaster strikes and we need to go back to > rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and > use the new things as much as possible in private, just not yet in Fedora > CVS. A further notification will be sent when the probation is over. Nice. We should sync up redhat-rpm-config with any macros updates you'd like to pull in at the same time. Jon. From rakesh.pandit at gmail.com Fri Jul 11 19:25:16 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sat, 12 Jul 2008 00:55:16 +0530 Subject: Request for sponsorship Message-ID: Hello all, For more then a month I am trying to learn fedora and fedora packaging. In the course of time I have submitted 7 packages for review: 1. 455056: Review Request: weex - Fast WEb EXchanger non-interactive FTP client 2. 455039: Review Request: php-oauth - PHP Authentication library for desktop to web applications 3. 454895: Review Request: sitecopy - Tool for easily maintaining remote web sites 4. 454395: Review Request: php-xmpphp - PHP XMPP Library 5. 445027: Review Request: dnrd - A caching, forwarding DNS proxy server 6. 448397: Review Request: ntop - A network traffic probe similar to the UNIX top command 7. 449879: Review Request: Zile - Zile Is Lossy Emacs Unofficial reviews for helping packages: 1. 454125: Review Request: gtest - Google C++ testing framework 2. 434861: Review Request: python-tftpy - Python TFTP library 3. 252108: Review Request: python-html5lib - A python based HTML5 parser/tokenizer 4. 445152: Review Request: yacpi - ncurses based acpi viewer I have done some mistakes also in process and learnt from them. I am looking for sponsor. May somebody sponsor me? I am also coordinating gnome kashmiri translation whose hosting has been shifted to fedorahosting [1]. Present owner would like to shift ownership to me as soon as I get Fedora account active. [1] https://fedorahosted.org/ks-gnome-trans/ -- Regards, Rakesh Pandit From notting at redhat.com Fri Jul 11 19:27:34 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Jul 2008 15:27:34 -0400 Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> Message-ID: <20080711192734.GB17243@nostromo.devel.redhat.com> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: > After koji began to accept jobs again, all dist-f10 ppc64 builds seem > to be failing due to some strange error? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 > http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 > http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 > > None of them have build.log and root.log say: > > DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] > DEBUG util.py:250: memory alloc (41 bytes) returned NULL. > > Would someone investigate what is happening here? Almost certianly the new rpm broke. Bill From kevin.kofler at chello.at Fri Jul 11 19:32:51 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 11 Jul 2008 19:32:51 +0000 (UTC) Subject: Announcing the Fedora EDU Spin Preview References: <20080710224154.0B86A6194AA@hormel.redhat.com> <3FF2F284-9DD6-4AA9-AF56-D124B5A3A404@silveroaks.com> Message-ID: chasd silveroaks.com> writes: > The question is, what could be more raw than RawHide ? What's actually needed here, and what kde-redhat unstable provides, is not something more experimental than Rawhide, but something inbetween updates-testing and Rawhide. Rawhide already has KDE 4.1 (prereleases), of course, but it's built against the dependencies which are in Rawhide, so you have to upgrade a lot of packages to get KDE 4.1 from Rawhide. The updates-testing repository, on the other hand, is used to test updates which are intended for pushing to the stable updates. In particular, we couldn't put KDE 4.1 in there because we needed it to test KDE 4.0 updates. (That's going to change in the next few days with KDE 4.1 having reached release candidate status and the release being scheduled for the end of the month though.) So what kde-redhat unstable provides is the latest KDE from Rawhide rebuilt for the Fedora 9 release, a preview of what is going to hit updates-testing later and the stable updates soon afterwards. Kevin Kofler From poelstra at redhat.com Fri Jul 11 19:36:45 2008 From: poelstra at redhat.com (John Poelstra) Date: Fri, 11 Jul 2008 12:36:45 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-07-07 Message-ID: <4877B64D.9020601@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jul-07 Please make corrections and clarifications to the wiki page. == Ticket Review == * spins for Fedora 9 - Fedora Release Engineering - Trac - https://fedorahosted.org/projects/rel-eng/ticket/24 * Fedora 10 Naming - Fedora Release Engineering - Trac - https://fedorahosted.org/projects/rel-eng/ticket/23 == Dropping Orphaned Packages == * Warren to start up process similar to one completed when FC6 went EOL * Did not perform at EOL for F7 * Target to complete before F10 Alpha freeze * https://fedorahosted.org/rel-eng/ticket/251 == Adjust Alpha Schedule == * Move forward one week--leave all other dates the same * http://poelstra.fedorapeople.org/schedules/f-10/f-10-all-tasks.html == IRC Transcript == From jonstanley at gmail.com Fri Jul 11 19:36:43 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 11 Jul 2008 15:36:43 -0400 Subject: New RPM has landed... In-Reply-To: References: Message-ID: On Fri, Jul 11, 2008 at 1:25 PM, Panu Matilainen wrote: > Oh and for now, please refrain from using the new spec features in Fedora to > minimize the fuss in case disaster strikes and we need to go back to rpm > 4.4.x. The new rpm is on probation for a while ;) Would it not be on "probation" until we have no more rpm 4.4.x-based releases to maintain (i.e. F8 and F9)? From jkeating at redhat.com Fri Jul 11 19:39:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 15:39:44 -0400 Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: <20080711192734.GB17243@nostromo.devel.redhat.com> References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> Message-ID: <1215805184.3224.24.camel@localhost.localdomain> On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: > Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: > > After koji began to accept jobs again, all dist-f10 ppc64 builds seem > > to be failing due to some strange error? > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 > > > > None of them have build.log and root.log say: > > > > DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] > > DEBUG util.py:250: memory alloc (41 bytes) returned NULL. > > > > Would someone investigate what is happening here? > > Almost certianly the new rpm broke. > > Bill Yeah, that's coming from rpm in the chroot. I can easily reproduce. I'm going to untag the new rpm until we sort this out. It'll be a bit before builds start working again. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 Jul 11 19:45:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Jul 2008 01:15:13 +0530 Subject: New RPM has landed... In-Reply-To: References: Message-ID: <4877B849.3050606@fedoraproject.org> Jon Stanley wrote: > On Fri, Jul 11, 2008 at 1:25 PM, Panu Matilainen wrote: > >> Oh and for now, please refrain from using the new spec features in Fedora to >> minimize the fuss in case disaster strikes and we need to go back to rpm >> 4.4.x. The new rpm is on probation for a while ;) > > Would it not be on "probation" until we have no more rpm 4.4.x-based > releases to maintain (i.e. F8 and F9)? Well, then what about EPEL? Rahul From notting at redhat.com Fri Jul 11 19:46:53 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Jul 2008 15:46:53 -0400 Subject: New RPM has landed... In-Reply-To: References: Message-ID: <20080711194653.GA1367@nostromo.devel.redhat.com> Jon Stanley (jonstanley at gmail.com) said: > On Fri, Jul 11, 2008 at 1:25 PM, Panu Matilainen wrote: > > > Oh and for now, please refrain from using the new spec features in Fedora to > > minimize the fuss in case disaster strikes and we need to go back to rpm > > 4.4.x. The new rpm is on probation for a while ;) > > Would it not be on "probation" until we have no more rpm 4.4.x-based > releases to maintain (i.e. F8 and F9)? specs don't *need* to be portable across branches. But we don't want to have to undo things to make the devel branch build if we go back. Bill From tibbs at math.uh.edu Fri Jul 11 19:49:08 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Jul 2008 14:49:08 -0500 Subject: New RPM has landed... In-Reply-To: References: Message-ID: >>>>> "JS" == Jon Stanley writes: JS> Would it not be on "probation" until we have no more rpm JS> 4.4.x-based releases to maintain (i.e. F8 and F9)? Well, if you intend a package only for rawhide (and later, only for rawhide and F10) then you could use the new features if you wanted. And then EPEL makes things interesting, because if you want a spec to be portable to EPEL you have to forego using anything new for the better part of a decade. - J< From sundaram at fedoraproject.org Fri Jul 11 19:56:46 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Jul 2008 01:26:46 +0530 Subject: Attention Spin Maintainers In-Reply-To: <20080711171811.GC13166@nostromo.devel.redhat.com> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> Message-ID: <4877BAFE.4040109@fedoraproject.org> Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >> Jeroen van Meeuwen wrote: >> >>> Spin Maintainers, may I please have your attention. >>> >>> To be included in the Fedora 10 release cycle, you'll need a Feature >>> page in category ProposedFeature (and change that to the >>> ProposedFeatureF10 category when you feel the Spin Concept is ready for >>> actual inclusion). This page should be ready (eg. prepared) before the >>> Alpha freeze. >> All or just new spins (ie, where to Desktop, KDE, and other existing ones >> fall)? > >>From talking to people, this is 'all spins which are not part of the > 'normal' set (i.e., Fedora install set, Desktop live, KDE live.) Should I submit feature pages for games and xfce spin and does it have to be done for each release? I am not sure I understand the purpose. Rahul From jkeating at redhat.com Fri Jul 11 20:01:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 16:01:36 -0400 Subject: Attention Spin Maintainers In-Reply-To: <4877BAFE.4040109@fedoraproject.org> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> Message-ID: <1215806496.3224.27.camel@localhost.localdomain> On Sat, 2008-07-12 at 01:26 +0530, Rahul Sundaram wrote: > > Should I submit feature pages for games and xfce spin and does it have > to be done for each release? I am not sure I understand the purpose. The spins we do for each release can change, thus they are features. All the other benefits of the feature process apply to spins too, even if we re-do them each release. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 Jul 11 20:05:27 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Jul 2008 01:35:27 +0530 Subject: Attention Spin Maintainers In-Reply-To: <1215806496.3224.27.camel@localhost.localdomain> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> Message-ID: <4877BD07.1010601@fedoraproject.org> Jesse Keating wrote: > On Sat, 2008-07-12 at 01:26 +0530, Rahul Sundaram wrote: >> Should I submit feature pages for games and xfce spin and does it have >> to be done for each release? I am not sure I understand the purpose. > > The spins we do for each release can change, thus they are features. > All the other benefits of the feature process apply to spins too, even > if we re-do them each release. I don't think spins should require Fedora Board approval every release. It should be a one time thing. Technical review can be done by the spin SIG. Didn't FESCo explicitly vote that spins are not features? I didn't see them reverse that decision. Besides what makes "desktop" and KDE variants not spins? Rahul From jdieter at gmail.com Fri Jul 11 20:10:18 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 11 Jul 2008 13:10:18 -0700 Subject: New RPM has landed... In-Reply-To: References: Message-ID: <1215807018.8490.25.camel@jdlaptop> On Fri, 2008-07-11 at 20:25 +0300, Panu Matilainen wrote: > Ok then... rpm-4.5.90-0.git8426.5 finished building into rawhide a while > ago just before maintenance outage (nice timing with the outage ;). Please > pay extra attention to build results and once it actually hits public > rawhide, any oddities in installation/updates etc. > > Oh and for now, please refrain from using the new spec features in Fedora > to minimize the fuss in case disaster strikes and we need to go back to > rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and > use the new things as much as possible in private, just not yet in Fedora > CVS. A further notification will be sent when the probation is over. As the maintainer for deltarpm, should I push a rebuild against the new rpm? 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 jkeating at redhat.com Fri Jul 11 20:15:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 16:15:29 -0400 Subject: Attention Spin Maintainers In-Reply-To: <4877BD07.1010601@fedoraproject.org> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> <4877BD07.1010601@fedoraproject.org> Message-ID: <1215807329.3224.34.camel@localhost.localdomain> On Sat, 2008-07-12 at 01:35 +0530, Rahul Sundaram wrote: > I don't think spins should require Fedora Board approval every release. > It should be a one time thing. Technical review can be done by the spin > SIG. That's correct, those two are a one-time shot, though subject to re-review. Neither of those are part of the Feature process. > Didn't FESCo explicitly vote that spins are not features? I didn't > see them reverse that decision. Besides what makes "desktop" and KDE > variants not spins? FESCo may have at one time, however it was ill advised. Releng and the SPINS sig want them to be features, and I'll use my powers in FESCo now and the board as well if necessary to push that agenda. Desktop and KDE are not "spins" because they are produced and qa'd as part of the rest of the distribution like the Fedora spin. They are in essence the non-contrib part. The board or FESCo could at some point change what we produce as those images, in which case Desktop or KDE would revert to a "spin" and thus go through that process and the Feature process. Features help us determine what is expected to work for a release, which drives many things like QA plans, schedules, marketing, etc... Knowing what spins to expect is very very important. There isn't always going to be somebody to pick up the slack if a spin owner moves on, we don't want to be creating these things in perpetuity if the owner isn't around, testing it, fixing it, etc... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jspaleta at gmail.com Fri Jul 11 20:23:39 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Jul 2008 12:23:39 -0800 Subject: Attention Spin Maintainers In-Reply-To: <1215806496.3224.27.camel@localhost.localdomain> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> Message-ID: <604aa7910807111323o54a6edck7bcbc7b81fcf45e1@mail.gmail.com> 2008/7/11 Jesse Keating : > The spins we do for each release can change, thus they are features. > All the other benefits of the feature process apply to spins too, even > if we re-do them each release. Unless rel-eng wants to deem specific spins as permanent spins. That wasn't part of the baseline proposal I put forward for consensus approval but suggestions on how to do a the permanent designation was in the amendent. -jef From jwboyer at gmail.com Fri Jul 11 20:44:33 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 11 Jul 2008 16:44:33 -0400 Subject: Attention Spin Maintainers In-Reply-To: <604aa7910807111323o54a6edck7bcbc7b81fcf45e1@mail.gmail.com> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> <604aa7910807111323o54a6edck7bcbc7b81fcf45e1@mail.gmail.com> Message-ID: <1215809073.14579.19.camel@weaponx> On Fri, 2008-07-11 at 12:23 -0800, Jeff Spaleta wrote: > 2008/7/11 Jesse Keating : > > The spins we do for each release can change, thus they are features. > > All the other benefits of the feature process apply to spins too, even > > if we re-do them each release. > > Unless rel-eng wants to deem specific spins as permanent spins. That > wasn't part of the baseline proposal I put forward for consensus > approval but suggestions on how to do a the permanent designation was > in the amendent. We (rel-eng) haven't designated any of the additional spins officially yet. josh From jwboyer at gmail.com Fri Jul 11 20:45:51 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 11 Jul 2008 16:45:51 -0400 Subject: New RPM has landed... In-Reply-To: <1215807018.8490.25.camel@jdlaptop> References: <1215807018.8490.25.camel@jdlaptop> Message-ID: <1215809151.14579.21.camel@weaponx> On Fri, 2008-07-11 at 13:10 -0700, Jonathan Dieter wrote: > On Fri, 2008-07-11 at 20:25 +0300, Panu Matilainen wrote: > > Ok then... rpm-4.5.90-0.git8426.5 finished building into rawhide a while > > ago just before maintenance outage (nice timing with the outage ;). Please > > pay extra attention to build results and once it actually hits public > > rawhide, any oddities in installation/updates etc. > > > > Oh and for now, please refrain from using the new spec features in Fedora > > to minimize the fuss in case disaster strikes and we need to go back to > > rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and > > use the new things as much as possible in private, just not yet in Fedora > > CVS. A further notification will be sent when the probation is over. > > As the maintainer for deltarpm, should I push a rebuild against the new > rpm? No, not yet anyway. The updated rpm has been untagged because it blows up in the buildsys. josh From sundaram at fedoraproject.org Fri Jul 11 20:49:48 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Jul 2008 02:19:48 +0530 Subject: Attention Spin Maintainers In-Reply-To: <1215807329.3224.34.camel@localhost.localdomain> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> <4877BD07.1010601@fedoraproject.org> <1215807329.3224.34.camel@localhost.localdomain> Message-ID: <4877C76C.6010505@fedoraproject.org> Jesse Keating wrote: > On Sat, 2008-07-12 at 01:35 +0530, Rahul Sundaram wrote: >> I don't think spins should require Fedora Board approval every release. >> It should be a one time thing. Technical review can be done by the spin >> SIG. > > That's correct, those two are a one-time shot, though subject to > re-review. Neither of those are part of the Feature process. I was somewhat confused by the original announcement mentioning board approval. > FESCo may have at one time, however it was ill advised. Releng and the > SPINS sig want them to be features, and I'll use my powers in FESCo now > and the board as well if necessary to push that agenda. I actually disagree with FESCo and agree with you as a spin SIG member but if FESCo makes a decision, it should be the same group reversing it instead of any of us arbitrarily deciding otherwise. There is no point in FESCo making such decisions otherwise. > Desktop and KDE are not "spins" because they are produced and qa'd as > part of the rest of the distribution like the Fedora spin. This seems to be a redefinition of a spin since KDE clearly was defined as a spin when it was proposed initially. Is the differentiation between a official and custom spin at http://fedoraproject.org/wiki/CustomSpins still valid? > Features help us determine what is expected to work for a release, which > drives many things like QA plans, schedules, marketing, etc... Knowing > what spins to expect is very very important. There isn't always going > to be somebody to pick up the slack if a spin owner moves on, we don't > want to be creating these things in perpetuity if the owner isn't > around, testing it, fixing it, etc... Agreed but it seems creating and maintaining spins have become more complicated over a period of time despite the composing tools being very easy and gaining functionality over time. One has to go through multiple groups involved including spin sig, FESCo and Fedora Board. It's been quite sometime since Fedora 9 got released and the spins are still going to be composed excluding all the many updates including critical security issues. The ks files I had originally tested and verified seems different from what is in the spin sig repo now. Probably because I don't understand git very well. We have been discussing the process forever and spin maintainers still don't have access to compose the spins. I think we need improvements in the current process for this to work at all for the sake of both the spin maintainers and others involved currently. Rahul From jspaleta at gmail.com Fri Jul 11 20:57:23 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Jul 2008 12:57:23 -0800 Subject: Attention Spin Maintainers In-Reply-To: <1215809073.14579.19.camel@weaponx> References: <487770C1.5020407@kanarip.com> <20080711171811.GC13166@nostromo.devel.redhat.com> <4877BAFE.4040109@fedoraproject.org> <1215806496.3224.27.camel@localhost.localdomain> <604aa7910807111323o54a6edck7bcbc7b81fcf45e1@mail.gmail.com> <1215809073.14579.19.camel@weaponx> Message-ID: <604aa7910807111357p3b352b0aqe4414b0dd19c4577@mail.gmail.com> On Fri, Jul 11, 2008 at 12:44 PM, Josh Boyer wrote: > We (rel-eng) haven't designated any of the additional spins officially > yet. Whatever you end up calling them... what Jesse described as the status of the Desktop and KDE images is exactly what the suggested permanent designation was meant to be used for. -jef"A permanent spin by any other name...smells as sweet?"spaleta From pjones at redhat.com Fri Jul 11 20:59:42 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 16:59:42 -0400 Subject: kernel bug - sound clicks In-Reply-To: <487799D9.6020107@hhs.nl> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> <1215780034.18964.2.camel@hughsie-work> <487799D9.6020107@hhs.nl> Message-ID: <4877C9BE.2080705@redhat.com> Hans de Goede wrote: > Richard Hughes wrote: >> On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: >>> Loud clicks from speakers (snd_intel_8x0): >>> https://bugzilla.redhat.com/show_bug.cgi?id=450395 >>> >>> Can somebody please look at this? >> >> Have a look at >> http://blogs.gnome.org/hughsie/2008/03/28/clicking-of-snd_hda_intel/ >> > > Hmm, > > We really should find a way to make this just work. How about adding a > quirk list for this to hal and make hal set the powerdown timeout to > like 5 minutes on affected laptops? Why not just make the driver lower the volume when you're not playing any sound? (I suspect that will also cause it to take very slightly less power, as well...) How long does it really take the hardware to adjust it back to the setting we're displaying to the user in the event of a noise? -- Peter From pjones at redhat.com Fri Jul 11 21:02:29 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 17:02:29 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <487535C4.9030704@blagblagblag.org> Message-ID: <4877CA65.1050904@redhat.com> Robert Nichols wrote: > Anaconda already allows you to add arbitrary kernel parameters when > configuring the bootloader. I always add "vga=791" and "selinux=0". There's a whitelist to determine which ones are propagated to the bootloader config, though. -- Peter From pjones at redhat.com Fri Jul 11 21:03:44 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Jul 2008 17:03:44 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4872962E.50101@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <48728008.2050705@blagblagblag.org> <48728BAB.3050109@blagblagblag.org> <4872962E.50101@blagblagblag.org> Message-ID: <4877CAB0.3070309@redhat.com> jeff wrote: > I just tested this on a stock F9 install: if you do selinux=0 at the > boot: line (the kernel cmdline) it doesn't get passed to the final > installed grub.conf. Does the system boot up correctly afterwards? What does "getenforce" say when you run it? -- Peter From dledford at redhat.com Fri Jul 11 21:10:05 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 17:10:05 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> Message-ID: <1215810605.3687.37.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 20:12 +0300, Panu Matilainen wrote: > On Fri, 11 Jul 2008, Doug Ledford wrote: > > > On Fri, 2008-07-11 at 19:22 +0300, Panu Matilainen wrote: > >>> Something like: > >>> > >>> SCMType: {cvs|svn|git|hg|etc.} > >>> SCMRepo: >>> for cvs> > >>> SCMModule: > >>> SCMTag: > >>> SCMBranch: >>> later sources from the same product line branch instead of exact sources > >>> of the installed package at the user's option> > >> > >> Right, these are just regular spec/header tags, rpmdb itself knows > >> basically nothing about such things, it's all hidden inside headers which > >> are more or less just "blob of stuff" to the database. Yes, if it were > >> something like an SQL db, this would be a schema change, but not so in the > >> case of rpmdb. > > > > OK, so that makes things *much* simpler. > > > >> Adding new tags is no flag day at all. The only incompatible part about > >> such things is the spec syntax - any new tag there will mean older rpm's > >> can be used to build such a spec. Old rpm's can however handle the > >> resulting packages with new tags in the header just fine, assuming > >> existing tag types (things like "32 bit integer", "string", "string array" > >> etc) are used. > > > > I assume you meant to say older rpms can't build the new spec based > > packages, but older rpms can handle the resulting binary rpms just fine. > > Which is fantastic. > > Yes, that's what I meant. > > > > >>> Anyway, the above fields are the essential elements necessary in order > >>> to be able to support exploded source repos and usage of exploded source > >>> repos as canonical source versions of binary packages. There's lots > >>> more you *could* do in rpm to make that support more integrated and > >>> nicer, but the rpmdb fields and spec fields are the absolute minimum. > >>> And, at least once those are in place, any additional support items can > >>> be added to rpm later at our convenience since everything beyond just > >>> the headers can be managed via scripts, macros, makefiles, build system > >>> changes, etc. > >> > >> Nod. This is post F10 material - just adding new tags is a total > >> no-brainer but *doing* something with them is an entirely different > >> question. I have all sorts of things in mind for enhancing rpmbuild and > >> integrating with SCM tools and such, but they'll have to wait until we get > >> this new release fully stabilized. > >> > >> I know. People have been waiting SO long for various things to happen in > >> RPM that everybody's out of patience and wants their stuff in NOW. Please > >> try to be patient a little bit longer: once this release stabilizes, RPM > >> can move to a "normal" development-release cycle where folks will not have > >> to wait 5+ years to get their changes in :) > > > > No offense, but as far as I'm concerned I'd trade your entire rpm update > > for the changes I listed above. Nothing in the list of rpm changes I > > saw was so earth shattering that it even comes close to the reality of > > being able to use a sane SCM as a canoncial source repo IMO. And people > > *have* been waiting *way* too long for this to happen... > > Look, I know. It's just that there are like 50 similar "but we needed this > two years ago" requests, they simply can't all happen at once no matter > how much people yell at me. Package building is just one part of RPM > functionality, the other parts have grave needs too. > > > I was just sitting down to start working on writing the changes myself > > (I hadn't gotten to figuring out how the spec fields were handled in the > > rpmdb yet, but I had gone through the rpmbuild > > -b?|-t?|--rebuild|--recompile as well as the rpm -i processes looking > > for how to hook everything into the existing source code and what > > changes to make, etc.) because it's something that's so overdue. Now I > > find out that even though I've gotten so fed up that I was willing to > > put my own time in to make it happen (which is well out of my field as a > > kernel developer) that it doesn't even matter if I'm willing to do so, > > I'm blocked. That sucks in ways I can't even describe. > > If you feel like working on this, PLEASE do so! What I'm trying to say > here is just that right now *my* priority number one is getting the new > release stable so we have a place to put new developments into. The best > way to accelerate introduction of something like this into rpm is to work > on it, not getting angry at me ;) Maybe the difference between what you are trying to say and are saying is the problem here. You see, here's what I said (in a nutshell): "We need these headers, everything else can wait, but just adding these allows us to move forward in using exploded source repos. All the other features a person might code into rpm can be added later because they can be worked around in the meantime via scripts, makefiles, macros, build system tweaks, etc." You responded: "Yeah, the headers are a no brainer - But doing something with them takes some effort and I don't have the time plus I got these fancy plans, so, umm, no...that'll have to wait until F11" And my response was: "Well, that's just fine...so I guess we can't make progress on things because those of us that are here and willing to work on this aren't allowed to." And your response was: "Hey, if you want to work on it, go ahead! Don't get mad at me." So, my question is, which is it? Are you going to block things, or not. I was angry because you said it would have to wait until F11 on the grounds of your grand plans, while all I asked for was just the headers, no more. You *assumed* I wanted you to implement some sort of full featured support. As did Seth. People should what I wrote more closely instead of letting their imaginations run wild. I asked for the bare minimum. Now that we have that straightened out, let me rephrase the question. Are the headers, and the headers alone, too much to ask for in the context of F10? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Fri Jul 11 21:14:16 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 17:14:16 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215795439.3020.39.camel@rosebud> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> Message-ID: <1215810856.3687.41.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 12:57 -0400, seth vidal wrote: > So, I'm sure it's a shame that you didn't get what you want, > but these things haven't been going on in secret. You and Panu both made assumptions about what I wrote that didn't exist. > A look at the rpm git > tree will show you that. Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of *any* activity of any sort there...makes a nice example of just how broken and disconnected from modern SCM management our system currently is. > rpm is in the middle of a good sized code reorg. You really can't expect > them devels to drop everything to implement your feature, can you? Didn't expect, didn't ask. Please to read better, thank you. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Fri Jul 11 21:35:04 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 17:35:04 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <48779612.2050000@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> Message-ID: <1215812104.3687.57.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 10:19 -0700, Toshio Kuratomi wrote: > There's absolutely nothing blocking you from sitting down with a > checkout of current code I did that. And then this huge update comes out of the blue (to me anyway) due to the total disconnect between upstream SCM management and our management. Not that I was complaining about the update in my previous mails, I was complaining about the statement that since it needs stabilized that it can't even tolerate some new headers (that being all I asked for). But I do find it to be a fitting example of why our SCM practices are in need of updating. > and starting to make your changes so that you > can submit some code against the updated branch to the rpm maintainers > when the current release is out the door. No, it will not get into F10 > but I highly doubt that Fedora Policy to allow using source control > repos interchangably with tarballs would be approved in time for F10 either. Good God, how long does it take you guys to make a policy decision? Should I submit a proposal and plan to argue it until F12 or some such crap? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 pmatilai at redhat.com Fri Jul 11 21:53:26 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Sat, 12 Jul 2008 00:53:26 +0300 (EEST) Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: <1215805184.3224.24.camel@localhost.localdomain> References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> Message-ID: On Fri, 11 Jul 2008, Jesse Keating wrote: > On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: >> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: >>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem >>> to be failing due to some strange error? >>> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 >>> >>> None of them have build.log and root.log say: >>> >>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] >>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. >>> >>> Would someone investigate what is happening here? >> >> Almost certianly the new rpm broke. >> >> Bill > > Yeah, that's coming from rpm in the chroot. I can easily reproduce. > I'm going to untag the new rpm until we sort this out. It'll be a bit > before builds start working again. Ugh :-/ Can you reproduce that outside of koji, and if so, how? Is this a ppc64 specific thing or a more generic one? - Panu - From moe at blagblagblag.org Fri Jul 11 21:55:47 2008 From: moe at blagblagblag.org (jeff) Date: Fri, 11 Jul 2008 18:55:47 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4877CA65.1050904@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <487535C4.9030704@blagblagblag.org> <4877CA65.1050904@redhat.com> Message-ID: <4877D6E3.1090806@blagblagblag.org> Peter Jones wrote: > Robert Nichols wrote: > >> Anaconda already allows you to add arbitrary kernel parameters when >> configuring the bootloader. I always add "vga=791" and "selinux=0". > > There's a whitelist to determine which ones are propagated to the > bootloader config, though. Is selinux=0 on the whitelist? I still don't understand why doing "boot: linux selinux=0" wouldn't/shouldn't be passed to grub. -Jeff From jspaleta at gmail.com Fri Jul 11 21:57:57 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Jul 2008 13:57:57 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215812104.3687.57.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> Message-ID: <604aa7910807111457j7d4b982fg6c18e248801e76bb@mail.gmail.com> 2008/7/11 Doug Ledford : > Good God, how long does it take you guys to make a policy decision? > Should I submit a proposal and plan to argue it until F12 or some such > crap? You have a draft proposal ready that I can read over? -jef From cra at WPI.EDU Fri Jul 11 22:00:14 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 11 Jul 2008 18:00:14 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4877D6E3.1090806@blagblagblag.org> References: <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <487535C4.9030704@blagblagblag.org> <4877CA65.1050904@redhat.com> <4877D6E3.1090806@blagblagblag.org> Message-ID: <20080711220014.GG5960@angus.ind.WPI.EDU> On Fri, Jul 11, 2008 at 06:55:47PM -0300, jeff wrote: > Peter Jones wrote: >> Robert Nichols wrote: >> >>> Anaconda already allows you to add arbitrary kernel parameters when >>> configuring the bootloader. I always add "vga=791" and "selinux=0". >> >> There's a whitelist to determine which ones are propagated to the >> bootloader config, though. > > Is selinux=0 on the whitelist? > > I still don't understand why doing "boot: linux selinux=0" > wouldn't/shouldn't be passed to grub. Because you might want to install without selnux if you have a problem with the installer in SELinux enforcing mode for example, but then want to boot the system with SELinux enabled. The installer's boot options should be kept separate from the installed system's boot options. From a.badger at gmail.com Fri Jul 11 21:56:57 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 11 Jul 2008 14:56:57 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215812104.3687.57.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> Message-ID: <4877D729.9000909@gmail.com> Doug Ledford wrote: > On Fri, 2008-07-11 at 10:19 -0700, Toshio Kuratomi wrote: >> There's absolutely nothing blocking you from sitting down with a >> checkout of current code > > I did that. And then this huge update comes out of the blue (to me > anyway) due to the total disconnect between upstream SCM management and > our management. Not that I was complaining about the update in my > previous mails, I was complaining about the statement that since it > needs stabilized that it can't even tolerate some new headers (that > being all I asked for). But I do find it to be a fitting example of why > our SCM practices are in need of updating. > No. This is a failure of you to practice good sense with the current tools. You are aware that the current tools don't reflect the state of the upstream development since they are coming out of tarballs. So why do you expect what we have in our downstream repository to reflect what is going on upstream? >> and starting to make your changes so that you >> can submit some code against the updated branch to the rpm maintainers >> when the current release is out the door. No, it will not get into F10 >> but I highly doubt that Fedora Policy to allow using source control >> repos interchangably with tarballs would be approved in time for F10 either. > > Good God, how long does it take you guys to make a policy decision? > Should I submit a proposal and plan to argue it until F12 or some such > crap? > > Well, We could always just say no without discussion if that makes you happier:-) Seriously, making use of this kind of functionality is a huge change in the expectations we have for what a source package is. Seeing as jcollie and I weren't able to sell people on making our SCM hold exploded trees of the source from tarballs, I think that having rpms that are created from SCM checkouts without the tarball intermediary are likely to meet with a lot of resistance. -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 moe at blagblagblag.org Fri Jul 11 22:07:08 2008 From: moe at blagblagblag.org (jeff) Date: Fri, 11 Jul 2008 19:07:08 -0300 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <487776F8.3080405@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <487776F8.3080405@redhat.com> Message-ID: <4877D98C.4040401@blagblagblag.org> Peter Jones wrote: > jeff wrote: > >> Mr. Cox, do you see and *technical* problems with the selinux=0 passed >> to anaconda passed to grub.conf proposal? > > If you pass selinux=0 to anaconda, you don't get selinux. It's been > that way since 13-Apr-2004. Did we break it? It doesn't appear to have > been broken intentionally, but I don't try it regularly either, since With selinux=0 in grub, in dmesg you get: Security Framework initialized SELinux: Disabled at boot. Capability LSM initialized Without selinux=0 in grub: Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary ... SELinux: Registering netfilter hooks ... SELinux: Disabled at runtime. SELinux: Unregistering netfilter hooks > Does the system boot up correctly afterwards? Yes, assuming the "Starting in permissive mode" is correct. > What does "getenforce" say when you run it? "Disabled" I don't know what the ramifications are, but it definitely has different behaviour if you disable using selinux=0 than if you don't. I see no reason why it should be loaded, initialized, etc. if it isn't wanted. Thanks, -Jeff From jspaleta at gmail.com Fri Jul 11 22:08:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Jul 2008 14:08:43 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <4877D729.9000909@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> Message-ID: <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> 2008/7/11 Toshio Kuratomi : > Seriously, making use of this kind of functionality is a huge change in the > expectations we have for what a source package is. Seeing as jcollie and I > weren't able to sell people on making our SCM hold exploded trees of the > source from tarballs, I think that having rpms that are created from SCM > checkouts without the tarball intermediary are likely to meet with a lot of > resistance. We pass on a significant burden with regard to source distribution, to anyone re-distributing Fedora media or install images. I'd like to make sure that I understand how rpms created from SCM check-outs impact our ability and downstream distributor's ability to meet that burden. If we aren't doing something to cache a copy of the corresponding source that acts like our current look aside cache, I would need someone to explain to me how this sort of thing impacts the ability of a downstream distributor to meet the source distribution requirements... using extremely small words. -jef From katzj at redhat.com Fri Jul 11 22:13:55 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 11 Jul 2008 18:13:55 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4877D98C.4040401@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <487776F8.3080405@redhat.com> <4877D98C.4040401@blagblagblag.org> Message-ID: <1215814435.29864.2.camel@aglarond.local> On Fri, 2008-07-11 at 19:07 -0300, jeff wrote: > I don't know what the ramifications are, but it definitely has different > behaviour if you disable using selinux=0 than if you don't. I see no reason why > it should be loaded, initialized, etc. if it isn't wanted. Because relying on boot options is a great way to cause problems for yourself later on down the line. If you boot with selinux=0, the installer disables SELinux for the installed system. The fact that we use a better and more persistent means of disabling it and also one that can be reversed if you later decide that you want SELinux is a *positive* thing. Jeremy From dledford at redhat.com Fri Jul 11 22:37:11 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 18:37:11 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> Message-ID: <1215815831.3687.91.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 14:08 -0800, Jeff Spaleta wrote: > 2008/7/11 Toshio Kuratomi : > > Seriously, making use of this kind of functionality is a huge change in the > > expectations we have for what a source package is. Seeing as jcollie and I > > weren't able to sell people on making our SCM hold exploded trees of the > > source from tarballs, I think that having rpms that are created from SCM > > checkouts without the tarball intermediary are likely to meet with a lot of > > resistance. > > We pass on a significant burden with regard to source distribution, to > anyone re-distributing Fedora media or install images. I'd like to > make sure that I understand how rpms created from SCM check-outs > impact our ability and downstream distributor's ability to meet that > burden. You merely need to be able to check out the source. In our case, that means we make a publicly available server for the scm repo and the gpl software recipient can check out the specific version used to build a specific package from us. If you redistribute what we ship, then you need to be able to provide the same thing to your downstream customers, so you need your own scm repo server. Now, for hg and git, this is easy. You simply clone our repo on your server and make your clone of our repo available to the world. Done. For subversion, I *think* you can do this too in the sense that I think when you check out a subversion repo, you actually get all the versions of the code and the entire repo is mirrored locally. For CVS, this is a nightmare. It's best just to not use CVS as a repo source because you either have to have the downstream party checkout each update to CVS and import it into their own CVS tree, or you let them rsync the CVS server's repo, in which case they can't make any changes of their own. It's just not pretty. It's why CVS should just frikkin' die already. > If we aren't doing something to cache a copy of the > corresponding source that acts like our current look aside cache, The repo itself acts as the look aside cache. In order for that to work, tags must be immutable and code can not be removed. However, this is no different than us not being able to rm tarballs from the cache that we have shipped, nor how we are not allowed to unpack a tarball, change the contents and then repack it back up and put it back on the cache under the same name. Exact same policies, different implementations. > I > would need someone to explain to me how this sort of thing impacts the > ability of a downstream distributor to meet the source distribution > requirements... using extremely small words. Don't use CVS (and maybe not subversion, I just don't know subversion enough to answer that), use a policy of immutable tags and commits on our own private branches enforced by access controls on our official repo server, allow downstream to pull from our repos into theirs, problem solved, and only a few large words. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jspaleta at gmail.com Fri Jul 11 22:57:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Jul 2008 14:57:43 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215815831.3687.91.camel@firewall.xsintricity.com> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> Message-ID: <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> 2008/7/11 Doug Ledford : > The repo itself acts as the look aside cache. In order for that to > work, tags must be immutable and code can not be removed. However, this > is no different than us not being able to rm tarballs from the cache > that we have shipped, nor how we are not allowed to unpack a tarball, > change the contents and then repack it back up and put it back on the > cache under the same name. Exact same policies, different > implementations. Okay.. the important bit I was missing was making sure 'we' keep a local clone of the source for everything we are building and packaging and we weren't just pulling dynamically from upstream at build time. -jef From jkeating at redhat.com Fri Jul 11 22:58:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 18:58:00 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215810856.3687.41.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> Message-ID: <1215817080.3224.37.camel@localhost.localdomain> On Fri, 2008-07-11 at 17:14 -0400, Doug Ledford wrote: > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > *any* activity of any sort there...makes a nice example of just how > broken and disconnected from modern SCM management our system currently > is. That's right, we wouldn't want to see inflight development in the HEAD of our package source control. That rapidly gets in the way of doing mass rebuilds, scripted code compliance tests, targeted fixes strikes, etc, etc... Our package SCM is not a software development SCM. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Fri Jul 11 23:04:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jul 2008 19:04:51 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> Message-ID: <1215817491.3224.42.camel@localhost.localdomain> On Fri, 2008-07-11 at 14:57 -0800, Jeff Spaleta wrote: > > Okay.. the important bit I was missing was making sure 'we' keep a > local clone of the source for everything we are building and packaging > and we weren't just pulling dynamically from upstream at build time. A "clone" would only work for a very very small portion of our software. More likely would be taking their tarball release and checking it into source code. Essentially turning our lookaside cache from a directory tree of tarballs to a SCM tree of modules. However since I don't think you can reasonably explode a tarball, check it into SCM, check it back out and tar it up again and expect the checksums to match that of the upstream tarball release. For that reason I picture two things. One, the pristine tarball itself checked into SCM, and an exploded view of it checked in and updated as new releases happen. The (s)rpms we build would be built from the pristine tarballs, the exploded view would just offer a convenient method of developing on them. Not exactly all that useful/desired in Fedora land where we're UPSTREAM UPSTREAM UPSTREAM, but useful for things like EPEL where version changes are less than welcome. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 pertusus at free.fr Sat Jul 12 00:04:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jul 2008 02:04:47 +0200 Subject: No answer to easy bug policy Message-ID: <20080712000447.GB2610@free.fr> Hello, With Rahul, we prepared a new pollicy which aim is to force maintainers to answer to easy fix bugs or orphan packages if they fail to do so in a one month delay. It may look a bit rude, but hopefully it will help spreading co-maintainership and quicker bugfixes. It is at https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance In my opinion it should be added to the non responsive policy at http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers I paste it here. Please comment. It should be proposed to FESCo after discussion here. = No answer to easy bug policy = == The Problem == There are several occasions where the individual maintainers are still active and working on some software packages while not fixing trivial bugs on other software packages. If this occurs over a long period of time, the maintainers should seek out co-maintainers or just be orphaning the software packages they are not interested in. If it does happen for a shorter periods, others can act as a buffer to avoid the problem lingering for our users. Other experienced and trusted package maintainers, developers or others in the community have offered a specific simple solution to the problem in terms of patches or recommendations that translate into straight forward solutions. Maintainers are wary of stepping on each other's toes and clear guidelines helps is setting expectations == The solution == When the situation described above happens, somebody (called the reporter) can proceed with what is explained below. However, this should only be done in one bug at a time for each maintainer, even if there are many such bugs for different or the same components. To enforce that, a blocker bug should be associated with the bug such that it is easy to see which maintainer is already concerned by the procedure. The reporter put the following comment in the bug: --- As per the 'No answer to easy bug' policy, please answer within 2 weeks whether * you allow others to fix this bug * you are not interested enough in that package to really keep on * maintaining it by yourself, and are looking for a co-maintainer or to orphan the package If you don't answer after 2 weeks and one remainder lasting also at least 2 week the package will be orphaned according to the policy stated at --- - The reporter blocks a blocker bug, such that before following the procedure another reporter can check that the packager hasn't have a similar procedure already begun. - The blocker bug is left for at least 1 month, even if the maintainer answered, such that only one procedure per month can be engaged. The idea is to avoid having people be able to bother maintainers more than needed by having only one procedure opened at a time, while forcing uninterested maintainers to orphan their packages. == References == * http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership * http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages * http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline -- Pat From sandeen at redhat.com Sat Jul 12 00:38:08 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 11 Jul 2008 19:38:08 -0500 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <4877FCF0.1000705@redhat.com> Patrice Dumas wrote: > Hello, > > With Rahul, we prepared a new pollicy which aim is to force maintainers > to answer to easy fix bugs or orphan packages if they fail to do so in a > one month delay. It may look a bit rude, but hopefully it will help > spreading co-maintainership and quicker bugfixes. It is at > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > In my opinion it should be added to the non responsive policy at > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > I paste it here. Please comment. It should be proposed to FESCo after > discussion here. Looks great except for the definition of "Easy Bug." Did I miss it? -Eric From a.badger at gmail.com Sat Jul 12 00:37:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 11 Jul 2008 17:37:14 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215815831.3687.91.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> Message-ID: <4877FCBA.80006@gmail.com> Firstly: what is your overall idea? Is it exploded trees as jcollie and I were arguing for at one time or is it mirroring of upstream repos onto Fedora servers? Go into more depth about the specifics of what you've thought out otherwise people don't know what the issues and solutions are going to be. -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 jkeating at j2solutions.net Sat Jul 12 00:40:08 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 11 Jul 2008 20:40:08 -0400 Subject: No answer to easy bug policy In-Reply-To: <4877FCF0.1000705@redhat.com> References: <20080712000447.GB2610@free.fr> <4877FCF0.1000705@redhat.com> Message-ID: <2D8A7D03-1CA8-40FF-8106-20DE2D5C9425@j2solutions.net> On Jul 11, 2008, at 20:38, Eric Sandeen wrote: > Patrice Dumas wrote: >> Hello, >> >> With Rahul, we prepared a new pollicy which aim is to force >> maintainers >> to answer to easy fix bugs or orphan packages if they fail to do so >> in a >> one month delay. It may look a bit rude, but hopefully it will help >> spreading co-maintainership and quicker bugfixes. It is at >> >> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >> >> In my opinion it should be added to the non responsive policy at >> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers >> I paste it here. Please comment. It should be proposed to FESCo after >> discussion here. > > Looks great except for the definition of "Easy Bug." Did I miss Those would be the bugs I file. All of them. -- Jes From dledford at redhat.com Sat Jul 12 01:11:30 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 21:11:30 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215817080.3224.37.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> Message-ID: <1215825090.3687.106.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 18:58 -0400, Jesse Keating wrote: > On Fri, 2008-07-11 at 17:14 -0400, Doug Ledford wrote: > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > > *any* activity of any sort there...makes a nice example of just how > > broken and disconnected from modern SCM management our system currently > > is. > > That's right, we wouldn't want to see inflight development in the HEAD > of our package source control. That rapidly gets in the way of doing > mass rebuilds, scripted code compliance tests, targeted fixes strikes, > etc, etc... > > Our package SCM is not a software development SCM. Because you are not being in the least bit imaginative with branches does not in the least justify the statement you are making. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sat Jul 12 01:29:06 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 21:29:06 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215817491.3224.42.camel@localhost.localdomain> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> Message-ID: <1215826146.3687.121.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 19:04 -0400, Jesse Keating wrote: > On Fri, 2008-07-11 at 14:57 -0800, Jeff Spaleta wrote: > > > > Okay.. the important bit I was missing was making sure 'we' keep a > > local clone of the source for everything we are building and packaging > > and we weren't just pulling dynamically from upstream at build time. > > A "clone" would only work for a very very small portion of our software. Any upstream project using git, hg, and maybe svn can do this. That is, by no means, a very very small portion of software. > More likely would be taking their tarball release and checking it into > source code. Essentially turning our lookaside cache from a directory > tree of tarballs to a SCM tree of modules. However since I don't think > you can reasonably explode a tarball, check it into SCM, check it back > out and tar it up again and expect the checksums to match that of the > upstream tarball release. If you have a cloned repo (Note: CVS does not qualify as this) then you don't need a tgz with matching checksums. The check against upstream can be a check against the upstream source revision. I sent some stuff to Jef under separate cover, but one of the things I pointed out in an email was this -----paste An SRPM is just a container, one that produces source in the end. Using an SCM repo that takes you directly to the source in question instead of generating the source in question is merely cutting out the middle man. -----end paste So, obviously, the same is true of tarballs. If you are going to do a package as an exploded source repo, then you need to get the idea straight right now that the tarball becomes totally, and completely irrelevant. It's all about the repo. A tarball is something you hand off to poor saps that haven't joined the 21st century, all the while snickering at their inability to get with the times. It is nothing more than a middle man step that interferes with efficiency of operation and that should be cut out of the loop. Instead, you use other means of verifying your initial upstream source matches upstream. Git has an extremely strong version of this built in, other repos don't but means could be scripted to get at the information you want. > For that reason I picture two things. One, the pristine tarball itself > checked into SCM, and an exploded view of it checked in and updated as > new releases happen. The (s)rpms we build would be built from the > pristine tarballs, the exploded view would just offer a convenient > method of developing on them. Not exactly all that useful/desired in > Fedora land where we're UPSTREAM UPSTREAM UPSTREAM, but useful for > things like EPEL where version changes are less than welcome. Ick. Anyone who wastes their time doing this is deserving of what they get. If upstream *only* does tarballs, and has no version control (or only CVS version control), then you can check the tarballs into an SCM or look aside cache, but there is no reason to have both exploded source and tarballs around. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 mtasaka at ioa.s.u-tokyo.ac.jp Sat Jul 12 01:29:09 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 12 Jul 2008 10:29:09 +0900 Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> Message-ID: <487808E5.7010906@ioa.s.u-tokyo.ac.jp> Panu Matilainen wrote, at 07/12/2008 06:53 AM +9:00: > On Fri, 11 Jul 2008, Jesse Keating wrote: > >> On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: >>> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: >>>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem >>>> to be failing due to some strange error? >>>> >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 >>>> >>>> None of them have build.log and root.log say: >>>> >>>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', >>>> '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] >>>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. >>>> >>>> Would someone investigate what is happening here? >>> >>> Almost certianly the new rpm broke. >>> >>> Bill >> >> Yeah, that's coming from rpm in the chroot. I can easily reproduce. >> I'm going to untag the new rpm until we sort this out. It'll be a bit >> before builds start working again. > > Ugh :-/ Can you reproduce that outside of koji, and if so, how? Is this > a ppc64 specific thing or a more generic one? > > - Panu - I don't have ppc64 based machine so currently I cannot reproduce this without koji. However this seems ppc64 specific as all other branches' build have build.logs like: http://koji.fedoraproject.org/koji/taskinfo?taskID=710412 Mamoru From mrsam at courier-mta.com Sat Jul 12 01:37:37 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 11 Jul 2008 21:37:37 -0400 Subject: Testing wanted: bootconf Message-ID: Feedback is kindly requested for bootconf, in updates-testing: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5995 This new package installs a basic GUI for selecting a boot kernel (it's an editor for grub.conf), and enabling or disabling a few command kernel boot option. The "bootconf" rpm is a baseline command line tool, the "bootconf-gui" rpm is the gnome front end. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lyos.gemininorezel at gmail.com Sat Jul 12 02:24:11 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Fri, 11 Jul 2008 22:24:11 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <487815CB.2090900@gmail.com> Patrice Dumas wrote: > Hello, > > With Rahul, we prepared a new pollicy which aim is to force maintainers > to answer to easy fix bugs or orphan packages if they fail to do so in a > one month delay. It may look a bit rude, but hopefully it will help > spreading co-maintainership and quicker bugfixes. It is at > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > In my opinion it should be added to the non responsive policy at > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > I paste it here. Please comment. It should be proposed to FESCo after > discussion here. > > > > > = No answer to easy bug policy = > > == The Problem == > > There are several occasions where the individual maintainers are still > active and working on some software packages while not fixing trivial > bugs on other software packages. If this occurs over a long period of > time, the maintainers should seek out co-maintainers or just be > orphaning the software packages they are not interested in. If it does > happen for a shorter periods, others can act as a buffer to avoid the > problem lingering for our users. Other experienced and trusted package > maintainers, developers or others in the community have offered a > specific simple solution to the problem in terms of patches or > recommendations that translate into straight forward solutions. > Maintainers are wary of stepping on each other's toes and clear > guidelines helps is setting expectations > > == The solution == > > When the situation described above happens, somebody (called the > reporter) can proceed with what is explained below. However, this > should only be done in one bug at a time for each maintainer, even if > there are many such bugs for different or the same components. > To enforce that, a blocker bug should be associated with the bug such > that it is easy to see which maintainer is already concerned > by the procedure. > > The reporter put the following comment in the bug: > > --- > > As per the 'No answer to easy bug' policy, please answer within 2 weeks > whether > > * you allow others to fix this bug > > * you are not interested enough in that package to really keep on > * maintaining it by yourself, and are looking for a co-maintainer or > to orphan the package > > If you don't answer after 2 weeks and one remainder lasting also at > least 2 week the package will be orphaned according to the policy stated > at > > --- > > - The reporter blocks a blocker bug, such that before following the > procedure another reporter can check that the packager hasn't have a > similar procedure already begun. > > - The blocker bug is left for at least 1 month, even if the maintainer > answered, such that only one procedure per month can be engaged. > > > The idea is to avoid having people be able to bother maintainers more > than needed by having only one procedure opened at a time, while forcing > uninterested maintainers to orphan their packages. > > == References == > > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline > > > > -- > Pat > > I'm no developer (not since the 6502 ASM days at any rate), but it seems to me that this may cause some contention. I hate bureaucracy in all it's forms, but I can see I slightly modified version of this being put into use, PROVIDED the majority of developers concerned (ie., at least 70%) agree to be bound by such rules. Otherwise, you risk losing alot of people. At any rate, the modification I propose is actually fairly simple. It simply makes an exception to a particular type of case. There are instances where the bug itself may be easy to fix, and there may even be a patch available, but solving that particular bug may cause bugs in other (possibly more vital) programs or libraries. I'm merely suggesting an exception for this particular case, on the off chance you'd have developers being forcefully removed because of such bugs. And yes, I do know that such cases would be rare. Lyos Gemini Norezel From jkeating at j2solutions.net Sat Jul 12 02:41:47 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 11 Jul 2008 22:41:47 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215826146.3687.121.camel@firewall.xsintricity.com> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> <1215826146.3687.121.camel@firewall.xsintricity.com> Message-ID: <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> On Jul 11, 2008, at 21:29, Doug Ledford wrote: > On Fri, 2008-07-11 at 19:04 -0400, Jesse Keating wrote: >> On Fri, 2008-07-11 at 14:57 -0800, Jeff Spaleta wrote: >>> >>> Okay.. the important bit I was missing was making sure 'we' keep a >>> local clone of the source for everything we are building and >>> packaging >>> and we weren't just pulling dynamically from upstream at build time. >> >> A "clone" would only work for a very very small portion of our >> software. > > Any upstream project using git, hg, and maybe svn can do this. That > is, > by no means, a very very small portion of software. > >> More likely would be taking their tarball release and checking it >> into >> source code. Essentially turning our lookaside cache from a >> directory >> tree of tarballs to a SCM tree of modules. However since I don't >> think >> you can reasonably explode a tarball, check it into SCM, check it >> back >> out and tar it up again and expect the checksums to match that of the >> upstream tarball release. > > If you have a cloned repo (Note: CVS does not qualify as this) then > you > don't need a tgz with matching checksums. The check against upstream > can be a check against the upstream source revision. > > I sent some stuff to Jef under separate cover, but one of the things I > pointed out in an email was this > > -----paste > > An SRPM is just a container, one that produces source in the end. > Using > an SCM repo that takes you directly to the source in question > instead of > generating the source in question is merely cutting out the middle > man. > > -----end paste > > So, obviously, the same is true of tarballs. If you are going to do a > package as an exploded source repo, then you need to get the idea > straight right now that the tarball becomes totally, and completely > irrelevant. It's all about the repo. A tarball is something you hand > off to poor saps that haven't joined the 21st century, all the while > snickering at their inability to get with the times. It is nothing > more > than a middle man step that interferes with efficiency of operation > and > that should be cut out of the loop. Instead, you use other means of > verifying your initial upstream source matches upstream. Git has an > extremely strong version of this built in, other repos don't but means > could be scripted to get at the information you want. > >> For that reason I picture two things. One, the pristine tarball >> itself >> checked into SCM, and an exploded view of it checked in and updated >> as >> new releases happen. The (s)rpms we build would be built from the >> pristine tarballs, the exploded view would just offer a convenient >> method of developing on them. Not exactly all that useful/desired in >> Fedora land where we're UPSTREAM UPSTREAM UPSTREAM, but useful for >> things like EPEL where version changes are less than welcome. > > Ick. Anyone who wastes their time doing this is deserving of what > they > get. > > If upstream *only* does tarballs, and has no version control (or only > CVS version control), then you can check the tarballs into an SCM or > look aside cache, but there is no reason to have both exploded source > and tarballs around. Unfortunatly I live in reality where many upstreams post process the scm checkout so reliance on the scm alone is not possible. -- Jes From dledford at redhat.com Sat Jul 12 02:48:01 2008 From: dledford at redhat.com (Doug Ledford) Date: Fri, 11 Jul 2008 22:48:01 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <4877FCBA.80006@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <4877FCBA.80006@gmail.com> Message-ID: <1215830881.3687.184.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 17:37 -0700, Toshio Kuratomi wrote: > Firstly: what is your overall idea? Is it exploded trees as jcollie and > I were arguing for at one time or is it mirroring of upstream repos onto > Fedora servers? It's both. You first have to support exploded source repos to make the rest of this worth anything. However, part of *truly* supporting an exploded source repo is making that repo available INSTEAD OF srpms. In other words, fulfill our legal obligation to provide source for a package via the source repo instead of via an srpm. Once you take that first step, then the next part is integrating our own development processes with those from upstream where ever we can (this means any upstream project that uses a distributed SCM, and possibly also subversion, but you might as well write off CVS). But you can't call it mirroring, because that implies that our source repo is just a copy of upstream's and that wouldn't be the case. Instead, we would *follow* their repo commits, on branches that belong to them and we don't touch, and we would do our own work on our own branches and merge from their branches to our branches when appropriate (this sounds more complex than it is really...most packages we are just going to take whatever upstream does wholesale into our own branch, it's only a few packages that will really make use of this capability). If upstream happens to be on any decent distributed SCM, then this becomes an almost dreamy operation for maintainers (compared to now anyway). And if upstream doesn't use an SCM worth a crap, there's nothing to say we can't explode out a package anyway. It all depends on how much work we are going to do on that package to determine if it's worth the effort, or if the ability to merge things between stable branches matters a lot. Obviously, some packages we just run make and throw them over the wall. Other packages we do more. It's the packages where we do a lot that it really makes a difference. > Go into more depth about the specifics of what you've > thought out otherwise people don't know what the issues and solutions > are going to be. The first issue is simply supporting an exploded source repo. An exploded source repo really only requires a few things. First, you no longer need a %setup or %patch portion in the spec file. Second, you treat things differently in that sourcedir, specdir, and builddir are all one and the same. Finally, since you built the binary packages from this exploded source repo, then in order to give people the exact sources you built from, you need to make the repo available for clone/checkout by people. You need never once build an srpm or tarball from this repo if you don't want to (and in fact, an srpm wouldn't build from the same spec file as an exploded source repo spec file unless you conditionalized the spec to know if it was in an srpm or in its native exploded source repo format). Other than that, the other issues related to the repo: access controls, making sure anything and everything built from the repo through the build system corresponds to a tag in the repo, that other standard policies are followed; these things are all srpm style versus exploded repo agnostic (implementation details differ, but the basic policies are the same). In a nutshell this sums up what's needed to support an exploded source repo (obviously, the RPM headers I mentioned earlier in this thread are for tracking what tag you build a package from, which you *must* do since you no longer produce an srpm unless needed for some other reason, and there are support details needed in the build system, but all of these are surprisingly simple things to take care of, it's more getting people used to the idea of not having an srpm in their hands that's the single biggest hurdle to an exploded source repo). Once you support and exploded source repo, and support a repo as the canonical source distribution mechanism, then the first advantage to this type of setup is that every SCM worth a pile of dog poo will store the different versions of software in some form of change related format that keeps you from duplicating the same things over and over again like tarball after tarball does. You generally take a hit in size versus a single tarball, but end up saving quite a lot in the long run. And the more efficient the system is at branching, the better this gets. And you generally don't have to worry about cleaning out caches and crap like that just because removing a single version isn't really possible, and wouldn't save you anything even if it was possible. Just about any package can benefit from this over time. Next, you get to work on the code in native format, try things out, run build tests, and all the while the pain of repetitive rpm source processing is reduced (sometimes it sucks, sometimes not, depends on the package). But, it's certainly much easier to do a bunch of work, build, oops it didn't build, edit again, build again, finally builds, test, oops it breaks, edit again, build again, it works this time, great time to check in: viola, you no longer have to worry about "gee, I forgot to create a backup copy of file blah so when I ran gendiff it missed that file from the patch and I lost it when I went to test the rpm build" or any crap like that, you just get to check in your changes with a nice changelog that describes your wonderful work. Those two things along really are enough to justify the exploded source repo concept by themselves. But, they aren't all by a long shot. This is all irregardless of upstream. What happens when upstream runs a reasonable distributed SCM too? Let's look at an example. This is where I point out that Jesse's email I responded to about the upstream RPM devel cluttering up fedora's devel branch, the one where I said he wasn't imaginative at all in terms of branching, is a perfect example. Panu mentioned he was pulling the new rpm from the upstream git repo. We would simply clone that. In the process, our official repo would have a list of references to the remote, upstream repo's branches. These branches are inviolate by us. We can never change them, they simply are a copy of upstream's metadata. We can, however, create our own branches. In fact, the standard modus operandi in a case like this would be to clone upstream, then create tracking branches in our repo that show us upstreams branches (because we don't see anything but master from upstream by default), then create our own branches (so upstream has it's own devel branch, usually just named master, and we could create our own branch named fedora-devel that would be our primary devel branch, then as we approach a release we can branch from fedora-devel to f-8, f-9, etc), and then we simply merge or don't merge from upstream to our devel branch as we see fit. For things where we want to follow upstream, we can actually configure fedora-devel to automatically merge any new changes from upstream's master branch in anytime we do a pull (in fact, you can do this on a per branch basis, any given branch can be told to automatically merge changes from another branch into it, or it can be a more static branch that doesn't auto merge anything). Had this been the case, then merely setting the fedora-devel branch to not automerge from the remote (upstream) devel branch would have resulted in all of the auto-rebuilds and things like that working just fine on the fedora-devel branch as Jesse mentioned needed to happen, but it would have let us see the changes going on in the remote tracking branches and everyone who bothered to update their rpm repo would see those changes on those remote branches and know something was up. And it gets even better. Let's say I decided to put mdadm under git management (as it turns out, upstream also uses git on mdadm). And let's say I have some patches I would like upstream to consider. Since I'm now working on exploded source, those patches aren't patches any more, they're change sets. I can actually create a temporary branch that is a clone of upstream's master, and then I can hand pick the patches I would like to go upstream and merge those change sets to this temporary branch, then I can send upstream an email that says: Hey Neil, I have some stuff I would like you to include in mdadm. Here's the change logs from the change sets: etc. please pull from git://git.fedorahosted.org/mdadm for-neil He can then pull those into his master, and the next time I pull from his tree and merge it into my tree, my git will see that he picked up my changes and not try to merge them onto branches where they already exist, making the whole "UPSTREAM UPSTREAM UPSTREAM" mantra of Fedora that much easier to implement. Really, there are all sorts of reasons to use exploded source repos, to join our own development efforts in with upstream and to hook our source systems together. In the end though, it all boils down to this. Some people are comfortable with and want to keep using srpms and our current disconnected SCM methodology, and some people want another choice. I'm perfectly fine with other people not wanting to change. They don't have to. But I would prefer to be granted the ability to modernize my own way of working should I choose to do so. And this is a big part of that. This has been more of a sales pitch than anything to be honest. If you want to know more about what I had in mind for nuts and bolts changes to rpm, then I'm attaching a tar.gz of my ~/.tomboy directory. As I was working on things, I just made notes (I really like Tomboy now). Move your own .tomboy out of the way if you have anything you'd like to save, then unpack mine in place, restart tomboy, and start reading from the Enabling optimal SCM usage in Fedora. Everything is linked from that one note. Of course, I was really only a little ways in. I was still concentrating on the rpm changes and hadn't touched on build system changes, or repo server changes, or access controls with different scms, or any of that stuff. And what I *had* accomplished in terms of rpm knowledge is now at least somewhat wrong given the rpm update. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: tomboy.tgz Type: application/x-compressed-tar Size: 18921 bytes Desc: not available URL: -------------- 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 abartlet at samba.org Sat Jul 12 03:11:28 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 12 Jul 2008 13:11:28 +1000 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807031637.11351.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807021754.52422.jbarnes@virtuousgeek.org> <200807031637.11351.jbarnes@virtuousgeek.org> Message-ID: <1215832288.3816.35.camel@naomi.s4.naomi.abartlet.net> On Thu, 2008-07-03 at 16:37 -0700, Jesse Barnes wrote: > On Wednesday, July 02, 2008 5:54 pm Jesse Barnes wrote: > > Thanks for packaging this stuff, I really hope the MAPI Akonadi code works; > > I'd *love* to ditch Outlook (it's the next best thing to escaping the > > Exchange ghetto). > > Ok, started building kdepim today, but ran into quite a few problems: > - profile*.cpp in openchange resource need to include KLocale > - samba-4.0/events.h shouldn't use C++ keywords as variable names > - lots of errors building openchange after fixing those things, along the > lines of: > ome/jbarnes/working/rpmbuild/BUILD/kdepim-4.0.84/x86_64-redhat-linux-gnu/akonadi/resources/openchange/akonadi_oc_resource_automoc.cpp > In file included from /usr/include/QtCore/qdebug.h:53, > from /usr/include/QtCore/QDebug:2, > from /home/jbarnes/working/rpmbuild/BUILD/kdepim-4.0.84/akonadi/resources/openchange/ocresource.cpp:26: > /usr/include/QtCore/qtextstream.h:105: error: expected unqualified-id before '(' token > /usr/include/QtCore/qtextstream.h:106: error: expected unqualified-id before '(' token > /usr/include/QtCore/qtextstream.h:107: error: expected unqualified-id before '(' token > /usr/include/QtCore/qtextstream.h:124: error: expected unqualified-id before '(' token > > which again looks like a possible missing header problem? Dunno yet... Probably a question for the OpenChange team. I'm stretching myself packaging this stuff, but I just wanted to see some movement in this area. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Sat Jul 12 04:38:36 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 11 Jul 2008 23:38:36 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215810856.3687.41.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> Message-ID: <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> 2008/7/11 Doug Ledford : > On Fri, 2008-07-11 at 12:57 -0400, seth vidal wrote: >> >> A look at the rpm git >> tree will show you that. > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > *any* activity of any sort there...makes a nice example of just how > broken and disconnected from modern SCM management our system currently > is. Doug, no offence, but I find it hard to believe that you didn't see: https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00003.html or: $ rpm -q --queryformat="%{url}\n" rpm http://www.rpm.org/ Jeff From j.w.r.degoede at hhs.nl Sat Jul 12 05:30:13 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 12 Jul 2008 07:30:13 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <48784165.7050704@hhs.nl> Patrice Dumas wrote: > Hello, > > With Rahul, we prepared a new pollicy which aim is to force maintainers > to answer to easy fix bugs or orphan packages if they fail to do so in a > one month delay. It may look a bit rude, but hopefully it will help > spreading co-maintainership and quicker bugfixes. It is at > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > In my opinion it should be added to the non responsive policy at > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > I paste it here. Please comment. It should be proposed to FESCo after > discussion here. > > Hmm, First of all, I agree that non-repsonsive ness to easy bugs and / or bugs with patches attached is an issue. But I'm not sure this is a good solution. There are really 2 problems here: 1) The person responsible for the package is letting these bugs linger 2) Others do not fix it, even though they could, because they are afraid of stepping on each other's toes, as you correctly point out. I feel that your policy completely fails to address 2), whereas that might be one of the more important points. For example I don't mind other people touching my packages _at all_, which can be seen from there ACL's. So we could have a policy that says that "easy fixes" (whatever the definition) may be done by anyone with CVS extras without a prior headsup, when the ACL's allow it. IOW, codify in policy that the ACL signals how much a developer minds other people touching his packages. Another possible solution would be a I don't mind my toes getting stepped on list in the wiki. Regards, Hans From lyos.gemininorezel at gmail.com Sat Jul 12 06:01:32 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sat, 12 Jul 2008 02:01:32 -0400 Subject: No answer to easy bug policy In-Reply-To: <48784165.7050704@hhs.nl> References: <20080712000447.GB2610@free.fr> <48784165.7050704@hhs.nl> Message-ID: <487848BC.7000008@gmail.com> Hans de Goede wrote: > Hmm, > > First of all, I agree that non-repsonsive ness to easy bugs and / or > bugs with patches attached is an issue. > > But I'm not sure this is a good solution. There are really 2 problems > here: > 1) The person responsible for the package is letting these bugs linger > 2) Others do not fix it, even though they could, because they are afraid > of stepping on each other's toes, as you correctly point out. > > I feel that your policy completely fails to address 2), whereas that > might be one of the more important points. For example I don't mind > other people touching my packages _at all_, which can be seen from > there ACL's. So we could have a policy that says that "easy fixes" > (whatever the definition) may be done by anyone with CVS extras > without a prior headsup, when the ACL's allow it. IOW, codify in > policy that the ACL signals how much a developer minds other people > touching his packages. > > Another possible solution would be a I don't mind my toes getting > stepped on list in the wiki. > > Regards, > > Hans > How about both? A list in the wiki... AND ACLs. I like this solution alot more than Rahul's proposal. Lyos Gemini Norezel From dwmw2 at infradead.org Sat Jul 12 08:30:48 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 12 Jul 2008 09:30:48 +0100 Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> Message-ID: <1215851448.11567.490.camel@pmac.infradead.org> On Sat, 2008-07-12 at 00:53 +0300, Panu Matilainen wrote: > On Fri, 11 Jul 2008, Jesse Keating wrote: > > > On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: > >> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: > >>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem > >>> to be failing due to some strange error? > >>> > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 > >>> > >>> None of them have build.log and root.log say: > >>> > >>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] > >>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. > >>> > >>> Would someone investigate what is happening here? > >> > >> Almost certianly the new rpm broke. > >> > >> Bill > > > > Yeah, that's coming from rpm in the chroot. I can easily reproduce. > > I'm going to untag the new rpm until we sort this out. It'll be a bit > > before builds start working again. > > Ugh :-/ Can you reproduce that outside of koji, and if so, how? Is this a > ppc64 specific thing or a more generic one? Let me know if you need an account on a suitable machine so you can try this in mock. -- dwmw2 From lystor at lystor.org.ua Sat Jul 12 08:33:43 2008 From: lystor at lystor.org.ua (Nikolay Ulyanitsky) Date: Sat, 12 Jul 2008 11:33:43 +0300 Subject: Source rpms for RHEL Supplementary CD java packages Message-ID: <1215851623.2853.3.camel@localhost.localdomain> Hi Are source rpm packages (or spec files + patches without source files) for binary java packages from RHEL Supplementary CD (v. 5 for 32-bit x86) (rhel-5.2-server-supplementary-i386-disc1.iso) available for free download? Some java packages from RHEL Supplementary CD (v. 5 for 32-bit x86): java-1.4.2-*.rpm java-1.5.0-*.rpm java-1.6.0-*.rpm These packages differ with packages from jpackage.org. -- Nikolay Ulyanitsky From hughsient at gmail.com Sat Jul 12 08:12:50 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 12 Jul 2008 09:12:50 +0100 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <1215850370.24851.29.camel@hughsie-work> On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote: > There are several occasions where the individual maintainers are still > active and working on some software packages while not fixing trivial > bugs on other software packages. Surely the maintainer in question knows the package well enough to decide whether to merge patches? For instance, I might push a patch upstream and hold off applying it to fedora as it's trivial and will get updated at the next version bump of my package in a few weeks. This all seems so very beurocratic to me. Richard. From pertusus at free.fr Sat Jul 12 08:48:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jul 2008 10:48:57 +0200 Subject: No answer to easy bug policy In-Reply-To: <1215850370.24851.29.camel@hughsie-work> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> Message-ID: <20080712084857.GA2762@free.fr> On Sat, Jul 12, 2008 at 09:12:50AM +0100, Richard Hughes wrote: > On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote: > > There are several occasions where the individual maintainers are still > > active and working on some software packages while not fixing trivial > > bugs on other software packages. > > Surely the maintainer in question knows the package well enough to > decide whether to merge patches? For instance, I might push a patch > upstream and hold off applying it to fedora as it's trivial and will get > updated at the next version bump of my package in a few weeks. But you can mention it on the patch, so that the reporter knows what is happening. Or close UPSTREAM. Also I have added a 3 weeks delay before this is started. This leads to 3 weeks + 1 month time. > This all seems so very beurocratic to me. It is. But burocracy is required when it comes to forcing other contributors. -- Pat From pertusus at free.fr Sat Jul 12 08:59:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jul 2008 10:59:24 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <20080712085924.GB2762@free.fr> On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > Hello, > > With Rahul, we prepared a new pollicy which aim is to force maintainers > to answer to easy fix bugs or orphan packages if they fail to do so in a > one month delay. It may look a bit rude, but hopefully it will help > spreading co-maintainership and quicker bugfixes. It is at > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > In my opinion it should be added to the non responsive policy at > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers I have hopefully adressed th ecomments, by stating that this is a policy for bug fixes, not easy bug as such. Also added a 3 weeks delay before the procedure is started, precise a bit what is a bug easy to fix and put explicitely the cleaning of blocker bugs on the reporter. -- Pat From pertusus at free.fr Sat Jul 12 09:07:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jul 2008 11:07:03 +0200 Subject: No answer to easy bug policy In-Reply-To: <48784165.7050704@hhs.nl> References: <20080712000447.GB2610@free.fr> <48784165.7050704@hhs.nl> Message-ID: <20080712090703.GC2762@free.fr> On Sat, Jul 12, 2008 at 07:30:13AM +0200, Hans de Goede wrote: > > First of all, I agree that non-repsonsive ness to easy bugs and / or > bugs with patches attached is an issue. > > But I'm not sure this is a good solution. There are really 2 problems here: > 1) The person responsible for the package is letting these bugs linger > 2) Others do not fix it, even though they could, because they are afraid > of stepping on each other's toes, as you correctly point out. > > I feel that your policy completely fails to address 2), whereas that > might be one of the more important points. For example I don't mind I agree. But this is not the intent of this policy, I mean even if 2) is easier (and it has became a lot easier already) it may happen that something is needed to have the maintainer react. > other people touching my packages _at all_, which can be seen from there > ACL's. So we could have a policy that says that "easy fixes" (whatever > the definition) may be done by anyone with CVS extras without a prior > headsup, when the ACL's allow it. IOW, codify in policy that the ACL > signals how much a developer minds other people touching his packages. I don't think we should mix the ACL with the intent to allow anybody to fix packages. Having open ACL also allows to have a package fixed for cases already covered by the WhoIsAllowedToModifyWhichPackages policy, for example. > Another possible solution would be a I don't mind my toes getting > stepped on list in the wiki. I think that it should better be in the packagedb. But I am not sure that it will fix the case I did the policy for, since if somebody is really opened like you are, a simple comment in the bug like 'you can do it' is very low cost, but I personally have never seen such a comment on the typical bugs that triggered me to do this policy. -- Pat From pertusus at free.fr Sat Jul 12 09:07:50 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jul 2008 11:07:50 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080712085924.GB2762@free.fr> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> Message-ID: <20080712090750.GD2762@free.fr> On Sat, Jul 12, 2008 at 10:59:24AM +0200, Patrice Dumas wrote: > On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > I have hopefully adressed th ecomments, by stating that this is a policy > for bug fixes, not easy bug as such. Also added a 3 weeks delay before > the procedure is started, precise a bit what is a bug easy to fix and > put explicitely the cleaning of blocker bugs on the reporter. Still on https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance -- Pat From pmatilai at redhat.com Sat Jul 12 09:37:01 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Sat, 12 Jul 2008 12:37:01 +0300 (EEST) Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: <1215851448.11567.490.camel@pmac.infradead.org> References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> <1215851448.11567.490.camel@pmac.infradead.org> Message-ID: On Sat, 12 Jul 2008, David Woodhouse wrote: > On Sat, 2008-07-12 at 00:53 +0300, Panu Matilainen wrote: >> On Fri, 11 Jul 2008, Jesse Keating wrote: >> >>> On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: >>>> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: >>>>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem >>>>> to be failing due to some strange error? >>>>> >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 >>>>> >>>>> None of them have build.log and root.log say: >>>>> >>>>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] >>>>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. >>>>> >>>>> Would someone investigate what is happening here? >>>> >>>> Almost certianly the new rpm broke. >>>> >>>> Bill >>> >>> Yeah, that's coming from rpm in the chroot. I can easily reproduce. >>> I'm going to untag the new rpm until we sort this out. It'll be a bit >>> before builds start working again. >> >> Ugh :-/ Can you reproduce that outside of koji, and if so, how? Is this a >> ppc64 specific thing or a more generic one? > > Let me know if you need an account on a suitable machine so you can try > this in mock. Thanks for the offer, Jarod Wilson already kindly provided me access to ppc64 host where I can mess around :) The good news is that I can reproduce it, and it is indeed a ppc64-only problem. Here's what happens: stat("/var/lib/rpm/Name", {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0 open("/var/lib/rpm/Name", O_RDONLY) = 6 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 read(6, "\0\0\0\0\0\0\0\1\0\0\0\0\0\6\25a\0\0\0\10\0\0\20\0\0\10\0\0\0\0\0\0"..., 512) = 512 close(6) = 0 open("/var/lib/rpm/Name", O_RDONLY) = 6 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 fstat(6, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 mmap(NULL, 171798695936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) No wonder it fails... Now just to figure out where that comes from... but that'll have to wait till later today/tomorrow, family is demanding attention :) - Panu - From rawhide at fedoraproject.org Sat Jul 12 09:53:58 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 12 Jul 2008 09:53:58 +0000 (UTC) Subject: rawhide report: 20080712 changes Message-ID: <20080712095358.B4649209D95@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080711/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080712/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gfs-ambrosia-fonts GFS Ambrosia majuscule Greek font New package gfs-fleischman-fonts GFS Fleischman majuscule Greek font New package guake Drop-down terminal for GNOME New package pnp4nagios Nagios performance data analysis tool Removed package ruby-amazon Updated Packages: NetworkManager-0.7.0-0.10.svn3801.fc10.1 ---------------------------------------- * Fri Jul 11 18:00:00 2008 Matthias Clasen - 1:0.7.0-0.10.svn3801 - Drop explicit hal dep in -gnome TnL-071111-6.fc10 ----------------- * Fri Jul 11 18:00:00 2008 Hans de Goede 071111-6 - Rebuild for new cegui anaconda-11.4.1.14-1 -------------------- * Fri Jul 11 18:00:00 2008 Chris Lumens - 11.4.1.14-1 - Remove an extra tab that was causing problems with the Iloko translation. (clumens) - Use the right stage2.img path for kickstart URL installs (#452140). (clumens) - Convert package errors to unicode before displaying them (#441200). (clumens) - Display a status message while waiting for the CD to become ready. (clumens) - Fix window title to be the same as all others. (clumens) - In cmdline mode, give some feedback when transferring loader files. (clumens) - If network config info isn't provided for cmdline, abort. (clumens) - If we're not given a method in cmdline mode, we have to quit. (clumens) - In cmdline mode, set language to the default if none is provided. (clumens) - Don't stop on the method screen if stage2= is provided. (clumens) - Add support for NFS to the repo editor (#443733). (clumens) - Fix whitespace silliness. (pjones) - Fix closing the drive door so that if the kernel happens to start giving us the right error code, we'll handle it correctly... (pjones) - Fix the mysterious Error: OK message. (clumens) - The return value from mediaCheckCdrom is totally useless. (clumens) - Add better error handling when initializing yum (#453695). (clumens) - Add functions for creating repos as well. (clumens) - Don't handle all possible exceptions as if they were repo errors. (clumens) - Reorganize to make it easier to reset the "base" repository. (clumens) - Remove the pkgSack when a repo is disabled. (clumens) - Use the new method of calling the NetworkConfigurator. (clumens) - Add an updated repo editor. (clumens) - Don't suggest text mode to the poor, poor user. (pjones) bind-9.5.1-0.1.b1.fc10 ---------------------- * Tue Jul 8 18:00:00 2008 Adam Tkac 32:9.5.1-0.1.b1 - 9.5.1b1 release (CVE-2008-1447) - dropped bind-9.5-recv-race.patch because upstream doesn't want it * Mon Jun 30 18:00:00 2008 Adam Tkac 32:9.5.0-37.1 - update default named.conf statements (#452708) cegui-0.6.1-1.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Hans de Goede 0.6.1-1 - New upstream release 0.6.1 - Drop upstreamed patches charis-fonts-4.104-2.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 - 4.104-2 ??? Fedora 10 alpha general package cleanup chess-1.0-17.fc10 ----------------- * Fri Jul 11 18:00:00 2008 Hans de Goede 1.0-17 - Rebuild for new cegui compat-db-4.6.21-2.fc10 ----------------------- * Fri Jul 11 18:00:00 2008 Panu Matilainen 4.6.21-2 - fix broken devel library symlinks crystalspace-1.2-7.fc10 ----------------------- * Fri Jul 11 18:00:00 2008 Hans de Goede 1.2-7 - Rebuild for new cegui dejavu-fonts-2.25-2.fc10 ------------------------ * Fri Jul 11 18:00:00 2008 - 2.25-2 ??? Fedora 10 alpha general package cleanup denyhosts-2.6-11.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Jason L Tibbitts III - 2.6-11 - Tweak initscript priorities to ensure that the MTA is started first. docbook-dtds-1.0-38.fc10 ------------------------ * Fri Jul 11 18:00:00 2008 Ondrej Vasik - 1.0-38 - fixed typo in post scriptlet(causing mishandling of DocBook 4.4 and 4.5 DTDs)-#453513 edrip-fonts-20080710-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 - 20080710-1 ??? Fedora 10 alpha general package cleanup emerald-0.7.6-1.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Nikolay Vladimirov - 0.7.6-1 - new upstream release - removed gcc43 patch(upstream) - added .desktop file patch(fixes bz 286141) - spec file clean up file-roller-2.23.3-2.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 Matthias Clasen - 2.23.3-2 - Fix icon lookup gdm-2.22.0-12.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Matthias Clasen - 1:2.22.0-12 - Actually apply the patch generic-logos-9.99.0-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 Bill Nottingham - 9.99.0-1 - add a system logo for plymouth's spinfinity plugin gfs-artemisia-fonts-20070415-7.fc10 ----------------------------------- * Fri Jul 11 18:00:00 2008 - 20070415-7 ??? Fedora 10 alpha general package cleanup gfs-baskerville-fonts-20070327-8.fc10 ------------------------------------- * Fri Jul 11 18:00:00 2008 - 20070415-8 ??? Fedora 10 alpha general package cleanup gfs-bodoni-classic-fonts-20070415-7.fc10 ---------------------------------------- * Fri Jul 11 18:00:00 2008 - 20070415-7 ??? Fedora 10 alpha general package cleanup gfs-bodoni-fonts-20070415-6.fc10 -------------------------------- * Fri Jul 11 18:00:00 2008 - 20070415-6 ??? Fedora 10 alpha general package cleanup gfs-complutum-fonts-20070413-8.fc10 ----------------------------------- * Fri Jul 11 18:00:00 2008 - 20070413-8 ??? Fedora 10 alpha general package cleanup gfs-didot-classic-fonts-20080702-2.fc10 --------------------------------------- * Fri Jul 11 18:00:00 2008 - 20080702-2 ??? Fedora 10 alpha general package cleanup gfs-didot-fonts-20070616-7.fc10 ------------------------------- * Fri Jul 11 18:00:00 2008 - 20070616-7 ??? Fedora 10 alpha general package cleanup gfs-gazis-fonts-20080318-3.fc10 ------------------------------- * Fri Jul 11 18:00:00 2008 - 20080318-3 ??? Fedora 10 alpha general package cleanup gfs-neohellenic-fonts-20070415-6.fc10 ------------------------------------- * Fri Jul 11 18:00:00 2008 - 20070415-6 ??? Fedora 10 alpha general package cleanup gfs-olga-fonts-20060908-6.fc10 ------------------------------ * Fri Jul 11 18:00:00 2008 - 20060908-6 ??? Fedora 10 alpha general package cleanup gfs-porson-fonts-20060908-8.fc10 -------------------------------- * Fri Jul 11 18:00:00 2008 - 20060908-8 ??? Fedora 10 alpha general package cleanup gfs-solomos-fonts-20071114-7.fc10 --------------------------------- * Fri Jul 11 18:00:00 2008 - 20071114-7 ??? Fedora 10 alpha general package cleanup gfs-theokritos-fonts-20070415-7.fc10 ------------------------------------ * Fri Jul 11 18:00:00 2008 - 20070415-7 ??? Fedora 10 alpha general package cleanup goocanvasmm-0.6.0-1.fc10 ------------------------ * Fri Jul 11 18:00:00 2008 Denis Leroy - 0.6.0-1 - Update to upstream 0.6.0 - Updated BRs gyachi-1.1.35-16.fc10 --------------------- * Sat Jul 12 18:00:00 2008 Gregory D Hosler - 1.1.35-16 - gyachi obsoletes gyachi-plugin-photosharing icu4j-3.8.1-2.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Andrew Overholt 0:3.8.1-2 - Remove GCJ support due to com.sun.tools.doclets.internal.toolkit.taglets.* import (not in gjdoc) * Fri Jul 11 18:00:00 2008 Andrew Overholt 0:3.8.1-1 - 3.8.1 iwl4965-firmware-228.57.2.21-2 ------------------------------ * Fri Jul 11 18:00:00 2008 kwizart < kwizart at gmail.com > - 228.57.2.21-2 - Bump to keep the old 4.44.17 firmware dropped. * Fri Jul 11 18:00:00 2008 kwizart < kwizart at gmail.com > - 228.57.2.21-1 - Update firmware v1 to 228.57.1.21 - Add firmware v2 to 228.57.2.21 * Tue Apr 8 18:00:00 2008 kwizart < kwizart at gmail.com > - 4.44.1.20-2 - Drop the old 4.44.17 firmware jakarta-commons-logging-1.0.4-7.8.fc10 -------------------------------------- * Fri Jul 11 18:00:00 2008 Andrew Overholt 0:1.0.4-7.7 - Update OSGi bundle version. jd-2.0.0-0.7.svn2191_trunk.fc10 ------------------------------- * Sat Jul 12 18:00:00 2008 Mamoru Tasaka - rev 2191 kdeaccessibility-4.0.98-1.fc10 ------------------------------ * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdeadmin-4.0.98-1.fc10 ---------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdeartwork-4.0.98-1.fc10 ------------------------ * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdebase-4.0.98-2.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-2 - BR: pciutils-devel * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdebase-runtime-4.0.98-1.fc10 ----------------------------- * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdebase-workspace-4.0.98-2.fc10 ------------------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-2 - respun tarball (with systray patch) * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdeedu-4.0.98-1.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdegames-4.0.98-1.fc10 ---------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdegraphics-4.0.98-1.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdemultimedia-4.0.98-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdenetwork-4.0.98-1.fc10 ------------------------ * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdepim-4.0.98-1.fc10 -------------------- * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdepimlibs-4.0.98-1.fc10 ------------------------ * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdeplasmoids-4.0.98-1.fc10 -------------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 * Thu Jul 10 18:00:00 2008 Rex Dieter 4.0.85-2 - Provides: kdeplasma-addons kdesdk-4.0.98-1.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdetoys-4.0.98-1.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kdeutils-4.0.98-1.fc10 ---------------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 kernel-2.6.26-0.131.rc9.git9.fc10 --------------------------------- * Fri Jul 11 18:00:00 2008 Roland McGrath - utrace update * Fri Jul 11 18:00:00 2008 Dave Jones - 2.6.26-rc9-git9 * Fri Jul 11 18:00:00 2008 Dave Jones - 2.6.26-rc9-git8 * Thu Jul 10 18:00:00 2008 John W. Linville - Upstream wireless fixes from 2008-07-09 (http://marc.info/?l=linux-netdev&m=121563769208664&w=2) * Thu Jul 10 18:00:00 2008 Dave Jones - 2.6.26-rc9-git7 * Thu Jul 10 18:00:00 2008 Dave Jones - 2.6.26-rc9-git6 krb5-1.6.3-15.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Nalin Dahyabhai 1.6.3-15 - build with -fno-strict-aliasing, which is needed because the library triggers these warnings - don't forget to label principal database lock files - fix the labeling patch so that it doesn't break bootstrapping * Sat Jun 14 18:00:00 2008 Tom "spot" Callaway 1.6.3-14 - generate src/include/krb5/krb5.h before building - fix conditional for sparcv9 * Wed Apr 16 18:00:00 2008 Nalin Dahyabhai 1.6.3-13 - ftp: use the correct local filename during mget when the 'case' option is enabled (#442713) * Fri Apr 4 18:00:00 2008 Nalin Dahyabhai 1.6.3-12 - stop exporting kadmin keys to a keytab file when kadmind starts -- the daemon's been able to use the database directly for a long long time now - belatedly add aes128,aes256 to the default set of supported key types * Tue Apr 1 18:00:00 2008 Nalin Dahyabhai 1.6.3-11 - libgssapi_krb5: properly export the acceptor subkey when creating a lucid context (Kevin Coffman, via the nfs4 mailing list) ocaml-bitmatch-1.9.5-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 Richard W.M. Jones - 1.9.5-1 - New upstream release 1.9.5. - Clarify that the programs have GPL license. - Ship bitmatch-objinfo program. ogre-1.4.9-2.fc10 ----------------- * Fri Jul 11 18:00:00 2008 Hans de Goede 1.4.9-2 - Rebuild for new cegui perl-Convert-UUlib-1.11-1.fc10 ------------------------------ * Fri Jul 11 18:00:00 2008 - 1:1.11-1 ??? Fedora 10 alpha general package cleanup perl-Crypt-CBC-2.29-1.fc10 -------------------------- * Fri Jul 11 18:00:00 2008 Tom "spot" Callawau - 2.29-1 - update to 2.29 perl-Font-TTF-0.45-1.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 - 0.45-1 ??? Fedora 10 alpha general package cleanup ??? Upstream needs to relicense fast to avoid culling perl-HTML-FormatText-WithLinks-0.09-3.fc10 ------------------------------------------ * Fri Jul 11 18:00:00 2008 Tom "spot" Callaway - 0.09-3 - fix license tag (it may be correct, but its flagging as a false positive on checks) perl-Net-Server-0.97-5.fc10 --------------------------- perl-Test-Pod-Coverage-1.08-6.fc10 ---------------------------------- * Fri Jul 11 18:00:00 2008 Tom "spot" Callaway - 1.08-6 - fix license tag perl-TimeDate-1.16-9.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 Tom "spot" Callaway - 1:1.16-9 - fix license tag php-pear-propel_generator-1.3.0-0.2.rc1.fc10 -------------------------------------------- * Fri Jul 11 18:00:00 2008 Alexander Kahl - 1.3.0-0.2.rc1 - updated summary - dropped Obsoletes - untabified php-pear-propel_runtime-1.3.0-0.2.rc1.fc10 ------------------------------------------ * Fri Jul 11 18:00:00 2008 Alexander Kahl - 1.3.0-0.2.rc1 - updated summary - untabified - dropped Obsoletes - dropped php-pear-Log dependency, not really necessary pop-before-smtp-1.42-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 Tom "spot" Callaway 1.42-1 - 1.42 - fix license tag prelude-correlator-0.9.0-0.3.beta3.fc10 --------------------------------------- * Fri Jul 11 18:00:00 2008 Steve Grubb 0.9.0-0.3.beta3 - New beta release pungi-2.0.2-1.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Jesse Keating 2.0.2-1 - add ability to gather debuginfo. It is default. python-basemap-0.99-2.fc10 -------------------------- * Fri Jul 11 18:00:00 2008 Jef Spaleta 0.99-2 - File conflict fix for Bug 455005 python-fedora-0.3-1.fc10 ------------------------ * Wed Jul 2 18:00:00 2008 Luke Macken - 0.3-1 - New upstream release. python-formencode-1.0.1-1.fc10 ------------------------------ * Fri Jul 11 18:00:00 2008 Toshio Kuratomi 1.0.1-1 - Update to 1.0.1 - Fixes issue where chained_validators were silently ignored. (bz#454988) Both of our patches are fixed upstream now. python-toscawidgets-0.9.2-1.fc10 -------------------------------- * Mon Jul 7 18:00:00 2008 Toshio Kuratomi - 0.9.2-1 - Update to latest release. - Fixes problem with pages being returned as text/plain. qt-4.4.0-12.fc10 ---------------- * Fri Jul 11 18:00:00 2008 Rex Dieter 4.4.0-12 - qt-copy-patches-20080711 rsyslog-3.19.9-1.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Lubomir Rintel 3.19.9-1 - upgrade sepostgresql-8.3.3-2.952.fc10 ----------------------------- * Fri Jul 11 18:00:00 2008 - 8.3.3-2.952 - Security policy module updates * Fri Jul 11 18:00:00 2008 - 8.3.3-2.945 - Add OpenSSL support - backport 8.4devel fixes * Sun Jun 15 18:00:00 2008 - 8.3.3-2.889 - backport 8.4devel features. seq24-0.8.7-13.fc10 ------------------- * Fri Jul 11 18:00:00 2008 Anthony Green 0.8.7-13 - Add buffer overflow fix. soprano-2.0.99-1.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Kevin Kofler 2.0.99-1 - update to 2.0.99 (2.1 RC 1) stix-fonts-0.9-7.fc10 --------------------- * Fri Jul 11 18:00:00 2008 - 0.9-7 ??? Fedora 10 alpha general package cleanup thunar-shares-0.13-1.fc10 ------------------------- * Fri Jul 11 18:00:00 2008 Christoph Wickert - 0.13-1 - Update to 0.13 virt-df-2.1.2-1.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Richard W.M. Jones - 2.1.2-1 - New upstream version 2.1.2. wireshark-1.0.2-1.fc10 ---------------------- * Fri Jul 11 18:00:00 2008 Radek Vok??l 1.0.2-1 - upgrade to 1.0.2 xenner-0.39-1.fc10 ------------------ * Fri Jul 11 18:00:00 2008 Gerd Hoffmann - 0.39-1.fc10 - update to version 0.39 - avoid emu*.elf getting stripped xmlsec1-1.2.11-1 ---------------- * Fri Jul 11 18:00:00 2008 Daniel Veillard - 1.2.11-1 - update to new upstream release 1.2.11 - rebuild for gnutls update yanone-kaffeesatz-fonts-20061120-3.fc10 --------------------------------------- * Fri Jul 11 18:00:00 2008 - 20061120-4 ??? Fedora 10 alpha general package cleanup Summary: Added Packages: 4 Removed Packages: 1 Modified Packages: 85 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.i386 requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.x86_64 requires libgnutls.so.13()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13(GNUTLS_1_3) ekg2-jabber-0.2-0.1.rc1.fc10.ppc requires libgnutls.so.13 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13(GNUTLS_1_3)(64bit) ekg2-jabber-0.2-0.1.rc1.fc10.ppc64 requires libgnutls.so.13()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) From dominik at greysector.net Sat Jul 12 10:45:09 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 12 Jul 2008 12:45:09 +0200 Subject: No answer to easy bug policy In-Reply-To: <487848BC.7000008@gmail.com> References: <20080712000447.GB2610@free.fr> <48784165.7050704@hhs.nl> <487848BC.7000008@gmail.com> Message-ID: <20080712104509.GA2915@mokona.greysector.net> On Saturday, 12 July 2008 at 08:01, Lyos Gemini Norezel wrote: > Hans de Goede wrote: > >Hmm, > > > >First of all, I agree that non-repsonsive ness to easy bugs and / or > >bugs with patches attached is an issue. > > > >But I'm not sure this is a good solution. There are really 2 problems > >here: > >1) The person responsible for the package is letting these bugs linger > >2) Others do not fix it, even though they could, because they are afraid > > of stepping on each other's toes, as you correctly point out. > > > >I feel that your policy completely fails to address 2), whereas that > >might be one of the more important points. For example I don't mind > >other people touching my packages _at all_, which can be seen from > >there ACL's. So we could have a policy that says that "easy fixes" > >(whatever the definition) may be done by anyone with CVS extras > >without a prior headsup, when the ACL's allow it. IOW, codify in > >policy that the ACL signals how much a developer minds other people > >touching his packages. > > > >Another possible solution would be a I don't mind my toes getting > >stepped on list in the wiki. > > > >Regards, > > > >Hans > > > How about both? A list in the wiki... AND ACLs. Not another list... I don't mind my packages being touched by others, but I'm reluctant to maintain yet another list. It's hard enough to keep track of my own packages. IMHO setting ACLs to open should be signal enough. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at gmail.com Sat Jul 12 11:42:23 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 12 Jul 2008 07:42:23 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215825090.3687.106.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> Message-ID: <1215862943.14579.24.camel@weaponx> On Fri, 2008-07-11 at 21:11 -0400, Doug Ledford wrote: > On Fri, 2008-07-11 at 18:58 -0400, Jesse Keating wrote: > > On Fri, 2008-07-11 at 17:14 -0400, Doug Ledford wrote: > > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > > > *any* activity of any sort there...makes a nice example of just how > > > broken and disconnected from modern SCM management our system currently > > > is. > > > > That's right, we wouldn't want to see inflight development in the HEAD > > of our package source control. That rapidly gets in the way of doing > > mass rebuilds, scripted code compliance tests, targeted fixes strikes, > > etc, etc... > > > > Our package SCM is not a software development SCM. > > Because you are not being in the least bit imaginative with branches > does not in the least justify the statement you are making. OK, how about this: Nobody has the time nor has anyone shown overwhelming benefits to rework our entire infrastructure to deal with a new SCM for _packages_ so that people can do code _development_ on them when that should all be done _upstream_. Again, scratch your own itch if it's bothering you that badly. josh From kanarip at kanarip.com Sat Jul 12 12:17:59 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 12 Jul 2008 14:17:59 +0200 Subject: Attention Spin Maintainers In-Reply-To: References: <487770C1.5020407@kanarip.com> Message-ID: <4878A0F7.4050303@kanarip.com> Rex Dieter wrote: > Jeroen van Meeuwen wrote: > >> Spin Maintainers, may I please have your attention. >> >> To be included in the Fedora 10 release cycle, you'll need a Feature >> page in category ProposedFeature (and change that to the >> ProposedFeatureF10 category when you feel the Spin Concept is ready for >> actual inclusion). This page should be ready (eg. prepared) before the >> Alpha freeze. > > All or just new spins (ie, where to Desktop, KDE, and other existing ones > fall)? > It should be done for all spins to-be included in the next release. Obviously, for the recurring spins such as Gnome and KDE, the page will just need to change category between development cycles. To show you how this is not at all too much overhead for you as a maintainer / initiator of the Spin Concept... The more you write on your wiki page about the spin, the easier the websites-team will be able to -in the future- create you a neat page for the specific spin on spins.fp.o Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Sat Jul 12 12:29:31 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 12 Jul 2008 14:29:31 +0200 Subject: Attention Spin Maintainers In-Reply-To: <4878A0F7.4050303@kanarip.com> References: <487770C1.5020407@kanarip.com> <4878A0F7.4050303@kanarip.com> Message-ID: <4878A3AB.5030804@kanarip.com> Jeroen van Meeuwen wrote: > It should be done for all spins to-be included in the next release. > Obviously, for the recurring spins such as Gnome and KDE, the page will > just need to change category between development cycles. > > To show you how this is not at all too much overhead for you as a > maintainer / initiator of the Spin Concept... The more you write on your > wiki page about the spin, the easier the websites-team will be able to > -in the future- create you a neat page for the specific spin on spins.fp.o > Note to self... read the entire thread before replying. If it's in spin-kickstarts, and going to end up on spins.fp.o, it needs to have a Feature page IMHO. Whether we all know to ignore whatever is on the KDE spin feature page, or whether we all get a chance to see how Rex and Sebastian are doing, track motivations for changes they make and where they're moving in general, or just because I can then search the wiki for all Spin Wiki Feature Pages, maintainers, progress, etc... I didn't even mention the advantages of treating two of the same things like if they really were the same, within the Feature process... Kind regards, Jeroen van Meeuwen -kanarip From sundaram at fedoraproject.org Sat Jul 12 12:32:25 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Jul 2008 18:02:25 +0530 Subject: No answer to easy bug policy In-Reply-To: <48784165.7050704@hhs.nl> References: <20080712000447.GB2610@free.fr> <48784165.7050704@hhs.nl> Message-ID: <4878A459.6090500@fedoraproject.org> Hans de Goede wrote: > I feel that your policy completely fails to address 2), whereas that > might be one of the more important points. For example I don't mind > other people touching my packages _at all_, which can be seen from there > ACL's. So we could have a policy that says that "easy fixes" (whatever > the definition) may be done by anyone with CVS extras without a prior > headsup, when the ACL's allow it. IOW, codify in policy that the ACL > signals how much a developer minds other people touching his packages. This is what I tried to address in an earlier mail. Boils back to the definition of easy fixes. > Another possible solution would be a I don't mind my toes getting > stepped on list in the wiki. If ACL's are open, I think that by itself should be enough indication of an agreement to any such policies. If we need another tag to denote it, it should be part of pkgdb itself instead of the wiki. Rahul From dominik at greysector.net Sat Jul 12 13:30:48 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 12 Jul 2008 15:30:48 +0200 Subject: rawhide report: 20080531 changes In-Reply-To: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> References: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> Message-ID: <20080712133048.GA3131@mokona.greysector.net> On Saturday, 31 May 2008 at 13:02, Rawhide wrote: [...] Sorry to dig up old stuff, but this update > gtk2-2.13.1-2.fc10 > ------------------ > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-2 > - Fix a problem with some pixbuf loaders > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-1 > - Update to 2.13.1 broke compilation of ekg2. See https://bugzilla.redhat.com/show_bug.cgi?id=449637 I finally managed to paper over the issue by adding a missing deprecated #define and not including a deprecated header. Looks like an incompatible API change in gtk2-2.13.1. I'll notify upstream about this. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dledford at redhat.com Sat Jul 12 14:04:05 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 10:04:05 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> Message-ID: <1215871445.3687.190.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 23:38 -0500, Jeffrey Ollie wrote: > 2008/7/11 Doug Ledford : > > On Fri, 2008-07-11 at 12:57 -0400, seth vidal wrote: > >> > >> A look at the rpm git > >> tree will show you that. > > > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > > *any* activity of any sort there...makes a nice example of just how > > broken and disconnected from modern SCM management our system currently > > is. > > Doug, no offence, but I find it hard to believe that you didn't see: > > https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00003.html Wasn't subscribed in December (recently added a number of fedora subscriptions to me email load). My day job is on RHEL and I'm *making* time for Fedora...back then I didn't need the additional email load. > or: > > $ rpm -q --queryformat="%{url}\n" rpm > http://www.rpm.org/ What I've been hearing for eons is that upstream rpm has gone rogue (well, not exactly, but my own simplification and paraphrase). That kinda makes one wonder if they should bother looking. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 lemenkov at gmail.com Sat Jul 12 14:08:21 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 12 Jul 2008 18:08:21 +0400 Subject: How to handle soname bump properly? Message-ID: Hello All! Consider, we got library libfoo and dependent utility bar. If I updated library libfoo (successfully built with soname increased, and ready to hit updates-testing via Bodhi), then how should I udate bar? If I rebuild bar, then against what version of libfoo it will be rebuilt? Against old one or against new, which still not submitted to updates-testing (to avoid unresolved dependencies). After brief looking into fedora-wiki, I found nothing valuable matching this topic. -- With best regards! From dledford at redhat.com Sat Jul 12 14:36:00 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 10:36:00 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215862943.14579.24.camel@weaponx> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> Message-ID: <1215873360.3687.213.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 07:42 -0400, Josh Boyer wrote: > On Fri, 2008-07-11 at 21:11 -0400, Doug Ledford wrote: > > On Fri, 2008-07-11 at 18:58 -0400, Jesse Keating wrote: > > > On Fri, 2008-07-11 at 17:14 -0400, Doug Ledford wrote: > > > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of > > > > *any* activity of any sort there...makes a nice example of just how > > > > broken and disconnected from modern SCM management our system currently > > > > is. > > > > > > That's right, we wouldn't want to see inflight development in the HEAD > > > of our package source control. That rapidly gets in the way of doing > > > mass rebuilds, scripted code compliance tests, targeted fixes strikes, > > > etc, etc... > > > > > > Our package SCM is not a software development SCM. > > > > Because you are not being in the least bit imaginative with branches > > does not in the least justify the statement you are making. > > OK, how about this: > > Nobody has the time I'm *making* the time...around my day job. > nor has anyone shown overwhelming benefits Well, I've made noises about it. Hell, so long ago that it was me, Tim Powers, and Christian Gafton sitting around drinking beers over the topic we knew that our CVS repo was a total steaming POS. But more recently, I spent 20 or 30 minutes listening to Mark Webbink talk legal issues at the Raleigh FUDCon, and during that talk someone asked a question (someone who was kinda upset at the time). The question/accusation kinda went something like this: "Fedora introduced this new thing, fedora spins, and they helped me easily make my own spin, but now they expect me to carry both it and all the sources myself. What kind of loyalty does this show to the community that *makes* Fedora that you won't support them on this sort of stuff and you leave them hanging out to dry." Now, Mark rightly answered that question with this basic response: "Yes, we don't distribute that for you, because that would then put us on the hook for keeping your sources around long enough to satisfy the GPL. We make it easy for you to create your own spins, but we don't have the resources or the administrative capacity to guarantee that your legal requirements in terms of the GPL are met, so we force you to distribute your spins yourself." After the talk was over I spent some time talking to Jesse where I pointed out to him that if you did away with the look aside cache for tarballs, and instead used exploded source in a repo, that you could in fact add new branches onto a repo for essentially zero cost and those branches could be what's used by people to make spins. That in this way we could, for next to no additional burden, carry their sources for them to satisfy the GPL and to allow them to more readily create and distribute spins. Obviously, this hasn't gone anywhere since then. > to rework > our entire infrastructure to deal with a new SCM for _packages_ so that > people can do code _development_ on them when that should all be done > _upstream_. The distinction between upstream development and Fedora development is artificial. And it's a nice way to keep upstream developers from having any interest in managing their own packages. Congratulations on that. But more importantly, I'm doing this because I want Red Hat to use the same tools that are used in Fedora (after all, Koji grew from brew, a Red Hat internal tool, and likewise the Fedora CVS is a cheap knock-off of the Red Hat internal CVS system), and in Red Hat Enterprise Linux, we most *definitely* have a need to be able to do real development on package branches versus upstream. So, as long as Red Hat and Fedora intend to share technology in this area, then I would suggest that Red Hat not block Fedora's needs, and likewise Fedora shouldn't actively block Red Hat's needs, especially on the basis of artificial maxims that aren't even true. > Again, scratch your own itch if it's bothering you that badly. Isn't that what I've been saying I want to do? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 tmz at pobox.com Sat Jul 12 15:24:48 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 12 Jul 2008 11:24:48 -0400 Subject: How to handle soname bump properly? In-Reply-To: References: Message-ID: <20080712152448.GS7900@inocybe.teonanacatl.org> Peter Lemenkov wrote: > Consider, we got library libfoo and dependent utility bar. > > If I updated library libfoo (successfully built with soname > increased, and ready to hit updates-testing via Bodhi), then how > should I udate bar? This is something that requires some help from rel-eng. You would build libfoo and then mail rel-eng at fedoraproject.org asking for a build root override for libfoo (providing the full n-e-v-r or cvs tag for the libfoo build you want to be in the build root) and often some brief justification for the request (like, "I need this to build bar against in order to fix outstanding bugs"). They sprinkle some pixie dust and let you know when it's done. Then you can build bar against the new libfoo and push both of them as a single update to updates-testing via bodhi. (Of course, you should already have done some testing of this in rawhide and locally for the affected stable release and thought hard about whether a soname bump in the stable release warranted -- that the benefits of the bump outweigh the drawbacks.) > If I rebuild bar, then against what version of libfoo it will be > rebuilt? Against old one or against new, which still not submitted to > updates-testing (to avoid unresolved dependencies). It would be built against the older version, which is obviously not what you want. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mollison's Bureaucracy Hypothesis: If an idea can survive a bureaucratic review and be implemented it wasn't worth doing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From pmatilai at redhat.com Sat Jul 12 15:26:12 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Sat, 12 Jul 2008 18:26:12 +0300 (EEST) Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: <1215805184.3224.24.camel@localhost.localdomain> References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> Message-ID: On Fri, 11 Jul 2008, Jesse Keating wrote: > On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: >> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: >>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem >>> to be failing due to some strange error? >>> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 >>> >>> None of them have build.log and root.log say: >>> >>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] >>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. >>> >>> Would someone investigate what is happening here? >> >> Almost certianly the new rpm broke. >> >> Bill > > Yeah, that's coming from rpm in the chroot. I can easily reproduce. > I'm going to untag the new rpm until we sort this out. It'll be a bit > before builds start working again. Ok, take two, build just completed. The ppc64 issue should be gone, at least things work on in mock. Hopefully it lasts in the builders a bit longer than previous try ;) but if it causes troubles, just untag it and let me know... - Panu - From lemenkov at gmail.com Sat Jul 12 15:30:55 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 12 Jul 2008 19:30:55 +0400 Subject: How to handle soname bump properly? In-Reply-To: <20080712152448.GS7900@inocybe.teonanacatl.org> References: <20080712152448.GS7900@inocybe.teonanacatl.org> Message-ID: 2008/7/12, Todd Zullinger : > Peter Lemenkov wrote: > > Consider, we got library libfoo and dependent utility bar. > > > > If I updated library libfoo (successfully built with soname > > increased, and ready to hit updates-testing via Bodhi), then how > > should I udate bar? > This is something that requires some help from rel-eng. You would > build libfoo and then mail rel-eng at fedoraproject.org asking for a > build root override for libfoo (providing the full n-e-v-r or cvs tag > for the libfoo build you want to be in the build root) and often some > brief justification for the request (like, "I need this to build bar > against in order to fix outstanding bugs"). > > They sprinkle some pixie dust and let you know when it's done. Then > you can build bar against the new libfoo and push both of them as a > single update to updates-testing via bodhi. > > (Of course, you should already have done some testing of this in > rawhide and locally for the affected stable release and thought hard > about whether a soname bump in the stable release warranted -- that > the benefits of the bump outweigh the drawbacks.) Thanks! Do you mind if I grab your post (partially) and bury it in Swamps of Fedora-Wiki? -- With best regards! From kanarip at kanarip.com Sat Jul 12 15:34:34 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 12 Jul 2008 17:34:34 +0200 Subject: Issue with re- or unbranding Message-ID: <4878CF0A.1000405@kanarip.com> Hi, if we replace fedora-logos for generic-logos to try and re- or unbrand Fedora, /etc/rc.sysinit gets in the way: == # Print a text banner. echo -en $"\t\tWelcome to " read -r redhat_release < /etc/redhat-release if [[ "$redhat_release" =~ "Red Hat" ]]; then [ "$BOOTUP" = "color" ] && echo -en "\\033[0;31m" echo -en "Red Hat" [ "$BOOTUP" = "color" ] && echo -en "\\033[0;39m" PRODUCT=`sed "s/Red Hat \(.*\) release.*/\1/" /etc/redhat-release` echo " $PRODUCT" elif [[ "$redhat_release" =~ "Fedora" ]]; then [ "$BOOTUP" = "color" ] && echo -en "\\033[0;34m" echo -en "Fedora" [ "$BOOTUP" = "color" ] && echo -en "\\033[0;39m" PRODUCT=`sed "s/Fedora \(.*\) \?release.*/\1/" /etc/redhat-release` echo " $PRODUCT" else PRODUCT=`sed "s/ release.*//g" /etc/redhat-release` echo "$PRODUCT" fi == Resulting in "Welcome to Fedora" when a machine boots -both Live Media and Installation media. No biggy, but I'm not sure whether replacing the contents of /etc/fedora-release (from fedora-release) would give my any trouble, and if so, whether we need to replace fedora-release when rebranding as well. Another approach is to modify rc.sysinit in a way that takes into account rebranding. Another approach is to move /etc/*-release to fedora-logos and having a generic-logos alternative. I'd like some additional thoughts on this and some advice on what to pursue. Kind regards, Jeroen van Meeuwen -kanarip From mclasen at redhat.com Sat Jul 12 17:04:36 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 12 Jul 2008 13:04:36 -0400 Subject: rawhide report: 20080531 changes In-Reply-To: <20080712133048.GA3131@mokona.greysector.net> References: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> <20080712133048.GA3131@mokona.greysector.net> Message-ID: <1215882276.3513.0.camel@localhost.localdomain> On Sat, 2008-07-12 at 15:30 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 31 May 2008 at 13:02, Rawhide wrote: > [...] > > Sorry to dig up old stuff, but this update > > > gtk2-2.13.1-2.fc10 > > ------------------ > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-2 > > - Fix a problem with some pixbuf loaders > > > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-1 > > - Update to 2.13.1 > > broke compilation of ekg2. See https://bugzilla.redhat.com/show_bug.cgi?id=449637 > > I finally managed to paper over the issue by adding a missing deprecated > #define and not including a deprecated header. Looks like an incompatible > API change in gtk2-2.13.1. I'll notify upstream about this. No need, I am upstream. But it would be more helpful if you let me know what was missing, in your opinion. From jwboyer at gmail.com Sat Jul 12 17:40:35 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 12 Jul 2008 13:40:35 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215873360.3687.213.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> Message-ID: <1215884435.14579.36.camel@weaponx> On Sat, 2008-07-12 at 10:36 -0400, Doug Ledford wrote: > > > > That's right, we wouldn't want to see inflight development in the HEAD > > > > of our package source control. That rapidly gets in the way of doing > > > > mass rebuilds, scripted code compliance tests, targeted fixes strikes, > > > > etc, etc... > > > > > > > > Our package SCM is not a software development SCM. > > > > > > Because you are not being in the least bit imaginative with branches > > > does not in the least justify the statement you are making. > > > > OK, how about this: > > > > Nobody has the time > > I'm *making* the time...around my day job. Most of the Fedora contributors do that. > But more recently, I spent 20 or 30 minutes listening to Mark Webbink > talk legal issues at the Raleigh FUDCon, and during that talk someone > asked a question (someone who was kinda upset at the time). The > question/accusation kinda went something like this: "Fedora introduced > this new thing, fedora spins, and they helped me easily make my own > spin, but now they expect me to carry both it and all the sources > myself. What kind of loyalty does this show to the community that > *makes* Fedora that you won't support them on this sort of stuff and you > leave them hanging out to dry." As a side bar, we need to figure out a way to do a better recap of FUDCon. People's blogs and personal recaps are great, but this seems like a pretty important topic and I don't recall it being discussed or recapped anywhere. (Please someone correct me if I'm wrong and I missed it.) > After the talk was over I spent some time talking to Jesse where I > pointed out to him that if you did away with the look aside cache for > tarballs, and instead used exploded source in a repo, that you could in > fact add new branches onto a repo for essentially zero cost and those > branches could be what's used by people to make spins. That in this way > we could, for next to no additional burden, carry their sources for them > to satisfy the GPL and to allow them to more readily create and > distribute spins. Obviously, this hasn't gone anywhere since then. This is the first time I've heard that benefit. It seems like a fairly good one. > > to rework > > our entire infrastructure to deal with a new SCM for _packages_ so that > > people can do code _development_ on them when that should all be done > > _upstream_. > > The distinction between upstream development and Fedora development is > artificial. And it's a nice way to keep upstream developers from having > any interest in managing their own packages. Congratulations on that. In many cases upstream and Fedora are synonymous (anaconda, pungi, yum, etc). In many cases they aren't. And we _do_ have upstream maintainers packaging for Fedora. The CVS package repo we have is not that large of a burden. Your argument about that is about as effective as saying RPM is the reason upstream doesn't package for Fedora because they mostly use Debian or Ubuntu, which are apt based. There is truth in it, but it is not an "OMG the sky is falling" situation. > So, as long as Red Hat and Fedora > intend to share technology in this area, then I would suggest that Red > Hat not block Fedora's needs, and likewise Fedora shouldn't actively > block Red Hat's needs, especially on the basis of artificial maxims that > aren't even true. This is very simple. Nobody is blocking anything. All you have to do is actually start doing something instead of telling everyone that you are going to do something and you'll make progress. Jesse had a git repo at one time of Fedora. You might be able to leverage that work as a starting point. > > Again, scratch your own itch if it's bothering you that badly. > > Isn't that what I've been saying I want to do? Yes. So do it, and stop saying it? Places to start: 1) Koji 2) Bodhi 3) The Makefiles in the SCM 4) Jesse's git import of Fedora josh From mschwendt at gmail.com Sat Jul 12 17:54:02 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 12 Jul 2008 19:54:02 +0200 Subject: rawhide report: 20080531 changes In-Reply-To: <1215882276.3513.0.camel@localhost.localdomain> References: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> <20080712133048.GA3131@mokona.greysector.net> <1215882276.3513.0.camel@localhost.localdomain> Message-ID: <20080712195402.4023c37f.mschwendt@gmail.com> On Sat, 12 Jul 2008 13:04:36 -0400, Matthias Clasen wrote: > On Sat, 2008-07-12 at 15:30 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 31 May 2008 at 13:02, Rawhide wrote: > > [...] > > > > Sorry to dig up old stuff, but this update > > > > > gtk2-2.13.1-2.fc10 > > > ------------------ > > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-2 > > > - Fix a problem with some pixbuf loaders > > > > > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-1 > > > - Update to 2.13.1 > > > > broke compilation of ekg2. See https://bugzilla.redhat.com/show_bug.cgi?id=449637 > > > > I finally managed to paper over the issue by adding a missing deprecated > > #define and not including a deprecated header. Looks like an incompatible > > API change in gtk2-2.13.1. I'll notify upstream about this. > > No need, I am upstream. > But it would be more helpful if you let me know what was missing, in > your opinion. For Sylpheed, including gtkclist.h breaks in gtkctree.h since gtk2-2.13.1, as something is missing. My attempt at reporting that has been bz #450266, but since it is about deprecated headers and gtk2-2.13.2 changed the stuff even further, I closed the ticket when I found a work-around. That work-around is to include gtk.h which includes _all_ headers including the deprecated ones. What exactly is missing, I've not spent time on finding out. From dledford at redhat.com Sat Jul 12 18:30:45 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 14:30:45 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215884435.14579.36.camel@weaponx> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> Message-ID: <1215887445.3687.244.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 13:40 -0400, Josh Boyer wrote: > > I'm *making* the time...around my day job. > > Most of the Fedora contributors do that. OK, how about I clarify that a bit. I'm making time around my day job because I can *at the moment*. If I were to put things off to F11, there is a good chance that when F11 is in development, I may be tied up elsewhere. So I really would like to move forward now, just because now is when I can. > > But more recently, I spent 20 or 30 minutes listening to Mark Webbink > > talk legal issues at the Raleigh FUDCon, and during that talk someone > > asked a question (someone who was kinda upset at the time). The > > question/accusation kinda went something like this: "Fedora introduced > > this new thing, fedora spins, and they helped me easily make my own > > spin, but now they expect me to carry both it and all the sources > > myself. What kind of loyalty does this show to the community that > > *makes* Fedora that you won't support them on this sort of stuff and you > > leave them hanging out to dry." > > As a side bar, we need to figure out a way to do a better recap of > FUDCon. People's blogs and personal recaps are great, but this seems > like a pretty important topic and I don't recall it being discussed or > recapped anywhere. (Please someone correct me if I'm wrong and I missed > it.) > > > After the talk was over I spent some time talking to Jesse where I > > pointed out to him that if you did away with the look aside cache for > > tarballs, and instead used exploded source in a repo, that you could in > > fact add new branches onto a repo for essentially zero cost and those > > branches could be what's used by people to make spins. That in this way > > we could, for next to no additional burden, carry their sources for them > > to satisfy the GPL and to allow them to more readily create and > > distribute spins. Obviously, this hasn't gone anywhere since then. > > This is the first time I've heard that benefit. It seems like a fairly > good one. I thought so. > > > to rework > > > our entire infrastructure to deal with a new SCM for _packages_ so that > > > people can do code _development_ on them when that should all be done > > > _upstream_. > > > > The distinction between upstream development and Fedora development is > > artificial. And it's a nice way to keep upstream developers from having > > any interest in managing their own packages. Congratulations on that. > > In many cases upstream and Fedora are synonymous (anaconda, pungi, yum, > etc). In many cases they aren't. > > And we _do_ have upstream maintainers packaging for Fedora. The CVS > package repo we have is not that large of a burden. Maybe not, but neither is standing on one foot and chanting "ooga booga" while kicking of koji builds. Being a small burden does not excuse requiring something that's unnecessary, or worse yet, counterproductive. > Your argument about > that is about as effective as saying RPM is the reason upstream doesn't > package for Fedora because they mostly use Debian or Ubuntu, which are > apt based. There is truth in it, but it is not an "OMG the sky is > falling" situation. You're right, it's not an OMG the sky is falling thing. It's an efficiency thing. Just as someone at one time pointed out that the design of the poll syscall meant the kernel implementation was horribly inefficient and so they lobbied for and eventually got epoll accepted, this is the same thing. My profile runs are showing we are wasting valuable time where we don't need to and where there are better ways of doing things, and I'm lobbying for it. > > So, as long as Red Hat and Fedora > > intend to share technology in this area, then I would suggest that Red > > Hat not block Fedora's needs, and likewise Fedora shouldn't actively > > block Red Hat's needs, especially on the basis of artificial maxims that > > aren't even true. > > This is very simple. Nobody is blocking anything. No, no...let's keep things very clear on the issues here. I haven't heard back from Panu on my last mail to him, but prior to that, I *have* been told things are blocked (specifically the rpm headers needed to proceed). > All you have to do > is actually start doing something instead of telling everyone that you > are going to do something and you'll make progress. Jesse had a git > repo at one time of Fedora. You might be able to leverage that work as > a starting point. > > > > Again, scratch your own itch if it's bothering you that badly. > > > > Isn't that what I've been saying I want to do? > > Yes. So do it, and stop saying it? I have weekly status reports I have to turn in, and I have to answer for where I spend my time. That means if I spend a lot of time on a project that ends up getting thrown away because people told me I was blocked and I didn't listen, then I have to answer for that. > Places to start: > Need the rpm changes before koji. > 1) Koji > 2) Bodhi > 3) The Makefiles in the SCM > 4) Jesse's git import of Fedora I'm not looking for anyone to do a damn thing really, but I am interested in making sure people will stay out of my way while I get things done. So far, I've been told F10 is a non-starter (by one person), but more importantly, as you point out above there would need to be changes in koji, bodhi, the official fedora SCM server(s), etc. Even if I thought Panu would take the header changes and any other possible things I might do to RPM, if the other people who control these other items of Fedora infrastructure are dead set against this type of work, then it's a waste of my time to futz around with it unless I'm willing to fork my own distro. The responses I've gotten so far have not made me inclined to think the powers that be will even look at things, but I could be wrong. However, a flat statement that they would look at things would go a long way towards eliminating any misunderstandings and would end this entire thread because I would just go off and get started on my own and come back when I have something to hand over. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 bpepple at fedoraproject.org Sat Jul 12 18:58:08 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 12 Jul 2008 14:58:08 -0400 Subject: [Final Reminder] FESCo Election Nominations Message-ID: <1215889088.1374.1.camel@kennedy> Hi all, This is the last reminder that the nomination period for the upcoming FESCo election is currently underway, and lasts until July 13th, 2008 0:00 UTC. If you wish to run for FESCo, please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Sat Jul 12 19:00:47 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 12 Jul 2008 21:00:47 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215887445.3687.244.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> Message-ID: <1215889247.25351.8.camel@rousalka.okg> Le samedi 12 juillet 2008 ? 14:30 -0400, Doug Ledford a ?crit : > Even if I thought Panu would take the header changes and any other > possible things I might do to RPM, if the other people who control these > other items of Fedora infrastructure are dead set against this type of > work, then it's a waste of my time to futz around with it unless I'm > willing to fork my own distro. The responses I've gotten so far have > not made me inclined to think the powers that be will even look at > things, but I could be wrong. As Jesse Keating tried to tell you, the reality is that the owerwhelming majority of the code we package is not pure VCS dumps, because upstreams massage their files manually before doing official releases, so being able to base a package on a precise tar.gz as posted on upstream's homepage is a hard requirement. As long as your system can take this into account I don't think anyone would mind having a more modern way to manage the stuff we put around this upstream archive. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dominik at greysector.net Sat Jul 12 19:09:16 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 12 Jul 2008 21:09:16 +0200 Subject: rawhide report: 20080531 changes In-Reply-To: <1215882276.3513.0.camel@localhost.localdomain> References: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> <20080712133048.GA3131@mokona.greysector.net> <1215882276.3513.0.camel@localhost.localdomain> Message-ID: <20080712190916.GC3131@mokona.greysector.net> On Saturday, 12 July 2008 at 19:04, Matthias Clasen wrote: > On Sat, 2008-07-12 at 15:30 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 31 May 2008 at 13:02, Rawhide wrote: > > [...] > > > > Sorry to dig up old stuff, but this update > > > > > gtk2-2.13.1-2.fc10 > > > ------------------ > > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-2 > > > - Fix a problem with some pixbuf loaders > > > > > > * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-1 > > > - Update to 2.13.1 > > > > broke compilation of ekg2. See https://bugzilla.redhat.com/show_bug.cgi?id=449637 > > > > I finally managed to paper over the issue by adding a missing deprecated > > #define and not including a deprecated header. Looks like an incompatible > > API change in gtk2-2.13.1. I'll notify upstream about this. > > No need, I am upstream. I meant ekg2 upstream, since they're using obsolete API and headers. > But it would be more helpful if you let me know what was missing, in > your opinion. ekg2 source used below is here: http://pl.ekg2.org/ekg2-0.2-rc1.tar.gz The ekg2-devel archives seem to be down, so I'll just post the compilation errors here (edited out some #warnings for readability): /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DDATADIR=\"/usr/share/ekg2\" -fvisibility=hidden -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -std=c99 -MT gtk_la-maingui.lo -MD -MP -MF .deps/gtk_la-maingui.Tpo -c -o gtk_la-maingui.lo `test -f 'maingui.c' || echo './'`maingui.c gcc -DHAVE_CONFIG_H -I. -I../.. -DDATADIR=\"/usr/share/ekg2\" -fvisibility=hidden -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -std=c99 -MT gtk_la-maingui.lo -MD -MP -MF .deps/gtk_la-maingui.Tpo -c maingui.c -fPIC -DPIC -o .libs/gtk_la-maingui.o In file included from maingui.c:78: xtext.h:243: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_xtext_get_type' maingui.c: In function 'mg_populate': maingui.c:686: warning: implicit declaration of function 'gtk_xtext_get_type' make[1]: *** [gtk_la-maingui.lo] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/ekg2-0.2-rc1/plugins/gtk' make: *** [all] Error 2 The missing typedef GType GtkType; is under #ifndef GTK_DISABLE_DEPRECATED in . After re-adding the missing typedef, the next error: /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DDATADIR=\"/usr/share/ekg2\" -fvisibility=hidden -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -std=c99 -MT gtk_la-gtkutil.lo -MD -MP -MF .deps/gtk_la-gtkutil.Tpo -c -o gtk_la-gtkutil.lo `test -f 'gtkutil.c' || echo './'`gtkutil.c gcc -DHAVE_CONFIG_H -I. -I../.. -DDATADIR=\"/usr/share/ekg2\" -fvisibility=hidden -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -std=c99 -MT gtk_la-gtkutil.lo -MD -MP -MF .deps/gtk_la-gtkutil.Tpo -c gtkutil.c -fPIC -DPIC -o .libs/gtk_la-gtkutil.o In file included from /usr/include/gtk-2.0/gtk/gtk.h:222, from /usr/include/gtk-2.0/gtk/gtksignal.h:33, from /usr/include/gtk-2.0/gtk/gtkclist.h:35, from gtkutil.c:30: /usr/include/gtk-2.0/gtk/gtkctree.h:110: error: expected specifier-qualifier-list before 'GtkCList' /usr/include/gtk-2.0/gtk/gtkctree.h:127: error: expected specifier-qualifier-list before 'GtkCListClass' /usr/include/gtk-2.0/gtk/gtkctree.h:149: error: expected specifier-qualifier-list before 'GtkCListRow' /usr/include/gtk-2.0/gtk/gtkctree.h:342: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gtk_ctree_node_get_cell_type' gtkutil.c: In function 'gtkutil_button': gtkutil.c:365: warning: comparison with string literal results in unspecified behavior make[1]: *** [gtk_la-gtkutil.lo] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/ekg2-0.2-rc1/plugins/gtk' make: *** [all] Error 2 This one is fixed by removing #include . Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dledford at redhat.com Sat Jul 12 19:31:07 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 15:31:07 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215889247.25351.8.camel@rousalka.okg> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> Message-ID: <1215891067.3687.263.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 21:00 +0200, Nicolas Mailhot wrote: > Le samedi 12 juillet 2008 ? 14:30 -0400, Doug Ledford a ?crit : > > > Even if I thought Panu would take the header changes and any other > > possible things I might do to RPM, if the other people who control these > > other items of Fedora infrastructure are dead set against this type of > > work, then it's a waste of my time to futz around with it unless I'm > > willing to fork my own distro. The responses I've gotten so far have > > not made me inclined to think the powers that be will even look at > > things, but I could be wrong. > > As Jesse Keating tried to tell you, the reality is that the owerwhelming > majority First, before I respond to the rest of this, keep in mind that the "overwhelming majority" of packages needs to be quantified. Furthermore, at least one very significant package (the kernel) does not massage files at all between SCM tag and tarball. And to be honest, I would be very surprised to find many projects that do have any significant difference between a tagged release in the SCM of their choice and their tarballs. So I would like some examples please, which shouldn't be hard to come up with since it is the "overwhelming majority" of projects that obviously think when they tag something in their SCM it doesn't need to match the tarball they make with the same tag version... > of the code we package is not pure VCS dumps, because upstreams > massage their files manually before doing official releases, so being > able to base a package on a precise tar.gz as posted on upstream's > homepage is a hard requirement. No, it's a *policy* that we base things on a precise tarball on some web/ftp server. It's a policy that is no better or worse than basing a package on a precise tagged source version in an SCM. And to be honest, I couldn't care less if upstream's tarball and their SCM version match or not. It's not important that they match, it's important that we pick one to be canonical, that we make our choice of which is canonical clear and apparent to everyone, and then we use that source consistently within that package. That's all that matters. Claiming that a precise tar.gz is a hard requirement is patently fallacious. It's currently a hard requirement *solely* because we haven't integrated cloned SCM repo support in Fedora yet, and since we are talking about implementing exactly that support, it negates this "hard" requirement. > As long as your system can take this into account I don't think anyone > would mind having a more modern way to manage the stuff we put around > this upstream archive. Sorry, but if I do the work, then I'm writing it to eliminate the tarball. You don't have to switch your package to this new method if you don't wish, but I'll be switching my packages over and they will never touch a tarball again. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 tcallawa at redhat.com Sat Jul 12 13:17:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 12 Jul 2008 09:17:55 -0400 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <1215851623.2853.3.camel@localhost.localdomain> References: <1215851623.2853.3.camel@localhost.localdomain> Message-ID: <1215868675.10539.81.camel@localhost.localdomain> On Sat, 2008-07-12 at 11:33 +0300, Nikolay Ulyanitsky wrote: > Hi > > Are source rpm packages (or spec files + patches without source files) > for binary java packages from RHEL Supplementary CD (v. 5 for 32-bit > x86) (rhel-5.2-server-supplementary-i386-disc1.iso) available for free > download? > > Some java packages from RHEL Supplementary CD (v. 5 for 32-bit x86): > java-1.4.2-*.rpm > java-1.5.0-*.rpm > java-1.6.0-*.rpm It's way off topic for this list, but I think those are the packaged version of the IBM and Sun JREs, for which no source is available. ~spot From lesmikesell at gmail.com Sat Jul 12 19:38:17 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 12 Jul 2008 14:38:17 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215862943.14579.24.camel@weaponx> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> Message-ID: <48790829.8020008@gmail.com> Josh Boyer wrote: > >>>> Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of >>>> *any* activity of any sort there...makes a nice example of just how >>>> broken and disconnected from modern SCM management our system currently >>>> is. >>> That's right, we wouldn't want to see inflight development in the HEAD >>> of our package source control. That rapidly gets in the way of doing >>> mass rebuilds, scripted code compliance tests, targeted fixes strikes, >>> etc, etc... >>> >>> Our package SCM is not a software development SCM. >> Because you are not being in the least bit imaginative with branches >> does not in the least justify the statement you are making. > > OK, how about this: > > Nobody has the time nor has anyone shown overwhelming benefits to rework > our entire infrastructure to deal with a new SCM for _packages_ so that > people can do code _development_ on them when that should all be done > _upstream_. Distributed SCMs don't change where the development work happens, they just eliminate much of the grunge work of picking up new changes along with the need to store a million point-in-time snapshot copies. -- Les Mikesell lesmikesell at gmail.com From jos at xos.nl Sat Jul 12 19:44:07 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Jul 2008 21:44:07 +0200 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <1215868675.10539.81.camel@localhost.localdomain> References: <1215851623.2853.3.camel@localhost.localdomain> <1215868675.10539.81.camel@localhost.localdomain> Message-ID: <20080712194407.GA3758@jasmine.xos.nl> On Sat, Jul 12, 2008 at 09:17:55AM -0400, Tom spot Callaway wrote: > It's way off topic for this list, but I think those are the packaged > version of the IBM and Sun JREs, for which no source is available. He was asking for nosrc.rpm's. It would be nice of RH would provide the nosrc.rpm's for the non-free additional packages. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mschwendt at gmail.com Sat Jul 12 20:09:27 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 12 Jul 2008 22:09:27 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215891067.3687.263.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> Message-ID: <20080712220927.fc9c9e52.mschwendt@gmail.com> On Sat, 12 Jul 2008 15:31:07 -0400, Doug Ledford wrote: > First, before I respond to the rest of this, keep in mind that the > "overwhelming majority" of packages needs to be quantified. > Furthermore, at least one very significant package (the kernel) does not > massage files at all between SCM tag and tarball. And to be honest, I > would be very surprised to find many projects that do have any > significant difference between a tagged release in the SCM of their > choice and their tarballs. So I would like some examples please, which > shouldn't be hard to come up with since it is the "overwhelming > majority" of projects that obviously think when they tag something in > their SCM it doesn't need to match the tarball they make with the same > tag version... Audacity is one example. They even include stuff in their cvs which would be illegal for Fedora to distribute. On the contrary, their tarballs are customised and stripped down to whatever they choose to ship. For other projects one cannot build from a scm checkout without running scripts, such as autogen.sh where one would need to reproduce the upstream development env. From jkeating at redhat.com Sat Jul 12 20:09:56 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 12 Jul 2008 16:09:56 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215873360.3687.213.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> Message-ID: <1215893396.3224.51.camel@localhost.localdomain> On Sat, 2008-07-12 at 10:36 -0400, Doug Ledford wrote: > After the talk was over I spent some time talking to Jesse where I > pointed out to him that if you did away with the look aside cache for > tarballs, and instead used exploded source in a repo, that you could in > fact add new branches onto a repo for essentially zero cost and those > branches could be what's used by people to make spins. That in this way > we could, for next to no additional burden, carry their sources for them > to satisfy the GPL and to allow them to more readily create and > distribute spins. Obviously, this hasn't gone anywhere since then. I think you misunderstood the problem. We already keep around the sources on our servers for eons and anybody can get to them. The problem surrounds actual distribution, IE handing you an CD/DVD of binary rpms. I either have to offer you a CD/DVD of corresponding sources in format, or provide you a written offer to provide the above that is good for the next 3 years, or pass along such written offer that I myself may have gotten. Nobody has confirmed nor denied what that means, nor how long the 3year clock ticks on those formats, and whether or not directions on how to get the source from our public source repo is OK. We don't need any special changes to our source control system, other than the fact that our tags are mutable, but one can go back as far as our merged core/extras Fedora world goes and recreate sourcerpms which contain the verifiable upstream source and any of our patches that went on top of it, and a reasonable build script for re-generating the binary. The problem really lies with whether or not this would satisfy, as a written offer, the requirements under which we distribute or ask our ambassadors to distribute our binaries. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 smooge at gmail.com Sat Jul 12 20:11:18 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 12 Jul 2008 14:11:18 -0600 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <20080712194407.GA3758@jasmine.xos.nl> References: <1215851623.2853.3.camel@localhost.localdomain> <1215868675.10539.81.camel@localhost.localdomain> <20080712194407.GA3758@jasmine.xos.nl> Message-ID: <80d7e4090807121311k3f55e7e3o120466291d9b0755@mail.gmail.com> On Sat, Jul 12, 2008 at 1:44 PM, Jos Vos wrote: > On Sat, Jul 12, 2008 at 09:17:55AM -0400, Tom spot Callaway wrote: > >> It's way off topic for this list, but I think those are the packaged >> version of the IBM and Sun JREs, for which no source is available. > > He was asking for nosrc.rpm's. It would be nice of RH would provide > the nosrc.rpm's for the non-free additional packages. > In the old days, the upstreams just handed RH the .rpms but that might have changed in the last 8 years :) -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Sat Jul 12 20:15:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 12 Jul 2008 16:15:13 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215871445.3687.190.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> <1215871445.3687.190.camel@firewall.xsintricity.com> Message-ID: <1215893713.3224.54.camel@localhost.localdomain> On Sat, 2008-07-12 at 10:04 -0400, Doug Ledford wrote: > Wasn't subscribed in December (recently added a number of fedora > subscriptions to me email load). My day job is on RHEL and I'm *making* > time for Fedora...back then I didn't need the additional email load. Are you subscribed to the internal Red Hat lists where this was announced as well? It's not like we've been quiet about it. Head in the sand rational doesn't really work. However, as fun as it is to pick on Doug for not noticing rpm advancements, that just derails the conversation from what's really important, actual thoughtful discussion about the future of our SCM system. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 tcallawa at redhat.com Sat Jul 12 20:34:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 12 Jul 2008 16:34:09 -0400 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <20080712194407.GA3758@jasmine.xos.nl> References: <1215851623.2853.3.camel@localhost.localdomain> <1215868675.10539.81.camel@localhost.localdomain> <20080712194407.GA3758@jasmine.xos.nl> Message-ID: <1215894849.10539.84.camel@localhost.localdomain> On Sat, 2008-07-12 at 21:44 +0200, Jos Vos wrote: > On Sat, Jul 12, 2008 at 09:17:55AM -0400, Tom spot Callaway wrote: > > > It's way off topic for this list, but I think those are the packaged > > version of the IBM and Sun JREs, for which no source is available. > > He was asking for nosrc.rpm's. It would be nice of RH would provide > the nosrc.rpm's for the non-free additional packages. I honestly have no visibility into that process, but it shouldn't be much different from downloading whatever is available on Sun or IBM's website. ~spot From lystor at lystor.org.ua Sat Jul 12 21:09:46 2008 From: lystor at lystor.org.ua (Nikolay Ulyanitsky) Date: Sun, 13 Jul 2008 00:09:46 +0300 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <1215894849.10539.84.camel@localhost.localdomain> References: <1215851623.2853.3.camel@localhost.localdomain> <1215868675.10539.81.camel@localhost.localdomain> <20080712194407.GA3758@jasmine.xos.nl> <1215894849.10539.84.camel@localhost.localdomain> Message-ID: <1215896986.4965.0.camel@lystor.users.home.lystor.org.ua> > I honestly have no visibility into that process, but it shouldn't be > much different from downloading whatever is available on Sun or IBM's > website. I think the base of java binary packages from RHEL Supplementary CD are nosrc.rpms from jpackage.org (packages have many common entries in changelogs). But RHEL java packages have additional bug fixes which are absent in jpackage.org (information from changelogs). Installing original Java packages from Sun or IBM is not recommended (https://fedoraproject.org/wiki/JavaFAQ), because they do not support alternatives and installed to non-standard locations in file system. -- Nikolay Ulyanitsky From lesmikesell at gmail.com Sat Jul 12 21:18:50 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 12 Jul 2008 16:18:50 -0500 Subject: Source rpms for RHEL Supplementary CD java packages In-Reply-To: <1215894849.10539.84.camel@localhost.localdomain> References: <1215851623.2853.3.camel@localhost.localdomain> <1215868675.10539.81.camel@localhost.localdomain> <20080712194407.GA3758@jasmine.xos.nl> <1215894849.10539.84.camel@localhost.localdomain> Message-ID: <48791FBA.3050302@gmail.com> Tom "spot" Callaway wrote: > >> >>> It's way off topic for this list, but I think those are the packaged >>> version of the IBM and Sun JREs, for which no source is available. >> He was asking for nosrc.rpm's. It would be nice of RH would provide >> the nosrc.rpm's for the non-free additional packages. > > I honestly have no visibility into that process, but it shouldn't be > much different from downloading whatever is available on Sun or IBM's > website. > Sun's binary and RPM packages don't mesh with the alternatives system that fedora/RH use. -- Les Mikesell lesmikesell at gmail.com From siddharth at techbugs.org Sun Jul 13 00:08:28 2008 From: siddharth at techbugs.org (Siddharth Upmanyu) Date: Sun, 13 Jul 2008 05:38:28 +0530 Subject: No login after KDE 4.0.98 rawhide update Message-ID: Hi, I just updated my KDE to rawhide and i got this "Could not start ksmserver. Check your installation" how to fix this? Thanks Siddharth From dledford at redhat.com Sun Jul 13 00:10:51 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 20:10:51 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080712220927.fc9c9e52.mschwendt@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> Message-ID: <1215907851.3687.271.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 22:09 +0200, Michael Schwendt wrote: > On Sat, 12 Jul 2008 15:31:07 -0400, Doug Ledford wrote: > > > First, before I respond to the rest of this, keep in mind that the > > "overwhelming majority" of packages needs to be quantified. > > Furthermore, at least one very significant package (the kernel) does not > > massage files at all between SCM tag and tarball. And to be honest, I > > would be very surprised to find many projects that do have any > > significant difference between a tagged release in the SCM of their > > choice and their tarballs. So I would like some examples please, which > > shouldn't be hard to come up with since it is the "overwhelming > > majority" of projects that obviously think when they tag something in > > their SCM it doesn't need to match the tarball they make with the same > > tag version... > > Audacity is one example. They even include stuff in their cvs which would > be illegal for Fedora to distribute. Fair enough. That's one. And I'm sure that of the audio/video players, there will be a number that have unshipable stuff in their CVS or whatever repos. So in our clone of the upstream repo we would remove that stuff and go from there. > On the contrary, their tarballs are > customised and stripped down to whatever they choose to ship. Presumably one could replicate this as needed. However, there is the question of whether or not it's needed. Remember that the concept using an upstream tarball as the canonical source version that we represent to the world that we are using is nothing more than a policy decision. Nothing in the GPL or anything else said we had to do that, it was just what we *chose* to do (long, long ago, in a galaxy far, far away). It is just as legitimate to say we are going to use tagged checkouts from their SCM (or clones if they have a distributed SCM) and provide a means of verification that we have done so. It's all just policy, and we are free to set policy as we see fit within the guidelines of meeting our obligations under the GPL. > For other > projects one cannot build from a scm checkout without running scripts, > such as autogen.sh where one would need to reproduce the upstream > development env. Where is the reference on that BTW. There was a time in the past when someone asked me what they should do before generating their tarballs and I told them to just tar it up and go, and I had every intention of running autogen.sh myself during the build process. Then someone told me "No, they need to run autogen.sh before they make the tarball". So, why is that? Why shouldn't the sources be autogen'ed against our specific dev environment, after all we will be the ones building our rpms in our build environment, so it would seem to make sense to me. Obviously I must be missing something of great importance... -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sun Jul 13 00:12:32 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 20:12:32 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215893396.3224.51.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> Message-ID: <1215907952.3687.274.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: > On Sat, 2008-07-12 at 10:36 -0400, Doug Ledford wrote: > > After the talk was over I spent some time talking to Jesse where I > > pointed out to him that if you did away with the look aside cache for > > tarballs, and instead used exploded source in a repo, that you could in > > fact add new branches onto a repo for essentially zero cost and those > > branches could be what's used by people to make spins. That in this way > > we could, for next to no additional burden, carry their sources for them > > to satisfy the GPL and to allow them to more readily create and > > distribute spins. Obviously, this hasn't gone anywhere since then. > > I think you misunderstood the problem. We already keep around the > sources on our servers for eons and anybody can get to them. The > problem surrounds actual distribution, IE handing you an CD/DVD of > binary rpms. I either have to offer you a CD/DVD of corresponding > sources in format, or provide you a > written offer to provide the above that is good for the next 3 years, or > pass along such written offer that I myself may have gotten. Nobody has > confirmed nor denied what that means, nor > how long the 3year clock ticks on those formats, and whether or not > directions on how to get the source from our public source repo is OK. > We don't need any special changes to our source control system, other > than the fact that our tags are mutable, but one can go back as far as > our merged core/extras Fedora world goes and recreate sourcerpms which > contain the verifiable upstream source and any of our patches that went > on top of it, and a reasonable build script for re-generating the > binary. > > The problem really lies with whether or not this would satisfy, as a > written offer, the requirements under which we distribute or ask our > ambassadors to distribute our binaries. OK, well regardless, if this meets the requirements, then certainly an immutably tagged exploded SCM would too (for far less space requirements than all those tarballs in the look aside cache), and my point still stands that it would be cheaper to allow people to hang their spin sources inside our SCMs when using exploded source and branches than the current way. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sun Jul 13 00:20:04 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 20:20:04 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215893713.3224.54.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> <1215871445.3687.190.camel@firewall.xsintricity.com> <1215893713.3224.54.camel@localhost.localdomain> Message-ID: <1215908404.3687.282.camel@firewall.xsintricity.com> On Sat, 2008-07-12 at 16:15 -0400, Jesse Keating wrote: > On Sat, 2008-07-12 at 10:04 -0400, Doug Ledford wrote: > > Wasn't subscribed in December (recently added a number of fedora > > subscriptions to me email load). My day job is on RHEL and I'm *making* > > time for Fedora...back then I didn't need the additional email load. > > Are you subscribed to the internal Red Hat lists where this was > announced as well? It's not like we've been quiet about it. Head in > the sand rational doesn't really work. It's not head in the sand Jesse. It's that following the daytime soap opera that is rpm4 vs rpm5 vs jbj vs everyone else isn't the least bit worth my time. I seem to recall a vague announcement inside Red Hat that went something like "We actually are working on RPM and we have plans, we just aren't going into them at this time...stay tuned." I don't ever recall the follow up to that though... > However, as fun as it is to pick on Doug for not noticing rpm > advancements, You can try to pick on me all you want, but the simple fact of the matter is that it makes not one whit of difference to me. You won't make me feel guilty for not having the time to watch a soap opera outside the scope of my normal daytime work. > that just derails the conversation from what's really > important, actual thoughtful discussion about the future of our SCM > system. This I agree with 100%. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sun Jul 13 00:29:28 2008 From: dledford at redhat.com (Doug Ledford) Date: Sat, 12 Jul 2008 20:29:28 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> <1215826146.3687.121.camel@firewall.xsintricity.com> <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> Message-ID: <1215908968.3687.292.camel@firewall.xsintricity.com> On Fri, 2008-07-11 at 22:41 -0400, Jesse Keating wrote: > Unfortunatly I live in reality where many upstreams post process the > scm checkout so reliance on the scm alone is not possible. And this is at least partially our own fault. For instance, the fact that upstream opensm, libibcommon, libibumad, libibmad, librdmacm, libibcm, and a few others from the OFED package set run autogen.sh is because someone in Fedora told me to tell them to. I originally told them not to and I was "corrected". So it seems a bit fishy to me to use that as a reason that we can't use an SCM checkout, we created our own problem here, I would think we should be able to solve our own problem. And that gets to my next point, which really is that people are getting caught up in how things are (like processing with autogen.sh), and aren't considering if things *must* be that way. For example, you can't really clone a subversion repository. You can check it out, but commits have to go back to the central repo. This means we would have a hard time dealing with subversion upstream sources. However, as a possible policy implementation, we could contact upstream and request that the fedora package maintainers be given their own branches in the upstream repo, and that they have full write access on those branches, and the package maintainer could then merge over specific updates from the upstream primary branches into the fedora branches as we decided to upgrade to a particular release. We could then request the ability to rsync the actual repo to our own servers so we would always have our own copy should upstream decide to implode. So, there are ways we could *make* a subversion upstream work, but it's not pretty. If I were the kind of person looking for reasons to shut this idea down, I would jump on the subversion thing. On the other hand, if I'm someone were looking to make this work, they would accept that as a hurdle we can tackle on a case by case basis and that we could make it work at least some of the time. I've simply got the impression that a lot of the people jumping into this discussion are in the first group of people. I'm in the second. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jkeating at j2solutions.net Sun Jul 13 00:37:59 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 12 Jul 2008 20:37:59 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215908968.3687.292.camel@firewall.xsintricity.com> References: <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> <1215826146.3687.121.camel@firewall.xsintricity.com> <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> <1215908968.3687.292.camel@firewall.xsintricity.com> Message-ID: <9339c38c0807121737r25aed525g83e07e42f6248362@mail.gmail.com> 2008/7/12 Doug Ledford : > On Fri, 2008-07-11 at 22:41 -0400, Jesse Keating wrote: > > > Unfortunatly I live in reality where many upstreams post process the > > scm checkout so reliance on the scm alone is not possible. > > And this is at least partially our own fault. For instance, the fact > that upstream opensm, libibcommon, libibumad, libibmad, librdmacm, > libibcm, and a few others from the OFED package set run autogen.sh is > because someone in Fedora told me to tell them to. I originally told > them not to and I was "corrected". So it seems a bit fishy to me to use > that as a reason that we can't use an SCM checkout, we created our own > problem here, I would think we should be able to solve our own problem. > > And that gets to my next point, which really is that people are getting > caught up in how things are (like processing with autogen.sh), and > aren't considering if things *must* be that way. For example, you can't > really clone a subversion repository. You can check it out, but commits > have to go back to the central repo. This means we would have a hard > time dealing with subversion upstream sources. However, as a possible > policy implementation, we could contact upstream and request that the > fedora package maintainers be given their own branches in the upstream > repo, and that they have full write access on those branches, and the > package maintainer could then merge over specific updates from the > upstream primary branches into the fedora branches as we decided to > upgrade to a particular release. We could then request the ability to > rsync the actual repo to our own servers so we would always have our own > copy should upstream decide to implode. So, there are ways we could > *make* a subversion upstream work, but it's not pretty. > > If I were the kind of person looking for reasons to shut this idea down, > I would jump on the subversion thing. On the other hand, if I'm someone > were looking to make this work, they would accept that as a hurdle we > can tackle on a case by case basis and that we could make it work at > least some of the time. I've simply got the impression that a lot of > the people jumping into this discussion are in the first group of > people. I'm in the second. > I'm not necessarily trying to shut it down, but I need something that works with the lowest common demoninator, without causing a lot of confusion and complication when trying to do something across a number of packages. I don't want maintainers to "guess" at how to do things, and I certainly don't want doing package updates to be bandwidth prohibitive to people. The fact that our package scm right now consists of a spec file, maybe a patch or two, and a file that references the actual source means it's an extremely small checkout to deal with when needing to update. If we were making people clone the entire source, including all the history from upstreams, that's going to be pretty prohibitive. Tried cloning the anaconda git repo lately? I'm really happy to see thought in this area, and I certainly need to drop the requirements/wishes/hates of the current/ list that I got from FUDCon into the wiki somewhere, so that when people are having these thoughts they can have a set of constraints to deal with. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Sun Jul 13 00:43:35 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 12 Jul 2008 20:43:35 -0400 Subject: koji rawhide ppc64 build failing due to strange error? In-Reply-To: References: <4877AA4F.3010207@ioa.s.u-tokyo.ac.jp> <20080711192734.GB17243@nostromo.devel.redhat.com> <1215805184.3224.24.camel@localhost.localdomain> Message-ID: <9339c38c0807121743u3a98da4fwa40dbf316c501e86@mail.gmail.com> On Sat, Jul 12, 2008 at 11:26 AM, Panu Matilainen wrote: > On Fri, 11 Jul 2008, Jesse Keating wrote: > > On Fri, 2008-07-11 at 15:27 -0400, Bill Nottingham wrote: >> >>> Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) said: >>> >>>> After koji began to accept jobs again, all dist-f10 ppc64 builds seem >>>> to be failing due to some strange error? >>>> >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710447 >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710455 >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=710471 >>>> >>>> None of them have build.log and root.log say: >>>> >>>> DEBUG util.py:272: Executing command: ['rpm', '-Uvh', '--nodeps', >>>> '/builddir/build/originals/xscreensaver-5.05.90.3-3.fc10.src.rpm'] >>>> DEBUG util.py:250: memory alloc (41 bytes) returned NULL. >>>> >>>> Would someone investigate what is happening here? >>>> >>> >>> Almost certianly the new rpm broke. >>> >>> Bill >>> >> >> Yeah, that's coming from rpm in the chroot. I can easily reproduce. >> I'm going to untag the new rpm until we sort this out. It'll be a bit >> before builds start working again. >> > > Ok, take two, build just completed. The ppc64 issue should be gone, at > least things work on in mock. Hopefully it lasts in the builders a bit > longer than previous try ;) but if it causes troubles, just untag it and let > me know... > A number of builds have gone through successfully, including ppc64 variants. Things are looking good so far.... It'll be interesting to see what happens with the composed rawhide tree tomorrow. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sun Jul 13 00:45:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 13 Jul 2008 00:45:54 +0000 (UTC) Subject: No login after KDE 4.0.98 rawhide update References: Message-ID: Siddharth Upmanyu techbugs.org> writes: > "Could not start ksmserver. Check your installation" > > how to fix this? Wait for tomorrow's Rawhide or fetch the fixed build from Koji. http://koji.fedoraproject.org/koji/taskinfo?taskID=712168 Kevin Kofler From arjan at infradead.org Sun Jul 13 00:49:16 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sat, 12 Jul 2008 17:49:16 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215907851.3687.271.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> Message-ID: <20080712174916.0b9fff00@infradead.org> On Sat, 12 Jul 2008 20:10:51 -0400 > Presumably one could replicate this as needed. However, there is the > question of whether or not it's needed. Remember that the concept > using an upstream tarball as the canonical source version that we > represent to the world that we are using is nothing more than a > policy decision. Nothing in the GPL or anything else said we had to > do that, it was just what we *chose* to do (long, long ago, in a > galaxy far, far away). one thing to keep in mind... as comparison, what you don't want is what Ubuntu is doing with their kernel (clone Linus and then just edit the source tree); it's just one big nightmare (as you can imagine). Keeping upstream source and local patches separate is a clear winner (anyone who has worked on the alternative will agree with me). If those upstream sources are a tarbal, or a tagged commit... is a lot less relevant. From darrellpf at gmail.com Sun Jul 13 00:57:54 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 12 Jul 2008 17:57:54 -0700 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: References: Message-ID: On Sat, Jul 12, 2008 at 17:45, Kevin Kofler wrote: > Siddharth Upmanyu techbugs.org> writes: > > "Could not start ksmserver. Check your installation" > > > > how to fix this? > > Wait for tomorrow's Rawhide or fetch the fixed build from Koji. > http://koji.fedoraproject.org/koji/taskinfo?taskID=712168 > > One more question, if you don't mind. My KDE won't start because it can't talk to dbus. I've googled but can't find the magic that allows it to start. Since others in rawhide don't seem to be having the problem, I'm assuming it is specific to when I happened to upgrade/install it. thanks... darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sun Jul 13 01:01:27 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 13 Jul 2008 01:01:27 +0000 (UTC) Subject: No login after KDE 4.0.98 rawhide update References: Message-ID: darrell pfeifer gmail.com> writes: > One more question, if you don't mind. > My KDE won't start because it can't talk to dbus. How exactly are you starting KDE? Through KDM? GDM? Some other display manager? Old-fashioned startx? Kevin Kofler From darrellpf at gmail.com Sun Jul 13 01:06:32 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 12 Jul 2008 18:06:32 -0700 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: References: Message-ID: On Sat, Jul 12, 2008 at 18:01, Kevin Kofler wrote: > darrell pfeifer gmail.com> writes: > > One more question, if you don't mind. > > My KDE won't start because it can't talk to dbus. > > How exactly are you starting KDE? Through KDM? GDM? Some other display > manager? > Old-fashioned startx? > > I've been selecting it through gdm. That worked for the original 4.0 release in rawhide, then it broke at some point with one of the subsequent upgrades. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at users.sourceforge.net Sun Jul 13 01:10:43 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 12 Jul 2008 18:10:43 -0700 Subject: How to handle soname bump properly? In-Reply-To: (Peter Lemenkov's message of "Sat\, 12 Jul 2008 19\:30\:55 +0400") References: <20080712152448.GS7900@inocybe.teonanacatl.org> Message-ID: >>>>> "PL" == Peter Lemenkov writes: PL> 2008/7/12, Todd Zullinger : >> Peter Lemenkov wrote: >> > Consider, we got library libfoo and dependent utility bar. >> > >> > If I updated library libfoo (successfully built with soname > >> increased, and ready to hit updates-testing via Bodhi), then how > >> should I udate bar? >> This is something that requires some help from rel-eng. You would >> build libfoo and then mail rel-eng at fedoraproject.org asking for a >> build root override for libfoo (providing the full n-e-v-r or cvs >> tag for the libfoo build you want to be in the build root) and >> often some brief justification for the request (like, "I need this >> to build bar against in order to fix outstanding bugs"). >> >> They sprinkle some pixie dust and let you know when it's done. >> Then you can build bar against the new libfoo and push both of them >> as a single update to updates-testing via bodhi. >> >> (Of course, you should already have done some testing of this in >> rawhide and locally for the affected stable release and thought >> hard about whether a soname bump in the stable release warranted -- >> that the benefits of the bump outweigh the drawbacks.) PL> Thanks! Do you mind if I grab your post (partially) and bury it PL> in Swamps of Fedora-Wiki? It is already documented: http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides although that page is buried in a somewhat obscure place that a casual package maintainer would probably not know to look there. It should probably linked from somewhere in the PackageMaintainers namespace with a higher-level explanation like the text above. This kind of thing might be useful for the PackageMaintainers Tips/Tricks page which I can't seem to locate the URL for right now (it isn't linked from http://fedoraproject.org/wiki/PackageMaintainers) As Todd said, you should request the buildroot override *before* you push any packages to updates-testing so you can do them as a single update. That way prevents broken deps which should be discouraged even in updates-testing. Alex From siddharth at techbugs.org Sun Jul 13 01:32:51 2008 From: siddharth at techbugs.org (Siddharth Upmanyu) Date: Sun, 13 Jul 2008 07:02:51 +0530 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: References: Message-ID: 2008/7/13 darrell pfeifer : > > > On Sat, Jul 12, 2008 at 17:45, Kevin Kofler wrote: >> >> Siddharth Upmanyu techbugs.org> writes: >> > "Could not start ksmserver. Check your installation" >> > >> > how to fix this? >> >> Wait for tomorrow's Rawhide or fetch the fixed build from Koji. >> http://koji.fedoraproject.org/koji/taskinfo?taskID=712168 >> > > One more question, if you don't mind. > > My KDE won't start because it can't talk to dbus. I've googled but can't > find the magic that allows it to start. > > Since others in rawhide don't seem to be having the problem, I'm assuming it > is specific to when I happened to upgrade/install it. > :-) big assumption... i dont think rawhide is supposed to work (just-work) i cant launch dolphin after logging in (if you wanted to know) > thanks... > > darrell > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jkeating at j2solutions.net Sun Jul 13 03:19:08 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 12 Jul 2008 23:19:08 -0400 Subject: How to handle soname bump properly? In-Reply-To: References: <20080712152448.GS7900@inocybe.teonanacatl.org> Message-ID: <9339c38c0807122019s470a396aref17aac97d0e72f3@mail.gmail.com> On Sat, Jul 12, 2008 at 9:10 PM, Alex Lancaster wrote: > >>>>> "PL" == Peter Lemenkov writes: > > PL> 2008/7/12, Todd Zullinger : > >> Peter Lemenkov wrote: > >> > Consider, we got library libfoo and dependent utility bar. > >> > > >> > If I updated library libfoo (successfully built with soname > > >> increased, and ready to hit updates-testing via Bodhi), then how > > >> should I udate bar? > > >> This is something that requires some help from rel-eng. You would > >> build libfoo and then mail rel-eng at fedoraproject.org asking for a > >> build root override for libfoo (providing the full n-e-v-r or cvs > >> tag for the libfoo build you want to be in the build root) and > >> often some brief justification for the request (like, "I need this > >> to build bar against in order to fix outstanding bugs"). > >> > >> They sprinkle some pixie dust and let you know when it's done. > >> Then you can build bar against the new libfoo and push both of them > >> as a single update to updates-testing via bodhi. > >> > >> (Of course, you should already have done some testing of this in > >> rawhide and locally for the affected stable release and thought > >> hard about whether a soname bump in the stable release warranted -- > >> that the benefits of the bump outweigh the drawbacks.) > > PL> Thanks! Do you mind if I grab your post (partially) and bury it > PL> in Swamps of Fedora-Wiki? > > It is already documented: > > http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides > > although that page is buried in a somewhat obscure place that a casual > package maintainer would probably not know to look there. That's because it's a document for release engineers to use when they actually process the tagging request. It's not necessarily meant for maintainers to use, that little bit of documentation has definitely been missing for a while. > > > It should probably linked from somewhere in the PackageMaintainers > namespace with a higher-level explanation like the text above. This > kind of thing might be useful for the PackageMaintainers Tips/Tricks > page which I can't seem to locate the URL for right now (it isn't > linked from http://fedoraproject.org/wiki/PackageMaintainers) All it takes is somebody to make it happen (: -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Sun Jul 13 04:12:46 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 13 Jul 2008 00:12:46 -0400 Subject: rawhide report: 20080531 changes In-Reply-To: <20080712195402.4023c37f.mschwendt@gmail.com> References: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> <20080712133048.GA3131@mokona.greysector.net> <1215882276.3513.0.camel@localhost.localdomain> <20080712195402.4023c37f.mschwendt@gmail.com> Message-ID: <1215922366.3216.6.camel@localhost.localdomain> On Sat, 2008-07-12 at 19:54 +0200, Michael Schwendt wrote: > For Sylpheed, including gtkclist.h breaks in gtkctree.h since > gtk2-2.13.1, as something is missing. > > My attempt at reporting that has been bz #450266, but since it is about > deprecated headers and gtk2-2.13.2 changed the stuff even further, I > closed the ticket when I found a work-around. That work-around is to > include gtk.h which includes _all_ headers including the deprecated ones. Well, including gtk.h is the supported way of using gtk. But I believe that the deprecated headers can be used individually again in the current release. From aoliva at redhat.com Sun Jul 13 04:46:12 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 13 Jul 2008 01:46:12 -0300 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: <200807100124.22222.konrad@tylerc.org> (Konrad Meyer's message of "Thu\, 10 Jul 2008 01\:24\:21 -0700") References: <200807100124.22222.konrad@tylerc.org> Message-ID: On Jul 10, 2008, Konrad Meyer wrote: > Quoth Alexandre Oliva: >> On Jul 8, 2008, Greg Dekoenigsberg wrote: >> >> > -- the education of the world's children -- with the use of free >> > software as the central component of their software strategy. >> Hey, can I help by keeping their kernel free from non-Free Software? > Please stop, the horse hasn't even begun to recover yet. Why, don't you want OLPC to get its own wish of being Free Software? Or are you just arguing for us all to keep our heads in a hole pretending everything is fine, like an ostrich that will happily eat whatever it is fed? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From nicolas.mailhot at laposte.net Sun Jul 13 06:55:55 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 13 Jul 2008 08:55:55 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215891067.3687.263.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> Message-ID: <1215932155.19719.13.camel@rousalka.okg> Le samedi 12 juillet 2008 ? 15:31 -0400, Doug Ledford a ?crit : > On Sat, 2008-07-12 at 21:00 +0200, Nicolas Mailhot wrote: > > Le samedi 12 juillet 2008 ? 14:30 -0400, Doug Ledford a ?crit : > > > > > Even if I thought Panu would take the header changes and any other > > > possible things I might do to RPM, if the other people who control these > > > other items of Fedora infrastructure are dead set against this type of > > > work, then it's a waste of my time to futz around with it unless I'm > > > willing to fork my own distro. The responses I've gotten so far have > > > not made me inclined to think the powers that be will even look at > > > things, but I could be wrong. > > > > As Jesse Keating tried to tell you, the reality is that the owerwhelming > > majority > > First, before I respond to the rest of this, keep in mind that the > "overwhelming majority" of packages needs to be quantified. How about the 9/10th of packages I've been involved with since I used RHL or Fedora (I think I've passed my decade of use and packaging now)? I'll grant you a few of them are clean SCM dumps. Since I had to rewrite upstream's release script myself (and get it merged) to make sure it was always the case. > Furthermore, at least one very significant package (the kernel) does not > massage files at all between SCM tag and tarball. If you can't understand the kernel is utterly unrepresentative in so many ways that's not even funny I can do nothing for you. > And to be honest, I > would be very surprised to find many projects that do have any > significant difference between a tagged release in the SCM of their > choice and their tarballs. It does not need to be huge to cause no end of QA and maintenance problems. > So I would like some examples please, which > shouldn't be hard to come up with since it is the "overwhelming > majority" of projects that obviously think when they tag something in > their SCM it doesn't need to match the tarball they make with the same > tag version... Take ten random packages in the review queue. They need the review and you need some perspective. > > of the code we package is not pure VCS dumps, because upstreams > > massage their files manually before doing official releases, so being > > able to base a package on a precise tar.gz as posted on upstream's > > homepage is a hard requirement. > > No, it's a *policy* that we base things on a precise tarball on some > web/ftp server. If you haven't noticed yet we are choke-full of policies that could all be reverted but contribute to make life easier to packagers. > It's a policy that is no better or worse than basing a > package on a precise tagged source version in an SCM. And to be honest, > I couldn't care less if upstream's tarball and their SCM version match > or not. It's not important that they match, it's important that we pick > one to be canonical, that we make our choice of which is canonical clear > and apparent to everyone, and then we use that source consistently > within that package. That's all that matters. No. What matters is we pick the version upstream intends us to use. What matter is we pick the version upstream checked for problems before publishing (even if that involved some dirty upstream massaging) What matters is we use the same upstream version as everyone else so we benefit from the collective QA work the community does. What matters is our users know exactly what they get and not dumps of VCS soup. > Claiming that a precise > tar.gz is a hard requirement is patently fallacious. It's currently a > hard requirement *solely* because we haven't integrated cloned SCM repo > support in Fedora yet, and since we are talking about implementing > exactly that support, it negates this "hard" requirement. You've certainly lived a sheltered life with no contact with the kind of code one can find in the internet. > > As long as your system can take this into account I don't think anyone > > would mind having a more modern way to manage the stuff we put around > > this upstream archive. > > Sorry, but if I do the work, then I'm writing it to eliminate the > tarball. You don't have to switch your package to this new method if > you don't wish, but I'll be switching my packages over and they will > never touch a tarball again. If you don't want to listen, don't complain you're not heard. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From walters at verbum.org Sun Jul 13 07:03:22 2008 From: walters at verbum.org (Colin Walters) Date: Sun, 13 Jul 2008 03:03:22 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215932155.19719.13.camel@rousalka.okg> References: <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> Message-ID: 2008/7/13 Nicolas Mailhot : > > > How about the 9/10th of packages I've been involved with since I used > RHL or Fedora (I think I've passed my decade of use and packaging now)? > Part of Fedora's role in the larger Free Software community is to drive convergence and improvements in upstream projects. This manifests in various ways, such as getting projects onto the same shared library versions, etc. In this instance, if our tooling could be signinficantly improved by using revision control instead of tarballs (and I definitely believe that is the case) we can help move upstream. For example in GNOME it would not be a large workflow change to make it a hard requirement that tarball releases on ftp.gnome.org have a predictable correspondingly named SVN (or hopefully later git) tag. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Sun Jul 13 07:23:15 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 13 Jul 2008 09:23:15 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> Message-ID: <1215933795.19719.20.camel@rousalka.okg> Le dimanche 13 juillet 2008 ? 03:03 -0400, Colin Walters a ?crit : > 2008/7/13 Nicolas Mailhot : > > > > How about the 9/10th of packages I've been involved with since > I used > RHL or Fedora (I think I've passed my decade of use and > packaging now)? > > Part of Fedora's role in the larger Free Software community is to > drive convergence and improvements in upstream projects. This > manifests in various ways, such as getting projects onto the same > shared library versions, etc. In this instance, if our tooling could > be signinficantly improved by using revision control instead of > tarballs (and I definitely believe that is the case) we can help move > upstream. > > For example in GNOME it would not be a large workflow change to make > it a hard requirement that tarball releases on ftp.gnome.org have a > predictable correspondingly named SVN (or hopefully later git) tag. Given that it's a lot of work just to convince projects to have sane numbering and clear licensing, that even Red Hat (hello Liberation) has been known to release high-profile material out of a VCS, that tag move and history rewrite is rampant even in our own Fedora CVS, this seems a hopeless cause to me. You keep giving big projects with lots of resources as examples, but while a big part of the distribution, they're not all of it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mschwendt at gmail.com Sun Jul 13 08:12:57 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 13 Jul 2008 10:12:57 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215907851.3687.271.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> Message-ID: <20080713101257.2369bbd2.mschwendt@gmail.com> On Sat, 12 Jul 2008 20:10:51 -0400, Doug Ledford wrote: > > For other > > projects one cannot build from a scm checkout without running scripts, > > such as autogen.sh where one would need to reproduce the upstream > > development env. > > Where is the reference on that BTW. There was a time in the past when > someone asked me what they should do before generating their tarballs > and I told them to just tar it up and go, and I had every intention of > running autogen.sh myself during the build process. Then someone told > me "No, they need to run autogen.sh before they make the tarball". So, > why is that? Why shouldn't the sources be autogen'ed against our > specific dev environment, after all we will be the ones building our > rpms in our build environment, so it would seem to make sense to me. > Obviously I must be missing something of great importance... It's related to the reason why we have multiple auto{conf,make} versions in the distribution. You need to pick the set of tools that is compatible with the rest of the source build setup. Sometimes errors force you to run a specific older or newer(!) version than what you can choose from. Or errors make you patch the configure.{ac,in} and closely related files before you can set up the source at all. That alone may be quite some work for several projects. Further, there have been silent incompatibilities before, which break configuration of the source, because you generate a build environment which differs from upstream. The errors may be subtle, which aren't trivial to track down in thousands of generated lines of typical "configure" scripts or aclocal.m4 files. Or, what seems to autogen for you today breaks tomorrow in a completely unexpected and weird way, and at an unfortunate point of time, only because your upgraded autotools reveal a sleeping incompatibility. From rawhide at fedoraproject.org Sun Jul 13 09:02:04 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 13 Jul 2008 09:02:04 +0000 (UTC) Subject: rawhide report: 20080713 changes Message-ID: <20080713090204.79E98209D96@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080712/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080713/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gfs-eustace-fonts GFS Eustace majuscule Greek font New package gl2ps An OpenGL to PostScript printing library New package milkytracker Module tracker software for creating music Updated Packages: cairo-dock-1.6.1-0.1.svn1193_trunk.fc10 --------------------------------------- * Sun Jul 13 18:00:00 2008 Mamoru Tasaka - rev. 1193 ekg2-0.2-0.3.rc1.fc10 --------------------- * Sat Jul 12 18:00:00 2008 Dominik Mierzejewski 0.2-0.3.rc1 - fix compilation with >=gtk-2.13 - add missing defattr * Wed Jun 4 18:00:00 2008 Dominik Mierzejewski 0.2-0.2.rc1 - fix No UI-PLUGIN problem (patch from upstream) fuse-2.7.3-3.fc10 ----------------- * Sat Jul 12 18:00:00 2008 Peter Lemenkov 2.7.3-3 - Fixed initscripts (BZ#441284) gc-7.1-2.fc10 ------------- * Sat Jul 12 18:00:00 2008 Rex Dieter 7.1-2 - --enable-large-config (#453972) gdb-6.8-15.fc10 --------------- * Sat Jul 12 18:00:00 2008 Jan Kratochvil - 6.8-15 - Temporary rpm-4.5.90 compatibility workaround by Panu Matilainen. - Fix a regression in the constant watchpoints fix, found by Daniel Jacobowitz. - Fix the prelink testcase for false FAILs on i386. glpi-0.71-1.fc10 ---------------- * Fri Jul 11 18:00:00 2008 Remi Collet - 0.71-1 - update to 0.71 stable - fix bug #452353 (selinux) glpi-data-injection-1.2-1.fc10 ------------------------------ * Sat Jul 12 18:00:00 2008 Remi Collet - 1.2-1 - update to 1.2 for glpi 0.71 glpi-mass-ocs-import-1.2-1.fc10 ------------------------------- * Sat Jul 12 18:00:00 2008 Remi Collet - 1.2-1 - update to 1.2 for glpi 0.71 glpi-pdf-0.5-1.fc10 ------------------- * Sat Jul 12 18:00:00 2008 Remi Collet - 0.5-1 - update to 0.5 finale for glpi 0.71 ikiwiki-2.53-1.fc10 ------------------- * Sat Jul 12 18:00:00 2008 Thomas Moschny - 2.53-1 - Update to 2.53. * Thu Jul 10 18:00:00 2008 Thomas Moschny - 2.52-1 - Update to 2.52. jd-2.0.0-0.7.svn2196_trunk.fc10 ------------------------------- * Sun Jul 13 18:00:00 2008 Mamoru Tasaka - rev 2196 kdelibs-4.0.98-2.fc10 --------------------- * Sat Jul 12 18:00:00 2008 Kevin Kofler - 4.0.98-2 - revert a kinit patch causing an assertion failure in KComponentData (#455130) munin-1.2.6-2.fc10 ------------------ * Sat Jul 12 18:00:00 2008 Kevin Fenzi - 1.2.6-2 - Apply postfix patch (fixes #454159) - Add perl version dep and remove unneeded perl-HTML-Template (fixes #453923) newsx-1.6-9.fc10 ---------------- * Sat Jul 12 18:00:00 2008 Dominik Mierzejewski 1.6-9 - fixed stack buffer overflow in getarticle.c (#454483) - rebuilt against INN shared libraries (#454897) - fixed build on rawhide npush-0.7-1.fc10 ---------------- * Sat Jul 12 18:00:00 2008 Stefan Posdzich - 0.7-1 - Update to 0.7 - Upstream now ships our .desktop an icon file - Add npush-0.7-level.patch to fix level path - Remove obsolete npush-0.6-level-svn.patch ntfs-3g-1.2712-1.fc10 --------------------- * Sat Jul 12 18:00:00 2008 Tom "spot" Callaway - 2:1.2712-1 - update to 1.2712 php-pear-Net-Socket-1.0.9-1.fc10 -------------------------------- * Sat Jul 12 18:00:00 2008 Remi Collet 1.0.9-1 - update to 1.0.9 rlog-1.4-1.fc10 --------------- * Sat Jul 12 18:00:00 2008 Peter Lemenkov 1.4-1 - Ver. 1.4 - Dropped upstreamed patch - Enabled valgrind on all supported platforms roadstencil-fonts-1.0-5.fc10 ---------------------------- * Sat Jul 12 18:00:00 2008 Jon Stanley - 1.0-5 - Fix the fontconfig file * Sat Jul 12 18:00:00 2008 Jon Stanley - 1.0-4 - fix build failure from previous * Sat Jul 12 18:00:00 2008 Jon Stanley - 1.0-3 - Add fontconfig file (#445136) rpm-4.5.90-0.git8426.6 ---------------------- * Sat Jul 12 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8426.6 - fix type mismatch causing funky breakage on ppc64 * Fri Jul 11 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8426.5 - flip back to external bdb - fix tab vs spaces complaints from rpmlint - add dep for lzma and require unzip instead of zip in build (#310694) - add pkgconfig dependency to rpm-devel - drop ISA-dependencies for initial introduction - new snapshot from upstream for documentation fixes * Thu Jul 10 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8424.4 - handle int vs external db in posttrans too * Tue Jul 8 18:00:00 2008 Panu Matilainen - rpm 4.5.90-0.git8424.1 (alpha snapshot) - adjust to build against Berkeley DB 4.5.20 from compat-db for now - add posttrans to clean up db environment mismatch after upgrade - forward-port devel autodeps patch * Tue Jul 8 18:00:00 2008 Panu Matilainen - adjust for rpmdb index name change - drop unnecessary vendor-macro patch for real - add ISA-dependencies among rpm subpackages - make lzma and sqlite deps conditional and disabled by default for now * Tue Jul 8 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8424.3 - require curl as external url helper * Tue Jul 8 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8424.2 - add support for building with or without internal db splint-3.1.2-1.fc10 ------------------- * Sat Jul 12 18:00:00 2008 Panu Matilainen - 3.1.2-1 - update to 3.1.2 tlock-1.4-1.fc10 ---------------- * Sat Jul 12 18:00:00 2008 _pjp_ - 1.4-1 - Fixed the `root># tlock -s' bug. Patch supplied by: Milos Jakubicek (xjakub at fi.muni.cz) Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 22 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 deltarpm-3.4-10.fc9.i386 requires librpmdb-4.4.so deltarpm-3.4-10.fc9.i386 requires librpm-4.4.so deltarpm-3.4-10.fc9.i386 requires librpmio-4.4.so f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fusecompress-1.99.14-3.fc9.i386 requires librlog.so.1 gdb-6.8-15.fc10.i386 requires librpmdb-4.4.so gdb-6.8-15.fc10.i386 requires librpm-4.4.so ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-5.4.1-19.fc10.i386 requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpmio-4.4.so ovaldi-5.4.2-1.fc10.i386 requires librpmdb-4.4.so ovaldi-5.4.2-1.fc10.i386 requires librpm-4.4.so ovaldi-5.4.2-1.fc10.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpmdb-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpm-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so stardict-3.0.1-9.fc9.i386 requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpmio-4.4.so()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpm-4.4.so()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpmdb-4.4.so()(64bit) f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) fusecompress-1.99.14-3.fc9.x86_64 requires librlog.so.1()(64bit) gdb-6.8-15.fc10.x86_64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.x86_64 requires librpmdb-4.4.so()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.x86_64 requires librpm-4.4.so()(64bit) 1:net-snmp-5.4.1-19.fc10.x86_64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.x86_64 requires librpm-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.x86_64 requires librpmio-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.x86_64 requires librpm-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.x86_64 requires librpmdb-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpm-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpmdb-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) stardict-3.0.1-9.fc9.x86_64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 deltarpm-3.4-10.fc9.ppc requires librpmdb-4.4.so deltarpm-3.4-10.fc9.ppc requires librpm-4.4.so deltarpm-3.4-10.fc9.ppc requires librpmio-4.4.so f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) fusecompress-1.99.14-3.fc9.ppc requires librlog.so.1 gdb-6.8-15.fc10.ppc requires librpmdb-4.4.so gdb-6.8-15.fc10.ppc requires librpm-4.4.so gdb-6.8-15.fc10.ppc64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.ppc64 requires librpmdb-4.4.so()(64bit) ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.ppc requires librpm-4.4.so 1:net-snmp-5.4.1-19.fc10.ppc requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.ppc requires librpmdb-4.4.so ovaldi-5.4.2-1.fc10.ppc requires librpm-4.4.so ovaldi-5.4.2-1.fc10.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpmdb-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpm-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so stardict-3.0.1-9.fc9.ppc requires libgucharmap.so.6 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpmio-4.4.so()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpm-4.4.so()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpmdb-4.4.so()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) fusecompress-1.99.14-3.fc9.ppc64 requires librlog.so.1()(64bit) gdb-6.8-15.fc10.ppc64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.ppc64 requires librpmdb-4.4.so()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:net-snmp-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) 1:net-snmp-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.ppc64 requires librpm-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.ppc64 requires librpmdb-4.4.so()(64bit) ovaldi-5.4.2-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 rpmreaper-0.1.4-1.fc10.ppc64 requires librpmbuild-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.ppc64 requires librpm-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) stardict-3.0.1-9.fc9.ppc64 requires libgucharmap.so.6()(64bit) subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From alexl at users.sourceforge.net Sun Jul 13 09:04:27 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 13 Jul 2008 02:04:27 -0700 Subject: How to handle soname bump properly? In-Reply-To: <9339c38c0807122019s470a396aref17aac97d0e72f3@mail.gmail.com> (Jesse Keating's message of "Sat\, 12 Jul 2008 23\:19\:08 -0400") References: <20080712152448.GS7900@inocybe.teonanacatl.org> <9339c38c0807122019s470a396aref17aac97d0e72f3@mail.gmail.com> Message-ID: >>>>> "JK" == Jesse Keating writes: [...] >> It is already documented: >> http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides >> although that page is buried in a somewhat obscure place that a >> casual package maintainer would probably not know to look there. JK> That's because it's a document for release engineers to use when JK> they actually process the tagging request. It's not necessarily JK> meant for maintainers to use, that little bit of documentation has JK> definitely been missing for a while. Sure, I was just pointing it out. >> It should probably linked from somewhere in the PackageMaintainers >> namespace with a higher-level explanation like the text above. >> This kind of thing might be useful for the PackageMaintainers >> Tips/Tricks page which I can't seem to locate the URL for right now >> (it isn't linked from >> http://fedoraproject.org/wiki/PackageMaintainers) JK> All it takes is somebody to make it happen (: Indeed, I think that's what Peter was volunteering to do. I was giving him some background that might be helpful when writing the text and/or figuring out where to put it. If needed I can assist in that. Alex From dledford at redhat.com Sun Jul 13 16:07:02 2008 From: dledford at redhat.com (Doug Ledford) Date: Sun, 13 Jul 2008 12:07:02 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080713101257.2369bbd2.mschwendt@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080713101257.2369bbd2.mschwendt@gmail.com> Message-ID: <1215965222.3687.311.camel@firewall.xsintricity.com> On Sun, 2008-07-13 at 10:12 +0200, Michael Schwendt wrote: > On Sat, 12 Jul 2008 20:10:51 -0400, Doug Ledford wrote: > > > > For other > > > projects one cannot build from a scm checkout without running scripts, > > > such as autogen.sh where one would need to reproduce the upstream > > > development env. > > > > Where is the reference on that BTW. There was a time in the past when > > someone asked me what they should do before generating their tarballs > > and I told them to just tar it up and go, and I had every intention of > > running autogen.sh myself during the build process. Then someone told > > me "No, they need to run autogen.sh before they make the tarball". So, > > why is that? Why shouldn't the sources be autogen'ed against our > > specific dev environment, after all we will be the ones building our > > rpms in our build environment, so it would seem to make sense to me. > > Obviously I must be missing something of great importance... > > It's related to the reason why we have multiple auto{conf,make} versions > in the distribution. You need to pick the set of tools that is compatible > with the rest of the source build setup. Sometimes errors force you to run > a specific older or newer(!) version than what you can choose from. Or > errors make you patch the configure.{ac,in} and closely related files > before you can set up the source at all. That alone may be quite some work > for several projects. Further, there have been silent incompatibilities > before, which break configuration of the source, because you generate a > build environment which differs from upstream. The errors may be subtle, > which aren't trivial to track down in thousands of generated lines of > typical "configure" scripts or aclocal.m4 files. Or, what seems to autogen > for you today breaks tomorrow in a completely unexpected and weird way, > and at an unfortunate point of time, only because your upgraded autotools > reveal a sleeping incompatibility. OK, so to sum up, we have upstream run autogen.sh because the autogen tools are buggy and from version to version they break. This then begs the question of whether or not the autogen people should be kicked. It also begs the question of how deeply a project depends on the autogen tools. If a project only minorly depends on them to get some definitions and the results barely effect the code, then it's possible, and in fact likely, that they wouldn't get hit by the bugs you allude to. So, in some cases, it would seem that running autogen.sh locally might be OK given the risk of bug introduction is low. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sun Jul 13 16:12:10 2008 From: dledford at redhat.com (Doug Ledford) Date: Sun, 13 Jul 2008 12:12:10 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215933795.19719.20.camel@rousalka.okg> References: <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> <1215933795.19719.20.camel@rousalka.okg> Message-ID: <1215965530.3687.316.camel@firewall.xsintricity.com> On Sun, 2008-07-13 at 09:23 +0200, Nicolas Mailhot wrote: > Le dimanche 13 juillet 2008 ? 03:03 -0400, Colin Walters a ?crit : > > 2008/7/13 Nicolas Mailhot : > > > > > > > > How about the 9/10th of packages I've been involved with since > > I used > > RHL or Fedora (I think I've passed my decade of use and > > packaging now)? > > > > Part of Fedora's role in the larger Free Software community is to > > drive convergence and improvements in upstream projects. This > > manifests in various ways, such as getting projects onto the same > > shared library versions, etc. In this instance, if our tooling could > > be signinficantly improved by using revision control instead of > > tarballs (and I definitely believe that is the case) we can help move > > upstream. > > > > For example in GNOME it would not be a large workflow change to make > > it a hard requirement that tarball releases on ftp.gnome.org have a > > predictable correspondingly named SVN (or hopefully later git) tag. > > Given that it's a lot of work just to convince projects to have sane > numbering and clear licensing, that even Red Hat (hello Liberation) has > been known to release high-profile material out of a VCS, that tag move > and history rewrite is rampant even in our own Fedora CVS, this seems a > hopeless cause to me. People have to care enough to do abide by sane SCM policies, I grant you that. I think a large enough number will agree to them that it's worth the effort. > You keep giving big projects with lots of > resources as examples, but while a big part of the distribution, they're > not all of it. This isn't an all or nothing exercise. If a few big projects sign on, then we've made a net win. Since I already know the kernel can use this, and of course I'm relatively certain every InfiniBand package, including all of the still active MPI stacks, will agree to it, and Colin is bringing up Gnome....really, how much more do you need to think it would be worthwhile? Personally, I'm sold even if only the mentioned packages take us up on it. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Sun Jul 13 16:17:54 2008 From: dledford at redhat.com (Doug Ledford) Date: Sun, 13 Jul 2008 12:17:54 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215932155.19719.13.camel@rousalka.okg> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> Message-ID: <1215965874.3687.320.camel@firewall.xsintricity.com> On Sun, 2008-07-13 at 08:55 +0200, Nicolas Mailhot wrote: > Le samedi 12 juillet 2008 ? 15:31 -0400, Doug Ledford a ?crit : > > On Sat, 2008-07-12 at 21:00 +0200, Nicolas Mailhot wrote: > > > Le samedi 12 juillet 2008 ? 14:30 -0400, Doug Ledford a ?crit : > > > > > > > Even if I thought Panu would take the header changes and any other > > > > possible things I might do to RPM, if the other people who control these > > > > other items of Fedora infrastructure are dead set against this type of > > > > work, then it's a waste of my time to futz around with it unless I'm > > > > willing to fork my own distro. The responses I've gotten so far have > > > > not made me inclined to think the powers that be will even look at > > > > things, but I could be wrong. > > > > > > As Jesse Keating tried to tell you, the reality is that the owerwhelming > > > majority > > > > First, before I respond to the rest of this, keep in mind that the > > "overwhelming majority" of packages needs to be quantified. > > How about the 9/10th of packages I've been involved with since I used > RHL or Fedora (I think I've passed my decade of use and packaging now)? > > I'll grant you a few of them are clean SCM dumps. Since I had to rewrite > upstream's release script myself (and get it merged) to make sure it was > always the case. Of the 26 or so packages I currently deal with from the InfiniBand community, the only difference between the tag in the SCM and the tarball is the running of autogen.sh and that's only because I *told* them to do so. Then of course I also deal with the kernel. So, you'll excuse me for not having the innate perspective you do on this issue. Everyone I deal with treats their SCM setup sanely. > > Furthermore, at least one very significant package (the kernel) does not > > massage files at all between SCM tag and tarball. > > If you can't understand the kernel is utterly unrepresentative in so > many ways that's not even funny I can do nothing for you. The kernel content is certainly not representative. However, that doesn't change the fact that it is both a very large project that would benefit greatly from the changes I'm talking about and also a nice example of good SCM policies in practice upstream. > > And to be honest, I > > would be very surprised to find many projects that do have any > > significant difference between a tagged release in the SCM of their > > choice and their tarballs. > > It does not need to be huge to cause no end of QA and maintenance > problems. > > > So I would like some examples please, which > > shouldn't be hard to come up with since it is the "overwhelming > > majority" of projects that obviously think when they tag something in > > their SCM it doesn't need to match the tarball they make with the same > > tag version... > > Take ten random packages in the review queue. They need the review and > you need some perspective. Actually, I'll take you up on that just to see. Thanks for the suggestion. > > > of the code we package is not pure VCS dumps, because upstreams > > > massage their files manually before doing official releases, so being > > > able to base a package on a precise tar.gz as posted on upstream's > > > homepage is a hard requirement. > > > > No, it's a *policy* that we base things on a precise tarball on some > > web/ftp server. > > If you haven't noticed yet we are choke-full of policies that could all > be reverted but contribute to make life easier to packagers. I'm sorry, but this policy you speak of does not make life easier. And while they could all be reversed, this one actually deserves to be reversed. > > It's a policy that is no better or worse than basing a > > package on a precise tagged source version in an SCM. And to be honest, > > I couldn't care less if upstream's tarball and their SCM version match > > or not. It's not important that they match, it's important that we pick > > one to be canonical, that we make our choice of which is canonical clear > > and apparent to everyone, and then we use that source consistently > > within that package. That's all that matters. > > No. > What matters is we pick the version upstream intends us to use. And if we tell upstream that we are going to use a particular tag in their SCM instead of a tarball, upstream can do their preparation there. Really, this isn't rocket science, it's just letting upstream know what we are doing and then they are fully capable of working with us on this. Only if we get so inured in our current way of doing things that we can't possibly change does this become impossible to correct. > What matter is we pick the version upstream checked for problems before > publishing (even if that involved some dirty upstream massaging) > What matters is we use the same upstream version as everyone else so we > benefit from the collective QA work the community does. > What matters is our users know exactly what they get and not dumps of > VCS soup. Like I said. Talk to upstream. Issue solved. Colin more or less made the same point. Assuming upstream won't work with us on something like this is a totally silly reason not to try. > > Claiming that a precise > > tar.gz is a hard requirement is patently fallacious. It's currently a > > hard requirement *solely* because we haven't integrated cloned SCM repo > > support in Fedora yet, and since we are talking about implementing > > exactly that support, it negates this "hard" requirement. > > You've certainly lived a sheltered life with no contact with the kind of > code one can find in the internet. No, I've been in contact with all sorts of code. Some good, some bad, some you felt like you needed a bath after looking at. Regardless though, I've generally found that upstream is willing to work with me on things. I would expect a change like this to be no different, and I'm certain that all 26 or so packages I'm working on would gladly implement the minimum policy requirements I have for their SCMs in order to make this happen (immutable tags, no deletions only revertions, and I keep a local clone in case they implode). Of course, I'm spoiled in that all 26 of those packages use git. Guess I'm just a lucky bastard. > > > As long as your system can take this into account I don't think anyone > > > would mind having a more modern way to manage the stuff we put around > > > this upstream archive. > > > > Sorry, but if I do the work, then I'm writing it to eliminate the > > tarball. You don't have to switch your package to this new method if > > you don't wish, but I'll be switching my packages over and they will > > never touch a tarball again. > > If you don't want to listen, don't complain you're not heard. I don't want to listen to "It can't be done, so don't try". I don't care if I'm heard, I care that people don't block me from going my own way and doing my own thing. To which end, I think I'm done with this thread. We've beat the horse to death. The people that handle the Fedora infrastructure will either take the patches or they won't, I'm headed off to write them. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 nicolas.mailhot at laposte.net Sun Jul 13 16:44:11 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 13 Jul 2008 18:44:11 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215965530.3687.316.camel@firewall.xsintricity.com> References: <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> <1215933795.19719.20.camel@rousalka.okg> <1215965530.3687.316.camel@firewall.xsintricity.com> Message-ID: <1215967451.26619.5.camel@rousalka.okg> Le dimanche 13 juillet 2008 ? 12:12 -0400, Doug Ledford a ?crit : > This isn't an all or nothing exercise. If a few big projects sign on, > then we've made a net win. Since I already know the kernel can use > this, and of course I'm relatively certain every InfiniBand package, > including all of the still active MPI stacks, will agree to it, and > Colin is bringing up Gnome....really, how much more do you need to think > it would be worthwhile? Personally, I'm sold even if only the mentioned > packages take us up on it. As long as you understand generalising VCS sourcing would need a major upstream education effort, and can only be done short-term for a few well-behaved projects, I don't think you'll get much opposition from me or others. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wwoods at redhat.com Sun Jul 13 17:30:09 2008 From: wwoods at redhat.com (Will Woods) Date: Sun, 13 Jul 2008 13:30:09 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215887445.3687.244.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> Message-ID: <1215970209.9869.21.camel@zebes.localdomain> On Sat, 2008-07-12 at 14:30 -0400, Doug Ledford wrote: > On Sat, 2008-07-12 at 13:40 -0400, Josh Boyer wrote: > > > I'm *making* the time...around my day job. > > > > Most of the Fedora contributors do that. > > OK, how about I clarify that a bit. I'm making time around my day job > because I can *at the moment*. If I were to put things off to F11, > there is a good chance that when F11 is in development, I may be tied up > elsewhere. So I really would like to move forward now, just because now > is when I can. A note about scheduling: We've got just over 4 weeks until F10 Feature Freeze and you haven't even *started*. This is a big change and it's going to take a lot of changes across the entire distro - I'm really doubtful that it could be done properly that soon. The good news is that F11 development branches in a mere 12 weeks (or so). I think people would have been a lot more receptive if you had been planning to land your changes then. Otherwise you end up hearing the stock Fedora response for people who want to make massively invasive changes without really talking to anyone first: "Yeah, that's great, let us know when you're done." It's not that anyone thinks these changes are a bad idea - I'm actually fairly excited about the possibilities here. But from what I've heard of the plans so far, it'd be a really bad idea to try to force it in for F10. -w From lesmikesell at gmail.com Sun Jul 13 17:39:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 13 Jul 2008 12:39:28 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215932155.19719.13.camel@rousalka.okg> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> Message-ID: <487A3DD0.3040702@gmail.com> Nicolas Mailhot wrote: >> First, before I respond to the rest of this, keep in mind that the >> "overwhelming majority" of packages needs to be quantified. > > How about the 9/10th of packages I've been involved with since I used > RHL or Fedora (I think I've passed my decade of use and packaging now)? > > I'll grant you a few of them are clean SCM dumps. Since I had to rewrite > upstream's release script myself (and get it merged) to make sure it was > always the case. If you can't reproduce a release exactly from a tag in your repository you've seriously missed the point of version control. You might even make a good argument that for sources that live in a distributed SCM, that is the "preferred form of the work for making modifications to it" as required by the GPL. On the other hand, I've heard svn mentioned in passing here and I don't think it will do what you need without some help - perhaps svk or pushmi would get a usable mirror copy where you can add a local branch for a build, but I'm not sure how you would do subsequent redistribution. >> And to be honest, I >> would be very surprised to find many projects that do have any >> significant difference between a tagged release in the SCM of their >> choice and their tarballs. > > It does not need to be huge to cause no end of QA and maintenance > problems. But upstream will be having these problems anyway and you inherit them. Some good examples of how to avoid them all the way to the packaged versions would be good for everyone. > No. > What matters is we pick the version upstream intends us to use. > What matter is we pick the version upstream checked for problems before > publishing (even if that involved some dirty upstream massaging) > What matters is we use the same upstream version as everyone else so we > benefit from the collective QA work the community does. These are all precisely why you have a VCS that manages the details for you. > What matters is our users know exactly what they get and not dumps of > VCS soup. I'm not sure what you mean here. A tarball with magic tweaks might be OK if it is perfect and will never need ongoing maintenance, but that is never the case. If you work directly with the VCS you can at least see what is changing and usually why. >> It's currently a >> hard requirement *solely* because we haven't integrated cloned SCM repo >> support in Fedora yet, and since we are talking about implementing >> exactly that support, it negates this "hard" requirement. > > You've certainly lived a sheltered life with no contact with the kind of > code one can find in the internet. As long as the old method continues to work, what's the problem with adding a way to improve it going forward? >>> As long as your system can take this into account I don't think anyone >>> would mind having a more modern way to manage the stuff we put around >>> this upstream archive. >> Sorry, but if I do the work, then I'm writing it to eliminate the >> tarball. You don't have to switch your package to this new method if >> you don't wish, but I'll be switching my packages over and they will >> never touch a tarball again. > > If you don't want to listen, don't complain you're not heard. If you don't eliminate the tarball, you aren't going to make a big improvement. Why not leave it as-is where you can't do anything better but add the mechanism to improve things when possible? This doesn't break anything and lets you take advantage of upstream changes that will happen (or not) at their own pace. You'll need to come up with a different concept for the src rpms though. Would they contain build commands to extract the tagged source from a separately stored (and available) mirrored scm repo for each project? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Sun Jul 13 18:08:49 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 13 Jul 2008 13:08:49 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215970209.9869.21.camel@zebes.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215970209.9869.21.camel@zebes.localdomain> Message-ID: <487A44B1.9010709@gmail.com> Will Woods wrote: > >>> Most of the Fedora contributors do that. >> OK, how about I clarify that a bit. I'm making time around my day job >> because I can *at the moment*. If I were to put things off to F11, >> there is a good chance that when F11 is in development, I may be tied up >> elsewhere. So I really would like to move forward now, just because now >> is when I can. > > A note about scheduling: We've got just over 4 weeks until F10 Feature > Freeze and you haven't even *started*. This is a big change and it's > going to take a lot of changes across the entire distro - I'm really > doubtful that it could be done properly that soon. > > The good news is that F11 development branches in a mere 12 weeks (or > so). > > I think people would have been a lot more receptive if you had been > planning to land your changes then. Otherwise you end up hearing the > stock Fedora response for people who want to make massively invasive > changes without really talking to anyone first: "Yeah, that's great, let > us know when you're done." > > It's not that anyone thinks these changes are a bad idea - I'm actually > fairly excited about the possibilities here. But from what I've heard of > the plans so far, it'd be a really bad idea to try to force it in for > F10. I'd argue that it would make sense to make the changes to RPM itself a version before anything uses them. Depending on the design of the change, it probably wouldn't be all that difficult to make it generate a tarball-containing srpm as a step in the process if anyone wanted it, but avoiding that is kind of the point. -- Les Mikesell lesmikesell at gmail.com From a.badger at gmail.com Sun Jul 13 22:22:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 13 Jul 2008 15:22:15 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215907851.3687.271.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> Message-ID: <487A8017.6080009@gmail.com> Doug Ledford wrote: > On Sat, 2008-07-12 at 22:09 +0200, Michael Schwendt wrote: >> For other >> projects one cannot build from a scm checkout without running scripts, >> such as autogen.sh where one would need to reproduce the upstream >> development env. > > Where is the reference on that BTW. There was a time in the past when > someone asked me what they should do before generating their tarballs > and I told them to just tar it up and go, and I had every intention of > running autogen.sh myself during the build process. Then someone told > me "No, they need to run autogen.sh before they make the tarball". So, > why is that? Why shouldn't the sources be autogen'ed against our > specific dev environment, after all we will be the ones building our > rpms in our build environment, so it would seem to make sense to me. > Obviously I must be missing something of great importance... > > Just to clarify a further point a tad tangential to your question: upstream should always run autogen.sh at some point prior to releasing as one of the basic ideas behind the autotools is that you do not need them installed on the end-user's machine. However, whether upstream does this once and then checks it into source control or does this before every release as part of the tarball creation process does not compromise this and can make a difference in whether one can simply checkout from revision control and be ready to build. -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 a.badger at gmail.com Sun Jul 13 22:24:11 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 13 Jul 2008 15:24:11 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <9339c38c0807121737r25aed525g83e07e42f6248362@mail.gmail.com> References: <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> <1215826146.3687.121.camel@firewall.xsintricity.com> <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> <1215908968.3687.292.camel@firewall.xsintricity.com> <9339c38c0807121737r25aed525g83e07e42f6248362@mail.gmail.com> Message-ID: <487A808B.1010504@gmail.com> Jesse Keating wrote: > > > 2008/7/12 Doug Ledford >: > > On Fri, 2008-07-11 at 22:41 -0400, Jesse Keating wrote: > > > Unfortunatly I live in reality where many upstreams post process the > > scm checkout so reliance on the scm alone is not possible. > > And this is at least partially our own fault. For instance, the fact > that upstream opensm, libibcommon, libibumad, libibmad, librdmacm, > libibcm, and a few others from the OFED package set run autogen.sh is > because someone in Fedora told me to tell them to. I originally told > them not to and I was "corrected". So it seems a bit fishy to me to use > that as a reason that we can't use an SCM checkout, we created our own > problem here, I would think we should be able to solve our own problem. > > And that gets to my next point, which really is that people are getting > caught up in how things are (like processing with autogen.sh), and > aren't considering if things *must* be that way. For example, you can't > really clone a subversion repository. You can check it out, but commits > have to go back to the central repo. This means we would have a hard > time dealing with subversion upstream sources. However, as a possible > policy implementation, we could contact upstream and request that the > fedora package maintainers be given their own branches in the upstream > repo, and that they have full write access on those branches, and the > package maintainer could then merge over specific updates from the > upstream primary branches into the fedora branches as we decided to > upgrade to a particular release. We could then request the ability to > rsync the actual repo to our own servers so we would always have our own > copy should upstream decide to implode. So, there are ways we could > *make* a subversion upstream work, but it's not pretty. > I'd *much* rather see us decide to stick with tarballs if upstream is using an svn repository. We'd need to support tarballs for cvs repositories, non-version controlled upstreams, and other random stuff so there's no need to build a Rube Goldberg machine simply for svn repositories. -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 a.badger at gmail.com Sun Jul 13 23:21:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 13 Jul 2008 16:21:25 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215830881.3687.184.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <4877FCBA.80006@gmail.com> <1215830881.3687.184.camel@firewall.xsintricity.com> Message-ID: <487A8DF5.2040509@gmail.com> Doug Ledford wrote: > On Fri, 2008-07-11 at 17:37 -0700, Toshio Kuratomi wrote: >> Firstly: what is your overall idea? Is it exploded trees as jcollie and >> I were arguing for at one time or is it mirroring of upstream repos onto >> Fedora servers? > > It's both. You first have to support exploded source repos to make the > rest of this worth anything. However, part of *truly* supporting an > exploded source repo is making that repo available INSTEAD OF srpms. In > other words, fulfill our legal obligation to provide source for a > package via the source repo instead of via an srpm. > I think you're missing some context. I've just read the message where you haven't been on this list for long. There's three or four discussions on this list, fedora-infrastructure-list (and possibly fedora-advisory-board) where we have talked about doing exploded trees. The basic idea I laid out for that was importing tarballs into a distributed SCM and making our changes against those imports (rather than checking patch files into the SCM). In cases where our SCM matched up against upstream's SCM we could start with upstream's SCM as the basis, import the tarballs into a branch and have better merging in those cases. I think you're taking a different approach:: 1) Support multiple different upstream SCMs (I've been thinking about taking this up since we are doing this for Fedora Hosted. However, doing this for packaging SCMs is a bigger job and is more in the critical path.) 2) Clone upstream's repo to our infrastructure. 3) Then do all of our work within a branch(es) of that repository. A) If upstream doesn't use a supported SCM, then continue to do what we do now with tarballs or import snapshots of upstream work (you don't specify where these snapshots come from... tarballs, their SCM, etc... I think your position would be "any of the above") (Make corrections if I'm wrong in what you're thinking) [snip stuff I think I summarized above] >> Go into more depth about the specifics of what you've >> thought out otherwise people don't know what the issues and solutions >> are going to be. > > The first issue is simply supporting an exploded source repo. An > exploded source repo really only requires a few things. First, you no > longer need a %setup or %patch portion in the spec file. I'd think we'd want to extend these rather than get rid of them. 1) We'll continue to have some packages that don't use supported revision control so we'll have to release for them from tarball. 2) We have cases where we release a package with multiple source tarballs; we'll also want the ability to release a package with multiple source SCM repos. 3) We want some way to produce different sets of changes for distinct features. With the current system we use multiple patch files for this. Under an SCM system I'd use distinct feature branches which we'd need to represent. (There could be other ways to represent this, though -- ideas?) > Second, you > treat things differently in that sourcedir, specdir, and builddir are > all one and the same. This is probably true but should mention that we're adding repo locations into the mix. The repo locations take the place of sourcedir. > Finally, since you built the binary packages from > this exploded source repo, then in order to give people the exact > sources you built from, you need to make the repo available for > clone/checkout by people. We'll have to be careful here. SCM's that we support will need to have the ability to remove changesets from their history in case we have to remove something that's illegal to distribute from the history. We'll also need to be able to process any merges from upstream before they hit our repository. I'm not sure how this fits into the feature branches talked about earlier either. We'd have to be able to tag a set of branmches as belonging to a certain build or have a release branch that gets built up from the feature branches. Maybe this build up would be done prior to getting to the rpm stage so that the rpm only has to deal with a single repository... but we don't want to encourage our developers to make single monolithic patches (one of the main flaws with Debian's dpkg format that they've tried to address with various add-ons to the base tools.) > You need never once build an srpm or tarball > from this repo if you don't want to (and in fact, an srpm wouldn't build > from the same spec file as an exploded source repo spec file unless you > conditionalized the spec to know if it was in an srpm or in its native > exploded source repo format). I'm not certain we'd want to go this route. It seems like it would be easy to generate tarballs when building the package so it would be easy to generate SRPMs as well (although rpmbuild would have to be taught that SCM referencing spec files could use a local cache tarball instead of checking out source). If this is easy, then the question becomes whether SRPMs are useful. SRPMs are mirrorable. They are buildable on networks that can't contact the internet. They can be signed and resigned by local admins. They can be put into repositories that yum understands and you can find all their build dependencies by using that repository information. Also, since we're going to have somethings that aren't backed by a distributed SCM but by a tarball, we're still going to need a way to distribute those sources. It'll just spawn confusion to have SRMs for part of the distro and a separate method for the rest. [snip cool stuff that I've mentioned before as well] > This is where I point out that Jesse's email I responded to about the > upstream RPM devel cluttering up fedora's devel branch, the one where I > said he wasn't imaginative at all in terms of branching, is a perfect > example. Panu mentioned he was pulling the new rpm from the upstream > git repo. We would simply clone that. In the process, our official > repo would have a list of references to the remote, upstream repo's > branches. These branches are inviolate by us. We can never change > them, they simply are a copy of upstream's metadata. We can, however, > create our own branches. In fact, the standard modus operandi in a case > like this would be to clone upstream, then create tracking branches in > our repo that show us upstreams branches (because we don't see anything > but master from upstream by default), then create our own branches (so > upstream has it's own devel branch, usually just named master, and we > could create our own branch named fedora-devel that would be our primary > devel branch, then as we approach a release we can branch from > fedora-devel to f-8, f-9, etc), and then we simply merge or don't merge > from upstream to our devel branch as we see fit. For things where we > want to follow upstream, we can actually configure fedora-devel to > automatically merge any new changes from upstream's master branch in > anytime we do a pull (in fact, you can do this on a per branch basis, > any given branch can be told to automatically merge changes from another > branch into it, or it can be a more static branch that doesn't auto > merge anything). Had this been the case, then merely setting the > fedora-devel branch to not automerge from the remote (upstream) devel > branch would have resulted in all of the auto-rebuilds and things like > that working just fine on the fedora-devel branch as Jesse mentioned > needed to happen, but it would have let us see the changes going on in > the remote tracking branches and everyone who bothered to update their > rpm repo would see those changes on those remote branches and know > something was up. > You're straying into git specifics here. Different upstream SCMs will give us different abilities. We'll need to figure out what things, like this, are important to us, and then make abstracted commands that implement the backend magic to talk to them all in native syntax. For other things, we'll have to decide on lowest-common-denominator. Also, this is unfortunately upstream policy dependent as well. I've worked with some upstreams recently who use DCVS to make project management spaghetti :-(. Nothing we can do about that when upstream doesn't see that they have a problem. [Cut more cool stuff I've mentioned before] > Really, there are all sorts of reasons to use exploded source repos, to > join our own development efforts in with upstream and to hook our source > systems together. In the end though, it all boils down to this. Some > people are comfortable with and want to keep using srpms and our current > disconnected SCM methodology, and some people want another choice. I'm > perfectly fine with other people not wanting to change. They don't have > to. But I would prefer to be granted the ability to modernize my own > way of working should I choose to do so. And this is a big part of > that. > One note: None of this is tied to SRPMs. SRPMs are a product of the build just as RPMs are. The system we're criticizing and trying to extend is really how we store and manage the inputs to the build system. (We've been calling this dist-cvs. The work that Jesse did earlier on git and hg were dist-hg and dist-git as they were just cloning the cvs process into the distributed SCMs. Exploded trees are different from that work.) > This has been more of a sales pitch than anything to be honest. If you > want to know more about what I had in mind for nuts and bolts changes to > rpm, then I'm attaching a tar.gz of my ~/.tomboy directory. As I was > working on things, I just made notes (I really like Tomboy now). Move > your own .tomboy out of the way if you have anything you'd like to save, > then unpack mine in place, restart tomboy, and start reading from the > Enabling optimal SCM usage in Fedora. Everything is linked from that > one note. Of course, I was really only a little ways in. I was still > concentrating on the rpm changes and hadn't touched on build system > changes, or repo server changes, or access controls with different scms, > or any of that stuff. And what I *had* accomplished in terms of rpm > knowledge is now at least somewhat wrong given the rpm update. > I'll try to get a chance to look at this but.... /me wishes tomboy had an export to treeview function -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 dfarning at sugarlabs.org Mon Jul 14 01:37:21 2008 From: dfarning at sugarlabs.org (David Farning) Date: Sun, 13 Jul 2008 20:37:21 -0500 Subject: Fedora, OLPC, and Sugar Labs Message-ID: <1215999441.29945.430.camel@dfarning.desktop.org> I just want to let those of you who do not follow political intrigue know that OLPC is spinning off the development of Sugar to Sugar Labs [1]. Once we get things untangled, we hope that Sugar development can be more responsive to the needs of other distributions such as Fedora and Redhat. If you have any questions or comments about Sugar or Sugar Labs please feel free to ?ask on the Sugar development mailing list [2] or contact me personally [3]. thanks dfarning 1. http://wiki.sugarlabs.org/go/Main_Page 2. sugar at laptop.org 3. dfarning at sugarlabs.org From james at fedoraproject.com Mon Jul 14 03:37:19 2008 From: james at fedoraproject.com (James Antill) Date: Sun, 13 Jul 2008 23:37:19 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215908404.3687.282.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> <1215871445.3687.190.camel@firewall.xsintricity.com> <1215893713.3224.54.camel@localhost.localdomain> <1215908404.3687.282.camel@firewall.xsintricity.com> Message-ID: <1216006639.4572.15.camel@code.and.org> On Sat, 2008-07-12 at 20:20 -0400, Doug Ledford wrote: > It's not head in the sand Jesse. It's that following the daytime soap > opera that is rpm4 vs rpm5 vs jbj vs everyone else isn't the least bit > worth my time. Doug, if I did some patches for the Linux kernel and acted as you have the last couple of days I'd be ignored or flamed to a crisp ... likely to never have my patches looked at. If you'd spoken to anyone involved with rpm, yum or Fedora rel-eng at any point you'd have been told what was happening and how you should go about getting what you want. Pretending there was or is any kind of confusion about rpm's future is like someone pretending they thought Linux might merge with OpenSolaris. The fact that you are still trying to blame everyone else for your own mistakes and trying to tell them what they should be doing for _you_ and how/when they should be doing it. While they are still trying to patiently help you, speaks volumes. -- James Antill Fedora From nphilipp at redhat.com Mon Jul 14 07:21:24 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 14 Jul 2008 09:21:24 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215907952.3687.274.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> Message-ID: <1216020084.31520.9.camel@wombat.tiptoe.de> On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote: > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: [...] > > The problem really lies with whether or not this would satisfy, as a > > written offer, the requirements under which we distribute or ask our > > ambassadors to distribute our binaries. > > OK, well regardless, if this meets the requirements, then certainly an > immutably tagged exploded SCM would too (for far less space requirements Leaving aside discussing the merits of it, you don't need to use immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision from which you built the package (which should already be immutable). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From valent.turkovic at gmail.com Mon Jul 14 07:51:55 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 14 Jul 2008 09:51:55 +0200 Subject: kernel bug - sound clicks In-Reply-To: <1215780034.18964.2.camel@hughsie-work> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> <1215780034.18964.2.camel@hughsie-work> Message-ID: <64b14b300807140051g5583d7acs25defb57c8a72d97@mail.gmail.com> On Fri, Jul 11, 2008 at 2:40 PM, Richard Hughes wrote: > On Fri, 2008-07-11 at 14:00 +0200, Valent Turkovic wrote: >> Loud clicks from speakers (snd_intel_8x0): >> https://bugzilla.redhat.com/show_bug.cgi?id=450395 >> >> Can somebody please look at this? > > Have a look at > http://blogs.gnome.org/hughsie/2008/03/28/clicking-of-snd_hda_intel/ > > Richard. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So as per your blog post this is bug over a year old. Is my bug a duplicate of it in bugzilla? If so please post the link. Is there something that we users who aren't developers can do so that this bug gets fixed faster? Is there some log, some debug output that would help kernel developers to find how to deal with these sound chips? Cheers, Valent. -- 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 dev at nigelj.com Mon Jul 14 07:56:24 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 14 Jul 2008 19:56:24 +1200 Subject: gtk-sharp2 dependencies Message-ID: <487B06A8.4070000@nigelj.com> Just an FYI before the Rawhide Report arrives, Yes gtk-sharp2 was bumped to 2.12.1 (at my request), yes it has broken the dependencies BUT: The reason this time is that rpm forgot to calculate the mono dependencies (something that can be expected with any major bump), with the old version of RPM the same Provides for 2.12.0-2 and 2.12.1-1 were calculated, so there isn't a need for a mass rebuild, just one of gtk-sharp2. So I think it's just a case of been patient while the mono provides bug is sorted and then be on our way. - Nigel From ae at op5.se Mon Jul 14 08:07:51 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 14 Jul 2008 10:07:51 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080712174916.0b9fff00@infradead.org> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> Message-ID: <487B0957.9060700@op5.se> Arjan van de Ven wrote: > On Sat, 12 Jul 2008 20:10:51 -0400 >> Presumably one could replicate this as needed. However, there is the >> question of whether or not it's needed. Remember that the concept >> using an upstream tarball as the canonical source version that we >> represent to the world that we are using is nothing more than a >> policy decision. Nothing in the GPL or anything else said we had to >> do that, it was just what we *chose* to do (long, long ago, in a >> galaxy far, far away). > > one thing to keep in mind... as comparison, what you don't want is what > Ubuntu is doing with their kernel (clone Linus and then just edit the > source tree); it's just one big nightmare (as you can imagine). Keeping > upstream source and local patches separate is a clear winner (anyone > who has worked on the alternative will agree with me). Well, if they clone and then edit without using separate branches for their various edits, then ofcourse it'll be a nightmare to manage. If, on the other hand, they're seriously interested in pawing off their changes back upstream in a way that makes it easy for the kernel devs to get them back, they'll have their changes on various topic-branches and issue "please pull" requests to the various kernel subsys developers, just like every other kernel hacker does. Personally, I would absolutely love finding a git repository with the fedora kernels so I can send patches without spending 4-5 days finding out how the hell one gets the kernel to the exact state that the one I'm running was built from. The process of finding a kernel source tree matching my exact version was actually so tricky I gave it up. Now I'm running a custom home-made kernel, so my (nvidia) graphics card doesn't work without additional hand-hacking. > If those upstream sources are a tarbal, or a tagged commit... is a lot > less relevant. > Not for the casual developer with an itch to scratch. I had 6 full days of work to spend on fixing the touchpad on my particular laptop (see bugzilla.redhat.com #448656) so the system actually became usable again, but since I couldn't duplicate the source-tree from the failing fedora kernel, I had nothing to diff against, so no way in hell I could send a patch. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Mon Jul 14 09:06:28 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 14 Jul 2008 11:06:28 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487A8DF5.2040509@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <4877FCBA.80006@gmail.com> <1215830881.3687.184.camel@firewall.xsintricity.com> <487A8DF5.2040509@gmail.com> Message-ID: <487B1714.7000904@op5.se> Toshio Kuratomi wrote: > Doug Ledford wrote: >> This is where I point out that Jesse's email I responded to about the >> upstream RPM devel cluttering up fedora's devel branch, the one where I >> said he wasn't imaginative at all in terms of branching, is a perfect >> example. Panu mentioned he was pulling the new rpm from the upstream >> git repo. We would simply clone that. In the process, our official >> repo would have a list of references to the remote, upstream repo's >> branches. These branches are inviolate by us. We can never change >> them, they simply are a copy of upstream's metadata. We can, however, >> create our own branches. In fact, the standard modus operandi in a case >> like this would be to clone upstream, then create tracking branches in >> our repo that show us upstreams branches (because we don't see anything >> but master from upstream by default), then create our own branches (so >> upstream has it's own devel branch, usually just named master, and we >> could create our own branch named fedora-devel that would be our primary >> devel branch, then as we approach a release we can branch from >> fedora-devel to f-8, f-9, etc), and then we simply merge or don't merge >> from upstream to our devel branch as we see fit. For things where we >> want to follow upstream, we can actually configure fedora-devel to >> automatically merge any new changes from upstream's master branch in >> anytime we do a pull (in fact, you can do this on a per branch basis, >> any given branch can be told to automatically merge changes from another >> branch into it, or it can be a more static branch that doesn't auto >> merge anything). Had this been the case, then merely setting the >> fedora-devel branch to not automerge from the remote (upstream) devel >> branch would have resulted in all of the auto-rebuilds and things like >> that working just fine on the fedora-devel branch as Jesse mentioned >> needed to happen, but it would have let us see the changes going on in >> the remote tracking branches and everyone who bothered to update their >> rpm repo would see those changes on those remote branches and know >> something was up. >> > You're straying into git specifics here. Different upstream SCMs will > give us different abilities. There are two categories; Distributed and non-distributed. The most important part is that which lets you uniquely identify one particular commit uniquely. git, hg, bzr and pretty much all the more-than-hardly-used-at-all DSCM's use SHA1 or something similar to identify a particular commit and also the history leading up to it. The fact that hg and bzr try to hide them while git does not doesn't mean they don't exist. For non-distributed SCM's (svn, cvs) I'd recommend any of the following: * importing them to whatever dscm happens to be easiest to do all the fancy stuff people want to do * importing tarballs to the dscm that would have been used above * keep using tarballs and patch-files > We'll need to figure out what things, like > this, are important to us, In order of priority: 1. Ability to name one specific commit uniquely 2. Ability to generate tarballs from said commit 3. Easy and cheap branching Only the first two are vital. The third one is for developer convenience and disk-space saving. Assuming 2 works properly, you don't never need to change anything in RPM for this to work. At my day-job, we let our horde of git repositories schedule builds whenever something is pushed to one of three different branches (master, maint, next). It does this by generating a tarball named by the "git describe" output and some very simple sed-hackery. When a signed tag is pushed to a repository the build result is also sent to our beta-release repos. The only pre-processing we do post-checkout is to sed out the version and release fields with parts of the "git describe" output. In the spec-file's %build section, we do sed -i -e "s/##FULL_VERSION##/%{version}-%{release}/" \ version.{h,php,pl,py,sh,lua,whatever} so we never need to have any "preparing for release blah blah" commits cluttering the repository and no package will ever have faulty version numbers. I'd be happy to share our stuff. Although it's got quite a lot of stuff hardcoded into it (paths, server addresses etc) someone interested could perhaps get some mileage out of looking at them. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From pmatilai at redhat.com Mon Jul 14 09:19:21 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 14 Jul 2008 12:19:21 +0300 (EEST) Subject: gtk-sharp2 dependencies In-Reply-To: <487B06A8.4070000@nigelj.com> References: <487B06A8.4070000@nigelj.com> Message-ID: On Mon, 14 Jul 2008, Nigel Jones wrote: > Just an FYI before the Rawhide Report arrives, > > Yes gtk-sharp2 was bumped to 2.12.1 (at my request), yes it has broken the > dependencies BUT: > > The reason this time is that rpm forgot to calculate the mono dependencies > (something that can be expected with any major bump), with the old version of > RPM the same Provides for 2.12.0-2 and 2.12.1-1 were calculated, so there > isn't a need for a mass rebuild, just one of gtk-sharp2. > > So I think it's just a case of been patient while the mono provides bug is > sorted and then be on our way. Yup, there was a string mismatch between current libmagic string and what rpmbuild expected (from ancient file-4.14). Fixed in rpm-4.5.90-0.git8426.7 which just finished building. - Panu - From alexl at users.sourceforge.net Mon Jul 14 08:54:16 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 14 Jul 2008 01:54:16 -0700 Subject: gtk-sharp2 dependencies In-Reply-To: <487B06A8.4070000@nigelj.com> (Nigel Jones's message of "Mon\, 14 Jul 2008 19\:56\:24 +1200") References: <487B06A8.4070000@nigelj.com> Message-ID: <1ik5fou9qf.fsf@allele2.eebweb.arizona.edu> >>>>> "NJ" == Nigel Jones writes: NJ> Just an FYI before the Rawhide Report arrives, Yes gtk-sharp2 was NJ> bumped to 2.12.1 (at my request), yes it has broken the NJ> dependencies BUT: NJ> The reason this time is that rpm forgot to calculate the mono NJ> dependencies (something that can be expected with any major bump), NJ> with the old version of RPM the same Provides for 2.12.0-2 and NJ> 2.12.1-1 were calculated, so there isn't a need for a mass NJ> rebuild, just one of gtk-sharp2. Bummer. I wonder if there was collateral damage to the provides/requires capabilities for other languages as well? NJ> So I think it's just a case of been patient while the mono NJ> provides bug is sorted and then be on our way. Can you post the bug number for this mono provides/requires breakage if there is one? (Presumably it should be filed against the rpm component and/or reported upstream if necessary). Alex From rawhide at fedoraproject.org Mon Jul 14 09:44:25 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 14 Jul 2008 09:44:25 +0000 (UTC) Subject: rawhide report: 20080714 changes Message-ID: <20080714094425.E5DBB209D2E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080713/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080714/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package andika-fonts A font for literacy and beginning readers New package aubio An audio labelling library New package khmeros-fonts Khmer font set created by Danh Hong of the Cambodian Open Institute New package python-dtopt Add options to doctest examples while they are running Updated Packages: abiword-2.6.4-3.fc10 -------------------- * Sun Jul 13 18:00:00 2008 Marc Maurer - 1:2.6.4-3 - We don't include ispell_dictionary_list.xml anymore, so no need to ghost it * Sun Jul 13 18:00:00 2008 Marc Maurer - 1:2.6.4-2 - Update patches to apply without fuzz * Sun Jul 13 18:00:00 2008 Marc Maurer - 1:2.6.4-1 - New upstream release clamav-0.93.3-1.fc10 -------------------- * Sun Jul 13 18:00:00 2008 Enrico Scholz - 0.93.3-1 - updated to 0.93.3; another fix for CVE-2008-2713 (out-of-bounds read on petite files) - put pid instead of pgrp into pidfile of clamav-milter (bz #452359) - rediffed patches fusecompress-1.99.16-1.fc10 --------------------------- * Sun Jul 13 18:00:00 2008 Lubomir Rintel 1.99.16-1 - New upstream release - Fedora patches integrated upstream - Rebuild against newer librlog gnome-commander-1.2.7-0.1.svn1874_trunk.fc10 -------------------------------------------- * Mon Jul 14 18:00:00 2008 Mamoru Tasaka - rev 1874 - Workaround for Decimal offset mode in Hexdump display mode gtk-sharp2-2.12.1-1.fc10 ------------------------ * Sun Jul 13 18:00:00 2008 Xavier Lamien - 2.12.1-1 - Update release. jd-2.0.0-0.8.rc080714.fc10 -------------------------- * Mon Jul 14 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.8.rc080714 - 2.0.0 rc 080714 kdebase-workspace-4.0.98-3.fc10 ------------------------------- * Sun Jul 13 18:00:00 2008 Kevin Kofler 4.0.98-3 - sync kickoff-suspend patch from F9 (loads ksmserver translations) kdepim-4.0.98-3.fc10 -------------------- * Sun Jul 13 18:00:00 2008 Rex Dieter 4.0.98-3 - fix conflict with oxygen-icon-theme kernel-2.6.26-136.fc10 ---------------------- * Sun Jul 13 18:00:00 2008 Kyle McMartin - Linux 2.6.26 * Sun Jul 13 18:00:00 2008 Kyle McMartin - Enable CONFIG_NETDEVICES_MULTIQUEUE (and CONFIG_MAC80211_QOS.) * Sun Jul 13 18:00:00 2008 Dave Jones - 2.6.26-rc9-git12 * Sun Jul 13 18:00:00 2008 Dave Jones - 2.6.26-rc9-git11 * Sat Jul 12 18:00:00 2008 Dave Jones - 2.6.26-rc9-git10 ktorrent-3.1-5.fc10 ------------------- * Sun Jul 13 18:00:00 2008 Roland Wolters - 3.1-1 - Update to version 3.1 libmtp-0.2.6.1-3.fc10 --------------------- * Fri Jul 11 18:00:00 2008 Linus Walleij 0.2.6.1-3 - Loose PAM console permissions, also assume that we can ship documentation again since Doxygen has been updated. Fedora HALd rules for the portable_audio_player capability in 20-acl-management.fdi will change permissions on the device node for each plugged-in device. mksh-35-1.fc10 -------------- * Sun Jul 13 18:00:00 2008 Robert Scheck 35-1 - Upgrade to 35 openoffice.org-3.0.0-0.0.24.1.fc10 ---------------------------------- * Fri Jul 11 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.24-1 - next version - drop integrated openoffice.org-3.0.0.ooo6087.sc.sheetnames.patch - drop integrated openoffice.org-3.0.0.ooo90055.swext.allowadmin.patch - drop integrated workspace.cairo06.patch - drop integrated workspace.ab55.patch - Resolves: rhbz#452385 add postgress-jdbc to default classpath - Resolves: rhbz#454682 expand macro to get correct name for inconsistent, unnecessarily complicated, redundant and nigh universially hated arch-dependant naming scheme for presenter-screen extension ovaldi-5.4.2-2.fc10 ------------------- * Sun Jul 13 18:00:00 2008 Lubomir Rintel 5.4.2-2 - Adjust for newer librpm perl-Gnome2-GConf-1.044-4.fc10 ------------------------------ * Sun Jul 13 18:00:00 2008 Chris Weyl 1.044-4 - skip network tests when building in the buildsys perl-Net-CUPS-0.56-2.fc10 ------------------------- * Sun Jul 13 18:00:00 2008 Chris Weyl 0.56-2 - and remove i18n.h from CUPS.xs. See bz#455190 - add zlib-devel as a BR. See bz#455192 - patch t/03_destination.t to not test add/remove functionality -- this is an admin action under Fedora, if memory serves * Sun Jul 13 18:00:00 2008 Chris Weyl 0.56-1 - update to 0.56 php-pecl-apc-3.0.19-1.fc10 -------------------------- * Wed Jun 25 18:00:00 2008 Tim Jackson - 3.0.19-1 - Update to 3.0.19 - Fix PHP Zend API/ABI dependencies to work on EL-4/5 - Fix "License" tag - Fix encoding of "NOTICE" file - Add registration via PECL redet-8.24-1.fc10 ----------------- * Sun Jul 13 18:00:00 2008 Debarshi Ray - 8.24-1 - Version bump to 8.24. Closes Red Hat Bugzilla bug #447203. - redet.desktop and xdg-open added by upstream. scim-python-0.1.13rc1-1.fc10 ---------------------------- * Mon Jul 14 18:00:00 2008 Huang Peng - 0.1.13rc1-1 - Update to 0.1.13rc1. stardict-3.0.1-11.1.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Caius Chance - 3.0.1-11.fc10 - Disable gucharmap for incompatibility with gucharmap-2. - Refactorized Requires and BuildRequires tags. * Mon Jul 14 18:00:00 2008 Caius Chance - 3.0.1-11.1.fc10 - Enable gucharmap-2. * Thu Jul 10 18:00:00 2008 Caius Chance - 3.0.1-10.fc10 - Rebuilt for gucharmap updation 2.22.1 and pkgconfig .ac name change. * Mon Jun 30 18:00:00 2008 Caius Chance - 3.0.1-9.fc10 - Fixed broken dependencies with gucharmap. suck-4.3.2-23.fc10 ------------------ * Thu Jul 10 18:00:00 2008 Jochen Schmitt 4.3.2-23 - Build agains dynamic inn libraries xorg-x11-drv-radeonhd-1.2.1-3.4.20080713git.fc10 ------------------------------------------------ * Sun Jul 13 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.4.20080713git - Note Fedora package version in radeonhd's Xorg.N.log output. - Snapshot generation updates spec file now - New snapshot (upstream commit 8326ff4fb3d2fff74b11a5391b74866a656380ff): - 8326ff4f: MC: Add a stub for RV770 MCIdle(). - c6dcd8d1: conntest: Add support for RV770 to rhd_conntest. - 20476754: I2C: Add DDC read out support for DDC3/4. - 49b3782f: I2C: Read SDA/SCL mapping for RV620 and up from AtomBIOS GPIO Info block. - 4b7ce33f: Add initial support for RV770 - 9b388fb0: DIG: Add support for ATOM_TRANSMITTER_CONFIG_LINKA_B/B_A. - c258c35f: conntest: test more error conditions. - 45961a0c: sh cmd substitution w/ backticks until git found - 31d76dab: Document more names for xorg/util/macros packages - fde79f9b: Add XORG_* macro names to docs for easy grepping - d44b0def: Name drivers dir "driversdir" - 7b3bd157: Disable unnecessary libtool CXX and F77 checks - cd4ed275: Fix typo in git format-patch instruction Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 22 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so avahi-ui-sharp-0.6.22-11.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 avahi-ui-sharp-0.6.22-11.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 beagle-evolution-0.3.7-7.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 beagle-thunderbird-0.3.7-7.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 deltarpm-3.4-10.fc9.i386 requires librpmdb-4.4.so deltarpm-3.4-10.fc9.i386 requires librpm-4.4.so deltarpm-3.4-10.fc9.i386 requires librpmio-4.4.so evolution-sharp-0.17.4-1.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gbrainy-0.70-3.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 gdb-6.8-15.fc10.i386 requires librpmdb-4.4.so gdb-6.8-15.fc10.i386 requires librpm-4.4.so gecko-sharp2-0.13-1.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gecko-sharp2-0.13-1.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires ghc682 gmime-sharp-2.2.21-1.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.i386 requires mono(atk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.i386 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-do-0.4.2.0-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gsf-sharp-0.8.1-7.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.i386 requires mono(glade-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-5.4.1-19.fc10.i386 requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpmdb-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpm-4.4.so rpmreaper-0.1.4-1.fc10.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.i386 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so tomboy-0.11.0-4.fc10.i386 requires mono(gdk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.i386 requires mono(gtk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.i386 requires mono(pango-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.i386 requires mono(glib-sharp) = 0:2.12.0.0 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) avahi-ui-sharp-0.6.22-11.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 avahi-ui-sharp-0.6.22-11.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 beagle-evolution-0.3.7-7.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 beagle-thunderbird-0.3.7-7.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpmio-4.4.so()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpm-4.4.so()(64bit) deltarpm-3.4-10.fc9.x86_64 requires librpmdb-4.4.so()(64bit) evolution-sharp-0.17.4-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gbrainy-0.70-3.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 gdb-6.8-15.fc10.x86_64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.x86_64 requires librpmdb-4.4.so()(64bit) gecko-sharp2-0.13-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gecko-sharp2-0.13-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires ghc682 gmime-sharp-2.2.21-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.x86_64 requires mono(atk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(gconf-sharp) = 0:2.16.0.0 gnome-do-0.4.2.0-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gsf-sharp-0.8.1-7.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.x86_64 requires mono(glade-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 mono-tools-1.9-4.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.x86_64 requires librpm-4.4.so()(64bit) 1:net-snmp-5.4.1-19.fc10.x86_64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.i386 requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.x86_64 requires librpm-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpm-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpmdb-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.x86_64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) tomboy-0.11.0-4.fc10.x86_64 requires mono(gdk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.x86_64 requires mono(gtk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.x86_64 requires mono(pango-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.x86_64 requires mono(glib-sharp) = 0:2.12.0.0 Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) avahi-ui-sharp-0.6.22-11.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 avahi-ui-sharp-0.6.22-11.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 banshee-1.0.0-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 beagle-0.3.7-7.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 beagle-evolution-0.3.7-7.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 beagle-gnome-0.3.7-7.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 beagle-thunderbird-0.3.7-7.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 deltarpm-3.4-10.fc9.ppc requires librpmdb-4.4.so deltarpm-3.4-10.fc9.ppc requires librpm-4.4.so deltarpm-3.4-10.fc9.ppc requires librpmio-4.4.so evolution-sharp-0.17.4-1.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gnome-vfs-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 f-spot-0.4.3.1-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gbrainy-0.70-3.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gbrainy-0.70-3.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 gdb-6.8-15.fc10.ppc requires librpmdb-4.4.so gdb-6.8-15.fc10.ppc requires librpm-4.4.so gdb-6.8-15.fc10.ppc64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.ppc64 requires librpmdb-4.4.so()(64bit) gecko-sharp2-0.13-1.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gecko-sharp2-0.13-1.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 ghc-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc = 0:6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires ghc682 gmime-sharp-2.2.21-1.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.ppc requires mono(atk-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 gnome-desktop-sharp-2.20.1-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gnome-do-0.4.2.0-2.fc10.ppc requires mono(gconf-sharp) = 0:2.16.0.0 gnome-do-0.4.2.0-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 gnome-sharp-2.20.0-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.ppc requires mono(glade-sharp) = 0:2.12.0.0 gnome-subtitles-0.8-4.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gsf-sharp-0.8.1-7.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 gtksourceview2-sharp-1.0-2.svn89788.2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 ipod-sharp-0.8.0-5.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 mono-addins-0.3.1-2.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 1:net-snmp-5.4.1-19.fc10.ppc requires librpm-4.4.so 1:net-snmp-5.4.1-19.fc10.ppc requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc requires librpm-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc requires librpmio-4.4.so 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpmdb-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpm-4.4.so rpmreaper-0.1.4-1.fc10.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.ppc requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so tomboy-0.11.0-4.fc10.ppc requires mono(gdk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.ppc requires mono(gtk-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.ppc requires mono(pango-sharp) = 0:2.12.0.0 tomboy-0.11.0-4.fc10.ppc requires mono(glib-sharp) = 0:2.12.0.0 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpmio-4.4.so()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpm-4.4.so()(64bit) deltarpm-3.4-10.fc9.ppc64 requires librpmdb-4.4.so()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gdb-6.8-15.fc10.ppc64 requires librpm-4.4.so()(64bit) gdb-6.8-15.fc10.ppc64 requires librpmdb-4.4.so()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) livecd-tools-017.1-1.fc9.ppc64 requires yaboot 1:net-snmp-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) 1:net-snmp-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpmio-4.4.so()(64bit) 1:net-snmp-libs-5.4.1-19.fc10.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 rpmreaper-0.1.4-1.fc10.ppc64 requires librpmbuild-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.ppc64 requires librpm-4.4.so()(64bit) rpmreaper-0.1.4-1.fc10.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.ppc64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From martin.sourada at gmail.com Mon Jul 14 10:03:27 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 14 Jul 2008 12:03:27 +0200 Subject: [F-10 Feature?] Nodoka notification theme Message-ID: <1216029807.2947.47.camel@pc-notebook> Hi, as some of you might know, I'd like to make new notification theme (the currently ugly bubbles [0] with various messages like package updates, battery status, incoming mail, etc.) for Fedora 10 and I am quite unsure, as it is rather a small change, albeit quite visible, whether to create a Feature page for it. The current status is: I've released first public release for testing [1] nearly three months ago, and have been using it since then without any issues, also so far nobody reported any bugs against it. It is also available in Fedora [2] and in order to get it used, you currently need to set gconf '/apps/notification-daemon/theme' key to 'nodoka' (without the quotes). I believe Mathias added some patch to the appearances caplet to set it by itself if specified in the gnome meta-theme, but it does not seem to work currently in rawhide. No gui for selection the theme is available ATM AFAIK. Also there is an issue with the notification-daemon that it crashes when theme is changed, I haven't filled a bug yet (but will probably do so soon). As AFAIK it is a first notification daemon engine/theme created separately from the notification daemon itself, it also needs some wider testing if everything works as expected. For those interested only in the looks, I also have some screenshots available [3][4]. I use compositing when available so the bubbles look slightly better if you have compositing on, either via metacity, compiz or anything else (I use rawhide metacity with compositing on and it works well with it). For test-list: ------------------------------------------------------------------------ I'd be grateful for any testers willing to test this and reporting any issues so that users in F10 will get only the improved experience of the new design and no problems caused by regressions or bugs. You can report issues both in upstream trac [5] or in rhbz. ------------------------------------------------------------------------ For art-list: ------------------------------------------------------------------------ For next release - which will be the one in F10 - I hope to improve the design a little and with enabled compositing perhaps add some animation when showing/hiding (starting from fully transparent, ending with semi-transparent and vice versa). Any suggestions in this matter? ------------------------------------------------------------------------ Thanks for your comments, Martin References: [0] http://mso.fedorapeople.org/nodoka/notify/preview/notify-orig.png [1] https://fedorahosted.org/releases/n/o/nodoka/notification-daemon-engine-nodoka-0.1.0.tar.gz [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=6197 [3] http://mso.fedorapeople.org/nodoka/notify/preview/notify-new-with-compositing.png [4] http://mso.fedorapeople.org/nodoka/notify/preview/notify-new.png [5] https://fedorahosted.org/nodoka/newticket -------------- 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 alexl at users.sourceforge.net Mon Jul 14 10:08:20 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 14 Jul 2008 03:08:20 -0700 Subject: gtk-sharp2 dependencies In-Reply-To: (Panu Matilainen's message of "Mon\, 14 Jul 2008 12\:19\:21 +0300 \(EEST\)") References: <487B06A8.4070000@nigelj.com> Message-ID: <2zbq10u6az.fsf@allele2.eebweb.arizona.edu> >>>>> "PM" == Panu Matilainen writes: PM> On Mon, 14 Jul 2008, Nigel Jones wrote: >> Just an FYI before the Rawhide Report arrives, >> >> Yes gtk-sharp2 was bumped to 2.12.1 (at my request), yes it has >> broken the dependencies BUT: >> >> The reason this time is that rpm forgot to calculate the mono >> dependencies (something that can be expected with any major bump), >> with the old version of RPM the same Provides for 2.12.0-2 and >> 2.12.1-1 were calculated, so there isn't a need for a mass rebuild, >> just one of gtk-sharp2. >> >> So I think it's just a case of been patient while the mono provides >> bug is sorted and then be on our way. PM> Yup, there was a string mismatch between current libmagic string PM> and what rpmbuild expected (from ancient file-4.14). Fixed in PM> rpm-4.5.90-0.git8426.7 which just finished building. Thanks! To speed things up, I'm rebuilding gtk-sharp2 against the new rpm that has just been built. Unfortunately this will take until the next rawhide for the spurious broken deps to go away. But at least it should allow f-spot to be (finally!) rebuilt by Nigel. Alex From dev at nigelj.com Mon Jul 14 10:14:04 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 14 Jul 2008 22:14:04 +1200 Subject: gtk-sharp2 dependencies In-Reply-To: <2zbq10u6az.fsf@allele2.eebweb.arizona.edu> References: <487B06A8.4070000@nigelj.com> <2zbq10u6az.fsf@allele2.eebweb.arizona.edu> Message-ID: <487B26EC.9070702@nigelj.com> Alex Lancaster wrote: >>>>>> "PM" == Panu Matilainen writes: >>>>>> > > PM> On Mon, 14 Jul 2008, Nigel Jones wrote: > >>> Just an FYI before the Rawhide Report arrives, >>> >>> Yes gtk-sharp2 was bumped to 2.12.1 (at my request), yes it has >>> broken the dependencies BUT: >>> >>> The reason this time is that rpm forgot to calculate the mono >>> dependencies (something that can be expected with any major bump), >>> with the old version of RPM the same Provides for 2.12.0-2 and >>> 2.12.1-1 were calculated, so there isn't a need for a mass rebuild, >>> just one of gtk-sharp2. >>> >>> So I think it's just a case of been patient while the mono provides >>> bug is sorted and then be on our way. >>> > > PM> Yup, there was a string mismatch between current libmagic string > PM> and what rpmbuild expected (from ancient file-4.14). Fixed in > PM> rpm-4.5.90-0.git8426.7 which just finished building. > > Thanks! To speed things up, I'm rebuilding gtk-sharp2 against the new > rpm that has just been built. > Heh, I hit a commit conflict with you when you did the rebuild (oops). - Nigel > Unfortunately this will take until the next rawhide for the spurious > broken deps to go away. But at least it should allow f-spot to be > (finally!) rebuilt by Nigel. > > Alex > > From abartlet at samba.org Mon Jul 14 10:21:24 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 14 Jul 2008 20:21:24 +1000 Subject: No answer to easy bug policy In-Reply-To: <487815CB.2090900@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> Message-ID: <1216030884.27495.6.camel@ruth> On Fri, 2008-07-11 at 22:24 -0400, Lyos Gemini Norezel wrote: > Patrice Dumas wrote: > > Hello, > > > > With Rahul, we prepared a new pollicy which aim is to force maintainers > > to answer to easy fix bugs or orphan packages if they fail to do so in a > > one month delay. It may look a bit rude, but hopefully it will help > > spreading co-maintainership and quicker bugfixes. It is at > > > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > > > In my opinion it should be added to the non responsive policy at > > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > > I paste it here. Please comment. It should be proposed to FESCo after > > discussion here. > > > > > > > > > > = No answer to easy bug policy = > > > > == The Problem == > > > > There are several occasions where the individual maintainers are still > > active and working on some software packages while not fixing trivial > > bugs on other software packages. If this occurs over a long period of > > time, the maintainers should seek out co-maintainers or just be > > orphaning the software packages they are not interested in. If it does > > happen for a shorter periods, others can act as a buffer to avoid the > > problem lingering for our users. Other experienced and trusted package > > maintainers, developers or others in the community have offered a > > specific simple solution to the problem in terms of patches or > > recommendations that translate into straight forward solutions. > > Maintainers are wary of stepping on each other's toes and clear > > guidelines helps is setting expectations > > > > == The solution == > > > > When the situation described above happens, somebody (called the > > reporter) can proceed with what is explained below. However, this > > should only be done in one bug at a time for each maintainer, even if > > there are many such bugs for different or the same components. > > To enforce that, a blocker bug should be associated with the bug such > > that it is easy to see which maintainer is already concerned > > by the procedure. > > > > The reporter put the following comment in the bug: > > > > --- > > > > As per the 'No answer to easy bug' policy, please answer within 2 weeks > > whether > > > > * you allow others to fix this bug > > > > * you are not interested enough in that package to really keep on > > * maintaining it by yourself, and are looking for a co-maintainer or > > to orphan the package > > > > If you don't answer after 2 weeks and one remainder lasting also at > > least 2 week the package will be orphaned according to the policy stated > > at > > > > --- > > > > - The reporter blocks a blocker bug, such that before following the > > procedure another reporter can check that the packager hasn't have a > > similar procedure already begun. > > > > - The blocker bug is left for at least 1 month, even if the maintainer > > answered, such that only one procedure per month can be engaged. > > > > > > The idea is to avoid having people be able to bother maintainers more > > than needed by having only one procedure opened at a time, while forcing > > uninterested maintainers to orphan their packages. > > > > == References == > > > > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/EncourageComaintainership > > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages > > * http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers#Outline > > > > > > > > -- > > Pat > > > > > > I'm no developer (not since the 6502 ASM days at any rate), but it seems > to me that this may cause some contention. I hate bureaucracy in all > it's forms, but I can see I slightly modified version of this being put > into use, PROVIDED the majority of developers concerned (ie., at least > 70%) agree to be bound by such rules. Otherwise, you risk losing alot of > people. Indeed. It seems like a stick to hit a stressed developer with - and surely developers under external stresses, who do not maintain Fedora packages as their day, job will be the ones most likely to have this stick waved at them. Their re-action may not be the one they or you want in the short and long term. I don't have a good counter-proposal, except to suggest that these requests be handled as a HR, not a computer science process, and with the greatest of tact. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Mon Jul 14 11:13:44 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 14 Jul 2008 12:13:44 +0100 Subject: gtk-sharp2 dependencies In-Reply-To: <487B26EC.9070702@nigelj.com> References: <487B06A8.4070000@nigelj.com> <2zbq10u6az.fsf@allele2.eebweb.arizona.edu> <487B26EC.9070702@nigelj.com> Message-ID: <1216034024.2203.1.camel@T7.Linux> Hi, > - Nigel > > Unfortunately this will take until the next rawhide for the spurious > > broken deps to go away. But at least it should allow f-spot to be > > (finally!) rebuilt by Nigel. There looks to be a problem with the 0.4.4 sources with an error being thrown when f-image-viewer.h accesses a file from libeog. Not sure if that's down to something broken in rawhide or in f-spot. I'm suspecting rawhide as there is also a similar problem building muine. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 ovasik at redhat.com Mon Jul 14 11:32:10 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Mon, 14 Jul 2008 13:32:10 +0200 Subject: Splitting package xmlto - which way is better? Message-ID: <1216035130.4597.12.camel@dhcp-lab-219.englab.brq.redhat.com> Hello, I would like to ask you about splitting package xmlto. I got request to split xmlto package to throw away passivetex (and TeX) requirements in the case of xmlto usage for building txt/html documentation (rhbz #454341). This change is reasonable, but I'm not sure which way is better. Generally I have two possibilities: 1) Split to xmlto and xmlto-base - with xmlto Requires: xmlto-base . In xmlto-base all binaries, documentation and backends without passivetex requirements. Main package will contain only three backends (fo to dvi/ps/pdf) after that change. This will not break any builds in Fedora Rawhide but raises rpmlint warnings about no binary/documentation in main package. 2) Split to xmlto and xmlto-tex . This will break builds which are using xmlto for building pdf/ps/dvi documentation - additional BuildRequires for xmlto-tex backends subpackage will be required. Which one should be preferred? I like the possibility #1 a bit more, although I guess in long-term is #2 better solution. Any other ideas? Thanks in advance for reactions. Greetings, Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From pmachata at redhat.com Mon Jul 14 11:58:18 2008 From: pmachata at redhat.com (Petr Machata) Date: Mon, 14 Jul 2008 13:58:18 +0200 Subject: byacc vulnerability Message-ID: <20080714115818.GA22494@hridell.englab.brq.redhat.com> Hi everyone, I've just requested a push that fixes #454583: byacc vulnerable to public buffer overflow. The bug has been around for past thirty years, so my guess would be it's rather benign, but what do I know. Owners of packages dependent on byacc might want to rebuild. For F-9, repoquery gives me the following list: alliance-0:5.0-16.20070718snap.fc9.src brltty-0:3.9-2.2.fc9.src checkpolicy-0:2.0.14-1.fc9.src compat-flex-0:2.5.4a-4.fc9.src condor-0:7.0.0-8.fc9.src cproto-0:4.7f-3.fc9.src cvsgraph-0:1.6.1-6.fc9.src dictd-0:1.10.9-2.src evolution-0:2.22.3.1-1.fc9.src geomview-0:1.9.4-8.fc9.src glusterfs-0:1.3.8-0.8.fc9.src gmediaserver-0:0.13.0-3.fc9.src groff-0:1.18.1.4-14.fc9.src gtk-gnutella-0:0.96.5-1.fc9.src hdf-0:4.2r3-2.fc9.src inn-0:2.4.4-1.fc9.src jam-0:2.5-6.fc9.src kannel-0:1.4.1-7.src kdelibs3-0:3.5.9-8.fc9.src linux-atm-0:2.5.0-5.src milter-regex-0:1.7-3.fc9.src monit-0:4.10.1-7.fc9.src ncl-0:5.0.0-11.fc9.src nethack-vultures-0:2.1.0-10.fc8.src pcmciautils-0:014-12.fc9.src postgis-0:1.3.3-1.fc9.src radvd-0:1.1-2.fc9.src rdist-1:6.1.5-45.src rpld-0:1.8-0.3.beta1.fc9.src ruby-0:1.8.6.230-4.fc9.src seedit-0:2.2.0-2.fc9.src squidGuard-0:1.2.0-18.fc9.src syslog-ng-0:2.0.8-1.fc9.src tin-0:1.8.3-4.fc9.src xorg-x11-server-0:1.4.99.905-1.20080701.fc9.src yasm-0:0.6.2-2.fc9.src PM -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From stickster at gmail.com Mon Jul 14 12:01:41 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 14 Jul 2008 08:01:41 -0400 Subject: Splitting package xmlto - which way is better? In-Reply-To: <1216035130.4597.12.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1216035130.4597.12.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <1216036901.24527.26.camel@victoria> On Mon, 2008-07-14 at 13:32 +0200, =?ISO-8859-1?Q?Ond=3Fej_Va=3F=EDk_ wrote: > Hello, > I would like to ask you about splitting package xmlto. > I got request to split xmlto package to throw away passivetex (and TeX) > requirements in the case of xmlto usage for building txt/html > documentation (rhbz #454341). This change is reasonable, but I'm not > sure which way is better. Generally I have two possibilities: > > 1) Split to xmlto and xmlto-base - with xmlto Requires: xmlto-base . In > xmlto-base all binaries, documentation and backends without passivetex > requirements. Main package will contain only three backends (fo to > dvi/ps/pdf) after that change. This will not break any builds in Fedora > Rawhide but raises rpmlint warnings about no binary/documentation in > main package. > 2) Split to xmlto and xmlto-tex . This will break builds which are using > xmlto for building pdf/ps/dvi documentation - additional BuildRequires > for xmlto-tex backends subpackage will be required. > > Which one should be preferred? > > I like the possibility #1 a bit more, although I guess in long-term is > #2 better solution. Any other ideas? I think #2 is definitely the better way to go. The passivetex stuff for building the PDF format, in my experience, has been fragile at best for some time. Although fop is getting closer to usable, and could end up being used by the xmlto scripts for PDF building in the future, it's not there yet -- and when it is, the fop package will also drag in a lot of Java package deps. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Mon Jul 14 12:02:55 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 14 Jul 2008 13:02:55 +0100 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215794681.3687.22.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> Message-ID: <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> 2008/7/11 Doug Ledford : [...] > No offense, but as far as I'm concerned I'd trade your entire rpm update > for the changes I listed above. Nothing in the list of rpm changes I > saw was so earth shattering that it even comes close to the reality of > being able to use a sane SCM as a canoncial source repo IMO. There's nothing to stop you now (AFAICS) using a URL that points into gitweb or cgit to specify the source, ... right? From hughsient at gmail.com Mon Jul 14 12:37:13 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 Jul 2008 13:37:13 +0100 Subject: kernel bug - sound clicks In-Reply-To: <64b14b300807140051g5583d7acs25defb57c8a72d97@mail.gmail.com> References: <64b14b300807110500x135e1dd9ke4b07c097d5ae74b@mail.gmail.com> <1215780034.18964.2.camel@hughsie-work> <64b14b300807140051g5583d7acs25defb57c8a72d97@mail.gmail.com> Message-ID: <1216039033.24296.43.camel@hughsie-work> On Mon, 2008-07-14 at 09:51 +0200, Valent Turkovic wrote: > So as per your blog post this is bug over a year old. Is my bug a > duplicate of it in bugzilla? If so please post the link. In fedora bugzilla I've not checked -- but there's a few in the kernel bugzilla and the alsa bugtracker. > Is there something that we users who aren't developers can do so that > this bug gets fixed faster? Is there some log, some debug output that > would help kernel developers to find how to deal with these sound > chips? Well, to be honest, I'm not sure how to go forward. Using WindowsXP, you don't get the sounds clicks, so either the windows driver has worked out a way of powering up the soundcard without a DC click, or the windows driver just doesn't power down the soundcard. You can be sure there's some vendor whitelist/blacklist trickery going on. We also think this is probably a per-laptop thing, rather than a per-chipset thing, so a kernel blacklist would be pretty hard to populate. The alsa docs explain things a bit better: """ With the automatic power-saving, the driver turns off the codec power appropriately when no operation is required. When no applications use the device and/or no analog loopback is set, the power disablement is done fully or partially. It'll save a certain power consumption, thus good for laptops (even for desktops). The time-out for automatic power-off can be specified via power_save module option of snd-ac97-codec and snd-hda-intel modules. Specify the time-out value in seconds. 0 means to disable the automatic power-saving. The default value of timeout is given via CONFIG_SND_AC97_POWER_SAVE_DEFAULT and CONFIG_SND_HDA_POWER_SAVE_DEFAULT Kconfig options. Setting this to 1 (the minimum value) isn't recommended because many applications try to reopen the device frequently. 10 would be a good choice for normal operations. The power_save option is exported as writable. This means you can adjust the value via sysfs on the fly. For example, to turn on the automatic power-save mode with 10 seconds, write to /sys/modules/snd_ac97_codec/parameters/power_save (usually as root): # echo 10 > /sys/modules/snd_ac97_codec/parameters/power_save Note that you might hear click noise/pop when changing the power state. Also, it often takes certain time to wake up from the power-down to the active state. These are often hardly to fix, so don't report extra bug reports unless you have a fix patch ;-) For HD-audio interface, there is another module option, power_save_controller. This enables/disables the power-save mode of the controller side. Setting this on may reduce a bit more power consumption, but might result in longer wake-up time and click noise. Try to turn it off when you experience such a thing too often. """ Richard. From dwalsh at redhat.com Mon Jul 14 12:48:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Jul 2008 08:48:01 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <1215814435.29864.2.camel@aglarond.local> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <487776F8.3080405@redhat.com> <4877D98C.4040401@blagblagblag.org> <1215814435.29864.2.camel@aglarond.local> Message-ID: <487B4B01.3080609@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: > On Fri, 2008-07-11 at 19:07 -0300, jeff wrote: >> I don't know what the ramifications are, but it definitely has different >> behaviour if you disable using selinux=0 than if you don't. I see no reason why >> it should be loaded, initialized, etc. if it isn't wanted. > > Because relying on boot options is a great way to cause problems for > yourself later on down the line. If you boot with selinux=0, the > installer disables SELinux for the installed system. The fact that we > use a better and more persistent means of disabling it and also one that > can be reversed if you later decide that you want SELinux is a > *positive* thing. > > Jeremy > Also there is little difference between "selinux=0" and selinux=disabled in the /etc/selinux/config file. The init process checks the config file for this entry and then tells the kernel to disable all SELinux components. selinux=0 disables all SELinux components before init runs. At the time init is running there is no loaded policy, so pretty much SELinux is disabled. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7SwEACgkQrlYvE4MpobPhXgCcDn48xGhOVhi292Qy43g235Fp eucAoJzCsnIL0RYHYdOqiCYutcdeNBEE =8qoI -----END PGP SIGNATURE----- From ovasik at redhat.com Mon Jul 14 13:43:37 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Mon, 14 Jul 2008 15:43:37 +0200 Subject: Splitting package xmlto - which way is better? In-Reply-To: <1216036901.24527.26.camel@victoria> References: <1216035130.4597.12.camel@dhcp-lab-219.englab.brq.redhat.com> <1216036901.24527.26.camel@victoria> Message-ID: <1216043017.4597.21.camel@dhcp-lab-219.englab.brq.redhat.com> Paul W. Frields p??e v Po 14. 07. 2008 v 08:01 -0400: > On Mon, 2008-07-14 at 13:32 +0200, =?ISO-8859-1?Q?Ond=3Fej_Va=3F=EDk_ > wrote: > > 2) Split to xmlto and xmlto-tex . This will break builds which are using > > xmlto for building pdf/ps/dvi documentation - additional BuildRequires > > for xmlto-tex backends subpackage will be required. > I think #2 is definitely the better way to go. The passivetex stuff for > building the PDF format, in my experience, has been fragile at best for > some time. Although fop is getting closer to usable, and could end up > being used by the xmlto scripts for PDF building in the future, it's not > there yet -- and when it is, the fop package will also drag in a lot of > Java package deps. Ok, thanks, you are right, will use #2. Therefore those who rely on xmlto while building pdf/ps/dvi documentation during koji build, please add xmlto-tex BuildRequires. Just want to say that xmlto scripts already have support for fop/dblatex (but dblatex brings requirements for TeX packages as well and fop's requirements for Java packages are maybe even more expensive) - but passivetex is still considered as default. When option --extensions is specified, PDF building with passivetex is much better (although you are right that not perfect). Greetings, Ondrej Vasik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From ajax at redhat.com Mon Jul 14 14:10:33 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 14 Jul 2008 10:10:33 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <1216044633.11726.40.camel@localhost.localdomain> On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote: > Hello, > > With Rahul, we prepared a new pollicy which aim is to force maintainers > to answer to easy fix bugs or orphan packages if they fail to do so in a > one month delay. It may look a bit rude, but hopefully it will help > spreading co-maintainership and quicker bugfixes. It is at > > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > > In my opinion it should be added to the non responsive policy at > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > I paste it here. Please comment. It should be proposed to FESCo after > discussion here. The problem with this policy is it assumes people read bug mail. If I read all my bug mail every day, I would get absolutely nothing else accomplished. So, just to head this off ahead of time: Every package owned by xgl-maint that I know of has cvsextras+ set. If there's a trivial bug in one of these packages, please, by all means, fix it. If you find an X package where this is not the case, please let me know. I'll even go one step further. If you're sufficiently interested in X and/or Mesa and _want_ to sign up for the xgl-maint mail deluge, please let me know! I'd totally love you forever. - ajax -------------- 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 dledford at redhat.com Mon Jul 14 14:20:14 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 10:20:14 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216020084.31520.9.camel@wombat.tiptoe.de> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> Message-ID: <1216045214.3687.332.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 09:21 +0200, Nils Philippsen wrote: > On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote: > > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: > [...] > > > The problem really lies with whether or not this would satisfy, as a > > > written offer, the requirements under which we distribute or ask our > > > ambassadors to distribute our binaries. > > > > OK, well regardless, if this meets the requirements, then certainly an > > immutably tagged exploded SCM would too (for far less space requirements > > Leaving aside discussing the merits of it, you don't need to use > immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision > from which you built the package (which should already be immutable). You are correct on that point, but the immutable tag is generally more readable as part of the output of rpm -i . -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dev at nigelj.com Mon Jul 14 14:29:40 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 15 Jul 2008 02:29:40 +1200 Subject: No answer to easy bug policy In-Reply-To: <1216044633.11726.40.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> Message-ID: <487B62D4.5000302@nigelj.com> Adam Jackson wrote: > On Sat, 2008-07-12 at 02:04 +0200, Patrice Dumas wrote: > >> Hello, >> >> With Rahul, we prepared a new pollicy which aim is to force maintainers >> to answer to easy fix bugs or orphan packages if they fail to do so in a >> one month delay. It may look a bit rude, but hopefully it will help >> spreading co-maintainership and quicker bugfixes. It is at >> >> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >> >> In my opinion it should be added to the non responsive policy at >> http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers >> I paste it here. Please comment. It should be proposed to FESCo after >> discussion here. >> > > The problem with this policy is it assumes people read bug mail. If I > read all my bug mail every day, I would get absolutely nothing else > accomplished. > Exactly, heck I don't own that many packages, but when I wake up in the morning, there is a combination of 100-200 emails at times, composing of mostly bugmail, mailing lists that I feel are too important to filter, or I have forgotten to filter, and spam, I skim through it all, see nothing important (i.e. nothing that looks interesting, or from the redhat bugzilla) continue with my plans for the day and login to bugzilla get to the 'frontpage.cgi' (which imo is damn useful) and go "what the, when was THAT bug reported" and notice that it was slipped in the middle of a batch of gnome bugs. So please give maintainers a break from fearing of missing an 'easy bug', we make mistakes (honest), we miss things, we forget to tell people that the reason why the bug isn't fixed is because we are working on getting brand new version y packaged that'd fix it better than a one line patch, heck, we are humans! - Nigel > So, just to head this off ahead of time: Every package owned by > xgl-maint that I know of has cvsextras+ set. If there's a trivial bug > in one of these packages, please, by all means, fix it. If you find an > X package where this is not the case, please let me know. > > I'll even go one step further. If you're sufficiently interested in X > and/or Mesa and _want_ to sign up for the xgl-maint mail deluge, please > let me know! I'd totally love you forever. > > - ajax > From nphilipp at redhat.com Mon Jul 14 14:36:24 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 14 Jul 2008 16:36:24 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216045214.3687.332.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> Message-ID: <1216046184.8308.26.camel@gibraltar.str.redhat.com> On Mon, 2008-07-14 at 10:20 -0400, Doug Ledford wrote: > On Mon, 2008-07-14 at 09:21 +0200, Nils Philippsen wrote: > > On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote: > > > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: > > [...] > > > > The problem really lies with whether or not this would satisfy, as a > > > > written offer, the requirements under which we distribute or ask our > > > > ambassadors to distribute our binaries. > > > > > > OK, well regardless, if this meets the requirements, then certainly an > > > immutably tagged exploded SCM would too (for far less space requirements > > > > Leaving aside discussing the merits of it, you don't need to use > > immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision > > from which you built the package (which should already be immutable). > > You are correct on that point, but the immutable tag is generally more > readable as part of the output of rpm -i . I don't understand why that thing should be (human-)readable, it's just a pointer to the exact state of things which was used to build a binary package. Correlating this to a human-readable version/release needs to be done of course so that these make sense. I think it should be done in a way where the resulting SRPMs still contain what amounts to the upstream tarball plus patch(es) so that you can easily pass around self-contained source packages where it is clear what is upstream and what Fedora/RHEL/... added. Note that this doesn't necessarily mean that a developer can't work in an exploded tree -- I think the patches could be generated from an exploded tree. To ensure that this really works (and the packages are self-contained), the build system would probably have to use these source packages for building and not work directly from the exploded tree. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From dledford at redhat.com Mon Jul 14 14:53:00 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 10:53:00 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216046184.8308.26.camel@gibraltar.str.redhat.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> <1216046184.8308.26.camel@gibraltar.str.redhat.com> Message-ID: <1216047180.3687.361.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 16:36 +0200, Nils Philippsen wrote: > On Mon, 2008-07-14 at 10:20 -0400, Doug Ledford wrote: > > On Mon, 2008-07-14 at 09:21 +0200, Nils Philippsen wrote: > > > On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote: > > > > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: > > > [...] > > > > > The problem really lies with whether or not this would satisfy, as a > > > > > written offer, the requirements under which we distribute or ask our > > > > > ambassadors to distribute our binaries. > > > > > > > > OK, well regardless, if this meets the requirements, then certainly an > > > > immutably tagged exploded SCM would too (for far less space requirements > > > > > > Leaving aside discussing the merits of it, you don't need to use > > > immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision > > > from which you built the package (which should already be immutable). > > > > You are correct on that point, but the immutable tag is generally more > > readable as part of the output of rpm -i . > > I don't understand why that thing should be (human-)readable, it's just > a pointer to the exact state of things which was used to build a binary > package. It doesn't have to be, but it might be nice. I would find it far easier to parse the tag in my head than the sha. That's one complaint I have with git, I rather wish it would hide the shas instead of putting them front and center. But, that's just personal preference. > Correlating this to a human-readable version/release needs to be done of > course so that these make sense. I think it should be done in a way > where the resulting SRPMs still contain what amounts to the upstream > tarball plus patch(es) so that you can easily pass around self-contained > source packages where it is clear what is upstream and what > Fedora/RHEL/... added. > > Note that this doesn't necessarily mean that a developer can't work in > an exploded tree -- I think the patches could be generated from an > exploded tree. To ensure that this really works (and the packages are > self-contained), the build system would probably have to use these > source packages for building and not work directly from the exploded > tree. We do this internally now for the RHEL4 and RHEL5 kernels. The kernel maintainer has a git repo, we work from that repo, we send patches to the maintainer internally, they commit to the repo, then come build time, they spit out a tarball and a set of patches to import into CVS and then the build happens from CVS. It's cumbersome, and it introduces a few problems in that if you make a patch that touches file that are part of the git repo itself, but not part of what you want exported to the CVS checkins (such as patches to the scripts that generate a tarball and patches from the git repo), then those have to be filtered out before you check things into CVS etc. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 pjones at redhat.com Mon Jul 14 15:35:45 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 14 Jul 2008 11:35:45 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4877D6E3.1090806@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <4871ED07.7050904@poolshark.org> <48722021.5020908@gmail.com> <48722A98.10405@poolshark.org> <4872363A.9070509@gmail.com> <4872493E.6040306@poolshark.org> <1215597493.29818.11.camel@wombat.tiptoe.de> <487535C4.9030704@blagblagblag.org> <4877CA65.1050904@redhat.com> <4877D6E3.1090806@blagblagblag.org> Message-ID: <487B7251.8080907@redhat.com> jeff wrote: > Peter Jones wrote: >> Robert Nichols wrote: >> >>> Anaconda already allows you to add arbitrary kernel parameters when >>> configuring the bootloader. I always add "vga=791" and "selinux=0". >> >> There's a whitelist to determine which ones are propagated to the >> bootloader config, though. > > Is selinux=0 on the whitelist? > > I still don't understand why doing "boot: linux selinux=0" > wouldn't/shouldn't be passed to grub. Well, in the past it used the config file to turn it off, IIRC. In general that's preferred over having to add things to the boot command line that become required for the system to boot up correctly. -- Peter From pjones at redhat.com Mon Jul 14 15:39:53 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 14 Jul 2008 11:39:53 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <4877D98C.4040401@blagblagblag.org> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <487776F8.3080405@redhat.com> <4877D98C.4040401@blagblagblag.org> Message-ID: <487B7349.3010802@redhat.com> jeff wrote: > Peter Jones wrote: > > Does the system boot up correctly afterwards? > > Yes, assuming the "Starting in permissive mode" is correct. That seems to match all the important criteria -- it doesn't enforce the permissions scheme on you. It doesn't get "in the way". > > What does "getenforce" say when you run it? > > "Disabled" > > > I don't know what the ramifications are, but it definitely has different > behaviour if you disable using selinux=0 than if you don't. I see no > reason why it should be loaded, initialized, etc. if it isn't wanted. We're not stopping you from setting it to disabled in the config file, we're just not helping you do so, either. Really, permissive is good enough here. If you're really /actively/ concerned about it, the barrier to disabling it completely is very low. If you're not, permissive is enough. Since this seems to work, I don't think we'll be making any further changes in anaconda to support this fringe use case. -- Peter From pertusus at free.fr Mon Jul 14 15:42:13 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Jul 2008 17:42:13 +0200 Subject: No answer to easy bug policy In-Reply-To: <1216030884.27495.6.camel@ruth> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> Message-ID: <20080714154212.GA2569@free.fr> On Mon, Jul 14, 2008 at 08:21:24PM +1000, Andrew Bartlett wrote: > > > > I'm no developer (not since the 6502 ASM days at any rate), but it seems > > to me that this may cause some contention. I hate bureaucracy in all > > it's forms, but I can see I slightly modified version of this being put > > into use, PROVIDED the majority of developers concerned (ie., at least > > 70%) agree to be bound by such rules. Otherwise, you risk losing alot of > > people. > > Indeed. It seems like a stick to hit a stressed developer with - and > surely developers under external stresses, who do not maintain Fedora > packages as their day, job will be the ones most likely to have this > stick waved at them. That's not what my experience is. Bug with fix not acted upon is almost always by people @ redhat. But I really don't want to start a flamewar about who are the good and the bad guys I want a policy for bug with fixes. > Their re-action may not be the one they or you > want in the short and long term. It is obvious that it is not a policy to make maintainers happy. It is here to make those who report bug with fixes and users happy. > I don't have a good counter-proposal, except to suggest that these > requests be handled as a HR, not a computer science process, and with > the greatest of tact. A policy helps not having to need tact. There is a standard template and the one who enforce the policy is not responsible of it, FESCo is. -- Pat From pjones at redhat.com Mon Jul 14 15:48:17 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 14 Jul 2008 11:48:17 -0400 Subject: Request to re-add option to disable SELinux - compromise In-Reply-To: <487B4B01.3080609@redhat.com> References: <1215029424.5130.13.camel@perihelion> <1215030141.17856.30.camel@localhost.localdomain> <4871AA56.3000302@blagblagblag.org> <4871CCB0.6030508@fedoraproject.org> <48726D88.7020407@blagblagblag.org> <4872BCB4.5020402@fedoraproject.org> <48727079.60304@blagblagblag.org> <4872BFF5.7010500@fedoraproject.org> <48727495.9070603@blagblagblag.org> <4872C3C3.50303@fedoraproject.org> <20080707200809.GA17236@devserv.devel.redhat.com> <4872789D.80006@blagblagblag.org> <487776F8.3080405@redhat.com> <4877D98C.4040401@blagblagblag.org> <1215814435.29864.2.camel@aglarond.local> <487B4B01.3080609@redhat.com> Message-ID: <487B7541.4050306@redhat.com> Daniel J Walsh wrote: > Also there is little difference between "selinux=0" and selinux=disabled > in the /etc/selinux/config file. > > The init process checks the config file for this entry and then tells > the kernel to disable all SELinux components. selinux=0 disables all > SELinux components before init runs. At the time init is running there > is no loaded policy, so pretty much SELinux is disabled. Since the advent of upstart, it's not init doing this any more, but in general you're right. -- Peter From jkeating at redhat.com Mon Jul 14 15:48:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 11:48:35 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080714154212.GA2569@free.fr> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> Message-ID: <1216050515.3631.0.camel@localhost.localdomain> On Mon, 2008-07-14 at 17:42 +0200, Patrice Dumas wrote: > That's not what my experience is. Bug with fix not acted upon is almost > always by people @ redhat. But I really don't want to start a flamewar > about who are the good and the bad guys I want a policy for bug with > fixes. Whilst I do like that you're trying to solve this problem, I think one big hole here is who decides that the "fix" is either easy, or right? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 pertusus at free.fr Mon Jul 14 16:08:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Jul 2008 18:08:43 +0200 Subject: No answer to easy bug policy In-Reply-To: <487B62D4.5000302@nigelj.com> References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> <487B62D4.5000302@nigelj.com> Message-ID: <20080714160843.GC2569@free.fr> On Tue, Jul 15, 2008 at 02:29:40AM +1200, Nigel Jones wrote: >> > bugzilla get to the 'frontpage.cgi' (which imo is damn useful) and go > "what the, when was THAT bug reported" and notice that it was slipped in > the middle of a batch of gnome bugs. > > So please give maintainers a break from fearing of missing an 'easy > bug', we make mistakes (honest), we miss things, we forget to tell > people that the reason why the bug isn't fixed is because we are working > on getting brand new version y packaged that'd fix it better than a one > line patch, heck, we are humans! The policy tries to respect that, while still being effective. I have put 3 weeks before the procedure is started, a first comment, a remainder after 2 weeks and then 2 weeks before the procedure of orphaning which will still leave time for the packager to react and will put the issue in the public arena. This can certainly be improved, just propose. The delay can be expanded, for example, the issue is more, in my opinion to have those bugs tracked than to have those fixed in a given time. -- Pat From drago01 at gmail.com Mon Jul 14 16:13:15 2008 From: drago01 at gmail.com (drago01) Date: Mon, 14 Jul 2008 18:13:15 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080714160843.GC2569@free.fr> References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> <487B62D4.5000302@nigelj.com> <20080714160843.GC2569@free.fr> Message-ID: On Mon, Jul 14, 2008 at 6:08 PM, Patrice Dumas wrote: > On Tue, Jul 15, 2008 at 02:29:40AM +1200, Nigel Jones wrote: >>> >> bugzilla get to the 'frontpage.cgi' (which imo is damn useful) and go >> "what the, when was THAT bug reported" and notice that it was slipped in >> the middle of a batch of gnome bugs. >> >> So please give maintainers a break from fearing of missing an 'easy >> bug', we make mistakes (honest), we miss things, we forget to tell >> people that the reason why the bug isn't fixed is because we are working >> on getting brand new version y packaged that'd fix it better than a one >> line patch, heck, we are humans! > > The policy tries to respect that, while still being effective. I have > put 3 weeks before the procedure is started, a first comment, a > remainder after 2 weeks and then 2 weeks before the procedure of > orphaning which will still leave time for the packager to react and will > put the issue in the public arena. This can certainly be improved, just > propose. The delay can be expanded, for example, the issue is more, in > my opinion to have those bugs tracked than to have those fixed in a > given time. Can we just add them to a tracker "easy bugs" and maintainers can just go there and fix this bugs as long as the ACLs are open? If a maintainer does NOT want this he shouldn't have enabled open ACLs at all. "Everybody can access my packages, but don't dare to touch them" is just plain stupid. From pertusus at free.fr Mon Jul 14 16:19:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Jul 2008 18:19:18 +0200 Subject: No answer to easy bug policy In-Reply-To: <1216050515.3631.0.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> Message-ID: <20080714161918.GD2569@free.fr> On Mon, Jul 14, 2008 at 11:48:35AM -0400, Jesse Keating wrote: > On Mon, 2008-07-14 at 17:42 +0200, Patrice Dumas wrote: > > That's not what my experience is. Bug with fix not acted upon is almost > > always by people @ redhat. But I really don't want to start a flamewar > > about who are the good and the bad guys I want a policy for bug with > > fixes. > > Whilst I do like that you're trying to solve this problem, I think one > big hole here is who decides that the "fix" is either easy, or right? There is nothing about the fix being right. The criterion is having a fix. These 3 situation may qualify for a bug easy to fix: * a patch is proposed, attached to the bug, and tested * a trivial change is proposed to the .spec, preferably tested * help is offered, with different possibilities outlined, but the maintainer has to ack or specify his preferences for the style of the proposed fix, so that the contributor can create a suitable patch Of course this is not a formal definition, but I think it is quite easy to delineate. I hope that contributors won't abuse the recourse to this policy, of course. -- Pat From fedora-devel-list at krp.org.uk Mon Jul 14 16:21:13 2008 From: fedora-devel-list at krp.org.uk (Kevin Page) Date: Mon, 14 Jul 2008 17:21:13 +0100 Subject: No answer to easy bug policy (and hal examples) In-Reply-To: <1216044633.11726.40.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> Message-ID: <1216052473.14139.60.camel@keyop> On Mon, 2008-07-14 at 10:10 -0400, Adam Jackson wrote: > Every package owned by xgl-maint that I know of has cvsextras+ set. > If there's a trivial bug in one of these packages, please, by all > means, fix it. Generally, is there a place to pool "easy" bugs that members of the cvsextras group could fix or escalate? (I couldn't find one). Specifically, there are a couple of F8 hal crasher bugs (#431377 and #452701). I've recently isolated existing upstream patches for them, but they need an errata/backport to F8. I reckon accepted upstream patches probably means they're "easy". Is this the sort of thing the cvsextras group can deal with? I'm doubtless being unfair to the hal package maintainer - it may well all be in hand - but I'm tainted by my experience of a pilot-link fix being blocked for 5 months on a hal update; even advice/a response from the hal maintainers would have been endlessly helpful (it was left NEEDINFO). I find it particularly odd given that hal is key to systems operation. I'm sure it happens because of the very understandable swamping reasons Adam mentions... but nonetheless, as someone who's been trying to solve the odd problem and provide the odd patch here and there, it's quite frustrating and disheartening to have your efforts stalled - or even undone - by these non-technical issues. Yeah, I know that's just how life is ;) I say, I only dug up the upstream patches recently. Perhaps I'd have done this at an earlier point, and would certainly be encouraged to do so again in the future, if I were more confident they'd make it into the package in a timely manner. So perhaps what's needed is a mechanism for a trusted group (cvsextras?) to enact what are essentially solved bugs? If they don't feel confident about applying and pushing a fix, then at least the package maintainer should be left with a smaller "non-easy" bug list. Regards, kev. From pertusus at free.fr Mon Jul 14 16:20:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Jul 2008 18:20:56 +0200 Subject: No answer to easy bug policy In-Reply-To: References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> <487B62D4.5000302@nigelj.com> <20080714160843.GC2569@free.fr> Message-ID: <20080714162056.GE2569@free.fr> On Mon, Jul 14, 2008 at 06:13:15PM +0200, drago01 wrote: > > Can we just add them to a tracker "easy bugs" and maintainers can just > go there and fix this bugs as long as the ACLs are open? > If a maintainer does NOT want this he shouldn't have enabled open ACLs at all. > "Everybody can access my packages, but don't dare to touch them" is > just plain stupid. Currently ACLs has to be open to be able to implement an existing policy: http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages And we also need something for packaages that don't have acl open. -- Pat From pmatilai at redhat.com Mon Jul 14 16:22:16 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 14 Jul 2008 19:22:16 +0300 (EEST) Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1215810605.3687.37.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215810605.3687.37.camel@firewall.xsintricity.com> Message-ID: On Fri, 11 Jul 2008, Doug Ledford wrote: > On Fri, 2008-07-11 at 20:12 +0300, Panu Matilainen wrote: > Maybe the difference between what you are trying to say and are saying > is the problem here. Maybe misinterpreting what I said is part of the problem, but certainly not the only one: this thread got started rather backwards with out-of-the-blue wild handwaving about flag days and delaying things for something that's not even described anywhere, much less implemented. Also this thread has gotten all mixed up between RPM and Fedora package management SCM - what RPM implements is not necessarily equal to what Fedora uses / permits to use. > You see, here's what I said (in a nutshell): > > "We need these headers, everything else can wait, but just adding these > allows us to move forward in using exploded source repos. All the other > features a person might code into rpm can be added later because they > can be worked around in the meantime via scripts, makefiles, macros, > build system tweaks, etc." > > You responded: > > "Yeah, the headers are a no brainer - But doing something with them > takes some effort and I don't have the time plus I got these fancy > plans, so, umm, no...that'll have to wait until F11" > > And my response was: > > "Well, that's just fine...so I guess we can't make progress on things > because those of us that are here and willing to work on this aren't > allowed to." > > And your response was: > > "Hey, if you want to work on it, go ahead! Don't get mad at me." > > So, my question is, which is it? Are you going to block things, or not. > I was angry because you said it would have to wait until F11 on the > grounds of your grand plans, while all I asked for was just the headers, > no more. You *assumed* I wanted you to implement some sort of full > featured support. As did Seth. People should what I wrote more closely > instead of letting their imaginations run wild. I asked for the bare > minimum. Now that we have that straightened out, let me rephrase the > question. Are the headers, and the headers alone, too much to ask for > in the context of F10? "Lets add some new tags and see if we can fit a design + implementation to them later" does not fly very well with me. RPM has enough examples of useless (and unused) tags already (quite possibly because they're easier to add than argue), I'm not particularly interested in adding more. Before promising anything at all, I want to see a description of what you are really trying to accomplish short-term and long-term and how, posted to rpm-maint at lists.rpm.org so that people from other distro-camps can comment too (remember that RPM isn't a Fedora-only thing). Let's see your proposal first and then we'll see what comes out of it and when. Arguing about tags, versions and schedules is waste of time at this stage. - Panu - From pertusus at free.fr Mon Jul 14 16:00:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Jul 2008 18:00:22 +0200 Subject: No answer to easy bug policy In-Reply-To: <1216044633.11726.40.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <1216044633.11726.40.camel@localhost.localdomain> Message-ID: <20080714160022.GB2569@free.fr> On Mon, Jul 14, 2008 at 10:10:33AM -0400, Adam Jackson wrote: > > The problem with this policy is it assumes people read bug mail. If I > read all my bug mail every day, I would get absolutely nothing else > accomplished. It is not this policy which assumes this, it is being a fedora maintainer. It is even put down on a document, but it doesn't need to, it is self-evident. The document is here: http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Deal_with_reported_bugs_in_a_timely_manner The objective of this policy is to have a way to force maintainers to look at bugs with fixes, though maintaining is based on voluntary work. > So, just to head this off ahead of time: Every package owned by > xgl-maint that I know of has cvsextras+ set. If there's a trivial bug > in one of these packages, please, by all means, fix it. If you find an > X package where this is not the case, please let me know. It is not a policy for xgl-maint packages. Having cvsextras+ doesn't mean that anybody can apply a change, there is a need for an ack from the maintainer. This policy is here to force the maintainer to answer or realize that he is too busy to maintain the package on his own. > I'll even go one step further. If you're sufficiently interested in X > and/or Mesa and _want_ to sign up for the xgl-maint mail deluge, please > let me know! I'd totally love you forever. If the xgl-maint have too much work they can ask for co-maintainership. -- Pat From jspaleta at gmail.com Mon Jul 14 16:28:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 08:28:34 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487A3DD0.3040702@gmail.com> References: <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> <487A3DD0.3040702@gmail.com> Message-ID: <604aa7910807140928y4d387bb6u7ea467dece47e7c2@mail.gmail.com> On Sun, Jul 13, 2008 at 9:39 AM, Les Mikesell wrote: > As long as the old method continues to work, what's the problem with adding > a way to improve it going forward? Yes, clearly there will need to keep something similar to the "old method" around for dealing with tarball releases while this new process moves forward. If we make the change, we'll have to support both ways of doing it, and track the update on the new process on a package by package basis. My largest concern continues to be source distribution. If we have to support both models of packaging source control then I'm not sure what our source distribution ends up looking like. Is it a mix of exploded branches and srpms? I'd also need to get an idea of what our local patchsets would look like in the new cloned vcs packaging. I've had people tell me that they very much prefer the style of different patch files as shipped in our srpm delineated based on purpose and not necessarily a single merged patch file that includes multiple changes. We are starting to see the single patch files which are multiple patches merged into a single patch and I've had someone complain specifically about it being more difficult to understand. The point being, some of our users do make use of the sources as provided in the SRPM. If we move away from that we'll need to re-educate those users on how to to use the new source approach to do things like back out a specific patch that was included for a specific purpose. -jef From mcepl at redhat.com Mon Jul 14 16:20:19 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 14 Jul 2008 18:20:19 +0200 Subject: No answer to easy bug policy References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> Message-ID: <3vask5xiru.ln2@ppp1053.in.ipex.cz> On 2008-07-14, 15:48 GMT, Jesse Keating wrote: > Whilst I do like that you're trying to solve this problem, > I think one big hole here is who decides that the "fix" is > either easy, or right? A bug with EasyFix keyword, and if you don't agree just change the Keyword (yes, there should be some ACLs so that it cannot be turned on again, but there are hopefully not that many people who would be arguing with)? Mat?j From kevin.kofler at chello.at Mon Jul 14 16:31:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 16:31:45 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> Message-ID: Doug Ledford redhat.com> writes: > The distinction between upstream development and Fedora development is > artificial. And it's a nice way to keep upstream developers from having > any interest in managing their own packages. Congratulations on that. Nonsense. Upstream developers don't want to do development in Fedora's SCM. They want to do development in their own SCM, make platform-independent releases and then package those releases (or get them packaged) for Fedora and other distributions. I don't see why tarballs wouldn't be an appropriate format for such releases. Kevin Kofler From kevin.kofler at chello.at Mon Jul 14 16:48:49 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 16:48:49 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> Message-ID: Doug Ledford redhat.com> writes: > First, before I respond to the rest of this, keep in mind that the > "overwhelming majority" of packages needs to be quantified. > Furthermore, at least one very significant package (the kernel) does not > massage files at all between SCM tag and tarball. And to be honest, I > would be very surprised to find many projects that do have any > significant difference between a tagged release in the SCM of their > choice and their tarballs. So I would like some examples please, which > shouldn't be hard to come up with since it is the "overwhelming > majority" of projects that obviously think when they tag something in > their SCM it doesn't need to match the tarball they make with the same > tag version... Many packages don't have a public SCM at all; some have a private SCM, some one-man projects have no SCM at all. (For example, there is _no_ SCM for Quarticurve and Quarticurve-KWin, unless you call fully exploded copies of old versions sitting around on my HDD an "SCM".) And even if they use an SCM, they can: * make releases without tags: For example, the weekly trunk snapshots of KDE don't get tags, nor do the extragear tarball releases. * modify tags: This is particularly common in Subversion which allows using a tag like a branch. KDE normally uses the following workflow: 1. tag release 2. prerelease tarballs from the tags to packagers 3. fix any showstoppers by merging fixes to the tag 4. respin tarballs for the modules which were thus fixed 5. make the release public so the contents of the tag can change between when we first build the package and the public release of the new version. The checksummed tarballs handle this robustly, we can just upload a new respun tarball with a new checksum. But automatically picking up a respin can break the build because sometimes we had a showstopper fix as a patch, which of course no longer applies if the release is respun including the fix, so building from whatever the current contents of the tag are rather than from whatever we used breaks reproducibility of builds. * require postprocessing: It's not just autotools which are a problem there. For example, the KDE extragear releases use a fairly clever script collecting translations from elsewhere in the SVN repository. Kevin Kofler From dledford at redhat.com Mon Jul 14 16:52:59 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 12:52:59 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> Message-ID: <1216054379.3687.405.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 16:31 +0000, Kevin Kofler wrote: > Doug Ledford redhat.com> writes: > > The distinction between upstream development and Fedora development is > > artificial. And it's a nice way to keep upstream developers from having > > any interest in managing their own packages. Congratulations on that. > > Nonsense. Upstream developers don't want to do development in Fedora's SCM. > They want to do development in their own SCM, make platform-independent > releases and then package those releases (or get them packaged) for Fedora and > other distributions. I don't see why tarballs wouldn't be an appropriate format > for such releases. The magic words above were "(or get them packaged)". Our separate SCM setup really just means they don't want to futz with it. However, if the process for an upstream developer was more like: Develop in their own SCM, push SCM changes to (Fedora/Debian/SuSE repos), kick off build process in (Fedora/Debian/SuSE), done. Well, I can list a few developers that might finally be willing to manage packaging their own stuff up where as right now they simply don't want to. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Mon Jul 14 17:01:12 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 13:01:12 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> Message-ID: <1216054872.3687.412.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 16:48 +0000, Kevin Kofler wrote: > Doug Ledford redhat.com> writes: > > First, before I respond to the rest of this, keep in mind that the > > "overwhelming majority" of packages needs to be quantified. > > Furthermore, at least one very significant package (the kernel) does not > > massage files at all between SCM tag and tarball. And to be honest, I > > would be very surprised to find many projects that do have any > > significant difference between a tagged release in the SCM of their > > choice and their tarballs. So I would like some examples please, which > > shouldn't be hard to come up with since it is the "overwhelming > > majority" of projects that obviously think when they tag something in > > their SCM it doesn't need to match the tarball they make with the same > > tag version... > > Many packages don't have a public SCM at all; some have a private SCM, some > one-man projects have no SCM at all. (For example, there is _no_ SCM for > Quarticurve and Quarticurve-KWin, unless you call fully exploded copies of old > versions sitting around on my HDD an "SCM".) > > And even if they use an SCM, they can: > * make releases without tags: For example, the weekly trunk snapshots of KDE > don't get tags, nor do the extragear tarball releases. > * modify tags: This is particularly common in Subversion which allows using a > tag like a branch. KDE normally uses the following workflow: > 1. tag release > 2. prerelease tarballs from the tags to packagers > 3. fix any showstoppers by merging fixes to the tag > 4. respin tarballs for the modules which were thus fixed > 5. make the release public > so the contents of the tag can change between when we first build the package > and the public release of the new version. The checksummed tarballs handle this > robustly, we can just upload a new respun tarball with a new checksum. But > automatically picking up a respin can break the build because sometimes we had > a showstopper fix as a patch, which of course no longer applies if the release > is respun including the fix, so building from whatever the current contents of > the tag are rather than from whatever we used breaks reproducibility of builds. > * require postprocessing: It's not just autotools which are a problem there. > For example, the KDE extragear releases use a fairly clever script collecting > translations from elsewhere in the SVN repository. I understand that some packages don't have an SCM, or that they use a totally unsuitable SCM for distributed repo management. It's a shame they won't be able to make use of the new functionality without first making internal changes to their own work flow processes, but it's hardly a reason not to make the new functionality available to others. So far, we've heard of kernel, the Infiniband and MPI stacks, and probably gnome that could make use of this change. Myself, I think that is sufficient to be worthwhile regardless of the state of KDE or the overwhelming majority of packages. You get enough benefit out of just the listed packages alone to make the changes of worth. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 Mon Jul 14 17:01:32 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 17:01:32 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> Message-ID: Doug Ledford redhat.com> writes: > how we are not allowed to unpack a tarball, > change the contents and then repack it back up and put it back on the > cache under the same name. Except we can. Our lookaside cache is explicitly designed to be robust for things like unversioned tarballs (which some upstreams still produce) or respun tarballs (like KDE and some other projects do). So the "sources" file stores not only the file name, but also a checksum. Now of course this means the original tarball is also preserved (it's still there in the lookaside cache under the old checksum), but still this is something to keep in mind in your redesign. Kevin Kofler From kevin.kofler at chello.at Mon Jul 14 17:06:11 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 17:06:11 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <48779612.2050000@gmail.com> <1215812104.3687.57.camel@firewall.xsintricity.com> <4877D729.9000909@gmail.com> <604aa7910807111508t54f60346te952ea0f7d95bfc7@mail.gmail.com> <1215815831.3687.91.camel@firewall.xsintricity.com> <604aa7910807111557x18d27a5ej7086e6be446291ec@mail.gmail.com> <1215817491.3224.42.camel@localhost.localdomain> <1215826146.3687.121.camel@firewall.xsintricity.com> <3742943F-3035-4D66-9D7F-D5BFE77B3345@j2solutions.net> <1215908968.3687.292.camel@firewall.xsintricity.com> Message-ID: Doug Ledford redhat.com> writes: > And this is at least partially our own fault. For instance, the fact > that upstream opensm, libibcommon, libibumad, libibmad, librdmacm, > libibcm, and a few others from the OFED package set run autogen.sh is > because someone in Fedora told me to tell them to. I originally told > them not to and I was "corrected". How about simply using a build system which doesn't suck? http://www.cmake.org/ > For example, you can't really clone a subversion repository. SVK might help there, or you could use one of the git-svn bridges out there. I think the bigger problem is that many upstreams either don't use a public SCM at all, have mutable tags (CVS, git and others allow moving a tag to a different revision (CVS even allows doing that per-file, so you can have a mix of old and new revisions in a tag), SVN even allows making changes to a tag which exist nowhere else in the repository) or release tarballs which don't match the SCM for several reasons. Kevin Kofler From kevin.kofler at chello.at Mon Jul 14 17:15:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 17:15:57 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> Message-ID: Bill Crawford gmail.com> writes: > There's nothing to stop you now (AFAICS) using a URL that points into > gitweb or cgit to specify the source, ... right? That won't work. You have to upload the sources into the lookaside cache, and the Source: tag has to end with the name of the tarball you uploaded. And gitweb and the like aren't suitable for checkouts at all, only for browsing. Kevin Kofler From dledford at redhat.com Mon Jul 14 17:16:50 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 13:16:50 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> Message-ID: <1216055810.3687.417.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 13:02 +0100, Bill Crawford wrote: > 2008/7/11 Doug Ledford : > [...] > > No offense, but as far as I'm concerned I'd trade your entire rpm update > > for the changes I listed above. Nothing in the list of rpm changes I > > saw was so earth shattering that it even comes close to the reality of > > being able to use a sane SCM as a canoncial source repo IMO. > > There's nothing to stop you now (AFAICS) using a URL that points into > gitweb or cgit to specify the source, ... right? You could point to a repo, but would need a rather complex URL or Source0 line in order specify things like the branch or tag. What's more though is the fact that if you want to support both srpm style packages and src repo style packages, then you really shouldn't overload source0 like that, and you would ideally still like to be able to have a URL that's *about* the package, also not overloaded to be an scm. So, yeah, you *could*, but it would not work nicely with srpm style packaging and such. Not to mention that you would need a very specific syntax for the URL since just the URL itself for a src repo does not always denote the repo type (several repo types can have an http url for example). -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 Mon Jul 14 17:19:19 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 17:19:19 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1216054379.3687.405.camel@firewall.xsintricity.com> Message-ID: Doug Ledford redhat.com> writes: > The magic words above were "(or get them packaged)". Our separate SCM > setup really just means they don't want to futz with it. However, if > the process for an upstream developer was more like: > > Develop in their own SCM, push SCM changes to (Fedora/Debian/SuSE > repos), kick off build process in (Fedora/Debian/SuSE), done. They'd still have to update the specfile (or equivalent, e.g. the debian/ directory) for the individual distribution. Uploading the tarball isn't the hard part of packaging, it can even be scripted (and I also don't see how it would be any easier to push the SCM changes than to upload the release tarball), updating the specfiles is. Kevin Kofler From a.badger at gmail.com Mon Jul 14 17:40:36 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 10:40:36 -0700 Subject: No answer to easy bug policy In-Reply-To: <20080712090750.GD2762@free.fr> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> Message-ID: <487B8F94.7090602@gmail.com> Patrice Dumas wrote: > On Sat, Jul 12, 2008 at 10:59:24AM +0200, Patrice Dumas wrote: >> On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: >>> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >> I have hopefully adressed th ecomments, by stating that this is a policy >> for bug fixes, not easy bug as such. Also added a 3 weeks delay before >> the procedure is started, precise a bit what is a bug easy to fix and >> put explicitely the cleaning of blocker bugs on the reporter. > > Still on > https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance > Instead of orphaning, what about adding comaintainers? That makes for more responsibility on the part of the person who thinks that the bug is an easy fix to evaluate this in terms of correctness, the future effects of the patch, and what is going on upstream. This would be separate from any other policy allowing people to fix EasyFix+evaluated correct bugs (like mschwendt's spec file cleanups.) -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 sundaram at fedoraproject.org Mon Jul 14 17:57:55 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 Jul 2008 23:27:55 +0530 Subject: No answer to easy bug policy In-Reply-To: <487B8F94.7090602@gmail.com> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> Message-ID: <487B93A3.2080404@fedoraproject.org> Toshio Kuratomi wrote: > Patrice Dumas wrote: >> On Sat, Jul 12, 2008 at 10:59:24AM +0200, Patrice Dumas wrote: >>> On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: >>>> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >>> I have hopefully adressed th ecomments, by stating that this is a policy >>> for bug fixes, not easy bug as such. Also added a 3 weeks delay before >>> the procedure is started, precise a bit what is a bug easy to fix and >>> put explicitely the cleaning of blocker bugs on the reporter. >> >> Still on >> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >> > Instead of orphaning, what about adding comaintainers? That makes for > more responsibility on the part of the person who thinks that the bug is > an easy fix to evaluate this in terms of correctness, the future effects > of the patch, and what is going on upstream. The intro covers that: "If this occurs over a long period of time, the maintainers should seek out co-maintainers or just be orphaning the software packages they are not interested in. If it does happen for a shorter periods, others can act as a buffer to avoid the problem lingering for our user" Rahul From wtogami at redhat.com Mon Jul 14 18:00:11 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 14 Jul 2008 14:00:11 -0400 Subject: Rawhide Orphan Status Message-ID: <487B942B.1070103@redhat.com> system-summary lipstik MegaMek xeuphoric gnome-applet-tvn24 aasaver kbiof nautilus-share AGReader system-switch-java sinjdoc man-pages-da gnome-ppp Some of these are new orphans. All orphans will be removed from rawhide sometime after July 18th if they are not claimed before then. Please talk to releng if you want to revive an already removed orphan. Warren Togami wtogami at redhat.com From dledford at redhat.com Mon Jul 14 17:30:13 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 13:30:13 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1216054379.3687.405.camel@firewall.xsintricity.com> Message-ID: <1216056613.1519.9.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 17:19 +0000, Kevin Kofler wrote: > Doug Ledford redhat.com> writes: > > The magic words above were "(or get them packaged)". Our separate SCM > > setup really just means they don't want to futz with it. However, if > > the process for an upstream developer was more like: > > > > Develop in their own SCM, push SCM changes to (Fedora/Debian/SuSE > > repos), kick off build process in (Fedora/Debian/SuSE), done. > > They'd still have to update the specfile (or equivalent, e.g. the debian/ > directory) for the individual distribution. It takes less than you think for this. We now have opensm in fedora CVS. Pull that package, then do make prep, then go look at their scripts directory. I don't *use* what's in there, because I have my own versions, but they are already set up to deal with the differences between Red Hat and SuSE RPMs in that directory and in their spec file. So, for them, it *would* be a push, build operation. Of course, that's assuming we let their spec file through review...I don't use that either. > Uploading the tarball isn't the > hard part of packaging, it can even be scripted (and I also don't see how it > would be any easier to push the SCM changes than to upload the release > tarball), I think you'd be amazed at just how hard it was to get the Infiniband community doing *any* tarballs. Even today, out of the 26 packages they produce, only about 12 have tarballs available. The rest are git repos only. Of course, I'm not saying they are common...most of them were new to open source development as of about 3 or 4 years ago. They didn't cut their open source teeth on tarballs. First it was subversion, then git. But, I think it's fair to say that as times change and progress, this lack of familiarity with tarballs and tarball releases will probably only grow as various dscms become more popular and easier to use. But, that's just my own personal crystal ball speaking, I could be wrong. > updating the specfiles is. For lots of packages, this can be a write once and forget operation for the most part, only needing a changelog/version update per build, which can also be scripted. Again, look in the opensm prep sources, I believe they still make a makefile entry that updates the opensm.spec.in and spits out the correct opensm.spec. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 caillon at redhat.com Mon Jul 14 18:22:05 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 14 Jul 2008 14:22:05 -0400 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: References: Message-ID: <487B994D.6080005@redhat.com> Siddharth Upmanyu wrote: > :-) big assumption... i dont think rawhide is supposed to work (just-work) > i cant launch dolphin after logging in (if you wanted to know) Rawhide is supposed to work. The point of rawhide is to get feedback on items before we release. If rawhide doesn't work, that makes it rather difficult to get feedback. Which is the problem we hit frequently. I'm pretty annoyed that many people seem to treat rawhide as a dumping ground. From limb at jcomserv.net Mon Jul 14 18:23:05 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 14 Jul 2008 13:23:05 -0500 (CDT) Subject: Rawhide Orphan Status In-Reply-To: <487B942B.1070103@redhat.com> References: <487B942B.1070103@redhat.com> Message-ID: <53484.198.175.55.5.1216059785.squirrel@mail.jcomserv.net> > system-summary > lipstik > MegaMek > xeuphoric > gnome-applet-tvn24 > aasaver > kbiof > nautilus-share > AGReader > system-switch-java > sinjdoc > man-pages-da > gnome-ppp > > Some of these are new orphans. All orphans will be removed from rawhide > sometime after July 18th if they are not claimed before then. Please > talk to releng if you want to revive an already removed orphan. I'd love to take a peek at some of these, but pkgdb is spewing 500s. > Warren Togami > wtogami at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From drago01 at gmail.com Mon Jul 14 18:25:47 2008 From: drago01 at gmail.com (drago01) Date: Mon, 14 Jul 2008 20:25:47 +0200 Subject: Rawhide Orphan Status In-Reply-To: <53484.198.175.55.5.1216059785.squirrel@mail.jcomserv.net> References: <487B942B.1070103@redhat.com> <53484.198.175.55.5.1216059785.squirrel@mail.jcomserv.net> Message-ID: On Mon, Jul 14, 2008 at 8:23 PM, Jon Ciesla wrote: > >> system-summary >> lipstik >> MegaMek >> xeuphoric >> gnome-applet-tvn24 >> aasaver >> kbiof >> nautilus-share >> AGReader >> system-switch-java >> sinjdoc >> man-pages-da >> gnome-ppp >> >> Some of these are new orphans. All orphans will be removed from rawhide >> sometime after July 18th if they are not claimed before then. Please >> talk to releng if you want to revive an already removed orphan. > > I'd love to take a peek at some of these, but pkgdb is spewing 500s. " I'm going to restart our postgres server. This will mean a bit of downtime for koji, accounts, admin.fp.o" From jspaleta at gmail.com Mon Jul 14 18:27:14 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 10:27:14 -0800 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <1215999441.29945.430.camel@dfarning.desktop.org> References: <1215999441.29945.430.camel@dfarning.desktop.org> Message-ID: <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> On Sun, Jul 13, 2008 at 5:37 PM, David Farning wrote: > I just want to let those of you who do not follow political intrigue > know that OLPC is spinning off the development of Sugar to Sugar Labs > [1]. > > Once we get things untangled, we hope that Sugar development can be more > responsive to the needs of other distributions such as Fedora and > Redhat. > > If you have any questions or comments about Sugar or Sugar Labs please > feel free to ?ask on the Sugar development mailing list [2] or contact > me personally [3]. I'm sort of following it. Here's the thing... sadly I don't have as much time as I would like to even start helping with this in a more direct way. My really big question is what can we do to get the people actually using the Sugar interface? And not just the target audience for olpc..but we need to get older people using the interface as well, people we can get involved in the development process via bug reports and patches. I think it really comes down to being able to provide an alternative Sugar desktop that our Fedora users can live and work inside of. Locally I'm in contact with some teachers who are basically sitting on a pile of slightly dated surplus Dell desktops that the military gave away. Some have been put in use, but there's still a pile of them. I'd like to take a few of them and make a Sugar lab, but I'm not really sure how I can do that from a policy standpoint. I can't just walk into the school system and setup a lab. I could try to set one up here at the university but I doubt anyone would really touch it. I'm just not sure how to make effective use of the resource, even if I got my hands on a few of those computers. -jef From kevin at scrye.com Mon Jul 14 18:49:43 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 14 Jul 2008 12:49:43 -0600 Subject: Request for sponsorship In-Reply-To: References: Message-ID: <20080714124943.0ec33b50@ohm.scrye.com> On Sat, 12 Jul 2008 00:55:16 +0530 rakesh.pandit at gmail.com ("Rakesh Pandit") wrote: > Hello all, > For more then a month I am trying to learn fedora and fedora > packaging. In the course of time I have submitted 7 packages for > review: > 1. 455056: Review Request: weex - Fast WEb EXchanger non-interactive > FTP client 2. 455039: Review Request: php-oauth - PHP Authentication > library for desktop to web applications > 3. 454895: Review Request: sitecopy - Tool for easily maintaining > remote web sites > 4. 454395: Review Request: php-xmpphp - PHP XMPP Library > 5. 445027: Review Request: dnrd - A caching, forwarding DNS proxy > server 6. 448397: Review Request: ntop - A network traffic probe > similar to the UNIX top command > 7. 449879: Review Request: Zile - Zile Is Lossy Emacs > > Unofficial reviews for helping packages: > 1. 454125: Review Request: gtest - Google C++ testing framework > 2. 434861: Review Request: python-tftpy - Python TFTP library > 3. 252108: Review Request: python-html5lib - A python based HTML5 > parser/tokenizer > 4. 445152: Review Request: yacpi - ncurses based acpi viewer > > I have done some mistakes also in process and learnt from them. I am > looking for sponsor. May somebody sponsor me? Greetings. I would be happy to look at sponsoring you... Let me go ahead and do some reviews of some of the above packages and then I can sponsor you once they are in good shape. Look for some official reviews later tonight hopefully. > I am also coordinating gnome kashmiri translation whose hosting has > been shifted to fedorahosting [1]. Present owner would like to shift > ownership to me as soon as I get Fedora account active. > > [1] https://fedorahosted.org/ks-gnome-trans/ Cool. :) > Regards, > Rakesh Pandit kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dledford at redhat.com Mon Jul 14 18:50:21 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 14:50:21 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215810605.3687.37.camel@firewall.xsintricity.com> Message-ID: <1216061421.1891.37.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 19:22 +0300, Panu Matilainen wrote: > On Fri, 11 Jul 2008, Doug Ledford wrote: > > On Fri, 2008-07-11 at 20:12 +0300, Panu Matilainen wrote: > > Maybe the difference between what you are trying to say and are saying > > is the problem here. > > Maybe misinterpreting what I said is part of the problem, but certainly > not the only one: this thread got started rather backwards with > out-of-the-blue wild handwaving about flag days and delaying things for > something that's not even described anywhere, much less implemented. You corrected me on the fact that it doesn't require an rpm flag day to change the headers. That doesn't mean they wouldn't still be useful so I could work without running a hacked up rpm locally, but it's no longer the big issue it was. > Also > this thread has gotten all mixed up between RPM and Fedora package > management SCM - what RPM implements is not necessarily equal to what > Fedora uses / permits to use. True, I never said it wasn't. I said, in a nutshell, I need the headers from RPM and that's it, everything else I can do elsewhere. > > You see, here's what I said (in a nutshell): > > > > "We need these headers, everything else can wait, but just adding these > > allows us to move forward in using exploded source repos. All the other > > features a person might code into rpm can be added later because they > > can be worked around in the meantime via scripts, makefiles, macros, > > build system tweaks, etc." > > > > You responded: > > > > "Yeah, the headers are a no brainer - But doing something with them > > takes some effort and I don't have the time plus I got these fancy > > plans, so, umm, no...that'll have to wait until F11" > > > > And my response was: > > > > "Well, that's just fine...so I guess we can't make progress on things > > because those of us that are here and willing to work on this aren't > > allowed to." > > > > And your response was: > > > > "Hey, if you want to work on it, go ahead! Don't get mad at me." > > > > So, my question is, which is it? Are you going to block things, or not. > > I was angry because you said it would have to wait until F11 on the > > grounds of your grand plans, while all I asked for was just the headers, > > no more. You *assumed* I wanted you to implement some sort of full > > featured support. As did Seth. People should what I wrote more closely > > instead of letting their imaginations run wild. I asked for the bare > > minimum. Now that we have that straightened out, let me rephrase the > > question. Are the headers, and the headers alone, too much to ask for > > in the context of F10? > > "Lets add some new tags and see if we can fit a design + implementation to > them later" does not fly very well with me. RPM has enough examples of > useless (and unused) tags already (quite possibly because they're easier > to add than argue), I'm not particularly interested in adding more. Sure, no problem. > Before promising anything at all, I want to see a description of what you > are really trying to accomplish short-term and long-term and how, posted > to rpm-maint at lists.rpm.org so that people from other distro-camps can > comment too (remember that RPM isn't a Fedora-only thing). When you consider that all I asked for was the headers, and the rest of it *would* be Fedora specific, then I fail to see the justification for proposing internal build system specifics to rpm-maint at lists.rpm.org for approval. If it were more than the headers, then sure. But just the headers when everything else would be outside rpm? No. Especially given that if it's as trivial as you say to add the headers, we could just carry the ones we want locally without needing them to be upstream. After all, as you pointed out, unpatched rpms will deal with the packages just fine, it's only the building rpm that needs to be patched. So even if we carried the patch in just our copy of rpm, our rpms would still be usable on other systems (srpms would be a different matter, but as this is all about doing a src repo instead of an srpm, it's a given that someone else would need a patched up rpm to build our stuff anyway). > Let's see your proposal first and then we'll see what comes out of it and > when. Arguing about tags, versions and schedules is waste of time at this > stage. If you've read this thread, and read those notes I sent, then you know how much is written up so far. It should at least be enough to know where I'm headed. If not, I apologize, but I don't really feel like spending even *more* time writing things up to satisfy your request for a proposal. I've already got a certain contingent giving me grief for the lack of real code so far, so I'd rather get to work on the code stuff instead of more writing. Besides, I work best when I'm both designing and coding at the same time. So now that I know there isn't a db schema to worry about in the rpmdb and that adding the headers is trivial, I'll just go do that and then proceed with making modifications to a local koji build server and various dscm setups here on my own where I can prototype things as I see fit. Sorry to have bothered you. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 at scrye.com Mon Jul 14 18:53:53 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 14 Jul 2008 12:53:53 -0600 Subject: source file audit - 2008-07-05 In-Reply-To: <935ead450807061305h4f2e2580j99c7d761ab4c0c34@mail.gmail.com> References: <20080705141930.5f42d27f@ohm.scrye.com> <935ead450807061305h4f2e2580j99c7d761ab4c0c34@mail.gmail.com> Message-ID: <20080714125353.4ce5f7ab@ohm.scrye.com> On Sun, 6 Jul 2008 15:05:50 -0500 jeff at ocjtech.us ("Jeffrey Ollie") wrote: > 2008/7/5 Kevin Fenzi : > > > > jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr > > jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis > > These two packages have been marked as dead and have been blocked from > rawhide, I'm not sure why these are still being checked. :( Looks like I broke dead.package handling when trying to fix something else. I will get this fixed for the next run. Thanks for pointing it out. > > jcollie:BADURL:sofia-sip-1.12.9.tar.gz:sofia-sip > > I'm not sure why this is marked as having a bad URL, as I was able to > download the source tarball just fine. Is it because the source url > differs from the "canonical" sourceforge URL? Yes. Any of the various sourceforge urls aside from the one suggested by the guidelines (http://downloads.sourceforge.net///) doesn't work right for automated download. My script got: --2008-07-02 07:26:00-- http://dl.sourceforge.net/sofia-sip/sofia-sip-1.12.9.tar.gz Resolving dl.sourceforge.net... failed: Message too long. wget: unable to resolve host address `dl.sourceforge.net' > Jeff > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jul 14 18:54:35 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 00:24:35 +0530 Subject: [F-10 Feature?] Nodoka notification theme In-Reply-To: <1216029807.2947.47.camel@pc-notebook> References: <1216029807.2947.47.camel@pc-notebook> Message-ID: <487BA0EB.103@fedoraproject.org> Martin Sourada wrote: > Hi, > > as some of you might know, I'd like to make new notification theme (the > currently ugly bubbles [0] with various messages like package updates, > battery status, incoming mail, etc.) for Fedora 10 and I am quite > unsure, as it is rather a small change, albeit quite visible, whether to > create a Feature page for it. It is a visible change and requires testing from more folks. I guess that would qualify for making it a feature. Rahul From notting at redhat.com Mon Jul 14 16:35:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Jul 2008 12:35:29 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080714161918.GD2569@free.fr> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <20080714161918.GD2569@free.fr> Message-ID: <20080714163529.GA10456@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Mon, Jul 14, 2008 at 11:48:35AM -0400, Jesse Keating wrote: > > On Mon, 2008-07-14 at 17:42 +0200, Patrice Dumas wrote: > > > That's not what my experience is. Bug with fix not acted upon is almost > > > always by people @ redhat. But I really don't want to start a flamewar > > > about who are the good and the bad guys I want a policy for bug with > > > fixes. > > > > Whilst I do like that you're trying to solve this problem, I think one > > big hole here is who decides that the "fix" is either easy, or right? > > There is nothing about the fix being right. The criterion is having a > fix. These 3 situation may qualify for a bug easy to fix: Wait, you want to escalate sanctions (or whatever you'd like to call them) without any knowledge of whether or not the fix is *right*? Bill From notting at redhat.com Mon Jul 14 15:07:09 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Jul 2008 11:07:09 -0400 Subject: Issue with re- or unbranding In-Reply-To: <4878CF0A.1000405@kanarip.com> References: <4878CF0A.1000405@kanarip.com> Message-ID: <20080714150709.GC5020@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > Resulting in "Welcome to Fedora" when a machine boots -both Live Media > and Installation media. > > No biggy, but I'm not sure whether replacing the contents of > /etc/fedora-release (from fedora-release) would give my any trouble, and > if so, whether we need to replace fedora-release when rebranding as well. The idea is that if you're adding packages, etc., you'd be pointing at your own repos, in which case you already want to modify *-release. Bill From notting at redhat.com Mon Jul 14 15:11:22 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Jul 2008 11:11:22 -0400 Subject: Testing wanted: bootconf In-Reply-To: References: Message-ID: <20080714151122.GD5020@nostromo.devel.redhat.com> Sam Varshavchik (mrsam at courier-mta.com) said: > Feedback is kindly requested for bootconf, in updates-testing: > > http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5995 > > This new package installs a basic GUI for selecting a boot kernel (it's > an editor for grub.conf), and enabling or disabling a few command kernel > boot option. The "bootconf" rpm is a baseline command line tool, the > "bootconf-gui" rpm is the gnome front end. Is this related to system-config-boot at all, or a different implementation with similar goals? Bill From dledford at redhat.com Mon Jul 14 19:18:43 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 15:18:43 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216006639.4572.15.camel@code.and.org> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <935ead450807112138r1f89a46bsc3ce2ba595725d6f@mail.gmail.com> <1215871445.3687.190.camel@firewall.xsintricity.com> <1215893713.3224.54.camel@localhost.localdomain> <1215908404.3687.282.camel@firewall.xsintricity.com> <1216006639.4572.15.camel@code.and.org> Message-ID: <1216063123.1891.52.camel@firewall.xsintricity.com> On Sun, 2008-07-13 at 23:37 -0400, James Antill wrote: > On Sat, 2008-07-12 at 20:20 -0400, Doug Ledford wrote: > > > It's not head in the sand Jesse. It's that following the daytime soap > > opera that is rpm4 vs rpm5 vs jbj vs everyone else isn't the least bit > > worth my time. > > Doug, if I did some patches for the Linux kernel and acted as you have > the last couple of days I'd be ignored or flamed to a crisp ... Depends on whether or not your patches were correct and solved a problem. The linux kernel community has both forgiven and harbored some really atrocious behavior in the past if the person's code was good. > likely > to never have my patches looked at. > If you'd spoken to anyone involved with rpm, Well, until Panu's announcement, I didn't know he was working on rpm. > yum Really? Probably 99% of the changes I'm talking about don't involve yum, so that would seem an odd place to go... > or Fedora rel-eng I did talk to Jesse about it in the past, but just like every single other time I've talked to either Fedora or Red Hat rel-eng about this sort of thing, no one has the incentive to make it work. And really, this is no surprise...this change won't markedly improve rel-eng's lives, it will make them slightly more complex. It's the developers that benefit from this. So I had just resigned myself to the idea that rel-eng isn't ever going to make this happen for the developers, someone would just have to do it themselves. Anyway, I'll repeat what I said to Jesse when he said I was burying my head in the sand. You will never make me feel guilty for not being intimately familiar with the political and personnel makeup of an area of coding that is so far outside of my own area of normal work. You can try to all you want, but since I don't blame and/or chastise people for not being intimately familiar with what kernel leuitenant to send which type of patch to when they aren't kernel hackers themselves, I refuse to accept blame from other people when I'm in a similar situation. > at > any point you'd have been told what was happening and how you should go > about getting what you want. Pretending there was or is any kind of > confusion about rpm's future is like someone pretending they thought > Linux might merge with OpenSolaris. Last I knew, rpm5 isn't dead, so you could of fooled me. Are you saying that even if the people still working on rpm5 put out a new version that's so totally kick ass that it makes our incremental changes to rpm4 look like something cooked up in a child's Easy Bake Oven then we would still stick with rpm4? The fact of the matter is that there exists a split in the rpm development process with two parties going two different ways, and if you claim to know which path you will follow before those paths have actually played out far enough to know which path is the best path, then your politics are overriding your judgment of the technical merits and that would be counter to Fedora's goal of being the *BEST* all free open source software distribution. I seriously hope that this isn't the case. > The fact that you are still trying to blame everyone else for your own > mistakes Really? Did I actually throw blame at someone, or accuse them of something? I did say that Panu said that the headers would be a piece of cake, but also said they are F11 material. That's been the only thing I've complained about/accused anyone of to date. That's mainly because I wanted the headers in place so I could start playing with the scripts and stuff I was going to place around those headers to make things work. If you recall from my email asking for those headers, I made it clear that I *thought* adding them was a bigger deal than it was and that if there was already going to be an rpm flag day to do the other upgrades to rpm, that I wanted the headers to go in to avoid a double flag day. Panu corrected me on that issue. However, his correction also pointed out just how simple and no-brainer it would be to add the headers so we could play with things, so it was sort of a double edged sword in terms of whether or not it supported my side of the argument or his. In any case, the only accusation/blame I *ever* made in this thread was that Panu's decision was blocking me up. And I stand by that. However, since his clarification also made it clear that the headers aren't an rpm flag day event, I can go off and modify my rpm separately and work without those changes in the official rpm somewhat easier, which is why in a later email I said I had just about beat this thread to death and I was going off to code. Actually James, I think I've behaved rather well...for a kernel engineer that can both take and dish out the stuff that gets thrown around in the kernel community. Could you imagine if Al Viro were writing this instead of me? > and trying to tell them what they should be doing for _you_ and > how/when they should be doing it. I asked for *one* thing, a simple thing, and said I would do the rest myself. And I've also said I would just go off and do it. So where exactly are you pulling the justification for this statement from? > While they are still trying to > patiently help you, You know, I just don't see this thread the way you do James. There has been *some* amount of patiently helping me, a far larger amount of constructive back and forth in the form of "you would need to make sure you handled this, and took care of that" (maybe you consider the constructive back and forth to be patiently helping, but seeing as it's back and forth with me producing as many valid arguments as anyone else, I see that as back and forth...you have to be educating me for it to be patiently helping). There's also been more than I would care to see of "I don't think this is a good idea", "It can't be done, we *must* have tarballs", "The world would come to an end if we did as you suggest" type negativity. I don't mind negativity based in fact, but some of it has been based in dogma, and that I could care less to hear. > speaks volumes. The letter you have written is both inaccurate and unjustified, which in my opinion "speaks volumes" far more than anything I've written. While I've attempted to set some facts straight, I have also attempted to refrain from the petty and vindictive retaliations this unconstructive email most certainly deserved. You're welcome. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 Mon Jul 14 19:45:19 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 19:45:19 +0000 (UTC) Subject: No login after KDE 4.0.98 rawhide update References: <487B994D.6080005@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > Rawhide is supposed to work. The point of rawhide is to get feedback on > items before we release. If rawhide doesn't work, that makes it rather > difficult to get feedback. Which is the problem we hit frequently. I'm > pretty annoyed that many people seem to treat rawhide as a dumping ground. You probably didn't mean to imply that anyway, but (just so people don't get the wrong impression) I want to make clear that KDE SIG is _not_ treating Rawhide as a dumping ground. On the contrary, KDE 4.1 is now in RC state and we are planning to push it as an update for Fedora 9 in 2 to 4 weeks (because it fixes many bugs in KDE 4.0 and readds some features which were lost in the 3.5->4.0 transition), so it is expected to fully work! Kevin Kofler From kevin.kofler at chello.at Mon Jul 14 19:58:11 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Jul 2008 19:58:11 +0000 (UTC) Subject: Issue with re- or unbranding References: <4878CF0A.1000405@kanarip.com> <20080714150709.GC5020@nostromo.devel.redhat.com> Message-ID: Bill Nottingham redhat.com> writes: > The idea is that if you're adding packages, etc., you'd be pointing > at your own repos, in which case you already want to modify *-release. Not necessarily. It is usually enough to add a *-release file, without modifying fedora-release. Even if you modify some packages, you can easily override Fedora's versions e.g. by using Epochs. Kevin Kofler From chasd at silveroaks.com Mon Jul 14 20:04:16 2008 From: chasd at silveroaks.com (chasd) Date: Mon, 14 Jul 2008 15:04:16 -0500 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <20080714185030.EA8818E02D7@hormel.redhat.com> References: <20080714185030.EA8818E02D7@hormel.redhat.com> Message-ID: <98706142-7B1E-4427-91FB-1CA46B20CFC1@silveroaks.com> On Jul 14, 2008, at 1:50 PM, Jeff Spaleta wrote: > My really big question is what can we do to get the people actually > using the Sugar interface? Instead of "Here's this cool hardware, and oh it comes with this software we call Sugar" to "Here's this cool software named Sugar, and if you need new hardware, this OLPC thing is cost effective, and has some neat features." You want to get people hooked on Sugar ( pun intended ) to drive OLPC adoption ? Charles Dostale From martin.sourada at gmail.com Mon Jul 14 20:05:44 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 14 Jul 2008 22:05:44 +0200 Subject: [F-10 Feature?] Nodoka notification theme In-Reply-To: <487BA0EB.103@fedoraproject.org> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> Message-ID: <1216065944.3210.2.camel@localhost.localdomain> On Tue, 2008-07-15 at 00:24 +0530, Rahul Sundaram wrote: > It is a visible change and requires testing from more folks. I guess > that would qualify for making it a feature. > > Rahul > Thanks for the advice. Created and submitted for approval [1]. Thanks, Martin References: [1] https://fedoraproject.org/wiki/Features/NodokaNotificationTheme -------------- 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 katzj at redhat.com Mon Jul 14 20:08:21 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 14 Jul 2008 16:08:21 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215810605.3687.37.camel@firewall.xsintricity.com> Message-ID: <1216066101.4217.40.camel@aglarond.local> On Mon, 2008-07-14 at 19:22 +0300, Panu Matilainen wrote: > "Lets add some new tags and see if we can fit a design + implementation to > them later" does not fly very well with me. RPM has enough examples of > useless (and unused) tags already (quite possibly because they're easier > to add than argue), I'm not particularly interested in adding more. Also, it's easy to add new tags in the private, external range (100000+) for doing things and then when things are working, it's easy to then move them to be real assigned header tags. Think of adding a new header tag as like adding a new syscall. Once added, they can't be removed. So the idea is to make sure that the implementation and usage is sound before they're added. But there's a range for experimenting and finding out what works available also Jeremy From jspaleta at gmail.com Mon Jul 14 20:16:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 12:16:32 -0800 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <98706142-7B1E-4427-91FB-1CA46B20CFC1@silveroaks.com> References: <20080714185030.EA8818E02D7@hormel.redhat.com> <98706142-7B1E-4427-91FB-1CA46B20CFC1@silveroaks.com> Message-ID: <604aa7910807141316o617c429ancbc049cbad1ba2c3@mail.gmail.com> On Mon, Jul 14, 2008 at 12:04 PM, chasd wrote: > You want to get people hooked on Sugar ( pun intended ) to drive OLPC > adoption ? I want to drive Sugar development...regardless of how its adopted. The olpc maybe cool, but as a piece of software Sugar needs to flourish on other hardware..including alpha workstations if we can manage it. Fedora as a community is a mix of software users and developers. We use hardware only because we don't have the ability..yet..to run the software as part of our own neural nets. So as a result the hardware is diverse through our community..but the software is shared. For Sugar to find a home and to gain a community following, we need to position and champion Sugar as a cool piece of software divorced from any particular piece of hardware. -jef From caillon at redhat.com Mon Jul 14 20:22:26 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 14 Jul 2008 16:22:26 -0400 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: References: <487B994D.6080005@redhat.com> Message-ID: <487BB582.4040701@redhat.com> Kevin Kofler wrote: > Christopher Aillon redhat.com> writes: >> Rawhide is supposed to work. The point of rawhide is to get feedback on >> items before we release. If rawhide doesn't work, that makes it rather >> difficult to get feedback. Which is the problem we hit frequently. I'm >> pretty annoyed that many people seem to treat rawhide as a dumping ground. > > You probably didn't mean to imply that anyway, but (just so people don't get > the wrong impression) I want to make clear that KDE SIG is _not_ treating > Rawhide as a dumping ground. On the contrary, KDE 4.1 is now in RC state and we > are planning to push it as an update for Fedora 9 in 2 to 4 weeks (because it > fixes many bugs in KDE 4.0 and readds some features which were lost in the > 3.5->4.0 transition), so it is expected to fully work! Right, I wasn't targeting KDE specifically. It was more of a general statement that there are still a non-zero amount of people who treat rawhide as such, and we need to fix that. From sundaram at fedoraproject.org Mon Jul 14 20:23:49 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 01:53:49 +0530 Subject: [F-10 Feature?] Nodoka notification theme In-Reply-To: <1216065944.3210.2.camel@localhost.localdomain> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> Message-ID: <487BB5D5.2000602@fedoraproject.org> Martin Sourada wrote: > On Tue, 2008-07-15 at 00:24 +0530, Rahul Sundaram wrote: >> It is a visible change and requires testing from more folks. I guess >> that would qualify for making it a feature. >> >> Rahul >> > Thanks for the advice. Created and submitted for approval [1]. You should add screenshots to show the difference and expand on the test plan (how do you switch between the plan one and nodoka theme?) the release notes. We would definitely want to note this during release. Rahul From a.badger at gmail.com Mon Jul 14 20:25:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 13:25:01 -0700 Subject: Rawhide Orphan Status In-Reply-To: References: <487B942B.1070103@redhat.com> <53484.198.175.55.5.1216059785.squirrel@mail.jcomserv.net> Message-ID: <487BB61D.8090606@gmail.com> drago01 wrote: > On Mon, Jul 14, 2008 at 8:23 PM, Jon Ciesla wrote: >> I'd love to take a peek at some of these, but pkgdb is spewing 500s. > > " I'm going to restart our postgres server. This will > mean a bit of downtime for koji, accounts, admin.fp.o" > This should be fixed now. Hop on #fedora-admin and let someone know (I'm abadger1999) if there's still issues. -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 jkeating at redhat.com Mon Jul 14 20:28:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 16:28:41 -0400 Subject: No login after KDE 4.0.98 rawhide update In-Reply-To: <487BB582.4040701@redhat.com> References: <487B994D.6080005@redhat.com> <487BB582.4040701@redhat.com> Message-ID: <1216067321.3631.164.camel@localhost.localdomain> On Mon, 2008-07-14 at 16:22 -0400, Christopher Aillon wrote: > Right, I wasn't targeting KDE specifically. It was more of a general > statement that there are still a non-zero amount of people who treat > rawhide as such, and we need to fix that. Hell, there is a non-zero amount of people who treat the release branches like that too, and that /really/ needs to stop. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 martin.sourada at gmail.com Mon Jul 14 20:42:02 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 14 Jul 2008 22:42:02 +0200 Subject: [F-10 Feature?] Nodoka notification theme In-Reply-To: <487BB5D5.2000602@fedoraproject.org> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> <487BB5D5.2000602@fedoraproject.org> Message-ID: <1216068122.3210.8.camel@localhost.localdomain> On Tue, 2008-07-15 at 01:53 +0530, Rahul Sundaram wrote: > You should add screenshots to show the difference and expand on the test > plan (how do you switch between the plan one and nodoka theme?) the > release notes. We would definitely want to note this during release. > > Rahul > I've expanded the release notes, added links to screenshots and a little expanded the Test Plan section. Does this seem OK now (I am not very good at writing such stuff)? Thanks, Martin https://fedoraproject.org/wiki/Features/NodokaNotificationTheme -------------- 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 a.badger at gmail.com Mon Jul 14 20:42:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 13:42:13 -0700 Subject: No answer to easy bug policy In-Reply-To: <487B93A3.2080404@fedoraproject.org> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> Message-ID: <487BBA25.1090303@gmail.com> Rahul Sundaram wrote: > Toshio Kuratomi wrote: >> Patrice Dumas wrote: >>> On Sat, Jul 12, 2008 at 10:59:24AM +0200, Patrice Dumas wrote: >>>> On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: >>>>> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >>>> I have hopefully adressed th ecomments, by stating that this is a >>>> policy >>>> for bug fixes, not easy bug as such. Also added a 3 weeks delay before >>>> the procedure is started, precise a bit what is a bug easy to fix and >>>> put explicitely the cleaning of blocker bugs on the reporter. >>> >>> Still on >>> https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance >>> >> Instead of orphaning, what about adding comaintainers? That makes for >> more responsibility on the part of the person who thinks that the bug >> is an easy fix to evaluate this in terms of correctness, the future >> effects of the patch, and what is going on upstream. > > The intro covers that: > > "If this occurs over a long period of time, the maintainers should seek > out co-maintainers or just be orphaning the software packages they are > not interested in. If it does happen for a shorter periods, others can > act as a buffer to avoid the problem lingering for our user" > What I'm asking is instead of: "If you don't answer after 2 weeks, a reminder should be sent, and if not answered within a further 2 weeks the package will be orphaned according to the policy stated at" We could have: "If you don't answer after 2 weeks, a reminder should be sent, and if not answered within a further 2 weeks My_Username will be assigned as a comaintainer and can make changes according to the policy stated at" -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 sundaram at fedoraproject.org Mon Jul 14 21:03:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 02:33:44 +0530 Subject: No answer to easy bug policy In-Reply-To: <487BBA25.1090303@gmail.com> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> Message-ID: <487BBF30.9040502@fedoraproject.org> Toshio Kuratomi wrote: > We could have: > > "If you don't answer after 2 weeks, a reminder should be sent, and if > not answered within a further 2 weeks My_Username will be assigned as a > comaintainer and can make changes according to the policy stated at" I am not sure we want to add someone as a co-maintainer just because the person is interested in seeing a new build with a particular fix. Co-maintainership involves a little more long term commitment than a one time fix. Rahul From dledford at redhat.com Mon Jul 14 21:21:07 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 14 Jul 2008 17:21:07 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216066101.4217.40.camel@aglarond.local> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215810605.3687.37.camel@firewall.xsintricity.com> <1216066101.4217.40.camel@aglarond.local> Message-ID: <1216070467.1891.57.camel@firewall.xsintricity.com> On Mon, 2008-07-14 at 16:08 -0400, Jeremy Katz wrote: > On Mon, 2008-07-14 at 19:22 +0300, Panu Matilainen wrote: > > "Lets add some new tags and see if we can fit a design + implementation to > > them later" does not fly very well with me. RPM has enough examples of > > useless (and unused) tags already (quite possibly because they're easier > > to add than argue), I'm not particularly interested in adding more. > > Also, it's easy to add new tags in the private, external range (100000+) > for doing things and then when things are working, it's easy to then > move them to be real assigned header tags. > > Think of adding a new header tag as like adding a new syscall. Once > added, they can't be removed. So the idea is to make sure that the > implementation and usage is sound before they're added. But there's a > range for experimenting and finding out what works available also Thank you Jeremy, I wasn't aware of that and it's a quite useful tip. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 wwoods at redhat.com Mon Jul 14 21:23:00 2008 From: wwoods at redhat.com (Will Woods) Date: Mon, 14 Jul 2008 17:23:00 -0400 Subject: Feature Test Plans (was Re: [F-10 Feature?] Nodoka notification theme) In-Reply-To: <1216068122.3210.8.camel@localhost.localdomain> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> <487BB5D5.2000602@fedoraproject.org> <1216068122.3210.8.camel@localhost.localdomain> Message-ID: <1216070580.31308.74.camel@metroid.rdu.redhat.com> On Mon, 2008-07-14 at 22:42 +0200, Martin Sourada wrote: > On Tue, 2008-07-15 at 01:53 +0530, Rahul Sundaram wrote: > > You should add screenshots to show the difference and expand on the test > > plan (how do you switch between the plan one and nodoka theme?) the > > release notes. We would definitely want to note this during release. > > > > Rahul > > > > I've expanded the release notes, added links to screenshots and a little > expanded the Test Plan section. Does this seem OK now (I am not very > good at writing such stuff)? Here's the deal with Test Plans: A Test Plan is a document that tells the testers how to test your feature. While writing your Test Plan, pretend that you have an intern whose job it is to test new features that land in Fedora releases. This brave, brave soul has a few years' experience as a Fedora user and basic familiarity with using the commandline to configure stuff, install packages, and so on. Your job is to tell this person how they can test your cool new feature, so they can either a) tell their friends about how cool it is, or b) tell you (via bugzilla) if it breaks. A good Test Plan should answer these four questions: 0. What special hardware / data / etc. is needed (if any)? 1. How do you prepare your system to test this feature? What packages need to be installed, config files edited, etc.? 2. What specific actions do you perform to check that the feature is working like it's supposed to? 3. What are the expected results of those actions? Your answers can be short: "get a bluetooth keyboard and yum install bluez-gnome newer than 0.25" answers question 0 and 1 just fine. But they need to be complete and explicit: "Get an appropriate keyboard and install the new packages" is not helpful. Soon I'm going to start tracking down Feature owners whose Feature pages don't tell me how to test their stuff. I'm happy to help write good test plans, but you can save a lot of trouble by getting one ready *before* I come bother you on IRC / by email / outside your window at night[1]. -w [1] Only kidding. Probably. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 14 21:27:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 17:27:07 -0400 Subject: No answer to easy bug policy In-Reply-To: <487BBA25.1090303@gmail.com> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> Message-ID: <1216070827.3631.168.camel@localhost.localdomain> On Mon, 2008-07-14 at 13:42 -0700, Toshio Kuratomi wrote: > What I'm asking is instead of: > > "If you don't answer after 2 weeks, a reminder should be sent, and if > not answered within a further 2 weeks the package will be orphaned > according to the policy stated at" > > We could have: > > "If you don't answer after 2 weeks, a reminder should be sent, and if > not answered within a further 2 weeks My_Username will be assigned as a > comaintainer and can make changes according to the policy stated at" Instead of creating a bunch of different ways to "timeout" a maintainer and "do something" after the fact, why can't we just fix up the non-responsive policy? I'd rather have one policy than n+ for each situation. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 Mon Jul 14 21:29:25 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 02:59:25 +0530 Subject: Feature Test Plans (was Re: [F-10 Feature?] Nodoka notification theme) In-Reply-To: <1216070580.31308.74.camel@metroid.rdu.redhat.com> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> <487BB5D5.2000602@fedoraproject.org> <1216068122.3210.8.camel@localhost.localdomain> <1216070580.31308.74.camel@metroid.rdu.redhat.com> Message-ID: <487BC535.20507@fedoraproject.org> Will Woods wrote: > On Mon, 2008-07-14 at 22:42 +0200, Martin Sourada wrote: >> On Tue, 2008-07-15 at 01:53 +0530, Rahul Sundaram wrote: >>> You should add screenshots to show the difference and expand on the test >>> plan (how do you switch between the plan one and nodoka theme?) the >>> release notes. We would definitely want to note this during release. >>> >>> Rahul >>> >> I've expanded the release notes, added links to screenshots and a little >> expanded the Test Plan section. Does this seem OK now (I am not very >> good at writing such stuff)? > > Here's the deal with Test Plans: A Test Plan is a document that tells > the testers how to test your feature. > > While writing your Test Plan, pretend that you have an intern whose job > it is to test new features that land in Fedora releases. This brave, > brave soul has a few years' experience as a Fedora user and basic > familiarity with using the commandline to configure stuff, install > packages, and so on. > > Your job is to tell this person how they can test your cool new feature, > so they can either a) tell their friends about how cool it is, or b) > tell you (via bugzilla) if it breaks. > > A good Test Plan should answer these four questions: > > 0. What special hardware / data / etc. is needed (if any)? > 1. How do you prepare your system to test this feature? What packages > need to be installed, config files edited, etc.? > 2. What specific actions do you perform to check that the feature is > working like it's supposed to? > 3. What are the expected results of those actions? > > Your answers can be short: "get a bluetooth keyboard and yum install > bluez-gnome newer than 0.25" answers question 0 and 1 just fine. But > they need to be complete and explicit: "Get an appropriate keyboard and > install the new packages" is not helpful. Can you add this information to http://fedoraproject.org/wiki/Features/Policy Rahul From sundaram at fedoraproject.org Mon Jul 14 21:30:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 03:00:51 +0530 Subject: No answer to easy bug policy In-Reply-To: <1216070827.3631.168.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> <1216070827.3631.168.camel@localhost.localdomain> Message-ID: <487BC58B.5060101@fedoraproject.org> Jesse Keating wrote: > Instead of creating a bunch of different ways to "timeout" a maintainer > and "do something" after the fact, why can't we just fix up the > non-responsive policy? I'd rather have one policy than n+ for each > situation. This is meant to be a addition/modification of the non responsive maintainer's policy as noted in https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00744.html Rahul From jspaleta at gmail.com Mon Jul 14 21:34:21 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 13:34:21 -0800 Subject: Offlist: Test plans Message-ID: <604aa7910807141434r3851a2cbo3e25f07af875cc27@mail.gmail.com> 2008/7/14 Will Woods : > Here's the deal with Test Plans: A Test Plan is a document that tells > the testers how to test your feature. Not that the Board has any real ability to help put test plans on the map. But if you think we can as a group do something to help the introduction of the test plan stuff let me know. -jef From jkeating at redhat.com Mon Jul 14 21:40:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 17:40:51 -0400 Subject: No answer to easy bug policy In-Reply-To: <487BC58B.5060101@fedoraproject.org> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> <1216070827.3631.168.camel@localhost.localdomain> <487BC58B.5060101@fedoraproject.org> Message-ID: <1216071651.3631.170.camel@localhost.localdomain> On Tue, 2008-07-15 at 03:00 +0530, Rahul Sundaram wrote: > This is meant to be a addition/modification of the non responsive > maintainer's policy as noted in > > https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00744.html What I meant by fix up is have the same time to respond and same outcome period, instead of a ton of different potential timeouts and responses. The various stages of timeouts are confusing to begin with, having to choose one and remember to follow which one is even worse. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 a.badger at gmail.com Mon Jul 14 21:37:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 14:37:34 -0700 Subject: No answer to easy bug policy In-Reply-To: <487BBF30.9040502@fedoraproject.org> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> <487BBF30.9040502@fedoraproject.org> Message-ID: <487BC71E.1010502@gmail.com> Rahul Sundaram wrote: > Toshio Kuratomi wrote: >> We could have: >> >> "If you don't answer after 2 weeks, a reminder should be sent, and if >> not answered within a further 2 weeks My_Username will be assigned as >> a comaintainer and can make changes according to the policy stated at" > > I am not sure we want to add someone as a co-maintainer just because the > person is interested in seeing a new build with a particular fix. > Co-maintainership involves a little more long term commitment than a one > time fix. > I see that as a benefit. It doesn't make much sense to me to make this transition:: Package has a maintainer that is active in fedora but is ignoring a particular bug report which may or may not contain a correct fix to the stated problem => Package becomes orphaned, possibly discarding any ideas the maintainer had for fixing the bug but forgot to write into the bug report. This seems like a better transition: Package has a maintainer that is active in Fedora but is ignoring a particular bug report => Package gets a comaintainer who has time to hit the low hanging fruit on the package and can take some of the burden off of the current package maintainer. Even the current state of affairs is better for some criteria: Package has a maintainer active in Fedora but is ignoring a particular bug report => Package continues to get updated for new upstream releases but the particular bug does not get addressed. -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 martin.sourada at gmail.com Mon Jul 14 21:50:43 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Mon, 14 Jul 2008 23:50:43 +0200 Subject: Feature Test Plans (was Re: [F-10 Feature?] Nodoka notification theme) In-Reply-To: <1216070580.31308.74.camel@metroid.rdu.redhat.com> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> <487BB5D5.2000602@fedoraproject.org> <1216068122.3210.8.camel@localhost.localdomain> <1216070580.31308.74.camel@metroid.rdu.redhat.com> Message-ID: <1216072243.3085.3.camel@pc-notebook> > Here's the deal with Test Plans: A Test Plan is a document that tells > the testers how to test your feature. > > While writing your Test Plan, pretend that you have an intern whose job > it is to test new features that land in Fedora releases. This brave, > brave soul has a few years' experience as a Fedora user and basic > familiarity with using the commandline to configure stuff, install > packages, and so on. > > Your job is to tell this person how they can test your cool new feature, > so they can either a) tell their friends about how cool it is, or b) > tell you (via bugzilla) if it breaks. > > A good Test Plan should answer these four questions: > > 0. What special hardware / data / etc. is needed (if any)? > 1. How do you prepare your system to test this feature? What packages > need to be installed, config files edited, etc.? > 2. What specific actions do you perform to check that the feature is > working like it's supposed to? > 3. What are the expected results of those actions? > > Your answers can be short: "get a bluetooth keyboard and yum install > bluez-gnome newer than 0.25" answers question 0 and 1 just fine. But > they need to be complete and explicit: "Get an appropriate keyboard and > install the new packages" is not helpful. > > Soon I'm going to start tracking down Feature owners whose Feature pages > don't tell me how to test their stuff. I'm happy to help write good test > plans, but you can save a lot of trouble by getting one ready *before* I > come bother you on IRC / by email / outside your window at night[1]. > > -w > > [1] Only kidding. Probably. Thanks for the info, it really makes my life a lot easier ;-) Does this test plan looks good (edited in wiki as well)? Test Plan * Install notification-daemon-engine-nodoka * Testing the engine * Set gconf '/app/notification-daemon/theme' key to 'nodoka' * Use various software that show notification bubbles * Test either with compositing enabled or disabled (the engine behaves slightly different based on the availability of true transparency) * Watch if the bubbles are displayed correctly * Testing theme selection via gconf * Switch gconf '/app/notification-daemon/theme' key between 'nodoka' and 'standard' * Watch if the change is applied correctly - i.e. the engine is set properly and applications continue showing notification bubbles * Known issues - Bug 455289: Notification daemon crashes after changing theme * Testing theme selection via appearances caplet * Switch between various themes in the appearances caplet (using the latest rawhide control-center rpm package) * Look if the notification theme is changed properly (look into /usr/share/themes/*/index.theme files for NotificationTheme key, if not set, notification theme should be set to standard, otherwise it should use the value of the key) * Try customizing the selected theme and see if the notification theme stays unchanged * Known issues - Bug 455329: Notification theme is reset to standard when theme is customized * Report any issues at rhbz Thanks, Martin -------------- 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 Mon Jul 14 21:52:12 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 03:22:12 +0530 Subject: No answer to easy bug policy In-Reply-To: <1216071651.3631.170.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <20080712085924.GB2762@free.fr> <20080712090750.GD2762@free.fr> <487B8F94.7090602@gmail.com> <487B93A3.2080404@fedoraproject.org> <487BBA25.1090303@gmail.com> <1216070827.3631.168.camel@localhost.localdomain> <487BC58B.5060101@fedoraproject.org> <1216071651.3631.170.camel@localhost.localdomain> Message-ID: <487BCA8C.9080701@fedoraproject.org> Jesse Keating wrote: > On Tue, 2008-07-15 at 03:00 +0530, Rahul Sundaram wrote: >> This is meant to be a addition/modification of the non responsive >> maintainer's policy as noted in >> >> https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00744.html > > > What I meant by fix up is have the same time to respond and same outcome > period, instead of a ton of different potential timeouts and responses. > The various stages of timeouts are confusing to begin with, having to > choose one and remember to follow which one is even worse. Ah, yes. That makes sense. Policy modified according to your suggestion along with Toshio's. Rahul From drepper at redhat.com Mon Jul 14 21:57:56 2008 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 14 Jul 2008 14:57:56 -0700 Subject: process wakeups Message-ID: <487BCBE4.9050107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One of the worst problems wrt energy savings we have today are all the wakeups processes request. This is not just an issue for laptops, it relevant everywhere. To see the size of the problem run the attached systemtap script. On my laptop I see the following output (47 secs runtime): uid | poll select epoll itimer futex nanosle signal| process 29799 |15941 7971 0 0 0 0 0| npviewer.bin 29841 | 253 0 0 0 1531 0 0| thunderbird-bin 3017 | 447 0 0 0 0 0 0| pulseaudio 2467 | 76 0 0 0 0 0 0| hald 2471 | 8 0 0 0 0 0 0| hald-runner 2620 | 58 0 0 0 0 0 0| NetworkManager 13174 | 214 0 0 0 0 0 0| stapio 3044 | 48 0 0 0 0 0 0| gnome-panel 9115 | 16 0 0 0 0 0 0| nm-vpnc-service 3112 | 32 0 0 0 0 0 0| gpk-update-icon 3108 | 24 0 0 0 0 0 0| nm-applet 3052 | 274 0 0 1 0 0 0| gnome-terminal 3115 | 29 0 0 0 0 0 0| gnome-power-man 3055 | 16 0 0 0 0 0 0| bluetooth-apple 3093 | 16 0 0 0 0 0 0| krb5-auth-dialo 2633 | 16 0 0 0 0 0 0| gdm-binary 2724 | 16 0 0 0 0 0 0| gdm-simple-slav 2630 | 16 0 0 0 0 0 0| nm-system-setti 2470 | 16 0 0 0 0 0 0| console-kit-dae 2385 | 16 0 0 0 0 0 0| avahi-daemon 2397 | 16 0 0 0 0 0 0| libvirtd 2725 | 63 214 0 4 0 0 0| Xorg 2150 | 42 0 0 0 0 0 0| setroubleshootd 3010 | 47 0 0 0 0 0 0| gnome-settings- 3040 | 111 0 0 0 0 0 0| metacity 3526 | 37 0 0 0 0 0 0| notification-da 3085 | 49 0 0 0 0 0 0| wnck-applet 3043 | 50 0 0 0 0 0 0| gnome-screensav 3042 | 26 0 0 0 0 0 0| nautilus 3050 | 8 0 0 0 0 0 0| evince 9120 | 0 5 0 0 0 0 0| vpnc 3342 | 11 0 0 0 0 0 0| clock-applet 3329 | 0 6 0 0 0 0 0| pam_timestamp_c 2337 | 0 7 0 0 0 0 0| sendmail 2132 | 0 0 0 0 33 0 0| automount 2958 | 0 3 0 0 0 0 0| ssh-agent 2118 | 1 0 0 0 0 0 0| dbus-daemon 5732 | 1 0 0 0 0 0 0| gnome-vfs-daemo 29394 | 68 131 0 0 65 0 0| firefox 2105 | 1 0 0 0 0 0 0| audispd 1979 | 0 1 0 0 0 0 0| rsyslogd As you can see, not all programs are equally bad and proprietary ones (here: flash) are the worst. Still, since the script records wakeups due to timeouts almost all mentions on this list are bad. Programs should be woken based on events. They shouldn't poll data (which is what usually happens after a timeout). I would hope the package maintainers can find some time and look at the issues. Maybe at least document them in a BZ. I might try to do the latter myself but given the large number of packages involved I'll most likely be able to cover just a few packages. IMO it should be a release criteria that a program does use polling. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7y9oACgkQ2ijCOnn/RHTW6wCfWzYOn3AvjLvJ5mwWjSZwr8tX Z84An2YYvqd9f2fkPGenE5uhDDdsan3y =VWLu -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.stap URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: timeout.stap.sig Type: application/octet-stream Size: 72 bytes Desc: not available URL: From rjones at redhat.com Mon Jul 14 22:00:22 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 23:00:22 +0100 Subject: No answer to easy bug policy In-Reply-To: <20080712000447.GB2610@free.fr> References: <20080712000447.GB2610@free.fr> Message-ID: <20080714220022.GA6690@amd.home.annexia.org> On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > If you don't answer after 2 weeks and one remainder lasting also at > least 2 week the package will be orphaned according to the policy stated > at So that's 4 weeks in all? 2 weeks alone is way too short because people commonly go on holiday for that length of time & longer. 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 poelstra at redhat.com Mon Jul 14 22:11:06 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 14 Jul 2008 15:11:06 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-07-14 Message-ID: <487BCEFA.8080801@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jul-14 Please make corrections and clarifications to the wiki page. == Spins as Features == * Some pushback from folks that think it is too much work to create a feature page * All spins must be proposed as features if they will be be offered at spins.fedoraproject.org **Feature page can be re-used (copy/pasted from release to release as necessary) * Feature pages are not required for the following spins: ** Fedora--classic dvd-install spin ** Desktop--live spin ** KDE--live spin == Misc == * rolling back to the F9 gold release of livecd-creator in order to make the F9 live images--selinux bug * Fedora board is ack/nacking the final set of names to go to public vote. Should have a list within hours. * Ticket #251 (Euthanize orphans)--https://fedorahosted.org/projects/rel-eng/ticket/251 ** deadline is set for 2008-07-18 == IRC Transcript == From jspaleta at gmail.com Mon Jul 14 22:15:53 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 14:15:53 -0800 Subject: Offlist: Test plans In-Reply-To: <604aa7910807141434r3851a2cbo3e25f07af875cc27@mail.gmail.com> References: <604aa7910807141434r3851a2cbo3e25f07af875cc27@mail.gmail.com> Message-ID: <604aa7910807141515q6d068cd4s97341117985add10@mail.gmail.com> On Mon, Jul 14, 2008 at 1:34 PM, Jeff Spaleta wrote: > 2008/7/14 Will Woods : >> Here's the deal with Test Plans: A Test Plan is a document that tells >> the testers how to test your feature. > > Not that the Board has any real ability to help put test plans on the > map. But if you think we can as a group do something to help the > introduction of the test plan stuff let me know. Okay not so offlist after all. Just wanted to make sure Will knows that I'm keen on supporting what's going on even if what I can make time for happens at the oxygen deprived altitude of the Board. -jef -jef From mrsam at courier-mta.com Mon Jul 14 22:20:37 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 14 Jul 2008 18:20:37 -0400 Subject: Testing wanted: bootconf References: <20080714151122.GD5020@nostromo.devel.redhat.com> Message-ID: Bill Nottingham writes: > Sam Varshavchik (mrsam at courier-mta.com) said: >> Feedback is kindly requested for bootconf, in updates-testing: >> >> http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5995 >> >> This new package installs a basic GUI for selecting a boot kernel (it's >> an editor for grub.conf), and enabling or disabling a few command kernel >> boot option. The "bootconf" rpm is a baseline command line tool, the >> "bootconf-gui" rpm is the gnome front end. > > Is this related to system-config-boot at all, or a different implementation > with similar goals? It's a different implementation, that offers a few more configurable knobs. Besides choosing the boot kernel, there are some options to configure a few common kernel boot parameters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dfarning at sugarlabs.org Mon Jul 14 22:27:13 2008 From: dfarning at sugarlabs.org (David Farning) Date: Mon, 14 Jul 2008 17:27:13 -0500 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> Message-ID: <1216074433.7931.99.camel@dfarning.desktop.org> On Mon, 2008-07-14 at 10:27 -0800, Jeff Spaleta wrote: > My really big question is what can we do to get the people actually > using the Sugar interface? > And not just the target audience for olpc..but we need to get older > people using the interface as well, people we can get involved in the > development process via bug reports and patches. I think it really > comes down to being able to provide an alternative Sugar desktop that > our Fedora users can live and work inside of. This a unique open source project in that developers are not developing for themselves. Many people become involved with a project by scratching their own itch. With Sugar, we are (hopefully) helping the next generation. In the end, this will help us. 10 years ago hackers were typified as loners working away in their parents basements. Now, many of us are parents. We can share our [passion|hobby|job] by setting up a Sugar desktop for our kids. > Locally I'm in contact with some teachers who are basically sitting on > a pile of slightly dated surplus Dell desktops that the military gave > away. Some have been put in use, but there's still a pile of them. I'd > like to take a few of them and make a Sugar lab, but I'm not really > sure how I can do that from a policy standpoint. I can't just walk > into the school system and setup a lab. I could try to set one up here > at the university but I doubt anyone would really touch it. I'm just > not sure how to make effective use of the resource, even if I got my > hands on a few of those computers. > Right now, the Fedora community can help by working on a Sugar based respin so we can increase the size and visibility of our user/tester base. thanks dfarning From sundaram at fedoraproject.org Mon Jul 14 22:31:17 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jul 2008 04:01:17 +0530 Subject: Fedora Release Engineering Meeting Recap 2008-07-14 In-Reply-To: <487BCEFA.8080801@redhat.com> References: <487BCEFA.8080801@redhat.com> Message-ID: <487BD3B5.6060206@fedoraproject.org> John Poelstra wrote: > Recap and full IRC transcript found here: > https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jul-14 > > Please make corrections and clarifications to the wiki page. > > == Spins as Features == > * Some pushback from folks that think it is too much work to create a > feature page This is a complete mischaracterization of my concerns which has nothing to do at all with the work involved. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00724.html Specifically: * FESCo voted to not classify spins as a feature. If that decision is to be reversed, I would prefer FESCo vote again. * There is a differentiation between the spins such as desktop and KDE and others and I want to make sure that difference gets incorporated into the process so spin maintainers are aware where to look to understand the difference and what it would take to be reclassified. Rahul From poelstra at redhat.com Mon Jul 14 22:55:59 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 14 Jul 2008 15:55:59 -0700 Subject: Feature Test Plans (was Re: [F-10 Feature?] Nodoka notification theme) In-Reply-To: <487BC535.20507@fedoraproject.org> References: <1216029807.2947.47.camel@pc-notebook> <487BA0EB.103@fedoraproject.org> <1216065944.3210.2.camel@localhost.localdomain> <487BB5D5.2000602@fedoraproject.org> <1216068122.3210.8.camel@localhost.localdomain> <1216070580.31308.74.camel@metroid.rdu.redhat.com> <487BC535.20507@fedoraproject.org> Message-ID: <487BD97F.5010008@redhat.com> Rahul Sundaram said the following on 07/14/2008 02:29 PM Pacific Time: >> Will Woods wrote: >> >> A good Test Plan should answer these four questions: >> >> 0. What special hardware / data / etc. is needed (if any)? >> 1. How do you prepare your system to test this feature? What packages >> need to be installed, config files edited, etc.? >> 2. What specific actions do you perform to check that the feature is >> working like it's supposed to? >> 3. What are the expected results of those actions? >> >> Your answers can be short: "get a bluetooth keyboard and yum install >> bluez-gnome newer than 0.25" answers question 0 and 1 just fine. But >> they need to be complete and explicit: "Get an appropriate keyboard and >> install the new packages" is not helpful. > > Can you add this information to > > http://fedoraproject.org/wiki/Features/Policy > > Rahul > Will do as part of enhancing definitions for each section heading. John From jkeating at redhat.com Tue Jul 15 00:31:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jul 2008 20:31:37 -0400 Subject: Fedora Release Engineering Meeting Recap 2008-07-14 In-Reply-To: <487BD3B5.6060206@fedoraproject.org> References: <487BCEFA.8080801@redhat.com> <487BD3B5.6060206@fedoraproject.org> Message-ID: <1216081897.3631.177.camel@localhost.localdomain> On Tue, 2008-07-15 at 04:01 +0530, Rahul Sundaram wrote: > This is a complete mischaracterization of my concerns which has nothing > to do at all with the work involved. Yours weren't the only concerns we talked about, particularly weren't the concerns pointed out in this log. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 peter at thecodergeek.com Tue Jul 15 03:19:28 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 14 Jul 2008 20:19:28 -0700 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) Message-ID: <1216091968.9625.13.camel@tuxhugs> Hi, all. Just an FYI: I've bumped rb_libtorrent to 0.13.1 in Rawhide, which changes the soname (libtorrent-0.12.1.so -->libtorrent-rasterbar.so.0) Aside from the large amount of bug-fixes, packaging recent versions of rb_libtorrent will make it much more feasible to use a system copy with Deluge 1.0 soon (which is just hitting its RCs, and currently uses its own internal copy synced to upstream trunk every so often). According to repoquery, the only thing that currently depends on this library is linkage (a GTK+ BitTorrent client); and that - according to its upstream authors - should work just fine with this updated rb_libtorrent once an update to linkage-0.2.0 is pushed. Howevever, I think that linkage-0.2.0 still needs some D-BUS C++ love, so it'll probably remain broken until that happens. (If needed, we can maintain a separate compat package for rb_libtorrent-0.12.x; but I hope that it will not be necessary.) Thanks. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 arjan at infradead.org Tue Jul 15 05:57:29 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 14 Jul 2008 22:57:29 -0700 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <20080714225729.6fed4f24@infradead.org> On Mon, 14 Jul 2008 14:57:56 -0700 Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the worst problems wrt energy savings we have today are all the > wakeups processes request. This is not just an issue for laptops, it > relevant everywhere. > > To see the size of the problem run the attached systemtap script. On > my laptop I see the following output (47 secs runtime): just a question.. is there anything this script does that powertop doesn't yet do? > I would hope the package maintainers can find some time and look at > the issues. Maybe at least document them in a BZ. there is a metabug for these things in bugzilla with the "wakeup" alias... -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From ae at op5.se Tue Jul 15 06:42:41 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 15 Jul 2008 08:42:41 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> Message-ID: <487C46E1.8080608@op5.se> Kevin Kofler wrote: > Bill Crawford gmail.com> writes: >> There's nothing to stop you now (AFAICS) using a URL that points into >> gitweb or cgit to specify the source, ... right? > > That won't work. You have to upload the sources into the lookaside cache, and > the Source: tag has to end with the name of the tarball you uploaded. And > gitweb and the like aren't suitable for checkouts at all, only for browsing. > But the URL: tag is free-style, isn't it? -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Tue Jul 15 06:51:41 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 15 Jul 2008 08:51:41 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> Message-ID: <487C48FD.9040609@op5.se> Kevin Kofler wrote: > Doug Ledford redhat.com> writes: >> First, before I respond to the rest of this, keep in mind that the >> "overwhelming majority" of packages needs to be quantified. >> Furthermore, at least one very significant package (the kernel) does not >> massage files at all between SCM tag and tarball. And to be honest, I >> would be very surprised to find many projects that do have any >> significant difference between a tagged release in the SCM of their >> choice and their tarballs. So I would like some examples please, which >> shouldn't be hard to come up with since it is the "overwhelming >> majority" of projects that obviously think when they tag something in >> their SCM it doesn't need to match the tarball they make with the same >> tag version... > > Many packages don't have a public SCM at all; some have a private SCM, some > one-man projects have no SCM at all. (For example, there is _no_ SCM for > Quarticurve and Quarticurve-KWin, unless you call fully exploded copies of old > versions sitting around on my HDD an "SCM".) > > And even if they use an SCM, they can: > * make releases without tags: For example, the weekly trunk snapshots of KDE > don't get tags, nor do the extragear tarball releases. I'm not sure if you saw my email regarding the requirements on the SCM for it to be useful in the scenario Doug Ledford proposes, but right at the top of the list comes the ability to uniquely name one particular commit. If you have that, you don't need tags. > * modify tags: This is particularly common in Subversion which allows using a > tag like a branch. KDE normally uses the following workflow: > 1. tag release > 2. prerelease tarballs from the tags to packagers > 3. fix any showstoppers by merging fixes to the tag > 4. respin tarballs for the modules which were thus fixed > 5. make the release public > so the contents of the tag can change between when we first build the package > and the public release of the new version. It would be extremely poor project policy to move a tag after it's made public, but for those rare occasions when that happens, it shouldn't matter. The SCM's which have the ability to uniquely name a commit independent of repository url all set the tag after the fact, linking one tag to one commit. Since the commit itself can be uniquely identified the name (or location) of the tag doesn't really matter. For centralized scms, moving tags doesn't matter in the slightest, since they can't name a commit uniquely anyway. What's more interesting though; Fedora can clone whatever repo, importing it to something sane if it isn't already, and then set tags that you simply never move. Me, being mostly a user who also happens to be a programmer, would love to have an easy way to be able to get a clone of , find the sources corresponding exactly to my version of the package and then fix whatever issues I have with it. Even if it was just me willing to do that (which I highly doubt), you'd have a net gain of one extra spare-time developer. You can't possibly argue that making it easier for casual developers to get involved is a bad thing. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nando at ccrma.Stanford.EDU Tue Jul 15 07:17:03 2008 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 15 Jul 2008 09:17:03 +0200 Subject: fedora 8 repository broken since 6/29 (#453312) Message-ID: <1216106223.2964.11.camel@cage.kgw.TU-Berlin.DE> Somehow alsa-firmware 1.0.16 got pushed out to stable without a corresponding alsa-tools-* package. So, for anyone that has alsa-firmware installed a "yum upgrade" fails with missing dependencies (ie: all Planet CCRMA users that have f8 installed). https://bugzilla.redhat.com/show_bug.cgi?id=453312 The bug was reported on June 29. It is now July 15th. Could someone with proper authority __please__ remove alsa-firmware asap from the repository (or push alsa-tools-* if it is waiting)?? Thanks. -- Fernando From j.w.r.degoede at hhs.nl Tue Jul 15 08:34:21 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 Jul 2008 10:34:21 +0200 Subject: fedora 8 repository broken since 6/29 (#453312) In-Reply-To: <1216106223.2964.11.camel@cage.kgw.TU-Berlin.DE> References: <1216106223.2964.11.camel@cage.kgw.TU-Berlin.DE> Message-ID: <487C610D.9040404@hhs.nl> Fernando Lopez-Lezcano wrote: > Somehow alsa-firmware 1.0.16 got pushed out to stable without a > corresponding alsa-tools-* package. So, for anyone that has > alsa-firmware installed a "yum upgrade" fails with missing dependencies > (ie: all Planet CCRMA users that have f8 installed). > > https://bugzilla.redhat.com/show_bug.cgi?id=453312 > > The bug was reported on June 29. It is now July 15th. > > Could someone with proper authority __please__ remove alsa-firmware asap > from the repository (or push alsa-tools-* if it is waiting)?? > I've forwarded this to release engineering, which usual is the proper place to send things like this to. Regards, Hans From rawhide at fedoraproject.org Tue Jul 15 10:37:24 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 15 Jul 2008 10:37:24 +0000 (UTC) Subject: rawhide report: 20080715 changes Message-ID: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080714/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080715/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package almanah A application to allow you to keep a diary of your life New package asana-math-fonts An OpenType font with a MATH table New package beldi Belug Linux Distribution Burner New package icelandic-fonts Icelandic Magical Staves New package perl-Getopt-Long-Descriptive Getopt::Long with usage text New package python-slip Miscellaneous convenience, extension and workaround code for Python New package tex-zfuzz Type-checker and LaTeX style for Z spec language New package xfce4-mpc-plugin MPD client for the Xfce panel New package xfmpc A MPD client for the Xfce desktop environment Updated Packages: CastPodder-5.0-9.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 5.0-9 - fix license tag DMitry-1.3a-4.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.3a-4 - fix license tag JSDoc-1.10.2-5.fc10 ------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.10.2-5 - fix license tag MegaMek-0.30.11-4.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.30.11-4 - fix license tag MochiKit-1.3.1-2.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 1.3.1-2 - fix license tag MyPasswordSafe-0.6.7-6.20061216.fc10 ------------------------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 0.6.7-6.20061216 - fix license tag * Sat Apr 5 18:00:00 2008 Ralf Ertzinger 0.6.7-5.20061216 - Change BuildRequires to qt3-devel PyXML-0.8.4-10 -------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.8.4-10 - fix license tag R-systemfit-1.0-3.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0-2 - fix license tag * Mon Jul 14 18:00:00 2008 Orion Poplawski - 1.0-3 - Add BR R-lmtest - Use "--no-install" in %check to avoid missing suggested dependencies * Thu Feb 14 17:00:00 2008 Orion Poplawski - 1.0-1 - Update to 1.0-2 SDL-1.2.13-5.fc10 ----------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 1.2.13-5 - fix license tag abcMIDI-20070106-3.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 20070106-3 - fix license tag acl-2.2.47-2.fc10 ----------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 2.2.47-2 - rework params patch to apply with fuzz=0 - fix license tag acpi-0.09-4.fc10 ---------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.09-4 - fix license tag acpid-1.0.6-8.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0.6-8 - fix license tag acpitool-0.4.7-5.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.4.7-5 - fix license tag adminutil-1.1.6-2.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.1.6-2 - fix license tag amarokFS-0.5-4.fc10 ------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.5-4 - fix license tag amavisd-new-2.5.2-3.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 2.5.2-3 - fix license tag - fix db patch to apply with fuzz=0 amqp-1.0.666398-6.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 0:1.0.666398-6 - fix license tag amtu-1.0.6-3.fc10 ----------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0.6-3 - fix license tag ant-contrib-1.0-0.6.b2.fc10 --------------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0-0.6.b2 - fix license tag archmage-0.1.9-3.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 0.1.9-3 - fix license tag arp-scan-1.6-3.fc10 ------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.6-3 - fix license tag arptables_jf-0.0.8-13.fc10 -------------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.0.8-13 - fix license tag - drop conflicts aspell-ar-1.2-4.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.2-4 - fix license tag aspell-he-1.0-4.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0-4 - fix license tag attr-2.4.41-2.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 2.4.41-2 - fix license tags audiofile-0.2.6-9.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1:0.2.6-9 - fix license tag autofs-5.0.3-19 --------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 5.0.3-19 - change conflicts to requires - fix license tag automake14-1.4p6-17.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 1.4p6-17 - fix license tag autotrace-0.31.1-18.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.31.1-18 - fix license tag avarice-2.6-3.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 2.6-3 - fix license tag azureus-3.0.4.2-16.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 3.0.4.2-16 - fix license tag - fix cache-size patch to apply with fuzz=0 barcode-0.98-12.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.9.8-12 - fix license tag berusky-1.1-9.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.1-9 - fix license tag berusky-data-1.0-4.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 1.0-4 - fix license tag bigboard-0.5.38-3.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.5.38-3 - fix license tag bitgtkmm-0.4.0-4.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.4.0-4 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.4.0-3 - Autorebuild for GCC 4.3 bitmap-fonts-0.3-6.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.3-6 - fix license tag blktool-4-8.fc10 ---------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 4-8 - fix license tag bogl-0.1.18-15 -------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0:0.1.18-15 - fix license tag bonnie++-1.03c-1.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway 1.03c-1 - update to 1.03c - fix license tag booty-0.104-2.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.104-2 - fix license tag bottlerocket-0.04c-3.fc10 ------------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.04c-3 - fix license tag brandy-1.0.19-6.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.0.19-6 - fix license tag bugzilla-3.0.4-2.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 3.0.4-2 - fix license tag buoh-0.8.2-6.fc10 ----------------- * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 0.8.2-6 - fix license tag byacc-1.9.20070509-4.fc10 ------------------------- * Mon Jul 14 18:00:00 2008 Petr Machata - 1.9.20070509-4 - Add a patch that fixes ancient buffer overflow - Resolves: #454583 cairo-dock-1.6.1.1-1.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Mamoru Tasaka - 1.6.1.1-1 - 1.6.1.1 control-center-2.23.4-4.fc10 ---------------------------- * Mon Jul 14 18:00:00 2008 Matthias Clasen - 2.23.4-4 - Drop some obsolete patches - Fix an issue with the notification-theme support (#455329) cpufrequtils-004-1.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Jarod Wilson 004-1 - New upstream release deltarpm-3.4-11.fc10 -------------------- * Sun Jul 13 18:00:00 2008 Jonathan Dieter - 3.4-11 - Rebuild for rpm 4.6 f-spot-0.4.4-4.fc10 ------------------- * Mon Jul 14 18:00:00 2008 Nigel Jones - 0.4.4-4 - Remove Tom's patch in -2, there is a gtk-sharp 2.12.1, just nobody bothered packaging it. - Patch Makefile{.in,am} to use DESTDIR for the gio-sharp.dll, this is effectively a backport of r4010 Upstream. - Patch libfspot/Makefile{.in,am} to remove -DGTK_DISABLE_DEPRECATED per recommendation of upstream. - Re-add patch to use system mono-addins - Include GIO stuff for now (until it appears in gtk-sharp) * Sat Jul 5 18:00:00 2008 Alex Lancaster - 0.4.4-3 - gtkhtml dependency now provided by gnome-desktop-sharp-devel rather than gnome-sharp-devel, so add as BuildRequires filezilla-3.1.0-0.1.beta2.fc10 ------------------------------ * Mon Jul 14 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.0-0.1.beta2 - Update to 3.1.0-beta2 gajim-0.11.4-4.fc10 ------------------- * Mon Jul 14 18:00:00 2008 Debarshi Ray - 0.11.4-4 - Rebuilding to overcome Koji outage. * Mon Jul 14 18:00:00 2008 Debarshi Ray - 0.11.4-3 - Updated BuildRoot according to Fedora packaging guidelines. - Added 'Requires: gnome-python2-canvas'. Closes Red Hat Bugzilla bug #454622. - Removed 'BuildRequires: pkgconfig' and dropped version from 'BuildRequires: pygtk2-devel'. - Fixed docdir and removed empty README. gamazons-0.83-3.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Michel Alexandre Salim - 0.83-3 - Remove OnlyShowIn=GNOME from desktop file gdb-6.8-17.fc10 --------------- * Mon Jul 14 18:00:00 2008 Jan Kratochvil - 6.8-17 - Refresh the patchset with fuzz 0 (for new rpmbuild). * Mon Jul 14 18:00:00 2008 Jan Kratochvil - 6.8-16 - Rebuild with the new rpm-4.5.90 in the buildroot. gnome-do-0.4.2.0-2.1.fc10 ------------------------- * Mon Jul 14 18:00:00 2008 Paul F. Johnson 0.4.2.0-2.1 - rebuild gtk-sharp2-2.12.1-3.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Xavier Lamien - 2.12.1-3 - Fix/Update libdir on GACUTIL & monodoc. * Mon Jul 14 18:00:00 2008 Alex Lancaster - 2.12.1-2 - Rebuild for fixed RPM for mono provides. gtk2hs-0.9.13-2.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Bryan O'Sullivan - 0.9.13-2 - Try to fix ppc build due to ghc 6.8.3 -fvia-C bug * Mon Jul 14 18:00:00 2008 Bryan O'Sullivan - 0.9.13-1 - Update to 0.9.13 * Mon Jun 23 18:00:00 2008 Jens Petersen - 0.9.12.1-10.fc10 - build with ghc-6.8.3 - add build_docs switch - use haddock09 to fix build failure (#440493) - merge ghcver subpackage into ghc subpackage in line with ghc - obsolete old ghcver packages - add opengl gtkglext subpackage (Ian Collier, #327541) - require xulrunner-devel instead of firefox-devel - update prereq's to script requires * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.9.12.1-9 - Autorebuild for GCC 4.3 gtkwave-3.1.12-1.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Paul Howarth 3.1.12-1 - update to 3.1.12 httpd-2.2.9-4 ------------- * Mon Jul 14 18:00:00 2008 Joe Orton 2.2.9-4 - use Charset=UTF-8 in default httpd.conf (#455123) - only enable suexec when appropriate (Jim Radford, #453697) jakarta-commons-el-1.0-9.4.fc10 ------------------------------- * Mon Jul 14 18:00:00 2008 Andrew Overholt 0:1.0-9.4 - Update OSGi metadata for Eclipse 3.4. jsch-0.1.39-1.1.fc10 -------------------- * Fri Jul 11 18:00:00 2008 Andrew Overholt 0:0.1.39-1.1 - 0.1.39 kdebase-runtime-4.0.98-4.fc10 ----------------------------- * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-4 - respin * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-3 - -phonon-backend-xine: new subpkg kdebase-workspace-4.0.98-5.fc10 ------------------------------- * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-4 - install circles kdm theme * Mon Jul 14 18:00:00 2008 Kevin Kofler 4.0.98-5 - new consolekit-kdm patch using libck-connector, BR ConsoleKit-devel (#430388) kdebindings-4.0.98-3.fc10 ------------------------- * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-3 - re-enable smoke (patched), ruby * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-2 - omit smoke, ruby bindings (build failures, sorting out upstream) - -devel: -BR: PyQt4-devel * Fri Jul 11 18:00:00 2008 Rex Dieter 4.0.98-1 - 4.0.98 * Sun Jul 6 18:00:00 2008 Rex Dieter 4.0.85-1 - 4.0.85 kdelibs-4.0.98-4.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Rex Dieter 4.0.98-4 - respun tarball kernel-2.6.26-138.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Roland McGrath - utrace update * Mon Jul 14 18:00:00 2008 Dave Jones - Improve 8139too PIO patch with jgarziks comments. kexec-tools-1.102pre-13.fc10 ---------------------------- * Fri Jul 11 18:00:00 2008 Neil Horman - 1.102pre-13 - Fix mkdumprd to support dynamic busybox (bz 443878) ltsp-5.1.11-1.fc9 ----------------- * Thu Jul 10 18:00:00 2008 Warren Togami - 5.1.11-1 - LDM_DIRECTX=yes unencrypted X by default in lts.conf This is for performance and scalability. Turn it off if you want security. - Fix chroot install that was broken by livecd-tools update - own /var/lib/ltsp to silence tmpwatch selinux errors lucene-2.3.1-3.4.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Andrew Overholt 0:2.3.1-3.4 - Update OSGi manifest data for Eclipse SDK 3.4 mod_perl-2.0.4-4 ---------------- * Mon Jul 14 18:00:00 2008 Joe Orton 2.0.4-4 - rebuild for new BDB mono-addins-0.3.1-2.2.fc10 -------------------------- * Mon Jul 14 18:00:00 2008 Paul F. Johnson - 0.3.1-2.2 - rebuild net-snmp-5.4.1-20.fc10 ---------------------- * Fri Jul 11 18:00:00 2008 Jan Safranek 5.4.1-20 - prepare for new rpm version notification-daemon-0.3.7.90-1.svn3009.fc10 ------------------------------------------- * Mon Jul 14 18:00:00 2008 Matthias Clasen - 0.3.7.90-1.svn3009 - Build against libsexy rather than copying part of it in a broken way (#455289) objectweb-asm-3.1-2.3.fc10 -------------------------- * Mon Jul 14 18:00:00 2008 Andrew Overholt 0:3.1-2.3 - Build and ship asm-all.jar with OSGi manifest (Alexander Kurtakov) openais-0.84-2.svn1579.fc10 --------------------------- * Mon Jul 14 18:00:00 2008 Fabio M. Di Nitto - 0.84-2.svn1579 - Update to svn trunk at revision 1579. 1577 (wrong commit) and 1578 (revert 1577) are not included (nor required) - Cleanup whitespace in spec file. pcmanfm-0.4.6.1-1.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Mamoru Tasaka - 0.4.6.1-1 - 0.4.6 - 0.4.6.1 - -Werror-implicit-function-declaration is added upstream perl-XML-Stream-1.22-8.fc10 --------------------------- * Mon Jul 14 18:00:00 2008 Chris Weyl 1.22-8 - add IO::Socket::SSL as a BR/R (see BZ#455344) - also add Net::DNS - make tests run if --with network-tests - misc spec touchups phonon-4.2-0.4.beta2.fc10 ------------------------- * Mon Jul 14 18:00:00 2008 Rex Dieter 4.2-0.4.beta2 - BR: automoc4 - -backend-gstreamer subpkg * Tue Jul 1 18:00:00 2008 Kevin Kofler 4.2-0.3.beta2 - drop automoc libsuffix patch, no longer needed php-5.2.6-3 ----------- * Mon Jul 14 18:00:00 2008 Joe Orton 5.2.6-3 - update to 5.2.6 - sync default php.ini with upstream - drop extension_dir from default php.ini, rely on hard-coded default, to make php-common multilib-safe (#455091) - update to r3 of systzdata patch pigment-0.3.6-4.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Matthias Saou 0.3.6-4 - Include upstream patch to fix "make check". - Run "autoreconf", nothing works when libdir is set to /usr/lib64 otherwise. * Fri Jul 11 18:00:00 2008 Matthias Saou 0.3.6-1 - Update to 0.3.6. - Temporarily disable "make check", as it's broken in this release. publican-0.33-2.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Jeff Fearn 0.33-2 - Rebuild * Tue Jul 15 18:00:00 2008 Jeff Fearn 0.33-1 - Change kde reqs to a more portable format python-fedora-0.3.1-1.fc10 -------------------------- * Mon Jul 14 18:00:00 2008 Luke Macken - 0.3.1-1 - New upstream bugfix release rb_libtorrent-0.13.1-1.fc10 --------------------------- * Mon Jul 14 18:00:00 2008 Peter Gordon - 0.13.1-1 - Update to new upstream release (0.13.1): Contains an incompatible ABI/API bump. - Drop GCC 4.3 patch (fixed upstream): - gcc43.patch - Disable building the examples for now. (Attempted builds fail due to missing Makefile support.) - Drop the source permissions and pkgconfig file tweaks (fixed upstream). rhythmbox-0.11.6-1.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 - Bastien Nocera - 0.11.6-1 - Update to 0.11.6 - Remove loads of upstreamed patches rpm-4.5.90-0.git8426.7 ---------------------- * Mon Jul 14 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8426.7 - fix mono dependency extraction (adjust for libmagic string change) rpmreaper-0.1.4-2.fc10 ---------------------- * Mon Jul 14 18:00:00 2008 Miroslav Lichvar 0.1.4-2 - fix building with new rpm (Panu Matilainen) rsyslog-3.19.9-2.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Peter Vrabec 3.19.9-2 - adjust default config file tomcat5-5.5.26-1.5.fc10 ----------------------- * Mon Jul 14 18:00:00 2008 Andrew Overholt 0:5.5.26-1.5 - Bump OSGi version numbers to match Eclipse SDK 3.4. - Update patches to apply with 0 fuzz. totem-pl-parser-2.23.3-1.fc10 ----------------------------- * Mon Jul 14 18:00:00 2008 - Bastien Nocera - 2.23.3-1 - Update to 2.23.3 - Fixes crasher when totem_cd_detect_type() generates an error (#455014) uim-1.5.0-3.fc10 ---------------- * Mon Jul 14 18:00:00 2008 Akira TAGOH - 1.5.0-3 - Add missing files. (#454957) vym-1.12.0-1.fc10 ----------------- * Mon Jul 14 18:00:00 2008 Jon Ciesla - 1.12.0-1 - Updated to new upstream version. - Dropped all patches, applied upstream. webalizer-2.01_10-37 -------------------- * Mon Jul 14 18:00:00 2008 Joe Orton 2.01_10-37 - rebuild for new BDB xchat-2.8.6-2.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Kevin Kofler - 1:2.8.6-2 - apply xc286-smallfixes.diff from upstream - don't #define GTK_DISABLE_DEPRECATED (fixes build against current GTK+) xfig-3.2.5-11.fc10 ------------------ * Mon Jul 14 18:00:00 2008 Ian Hutchinson 3.2.5-11 - Fix incorrect height of modepanel. xmlto-0.0.21-2.fc10 ------------------- * Fri Jul 11 18:00:00 2008 Ondrej Vasik - 0.0.21-2 - xmlto-tex subpackage to prevent requirements for passivetex/tex for all backends(#454341) Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 97 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so pigment-python-0.3.3-1.fc9.i386 requires libpigment-0.3.so.4 pigment-python-0.3.3-1.fc9.i386 requires libpigment-gtk-0.3.so.4 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.i386 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.x86_64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pigment-python-0.3.3-1.fc9.x86_64 requires libpigment-gtk-0.3.so.4()(64bit) pigment-python-0.3.3-1.fc9.x86_64 requires libpigment-0.3.so.4()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.x86_64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.ppc requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so pigment-python-0.3.3-1.fc9.ppc requires libpigment-0.3.so.4 pigment-python-0.3.3-1.fc9.ppc requires libpigment-gtk-0.3.so.4 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.ppc requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pigment-python-0.3.3-1.fc9.ppc64 requires libpigment-gtk-0.3.so.4()(64bit) pigment-python-0.3.3-1.fc9.ppc64 requires libpigment-0.3.so.4()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.ppc64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From mschwendt at gmail.com Tue Jul 15 10:46:26 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 15 Jul 2008 12:46:26 +0200 Subject: No answer to easy bug policy In-Reply-To: <3vask5xiru.ln2@ppp1053.in.ipex.cz> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> Message-ID: <20080715124626.a6fcb0d8.mschwendt@gmail.com> On Mon, 14 Jul 2008 18:20:19 +0200, Matej Cepl wrote: > On 2008-07-14, 15:48 GMT, Jesse Keating wrote: > > Whilst I do like that you're trying to solve this problem, > > I think one big hole here is who decides that the "fix" is > > either easy, or right? > > A bug with EasyFix keyword, and if you don't agree just change > the Keyword (yes, there should be some ACLs so that it cannot be > turned on again, but there are hopefully not that many people who > would be arguing with)? There's a problem with this. It's not the only one, but just one of many which make the entire issue not easy to solve. The maintainers say they can't cope with the huge amount of "bugzilla spam". Probably they don't see the EasyFix keyword, because they don't look at the ticket at all. And an EasyFix ticket is not more important than other tickets. There is the NonResponsiveMaintainers policy already, which covers a very similar process: trying to get a response from a maintainer prior to further action. More bugzilla mails make it worse. Do we need more bureaucracy to determine which maintainers can't handle all their bugzilla mail? How many maintainers are affected by huge amounts of bz mail? How many packages are affected? Whatever email filtering technology the maintainers use, they either don't get to see the additional bugzilla messages (e.g. when sorting by thread) or they skip them deliberately. Private "ping" attacks don't make it better either, if such methods are used to force maintainers to re-prioritise their work. Either there is time to look at a ticket and bug, or there isn't. Why is it that direct mail is considered more important than bugzilla mail? Bugzilla explicitly asks reporters not to reply privately. And what do we do? We establish processes where everyone, who is stubborn enough, may hunt down maintainers via private mail or on IRC/IM to respond to EasyFix bugs. A process that must be repeated everytime a new ticket is not responded to soon enough. Instead of using bugzilla's severity flags, private mail is the way to draw maintainer's attention? That sounds wrong to me. It would be helpful if registered Fedora Package Collection contributors [with pkg cvs commit access] could set a special flag in bugzilla, indicating that they are committed to preparing a test update. Then package maintainers would ACK/NAK that request, knowing it is a fellow Fedora packager who made it and who is willing to fix the bug. And we do want to improve the communication inside the project, don't we? This isn't about hundreds of such requests already, is it? Do the maintainers see through all their commit mails and notifications from koji? Or is that another source of too much mail traffic? Adding a lot of bureaucracy for other contributors before they could apply an EasyFix makes the process more tedious than necessary. It is another attempt at solving the problem at the wrong end. While a maintainer seems to be free to ignore bugs in shipped products (which is especially bad wrt regressions), you expect volunteers to go through a tedious process, which involves waiting several weeks plus waiting even longer to get an answer from the maintainer. This means that the volunteer has to stay up-to-date in that matter for more time than necessary. In a month, upstream might publish a new minor release with further bug-fixes. And suddenly the pkg maintainer has time again and wants to ship an upgrade instead of just a patched pkg. That leads to wasted effort especially on the volunteer's side. I'd rather prefer a policy for package maintainers to respond to specially marked tickets from fellow fedora contributors in a timely manner. And if that results in tickets which are still not answered, timeout periods can be applied and give contributors the opportunity to prepare a test update (and only a test update!). From mjg at redhat.com Tue Jul 15 11:06:58 2008 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 15 Jul 2008 12:06:58 +0100 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <20080715110658.GA2591@srcf.ucam.org> On Mon, Jul 14, 2008 at 02:57:56PM -0700, Ulrich Drepper wrote: > I would hope the package maintainers can find some time and look at the > issues. Maybe at least document them in a BZ. I might try to do the > latter myself but given the large number of packages involved I'll most > likely be able to cover just a few packages. IMO it should be a release > criteria that a program does use polling. There are certain situations where polling is inevitable (such as querying hardware for battery status or signal strength, pulling mail, that kind of thing). Applications that do this should do it at relatively low frequency, and where possible (ie, almost always) use g_timeout_add_seconds or equivalent functionality. It's pretty inevitable that we'll have one wakeup a second, and ensuring that all applications that need to be woken during that second are woken at the same time has a significant benefit on power consumption. -- Matthew Garrett | mjg59 at srcf.ucam.org From jkeating at redhat.com Tue Jul 15 11:07:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 07:07:28 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080715124626.a6fcb0d8.mschwendt@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> Message-ID: <1216120048.3631.187.camel@localhost.localdomain> On Tue, 2008-07-15 at 12:46 +0200, Michael Schwendt wrote: > I'd rather prefer a policy for package maintainers to respond to specially > marked tickets from fellow fedora contributors in a timely manner. And > if that results in tickets which are still not answered, timeout periods > can be applied and give contributors the opportunity to prepare a > test update (and only a test update!). I think that's pretty sane. Would you be willing to take the existing policy and morph it more into the above? In particular though I'd really like to see the policy get written up with input from those who are just drowning in bugzilla mail. One thing I think would really help is if SIG meetings took a little slice of time to quickly triage any bugs for packages related to the SIG that have some marking of easy fix. Low hanging fruit isn't the really important work, but it goes a long way toward fit and polish. A few minutes to triage and say yes/no/idon'tcare to these bugs would really help. Maybe even a BugZapper person can join the meeting and be the person listing the bugs and following up in the bug for the SIG people. I don't want to make that mandatory at all, just highly suggested. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 harald at redhat.com Tue Jul 15 11:30:50 2008 From: harald at redhat.com (Harald Hoyer) Date: Tue, 15 Jul 2008 13:30:50 +0200 Subject: process wakeups In-Reply-To: <20080715110658.GA2591@srcf.ucam.org> References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> Message-ID: Matthew Garrett wrote: > On Mon, Jul 14, 2008 at 02:57:56PM -0700, Ulrich Drepper wrote: > >> I would hope the package maintainers can find some time and look at the >> issues. Maybe at least document them in a BZ. I might try to do the >> latter myself but given the large number of packages involved I'll most >> likely be able to cover just a few packages. IMO it should be a release >> criteria that a program does use polling. > > There are certain situations where polling is inevitable (such as > querying hardware for battery status or signal strength, pulling mail, > that kind of thing). Applications that do this should do it at > relatively low frequency, and where possible (ie, almost always) use > g_timeout_add_seconds or equivalent functionality. It's pretty > inevitable that we'll have one wakeup a second, and ensuring that all > applications that need to be woken during that second are woken at the > same time has a significant benefit on power consumption. > g_timeout_add_seconds does not "really" sync globally. The kernel could schedule a common (across all apps) wakeup time a little bit better than g_timeout_add_seconds(), if the application could specify a time "range" of how long it would like to approx. sleep. Also g_timeout_add_seconds() does not work with select/poll. From buc at odusz.so-cdu.ru Tue Jul 15 11:42:45 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 Jul 2008 15:42:45 +0400 Subject: fedora 8 repository broken since 6/29 (#453312) In-Reply-To: <1216106223.2964.11.camel@cage.kgw.TU-Berlin.DE> References: <1216106223.2964.11.camel@cage.kgw.TU-Berlin.DE> Message-ID: <487C8D35.7020703@odu.neva.ru> Fernando Lopez-Lezcano wrote: > Somehow alsa-firmware 1.0.16 got pushed out to stable without a > corresponding alsa-tools-* package. So, for anyone that has > alsa-firmware installed a "yum upgrade" fails with missing dependencies > ...IOW, if during the period of the broken state of the repository, some security update (of some another package) will be released, such an update will not reach the user since the "yum update" is failed... ~buc From harald at redhat.com Tue Jul 15 11:47:41 2008 From: harald at redhat.com (Harald Hoyer) Date: Tue, 15 Jul 2008 13:47:41 +0200 Subject: Study: Attacks on package managers Message-ID: http://lwn.net/Articles/289883/ The University of Arizona is publishing a study on security problems with package management systems. The core problem would appear to be that tools like yum and apt will happily install versions of packages with known vulnerabilities if they think that's the most recent version available. And feeding such packages to the package managers is not a big challenge: "To give an example of how easy it is for a malicious party to obtain a mirror, we ran an experiment where we created a fake administrator and company name and leased a server from a hosting provider. We were able to get our mirror listed on every distribution we tried (Ubuntu, Fedora, OpenSuSE, CentOS, and Debian) and our mirrors were contacted by thousands of clients, even including military and government computers!" http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html From mschwendt at gmail.com Tue Jul 15 11:53:02 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 15 Jul 2008 13:53:02 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080714220022.GA6690@amd.home.annexia.org> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> Message-ID: <20080715135302.c3ec7a96.mschwendt@gmail.com> On Mon, 14 Jul 2008 23:00:22 +0100, Richard W.M. Jones wrote: > On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > > If you don't answer after 2 weeks and one remainder lasting also at > > least 2 week the package will be orphaned according to the policy stated > > at > > So that's 4 weeks in all? > > 2 weeks alone is way too short because people commonly go on holiday > for that length of time & longer. Less of a problem if someone opens a ticket while you enter the airport. More of a problem if a ticket is open already for two weeks before you go on holidays. It still may need some kind of emergency team (or rel-eng) to jump in under certain circumstances. Imagine, one of your packages fails to start because a library update reveals a crasher bug in the application. Do we want to keep it broken for 4+ weeks and only then start a process on finding out why you don't respond? From jkeating at redhat.com Tue Jul 15 12:12:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 08:12:31 -0400 Subject: No answer to easy bug policy In-Reply-To: <20080715135302.c3ec7a96.mschwendt@gmail.com> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> <20080715135302.c3ec7a96.mschwendt@gmail.com> Message-ID: <1216123951.3631.191.camel@localhost.localdomain> On Tue, 2008-07-15 at 13:53 +0200, Michael Schwendt wrote: > > It still may need some kind of emergency team (or rel-eng) to jump in > under certain circumstances. Imagine, one of your packages fails to start > because a library update reveals a crasher bug in the application. Do we > want to keep it broken for 4+ weeks and only then start a process on > finding out why you don't respond? not at all. I think those are the occasions where somebody should step in. Perhaps when new maintainer containment goes live (as early as next week!) maintainers will feel more comfortable allowing access to 'uperpackager' people, and thus be welcome to people fixing things for them, and we won't have to sit on our hands for 4 weeks waiting for the erstwhile maintainer to ping back. Also what would really help this situation is if we did have automated tests that ran and could verify that the fix didn't regress anything, but that's a more far off solution. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 thomas.moschny at gmail.com Tue Jul 15 12:16:06 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Tue, 15 Jul 2008 14:16:06 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080709164728.GD3088@angus.ind.WPI.EDU> References: <20080709161226.GA9444@cupro.opengvs.com> <200807091228.00498.jwilson@redhat.com> <20080709164728.GD3088@angus.ind.WPI.EDU> Message-ID: 2008/7/9 Chuck Anderson : > +1. This has been my .rpmmacros for years: > > %_topdir /home/cra/src/redhat > %_ntopdir %{_topdir}/%{name}-%{version}-%{release} > %_builddir %{_ntopdir} > %_sourcedir %{_ntopdir} > %_specdir %{_ntopdir} > %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm > %_rpmdir %{_topdir}/RPMS > %_srcrpmdir %{_topdir}/SRPMS Is there a trick to teach "spectool -g -R" to expand %{name}, %{version} and %{release} and not to create directories that literally contain '%{name}' etc. ? Tried to use the -d option, but that didn't seem to work. - Thomas From berrange at redhat.com Tue Jul 15 12:30:39 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Jul 2008 13:30:39 +0100 Subject: No answer to easy bug policy In-Reply-To: <20080714220022.GA6690@amd.home.annexia.org> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> Message-ID: <20080715123038.GC1369@redhat.com> On Mon, Jul 14, 2008 at 11:00:22PM +0100, Richard W.M. Jones wrote: > On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > > If you don't answer after 2 weeks and one remainder lasting also at > > least 2 week the package will be orphaned according to the policy stated > > at > > So that's 4 weeks in all? > > 2 weeks alone is way too short because people commonly go on holiday > for that length of time & longer. Yes, IMHO we are being too aggressive at trying to orphan packages from maintainers. As we are fundamentally a community of volunteers it is unreasonable to expect that every maintainer keep up2date with their their packages on a weekly basis throughout the year. There are periods when people go on vacation, or when their full-time day job means we simply cannot even have time to browse the list of BZ email spams, let alone respond to them. Defining an aggressive orphaning policy for non-responsiveness is inevitably going to result in the dismissal of maintainers who are otherwise doing a good job. The primary problem we are trying to address here is how to get bug fixed in a timely manner. Orphaning a package doesn't solve that problem, it makes it worse. Finding new maintainer(s) is the only way to get the bugs fixed. Thus we should focus more energy on making sure that *every* package in our respository has 2 or more maintainers - at very least a a primary owner, and a co-maintainer. The process on this page is biased towards quickly removing non-responsive maintainer. The focus should be on quickly *adding* new co-maintainers. http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers With suitable approved permissions in PKGDB, a co-maintainer can do just as much as the owner. So provided we can quickly add co-maintainers, there is no need to have a short timescale for removing the actual owner. A 4 week process in which to add a co-maintainer is very reasonable. Actually switching the ownership should be longer - 2-3 months. eg, after a person has been added as co-maintainer, if they have done 1 months good work with no objections then they can request to become owner. If current owner doesn't object within 4 weeks, then the owner is demoted to co-maintainer, and the new owner installed. So that's 4 weeks before someone can starting fixing bugs in a package but 12 weeks before ownership is finally switched. 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 choeger at cs.tu-berlin.de Tue Jul 15 12:54:11 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 15 Jul 2008 14:54:11 +0200 Subject: Study: Attacks on package managers In-Reply-To: References: Message-ID: <1216126451.20348.4.camel@s5.math.tu-berlin.de> Hi, obviously that means metadata needs good signatures as packages do, right? That should be easy to implement. Also metadata should be versioned and that version should be updated on a regulary (e.g. daily) base. (I don't know if it already is) Than one could simply diff the metadata(-hash) of two or more servers with a trusted base server to figure out if someone holds back updates. So that should not be _that_ big problem at all, right? Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From hughsient at gmail.com Tue Jul 15 13:04:59 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Jul 2008 14:04:59 +0100 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <1216127099.3389.15.camel@hughsie-work> On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper wrote: > 3112 | 32 0 0 0 0 0 0| gpk-update-icon All wakeups fixed in git master -- should be essentially polling free apart from when actually being used. > 3115 | 29 0 0 0 0 0 0| gnome-power-man Harder to fix, as we still have to poll the xserver to see if dpms has been enabled every now and then. There's a fix in the works for this, as X will send out notification of the changed state. Richard. From gnomeuser at gmail.com Tue Jul 15 13:21:12 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 15 Jul 2008 15:21:12 +0200 Subject: No answer to easy bug policy In-Reply-To: <20080714220022.GA6690@amd.home.annexia.org> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> Message-ID: <1216128073.2798.46.camel@dawkins> man, 14 07 2008 kl. 23:00 +0100, skrev Richard W.M. Jones: > On Sat, Jul 12, 2008 at 02:04:47AM +0200, Patrice Dumas wrote: > > If you don't answer after 2 weeks and one remainder lasting also at > > least 2 week the package will be orphaned according to the policy stated > > at > > So that's 4 weeks in all? > > 2 weeks alone is way too short because people commonly go on holiday > for that length of time & longer. Maybe some kind of exception to the rule or clarification should be added provided the maintainer is on the Vacation wiki page that this draconian type of punishment doesn't apply or doesn't apply in full. All this rule making seem to me though to be forgetting that most Fedora contributors are doing this in their sparetime, out of the goodness of their heart. Coating the progress of contributing in a continual thick layer of rules and punishment might just make it unfunny to be part of the community as such we might see a decline in our number of available maintainers. Another fear to consider before imposing more rules is that the more we force maintainers to do certain things, the less time they will have available to expand their package count, help new contributors learn the ropes and review packages in the end potentially causing grave harm to Fedora as a whole. It also might pose a barrier of entry considered much to tall for new contributors. Be careful not to regulate Fedora to death. Don't get me wrong I am strongly in favor of fixing bugs, but I would love an approach that was centered around creating and integrating tools to help maintainers. Automating the gathering of information, marking of duplicates and such things as provided by tools like Apport seems to be the saner focus as opposed to regulation at least for the moment. Do all that, then start worrying about making rules should easy bugs still slip through the net. - David Nielsen From sgrubb at redhat.com Tue Jul 15 13:39:21 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 15 Jul 2008 09:39:21 -0400 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <200807150939.21479.sgrubb@redhat.com> On Monday 14 July 2008 17:57:56 Ulrich Drepper wrote: > Still, since the script records wakeups due to timeouts almost all > mentions on this list are bad. ?Programs should be woken based on > events. ?They shouldn't poll data (which is what usually happens after a > timeout). One of the worst that I've found that's not on the list is mysqld. It has 2 threads that just never stop. -Steve From selinux at gmail.com Tue Jul 15 13:58:56 2008 From: selinux at gmail.com (Tom London) Date: Tue, 15 Jul 2008 06:58:56 -0700 Subject: rawhide report: 20080715 changes In-Reply-To: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> Message-ID: <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> On Tue, Jul 15, 2008 at 3:37 AM, Rawhide wrote: > rpm-4.5.90-0.git8426.7 > ---------------------- > * Mon Jul 14 18:00:00 2008 Panu Matilainen > - 4.5.90-0.git8426.7 > - fix mono dependency extraction (adjust for libmagic string change) > > After installing this, rpm seems very disfunctional: [root at localhost packages]# rpm -q kernel rpmdb: Program version 4.5 doesn't match environment version 0.128 error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30972) error: cannot open Packages database in /var/lib/rpm rpmdb: Program version 4.5 doesn't match environment version 0.128 error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages database in /var/lib/rpm package kernel is not installed [root at localhost packages]# Same for "rpm --rebuilddb": [root at localhost Downloads]# rpm --rebuilddb rpmdb: Program version 4.5 doesn't match environment version 0.128 error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30972) [root at localhost Downloads]# Didn't see anything strange during the update. Any thoughts on how to recover? tom -- Tom London From chris.stone at gmail.com Tue Jul 15 14:02:46 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 15 Jul 2008 07:02:46 -0700 Subject: Having problems with koji builds using mesa-libGL-devel In-Reply-To: <1215441477.24769.292.camel@localhost.localdomain> References: <1215441477.24769.292.camel@localhost.localdomain> Message-ID: 2008/7/7 Adam Jackson : > On Thu, 2008-07-03 at 12:45 -0700, Christopher Stone wrote: >> Hi, I am getting X crashes on one of my applications. It seems that >> all it needs is a recompile, however, it needs to recompile against >> mesa-libGL-devel 7.1-0.35.fc9. This is all good when I do a build >> using mock, however when I try to build using koji it picks up version >> 7.1-0.37.fc9 and I continue to get the X crashes. >> >> http://kojipkgs.fedoraproject.org/packages/xwnc/0.3.3/5.fc9/data/logs/x86_64/root.log >> >> Why does koji use the .37 version of mesa-ligGL-devel instead of the >> .35 version like mock does? > > And the fix for your package will be the same as was done for Xvnc: link > the server with -Wl,--export-dynamic. > > I was only vaguely aware that this package existed. I'm happy to see > that it's got cvsextras+, so in the future when the X build system > changes I'll try to remember to include it in the rebuilds. Hi, I tried a rebuild xwnc with these options and I still get crashes. You can test xwnc by running poker3d. So far I have only been able to get poker3d to run by building xwnc with the -35 version of mesa-libGL-devel From harald at redhat.com Tue Jul 15 14:05:01 2008 From: harald at redhat.com (Harald Hoyer) Date: Tue, 15 Jul 2008 16:05:01 +0200 Subject: rawhide report: 20080715 changes In-Reply-To: <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> Message-ID: Tom London wrote: > On Tue, Jul 15, 2008 at 3:37 AM, Rawhide wrote: >> rpm-4.5.90-0.git8426.7 >> ---------------------- >> * Mon Jul 14 18:00:00 2008 Panu Matilainen >> - 4.5.90-0.git8426.7 >> - fix mono dependency extraction (adjust for libmagic string change) >> >> > > After installing this, rpm seems very disfunctional: > > [root at localhost packages]# rpm -q kernel > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages index using db3 - (-30972) > error: cannot open Packages database in /var/lib/rpm > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages database in /var/lib/rpm > package kernel is not installed > [root at localhost packages]# > > Same for "rpm --rebuilddb": > > [root at localhost Downloads]# rpm --rebuilddb > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages index using db3 - (-30972) > [root at localhost Downloads]# > > Didn't see anything strange during the update. > > Any thoughts on how to recover? > > tom # rm -f /var/lib/rpm/__* From selinux at gmail.com Tue Jul 15 14:08:53 2008 From: selinux at gmail.com (Tom London) Date: Tue, 15 Jul 2008 07:08:53 -0700 Subject: rawhide report: 20080715 changes In-Reply-To: References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> Message-ID: <4c4ba1530807150708m1db5acfau195cbca746c95d57@mail.gmail.com> On Tue, Jul 15, 2008 at 7:05 AM, Harald Hoyer wrote: > Tom London wrote: >> >> On Tue, Jul 15, 2008 at 3:37 AM, Rawhide >> wrote: >>> >>> rpm-4.5.90-0.git8426.7 >>> ---------------------- >>> * Mon Jul 14 18:00:00 2008 Panu Matilainen >>> - 4.5.90-0.git8426.7 >>> - fix mono dependency extraction (adjust for libmagic string change) >>> >>> >> >> After installing this, rpm seems very disfunctional: >> >> [root at localhost packages]# rpm -q kernel >> rpmdb: Program version 4.5 doesn't match environment version 0.128 >> error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: >> Database environment version mismatch >> error: cannot open Packages index using db3 - (-30972) >> error: cannot open Packages database in /var/lib/rpm >> rpmdb: Program version 4.5 doesn't match environment version 0.128 >> error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: >> Database environment version mismatch >> error: cannot open Packages database in /var/lib/rpm >> package kernel is not installed >> [root at localhost packages]# >> >> Same for "rpm --rebuilddb": >> >> [root at localhost Downloads]# rpm --rebuilddb >> rpmdb: Program version 4.5 doesn't match environment version 0.128 >> error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: >> Database environment version mismatch >> error: cannot open Packages index using db3 - (-30972) >> [root at localhost Downloads]# >> >> Didn't see anything strange during the update. >> >> Any thoughts on how to recover? >> >> tom > > # rm -f /var/lib/rpm/__* > Thanks, but I was a little quick on the trigger: rebooting seems to have fixed this too. Sorry, tom -- Tom London From katzj at redhat.com Tue Jul 15 14:09:15 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 Jul 2008 10:09:15 -0400 Subject: rawhide report: 20080715 changes In-Reply-To: <4c4ba1530807150708m1db5acfau195cbca746c95d57@mail.gmail.com> References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> <4c4ba1530807150708m1db5acfau195cbca746c95d57@mail.gmail.com> Message-ID: <1216130955.4217.61.camel@aglarond.local> On Tue, 2008-07-15 at 07:08 -0700, Tom London wrote: > On Tue, Jul 15, 2008 at 7:05 AM, Harald Hoyer wrote: > > Tom London wrote: > >> rpmdb: Program version 4.5 doesn't match environment version 0.128 > >> error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > >> Database environment version mismatch > >> error: cannot open Packages index using db3 - (-30972) > >> [root at localhost Downloads]# > > > > # rm -f /var/lib/rpm/__* > > Thanks, but I was a little quick on the trigger: rebooting seems to > have fixed this too. rc.sysinit does an rm -f /var/lib/rpm/__* at boot-time Jeremy From mschwendt at gmail.com Tue Jul 15 14:21:48 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 15 Jul 2008 16:21:48 +0200 Subject: No answer to easy bug policy In-Reply-To: <1216128073.2798.46.camel@dawkins> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> <1216128073.2798.46.camel@dawkins> Message-ID: <20080715162148.47857b13.mschwendt@gmail.com> On Tue, 15 Jul 2008 15:21:12 +0200, David Nielsen wrote: > Be careful not to regulate Fedora to death. So, then the typical "there's no silver bullet" warning here. We do need guidelines for collaboration and to remove bottle-necks, where maintainers are too busy to handle incoming bz mail. Perhaps they focus on devel and don't mind if somebody else applies a patch to F-8 or F-9? These policy documents, however, try to cover each and everything, not taking into account which actual problems we run into regularly and frequently. There are multiple related policies already. Much too complex and tedious. Are there many examples of where someone is waiting long for an easy patch to be applied? Do we have examples of patches where there is disagreement about whether the patch is fine? What damage is done if existing patches are published as test updates? Is it just the theoretical threat that a patch breaks very badly and is worse than no bug-fix? This is about package maintainers who neglect packages in the eyes of the bug reporters or contributors. This is about bugs with existing fixes, but without anybody to prepare and push updates. This is not about forcing maintainers to do major version upgrades, and it shouldn't be about forcing them to orphan a package. I don't want to see a backdoor for version fanatics who want the very latest upstream release on every branch and who just wait for a minor bug to push a major version upgrade while a maintainer cannot be reached for two weeks. From jamatos at fc.up.pt Tue Jul 15 14:07:26 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 15 Jul 2008 15:07:26 +0100 Subject: rawhide report: 20080715 changes In-Reply-To: <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> Message-ID: <200807151507.40366.jamatos@fc.up.pt> On Tuesday 15 July 2008 14:58:56 Tom London wrote: > > Any thoughts on how to recover? Although radical it may be a reboot fixed the problem. :-) > tom > -- > Tom London -- Jos? Ab?lio From mjg at redhat.com Tue Jul 15 14:28:28 2008 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 15 Jul 2008 15:28:28 +0100 Subject: process wakeups In-Reply-To: References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> Message-ID: <20080715142828.GA6354@srcf.ucam.org> On Tue, Jul 15, 2008 at 01:30:50PM +0200, Harald Hoyer wrote: > g_timeout_add_seconds does not "really" sync globally. Yeah, it's non-ideal. Anything better is going to need at least glibc (and ideally kernel) support. -- Matthew Garrett | mjg59 at srcf.ucam.org From pmatilai at redhat.com Tue Jul 15 14:33:33 2008 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 15 Jul 2008 17:33:33 +0300 (EEST) Subject: rawhide report: 20080715 changes In-Reply-To: <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> Message-ID: On Tue, 15 Jul 2008, Tom London wrote: > On Tue, Jul 15, 2008 at 3:37 AM, Rawhide wrote: >> rpm-4.5.90-0.git8426.7 >> ---------------------- >> * Mon Jul 14 18:00:00 2008 Panu Matilainen >> - 4.5.90-0.git8426.7 >> - fix mono dependency extraction (adjust for libmagic string change) >> >> > > After installing this, rpm seems very disfunctional: > > [root at localhost packages]# rpm -q kernel > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages index using db3 - (-30972) > error: cannot open Packages database in /var/lib/rpm > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages database in /var/lib/rpm > package kernel is not installed > [root at localhost packages]# > > Same for "rpm --rebuilddb": > > [root at localhost Downloads]# rpm --rebuilddb > rpmdb: Program version 4.5 doesn't match environment version 0.128 > error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: > Database environment version mismatch > error: cannot open Packages index using db3 - (-30972) > [root at localhost Downloads]# > > Didn't see anything strange during the update. > > Any thoughts on how to recover? Nothing to recover, just clean up the BDB environment from previous version: # rm -f /var/lib/rpm/__db* That was supposed to happen automatically in the update (that's why it wasn't mentioned in the heads-up mail) but there's a thinko in the logic so you get to do this manually for now. - Panu - From drepper at redhat.com Tue Jul 15 14:39:41 2008 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 15 Jul 2008 07:39:41 -0700 Subject: process wakeups In-Reply-To: <20080715110658.GA2591@srcf.ucam.org> References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> Message-ID: <487CB6AD.6000100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Garrett wrote: > There are certain situations where polling is inevitable (such as > querying hardware for battery status or signal strength, pulling mail, > that kind of thing). For querying hardware there should be better ways. Have a centralized place where the information is poll and the broadcast changes. I though hal etc is supposed to do this. As for mail pulling: sure. But the frequency should be measured in minutes and not in micro-seconds. > Applications that do this should do it at > relatively low frequency, and where possible (ie, almost always) use > g_timeout_add_seconds or equivalent functionality. I assume this refers to the same thing Arjan tried to do: group wakeups of multiple waiters together. He can probably recall the details more easily than I can. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh8tq0ACgkQ2ijCOnn/RHRF/QCfeGAbjuejLQl5MDhNQafy7edA coYAn0a3cULC+vdaYVRAZOEHMA2rnQ/d =rW6D -----END PGP SIGNATURE----- From selinux at gmail.com Tue Jul 15 14:39:37 2008 From: selinux at gmail.com (Tom London) Date: Tue, 15 Jul 2008 07:39:37 -0700 Subject: rawhide report: 20080715 changes In-Reply-To: References: <20080715103724.A7B87209D0A@releng1.fedora.phx.redhat.com> <4c4ba1530807150658k3fb31ee5x7d728dc24ff44bd1@mail.gmail.com> Message-ID: <4c4ba1530807150739lb68618fn1a99b04de1cd16ea@mail.gmail.com> On Tue, Jul 15, 2008 at 7:33 AM, Panu Matilainen wrote: > Nothing to recover, just clean up the BDB environment from previous version: > # rm -f /var/lib/rpm/__db* > > That was supposed to happen automatically in the update (that's why it > wasn't mentioned in the heads-up mail) but there's a thinko in the logic so > you get to do this manually for now. > > - Panu - > No problem. After a few moments of panic, all recovered fine (including me ;) ) with a reboot. Thanks for the update, tom -- Tom London From arjan at infradead.org Tue Jul 15 14:50:21 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 15 Jul 2008 07:50:21 -0700 Subject: process wakeups In-Reply-To: <487CB6AD.6000100@redhat.com> References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> <487CB6AD.6000100@redhat.com> Message-ID: <20080715075021.084b3bda@infradead.org> On Tue, 15 Jul 2008 07:39:41 -0700 Ulrich Drepper wrote: > > Applications that do this should do it at > > relatively low frequency, and where possible (ie, almost always) > > use g_timeout_add_seconds or equivalent functionality. > > I assume this refers to the same thing Arjan tried to do: group > wakeups of multiple waiters together. He can probably recall the > details more easily than I can. g_timeout_add_seconds() is what I did ;-) it's not ideal (it doesn't allow for a range, and it only works for glib based apps).. but it's the best we have for userspace so far. we really ought to do a range based timeout (or a precision specifier) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From kevin.kofler at chello.at Tue Jul 15 15:03:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 Jul 2008 15:03:33 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <544eb990807140502x322908ect1b81e07c4af41d62@mail.gmail.com> <487C46E1.8080608@op5.se> Message-ID: Andreas Ericsson op5.se> writes: > But the URL: tag is free-style, isn't it? But it is supposed to cpntain a link to the project web page where users can find information about the project, not to a gitweb. Kevin Kofler From billcrawford1970 at gmail.com Tue Jul 15 15:15:56 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 15 Jul 2008 16:15:56 +0100 Subject: process wakeups In-Reply-To: <200807150939.21479.sgrubb@redhat.com> References: <487BCBE4.9050107@redhat.com> <200807150939.21479.sgrubb@redhat.com> Message-ID: <544eb990807150815x1e394f81q7388478bcae12061@mail.gmail.com> 2008/7/15 Steve Grubb : ... > One of the worst that I've found that's not on the list is mysqld. It has 2 > threads that just never stop. I see about 1 wakeup per second from mysqld (it's currently idle, though). What are you seeing there? From kevin.kofler at chello.at Tue Jul 15 15:26:50 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 Jul 2008 15:26:50 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> Message-ID: Andreas Ericsson op5.se> writes: > > * make releases without tags: For example, the weekly trunk snapshots of > > KDE don't get tags, nor do the extragear tarball releases. > > I'm not sure if you saw my email regarding the requirements on the SCM for it > to be useful in the scenario Doug Ledford proposes, but right at the top of > the list comes the ability to uniquely name one particular commit. If you > have that, you don't need tags. The problem with commit IDs is that they're a lot less readable and intuitive than tags. > It would be extremely poor project policy to move a tag after it's made > public Are you trying to imply that KDE has "extremely poor project policy"? I think it only makes sense to do respins that way. A release isn't always perfect on the first try. > For centralized scms, moving tags doesn't matter in the slightest, since > they can't name a commit uniquely anyway. That's not true, a SVN commit is uniquely named by the revision number. And in fact, being centralized allows SVN to actually use totally-ordered numbers, not random IDs coming from the checksum of something (which are bound to break the day you run into a collision, by the way). The best way to reproducibly name a tag in SVN would be to use the tag name (which would be part of the URL) _and_ the revision number. Tags in SVN are just directories, so you can use the directory at the given revision and you'll get the exact thing you originally checked out. > Me, being mostly a user who also happens to be a programmer, would love > to have an easy way to be able to get a clone of , > find the sources corresponding exactly to my version of the package and > then fix whatever issues I have with it. Even if it was just me willing > to do that (which I highly doubt), you'd have a net gain of one extra > spare-time developer. You can't possibly argue that making it easier for > casual developers to get involved is a bad thing. With the current system, you just have to check out the package and run "make" in one of the branches to get all source files (usually just a tarball) downloaded from the lookaside cache. Extract the tarball and you have your sources. The patches aren't applied there, but that's by design. Patches are supposed to be independent, so (with some exceptions, e.g. the kernel which often includes series of interdependent patches automatically generated from some git repository) we develop each patch against the _original_ sources, then only when actually building the package we apply them all. My workflow when I develop a patch for KDE is: 1. I extract the tarball (e.g. kdebase-workspace-4.0.98.tar.bz2). 2. This creates a directory (e.g. kdebase-workspace-4.0.98). 3. I copy this directory, appending the name of the patch I intend to write (e.g. kdebase-workspace-4.0.98-consolekit-kdm). 4. I make my changes in that directory (e.g. kdebase-workspace-4.0.98-consolekit-kdm). 5. I diff the original vs. the patched directory (e.g. diff -Nur kdebase-workspace-4.0.98 kdebase-workspace-4.0.98-consolekit-kdm >kdebase-workspace-4.0.98-consolekit-kdm.patch). 6. I copy the patch to the package branch. 7. I cvs add it to the repository. 8. I apply it in the specfile (2 lines, e.g. Patch1: kdebase-workspace-4.0.98-consolekit-kdm.patch in the header and %patch1 -p1 -b .consolekit-kdm in the %prep section). 9. I commit. 10. I run make tag. 11. I run make build BUILD_FLAGS=--nowait. 12. Koji sends me the results. 13. If the build failed, I: * repeat steps 4, 5, 6 and 9 * run make force-tag * resubmit the failed build through the Koji web interface as often as needed until it builds. I know this sounds overly complicated, but keep in mind that most of these steps are just a couple of mouse clicks or one line in a terminal, I intentionally detailed them so a beginner can understand what's going on. I'm not sure a SCM with fully-exploded sources would really make that easier. Kevin Kofler From sgrubb at redhat.com Tue Jul 15 15:28:59 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 15 Jul 2008 11:28:59 -0400 Subject: process wakeups In-Reply-To: <544eb990807150815x1e394f81q7388478bcae12061@mail.gmail.com> References: <487BCBE4.9050107@redhat.com> <200807150939.21479.sgrubb@redhat.com> <544eb990807150815x1e394f81q7388478bcae12061@mail.gmail.com> Message-ID: <200807151128.59866.sgrubb@redhat.com> On Tuesday 15 July 2008 11:15:56 Bill Crawford wrote: > > One of the worst that I've found that's not on the list is mysqld. It has > > 2 threads that just never stop. > > I see about 1 wakeup per second from mysqld (it's currently idle, > though). What are you seeing there? ps -ef | grep sql root 2227 1 0 07:41 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid mysql 2286 2227 0 07:41 ? 00:00:12 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock ls /proc/2286/task/ 2286 2296 2297 2298 2299 2301 2304 2308 2309 2312 2460 then strace them. strace -p 2301 Process 2301 attached - interrupt to quit select(0, NULL, NULL, NULL, {0, 78000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {1, 0}^C ...this is after about 5 seconds. This thread just never gets quiet and is constantly churning. My system is idle too with nothing being added or deleted or read from the database. strace -p 2304 Process 2304 attached - interrupt to quit select(0, NULL, NULL, NULL, {0, 101000}) = 0 (Timeout) select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {2, 0}^C Those are the 2 noisy threads. -Steve From nikolay at vladimiroff.com Tue Jul 15 15:29:49 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Tue, 15 Jul 2008 18:29:49 +0300 Subject: compiz and ppc64 Message-ID: <20080715152949.GA17312@marvin> Hi! For some time compiz wasn't available for ppc64 because of missing libdrm. Few days ago when I reviewing some emerald bugs(since I'm the maintainer) i noticed that there is libdrm.ppc64. So today I decided to rebuild compiz for ppc64 and the build went fine ( http://koji.fedoraproject.org/koji/taskinfo?taskID=717203 ) Also I rebuilt emerald and it also went fine. There is some more stuff to be rebuild: libcompizconfig gnome-compiz-manager compiz-fusion I can rebuild them or the maintainers can. I also have no possible way of testing this so I'll mail fedora-testing Before rebuilding whole bunch of other stuff i was wondering: Is this something important? For fedora ppc64 arch there wasn't compiz and all the composing stuff, but now there is. Is this "feature" or just some packaging bugfix? Best Regards, -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Jul 15 15:33:47 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 15 Jul 2008 08:33:47 -0700 Subject: process wakeups In-Reply-To: <20080715142828.GA6354@srcf.ucam.org> References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> <20080715142828.GA6354@srcf.ucam.org> Message-ID: <1216136027.27455.260.camel@shinybook.infradead.org> On Tue, 2008-07-15 at 15:28 +0100, Matthew Garrett wrote: > On Tue, Jul 15, 2008 at 01:30:50PM +0200, Harald Hoyer wrote: > > > g_timeout_add_seconds does not "really" sync globally. > > Yeah, it's non-ideal. Anything better is going to need at least glibc > (and ideally kernel) support. If it needs to be done per sleep event. On the other hand, if you can set a per-thread flag or tunable which says 'you can always delay my wake by up to N milliseconds', then you don't need special magic in poll/select/nanosleep/etc for that. And it would make it easier to modify userspace to use it too. In fact, you could even use it with binary-only unmodified userspace, by executing a program with the flag already set. -- dwmw2 From lyos.gemininorezel at gmail.com Tue Jul 15 15:39:20 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Tue, 15 Jul 2008 11:39:20 -0400 Subject: No answer to easy bug policy In-Reply-To: <1216120048.3631.187.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> Message-ID: <487CC4A8.4090108@gmail.com> Jesse Keating wrote: > On Tue, 2008-07-15 at 12:46 +0200, Michael Schwendt wrote: > >> I'd rather prefer a policy for package maintainers to respond to specially >> marked tickets from fellow fedora contributors in a timely manner. And >> if that results in tickets which are still not answered, timeout periods >> can be applied and give contributors the opportunity to prepare a >> test update (and only a test update!). >> > > I think that's pretty sane. Would you be willing to take the existing > policy and morph it more into the above? In particular though I'd > really like to see the policy get written up with input from those who > are just drowning in bugzilla mail. > > One thing I think would really help is if SIG meetings took a little > slice of time to quickly triage any bugs for packages related to the SIG > that have some marking of easy fix. Low hanging fruit isn't the really > important work, but it goes a long way toward fit and polish. A few > minutes to triage and say yes/no/idon'tcare to these bugs would really > help. Maybe even a BugZapper person can join the meeting and be the > person listing the bugs and following up in the bug for the SIG people. > > I don't want to make that mandatory at all, just highly suggested. > > Instead of fixing maintainers in such a bureaucratic manner... why not fix bugzilla's mailing list? Ya'll have mentioned the issue of maintainers drowning in bugzilla spam... and the majority of maintainers seem not to know and/or care how to filter their mail... so why not do it for them? Why not use the list of package maintainers and send a bug report only to those who are maintainers for said package? (This can be easily modified to add the list of CCs to those included in the bug report list) A.) This would cut down on the amount of bugzilla spam each maintainer has to sort through B.) This can be an option set in the users preferences that can be turned off if desired. C.) Will, likely, reduce the amount of time it takes to fix bugs. Just a thought... but it seems to me to be a better way to help the developers without adding undue pressure. Lyos Gemini Norezel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Tue Jul 15 15:43:44 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 15 Jul 2008 10:43:44 -0500 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <1216074433.7931.99.camel@dfarning.desktop.org> References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> Message-ID: <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> On Mon, Jul 14, 2008 at 5:27 PM, David Farning wrote: > On Mon, 2008-07-14 at 10:27 -0800, Jeff Spaleta wrote: > >> My really big question is what can we do to get the people actually >> using the Sugar interface? >> And not just the target audience for olpc..but we need to get older >> people using the interface as well, people we can get involved in the >> development process via bug reports and patches. I think it really >> comes down to being able to provide an alternative Sugar desktop that >> our Fedora users can live and work inside of. > > This a unique open source project in that developers are not developing > for themselves. Many people become involved with a project by > scratching their own itch. With Sugar, we are (hopefully) helping the > next generation. Maybe it would be a good idea to start targeting potential devs within school environment world wides. Ie. the guys who could actually becoming users (sort of) of Sugar. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From drago01 at gmail.com Tue Jul 15 15:44:05 2008 From: drago01 at gmail.com (drago01) Date: Tue, 15 Jul 2008 17:44:05 +0200 Subject: compiz and ppc64 In-Reply-To: <20080715152949.GA17312@marvin> References: <20080715152949.GA17312@marvin> Message-ID: 2008/7/15 Nikolay Vladimirov : > Hi! > > For some time compiz wasn't available for ppc64 because of missing > libdrm. Few days ago when I reviewing some emerald bugs(since I'm the > maintainer) i noticed that there is libdrm.ppc64. So today I decided > to rebuild compiz for ppc64 and the build went fine > ( http://koji.fedoraproject.org/koji/taskinfo?taskID=717203 ) > Also I rebuilt emerald and it also went fine. There is some more stuff > to be rebuild: > > compiz-fusion Started a chainbuild of compiz-fusion and compiz-fusion-extras http://koji.fedoraproject.org/koji/taskinfo?taskID=717544 > Before rebuilding whole bunch of other stuff i was wondering: > Is this something important? For fedora ppc64 arch there wasn't compiz and > all the composing stuff, but now there is. Is this "feature" or just > some packaging bugfix? Well I wouldn't really consider this a feature. From notting at redhat.com Tue Jul 15 15:47:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jul 2008 11:47:26 -0400 Subject: consolidating on gnupg2 in F10 Message-ID: <20080715154726.GB24550@nostromo.devel.redhat.com> For a really long time now, we've shipped both gnupg and gnupg2 in Fedora. In fact, in Fedora 9 a relatively standard install will get both installed. This isn't ideal, obviously - we want as much to be using the same code, keystore, etc. as possible. Here's the current list of things that require gnupg 1: AcetoneISO2 spot apt athimm duplicity robert ketchup ben perl-GnuPG-Interface mdomsch perl-Module-Signature scop pgp-tools mdomsch psi abompard qca-gnupg abompard spamassassin wtogami zeroinstall-injector salimma It appears a good number of these can be ported to gnupg2, if not all of them. Should we wire up a feature page? Bill From berrange at redhat.com Tue Jul 15 15:50:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Jul 2008 16:50:02 +0100 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <20080715155002.GN1369@redhat.com> On Mon, Jul 14, 2008 at 02:57:56PM -0700, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the worst problems wrt energy savings we have today are all the > wakeups processes request. This is not just an issue for laptops, it > relevant everywhere. > > To see the size of the problem run the attached systemtap script. On my > laptop I see the following output (47 secs runtime): > > uid | poll select epoll itimer futex nanosle signal| process > 2397 | 16 0 0 0 0 0 0| libvirtd This isn't libvirtd's fault - we don't use any timeouts, and only break out of poll() if there's real work todo. In this case it appears we're being woken up once every 5 seconds, bt a message from the DBus system bus saying NameOwnerChanged (nil) 1.237 and then almost immediately NameOwnerChanged 1.237 (nil) Which basically means that every 6 seconds some app is connecting to DBus and then almost immediately disconnecting again. What's most annoying is that I've not actually requested that DBus send me this signal. Anyway, a systemtap script probing 'unix_stream_connect' identifies the cuplrits.. # cat conn.stap probe kernel.function("unix_stream_connect").return { if ($return == 0) { p = pid() n = execname() printf ("%d %d %s\n", gettimeofday_s(), p, n) } } [root at t60wlan ~]# stap conn.stap 1216136855 8215 hal-is-caller-p 1216136855 8217 hal-ipw-killswi 1216136861 8219 hal-is-caller-p 1216136861 8221 hal-ipw-killswi 1216136867 8223 hal-is-caller-p 1216136867 8225 hal-ipw-killswi Aka /usr/libexec/hal-ipw-killswitch-linux /usr/bin/hal-is-caller-privileged which both seem to be spawned once every 5-6 seconds :-( 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 camilo at mesias.co.uk Tue Jul 15 15:50:53 2008 From: camilo at mesias.co.uk (Camilo Mesias) Date: Tue, 15 Jul 2008 16:50:53 +0100 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> Message-ID: Surely publishing an image for VMWare (ie. a virtual appliance) would be the quickest way to let people try out the software (and get started with developing it?) It would be very accessible in terms of platforms and would avoid any hardware specific foibles. I had a look at the wiki but didn't find any references to VMWare etc. -Cam From bkearney at redhat.com Tue Jul 15 15:51:30 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 15 Jul 2008 11:51:30 -0400 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> Message-ID: <487CC782.4090201@redhat.com> Point me at the instructions for building.. and I will spit out the appliance for you. -- bk Camilo Mesias wrote: > Surely publishing an image for VMWare (ie. a virtual appliance) would > be the quickest way to let people try out the software (and get > started with developing it?) > > It would be very accessible in terms of platforms and would avoid any > hardware specific foibles. > > I had a look at the wiki but didn't find any references to VMWare etc. > > -Cam > From dcbw at redhat.com Tue Jul 15 15:52:35 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 15 Jul 2008 11:52:35 -0400 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <1216137155.6039.57.camel@localhost.localdomain> On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the worst problems wrt energy savings we have today are all the > wakeups processes request. This is not just an issue for laptops, it > relevant everywhere. > > To see the size of the problem run the attached systemtap script. On my > laptop I see the following output (47 secs runtime): > > uid | poll select epoll itimer futex nanosle signal| process > 29799 |15941 7971 0 0 0 0 0| npviewer.bin > 29841 | 253 0 0 0 1531 0 0| thunderbird-bin > 3017 | 447 0 0 0 0 0 0| pulseaudio > 2467 | 76 0 0 0 0 0 0| hald > 2471 | 8 0 0 0 0 0 0| hald-runner > 2620 | 58 0 0 0 0 0 0| NetworkManager While there are probably stupidities in NM, there are also known externally-driven wakeup causes including: 1) until 2.6.27 lands, there's no way to get the rfkill switch state-change events, so NM polls them every 6 seconds _iff_ they exist. Unfortunately, they often exist in HAL even though there are no physical switches on the laptop because the nice rfkill patches haven't landed yet (again, scheduled for 2.6.27) 2) Intel-based wireless cards driven by ipw drivers send out a steady stream of background scan events, which causes any process listening for WEXT events to wake up. Somewhat fixed for ipw2200 in 2.6.24 and later by 0b5316769774d1dc2fdd702e095f9e6992af269a, but still wakes up all WEXT listeners every 4 seconds 3) Have to poll the driver every so often (every 6 seconds right now maybe?) to get signal strength information; I'd love it if drivers would just send this out over netlink or WEXT or whatever every few seconds. Not sure if people want that kernel-side though since there's not always a listener and the frequency of events should be somewhat selectable. > 13174 | 214 0 0 0 0 0 0| stapio > 3044 | 48 0 0 0 0 0 0| gnome-panel > 9115 | 16 0 0 0 0 0 0| nm-vpnc-service Interesting... I have no idea why it would be a significant wakeup source. It just listens on the D-Bus system bus, and uses the glib child-watch functionality to monitor vpnc child process state. Dan > 3112 | 32 0 0 0 0 0 0| gpk-update-icon > 3108 | 24 0 0 0 0 0 0| nm-applet > 3052 | 274 0 0 1 0 0 0| gnome-terminal > 3115 | 29 0 0 0 0 0 0| gnome-power-man > 3055 | 16 0 0 0 0 0 0| bluetooth-apple > 3093 | 16 0 0 0 0 0 0| krb5-auth-dialo > 2633 | 16 0 0 0 0 0 0| gdm-binary > 2724 | 16 0 0 0 0 0 0| gdm-simple-slav > 2630 | 16 0 0 0 0 0 0| nm-system-setti > 2470 | 16 0 0 0 0 0 0| console-kit-dae > 2385 | 16 0 0 0 0 0 0| avahi-daemon > 2397 | 16 0 0 0 0 0 0| libvirtd > 2725 | 63 214 0 4 0 0 0| Xorg > 2150 | 42 0 0 0 0 0 0| setroubleshootd > 3010 | 47 0 0 0 0 0 0| gnome-settings- > 3040 | 111 0 0 0 0 0 0| metacity > 3526 | 37 0 0 0 0 0 0| notification-da > 3085 | 49 0 0 0 0 0 0| wnck-applet > 3043 | 50 0 0 0 0 0 0| gnome-screensav > 3042 | 26 0 0 0 0 0 0| nautilus > 3050 | 8 0 0 0 0 0 0| evince > 9120 | 0 5 0 0 0 0 0| vpnc > 3342 | 11 0 0 0 0 0 0| clock-applet > 3329 | 0 6 0 0 0 0 0| pam_timestamp_c > 2337 | 0 7 0 0 0 0 0| sendmail > 2132 | 0 0 0 0 33 0 0| automount > 2958 | 0 3 0 0 0 0 0| ssh-agent > 2118 | 1 0 0 0 0 0 0| dbus-daemon > 5732 | 1 0 0 0 0 0 0| gnome-vfs-daemo > 29394 | 68 131 0 0 65 0 0| firefox > 2105 | 1 0 0 0 0 0 0| audispd > 1979 | 0 1 0 0 0 0 0| rsyslogd > > > As you can see, not all programs are equally bad and proprietary ones > (here: flash) are the worst. > > Still, since the script records wakeups due to timeouts almost all > mentions on this list are bad. Programs should be woken based on > events. They shouldn't poll data (which is what usually happens after a > timeout). > > I would hope the package maintainers can find some time and look at the > issues. Maybe at least document them in a BZ. I might try to do the > latter myself but given the large number of packages involved I'll most > likely be able to cover just a few packages. IMO it should be a release > criteria that a program does use polling. > > - -- > ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkh7y9oACgkQ2ijCOnn/RHTW6wCfWzYOn3AvjLvJ5mwWjSZwr8tX > Z84An2YYvqd9f2fkPGenE5uhDDdsan3y > =VWLu > -----END PGP SIGNATURE----- > plain text document attachment (timeout.stap) > # Copyright (C) 2008 Red Hat, Inc. > # Written by Ulrich Drepper > global process > global poll_timeouts > global epoll_timeouts > global select_timeouts > global itimer_timeouts > global nanosleep_timeouts > global futex_timeouts > global signal_timeouts > > probe kernel.function("do_sys_poll").return { > if ($return == 0) { > p = pid() > if (!(p in process)) > process[p] = execname() > poll_timeouts[p]++ > } > } > > probe kernel.function("do_select").return { > if ($return == 0) { > p = pid() > if (!(p in process)) > process[p] = execname() > select_timeouts[p]++ > } > } > > probe kernel.function("sys_epoll_wait").return { > if ($return == 0) { > p = pid() > if (!(p in process)) > process[p] = execname() > epoll_timeouts[p]++ > } > } > > probe kernel.function("do_futex").return { > if ($return == -110) { > p = pid() > if (!(p in process)) > process[p] = execname() > futex_timeouts[p]++ > } > } > > probe kernel.function("hrtimer_nanosleep").return, > kernel.function("sys_clock_nanosleep").return { > if ($return == 0) { > p = pid() > if (!(p in process)) > process[p] = execname() > nanosleep_timeouts[p]++ > } > } > > probe kernel.function("it_real_fn") { > p = pid() > itimer_timeouts[p]++ > if (!(p in process)) > process[p] = execname() > } > > probe kernel.function("sys_rt_sigtimedwait").return { > if ($return == -11) { > p = pid() > if (!(p in process)) > process[p] = execname() > signal_timeouts[p]++ > } > } > > probe kernel.function("do_exit") { > p = pid() > if (process[p] == execname()) { > delete process[p] > poll_timeouts[p] = 0 > epoll_timeouts[p] = 0 > select_timeouts[p] = 0 > itimer_timeouts[p] = 0 > futex_timeouts[p] = 0 > nanosleep_timeouts[p] = 0 > signal_timeouts[p] = 0 > } > } > > probe timer.ms(1000) { > printf("\033[2J\033[1;1H") /* clear screen */ > printf (" uid | poll select epoll itimer futex nanosle signal| process\n"); > foreach (p in process) { > if (poll_timeouts[p] != 0 || select_timeouts[p] != 0 > || epoll_timeouts[p] != 0 || itimer_timeouts[p] != 0 > || futex_timeouts[p] != 0 || nanosleep_timeouts[p] != 0 > || signal_timeouts[p] != 0) > printf ("%5d |%7d %7d %7d %7d %7d %7d %7d| %-.38s\n", p, > poll_timeouts[p], select_timeouts[p], > epoll_timeouts[p], itimer_timeouts[p], > futex_timeouts[p], nanosleep_timeouts[p], > signal_timeouts[p], process[p]) > } > } > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jspaleta at gmail.com Tue Jul 15 15:55:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 07:55:08 -0800 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> Message-ID: <604aa7910807150855k6296b66am8f9c8a7c4c3e90a7@mail.gmail.com> On Tue, Jul 15, 2008 at 7:50 AM, Camilo Mesias wrote: > Surely publishing an image for VMWare (ie. a virtual appliance) would > be the quickest way to let people try out the software (and get > started with developing it?) As a project we have so far not directly sponsored the creation of any Fedora images..for any purpose. People make them, but at the project level we do not provide anything that could be considered pre-cooked for vmware. -jef From berrange at redhat.com Tue Jul 15 15:57:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Jul 2008 16:57:27 +0100 Subject: process wakeups In-Reply-To: <1216137155.6039.57.camel@localhost.localdomain> References: <487BCBE4.9050107@redhat.com> <1216137155.6039.57.camel@localhost.localdomain> Message-ID: <20080715155727.GO1369@redhat.com> On Tue, Jul 15, 2008 at 11:52:35AM -0400, Dan Williams wrote: > On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > One of the worst problems wrt energy savings we have today are all the > > wakeups processes request. This is not just an issue for laptops, it > > relevant everywhere. > > > > To see the size of the problem run the attached systemtap script. On my > > laptop I see the following output (47 secs runtime): > > > > uid | poll select epoll itimer futex nanosle signal| process > > 29799 |15941 7971 0 0 0 0 0| npviewer.bin > > 29841 | 253 0 0 0 1531 0 0| thunderbird-bin > > 3017 | 447 0 0 0 0 0 0| pulseaudio > > 2467 | 76 0 0 0 0 0 0| hald > > 2471 | 8 0 0 0 0 0 0| hald-runner > > 2620 | 58 0 0 0 0 0 0| NetworkManager > > While there are probably stupidities in NM, there are also known > externally-driven wakeup causes including: > > 1) until 2.6.27 lands, there's no way to get the rfkill switch > state-change events, so NM polls them every 6 seconds _iff_ they exist. > Unfortunately, they often exist in HAL even though there are no physical > switches on the laptop because the nice rfkill patches haven't landed > yet (again, scheduled for 2.6.27) Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux to be run every 6 seconds, which in turns causes any app connected to DBus system bus to be send a signal every 6 seconds and thus causes all the hits against libvirtd - and a fair number of other apps in that list too 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 dcbw at redhat.com Tue Jul 15 16:01:20 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 15 Jul 2008 12:01:20 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <20080712174916.0b9fff00@infradead.org> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> Message-ID: <1216137680.6039.61.camel@localhost.localdomain> On Sat, 2008-07-12 at 17:49 -0700, Arjan van de Ven wrote: > On Sat, 12 Jul 2008 20:10:51 -0400 > > Presumably one could replicate this as needed. However, there is the > > question of whether or not it's needed. Remember that the concept > > using an upstream tarball as the canonical source version that we > > represent to the world that we are using is nothing more than a > > policy decision. Nothing in the GPL or anything else said we had to > > do that, it was just what we *chose* to do (long, long ago, in a > > galaxy far, far away). > > one thing to keep in mind... as comparison, what you don't want is what > Ubuntu is doing with their kernel (clone Linus and then just edit the > source tree); it's just one big nightmare (as you can imagine). Keeping > upstream source and local patches separate is a clear winner (anyone > who has worked on the alternative will agree with me). > If those upstream sources are a tarbal, or a tagged commit... is a lot > less relevant. Yeah, there is actually a benefit to tarball+patches approach we take right now; and that benefit is that it's extremely easy to see just what we've done to the upstream package, and it's usually really easy to extract those changes and push them upstream. You don't want a mega-diff that includes 20 specific patches. One problem working directly on exploded source trees is that you as a developer have to be much more disciplined to make small, targeted commits that are easily able to go upstream, otherwise you do end up with a huge diffmess that you simply can't upstream easily. And that's where we should always be working: upstream. Dan From camilo at mesias.co.uk Tue Jul 15 16:04:47 2008 From: camilo at mesias.co.uk (Camilo Mesias) Date: Tue, 15 Jul 2008 17:04:47 +0100 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <487CC782.4090201@redhat.com> References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> <487CC782.4090201@redhat.com> Message-ID: Hi Bryan, 2008/7/15 Bryan Kearney : > Point me at the instructions for building.. and I will spit out the > appliance for you. http://www.thoughtpolice.co.uk/vmware/ I think there's not much more to it than starting with an empty appliance (with a BIOS?) and installing the distro of your choice. On top of that you would install the Sugar stuff, then save the resulting machine image. You might want to start with the Fedora images above. I can't take the credit for the link above, but I have used his VMs from time to time. I'm sure the usual suspects will be along shortly with warnings of legal implications and so on :) Even if you don't publish an image as such (for whatever reasons, legal, disk space, bandwidth or whatever), a clear set of instructions that have been tested and proven would be very useful. My children all use Fedora and I'd be keen to show them Sugar so long as it's an easy install. If there was a VMWare image I could probably show it to representatives at the school too. I suppose how well it would be received would depend on the fit with the curriculum, but it's worth a try. -Cam From dcbw at redhat.com Tue Jul 15 16:07:13 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 15 Jul 2008 12:07:13 -0400 Subject: process wakeups In-Reply-To: <20080715155727.GO1369@redhat.com> References: <487BCBE4.9050107@redhat.com> <1216137155.6039.57.camel@localhost.localdomain> <20080715155727.GO1369@redhat.com> Message-ID: <1216138033.6039.67.camel@localhost.localdomain> On Tue, 2008-07-15 at 16:57 +0100, Daniel P. Berrange wrote: > On Tue, Jul 15, 2008 at 11:52:35AM -0400, Dan Williams wrote: > > On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > One of the worst problems wrt energy savings we have today are all the > > > wakeups processes request. This is not just an issue for laptops, it > > > relevant everywhere. > > > > > > To see the size of the problem run the attached systemtap script. On my > > > laptop I see the following output (47 secs runtime): > > > > > > uid | poll select epoll itimer futex nanosle signal| process > > > 29799 |15941 7971 0 0 0 0 0| npviewer.bin > > > 29841 | 253 0 0 0 1531 0 0| thunderbird-bin > > > 3017 | 447 0 0 0 0 0 0| pulseaudio > > > 2467 | 76 0 0 0 0 0 0| hald > > > 2471 | 8 0 0 0 0 0 0| hald-runner > > > 2620 | 58 0 0 0 0 0 0| NetworkManager > > > > While there are probably stupidities in NM, there are also known > > externally-driven wakeup causes including: > > > > 1) until 2.6.27 lands, there's no way to get the rfkill switch > > state-change events, so NM polls them every 6 seconds _iff_ they exist. > > Unfortunately, they often exist in HAL even though there are no physical > > switches on the laptop because the nice rfkill patches haven't landed > > yet (again, scheduled for 2.6.27) > > Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux > to be run every 6 seconds, which in turns causes any app connected to DBus > system bus to be send a signal every 6 seconds and thus causes all the > hits against libvirtd - and a fair number of other apps in that list too That's probably the cause, yes. Is D-Bus signal filtering done client-side or bus-side? I forget. You do have to explicitly subscribe to most signals (see dbus_bus_add_match) with libdbus otherwise you won't get them, so maybe a library that libvirt depends on is asking for the subscription or not properly limiting its subscription. Dan From rjones at redhat.com Tue Jul 15 16:04:49 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Jul 2008 17:04:49 +0100 Subject: No deletionism policy (was: Re: No answer to easy bug policy) In-Reply-To: <20080715123038.GC1369@redhat.com> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> <20080715123038.GC1369@redhat.com> Message-ID: <20080715160449.GA10129@amd.home.annexia.org> Agreed with what Dan says. I also see disturbing overtones of Wikipedia-style 'deletionism' occurring here. The urge to delete quickly things which may have been lovingly worked on for years, because it gives certain admins a sense of power. Deletionism was what drove me away from Wikipedia. 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 jspaleta at gmail.com Tue Jul 15 16:15:16 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 08:15:16 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216137680.6039.61.camel@localhost.localdomain> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> Message-ID: <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: > Yeah, there is actually a benefit to tarball+patches approach we take > right now; and that benefit is that it's extremely easy to see just what > we've done to the upstream package, and it's usually really easy to > extract those changes and push them upstream. You don't want a > mega-diff that includes 20 specific patches. I know of at least one example currently in our cvs where we went from a set of separate small patch files to one encompassing patch file. I think it was a diff from git. If we move to more advanced vcs are we going to have a harder time keeping patches separated? Or is it just a matter of education on how not to reach for the easy to produce mega patch shortcut? -jef From dcbw at redhat.com Tue Jul 15 16:24:26 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 15 Jul 2008 12:24:26 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> Message-ID: <1216139066.6039.81.camel@localhost.localdomain> On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: > > Yeah, there is actually a benefit to tarball+patches approach we take > > right now; and that benefit is that it's extremely easy to see just what > > we've done to the upstream package, and it's usually really easy to > > extract those changes and push them upstream. You don't want a > > mega-diff that includes 20 specific patches. > > I know of at least one example currently in our cvs where we went from > a set of separate small patch files to one encompassing patch file. I > think it was a diff from git. If we move to more advanced vcs are we > going to have a harder time keeping patches separated? Or is it just a > matter of education on how not to reach for the easy to produce mega > patch shortcut? That's the problem here: if we move to git (or any DVCS really), as a packager you would have to be _much_ more aware of how to use the VCS to achieve the same separation of patches and upstream source. You'd need to do something like topic branches for each patch and then merge each topic branch into a "release" branch to ensure that each of the patches was cleanly separated from the main source. Basically, moving to a DVCS and exploded source trees just raises the bar for packagers since they'd have to learn quite a bit about how DVCS works. CVS + tarball + patches are quite easy for most people to learn, but a DVCS + branches + merges is much more complicated if the changesets are small. And the changesets should always be small, otherwise we're completely failing at pushing stuff upstream. Maybe the fix here is to let package maintainers who want to use a DVCS style, and those that don't want to use the old style, and provide the ability to switch between the two styles when a new maintainer takes over the package? Dan From dledford at redhat.com Tue Jul 15 16:28:03 2008 From: dledford at redhat.com (Doug Ledford) Date: Tue, 15 Jul 2008 12:28:03 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> Message-ID: <1216139283.1891.107.camel@firewall.xsintricity.com> On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: > > Yeah, there is actually a benefit to tarball+patches approach we take > > right now; and that benefit is that it's extremely easy to see just what > > we've done to the upstream package, and it's usually really easy to > > extract those changes and push them upstream. You don't want a > > mega-diff that includes 20 specific patches. > > I know of at least one example currently in our cvs where we went from > a set of separate small patch files to one encompassing patch file. I > think it was a diff from git. If we move to more advanced vcs are we > going to have a harder time keeping patches separated? Or is it just a > matter of education on how not to reach for the easy to produce mega > patch shortcut? Education most likely. Git can git you patches one at a time, or all in one, depending on what you ask for (of course, if you import a bunch of patches all at once into a single changeset then you are stuck from then on). Our internal kernel git scripts do a patch per changeset. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Tue Jul 15 16:31:49 2008 From: dledford at redhat.com (Doug Ledford) Date: Tue, 15 Jul 2008 12:31:49 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216139066.6039.81.camel@localhost.localdomain> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> Message-ID: <1216139509.1891.111.camel@firewall.xsintricity.com> On Tue, 2008-07-15 at 12:24 -0400, Dan Williams wrote: > On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: > > > Yeah, there is actually a benefit to tarball+patches approach we take > > > right now; and that benefit is that it's extremely easy to see just what > > > we've done to the upstream package, and it's usually really easy to > > > extract those changes and push them upstream. You don't want a > > > mega-diff that includes 20 specific patches. > > > > I know of at least one example currently in our cvs where we went from > > a set of separate small patch files to one encompassing patch file. I > > think it was a diff from git. If we move to more advanced vcs are we > > going to have a harder time keeping patches separated? Or is it just a > > matter of education on how not to reach for the easy to produce mega > > patch shortcut? > > That's the problem here: if we move to git (or any DVCS really), as a > packager you would have to be _much_ more aware of how to use the VCS to > achieve the same separation of patches and upstream source. You'd need > to do something like topic branches for each patch and then merge each > topic branch into a "release" branch to ensure that each of the patches > was cleanly separated from the main source. Indeed, the workflow is different, but only in implementation. You still adhere to the same principles with the tarball + patch approach. So, it's mainly just a matter of keeping someone from being lazy with the scm instead of doing things the right way, and providing documentation on what the right way is. > Basically, moving to a DVCS and exploded source trees just raises the > bar for packagers since they'd have to learn quite a bit about how DVCS > works. CVS + tarball + patches are quite easy for most people to learn, > but a DVCS + branches + merges is much more complicated if the > changesets are small. And the changesets should always be small, > otherwise we're completely failing at pushing stuff upstream. > > Maybe the fix here is to let package maintainers who want to use a DVCS > style, and those that don't want to use the old style, and provide the > ability to switch between the two styles when a new maintainer takes > over the package? Certainly, there's no need to force any maintainer to switch the packages they take care of, so you will probably always want to support both ways of doing things. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Tue Jul 15 16:38:13 2008 From: dledford at redhat.com (Doug Ledford) Date: Tue, 15 Jul 2008 12:38:13 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> Message-ID: <1216139893.1891.118.camel@firewall.xsintricity.com> On Tue, 2008-07-15 at 15:26 +0000, Kevin Kofler wrote: > Andreas Ericsson op5.se> writes: > > > * make releases without tags: For example, the weekly trunk snapshots of > > > KDE don't get tags, nor do the extragear tarball releases. > > > > I'm not sure if you saw my email regarding the requirements on the SCM for it > > to be useful in the scenario Doug Ledford proposes, but right at the top of > > the list comes the ability to uniquely name one particular commit. If you > > have that, you don't need tags. > > The problem with commit IDs is that they're a lot less readable and intuitive > than tags. > > > It would be extremely poor project policy to move a tag after it's made > > public > > Are you trying to imply that KDE has "extremely poor project policy"? I think > it only makes sense to do respins that way. A release isn't always perfect on > the first try. Well, no offense intended even though I'm sure you're not going to like my answer, but yeah, large portions of the world think moving tags is an explicit no-no in publicly available repos. If you want to avoid respins, then you should do rc candidates out the wazoo and when it is all baked and perfect, make a final release with the tag you want. If, at some later time, it's found that you absolutely must respin, then it deserves a point update on the version. To do things any other way is a gross violation of the principle of least surprise. You run a very real risk of essentially tricking users into running the wrong code without knowing it because you change things silently. I have, on several occasions, refused to even submit packages to the review process if I knew that the upstream people changed their tarballs without changing the version on the tarball. I let them know that it was a hard requirement that any updated tarball have an updated version, and once they complied I would then look at packaging their software up and submitting it for review. They listened and agreed to why it was necessary, and I submitted their package for review after that ;-) > > For centralized scms, moving tags doesn't matter in the slightest, since > > they can't name a commit uniquely anyway. > > That's not true, a SVN commit is uniquely named by the revision number. And in > fact, being centralized allows SVN to actually use totally-ordered numbers, not > random IDs coming from the checksum of something (which are bound to break the > day you run into a collision, by the way). Nah, they did the math on the sha1 identifiers when they designed the scms. The argument of a collision is bogus. It's almost impossible to *intentionally* create a collision, let alone by accident. You're about as likely to win the lottery as have a collision, and that's saying a lot for someone like me who doesn't buy lottery tickets. > The best way to reproducibly name a tag in SVN would be to use the tag name > (which would be part of the URL) _and_ the revision number. Tags in SVN are > just directories, so you can use the directory at the given revision and you'll > get the exact thing you originally checked out. Well, as has already been discussed, it would be almost impossible to directly use svn repos. More like we would just need to import them into another scm that we can control locally (be that tarballs into a look aside cache, or exploded source into an scm, either way it's still local to us). This is due to the difficulty of being able to actually have our own tags and modifications relative to upstream's ownership of the svn repo. > > Me, being mostly a user who also happens to be a programmer, would love > > to have an easy way to be able to get a clone of , > > find the sources corresponding exactly to my version of the package and > > then fix whatever issues I have with it. Even if it was just me willing > > to do that (which I highly doubt), you'd have a net gain of one extra > > spare-time developer. You can't possibly argue that making it easier for > > casual developers to get involved is a bad thing. > > With the current system, you just have to check out the package and run "make" > in one of the branches to get all source files (usually just a tarball) > downloaded from the lookaside cache. Extract the tarball and you have your > sources. The patches aren't applied there, but that's by design. Patches are > supposed to be independent, so (with some exceptions, e.g. the kernel which > often includes series of interdependent patches automatically generated from > some git repository) we develop each patch against the _original_ sources, then > only when actually building the package we apply them all. There's no need to specifically patch against the original sources. Either the other patches in the rpm will touch the same area of code, in which case your patch won't apply over the top of them and you need a fully prepped tree to generate a patch that will apply, or your patch won't touch the same code as any other patches and regardless of whether you patch against a prepped tree or original sources the patch will still apply to the original source with at most some line offsets. So, just make prep and go. > My workflow when I develop a patch for KDE is: > 1. I extract the tarball (e.g. kdebase-workspace-4.0.98.tar.bz2). > 2. This creates a directory (e.g. kdebase-workspace-4.0.98). make prep here > 3. I copy this directory, appending the name of the patch I intend to write > (e.g. kdebase-workspace-4.0.98-consolekit-kdm). sometimes I copy the directory if I think there will be lots of files that change, otherwise I just copy the files independently to some unique backup suffix as I'm preparing to edit them and use gendiff instead of diff > 4. I make my changes in that directory (e.g. > kdebase-workspace-4.0.98-consolekit-kdm). > 5. I diff the original vs. the patched directory (e.g. diff -Nur > kdebase-workspace-4.0.98 kdebase-workspace-4.0.98-consolekit-kdm > >kdebase-workspace-4.0.98-consolekit-kdm.patch). > 6. I copy the patch to the package branch. > 7. I cvs add it to the repository. > 8. I apply it in the specfile (2 lines, e.g. Patch1: > kdebase-workspace-4.0.98-consolekit-kdm.patch in the header > and %patch1 -p1 -b .consolekit-kdm in the %prep section). > 9. I commit. > 10. I run make tag. > 11. I run make build BUILD_FLAGS=--nowait. > 12. Koji sends me the results. > 13. If the build failed, I: > * repeat steps 4, 5, 6 and 9 > * run make force-tag > * resubmit the failed build through the Koji web interface > as often as needed until it builds. > > I know this sounds overly complicated, It *is* overly complicated. Not that you did anything to make it that way, you are doing things just like I do. I'm just saying the process is more difficult than it needs to be. > but keep in mind that most of these > steps are just a couple of mouse clicks or one line in a terminal, I > intentionally detailed them so a beginner can understand what's going on. I'm > not sure a SCM with fully-exploded sources would really make that easier. Oh yeah it does. I'll use the example of git since that's what I work with most. But, as I mentioned above, sometimes I copy the entire directory and run diff, sometimes I just create backup files and run gendiff. I have had circumstances where I forgot to make a backup file and ran gendiff and then edited the spec and ran a build process (which of course wipes out the make prep directory I was working in) and only later found out I missed that file, so that file's work is now gone. Of course, this is an artifact of my workflow, but it's a pain and has happened on more than one occasion. Now, had I been working in git, then if I had ran git gui, I would have gotten a list of all the files I modified while working on the source and could select them individually or all at once for committing to the repo. There's no missing files when you do that. And since there's no make prep necessary, there's no chance of wiping anything out. And since I can do my build testing and basic run testing in the directory before I make the git commit, I can be assured that once I commit the change, the code will be exactly as I intended it to be and be functional. I mentioned in one of my previous mails that this whole thing of an exploded repo is probably more important to Red Hat than to Fedora, and that's really true if you are talking about the pure development advantage (other features of exploded source apply to Fedora as much as Red Hat, such as having a single repo able to be the canonical source for all your packages). The steps you outline above are not that bad when dealing with packages where your patches are minimal in both total size and quantity. Where it becomes important is in places like the kernel where we freeze the kernel internally but still work on it for years. We end up with well over 1,000 individual patches to our kernels long before we quit working on them. And some of those patches are *huge*. Last update (rhel5.2) I submitted a kernel patch that was 96,000 lines of diff. And that was just one of the 1000+ patches in our kernel. It's when dealing with this sort of thing that the whole exploded source method becomes *far* more important in terms of developer productivity. Right now, both the rhel4 and rhel5 kernel maintainers actually use exploded source because CVS was untenable. But, because the build system doesn't support exploded source, they have some convoluted scripts that spit out a tarball and patches from their git repo and check those into CVS solely for the purpose of building. Aside from the development advantage that isn't nearly as strong for Fedora as it is for Red Hat, there are also other advantages to exploded source scm management. Which is why I'm trying to drive this here in Fedora versus just trying to make it happen internally inside Red Hat. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jspaleta at gmail.com Tue Jul 15 16:40:00 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 08:40:00 -0800 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216139283.1891.107.camel@firewall.xsintricity.com> References: <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139283.1891.107.camel@firewall.xsintricity.com> Message-ID: <604aa7910807150940l62b8f3a1i14033940aa1d58ad@mail.gmail.com> 2008/7/15 Doug Ledford : > Education most likely. Git can git you patches one at a time, or all in > one, depending on what you ask for (of course, if you import a bunch of > patches all at once into a single changeset then you are stuck from then > on). Our internal kernel git scripts do a patch per changeset. I'm not going to call people out publically since we don't have a firm policy with regard to how patches are handled...yet. But there are other git trees right now which don't do things the way the kernel is dealing with its patches. There's going to need to be some care with regard to making sure the correct patch hygiene is encouraged(its difficult to say enforced since I doubt it could be) as packages transition to an advanced vcs setup. At a minimum we'll need someone who understand what the best practices are to help write a migration document that covers making small patchsets. -jef From lesmikesell at gmail.com Tue Jul 15 16:41:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 15 Jul 2008 11:41:55 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216137680.6039.61.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.locald! omain> Message-ID: <487CD353.2080501@gmail.com> Dan Williams wrote: > > Yeah, there is actually a benefit to tarball+patches approach we take > right now; and that benefit is that it's extremely easy to see just what > we've done to the upstream package, and it's usually really easy to > extract those changes and push them upstream. Easier than working directly in a distributed SCM where you can see not only the patch code but who committed it, when, and why? And how it might differ from other distro-specific changes if they all end up in the same repo... > One problem working directly on exploded source trees is that you as a > developer have to be much more disciplined to make small, targeted > commits that are easily able to go upstream, otherwise you do end up > with a huge diffmess that you simply can't upstream easily. > > And that's where we should always be working: upstream. Likewise if they are using a distributed SCM, the best way to get changes done there is to put the changes in a branch they can pull and merge. The down side is going to be that there are several versions of SCMs around and you'll have to follow the upstream conventions which probably differ wildly, and figure out what to do with subversion. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue Jul 15 16:55:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 15 Jul 2008 11:55:07 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216139893.1891.118.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <1216139893.1891.118.camel@firewall.xsintricity.com> Message-ID: <487CD66B.2050309@gmail.com> Doug Ledford wrote: > It's when dealing with > this sort of thing that the whole exploded source method becomes *far* > more important in terms of developer productivity. Right now, both the > rhel4 and rhel5 kernel maintainers actually use exploded source because > CVS was untenable. But, because the build system doesn't support > exploded source, they have some convoluted scripts that spit out a > tarball and patches from their git repo and check those into CVS solely > for the purpose of building. Is it feasible to do that in general to make current-style src rpms available until you can replace them completely with something better for both the build system and public source redistribution? -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Tue Jul 15 17:01:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 13:01:26 -0400 Subject: No answer to easy bug policy In-Reply-To: <487CC4A8.4090108@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> Message-ID: <1216141286.3631.209.camel@localhost.localdomain> On Tue, 2008-07-15 at 11:39 -0400, Lyos Gemini Norezel wrote: > Ya'll have mentioned the issue of maintainers drowning in bugzilla > spam... and the majority of maintainers seem not to know and/or care how > to filter their mail... so why not do it for them? Why not use the list > of package maintainers and send a bug report only to those who are > maintainers for said package? (This can be easily modified to add the > list of CCs to those included in the bug report list) > A.) This would cut down on the amount of bugzilla spam each maintainer > has to sort through > B.) This can be an option set in the users preferences that can be > turned off if desired. > C.) Will, likely, reduce the amount of time it takes to fix bugs. I think you misunderstood the problem. The mails that we are talking about /are/ the bugzilla mails directed specifically at individuals or specific mailing lists for that package. For some maintainers/software even that is far far too much, across every active Fedora/RHEL variant. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 lyos.gemininorezel at gmail.com Tue Jul 15 17:08:59 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Tue, 15 Jul 2008 13:08:59 -0400 Subject: No answer to easy bug policy In-Reply-To: <1216141286.3631.209.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> Message-ID: <487CD9AB.9080906@gmail.com> Jesse Keating wrote: > On Tue, 2008-07-15 at 11:39 -0400, Lyos Gemini Norezel wrote: > >> Ya'll have mentioned the issue of maintainers drowning in bugzilla >> spam... and the majority of maintainers seem not to know and/or care how >> to filter their mail... so why not do it for them? Why not use the list >> of package maintainers and send a bug report only to those who are >> maintainers for said package? (This can be easily modified to add the >> list of CCs to those included in the bug report list) >> A.) This would cut down on the amount of bugzilla spam each maintainer >> has to sort through >> B.) This can be an option set in the users preferences that can be >> turned off if desired. >> C.) Will, likely, reduce the amount of time it takes to fix bugs. >> > > I think you misunderstood the problem. The mails that we are talking > about /are/ the bugzilla mails directed specifically at individuals or > specific mailing lists for that package. For some maintainers/software > even that is far far too much, across every active Fedora/RHEL variant. > > Perhaps it's the fact that I don't have any packages at the moment... but I receive ALL bugzilla list email. Regardless of whether or not I have any interest in it. This is what I meant in my earlier email... people are drowning in bz spam from bugs that aren't even theirs. Perhaps filtering most, if not all of that at the BZ list itself is the best way to solve this. I realize some people have so many packages and/or a few high traffic packages to begin with... but it's a start. Lyos Gemini Norezel From jkeating at redhat.com Tue Jul 15 17:11:40 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 13:11:40 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216139283.1891.107.camel@firewall.xsintricity.com> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139283.1891.107.camel@firewall.xsintricity.com> Message-ID: <1216141900.3631.211.camel@localhost.localdomain> On Tue, 2008-07-15 at 12:28 -0400, Doug Ledford wrote: > > I know of at least one example currently in our cvs where we went from > > a set of separate small patch files to one encompassing patch file. I > > think it was a diff from git. If we move to more advanced vcs are we > > going to have a harder time keeping patches separated? Or is it just a > > matter of education on how not to reach for the easy to produce mega > > patch shortcut? > > Education most likely. Git can git you patches one at a time, or all in > one, depending on what you ask for (of course, if you import a bunch of > patches all at once into a single changeset then you are stuck from then > on). Our internal kernel git scripts do a patch per changeset. This is likely grub you speak of, where essentially we've forked grub1 without really forking it. Absolutely no upstream work goes into grub1, and grub2 remains unusable by us, so Peter and co continue to develop on grub1 for our needs. We've made the git tree he uses public, and export from that git tree into a patch we apply during the package build. We really could just switch to doing git snapshots /as/ the source for our grub build, but what would that gain us? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jspaleta at gmail.com Tue Jul 15 17:12:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 09:12:45 -0800 Subject: No answer to easy bug policy In-Reply-To: <487CD9AB.9080906@gmail.com> References: <20080712000447.GB2610@free.fr> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> Message-ID: <604aa7910807151012k379168c9s300f371c1cb7e004@mail.gmail.com> On Tue, Jul 15, 2008 at 9:08 AM, Lyos Gemini Norezel wrote: > Perhaps it's the fact that I don't have any packages at the moment... but I > receive ALL bugzilla list email. Regardless of whether or not I have any > interest in it. Did you sign up for some optional mailinglist that you shouldn't have? -jef From jkeating at redhat.com Tue Jul 15 17:14:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 13:14:26 -0400 Subject: No answer to easy bug policy In-Reply-To: <487CD9AB.9080906@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> Message-ID: <1216142066.3631.213.camel@localhost.localdomain> On Tue, 2008-07-15 at 13:08 -0400, Lyos Gemini Norezel wrote: > Perhaps it's the fact that I don't have any packages at the moment... > but I receive ALL bugzilla list email. Regardless of whether or not I > have any interest in it. What 'list' are you talking about? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 lyos.gemininorezel at gmail.com Tue Jul 15 17:18:44 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Tue, 15 Jul 2008 13:18:44 -0400 Subject: No answer to easy bug policy In-Reply-To: <487CD9AB.9080906@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> Message-ID: <487CDBF4.3000305@gmail.com> Lyos Gemini Norezel wrote: > Jesse Keating wrote: >> On Tue, 2008-07-15 at 11:39 -0400, Lyos Gemini Norezel wrote: >> >>> Ya'll have mentioned the issue of maintainers drowning in bugzilla >>> spam... and the majority of maintainers seem not to know and/or care >>> how to filter their mail... so why not do it for them? Why not use >>> the list of package maintainers and send a bug report only to those >>> who are maintainers for said package? (This can be easily modified >>> to add the list of CCs to those included in the bug report list) >>> A.) This would cut down on the amount of bugzilla spam each >>> maintainer has to sort through >>> B.) This can be an option set in the users preferences that can be >>> turned off if desired. >>> C.) Will, likely, reduce the amount of time it takes to fix bugs. >>> >> >> I think you misunderstood the problem. The mails that we are talking >> about /are/ the bugzilla mails directed specifically at individuals or >> specific mailing lists for that package. For some maintainers/software >> even that is far far too much, across every active Fedora/RHEL variant. >> >> > Perhaps it's the fact that I don't have any packages at the moment... > but I receive ALL bugzilla list email. Regardless of whether or not I > have any interest in it. > This is what I meant in my earlier email... people are drowning in bz > spam from bugs that aren't even theirs. Perhaps filtering most, if not > all of that at the BZ list itself is the best way to solve this. I > realize some people have so many packages and/or a few high traffic > packages to begin with... but it's a start. > Lyos Gemini Norezel > One other thing that may be a part of this issue... I receive every bug I submit 3 times. Once from: bugzilla at redhat.com Once from: fedora-fonts-list at redhat.com and Once from: fedora-package-review-bounces at redhat.com If a developer has 100 packages... that's 300 emails he'll receive if a bug is filed on each package. On a high traffic package... this would quickly lead to a deluge of email. No wonder many ignore such emails. If I got that many emails about bugs for all my packages... I'd reassign my "Bugs" folder in Thunderbird to be '/dev/null', but that's just me. The issue, as I see it... is too many swamped developers and not enough time to fix issues. The bugzilla fix I propose is only a start in the route to fixing the issues at hand. I like the idea of open ACLs meaning the community of trusted developers can all help in fixing bugs on any package with open ACLs. That, I suspect, will lead to a greatly reduced list of non-fixed "EasyBugs", and, at the same time, reduce the workload of our swamped developers. Lyos Gemini Norezel From drepper at redhat.com Tue Jul 15 17:22:09 2008 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 15 Jul 2008 10:22:09 -0700 Subject: process wakeups In-Reply-To: <20080715155002.GN1369@redhat.com> References: <487BCBE4.9050107@redhat.com> <20080715155002.GN1369@redhat.com> Message-ID: <487CDCC1.7020200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel P. Berrange wrote: >> uid | poll select epoll itimer futex nanosle signal| process >> 2397 | 16 0 0 0 0 0 0| libvirtd > > This isn't libvirtd's fault - we don't use any timeouts, and only > break out of poll() if there's real work todo. The script counts returns from poll() where no file descriptor is ready. This is no count of all poll() calls. Note, that all calls in a process regardless of whether it's in the binary or a DSO is counted. Of course there could be a problem with systemtap but I doubt it actually, the script is simple. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh83MEACgkQ2ijCOnn/RHRUoACeIHb4a6oMyXlUm0pG95luohak jlgAoMmz2cCKzdoPLBE3V+svauzXAfqC =SZEe -----END PGP SIGNATURE----- From lyos.gemininorezel at gmail.com Tue Jul 15 17:23:05 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Tue, 15 Jul 2008 13:23:05 -0400 Subject: No answer to easy bug policy In-Reply-To: <604aa7910807151012k379168c9s300f371c1cb7e004@mail.gmail.com> References: <20080712000447.GB2610@free.fr> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> <604aa7910807151012k379168c9s300f371c1cb7e004@mail.gmail.com> Message-ID: <487CDCF9.8090809@gmail.com> Jeff Spaleta wrote: > On Tue, Jul 15, 2008 at 9:08 AM, Lyos Gemini Norezel > wrote: > >> Perhaps it's the fact that I don't have any packages at the moment... but I >> receive ALL bugzilla list email. Regardless of whether or not I have any >> interest in it. >> > > Did you sign up for some optional mailinglist that you shouldn't have? > > -jef > > I'm on several lists, including fedora-devel, bugzilla, fedora-fonts, and a few others. Lyos Gemini Norezel From jspaleta at gmail.com Tue Jul 15 17:26:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 09:26:32 -0800 Subject: No answer to easy bug policy In-Reply-To: <487CDCF9.8090809@gmail.com> References: <20080712000447.GB2610@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> <604aa7910807151012k379168c9s300f371c1cb7e004@mail.gmail.com> <487CDCF9.8090809@gmail.com> Message-ID: <604aa7910807151026i25b4c6b7v18f9351ef0d67902@mail.gmail.com> On Tue, Jul 15, 2008 at 9:23 AM, Lyos Gemini Norezel wrote: > I'm on several lists, including fedora-devel, bugzilla, fedora-fonts, and a > few others. Okay.. why specifically did you choose to be on the bugzilla list? If you are complaining about the amount of traffic from that list... can't you just drop that specific list? There's no mandate that we all watch the full bugzilla list is there? -jef From dledford at redhat.com Tue Jul 15 17:28:11 2008 From: dledford at redhat.com (Doug Ledford) Date: Tue, 15 Jul 2008 13:28:11 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487CD66B.2050309@gmail.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <1216139893.1891.118.camel@firewall.xsintricity.com> <487CD66B.2050309@gmail.com> Message-ID: <1216142891.1891.125.camel@firewall.xsintricity.com> On Tue, 2008-07-15 at 11:55 -0500, Les Mikesell wrote: > Doug Ledford wrote: > > It's when dealing with > > this sort of thing that the whole exploded source method becomes *far* > > more important in terms of developer productivity. Right now, both the > > rhel4 and rhel5 kernel maintainers actually use exploded source because > > CVS was untenable. But, because the build system doesn't support > > exploded source, they have some convoluted scripts that spit out a > > tarball and patches from their git repo and check those into CVS solely > > for the purpose of building. > > Is it feasible to do that in general to make current-style src rpms > available until you can replace them completely with something better > for both the build system and public source redistribution? Oh, I'm sure it could be done, yeah. It's very hackish though. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 mschwendt at gmail.com Tue Jul 15 17:33:50 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 15 Jul 2008 19:33:50 +0200 Subject: No answer to easy bug policy In-Reply-To: <487CD9AB.9080906@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> Message-ID: <20080715193350.0cd8bd5d.mschwendt@gmail.com> On Tue, 15 Jul 2008 13:08:59 -0400, Lyos Gemini Norezel wrote: > Jesse Keating wrote: > > On Tue, 2008-07-15 at 11:39 -0400, Lyos Gemini Norezel wrote: > > > >> Ya'll have mentioned the issue of maintainers drowning in bugzilla > >> spam... and the majority of maintainers seem not to know and/or care how > >> to filter their mail... so why not do it for them? Why not use the list > >> of package maintainers and send a bug report only to those who are > >> maintainers for said package? (This can be easily modified to add the > >> list of CCs to those included in the bug report list) > >> A.) This would cut down on the amount of bugzilla spam each maintainer > >> has to sort through > >> B.) This can be an option set in the users preferences that can be > >> turned off if desired. > >> C.) Will, likely, reduce the amount of time it takes to fix bugs. > >> > > > > I think you misunderstood the problem. The mails that we are talking > > about /are/ the bugzilla mails directed specifically at individuals or > > specific mailing lists for that package. For some maintainers/software > > even that is far far too much, across every active Fedora/RHEL variant. > > > > > Perhaps it's the fact that I don't have any packages at the moment... > but I receive ALL bugzilla list email. Regardless of whether or not I > have any interest in it. What list is that? Your problem sounds like it's a different one. We don't refer to any list. The mailing-lists for package reviews are something else. They are fully optional. In bugzilla you only get email for tickets where you are the assignee, or Cc, or the reporter, or you watch somebody else, or your address appears in any of the fields (QA Contact e.g.). Some of the mails when other people post comments can be disabled in your bugzilla preferences. The problem is that a) several people maintain *many* packages, where "many" is multiple dozens or even hundreds of packages, and b) some packages have too many bugs which are reported, e.g. the kernel or xorg-x11. > This is what I meant in my earlier email... people are drowning in bz > spam from bugs that aren't even theirs. No. From lesmikesell at gmail.com Tue Jul 15 17:38:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 15 Jul 2008 12:38:13 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216142891.1891.125.camel@firewall.xsintricity.com> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <1216139893.1891.118.camel@firewall.xsintricity.com> <487CD66B.2050309@gmail.com> <1216142891.1891.125.camel@firewall.xsintricity.com> Message-ID: <487CE085.7010302@gmail.com> Doug Ledford wrote: > >>> It's when dealing with >>> this sort of thing that the whole exploded source method becomes *far* >>> more important in terms of developer productivity. Right now, both the >>> rhel4 and rhel5 kernel maintainers actually use exploded source because >>> CVS was untenable. But, because the build system doesn't support >>> exploded source, they have some convoluted scripts that spit out a >>> tarball and patches from their git repo and check those into CVS solely >>> for the purpose of building. >> Is it feasible to do that in general to make current-style src rpms >> available until you can replace them completely with something better >> for both the build system and public source redistribution? > > Oh, I'm sure it could be done, yeah. It's very hackish though. Backwards compatibility to simplify user's lives is sometimes worth a hack. Isn't that what RHEL is all about - and for good reasons? -- Les Mikesell lesmikesell at gmail.com From mschwendt at gmail.com Tue Jul 15 17:39:07 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 15 Jul 2008 19:39:07 +0200 Subject: No answer to easy bug policy In-Reply-To: <487CDBF4.3000305@gmail.com> References: <20080712000447.GB2610@free.fr> <487815CB.2090900@gmail.com> <1216030884.27495.6.camel@ruth> <20080714154212.GA2569@free.fr> <1216050515.3631.0.camel@localhost.localdomain> <3vask5xiru.ln2@ppp1053.in.ipex.cz> <20080715124626.a6fcb0d8.mschwendt@gmail.com> <1216120048.3631.187.camel@localhost.localdomain> <487CC4A8.4090108@gmail.com> <1216141286.3631.209.camel@localhost.localdomain> <487CD9AB.9080906@gmail.com> <487CDBF4.3000305@gmail.com> Message-ID: <20080715193907.972f59eb.mschwendt@gmail.com> On Tue, 15 Jul 2008 13:18:44 -0400, Lyos Gemini Norezel wrote: > One other thing that may be a part of this issue... > I receive every bug I submit 3 times. Not normal. > Once from: bugzilla at redhat.com That is normal. Check your Account>Email Preferences at bugzilla.redhat.com where you can disable several types of mails. > Once from: fedora-fonts-list at redhat.com For every ticket you open or only for tickets where fedora-fonts-list is in Cc? > and Once from: fedora-package-review-bounces at redhat.com Only for package review comments, I guess. Then unsubscribe from that optional list. Hardly anybody has the time to process all the traffic on it. Your conclusions regarding "bugzilla spam" are wrong, though. From fedora-devel-list at krp.org.uk Tue Jul 15 18:51:15 2008 From: fedora-devel-list at krp.org.uk (Kevin Page) Date: Tue, 15 Jul 2008 19:51:15 +0100 Subject: No answer to easy bug policy In-Reply-To: <1215850370.24851.29.camel@hughsie-work> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> Message-ID: <1216147875.16175.123.camel@keyop> On Sat, 2008-07-12 at 09:12 +0100, Richard Hughes wrote: > Surely the maintainer in question knows the package well enough to > decide whether to merge patches? For instance, I might push a patch > upstream and hold off applying it to fedora as it's trivial and will > get updated at the next version bump of my package in a few weeks. If this were happening for all packages, I don't think anyone would have a problem? Although the reporter might like to know that an update is forthcoming... because no-one likes to feel ignored (or waste their time finding a solution if one is already forthcoming). The problem is when a few weeks turns into numerous months. Regards, kev. From fedora-devel-list at krp.org.uk Tue Jul 15 19:02:33 2008 From: fedora-devel-list at krp.org.uk (Kevin Page) Date: Tue, 15 Jul 2008 20:02:33 +0100 Subject: No answer to easy bug policy In-Reply-To: <20080715162148.47857b13.mschwendt@gmail.com> References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> <1216128073.2798.46.camel@dawkins> <20080715162148.47857b13.mschwendt@gmail.com> Message-ID: <1216148553.16175.133.camel@keyop> On Tue, 2008-07-15 at 16:21 +0200, Michael Schwendt wrote: > We do need guidelines for collaboration and to remove bottle-necks, > where maintainers are too busy to handle incoming bz mail. Perhaps > they focus on devel and don't mind if somebody else applies a patch to > F-8 or F-9? I suspect this is the case - or at least one common case. Perhaps the problem is more acute with fast moving packages, or where the package maintainer is also an upstream developer? When, understandably, the focus probably isn't on existing releases. Is this a consequence of the laudable push to upstream? Are back-ported bugfixes a special case that could be highlighted to maintainers or applied by other maintainers? Could better use be made of the EasyFix and/or Patch keywords? (I only discovered them because of this thread). Perhaps if this process worked better more people would be inclined to seek out patches already available upstream or from other distros? Or if their own patch take it upstream themselves knowing it was a sure-fire way to get a timely fix in their favourite distribution? Removing maintainers does seem silly. It's clear in many cases that the maintainer is just overwhelmed, not inactive. By way of an example: at the beginning of the year I fixed a problem found in F8 and built patches. Nothing ground breaking. For F9 things worked pretty well. Encouraged by the Fedora "upstream" mantra (and lack of response in BZ) I went upstream - the patch was accepted, pushed in an upstream release, and 3 months later carried in F9. Worst case would have been the 6 month Fedora development cycle. Of course it's still frustrating that a fix exists but isn't in the hands of users. It's sucked for F8 - where the problem was initially identified. It's only just been partially fixed; some related bugs still are outstanding and seem to be following a similar path. There's not going to be a Fedora update to the new upstream release, and while the appropriate patches (already accepted in upstream trunk - so easy patches) are linked in bugzilla, there aren't errata or even test builds forthcoming. I've lost faith that the remaining bugzilla entries will be acted upon, and to be honest, I'm loosing interest and motivation. Fedora makes a fuss about encouraging contributions and participation. Sorry, but I've spent *far* more time and effort trying to progress bugs than identifying the problems and writing or finding fixes. I recognise that traditional management structures are often skewed to maximise the efficiency of those higher up at the expense of those further down... but if you want volunteer contributors to feel their efforts are worthwhile and worth repeating, what currently happens doesn't work. One conclusion from this thread is that it's accepted that some maintainers don't follow bugzilla. Not condoned, but accepted as a reality. That's clearly incompatible with asking users to report their problems in bugzilla. Regards, kev. From jkeating at redhat.com Tue Jul 15 19:10:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 15:10:22 -0400 Subject: Release Engineering Email Trac Queue Disabled Message-ID: <1216149022.3631.229.camel@localhost.localdomain> Until further notice the email to trac gateway for rel-eng has been disabled. We've been unable to cope with the spam attacks and the subsequent mail loops that have been created, and thus we have disabled the gateway. For the time being if you need release engineering to do something for you, please use the web UI to file a ticket. It allows for anonymous filing, but we would prefer you put in your email address so that you get properly contacted when the task is complete. https://fedorahosted.org/rel-eng/newticket If anybody would like to help us take another stab at email to trac submissions, feel free to contact us on rel-eng at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/rel-eng or in #fedora-admin on freenode IRC. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From berrange at redhat.com Tue Jul 15 19:13:15 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Jul 2008 20:13:15 +0100 Subject: process wakeups In-Reply-To: <487CDCC1.7020200@redhat.com> References: <487BCBE4.9050107@redhat.com> <20080715155002.GN1369@redhat.com> <487CDCC1.7020200@redhat.com> Message-ID: <20080715191315.GQ1369@redhat.com> On Tue, Jul 15, 2008 at 10:22:09AM -0700, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel P. Berrange wrote: > >> uid | poll select epoll itimer futex nanosle signal| process > >> 2397 | 16 0 0 0 0 0 0| libvirtd > > > > This isn't libvirtd's fault - we don't use any timeouts, and only > > break out of poll() if there's real work todo. > > The script counts returns from poll() where no file descriptor is ready. > This is no count of all poll() calls. Sorry I wasn't being clear. The call to poll() with a 0 second timeout is an artifact of the way the DBus/Avahi/event loop integration works. It gets a wakeup on a file descriptor, processes some messages and then does one iteration through the main loop with a 0 second timeout to flush out the queues, before finally going back to sleep for events on its file descriptors. As such the poll() with timeout is harmless - the process was already awake at this point. Its the wakeup from irrelevant DBus signals that's the real problem that needs to be addressed - once that's solved the poll() will timeout won't be done. 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 jspaleta at gmail.com Tue Jul 15 19:19:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 11:19:56 -0800 Subject: No answer to easy bug policy In-Reply-To: <1216147875.16175.123.camel@keyop> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> <1216147875.16175.123.camel@keyop> Message-ID: <604aa7910807151219q20a21deey334fd68e55f7e72f@mail.gmail.com> On Tue, Jul 15, 2008 at 10:51 AM, Kevin Page wrote: > The problem is when a few weeks turns into numerous months. The solution is and continues to be to encourage packages be put under the purview of maintainer teams who are comfortable working with each other and care about the packages in question regardless of who the primary owner of a package is. SIGs are the obvious construct here, but can we carve up all of the packagespace to fall inside at least one SIG? Most if not all of my packages aren't associated with a SIG at all currently, so I admit I'm hypothesizing about the value of SIGs to reduce the problem of long lived fixable bugs. -jef From drago01 at gmail.com Tue Jul 15 19:35:52 2008 From: drago01 at gmail.com (drago01) Date: Tue, 15 Jul 2008 21:35:52 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: <1216091968.9625.13.camel@tuxhugs> References: <1216091968.9625.13.camel@tuxhugs> Message-ID: 2008/7/15 Peter Gordon : > Hi, all. > > Just an FYI: I've bumped rb_libtorrent to 0.13.1 in Rawhide, which > changes the soname (libtorrent-0.12.1.so -->libtorrent-rasterbar.so.0) > > Aside from the large amount of bug-fixes, packaging recent versions of > rb_libtorrent will make it much more feasible to use a system copy with > Deluge 1.0 soon (which is just hitting its RCs, and currently uses its > own internal copy synced to upstream trunk every so often). > > According to repoquery, the only thing that currently depends on this > library is linkage (a GTK+ BitTorrent client); and that - according to > its upstream authors - should work just fine with this updated > rb_libtorrent once an update to linkage-0.2.0 is pushed. > > Howevever, I think that linkage-0.2.0 still needs some D-BUS C++ love, > so it'll probably remain broken until that happens. (If needed, we can > maintain a separate compat package for rb_libtorrent-0.12.x; but I hope > that it will not be necessary.) I tryed to do a scratch build of llinkage 0.2.0 [1] against the new rb_libtorrent but it fails.[2] Which is odd (complaining about cannot find 0.13) while the root.log shows that it is indeed installed. [3] 1: http://koji.fedoraproject.org/koji/taskinfo?taskID=718436 2: http://koji.fedoraproject.org/koji/getfile?taskID=718436&name=build.log 3: http://koji.fedoraproject.org/koji/getfile?taskID=718455&name=root.log From jkeating at redhat.com Tue Jul 15 19:42:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jul 2008 15:42:21 -0400 Subject: No answer to easy bug policy In-Reply-To: <604aa7910807151219q20a21deey334fd68e55f7e72f@mail.gmail.com> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> <1216147875.16175.123.camel@keyop> <604aa7910807151219q20a21deey334fd68e55f7e72f@mail.gmail.com> Message-ID: <1216150941.3631.232.camel@localhost.localdomain> On Tue, 2008-07-15 at 11:19 -0800, Jeff Spaleta wrote: > Most if not all of my packages aren't associated with a SIG at all > currently, so I admit I'm hypothesizing about the value of SIGs to > reduce the problem of long lived fixable bugs. They belong in the SIGLess SIG -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jspaleta at gmail.com Tue Jul 15 19:45:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 11:45:13 -0800 Subject: No answer to easy bug policy In-Reply-To: <1216150941.3631.232.camel@localhost.localdomain> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> <1216147875.16175.123.camel@keyop> <604aa7910807151219q20a21deey334fd68e55f7e72f@mail.gmail.com> <1216150941.3631.232.camel@localhost.localdomain> Message-ID: <604aa7910807151245s6affa794h12e0a87db27dc0e5@mail.gmail.com> 2008/7/15 Jesse Keating : > They belong in the SIGLess SIG Now I want to rename SIG's as HOME's -jef From sebastian at when.com Tue Jul 15 20:31:20 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Tue, 15 Jul 2008 22:31:20 +0200 Subject: Fedora Spins and "where will this end?" Message-ID: <487D0918.3010309@when.com> Hi all, as you may have noticed, there has been a kind of discussion concerning the future spins for F10 (and later) on this list. I was just drawing up some statements for a possible Fedora EDU Math Spin [1] (note: this is just a draft for now), but I think there are some points, which should be mentioned. The question I would like to ask is: "Where will all this lead to?" I need to explain some things: I created some time ago this roadmap [2] for the education SIG. In one of our first meetings, we decided to focus first on applications for mathematical purposes - that's how the idea of this EDU Math spin was born. On the other hand, I'm aware of the fact (due to some discussions I had with Warren at the beginning) that there are others, who're building as well spins: Warren announced a K12LTSP spin including his LTSP5-work [3], even if I don't know, how the current state is there [4]. So far so good, but what else do we have? The Astronomy SIG is preparing an astronomy spin, too [5]. And I would bet that there'll be an OLPC (or more specific: a sugar-based) spin more than soon [6] - this has also already been mentioned three month ago in one of the education SIG's meetings [7]. But then, have we already covered all possible topics - even if we stick with the educational purposes for now? I tend to say no! There might be still some place for an Fedora Education Language Spin (hey, why don't why split this one up? - Fedora Education Language English and Fedora Education Language German spin are awaiting their maintainers!)... Sorry, this might somehow sound inappropriate, but that is just the way it is. Don't get me wrong - I'm even myself a member of the Spin SIG and I applaud everyone's efforts to make use of this innovative technology - and I'm not going to blame anyone for his/her work, but still: I think it's obvious that we're going to run into trouble that way... What do you think? Sebastian --- [1] http://fedoraproject.org/wiki/Features/Education [2] http://fedoraproject.org/wiki/SIGs/Education/Roadmap [3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00888.html [4] http://fedoraproject.org/wiki/Features/K12Linux [5] http://fedoraproject.org/wiki/SIGs/Astronomy/Spin [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00926.html [7] http://fedoraproject.org/wiki/SIGs/Education/Meetings/2008-05-09 From jwilliam at xmission.com Tue Jul 15 20:59:10 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Tue, 15 Jul 2008 14:59:10 -0600 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: References: <1215999441.29945.430.camel@dfarning.desktop.org><604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com><1216074433.7931.99.camel@dfarning.desktop.org><16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com><487CC782.4090201@redhat.com> Message-ID: http://dev.laptop.org/pub/livebackupcd/build-708+joyride-2024/XO-LiveCD_0806 07.iso Seems to work pretty well on VirtualBox. http://www.virtualbox.org/ > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Camilo Mesias > Sent: Tuesday, July 15, 2008 10:05 AM > To: Development discussions related to Fedora > Subject: Re: Fedora, OLPC, and Sugar Labs > > Hi Bryan, > > 2008/7/15 Bryan Kearney : > > Point me at the instructions for building.. and I will spit out the > > appliance for you. > > http://www.thoughtpolice.co.uk/vmware/ > > I think there's not much more to it than starting with an empty > appliance (with a BIOS?) and installing the distro of your choice. On > top of that you would install the Sugar stuff, then save the resulting > machine image. > > You might want to start with the Fedora images above. > > I can't take the credit for the link above, but I have used his VMs > from time to time. > > I'm sure the usual suspects will be along shortly with warnings of > legal implications and so on :) Even if you don't publish an image as > such (for whatever reasons, legal, disk space, bandwidth or whatever), > a clear set of instructions that have been tested and proven would be > very useful. > > My children all use Fedora and I'd be keen to show them Sugar so long > as it's an easy install. If there was a VMWare image I could probably > show it to representatives at the school too. I suppose how well it > would be received would depend on the fit with the curriculum, but > it's worth a try. > > -Cam > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jspaleta at gmail.com Tue Jul 15 21:02:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 13:02:13 -0800 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D0918.3010309@when.com> References: <487D0918.3010309@when.com> Message-ID: <604aa7910807151402h27bba1eds6ee610e752dcf333@mail.gmail.com> On Tue, Jul 15, 2008 at 12:31 PM, Sebastian Dziallas wrote: > The question I would like to ask is: "Where will all this lead to?" Where does it lead...it leads to a lot of spins. We've known that for a while. What we hope is that the Spin SIG leads to higher quality and more maintainable spins. The Spin SIG is the process by which we can tier these efforts so we do not have to support each and every spin concept as part of the "Release" process. Fact 0: We want people to build quality spins. Fact 1: our spin creation tools are make it dirt simple to create spins, but we still need a best-practices approach with human review to ensure quality. Fact 2: We do not have the resource to build and host every possible spin that the community is interested in building. Its perfectly okay if our community wants to build 100 different solid spin concepts that we could brand as Fedora. If you and warren need to work in parallel to get spin concepts up and running that target similar but different usage cases..that's okay too. The key idea is this, with the Spin SIG and the kickstart pool, community members like yourself can work on these things, can even build these things via Fedora infrastructure. The Spin SIG sets defines the quality bar for what lives in the kickstart pool. Everyone who wants to brand their spin as a Fedora spin, and we do want people to be able to call these things Fedora, need to meet the technical and quality bars that the Spin SIG defines. And you know what else, over time, as we get more comfortable with usb as a delivery mechanism and the size of affordable usb thumb drives continues to go up this will impact what we think of as space limits on a spin and people will push beyond the cd or dvd size boundary and target there spin images for usb keys...that's okay to. At that point you and warren might ba able to merge your efforts..and that would be wonderful. But the Fedora Project doesn't have to "release" these sorts of spins as part of any Fedora Release..even once they are granted access to the trademark. What does that mean? That means community members need to find their own hosting to point users to for the spin binaries they produce. And you know what that is completely okay too. We simply do not have the resources to host everything that people in our community want to do. As Spins become more popular and more innovative we will have to make some hard choices as to which Spins should be part of a particular Fedora release, every release period. Competition for scarce resources is the responsible approach to resource management. And that is where the release process comes in. Spins can be submitted for release selection..I believe right now that is expected to happen as part of the Release Feature process..releases are chosen based on merit and constrained by infrastructure resources set aside for spins. If a spin isn't part of a release, then it doesn't get official project hosting..but it can still get trademark access because it lives in the kickstart pool. It's a compromise that lifts up the best of the best while still letting new spin development flourish. -jef From sebastian at when.com Tue Jul 15 21:05:57 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Tue, 15 Jul 2008 23:05:57 +0200 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D0918.3010309@when.com> References: <487D0918.3010309@when.com> Message-ID: <487D1135.7020500@when.com> Sebastian Dziallas schrieb: > Hi all, > > as you may have noticed, there has been a kind of discussion concerning > the future spins for F10 (and later) on this list. I was just drawing up > some statements for a possible Fedora EDU Math Spin [1] (note: this is > just a draft for now), but I think there are some points, which should > be mentioned. > > The question I would like to ask is: "Where will all this lead to?" > > I need to explain some things: > > I created some time ago this roadmap [2] for the education SIG. In one > of our first meetings, we decided to focus first on applications for > mathematical purposes - that's how the idea of this EDU Math spin was > born. On the other hand, I'm aware of the fact (due to some discussions > I had with Warren at the beginning) that there are others, who're > building as well spins: Warren announced a K12LTSP spin including his > LTSP5-work [3], even if I don't know, how the current state is there [4]. > > So far so good, but what else do we have? The Astronomy SIG is preparing > an astronomy spin, too [5]. And I would bet that there'll be an OLPC (or > more specific: a sugar-based) spin more than soon [6] - this has also > already been mentioned three month ago in one of the education SIG's > meetings [7]. > > But then, have we already covered all possible topics - even if we stick > with the educational purposes for now? I tend to say no! There might be > still some place for an Fedora Education Language Spin (hey, why don't > why split this one up? - Fedora Education Language English and Fedora > Education Language German spin are awaiting their maintainers!)... > > Sorry, this might somehow sound inappropriate, but that is just the way > it is. Don't get me wrong - I'm even myself a member of the Spin SIG and > I applaud everyone's efforts to make use of this innovative technology - > and I'm not going to blame anyone for his/her work, but still: I think > it's obvious that we're going to run into trouble that way... > > What do you think? > > Sebastian > > --- > > [1] http://fedoraproject.org/wiki/Features/Education > [2] http://fedoraproject.org/wiki/SIGs/Education/Roadmap > [3] > https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00888.html > > [4] http://fedoraproject.org/wiki/Features/K12Linux > [5] http://fedoraproject.org/wiki/SIGs/Astronomy/Spin > [6] > https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00926.html > [7] http://fedoraproject.org/wiki/SIGs/Education/Meetings/2008-05-09 (Yeah, I know, somewhat odd to reply to myself, but there's something to add) By the way: I think, the question is also: Who is going to use all these spins? Is the average user downloading three different education spins? Or isn't he just moving to another distribution with an all-in-one solution? We had such a discussion in one of the education SIG meetings... somebody predicted teachers asking their students to insert spin 17B for the current lesson. ...just my two cents ;) Sebastian From jspaleta at gmail.com Tue Jul 15 21:18:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 Jul 2008 13:18:54 -0800 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D1135.7020500@when.com> References: <487D0918.3010309@when.com> <487D1135.7020500@when.com> Message-ID: <604aa7910807151418v769c7ebxe90117ae33af7484@mail.gmail.com> On Tue, Jul 15, 2008 at 1:05 PM, Sebastian Dziallas wrote: > By the way: I think, the question is also: Who is going to use all these > spins? Is the average user downloading three different education spins? Or > isn't he just moving to another distribution with an all-in-one solution? We will... NEVER... have an all-in-one solution for every possible usage that can be thought of as a stand alone live image. The repository is huge and will continue to grow. A Spin image is at best a starting point meant to address a narrow usage case. If you really need to do a lot with the operating system, then you will end up needing to install the operating system and install more software. Education as a topic can be made as broad as the full extent of our software catalog without much trouble. > We had such a discussion in one of the education SIG meetings... somebody > predicted teachers asking their students to insert spin 17B for the current > lesson. Or perhaps we make generating single-purpose spins so easy, that individual teachers can produce exactly the Fedora Spin they need for their classroom, with exactly the software they want from a livecd. Spins are not and will not replace the need to do an installation to hard disk and install additional packages. -jef From sundaram at fedoraproject.org Tue Jul 15 21:18:24 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jul 2008 02:48:24 +0530 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D1135.7020500@when.com> References: <487D0918.3010309@when.com> <487D1135.7020500@when.com> Message-ID: <487D1420.9050803@fedoraproject.org> Sebastian Dziallas wrote: > > By the way: I think, the question is also: Who is going to use all these > spins? Is the average user downloading three different education spins? > Or isn't he just moving to another distribution with an all-in-one > solution? That's a false dichotomy. The fundamental qualification to be considered a Fedora spin is that packages are already part of the Fedora repository which means that the Fedora already has the all-in-one solution. Spins merely provide a convenient starting point for those interested. Perhaps you will be interested in https://fedoraproject.org/wiki/Spins/What_is_a_spin https://fedoraproject.org/wiki/Category:Spins > We had such a discussion in one of the education SIG meetings... > somebody predicted teachers asking their students to insert spin 17B for > the current lesson. If it is a meaningful and valuable spin (as determined by Spin SIG and others) then that's perfectly fine. Rahul From alexl at users.sourceforge.net Wed Jul 16 00:35:17 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 15 Jul 2008 17:35:17 -0700 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: (drago's message of "Tue\, 15 Jul 2008 21\:35\:52 +0200") References: <1216091968.9625.13.camel@tuxhugs> Message-ID: <5cr69uoed6.fsf@allele2.eebweb.arizona.edu> >>>>> "d" == drago01 writes: [...] d> I tryed to do a scratch build of llinkage 0.2.0 [1] against the new d> rb_libtorrent but it fails.[2] Which is odd (complaining about d> cannot find 0.13) while the root.log shows that it is indeed d> installed. [3] d> 1: http://koji.fedoraproject.org/koji/taskinfo?taskID=718436 2: d> http://koji.fedoraproject.org/koji/getfile?taskID=718436&name=build.log d> 3: d> http://koji.fedoraproject.org/koji/getfile?taskID=718455&name=root.log Looking at that build.log it looks like it's failing because of a patch that fails, not an error from configure or make: + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #0 (linkage-0.1.4-plugindir.patch):' Patch #0 (linkage-0.1.4-plugindir.patch): + /bin/cat /builddir/build/SOURCES/linkage-0.1.4-plugindir.patch + /usr/bin/patch -s -p1 -b --suffix .plugindir --fuzz=0 1 out of 1 hunk FAILED -- saving rejects to file configure.rej error: Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) Alex From notting at redhat.com Tue Jul 15 22:24:27 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jul 2008 18:24:27 -0400 Subject: handling a 'debug' or 'development' setting Message-ID: <20080715222427.GA1170@nostromo.devel.redhat.com> In initscripts recently, we added code that would conditionally enable two forms of malloc debugging. [1] While this build was disabled shortly after it hit the build system (because it broke the build system [2]), it raised a more general issue. We should have a generic framework for running in a 'debug' or 'development' mode that does extra debugging at the sake of some minimal amount of performance. For example, right now in the rawhide kernel we enable various debug options, which are then disabled when we do final builds for a release. Wouldn't it be better if these could be switched on somehow at runtime based on configuration? Simiarly, there may be debugging parameters already in /proc or /sys that can be twiddled if we're willing to run in a debug mode. This leads to a few questions: 1) What can we reasonably set? Right now, there's MALLOC_CHECK_ and MALLOC_PERTURB. There should be more. Is there anything in the various desktops that is appropriate? 2) How best to deploy this? The current malloc checking is added in the initscripts package as a profile.d script, enabled based on a file in /etc/sysconfig. While it could be done similar to how the kernel's debug support is done (rawhide builds set the config file to be enabled, final builds do not), I'm wondering if there's a better way. For example, do we have a 'fedora-debug' package that contains all the relevant settings that can be set? Do we make this required by a particular rawhide package, but not by the release package? Just looking for brainstorming ideas right now. Bill From mcepl at redhat.com Wed Jul 16 00:51:03 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 16 Jul 2008 02:51:03 +0200 Subject: No answer to easy bug policy References: <20080712000447.GB2610@free.fr> <20080714220022.GA6690@amd.home.annexia.org> <1216128073.2798.46.camel@dawkins> <20080715162148.47857b13.mschwendt@gmail.com> <1216148553.16175.133.camel@keyop> Message-ID: On 2008-07-15, 19:02 GMT, Kevin Page wrote: > One conclusion from this thread is that it's accepted that some > maintainers don't follow bugzilla. Not condoned, but accepted as a > reality. That's clearly incompatible with asking users to report their > problems in bugzilla. I think it should be emphasized that ajax & co. have me as their trusted bug triager/bugmaster to watch over their bugs for them. So, it is not like there is no control over Xorg & co. (and Gecko & co.) bugs ? just that such control is not provided by ajax himself, because he is doing way too much way more important things. Mat?j From peter at thecodergeek.com Wed Jul 16 01:02:50 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 15 Jul 2008 18:02:50 -0700 Subject: handling a 'debug' or 'development' setting In-Reply-To: <20080715222427.GA1170@nostromo.devel.redhat.com> References: <20080715222427.GA1170@nostromo.devel.redhat.com> Message-ID: <1216170170.3372.2.camel@tuxhugs> On Tue, 2008-07-15 at 18:24 -0400, Bill Nottingham wrote: > 1) What can we reasonably set? > > Right now, there's MALLOC_CHECK_ and MALLOC_PERTURB. There > should be more. Is there anything in the various desktops > that is appropriate? I would love it if, when this 'debug mode' is active, any package installation would automagically install the relevant debuginfos to accompany it. (Likewise, any package removal should remove the leaf debuginfo.) -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 davej at redhat.com Wed Jul 16 01:22:48 2008 From: davej at redhat.com (Dave Jones) Date: Tue, 15 Jul 2008 21:22:48 -0400 Subject: handling a 'debug' or 'development' setting In-Reply-To: <20080715222427.GA1170@nostromo.devel.redhat.com> References: <20080715222427.GA1170@nostromo.devel.redhat.com> Message-ID: <20080716012248.GC17417@redhat.com> On Tue, Jul 15, 2008 at 06:24:27PM -0400, Bill Nottingham wrote: > In initscripts recently, we added code that would conditionally > enable two forms of malloc debugging. [1] While this build was > disabled shortly after it hit the build system (because it > broke the build system [2]), it raised a more general issue. > > We should have a generic framework for running in a 'debug' > or 'development' mode that does extra debugging at the sake > of some minimal amount of performance. > > For example, right now in the rawhide kernel we enable various > debug options, which are then disabled when we do final builds > for a release. Wouldn't it be better if these could be switched > on somehow at runtime based on configuration? For the kernel options, the problem is that most of the costly ones aren't runtime switchable, and can't be made to do so. Their cost comes from the growth of various data structures, so we need to copy more data around etc. (as an example, page structs almost double in size with lockdep enabled on 32bit). Even if we took all the options which /are/ runtime switchable, put them under your config management proposal, and then turned them off, the cost of the stuff that's still enabled is pretty dramatic. (Especially things like PAGEALLOC_DEBUG) I don't really have much of an opinion on whether one way is better than the other, but I want people to realise that turning off the knobs that are turnable isn't going to be the silver bullet to performance. Dave -- http://www.codemonkey.org.uk From mclasen at redhat.com Wed Jul 16 03:15:43 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 15 Jul 2008 23:15:43 -0400 Subject: handling a 'debug' or 'development' setting In-Reply-To: <20080715222427.GA1170@nostromo.devel.redhat.com> References: <20080715222427.GA1170@nostromo.devel.redhat.com> Message-ID: <1216178143.3330.3.camel@localhost.localdomain> On Tue, 2008-07-15 at 18:24 -0400, Bill Nottingham wrote: > > Right now, there's MALLOC_CHECK_ and MALLOC_PERTURB. There > should be more. Is there anything in the various desktops > that is appropriate? > In Glib, there is G_SLICE=debug-blocks which performs extra sanity checks in the gslice allocator. From peter at thecodergeek.com Wed Jul 16 05:13:27 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 15 Jul 2008 22:13:27 -0700 Subject: Heads-Up: Deluge 1.0 RCs (BIG FAT WARNING) Message-ID: <1216185207.8878.22.camel@tuxhugs> Hi, all. I've just pushed Deluge 1.0.0 RC2 (0.9.02) into Rawhide. Formerly 0.6.x, this is an almost-complete rewrite from the 0.5.x series and therefore comes with several caveats/warnings. Firstly, it is NOT BACKWARD-COMPATIBLE with the old 0.5 series' plugins and configurations. Any current state and torrents will not be loaded. I have included in the package documentation a script from upstream trunk (state_upgrade.py) which will convert your state file (and currently running torrents) to the new format if used while Deluge is running. However, any plugins found will fail to function until they are rewritten for 1.0; and most preferences such as share ratios/etc will need to be reset manually. Secondly, the program has been split into a "daemon" and "frontend" portion (with current frontends being GTK+ and WebUI). Deluge will default to a so-called "Classic Mode" which hides the daemon-specific functionality in the GTK+ frontend; but this can be changed in the preferences ("Interface"). Thirdly, the blocklist plugin is no longer being shipped. (The Debian/Ubuntu packaging will follow suit.) At upstream's behest, this plugin is horribly, entirely, and completely broken. It will likely not even be included in future RCs/releases until the rewrite is complete. Lastly, one of my hopes with this release is that we can finally resume shipping Deluge built against a system copy of rb_libtorrent. I don't yet know how feasible this will be though, since I have recently spoken with upstream about it and they say that Deluge requires a pretty recent (usually SVN trunk) release of rb_libtorrent. For more information and details, please see the upstream changelog [1], FAQ [2], and RC2 announcement [3]. [1] http://svn.deluge-torrent.org/trunk/ChangeLog [2] http://dev.deluge-torrent.org/wiki/Faq [3] http://forum.deluge-torrent.org/viewtopic.php?f=8&t=7535 As usual, please don't hesitate to respond with any questions/comments/concerns. Thanks! -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 ae at op5.se Wed Jul 16 06:01:03 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 16 Jul 2008 08:01:03 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216137680.6039.61.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdo main> Message-ID: <487D8E9F.9000100@op5.se> Dan Williams wrote: > On Sat, 2008-07-12 at 17:49 -0700, Arjan van de Ven wrote: >> On Sat, 12 Jul 2008 20:10:51 -0400 >>> Presumably one could replicate this as needed. However, there is the >>> question of whether or not it's needed. Remember that the concept >>> using an upstream tarball as the canonical source version that we >>> represent to the world that we are using is nothing more than a >>> policy decision. Nothing in the GPL or anything else said we had to >>> do that, it was just what we *chose* to do (long, long ago, in a >>> galaxy far, far away). >> one thing to keep in mind... as comparison, what you don't want is what >> Ubuntu is doing with their kernel (clone Linus and then just edit the >> source tree); it's just one big nightmare (as you can imagine). Keeping >> upstream source and local patches separate is a clear winner (anyone >> who has worked on the alternative will agree with me). >> If those upstream sources are a tarbal, or a tagged commit... is a lot >> less relevant. > > Yeah, there is actually a benefit to tarball+patches approach we take > right now; and that benefit is that it's extremely easy to see just what > we've done to the upstream package, Easier than, oh, say "git log -p --reverse fedora..upstream" ? > and it's usually really easy to > extract those changes and push them upstream. You don't want a > mega-diff that includes 20 specific patches. > Who's talking about mega-diffs? You can get each diff individually with any sane scm (and with quite a few of the insane ones as well). > One problem working directly on exploded source trees is that you as a > developer have to be much more disciplined to make small, targeted > commits that are easily able to go upstream, otherwise you do end up > with a huge diffmess that you simply can't upstream easily. > That's really no difference at all to what needs to be done now. Each patch has to be kept and generated separately. Using a tool for it only means you have a much easier way of moving that patch-set around and automagically finding already applied patches. > And that's where we should always be working: upstream. > So work with the tools they have then. I manage a few projects in git, and I'd much prefer to get patches sent to me via the git tools than someone using diff on two exploded source-trees. I'd *love* to get pull-requests, since I won't have to bring any sourcecode or patch outside the scm at all that way. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Wed Jul 16 07:07:25 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 16 Jul 2008 09:07:25 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> Message-ID: <487D9E2D.8050902@op5.se> Kevin Kofler wrote: > Andreas Ericsson op5.se> writes: >>> * make releases without tags: For example, the weekly trunk snapshots of >>> KDE don't get tags, nor do the extragear tarball releases. >> I'm not sure if you saw my email regarding the requirements on the SCM for it >> to be useful in the scenario Doug Ledford proposes, but right at the top of >> the list comes the ability to uniquely name one particular commit. If you >> have that, you don't need tags. > > The problem with commit IDs is that they're a lot less readable and intuitive > than tags. > True that. I thought the ID's were going to be used by computers though, and packages would still have version numbers. >> It would be extremely poor project policy to move a tag after it's made >> public > > Are you trying to imply that KDE has "extremely poor project policy"? If a the code corresponding to a particular version can be changed once released publicly, then yes. > I think > it only makes sense to do respins that way. A release isn't always perfect on > the first try. > I don't. I think a much saner approach would be to set a new tag when a new release is done. When something is tagged as "v4.0.0" (or whatever), people expect that version to damn well have the same code as it did last week. Otherwise you can have kde-4.0.0.tar.gz with one particular bug and kde-4.0.0.tar.gz next week where that bug is missing (but something else is broken). Calling the first package kde-4.0.0rc1.tar.gz would make sense though, or calling the second one kde-4.0.1 would work just as well. Giving several different versions of the same package the same version number is just broken. It'd be like amazon and google sharing the same ip. >> For centralized scms, moving tags doesn't matter in the slightest, since >> they can't name a commit uniquely anyway. > > That's not true, a SVN commit is uniquely named by the revision number. If you have a history looking like this: A--B--C--D \ E Both E and D have the same revision number. As such, revision numbers are not unique. > And in > fact, being centralized allows SVN to actually use totally-ordered numbers, not > random IDs coming from the checksum of something (which are bound to break the > day you run into a collision, by the way). > True that. Current maths suggests that with the current commit-tempo to the kernel (10487 commits between 2.6.25 and 2.6.26, most of them merges), we'll run into the first SHA1 collision a mere 16 billion years after the calculated end of the universe. I can see how that's a real problem.... > The best way to reproducibly name a tag in SVN would be to use the tag name > (which would be part of the URL) So what happens when the repository moves? Then you no longer have the same url and you need to trust the new repository location to have done an exact clone of the source repository. Since there are no commit checksums, you can't know that the version you get from the new repo is the same as you would have gotten from the old one. Oh, and the original repo can get modified (rewritten; it's not supposed to happen, but it happens). Since there are no checksums, you're left flying blind and just hoping. > _and_ the revision number. Tags in SVN are > just directories, so you can use the directory at the given revision and you'll > get the exact thing you originally checked out. > >> Me, being mostly a user who also happens to be a programmer, would love >> to have an easy way to be able to get a clone of , >> find the sources corresponding exactly to my version of the package and >> then fix whatever issues I have with it. Even if it was just me willing >> to do that (which I highly doubt), you'd have a net gain of one extra >> spare-time developer. You can't possibly argue that making it easier for >> casual developers to get involved is a bad thing. > > With the current system, you just have to check out the package and run "make" > in one of the branches to get all source files (usually just a tarball) > downloaded from the lookaside cache. Extract the tarball and you have your > sources. The patches aren't applied there, but that's by design. Patches are > supposed to be independent, so (with some exceptions, e.g. the kernel which > often includes series of interdependent patches automatically generated from > some git repository) we develop each patch against the _original_ sources, then > only when actually building the package we apply them all. > That's nice and allowing for maximum flexibility, but what I'm guessing 99% of the users want is to be able to easily get the source code they're running so they can start fiddling with it. > My workflow when I develop a patch for KDE is: > 1. I extract the tarball (e.g. kdebase-workspace-4.0.98.tar.bz2). > 2. This creates a directory (e.g. kdebase-workspace-4.0.98). > 3. I copy this directory, appending the name of the patch I intend to write > (e.g. kdebase-workspace-4.0.98-consolekit-kdm). > 4. I make my changes in that directory (e.g. > kdebase-workspace-4.0.98-consolekit-kdm). > 5. I diff the original vs. the patched directory (e.g. diff -Nur > kdebase-workspace-4.0.98 kdebase-workspace-4.0.98-consolekit-kdm >> kdebase-workspace-4.0.98-consolekit-kdm.patch). > 6. I copy the patch to the package branch. > 7. I cvs add it to the repository. > 8. I apply it in the specfile (2 lines, e.g. Patch1: > kdebase-workspace-4.0.98-consolekit-kdm.patch in the header > and %patch1 -p1 -b .consolekit-kdm in the %prep section). > 9. I commit. > 10. I run make tag. > 11. I run make build BUILD_FLAGS=--nowait. > 12. Koji sends me the results. > 13. If the build failed, I: > * repeat steps 4, 5, 6 and 9 > * run make force-tag > * resubmit the failed build through the Koji web interface > as often as needed until it builds. > You poor bastard. > I know this sounds overly complicated, but keep in mind that most of these > steps are just a couple of mouse clicks or one line in a terminal, I > intentionally detailed them so a beginner can understand what's going on. I'm > not sure a SCM with fully-exploded sources would really make that easier. > My workflow when developing a feature for our own projects is: 1. git checkout -b 2. edit, edit, edit 3. commit 4. goto 2 as necessary 5. git checkout && git merge feature 6. git push 7. magic makes the package build and install on one machine of every supported arch, sending me an email of the results If I do it for some project where I'm not upstream, I do: repeat 1-4 5. git submit master..feature In short, I deal with a single tool to handle everything regarding development. If I need patches kept around for a while, I keep them as changesets in the scm and regenerate them when needed. If I miss the merge-window for an upstream feature-release, I can simply let the tool move my patches to where they belong when the next merge- window is about to open, rather than having to maintain separate patch-files which I need to handle manually, which is tedious, timeconsuming and error-prone. Like Doug says, maintaining up to 5 or so patches that are all sort of small (say, less than 2000 lines of diff) is manageable, but it's not as easy as it could be. I gave up on it completely when I had 35 rather small patches to juggle and had to re-apply them for every new version we released of an upstream project. Earlier I used to spend 1-2 full days forward-porting those patches. Now I do it in 0.1-15 minutes, depending on conflicts. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From kevin.kofler at chello.at Wed Jul 16 08:05:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 16 Jul 2008 08:05:57 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: Andreas Ericsson op5.se> writes: > > Are you trying to imply that KDE has "extremely poor project policy"? > > If a the code corresponding to a particular version can be changed once > released publicly, then yes. What's your definition of "publicly"? KDE's definition of a public release is when the tarballs are synced to official KDE mirrors. But we packagers get access to the tarballs a few days earlier, and of course the releases are tagged in SVN before the first tarballs are produced. Any respins happen in the time period when the tarballs are available to us packagers, but not the general public (in principle... of course with packagers working in public SCMs like our CVS, source and binary packages tend to leak out early, but that's another can of worms). So as far as KDE is concerned, the versions are not "released publicly" when the changes happen, but as they _are_ released to us (packagers), we have to be able to handle the possibility of a respin. > Otherwise you can have kde-4.0.0.tar.gz with one particular bug and > kde-4.0.0.tar.gz next week where that bug is missing (but something > else is broken). In KDE's case, you won't get the old tarball, at least not from KDE's mirrors. As for packages, they can already contain patches, so if 4.0.0-1 and 4.0.0-2 differ by a patch or a respun tarball doesn't make that much a difference in practice. That said, there are other upstreams (usually small projects) which respin tarballs even after they were uploaded, hoping nobody noticed the broken version. ;-) > Calling the first package kde-4.0.0rc1.tar.gz would make sense though, Except there was actually an RC1, and it went through the same "prerelease to packagers, respin, release" process. > If you have a history looking like this: > > A--B--C--D > \ > E You can't have such a history in a centralized SCM. You can have a branch off C, but that means a different branch (= URL in SVN's case, where branches are just directories) where C is branched (= copied in SVN) to. At a given SVN URL, you only see A-B-C-D or A-B-C-E as the history. That's kinda the definition of "centralized". Therefore, URL+revision uniquely identifies a SVN fileset. In addition, SVN gives out unique numbers throughout the entire repository, so the actual commits for D and E will have different commit IDs. The IDs are totally ordered by the time they were committed to the central repository, which also implies that the relevant IDs for a branch are totally ordered. For example, if you specify the branch as the URL and any revision between C and D, you'll get the same files as if you specify the revision number for C. > True that. Current maths suggests that with the current commit-tempo to the > kernel (10487 commits between 2.6.25 and 2.6.26, most of them merges), we'll > run into the first SHA1 collision a mere 16 billion years after the > calculated end of the universe. I can see how that's a real problem.... All this is probabilistic, so nothing guarantees we won't run into a collision today, as unlikely as it is. I consider this a major design flaw in the concept of distributed SCMs. Kevin Kofler From drago01 at gmail.com Wed Jul 16 08:19:05 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jul 2008 10:19:05 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: <5cr69uoed6.fsf@allele2.eebweb.arizona.edu> References: <1216091968.9625.13.camel@tuxhugs> <5cr69uoed6.fsf@allele2.eebweb.arizona.edu> Message-ID: On Wed, Jul 16, 2008 at 2:35 AM, Alex Lancaster wrote: >>>>>> "d" == drago01 writes: > > [...] > > d> I tryed to do a scratch build of llinkage 0.2.0 [1] against the new > d> rb_libtorrent but it fails.[2] Which is odd (complaining about > d> cannot find 0.13) while the root.log shows that it is indeed > d> installed. [3] > > d> 1: http://koji.fedoraproject.org/koji/taskinfo?taskID=718436 2: > d> http://koji.fedoraproject.org/koji/getfile?taskID=718436&name=build.log > d> 3: > d> http://koji.fedoraproject.org/koji/getfile?taskID=718455&name=root.log > > Looking at that build.log it looks like it's failing because of a > patch that fails, not an error from configure or make: > > + /bin/chmod -Rf a+rX,u+w,g-w,o-w . > + echo 'Patch #0 (linkage-0.1.4-plugindir.patch):' > Patch #0 (linkage-0.1.4-plugindir.patch): > + /bin/cat /builddir/build/SOURCES/linkage-0.1.4-plugindir.patch > + /usr/bin/patch -s -p1 -b --suffix .plugindir --fuzz=0 > 1 out of 1 hunk FAILED -- saving rejects to file configure.rej > error: Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) Sorry wrong log here is the one: http://koji.fedoraproject.org/koji/taskinfo?taskID=718465 http://koji.fedoraproject.org/koji/getfile?taskID=718465&name=build.log From markmc at redhat.com Wed Jul 16 08:32:43 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 16 Jul 2008 09:32:43 +0100 Subject: Using git to maintain patches [was Re: Heads-up: brand new RPM version about to hit rawhide] In-Reply-To: <1216139066.6039.81.camel@localhost.localdomain> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> Message-ID: <1216197163.8258.35.camel@muff> On Tue, 2008-07-15 at 12:24 -0400, Dan Williams wrote: > On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: > > > Yeah, there is actually a benefit to tarball+patches approach we take > > > right now; and that benefit is that it's extremely easy to see just what > > > we've done to the upstream package, and it's usually really easy to > > > extract those changes and push them upstream. You don't want a > > > mega-diff that includes 20 specific patches. > > > > I know of at least one example currently in our cvs where we went from > > a set of separate small patch files to one encompassing patch file. I > > think it was a diff from git. If we move to more advanced vcs are we > > going to have a harder time keeping patches separated? Or is it just a > > matter of education on how not to reach for the easy to produce mega > > patch shortcut? > > That's the problem here: if we move to git (or any DVCS really), as a > packager you would have to be _much_ more aware of how to use the VCS to > achieve the same separation of patches and upstream source. That is true; and there's definitely a steep learning curve there. I'm not sure the learning curve will always seem incredibly steep - as we figure out the best way of doing this stuff and more people become comfortable with it, I'm sure that it would become just as easy a methodology to pick up as tarball+patches ... which isn't exactly a walk in the park the first time you do it, either, if you think back. > You'd need > to do something like topic branches for each patch and then merge each > topic branch into a "release" branch to ensure that each of the patches > was cleanly separated from the main source. Not at all - "git-rebase -i" allows you to very easily maintain a set of git commits as if they were individual patches. e.g. I use this git tree: http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git to maintain the set of patches for kernel-xen[1]. The only tricky part right now is that the that stock Fedora kernel isn't maintained in git, so I first import all those patches into git as a single commit. The point is, that if you maintained the kernel patches in git, the latest kernel was based on v2.6.26-rc8 and v2.6.26-rc9 was released you would just do: $> git-rebase v2.6.26-rc9 and any patches that had gone upstream would automatically be dropped, you'd have a nice interface for resolving conflicts etc. If you then wanted to drop, re-order, edit, split up or merge patches you would just do: $> git-rebase -i v2.6.26-rc9 Truly, after doing this for a while, I wouldn't dream of going back to tarball+patches for maintaining a package with a git upstream/mirror. Cheers, Mark. [1] - touch wood, this kernel is going away soon ... at last and forever From drago01 at gmail.com Wed Jul 16 10:21:12 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jul 2008 12:21:12 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: References: <1216091968.9625.13.camel@tuxhugs> <5cr69uoed6.fsf@allele2.eebweb.arizona.edu> Message-ID: On Wed, Jul 16, 2008 at 10:19 AM, drago01 wrote: > On Wed, Jul 16, 2008 at 2:35 AM, Alex Lancaster > wrote: >>>>>>> "d" == drago01 writes: >> >> [...] >> >> d> I tryed to do a scratch build of llinkage 0.2.0 [1] against the new >> d> rb_libtorrent but it fails.[2] Which is odd (complaining about >> d> cannot find 0.13) while the root.log shows that it is indeed >> d> installed. [3] >> >> d> 1: http://koji.fedoraproject.org/koji/taskinfo?taskID=718436 2: >> d> http://koji.fedoraproject.org/koji/getfile?taskID=718436&name=build.log >> d> 3: >> d> http://koji.fedoraproject.org/koji/getfile?taskID=718455&name=root.log >> >> Looking at that build.log it looks like it's failing because of a >> patch that fails, not an error from configure or make: >> >> + /bin/chmod -Rf a+rX,u+w,g-w,o-w . >> + echo 'Patch #0 (linkage-0.1.4-plugindir.patch):' >> Patch #0 (linkage-0.1.4-plugindir.patch): >> + /bin/cat /builddir/build/SOURCES/linkage-0.1.4-plugindir.patch >> + /usr/bin/patch -s -p1 -b --suffix .plugindir --fuzz=0 >> 1 out of 1 hunk FAILED -- saving rejects to file configure.rej >> error: Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.8c3LMo (%prep) > > Sorry wrong log here is the one: > http://koji.fedoraproject.org/koji/taskinfo?taskID=718465 > http://koji.fedoraproject.org/koji/getfile?taskID=718465&name=build.log > OK, seems like the name changed to libtorrent-rasterbar in the pkg-config file. From ae at op5.se Wed Jul 16 10:28:59 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 16 Jul 2008 12:28:59 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: <487DCD6B.7040800@op5.se> Kevin Kofler wrote: > Andreas Ericsson op5.se> writes: >>> Are you trying to imply that KDE has "extremely poor project policy"? >> If a the code corresponding to a particular version can be changed once >> released publicly, then yes. > > What's your definition of "publicly"? KDE's definition of a public release is > when the tarballs are synced to official KDE mirrors. But we packagers get > access to the tarballs a few days earlier, and of course the releases are > tagged in SVN before the first tarballs are produced. Any respins happen in the > time period when the tarballs are available to us packagers, but not the > general public (in principle... of course with packagers working in public SCMs > like our CVS, source and binary packages tend to leak out early, but that's > another can of worms). So as far as KDE is concerned, the versions are > not "released publicly" when the changes happen, but as they _are_ released to > us (packagers), we have to be able to handle the possibility of a respin. > I still think it's slightly crazy. The respin must happen due to bug-reports, so people will be reporting the same version but actually be talking about different code. That's a bit off-topic though, so let's just agree to disagree and leave it at that, shall we? > >> If you have a history looking like this: >> >> A--B--C--D >> \ >> E > > You can't have such a history in a centralized SCM. You can have a branch off > C, but that means a different branch (= URL in SVN's case, where branches are > just directories) where C is branched (= copied in SVN) to. At a given SVN URL, > you only see A-B-C-D or A-B-C-E as the history. That's kinda the definition > of "centralized". Therefore, URL+revision uniquely identifies a SVN fileset. > But the URL is not immutable. You wouldn't believe the number of people that have come to the git-list to complain about git-svn not properly importing svn repositories simply because the layout has changed since the repository was first started, or because it was moved one directory up, or some branch was deleted after having been used to tag something from. SVN is fragile and has no way of canonically naming a commit. URL+Rev doesn't cut it, since URL can change (and so can rev, but only in insane cases). > >> True that. Current maths suggests that with the current commit-tempo to the >> kernel (10487 commits between 2.6.25 and 2.6.26, most of them merges), we'll >> run into the first SHA1 collision a mere 16 billion years after the >> calculated end of the universe. I can see how that's a real problem.... > > All this is probabilistic, so nothing guarantees we won't run into a collision > today, as unlikely as it is. I consider this a major design flaw in the concept > of distributed SCMs. > The odds of accidentally hitting a collision is 1 to 1461501637330902918203684832716283019655932542976 with SHA1. Oh, and here's a neat thing; If you actually find such a collision, nothing bad happens to the data. In short; There's a much higher chance that every piece of hardware containing a full copy of the SVN repository stop working at the same time than there is of accidentally stumbling upon a collision with SHA1. I'd go so far as to say it's not even odd for an SVN repo to get completely wiped off the face of the earth, since sloppy backup routines make it possible for it to happen in something so mundane and simple as a building burning down. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nphilipp at redhat.com Wed Jul 16 10:35:40 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 16 Jul 2008 12:35:40 +0200 Subject: process wakeups In-Reply-To: <487CB6AD.6000100@redhat.com> References: <487BCBE4.9050107@redhat.com> <20080715110658.GA2591@srcf.ucam.org> <487CB6AD.6000100@redhat.com> Message-ID: <1216204540.13063.6.camel@gibraltar.str.redhat.com> On Tue, 2008-07-15 at 07:39 -0700, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matthew Garrett wrote: > > There are certain situations where polling is inevitable (such as > > querying hardware for battery status or signal strength, pulling mail, > > that kind of thing). [...] > As for mail pulling: sure. But the frequency should be measured in > minutes and not in micro-seconds. IMAP IDLE (the IMAP server telling connected clients when there is new mail) should be able to fix that: http://en.wikipedia.org/wiki/IMAP_IDLE We just have to ensure that our clients and servers support this correctly (and that it is enabled by default). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From billcrawford1970 at gmail.com Wed Jul 16 10:42:04 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 16 Jul 2008 11:42:04 +0100 Subject: process wakeups In-Reply-To: <200807151128.59866.sgrubb@redhat.com> References: <487BCBE4.9050107@redhat.com> <200807150939.21479.sgrubb@redhat.com> <544eb990807150815x1e394f81q7388478bcae12061@mail.gmail.com> <200807151128.59866.sgrubb@redhat.com> Message-ID: <544eb990807160342q45457ca8i5a6f198df4aeaa8@mail.gmail.com> 2008/7/15 Steve Grubb : ... > ...this is after about 5 seconds. This thread just never gets quiet and is > constantly churning. My system is idle too with nothing being added or > deleted or read from the database. ... > Those are the 2 noisy threads. Ah, that does fit with what I see here, then. I took your "that just never stop" to mean you were seeing significant CPU usage. It's not good, certainly, but I guess it's designed on the assumption that you're using it, ... so doesn't make quite the extraordinary effort to avoid these wakeups that it otherwise might. I presume that the timeout could be increased greatly when there's no activity to monitor; but I have no knowledge at all of the mysql code, so I won't claim it would be easy :o) From drago01 at gmail.com Wed Jul 16 11:36:10 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jul 2008 13:36:10 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: <1216091968.9625.13.camel@tuxhugs> References: <1216091968.9625.13.camel@tuxhugs> Message-ID: 2008/7/15 Peter Gordon : > Hi, all. > > Just an FYI: I've bumped rb_libtorrent to 0.13.1 in Rawhide, which > changes the soname (libtorrent-0.12.1.so -->libtorrent-rasterbar.so.0) > > Aside from the large amount of bug-fixes, packaging recent versions of > rb_libtorrent will make it much more feasible to use a system copy with > Deluge 1.0 soon (which is just hitting its RCs, and currently uses its > own internal copy synced to upstream trunk every so often). > > According to repoquery, the only thing that currently depends on this > library is linkage (a GTK+ BitTorrent client); and that - according to > its upstream authors - should work just fine with this updated > rb_libtorrent once an update to linkage-0.2.0 is pushed. > > Howevever, I think that linkage-0.2.0 still needs some D-BUS C++ love, > so it'll probably remain broken until that happens. (If needed, we can > maintain a separate compat package for rb_libtorrent-0.12.x; but I hope > that it will not be necessary.) Submitted dbus-c++ for review (its needed for the new linkage). https://bugzilla.redhat.com/show_bug.cgi?id=455575 From lesmikesell at gmail.com Wed Jul 16 12:38:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 16 Jul 2008 07:38:53 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487DCD6B.7040800@op5.se> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> <487DCD6B.7040800@op5.se> Message-ID: <487DEBDD.20409@gmail.com> Andreas Ericsson wrote: > > But the URL is not immutable. You wouldn't believe the number of people > that > have come to the git-list to complain about git-svn not properly importing > svn repositories simply because the layout has changed since the repository > was first started, or because it was moved one directory up, or some branch > was deleted after having been used to tag something from. SVN is fragile > and > has no way of canonically naming a commit. URL+Rev doesn't cut it, since > URL can change (and so can rev, but only in insane cases). You can uniquely reference specific versions of deleted/reused tags in svn using what they call 'peg revision' syntax. I have no idea if git-svn understands this concept or not, but I suspect that's the real issue here. Regardless, I agree that it's a bad idea to ever reuse a tag that has been released. It's not like there is a shortage of available revision numbers - but it is sometimes handy to float well known tags in the repository for scripting purposed like everyone used to do with CVS. -- Les Mikesell lesmikesell at gmail.com From billcrawford1970 at gmail.com Wed Jul 16 12:57:05 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 16 Jul 2008 13:57:05 +0100 Subject: No answer to easy bug policy In-Reply-To: <604aa7910807151245s6affa794h12e0a87db27dc0e5@mail.gmail.com> References: <20080712000447.GB2610@free.fr> <1215850370.24851.29.camel@hughsie-work> <1216147875.16175.123.camel@keyop> <604aa7910807151219q20a21deey334fd68e55f7e72f@mail.gmail.com> <1216150941.3631.232.camel@localhost.localdomain> <604aa7910807151245s6affa794h12e0a87db27dc0e5@mail.gmail.com> Message-ID: <544eb990807160557q6d2e77aqf4a5576bb4ab976e@mail.gmail.com> 2008/7/15 Jeff Spaleta : > 2008/7/15 Jesse Keating : >> They belong in the SIGLess SIG > > Now I want to rename SIG's as HOME's Move SIG ... for great justice? > -jef From kevin.kofler at chello.at Wed Jul 16 13:07:52 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 16 Jul 2008 13:07:52 +0000 (UTC) Subject: Heads-up: brand new RPM version about to hit rawhide References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: Andreas Ericsson op5.se> writes: > But the URL is not immutable. You wouldn't believe the number of people that > have come to the git-list to complain about git-svn not properly importing > svn repositories simply because the layout has changed since the repository > was first started, or because it was moved one directory up, or some branch > was deleted after having been used to tag something from. SVN is fragile and > has no way of canonically naming a commit. URL+Rev doesn't cut it, since > URL can change (and so can rev, but only in insane cases). But the old revision will still have the code at the given URL, it will be moved or deleted only in the new revision. The only way the URL of a given revision can change is if the entire repository moves to somewhere else. Your mistake there is that you're treating the URL as the primary key, when actually the order to lookup something is: 1. repository 2. revision (only valid in the context of the repository) 3. directory within the repository (only valid for a given revision) because SVN versions entire repositories with revision IDs, not directories or branches. (One thing which confuses this issue is that normally 1 and 3 are given in a single URL and 2 separately. SVN will do the right thing and separate the URL into repository and directory.) Kevin Kofler From lesmikesell at gmail.com Wed Jul 16 13:13:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 16 Jul 2008 08:13:27 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: <487DF3F7.2020204@gmail.com> Kevin Kofler wrote: > > What's your definition of "publicly"? KDE's definition of a public release is > when the tarballs are synced to official KDE mirrors. But we packagers get > access to the tarballs a few days earlier, and of course the releases are > tagged in SVN before the first tarballs are produced. Any respins happen in the > time period when the tarballs are available to us packagers, but not the > general public (in principle... Svn doesn't force different handling for trunk/branches/tags but the usual convention is that you mostly expect to be working on a changing head revision in the trunk/branches trees and normally wouldn't specify a revision number, but the copies in tags (by convention only) never have additional commits and exist only to give an arbitrary name to a frozen version without having to deal with the repository revision number. If you are committing to something called a tag in svn, it is at best unexpected behavior. A more typical process would be to have created a pre-release branch for the final work and to make tag copies with unique names for any snapshots that you want to be able to reproduce later, including your final release. -- Les Mikesell lesmikesell at gmail.com From nphilipp at redhat.com Wed Jul 16 14:40:23 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 16 Jul 2008 16:40:23 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216047180.3687.361.camel@firewall.xsintricity.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> <1216046184.8308.26.camel@gibraltar.str.redhat.com> <1216047180.3687.361.camel@firewall.xsintricity.com> Message-ID: <1216219223.13063.28.camel@gibraltar.str.redhat.com> On Mon, 2008-07-14 at 10:53 -0400, Doug Ledford wrote: > On Mon, 2008-07-14 at 16:36 +0200, Nils Philippsen wrote: > > On Mon, 2008-07-14 at 10:20 -0400, Doug Ledford wrote: > > > On Mon, 2008-07-14 at 09:21 +0200, Nils Philippsen wrote: > > > > On Sat, 2008-07-12 at 20:12 -0400, Doug Ledford wrote: > > > > > On Sat, 2008-07-12 at 16:09 -0400, Jesse Keating wrote: > > > > [...] > > > > > > The problem really lies with whether or not this would satisfy, as a > > > > > > written offer, the requirements under which we distribute or ask our > > > > > > ambassadors to distribute our binaries. > > > > > > > > > > OK, well regardless, if this meets the requirements, then certainly an > > > > > immutably tagged exploded SCM would too (for far less space requirements > > > > > > > > Leaving aside discussing the merits of it, you don't need to use > > > > immutable tags (pkg-1_0-1_fcX) as you can just record the exact revision > > > > from which you built the package (which should already be immutable). > > > > > > You are correct on that point, but the immutable tag is generally more > > > readable as part of the output of rpm -i . > > > > I don't understand why that thing should be (human-)readable, it's just > > a pointer to the exact state of things which was used to build a binary > > package. > > It doesn't have to be, but it might be nice. Hmm, but "it might be nice" isn't a sufficient reason for me to enforce unchangeable tags -- "it has built successfully" would be, though. Or rather, let the successful build trigger the tagging of the built revision. > I would find it far easier > to parse the tag in my head than the sha. That's one complaint I have > with git, I rather wish it would hide the shas instead of putting them > front and center. But, that's just personal preference. > > > Correlating this to a human-readable version/release needs to be done of > > course so that these make sense. I think it should be done in a way > > where the resulting SRPMs still contain what amounts to the upstream > > tarball plus patch(es) so that you can easily pass around self-contained > > source packages where it is clear what is upstream and what > > Fedora/RHEL/... added. > > > > Note that this doesn't necessarily mean that a developer can't work in > > an exploded tree -- I think the patches could be generated from an > > exploded tree. To ensure that this really works (and the packages are > > self-contained), the build system would probably have to use these > > source packages for building and not work directly from the exploded > > tree. > > We do this internally now for the RHEL4 and RHEL5 kernels. The kernel > maintainer has a git repo, we work from that repo, we send patches to > the maintainer internally, they commit to the repo, then come build > time, they spit out a tarball and a set of patches to import into CVS > and then the build happens from CVS. It's cumbersome, and it introduces > a few problems in that if you make a patch that touches file that are > part of the git repo itself, but not part of what you want exported to > the CVS checkins (such as patches to the scripts that generate a tarball > and patches from the git repo), then those have to be filtered out > before you check things into CVS etc. Heh, but these parts should have been put elsewhere in the first place, don't you think ;-)? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Wed Jul 16 14:49:39 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 16 Jul 2008 16:49:39 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <604aa7910807140928y4d387bb6u7ea467dece47e7c2@mail.gmail.com> References: <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> <487A3DD0.3040702@gmail.com> <604aa7910807140928y4d387bb6u7ea467dece47e7c2@mail.gmail.com> Message-ID: <1216219779.13063.37.camel@gibraltar.str.redhat.com> On Mon, 2008-07-14 at 08:28 -0800, Jeff Spaleta wrote: > On Sun, Jul 13, 2008 at 9:39 AM, Les Mikesell wrote: > > As long as the old method continues to work, what's the problem with adding > > a way to improve it going forward? > > > Yes, clearly there will need to keep something similar to the "old > method" around for dealing with tarball releases while this new > process moves forward. If we make the change, we'll have to support > both ways of doing it, and track the update on the new process on a > package by package basis. > > My largest concern continues to be source distribution. If we have to > support both models of packaging source control then I'm not sure what > our source distribution ends up looking like. Is it a mix of exploded > branches and srpms? IMO it should be SRPMS that contain a set of individual patches, just as what we have right now. > I'd also need to get an idea of what our local patchsets would look > like in the new cloned vcs packaging. I've had people tell me that > they very much prefer the style of different patch files as shipped in > our srpm delineated based on purpose and not necessarily a single > merged patch file that includes multiple changes. We are starting to > see the single patch files which are multiple patches merged into a > single patch and I've had someone complain specifically about it > being more difficult to understand. It should be possible (see Doug's comments about how kernel does it this way) to generate individual patches on top of a pristine tarball out of say a git repository. For packages that opted for this scheme, they could have their exploded repository which e.g. contained individual branches for each logical patch (stable and experimental ones), where you could cherry-pick the desired patches into a package release branch and have some tools that generated the patch files out of that (and possibly import it into the dist VCS which contained spec files and patches as usual). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jkeating at redhat.com Wed Jul 16 14:53:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jul 2008 10:53:38 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216219223.13063.28.camel@gibraltar.str.redhat.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> <1216046184.8308.26.camel@gibraltar.str.redhat.com> <1216047180.3687.361.camel@firewall.xsintricity.com> <1216219223.13063.28.camel@gibraltar.str.redhat.com> Message-ID: <1216220018.4854.0.camel@localhost.localdomain> On Wed, 2008-07-16 at 16:40 +0200, Nils Philippsen wrote: > > It doesn't have to be, but it might be nice. > > Hmm, but "it might be nice" isn't a sufficient reason for me to enforce > unchangeable tags -- "it has built successfully" would be, though. Or > rather, let the successful build trigger the tagging of the built > revision. That's why you have something other than the human apply the immutable tag. The buildsystem would build from the sum that wouldn't ever change. Once a build is actually successful, the n-v-r of that build is immutable tagged to the matching sum by some bot running in the build infrastructure. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 lesmikesell at gmail.com Wed Jul 16 15:01:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 16 Jul 2008 10:01:10 -0500 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: <487E0D36.4080008@gmail.com> Kevin Kofler wrote: > >> But the URL is not immutable. You wouldn't believe the number of people that >> have come to the git-list to complain about git-svn not properly importing >> svn repositories simply because the layout has changed since the repository >> was first started, or because it was moved one directory up, or some branch >> was deleted after having been used to tag something from. SVN is fragile and >> has no way of canonically naming a commit. URL+Rev doesn't cut it, since >> URL can change (and so can rev, but only in insane cases). > > But the old revision will still have the code at the given URL, it will be > moved or deleted only in the new revision. The only way the URL of a given > revision can change is if the entire repository moves to somewhere else. Your > mistake there is that you're treating the URL as the primary key, when actually > the order to lookup something is: > 1. repository > 2. revision (only valid in the context of the repository) > 3. directory within the repository (only valid for a given revision) > because SVN versions entire repositories with revision IDs, not directories or > branches. > > (One thing which confuses this issue is that normally 1 and 3 are given in a > single URL and 2 separately. SVN will do the right thing and separate the URL > into repository and directory.) This is all correct, but... in subversion, by convention tags are used to create human-generated names for specific revisions and for that to work as expected (i.e. not needing the revision # along with the tag) you have to not do subsequent commits to that tag. Also it is permitted, but confusing, to delete a tag and recreate another with the same name but different contents. In this circumstance older tag copies are not actually removed from the repository but can only be referenced by specifying the associated repository revision number using peg reference syntax - and since you typically don't need to know the revision number when working with tags it may be difficult to find after the fact. -- Les Mikesell lesmikesell at gmail.com From a.badger at gmail.com Wed Jul 16 15:24:56 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Jul 2008 08:24:56 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487D9E2D.8050902@op5.se> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> Message-ID: <487E12C8.4050009@gmail.com> Andreas Ericsson wrote: > > In short, I deal with a single tool to handle everything regarding > development. Be careful of this advantage, though. It works when you deal with git exclusively for all your packages but for the majority of our packagers, we'll have to deal with a minimum of two vcses and methodologies. I deal with upstream who has svn, cvs, none, hg, and bzr. So if we did good exploded tree support I'd need to work with dist-cvs, hg, and bzr locally. (And saying: "Don't convert your other packages" is extremely hard for a variety of reasons: 1) Since you aren't the only maintainer, you may not have a choice. 2) When packages are passed back and forth between maintainers, you end up with a very disjoint history if you let them switch in and out of upstream VCS arbitrarily. ) -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 bnocera at redhat.com Wed Jul 16 15:37:20 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 16 Jul 2008 16:37:20 +0100 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710141001.GA10449@srcf.ucam.org> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> <20080710130230.GA29114@nostromo.devel.redhat.com> <20080710141001.GA10449@srcf.ucam.org> Message-ID: <1216222640.3080.168.camel@cookie.hadess.net> On Thu, 2008-07-10 at 15:10 +0100, Matthew Garrett wrote: > On Thu, Jul 10, 2008 at 09:02:30AM -0400, Bill Nottingham wrote: > > Maybe I'm unusual, but I rarely reboot my laptop cleanly. I'm not sure I'd > > want X weeks of logs to go away. > > > > Are there any sorts of mechanisms to do per-directory or per-file writeback > > caching, so that /var/log/ could be set to 'sync only every 15 minutes', > > or similar? > > Not that I can think of. Implementing it in rsyslog might be the easiest > option, though that would still leave apps that do their logging by > hand. Maybe we should just fix them all up to use syslog when possible. Maybe logrotate could copy the files from the tmpfs to disk on a semi-regular basis, rather than hack this into syslog directly? Would also mean that apps that have their own logging would work as expected as well. From a.badger at gmail.com Wed Jul 16 15:36:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Jul 2008 08:36:31 -0700 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487DCD6B.7040800@op5.se> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> <487DCD6B.7040800@op5.se> Message-ID: <487E157F.1080008@gmail.com> Andreas Ericsson wrote: > > But the URL is not immutable. You wouldn't believe the number of people > that > have come to the git-list to complain about git-svn not properly importing > svn repositories simply because the layout has changed since the repository > was first started, or because it was moved one directory up, or some branch > was deleted after having been used to tag something from. SVN is fragile > and > has no way of canonically naming a commit. URL+Rev doesn't cut it, since > URL can change (and so can rev, but only in insane cases). > That's a misunderstanding of SVN. The URL at a revision cannot change without filtering the repository (which you could do with any SCM if you understand the internal repository format). You're seeing URLs change between revisions. IE: revision 10 has file:///trunk/foo/README.txt revision 11 has file:///foo/trunk/README.txt -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 hughsient at gmail.com Wed Jul 16 15:42:42 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jul 2008 16:42:42 +0100 Subject: latency-policy call for review Message-ID: <1216222962.3204.54.camel@hughsie-work> Anyone want to review this package? It's designed to make it easy to set system latency power tunables. https://bugzilla.redhat.com/show_bug.cgi?id=455149 Once its in cvs, I'll be suggesting it's installed by default for Fedora 10. The output is something like this: [root at hughsie-work sys]# service latency-policy restart Setting best-effort system latency: 10000?s [ OK ] ? Enabling ALPM link powersave [ OK ] ? Enabling ASPM powersave [ OK ] ? Enabling ALSA powerdown [ OK ] ? Enabling ondemand governor [ OK ] ? Enabling WiFi poll powersave [ OK ] Admins can tweak the system latency and everything is auto calculated, or they can just force disable or enable of certain modes. The default policy provides substantial power savings. I'll post power numbers when the new 2.6.26 kernel is pushed into F9. More details are on my blog: http://blogs.gnome.org/hughsie/2008/07/01/latency-policy/ Thanks. Richard. From mzerqung at 0pointer.de Wed Jul 16 16:00:13 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 16 Jul 2008 18:00:13 +0200 Subject: process wakeups In-Reply-To: <487BCBE4.9050107@redhat.com> References: <487BCBE4.9050107@redhat.com> Message-ID: <20080716160013.GB27269@tango.0pointer.de> On Mon, 14.07.08 14:57, Ulrich Drepper (drepper at redhat.com) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the worst problems wrt energy savings we have today are all the > wakeups processes request. This is not just an issue for laptops, it > relevant everywhere. > > To see the size of the problem run the attached systemtap script. On my > laptop I see the following output (47 secs runtime): > > uid | poll select epoll itimer futex nanosle signal| process > 29799 |15941 7971 0 0 0 0 0| npviewer.bin > 29841 | 253 0 0 0 1531 0 0| thunderbird-bin > 3017 | 447 0 0 0 0 0 0| pulseaudio I would assume that this is just a followup by Flash/npviewer. Flash opens an audio stream and never closes it again during its entire runtime. While the audio stream is open. PA also needs to keep the audio device open. As long as the audio device is open we we will schedule audio via timers. The PA version from rawhide should not generate any wakeups when completely idle (i.e. no streams allocated or all streams that are allocated are properly paused) But of course, I might be mistaken, I didn't run this test, and pointing fingers to other people's software (flash) might just by an automatic reflex of me. Last time I checked PA didn't show up in powertop when idle, to say the least. I'll check again. > 2467 | 76 0 0 0 0 0 0| hald > 2471 | 8 0 0 0 0 0 0| hald-runner > 2620 | 58 0 0 0 0 0 0| NetworkManager > 13174 | 214 0 0 0 0 0 0| stapio > 3044 | 48 0 0 0 0 0 0| gnome-panel > 9115 | 16 0 0 0 0 0 0| nm-vpnc-service > 3112 | 32 0 0 0 0 0 0| gpk-update-icon > 3108 | 24 0 0 0 0 0 0| nm-applet > 3052 | 274 0 0 1 0 0 0| gnome-terminal > 3115 | 29 0 0 0 0 0 0| gnome-power-man > 3055 | 16 0 0 0 0 0 0| bluetooth-apple > 3093 | 16 0 0 0 0 0 0| krb5-auth-dialo > 2633 | 16 0 0 0 0 0 0| gdm-binary > 2724 | 16 0 0 0 0 0 0| gdm-simple-slav > 2630 | 16 0 0 0 0 0 0| nm-system-setti > 2470 | 16 0 0 0 0 0 0| console-kit-dae > 2385 | 16 0 0 0 0 0 0| avahi-daemon For avahi-daemon the wakeups are highly dependant on how much traffic actually goes on on the network and how long Avahi has already been running. I think the room for improvements here is rather minimal, I would assume, due to the way the protocol works: in mDNS traffic is scheduled based on time. Basically, every packet we send is implicitly delayed to increase the chance that we can merge multiple messages into a single packet. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From dledford at redhat.com Wed Jul 16 16:05:05 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 16 Jul 2008 12:05:05 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216219779.13063.37.camel@gibraltar.str.redhat.com> References: <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <1215932155.19719.13.camel@rousalka.okg> <487A3DD0.3040702@gmail.com> <604aa7910807140928y4d387bb6u7ea467dece47e7c2@mail.gmail.com> <1216219779.13063.37.camel@gibraltar.str.redhat.com> Message-ID: <1216224306.1891.164.camel@firewall.xsintricity.com> On Wed, 2008-07-16 at 16:49 +0200, Nils Philippsen wrote: > On Mon, 2008-07-14 at 08:28 -0800, Jeff Spaleta wrote: > > On Sun, Jul 13, 2008 at 9:39 AM, Les Mikesell wrote: > > > As long as the old method continues to work, what's the problem with adding > > > a way to improve it going forward? > > > > > > Yes, clearly there will need to keep something similar to the "old > > method" around for dealing with tarball releases while this new > > process moves forward. If we make the change, we'll have to support > > both ways of doing it, and track the update on the new process on a > > package by package basis. > > > > My largest concern continues to be source distribution. If we have to > > support both models of packaging source control then I'm not sure what > > our source distribution ends up looking like. Is it a mix of exploded > > branches and srpms? > > IMO it should be SRPMS that contain a set of individual patches, just as > what we have right now. Well, as has been brought up in this discussion, we really are going to have to end up supporting multiple formats because we really can't just go and say to everyone "Look, switch to this new vcs setup for Fedora" because there are those upstream projects where doing so would be counterproductive. In addition, I think Jeff's concerns (do you prefer Jeff or Jef, your mail full name is one, your sig is the other...) can be split into two distinctly different categories: the online fulfillment of the source requirements of the GPL versus physical media fulfillment of the source requirements of the GPL. So, I think the matrix of answers to Jeff's concerns could actually be drawn up as so: On-Line On-Media Fulfillment Fulfillment Traditional SRPM style package Current dist-cvs SRPM package + look aside cache Exploded source repo package On-line dist-* Tarball of SCMs (could be package [1] multiple types) with exploded src 1 - Yeah, yeah, I know I've been harping about wanting to end the life of tarballs, and I do, but as it turns out, for several technical reasons, an exploded src repo is best distributed in a single version format as an exported tarball from the scm. Included in the various reasons why this is true is the fact that an exploded source repo that has been tarballed up will in fact work with rpmbuild --rebuild or rpmbuild -t? with only one modification needed to rpmbuild. There is an inherent conflict between the exploded src repo and a tarball/srpm in that an exploded source repo has no need of the % setup macro, and without a %setup in %prep, it won't build as either an srpm or tarball. However, given the specific nature of the tarball special case code, it would actually be a rather simple change to have the tarball special case code do an implicit %setup of the tarball it was passed regardless of the presence of a %setup in %prep, and that would then make tarball exports of an otherwise building exploded source repo spec file work with 0 modifications necessary to the spec file, and that preserves the concept that the tagged version of code in the scm and the contents of the similarly versioned tarball are in fact byte for byte identical. And given that the current tarball special case code will break if you have anything *besides* %setup in %prep (well, anything that needs additional sources unless they exists outside the tarball already), and given that the %setup must reference the tarball we were passed (or all sorts of nasty surprises can happen), the implicit %setup change would not violate any principle of least surprise changes in the rpmbuild code. > > I'd also need to get an idea of what our local patchsets would look > > like in the new cloned vcs packaging. I've had people tell me that > > they very much prefer the style of different patch files as shipped in > > our srpm delineated based on purpose and not necessarily a single > > merged patch file that includes multiple changes. We are starting to > > see the single patch files which are multiple patches merged into a > > single patch and I've had someone complain specifically about it > > being more difficult to understand. > > It should be possible (see Doug's comments about how kernel does it this > way) to generate individual patches on top of a pristine tarball out of > say a git repository. For packages that opted for this scheme, they > could have their exploded repository which e.g. contained individual > branches for each logical patch (stable and experimental ones), where > you could cherry-pick the desired patches into a package release branch > and have some tools that generated the patch files out of that (and > possibly import it into the dist VCS which contained spec files and > patches as usual). The ultimate goal though would be to just educate people on using the scm tools. We *could* export a bunch of patches into a separate vcs, but that kind of defeats the purpose of trying to match our vcs to upstream and doing cloned repos and what not ;-) I don't really think it's that big of a problem though. Take for instance the issue that Jesse addressed in this thread where he thought the subtle finger pointing about doing a massive patch that was not so open source community friendly was probably directed at grub. Not withstanding the fact that the changes are basically a custom fork from a dead package, and therefore there aren't many people interested in going over them, he did mention that it was basically just a git export to cvs. Which goes back to my assertion from the paragraph above that if we aren't exporting from one scm to another, this sort of thing doesn't happen (at least not as part of the export process anyway). And the whole point would be non-existent if our grub repo were based on git so we could just clone pjones' changes instead of exporting them. So, I'll chalk this up as another reason why it's best not to export from vcs to vcs, but to clone from upstream vcs to the same vcs here *when possible and the packager doesn't mind changing to upstream's vcs*. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Wed Jul 16 16:19:26 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 16 Jul 2008 12:19:26 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216220018.4854.0.camel@localhost.localdomain> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> <1216046184.8308.26.camel@gibraltar.str.redhat.com> <1216047180.3687.361.camel@firewall.xsintricity.com> <1216219223.13063.28.camel@gibraltar.str.redhat.com> <1216220018.4854.0.camel@localhost.localdomain> Message-ID: <1216225166.1891.168.camel@firewall.xsintricity.com> On Wed, 2008-07-16 at 10:53 -0400, Jesse Keating wrote: > On Wed, 2008-07-16 at 16:40 +0200, Nils Philippsen wrote: > > > It doesn't have to be, but it might be nice. > > > > Hmm, but "it might be nice" isn't a sufficient reason for me to enforce > > unchangeable tags -- "it has built successfully" would be, though. Or > > rather, let the successful build trigger the tagging of the built > > revision. > > That's why you have something other than the human apply the immutable > tag. > > The buildsystem would build from the sum that wouldn't ever > change. Once a build is actually successful, the n-v-r of that build is > immutable tagged to the matching sum by some bot running in the > build infrastructure. I agree 100%. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Wed Jul 16 16:23:48 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 16 Jul 2008 12:23:48 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216219223.13063.28.camel@gibraltar.str.redhat.com> References: <1215785905.4327.133.camel@firewall.xsintricity.com> <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215893396.3224.51.camel@localhost.localdomain> <1215907952.3687.274.camel@firewall.xsintricity.com> <1216020084.31520.9.camel@wombat.tiptoe.de> <1216045214.3687.332.camel@firewall.xsintricity.com> <1216046184.8308.26.camel@gibraltar.str.redhat.com> <1216047180.3687.361.camel@firewall.xsintricity.com> <1216219223.13063.28.camel@gibraltar.str.redhat.com> Message-ID: <1216225428.1891.173.camel@firewall.xsintricity.com> On Wed, 2008-07-16 at 16:40 +0200, Nils Philippsen wrote: > On Mon, 2008-07-14 at 10:53 -0400, Doug Ledford wrote: > > We do this internally now for the RHEL4 and RHEL5 kernels. The kernel > > maintainer has a git repo, we work from that repo, we send patches to > > the maintainer internally, they commit to the repo, then come build > > time, they spit out a tarball and a set of patches to import into CVS > > and then the build happens from CVS. It's cumbersome, and it introduces > > a few problems in that if you make a patch that touches file that are > > part of the git repo itself, but not part of what you want exported to > > the CVS checkins (such as patches to the scripts that generate a tarball > > and patches from the git repo), then those have to be filtered out > > before you check things into CVS etc. > > Heh, but these parts should have been put elsewhere in the first place, > don't you think ;-)? Not necessarily. The custom Makefile in the kernel cvs repo does some magic to massage certain files before building (like the vast array of kernel config files that it generates from a hierarchy of config settings). The sources for that massaging are part of the cvs repo, and they should also be a part of the git repo. But, because we don't use them in directly in the spec file, nor massage them directly in the spec file, they get excluded from the srpm, so if we allow git patches that touch these files to get automatically exported as patches for the srpm to use, they end up not applying to anything and break. On the other hand, we very well need those patches to be applied to the gunk that's in CVS but *doesn't* become part of the srpm. It's just a mess. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 notting at redhat.com Wed Jul 16 16:51:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 Jul 2008 12:51:36 -0400 Subject: latency-policy call for review In-Reply-To: <1216222962.3204.54.camel@hughsie-work> References: <1216222962.3204.54.camel@hughsie-work> Message-ID: <20080716165136.GB15103@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > Anyone want to review this package? It's designed to make it easy to set > system latency power tunables. How does it coexist with, or obsolete, a separate cpuspeed service? Bill From jspaleta at gmail.com Wed Jul 16 16:57:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jul 2008 08:57:02 -0800 Subject: Using git to maintain patches [was Re: Heads-up: brand new RPM version about to hit rawhide] In-Reply-To: <1216197163.8258.35.camel@muff> References: <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> <1216197163.8258.35.camel@muff> Message-ID: <604aa7910807160957q39c86126k133f0f9b8b706961@mail.gmail.com> On Wed, Jul 16, 2008 at 12:32 AM, Mark McLoughlin wrote: > I'm not sure the learning curve will always seem incredibly steep - as > we figure out the best way of doing this stuff and more people become > comfortable with it, I'm sure that it would become just as easy a > methodology to pick up as tarball+patches ... which isn't exactly a walk > in the park the first time you do it, either, if you think back. I just want to make sure the people who end up making the new vcs style packaging option available to keep the transition initial condition in mind. We will need a best practices document to help educate people to move patches over the 'right' way. We want that sort of transitional document available before this goes live for contributors to use. It will be much easier to re-educate people before they build new bad habits. Not impossible, but we just can't forget to do this. -jef From rawhide at fedoraproject.org Wed Jul 16 16:59:40 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 16 Jul 2008 16:59:40 +0000 (UTC) Subject: rawhide report: 20080716 changes Message-ID: <20080716165940.CB858209D33@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080715/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080716/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package evolution-rspam Evolution Plugin for reporting spam New package gnome-keyring-sharp Mono implementation of GNOME Keyring New package japanese-bitmap-fonts Free Japanese Bitmap fonts New package odfpy Python library for manipulating OpenDocument files New package php-pear-Net-DNS Resolver library used to communicate with a DNS server New package php-pear-Net-IPv4 IPv4 network calculations and validation New package sat4j A library of SAT solvers written in Java Updated Packages: anaconda-11.4.1.15-1 -------------------- * Tue Jul 15 18:00:00 2008 David Cantrell - 11.4.1.15-1 - Add a text-mode network config dialog so default installs can work. (clumens) - Use the right format for the NFS methodstr, but harder this time. (clumens) - Ask the user if he wants to use VNC instead of text mode (#453551) (msivak) - Fix a segfault when displaying the wrong CD message. (clumens) - Use the right format for the NFS methodstr. (clumens) - Use correct path for FAK plugins in upd-instroot (jgranado) apr-1.3.2-2.fc10 ---------------- * Wed Jul 16 18:00:00 2008 Bojan Smojver - 1.3.2-2 - ship find_apr.m4, fix bug #455189 apr-util-1.3.2-8.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Bojan Smojver - 1.3.2-8 - beat the fuzz, rework apr-util-1.2.7-pkgconf.patch * Wed Jul 16 18:00:00 2008 Bojan Smojver - 1.3.2-7 - ship find_apu.m4, fix bug #455189 beagle-0.3.8-1.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adel Gadllah - 0.3.8-1 - Update to 0.3.8 - Drop unneeded patches - Clean up requires bzr-gtk-0.94.0-4.fc10.1 ----------------------- * Mon Jul 14 18:00:00 2008 Toshio Kuratomi 0.94.0-4.1 - Add upstream patch to fix a traceback when using log in olive. - Refresh patches so we don't have fuzz. c2050-0.3b-1.fc10 ----------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel - 0.3b-1 - New upstream, just integrates the signedness patch cachefilesd-0.7-5.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.7-5 - fix license tag cacti-0.8.7b-2.fc10 ------------------- cairo-java-1.0.5-10.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 1.0.5-10 - fix license tag ccrtp-1.6.0-2.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 1.6.0-2 - fix license tag cdparanoia-10.0-3.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 10.0-3 - fix license tag - fix headers, setspeed patch to apply with fuzz=0 chkrootkit-0.48-9.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.48-9 - fix license tag cluster-2.99.06-1.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Fabio M. Di Nitto - 2.99.06-1 - New upstream release. - BR on new openais for logging features. - drop local logrotate snippet in favour of upstream one. - cman Requires: PyOpenSSL for telnet_ssl wrapper. - cman Requires: pexpect and net-snmp-utils for fence agents. Thanks to sendro on IRC for spotting the issue. - Another cleanup round for docs codeina-0.10.1-9.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.10.1-9 - fix license tag cohoba-0.0.4-6.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.0.4-6 - fix license tag commoncpp2-1.6.1-2.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 1.6.1-2 - fix license tag compat-erlang-R10B-12.10.fc10 ----------------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - R10B-12.10 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - R10B-12.9 - Autorebuild for GCC 4.3 compat-gcc-296-2.96-141 ----------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 2.96-141 - fix license tag - fix patches to apply with fuzz=0 compat-gcc-32-3.2.3-64 ---------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 3.2.3-64 - fix license tag - apply patches with fuzz=2 compat-wxGTK26-2.6.4-3 ---------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 2.6.4-3 - fix license tag compiz-0.7.6-9.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.7.6-9 - fix license tag * Tue Jul 15 18:00:00 2008 Nikolay Vladimirov - 0.7.6-8 - Rebuild for ppc64 compiz-fusion-0.7.6-6.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Adel Gadllah 0.7.6-6 - Build on ppc64 too - Add patch to fix build on ppc64 compiz-fusion-extras-0.7.6-6.fc10 --------------------------------- * Tue Jul 15 18:00:00 2008 Adel Gadllah 0.7.6-6 - Build on ppc64 too comps-extras-13-2 ----------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 13-2 - fix license tag conman-0.2.1-2.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 0.2.1-2 - fix license tag connect-proxy-1.100-2.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 1.100-2 - fix license tag cowsay-3.03-6.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 3.03-6 - fix license tag to prevent false positive * Fri May 23 18:00:00 2008 Jon Stanley - 3.03-5 - Fix license tag cpufrequtils-004-2.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 004-2 - fix license tag cpuspeed-1.2.1-8.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 1.2.1-8 - fix license tag * Sun May 11 18:00:00 2008 Dennis Gilmore 1.2.1-7 - add sparcv9 sparc64 to list of arches * Wed Mar 12 18:00:00 2008 Jarod Wilson 1.2.1-6 - Minor formatting and redirection fixups crash-4.0-7 ----------- cronolog-1.6.2-8.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 1.6.2-8 - fix license tag ctags-5.7-2.fc10 ---------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 5.7-2 - fix license tag cups-1.3.7-13.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Tim Waugh 1:1.3.7-13 - CVE-2008-1373 patch is no longer needed (applied upstream). - Mark HTML files and templates config(noreplace) for site-local modifications (bug #441719). - The cups-devel package requires zlib-devel (bug #455192). cvs-1.11.23-2.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 1.11.23-2 - fix license tag - fix patches to apply with fuzz=0 cycle-0.3.1-6.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.3.1-6 - fix license tag * Fri May 4 18:00:00 2007 Matej Cepl - 0.3.1-5 - added information about source of Debian files. debootstrap-1.0.10-1.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel - 1.0.10-1 - New upstream version deluge-0.9.02-1.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Peter Gordon - 0.9.02-1 - Update to new upstream release candidate (1.0.0 RC2) - Force building against the multithreaded Boost libs. + use-mt-boost.patch - Remove python-libtorrent Obsoletes. (It's been dead for 3 releases now; and is just clutter.) - Remove the blocklist plugin, at upstream's recommendation. elinks-0.12-0.3.pre1.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Ondrej Vasik 0.12-0.3.pre1 - get rid off fuzz in patches * Tue Jul 15 18:00:00 2008 Ondrej Vasik 0.12-0.2.pre1 - fix a crash when opening tab during page reload emerald-0.7.6-2.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Nikolay Vladimirof - 0.7.6-2 - rebuild for ppc64 firstaidkit-0.2.1-1.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Joel Granados 0.2.1-1 - New version - Brings in a new plugin. gambit-c-4.2.8-6.fc10 --------------------- * Mon Jul 14 18:00:00 2008 Michel Alexandre Salim - 4.2.8-6 - Put include files and libraries in standard paths gnome-mag-0.15.1-1.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Matthias Clasen - 0.15.1-1 - Update to 0.15.1 gok-1.4.0-1.fc10 ---------------- * Tue Jul 15 18:00:00 2008 Matthias Clasen - 1.4.0-1 - Update to 1.4.0 gpodder-0.12.0-1.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Jef Spaleta 0.12.0-1 - First of the 0.12.x series * Tue Jul 1 18:00:00 2008 Jef Spaleta 0.11.3-1 - latest stable release hunspell-pl-0.20080715-1.fc10 ----------------------------- * Tue Jul 15 18:00:00 2008 Caolan McNamara - 0.20080715-1 - latest version imake-1.0.2-7.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-7 - Fix license tag. java_cup-0.10k-1 ---------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel - 1:0.10k-1 - Fix the version to match upstream, so that FEver can be used kdebase-workspace-4.0.98-6.fc10 ------------------------------- * Tue Jul 15 18:00:00 2008 Kevin Kofler 4.0.98-6 - move systemsettings back from System to Settings in the menu kernel-2.6.27-0.144.rc0.git2.fc10 --------------------------------- * Tue Jul 15 18:00:00 2008 Dave Jones - 2.6.26-git2 * Tue Jul 15 18:00:00 2008 Dave Jones - 2.6.26-git1 knetworkmanager-0.7-0.5.20080715svn.fc10 ---------------------------------------- * Tue Jul 15 18:00:00 2008 Dennis Gilmore - 0.7-0.5.20080715svn - update to latest snapshot - renable all sub-packages - pptp is still not upstream but we will create a blank rpm for now. konversation-1.1-0.2.fc10.rc1 ----------------------------- * Tue Jul 15 18:00:00 2008 Dennis Gilmore - 1.1-0.2.rc1 - fix stupidity * Tue Jul 15 18:00:00 2008 Dennis Gilmore - 1.1-0.1.rc1 - update to 1.1 rc1 libFS-1.0.1-2.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.1-2 - Fix license tag. * Tue Jun 10 18:00:00 2008 Adam Jackson 1.0.1-1 - libFS 1.0.1 libICE-1.0.4-4.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.4-4 - Fix license tag. libSM-1.1.0-2.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.0-2 - Fix license tag. libX11-1.1.4-2.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.4-2 - Fix license tag. libXScrnSaver-1.1.2-5.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.2-5 - Fix license tag. libXTrap-1.0.0-6.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.0-6 - Fix license tag. libXau-1.0.3-6.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.3-6 - Fix license tag. libXaw-1.0.4-3.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.4-3 - Fix license tag. libXcomposite-0.4.0-5.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 0.4.0-5 - Fix license tag. libXcursor-1.1.9-3.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.9-3 - Fix license tag. libXdmcp-1.0.2-6.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-6 - Fix license tag. libXevie-1.0.2-4.fc10 --------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-4 - Fix license tag. libXfixes-4.0.3-4.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 4.0.3-4 - Fix license tag. libXinerama-1.0.3-2.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.3-2 - Fix license tag. libXres-1.0.3-5.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.3-5 - Fix license tag. libXvMC-1.0.4-5.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.4-5 - Fix license tag. libXxf86dga-1.0.2-3.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-3 - Fix license tag. libXxf86misc-1.0.1-6.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.1-6 - Fix license tag. libXxf86vm-1.0.1-6.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.1-6 - Fix license tag. libcompizconfig-0.7.6-2.fc10 ---------------------------- * Tue Jul 15 18:00:00 2008 Nikolay Vladimirof - 0.7.6-2 - rebuild for ppc64 libdmx-1.0.2-6.fc10 ------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-6 - Fix license tag. libfontenc-1.0.4-6.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.4-6 - Fix license tag. libsamplerate-0.1.4-1.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel 0.1.4-1 - New upstream release metacity-2.23.55-1.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Matthias Clasen - 2.23.55-1 - Update to 2.23.55 net-tools-1.60-89.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Zdenek Prikryl - 1.60-89 - fixed man pages for arp (#446195) - fixed netstat --interfaces option (#446187) - fixed clearing flags in ifconfig (#450252) pastebin-0.60-4.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Michael Stahnke - 0.60-4 - Fix a requires (added php) - Bug number 455389 pavucontrol-0.9.7-0.1.git20080715.fc10 -------------------------------------- * Tue Jul 15 18:00:00 2008 Lennart Poettering 0.9.7-0.1.git20080715 - Update from GIT snapshot pcmanfm-0.4.6.2-1.fc10 ---------------------- * Wed Jul 16 18:00:00 2008 Mamoru Tasaka - 0.4.6.2-1 - 0.4.6.2 perl-DateTime-0.4304-1.fc10 --------------------------- * Tue Jul 15 18:00:00 2008 Steven Pritchard 1:0.4304-1 - Update to 0.4304. - Update to DateTime::TimeZone 0.78. - Update to DateTime::Locale 0.41. perl-Devel-Cycle-1.10-1.fc10 ---------------------------- * Tue Jul 15 18:00:00 2008 Steven Pritchard 1.10-1 - Update to 1.10. perl-HTML-Template-Pro-0.70-1.fc10 ---------------------------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel (Good Data) - 0.70-1 - New upstream version perl-TAP-Harness-Archive-0.10-1.fc10 ------------------------------------ * Tue Jul 15 18:00:00 2008 Lubomir Rintel (Good Data) - 0.10-1 - New upstream version perl-Tie-EncryptedHash-1.24-1.fc10 ---------------------------------- * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway 1.23-1 - update to 1.23 - license changed to GPL+ or Artistic * Tue Jul 15 18:00:00 2008 Paul Howarth 1.24-1 - Update to 1.24 (upstream has clarified the license - see http://rt.cpan.org/Ticket/Display.html?id=28813) - Include LICENSE file as %doc perl-XML-Atom-SimpleFeed-0.82-1.fc10 ------------------------------------ * Tue Jul 15 18:00:00 2008 Lubomir Rintel (Good Data) - 0.82-1 - New upstream version phpMyAdmin-2.11.7.1-1.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Robert Scheck 2.11.7.1-1 - Upstream released 2.11.7.1 (#455520) pigment-python-0.3.4-1.fc10 --------------------------- * Fri Jul 11 18:00:00 2008 Matthias Saou 0.3.4-1 - Update to 0.3.4. pungi-2.0.3-1.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Jesse Keating 2.0.3-1 - Checksum various files from buildinstall output and put them in .treeinfo - Use new hashsum utility to generate sha1sums pykickstart-1.40-1.fc10 ----------------------- * Tue Jul 15 18:00:00 2008 Chris Lumens - 1.40-1 - RHEL5_LogVolData should inherit from FC4, not FC3. Also fix FC9->F9 typo. (dlehman) - Support creation of encrypted block devices in RHEL5. (#449830) (dlehman) - Use the right LogVolData objects for RHEL3 and 4 (jlaska). (clumens) - We no longer use rhpl for translations. (clumens) - All the base classes should derive from object. (clumens) rpm-4.5.90-0.git8426.8 ---------------------- * Tue Jul 15 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8426.8 - fix regression in macro argument handling (#455333) s3cmd-0.9.8.2-1.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Lubomir Rintel (Good Data) - 0.9.8.2-1 - New upstream speech-dispatcher-0.6.6-16.fc10 ------------------------------- * Wed Jul 16 18:00:00 2008 Hemant Goyal 0.6.6-16 - yet another release bump required :-/ * Wed Jul 16 18:00:00 2008 Hemant Goyal 0.6.6-15 - release bump * Sun Jul 13 18:00:00 2008 Hemant Goyal 0.6.6-14 - conditional build required for OLPC Branch - Building without nas and pulse-audio support. systemtap-0.7-1.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Frank Ch. Eigler - 0.7-1 - Upstream release. vala-0.3.4-2.fc10 ----------------- * Tue Jul 15 18:00:00 2008 Michel Alexandre Salim - 0.3.4-2 - Add vala-mode for editing Vala code in Emacs xorg-sgml-doctools-1.1.1-2.fc10 ------------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.1-2 - Fix license tag. xorg-x11-apps-7.3-4.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 7.3-4 - Fix license tag. xorg-x11-docs-1.3-3.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.3-3 - Fix license tag. xorg-x11-drivers-7.3-7.fc10 --------------------------- * Tue Jul 15 18:00:00 2008 Warren Togami 7.3-6 - amd was renamed to geode * Tue Jul 15 18:00:00 2008 Adam Jackson 7.3-7 - Comment cleanup. - Add imstt to ppc, just for giggles. xorg-x11-filesystem-7.3-2.fc10 ------------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 7.3-2 - Fix license tag. xorg-x11-font-utils-7.2-6.fc10 ------------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 7.2-6 - Fix license tag. xorg-x11-resutils-7.1-6.fc10 ---------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 7.1-6 - Fix license tag. xorg-x11-server-utils-7.4-2.fc10 -------------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 7.4-2 - Fix license tag. xorg-x11-twm-1.0.3-3.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.3-3 - Fix license tag. xorg-x11-utils-7.4-2.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 7.4-2 - Fix license tag. xorg-x11-xauth-1.0.2-5.fc10 --------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-5 - Fix license tag xorg-x11-xbitmaps-1.0.1-6.fc10 ------------------------------ * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.1-6 - Fix license tag. xorg-x11-xdm-1.1.6-4.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.1.6-4 - Fix license tag. xorg-x11-xfs-1.0.5-3.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.5-3 - Fix license tag. xorg-x11-xfwp-1.0.1-7.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.1-7 - Fix license tag. xorg-x11-xkb-utils-7.2-6.fc10 ----------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 7.2-6 - Fix license tag. * Wed Apr 16 18:00:00 2008 Adam Jackson 7.2-5 - xkbcomp 1.0.4 - xkbcomp-1.0.4-open-less.patch: Make xkbcomp faster by removing uncredible fail. xorg-x11-xsm-1.0.2-8.fc10 ------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.0.2-8 - Fix license tag. xorg-x11-xtrans-devel-1.2.1-2.fc10 ---------------------------------- * Tue Jul 15 18:00:00 2008 Adam Jackson 1.2.1-2 - Fix license tag. xsane-0.995-4.fc10 ------------------ * Tue Jul 15 18:00:00 2008 Nils Philippsen - 0.995-4 - don't leak file descriptors to help browser process (#455450) zaf-0-0.1.20080714svn.fc10 -------------------------- * Tue Jul 15 18:00:00 2008 Caolan McNamara - 0-0.1.20080714svn - latest version Summary: Added Packages: 7 Removed Packages: 0 Modified Packages: 114 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.i386 requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.i386 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.i386 requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.x86_64 requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.x86_64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.x86_64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtksourceview-sharp-2.0.12-3.fc10.ppc requires mono(gnome-sharp) = 0:2.16.0.0 linkage-0.1.4-6.fc9.ppc requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so stardict-3.0.1-11.1.fc10.ppc requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc requires libsvn_ra_dav-1.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so xorg-x11-drivers-7.3-7.fc10.ppc requires xorg-x11-drv-imstt Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) compiz-kde-0.7.6-9.fc10.ppc64 requires compiz-manager fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) stardict-3.0.1-11.1.fc10.ppc64 requires bonobo-activitation >= 0:2.2.0 subcommander-1.9.93-2.fc10.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) xorg-x11-drivers-7.3-7.fc10.ppc64 requires xorg-x11-drv-imstt From arjan at infradead.org Wed Jul 16 17:29:15 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Wed, 16 Jul 2008 10:29:15 -0700 Subject: latency-policy call for review In-Reply-To: <1216222962.3204.54.camel@hughsie-work> References: <1216222962.3204.54.camel@hughsie-work> Message-ID: <20080716102915.434b1414@infradead.org> On Wed, 16 Jul 2008 16:42:42 +0100 Richard Hughes wrote: does this use the pm_qos kernel infrastructure? If not.. it probably really really should... -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From dledford at redhat.com Wed Jul 16 17:55:24 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 16 Jul 2008 13:55:24 -0400 Subject: Using git to maintain patches [was Re: Heads-up: brand new RPM version about to hit rawhide] In-Reply-To: <604aa7910807160957q39c86126k133f0f9b8b706961@mail.gmail.com> References: <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> <1216197163.8258.35.camel@muff> <604aa7910807160957q39c86126k133f0f9b8b706961@mail.gmail.com> Message-ID: <1216230924.1891.178.camel@firewall.xsintricity.com> On Wed, 2008-07-16 at 08:57 -0800, Jeff Spaleta wrote: > On Wed, Jul 16, 2008 at 12:32 AM, Mark McLoughlin wrote: > > I'm not sure the learning curve will always seem incredibly steep - as > > we figure out the best way of doing this stuff and more people become > > comfortable with it, I'm sure that it would become just as easy a > > methodology to pick up as tarball+patches ... which isn't exactly a walk > > in the park the first time you do it, either, if you think back. > > I just want to make sure the people who end up making the new vcs > style packaging option available to keep the transition initial > condition in mind. We will need a best practices document to help > educate people to move patches over the 'right' way. That's one of the things I'm working on. Just as a proof of concept prototype I'm transitioning mdadm to use git. In the process, I'm working on making notes about the various things that need to be done, the general requirements that have to be met, and best practices kind of stuff. I should probably look at the work Jesse did on dist-git, but if he did it the way cvs is setup, aka as non-exploded source with a look aside cache, then it likely won't help me any. Jesse? > We want that > sort of transitional document available before this goes live for > contributors to use. It will be much easier to re-educate people > before they build new bad habits. Not impossible, but we just can't > forget to do this. I agree. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jkeating at redhat.com Wed Jul 16 18:02:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jul 2008 14:02:48 -0400 Subject: Using git to maintain patches [was Re: Heads-up: brand new RPM version about to hit rawhide] In-Reply-To: <1216230924.1891.178.camel@firewall.xsintricity.com> References: <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> <1216197163.8258.35.camel@muff> <604aa7910807160957q39c86126k133f0f9b8b706961@mail.gmail.com> <1216230924.1891.178.camel@firewall.xsintricity.com> Message-ID: <1216231368.14092.9.camel@localhost.localdomain> On Wed, 2008-07-16 at 13:55 -0400, Doug Ledford wrote: > > I should probably look at the work Jesse did on dist-git, but if he did > it the way cvs is setup, aka as non-exploded source with a look aside > cache, then it likely won't help me any. Jesse? It's likely not going to help you. It was just like dist-cvs only it used git as the scm rather than CVS. Nothing else was changed, much. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 poelstra at redhat.com Wed Jul 16 18:35:35 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 16 Jul 2008 11:35:35 -0700 Subject: consolidating on gnupg2 in F10 In-Reply-To: <20080715154726.GB24550@nostromo.devel.redhat.com> References: <20080715154726.GB24550@nostromo.devel.redhat.com> Message-ID: <487E3F77.4000605@redhat.com> Bill Nottingham said the following on 07/15/2008 08:47 AM Pacific Time: > For a really long time now, we've shipped both gnupg and gnupg2 > in Fedora. In fact, in Fedora 9 a relatively standard install will > get both installed. > > This isn't ideal, obviously - we want as much to be using the same > code, keystore, etc. as possible. > > Here's the current list of things that require gnupg 1: > > AcetoneISO2 spot > apt athimm > duplicity robert > ketchup ben > perl-GnuPG-Interface mdomsch > perl-Module-Signature scop > pgp-tools mdomsch > psi abompard > qca-gnupg abompard > spamassassin wtogami > zeroinstall-injector salimma > > It appears a good number of these can be ported to gnupg2, if not > all of them. Should we wire up a feature page? > > Bill > I think it is a good idea. John From davej at redhat.com Wed Jul 16 18:33:59 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 16 Jul 2008 14:33:59 -0400 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487B0957.9060700@op5.se> References: <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <487B0957.9060700@op5.se> Message-ID: <20080716183359.GA11438@redhat.com> On Mon, Jul 14, 2008 at 10:07:51AM +0200, Andreas Ericsson wrote: > Arjan van de Ven wrote: > > On Sat, 12 Jul 2008 20:10:51 -0400 > >> Presumably one could replicate this as needed. However, there is the > >> question of whether or not it's needed. Remember that the concept > >> using an upstream tarball as the canonical source version that we > >> represent to the world that we are using is nothing more than a > >> policy decision. Nothing in the GPL or anything else said we had to > >> do that, it was just what we *chose* to do (long, long ago, in a > >> galaxy far, far away). > > > > one thing to keep in mind... as comparison, what you don't want is what > > Ubuntu is doing with their kernel (clone Linus and then just edit the > > source tree); it's just one big nightmare (as you can imagine). Keeping > > upstream source and local patches separate is a clear winner (anyone > > who has worked on the alternative will agree with me). > > Well, if they clone and then edit without using separate branches for > their various edits, then ofcourse it'll be a nightmare to manage. Even then, it becomes a real pain. I did some experiments about a year and a half ago where I kept a git-tree that I committed to in parallel to changes in CVS. The git workflow ended up taking a lot more time. With the CVS workflow, dropping a patch in the middle of a series is trivial. With git, it became a royal pain in the ass when later branches would now need rediffing. Editting a diff directly to fix up offsets for eg, is trivial with the patch-in-cvs approach. It was more painful because at the time we carrying huge patches like Xen, but even without that monstrosity, for a package which contains a lot of come-and-go patches like the kernel, it's really the wrong workflow. Quilt is probably a lot more appropriate than git to be honest for a vendor kernel. Something git wins at hands down is getting changes into a tree. Pulling stuff back out is a complete nightmare. Given our goal is to get as many of our patches upstream asap, having a tool that allows to get lots of change IN doesn't really help. > Not for the casual developer with an itch to scratch. I had 6 full > days of work to spend on fixing the touchpad on my particular laptop > (see bugzilla.redhat.com #448656) so the system actually became usable > again, but since I couldn't duplicate the source-tree from the failing > fedora kernel, I had nothing to diff against, so no way in hell I could > send a patch. You'd really want to be basing any work on the latest cvs anyway, of which there are instructions at https://fedoraproject.org/wiki/Kernel (Substitute devel with F-9 or whatever..) Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jul 16 18:36:39 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 16 Jul 2008 14:36:39 -0400 Subject: handling a 'debug' or 'development' setting In-Reply-To: <1216170170.3372.2.camel@tuxhugs> References: <20080715222427.GA1170@nostromo.devel.redhat.com> <1216170170.3372.2.camel@tuxhugs> Message-ID: <20080716183639.GB11438@redhat.com> On Tue, Jul 15, 2008 at 06:02:50PM -0700, Peter Gordon wrote: > On Tue, 2008-07-15 at 18:24 -0400, Bill Nottingham wrote: > > 1) What can we reasonably set? > > > > Right now, there's MALLOC_CHECK_ and MALLOC_PERTURB. There > > should be more. Is there anything in the various desktops > > that is appropriate? > > I would love it if, when this 'debug mode' is active, any package > installation would automagically install the relevant debuginfos to > accompany it. (Likewise, any package removal should remove the leaf > debuginfo.) If that happens it should definitly be optional given the size of debuginfo packages. I can't think of a single situation where I'd need the debuginfo for every package installed. Installing them on demand before running gdb is painful, but a lot less so than sitting around twiddling thumbs waiting for yum to update several gig of debuginfos. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jul 16 18:44:20 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 16 Jul 2008 14:44:20 -0400 Subject: latency-policy call for review In-Reply-To: <20080716165136.GB15103@nostromo.devel.redhat.com> References: <1216222962.3204.54.camel@hughsie-work> <20080716165136.GB15103@nostromo.devel.redhat.com> Message-ID: <20080716184420.GC11438@redhat.com> On Wed, Jul 16, 2008 at 12:51:36PM -0400, Bill Nottingham wrote: > Richard Hughes (hughsient at gmail.com) said: > > Anyone want to review this package? It's designed to make it easy to set > > system latency power tunables. > > How does it coexist with, or obsolete, a separate cpuspeed service? last one to run stomps over the other. this one also seems to lack a lot of the logic in cpuspeeds initscript to determine if we're actually capable of running the ondemand governor. If the CPU is capable of running ondemand in a manner that it doesn't introduce performance regressions, we choose it already in cpuspeed. latency policy seems to be trying to second guess all of that. My vote would be to rip out all of this from latencypolicy, and have lp set the sampling rate sysfs knobs. Dave -- http://www.codemonkey.org.uk From Axel.Thimm at ATrpms.net Wed Jul 16 19:45:15 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Jul 2008 22:45:15 +0300 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D0918.3010309@when.com> References: <487D0918.3010309@when.com> Message-ID: <20080716194515.GD16657@puariko.nirvana> On Tue, Jul 15, 2008 at 10:31:20PM +0200, Sebastian Dziallas wrote: > [...] EDU Math spin was born.[...] Warren announced a K12LTSP spin > including his LTSP5-work [3], even if I don't know, how the current > state is there [4]. [...] The Astronomy SIG is preparing an > astronomy spin, too. [...] an OLPC (or more specific: a sugar-based) > spin more than soon [...] There might be still some place for an > Fedora Education Language Spin (hey, why don't why split this one > up? - Fedora Education Language English and Fedora Education > Language German spin are awaiting their maintainers!)... > > Sorry, this might somehow sound inappropriate, but that is just the way > it is. Don't get me wrong - I'm even myself a member of the Spin SIG and > I applaud everyone's efforts to make use of this innovative technology - > and I'm not going to blame anyone for his/her work, but still: I think > it's obvious that we're going to run into trouble that way... > > What do you think? Personally as a user I'd prefer a less fragmented landscape, especially in the broader educational institutions like schools. OTOH the spin technology gets more throughput and gets improved and astronomers and mathematician, LTSP and OLPC can be on their own independent release schedules. So in the end you have a users vs developers problem. But IMHO I'd say let the spins do their start and then we can discuss about how to merge them. From a naive POV I would think that for example merging math and astro/phys spins should be just a collation of package lists and then maybe a space problem (e.g. no CD spin, straight-to-DVD). But for some special technolgies like LTSP or OLPC which go beyond package collations [1] I see a clear need for their own scheduling until they become standard components. My advice: Perhaps some spin people don't know that there are similar spinning efforts (like math and astro folks), and if they do get to know that they might join up forces. So having a spin coordinator that introduces the various groups to each other sounds like a good idea (and sounds like his first name should be Sebastian :). But other than that, if the groups prefer to spin alone, let them and they can still later discover each other. [1] I'm not lowering math/astro/lang spins, but LTSP/OLPC are almost upstream spins hot from development to testing users -- 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 Axel.Thimm at ATrpms.net Wed Jul 16 19:49:16 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Jul 2008 22:49:16 +0300 Subject: freenx orphaned - not Message-ID: <20080716194916.GE16657@puariko.nirvana> Hi, freenx was upstream split into a server and client tarball. The respective packages were resubmitted and rereviewed with a plan to simply decomission the old "freenx" package. So for devel it was orphaned (and maybe I need to orphan it for F8/F9, but I'm not sure, since it was there on the release day). So please don't try to pick it up, let it die :) (But if you are interested in freenx/nx anyway, just add yourself to the packagedb). -- 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 jspaleta at gmail.com Wed Jul 16 20:00:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jul 2008 12:00:43 -0800 Subject: Fedora Spins and "where will this end?" In-Reply-To: <20080716194515.GD16657@puariko.nirvana> References: <487D0918.3010309@when.com> <20080716194515.GD16657@puariko.nirvana> Message-ID: <604aa7910807161300i8900150sc105492ca2184dc3@mail.gmail.com> 2008/7/16 Axel Thimm : > My advice: Perhaps some spin people don't know that there are similar > spinning efforts (like math and astro folks), and if they do get to > know that they might join up forces. So having a spin coordinator that > introduces the various groups to each other sounds like a good idea > (and sounds like his first name should be Sebastian :). But other than > that, if the groups prefer to spin alone, let them and they can still > later discover each other. The Spin SIG and the kickstart pool hosted on fedorahosted should help make it easier to know about other efforts moving forward. Making sure spins.fp.org gets the love it needs so it can be attractive and informative will help as well. -jef From hughsient at gmail.com Wed Jul 16 20:05:31 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jul 2008 21:05:31 +0100 Subject: latency-policy call for review In-Reply-To: <20080716184420.GC11438@redhat.com> References: <1216222962.3204.54.camel@hughsie-work> <20080716165136.GB15103@nostromo.devel.redhat.com> <20080716184420.GC11438@redhat.com> Message-ID: <1216238731.31217.4.camel@hughsie-work> On Wed, 2008-07-16 at 14:44 -0400, Dave Jones wrote: > On Wed, Jul 16, 2008 at 12:51:36PM -0400, Bill Nottingham wrote: > > Richard Hughes (hughsient at gmail.com) said: > > > Anyone want to review this package? It's designed to make it easy to set > > > system latency power tunables. > > > > How does it coexist with, or obsolete, a separate cpuspeed service? > > last one to run stomps over the other. Exactly, it's not actually a great friend at the moment. > this one also seems to lack a lot of the logic in cpuspeeds initscript > to determine if we're actually capable of running the ondemand governor. > > If the CPU is capable of running ondemand in a manner that it doesn't > introduce performance regressions, we choose it already in cpuspeed. > latency policy seems to be trying to second guess all of that. Well, it's a lot more blunt. In the long term I would like to get the latency information from the kernel, so we can make some sort of sane estimation of the latencies involved. > My vote would be to rip out all of this from latencypolicy, and have lp > set the sampling rate sysfs knobs. I guess you meant "have cpuspeed set the knobs" in which case that might be sane. I would really like the latency information from the kernel so we can still load ondemand even if the latency is horrible when we configure for maximum latency for maximum powersaving. Richard. From hughsient at gmail.com Wed Jul 16 20:28:17 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Jul 2008 21:28:17 +0100 Subject: latency-policy call for review In-Reply-To: <20080716102915.434b1414@infradead.org> References: <1216222962.3204.54.camel@hughsie-work> <20080716102915.434b1414@infradead.org> Message-ID: <1216240097.31217.9.camel@hughsie-work> On Wed, 2008-07-16 at 10:29 -0700, Arjan van de Ven wrote: > On Wed, 16 Jul 2008 16:42:42 +0100 > Richard Hughes wrote: > > does this use the pm_qos kernel infrastructure? > If not.. it probably really really should... Yes, I've looked briefly at pm_qos. The set of scripts I propose are much simpler than that. I think a set of simple scripts is a nice initial half solution, and certainly not the finished article. Richard. From drago01 at gmail.com Wed Jul 16 21:35:11 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jul 2008 23:35:11 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: <1216091968.9625.13.camel@tuxhugs> References: <1216091968.9625.13.camel@tuxhugs> Message-ID: dbus-c++ is now packaged and built but it still fails to build. Peter can you please have a look at http://code.google.com/p/linkage/issues/detail?id=59&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Opened Did the API between 0.13 -> 0.13.1 ? From bpepple at fedoraproject.org Wed Jul 16 22:07:08 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 16 Jul 2008 18:07:08 -0400 Subject: Plan for tomorrows (20080717) FESCO meeting Message-ID: <1216246028.10881.2.camel@truman> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- new maintainer containment update -- sadmac2, abadger1999 /topic FESCo-Meeting -- Changing bodhi karma -- nirik /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/ConnectionSharing /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/GlitchFreeAudio /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/LatencyPolicy /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/NodokaNotificationTheme /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/OpenChange /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/SecurityAudit /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sebastian at when.com Wed Jul 16 22:23:30 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Thu, 17 Jul 2008 00:23:30 +0200 Subject: Fedora Spins and "where will this end?" In-Reply-To: <20080716194515.GD16657@puariko.nirvana> References: <487D0918.3010309@when.com> <20080716194515.GD16657@puariko.nirvana> Message-ID: <487E74E2.8000307@when.com> Axel Thimm wrote: > On Tue, Jul 15, 2008 at 10:31:20PM +0200, Sebastian Dziallas wrote: >> [...] EDU Math spin was born.[...] Warren announced a K12LTSP spin >> including his LTSP5-work [3], even if I don't know, how the current >> state is there [4]. [...] The Astronomy SIG is preparing an >> astronomy spin, too. [...] an OLPC (or more specific: a sugar-based) >> spin more than soon [...] There might be still some place for an >> Fedora Education Language Spin (hey, why don't why split this one >> up? - Fedora Education Language English and Fedora Education >> Language German spin are awaiting their maintainers!)... >> >> Sorry, this might somehow sound inappropriate, but that is just the way >> it is. Don't get me wrong - I'm even myself a member of the Spin SIG and >> I applaud everyone's efforts to make use of this innovative technology - >> and I'm not going to blame anyone for his/her work, but still: I think >> it's obvious that we're going to run into trouble that way... >> >> What do you think? > > Personally as a user I'd prefer a less fragmented landscape, > especially in the broader educational institutions like schools. > > OTOH the spin technology gets more throughput and gets improved and > astronomers and mathematician, LTSP and OLPC can be on their own > independent release schedules. > > So in the end you have a users vs developers problem. But IMHO I'd say > let the spins do their start and then we can discuss about how to merge > them. From a naive POV I would think that for example merging math and > astro/phys spins should be just a collation of package lists and then > maybe a space problem (e.g. no CD spin, straight-to-DVD). > > But for some special technolgies like LTSP or OLPC which go beyond > package collations [1] I see a clear need for their own scheduling > until they become standard components. Agreed! Later, we could consider those mergers... for now, you may be right that the best way would be to move on and to publish something first. I also agree concerning those "upstream" spins, but some kind of discussion cannot be bad, though?! > My advice: Perhaps some spin people don't know that there are similar > spinning efforts (like math and astro folks), and if they do get to > know that they might join up forces. So having a spin coordinator that > introduces the various groups to each other sounds like a good idea > (and sounds like his first name should be Sebastian :). But other than > that, if the groups prefer to spin alone, let them and they can still > later discover each other. Yeah! :) That's also what I wanted to point out: It was really not my intention to criticize the Spin SIG's policies or anything like this - I just wanted to bring this topic to the surface, since I think it should be mentioned. I also believe that we need a kind of collaboration between those groups, which are all acting more or less in the same sector. That's how we can make sure, that we're not doing the same work two or three times. Maybe we should even have an IRC meeting concerning this topic soonish, so that we might get some opinions from the other SIGs and further interested people. > [1] I'm not lowering math/astro/lang spins, but LTSP/OLPC are almost > upstream spins hot from development to testing users From mjg at redhat.com Wed Jul 16 22:28:12 2008 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 16 Jul 2008 23:28:12 +0100 Subject: latency-policy call for review In-Reply-To: <20080716102915.434b1414@infradead.org> References: <1216222962.3204.54.camel@hughsie-work> <20080716102915.434b1414@infradead.org> Message-ID: <20080716222812.GA15531@srcf.ucam.org> On Wed, Jul 16, 2008 at 10:29:15AM -0700, Arjan van de Ven wrote: > does this use the pm_qos kernel infrastructure? > If not.. it probably really really should... To be honest, I'm moderately convinced that the pm_qos userspace interface should be indicted for crimes against humanity. Lennart's suggestion that this be implemented through cgroups seems a rather more elegant solution. -- Matthew Garrett | mjg59 at srcf.ucam.org From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 17 00:34:11 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 17 Jul 2008 09:34:11 +0900 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: References: <1216091968.9625.13.camel@tuxhugs> Message-ID: <487E9383.8090800@ioa.s.u-tokyo.ac.jp> drago01 wrote, at 07/17/2008 06:35 AM +9:00: > dbus-c++ is now packaged and built but it still fails to build. > > Peter can you please have a look at > http://code.google.com/p/linkage/issues/detail?id=59&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Opened > Did the API between 0.13 -> 0.13.1 ? > This is very similar with https://bugzilla.redhat.com/show_bug.cgi?id=454940#c3 and for this issue the following can be a workaround: ----------------------------------------------------------- sed -i \ -e 's|\$ac_boost_path/lib|\$libdir|' \ -e 's|$ac_boost_path_tmp/lib|\$libdir|' \ configure ----------------------------------------------------------- However even after applying this workaround, the build fails at another point (not specific to x86_64): http://koji.fedoraproject.org/koji/taskinfo?taskID=721548 Mamoru From tomek at crocom.com.pl Thu Jul 17 06:35:37 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Thu, 17 Jul 2008 08:35:37 +0200 Subject: latency-policy call for review In-Reply-To: <1216222962.3204.54.camel@hughsie-work> References: <1216222962.3204.54.camel@hughsie-work> Message-ID: <1216276537.23774.5.camel@s1.crocom.com.pl> Dnia 2008-07-16, ?ro o godzinie 16:42 +0100, Richard Hughes pisze: > [root at hughsie-work sys]# service latency-policy restart > Setting best-effort system latency: 10000?s [ OK ] > ? Enabling ALPM link powersave [ OK ] > ? Enabling ASPM powersave [ OK ] > ? Enabling ALSA powerdown [ OK ] > ? Enabling ondemand governor [ OK ] > ? Enabling WiFi poll powersave [ OK ] I don't see scripts for /etc/pm for this features, only boot script. Some of those setting need to be restored upon resume (HDD set by hdparm must be for sure). Others should be disabled/enabled around suspend (ALPM could make resume slow). -- Tomasz Torcz From kzak at redhat.com Thu Jul 17 08:08:58 2008 From: kzak at redhat.com (Karel Zak) Date: Thu, 17 Jul 2008 10:08:58 +0200 Subject: handling a 'debug' or 'development' setting In-Reply-To: <20080715222427.GA1170@nostromo.devel.redhat.com> References: <20080715222427.GA1170@nostromo.devel.redhat.com> Message-ID: <20080717080858.GC13886@nb.net.home> On Tue, Jul 15, 2008 at 06:24:27PM -0400, Bill Nottingham wrote: > We should have a generic framework for running in a 'debug' > or 'development' mode that does extra debugging at the sake > of some minimal amount of performance. I guess there are many packages where you can enable extra checks (mem checks, assert code, ...) -- for example PostgreSQL, glib, ... It would be nice to have a generic way to enable/disable this stuff in spec files. %configure \ --enable-foo \ %if %{develmode} --enable-asserts %endif --enable-bar Karel -- Karel Zak From ae at op5.se Thu Jul 17 10:49:27 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 17 Jul 2008 12:49:27 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <1216139066.6039.81.camel@localhost.localdomain> References: <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintricity.com> <20080712220927.fc9c9e52.mschwendt@gmail.com> <1215907851.3687.271.camel@firewall.xsintricity.com> <20080712174916.0b9fff00@infradead.org> <1216137680.6039.61.camel@localhost.localdomain> <604aa7910807150915m5a9b4d8fx9e24b0d71ac05692@mail.gmail.com> <1216139066.6039.81.camel@localhost.localdomain> Message-ID: <487F23B7.10400@op5.se> Dan Williams wrote: > On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: >> On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams wrote: >>> Yeah, there is actually a benefit to tarball+patches approach we take >>> right now; and that benefit is that it's extremely easy to see just what >>> we've done to the upstream package, and it's usually really easy to >>> extract those changes and push them upstream. You don't want a >>> mega-diff that includes 20 specific patches. >> I know of at least one example currently in our cvs where we went from >> a set of separate small patch files to one encompassing patch file. I >> think it was a diff from git. If we move to more advanced vcs are we >> going to have a harder time keeping patches separated? Or is it just a >> matter of education on how not to reach for the easy to produce mega >> patch shortcut? > > That's the problem here: if we move to git (or any DVCS really), as a > packager you would have to be _much_ more aware of how to use the VCS to > achieve the same separation of patches and upstream source. You'd need > to do something like topic branches for each patch and then merge each > topic branch into a "release" branch to ensure that each of the patches > was cleanly separated from the main source. > Well, I spent 4 days learning all of git's sourcecode once (mind you, it was a long time ago) and just recently I spent that long trying, and failing, to get the exact sources to the kernel I was running when I found a bug in it. Since the kernel is managed in git, I was quite appalled to find out that fedora doesn't have a repo anywhere with tags set so I could just clone it, check the right version out and fire up a bisect-run. In the end, I settled for hacking the source rpm to run a "git commit -a" between each patchfile so I could at least bisect on the result of that, and then exclude the fedora patches from the list of possible culprits to my particular problem. Mind you, with all the hackery I had to go through to get that working, I can't say for sure that what I was looking at in the end was actually the sources of my running kernel anyway so it could just as well have been a complete and utter waste of time. Anyways, different workflow or not, using a distributed version control system provides three huge advantages over tarball + patches, namely: * Endpoint-hacker access to the reason a particular patch is needed. Without this, it's extremely tedious to know what to test when altering code in the same area a particular other patch touched, and so is much more likely to introduce regressions. * Easy access to the exact revision. I won't ever try to debug the fedora kernel again. I'll just clone the vanilla kernel tree and find out which version fixes my particular issue or, if none of them does, start hacking on the upstream one instead. If some issue I'm seeing isn't in the upstream, I'll just report it as being caused by one of the patches in fedora. Hardly any work left for the poor fedora kernel folks to do what with the >100 patches you apply to the tarball. * Bisection. If you've never used an scm that has a bisect command, you won't know what I'm talking about and you won't know what you've missed. It's like telling your scm "find which exact revision introduced this bug", and it does it. Instead of looking at a sourcetree of 10k-5M LoC you get to see a single patch that introduced the bug you're looking for. > Basically, moving to a DVCS and exploded source trees just raises the > bar for packagers since they'd have to learn quite a bit about how DVCS > works. CVS + tarball + patches are quite easy for most people to learn, > but a DVCS + branches + merges is much more complicated if the > changesets are small. And the changesets should always be small, > otherwise we're completely failing at pushing stuff upstream. > Why would you have packagers doing merges? They really shouldn't need to do that. Only developers (and yes, package managers for really complex projects, like the kernel) will need to know about branches and merges. Package-managers just need to know how to extract a tarball from a repository, so that's a single command they need to know about. > Maybe the fix here is to let package maintainers who want to use a DVCS > style, and those that don't want to use the old style, and provide the > ability to switch between the two styles when a new maintainer takes > over the package? > I think that's what Doug has been after the entire time. Obviously, the kernel is tons easier to manage if it's all in git, with patches committed to it as changesets rather than separate files. I'd imagine the same goes for every other project whose upstream is managed in git as well. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Thu Jul 17 11:06:55 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 17 Jul 2008 13:06:55 +0200 Subject: Heads-up: brand new RPM version about to hit rawhide In-Reply-To: <487E157F.1080008@gmail.com> References: <1215792220.3687.9.camel@firewall.xsintricity.com> <1215794681.3687.22.camel@firewall.xsintricity.com> <1215795439.3020.39.camel@rosebud> <1215810856.3687.41.camel@firewall.xsintricity.com> <1215817080.3224.37.camel@localhost.localdomain> <1215825090.3687.106.camel@firewall.xsintricity.com> <1215862943.14579.24.camel@weaponx> <1215873360.3687.213.camel@firewall.xsintricity.com> <1215884435.14579.36.camel@weaponx> <1215887445.3687.244.camel@firewall.xsintricity.com> <1215889247.25351.8.camel@rousalka.okg> <1215891067.3687.263.camel@firewall.xsintrici ty.com> <487C48FD.9040609@op5.se> <487D9E2D.8050902@op5.se> <487DCD6B.7040800@op5.se> <487E157F.1080008@gmail.com> Message-ID: <487F27CF.3060508@op5.se> Toshio Kuratomi wrote: > Andreas Ericsson wrote: >> >> But the URL is not immutable. You wouldn't believe the number of >> people that >> have come to the git-list to complain about git-svn not properly >> importing >> svn repositories simply because the layout has changed since the >> repository >> was first started, or because it was moved one directory up, or some >> branch >> was deleted after having been used to tag something from. SVN is >> fragile and >> has no way of canonically naming a commit. URL+Rev doesn't cut it, since >> URL can change (and so can rev, but only in insane cases). >> > That's a misunderstanding of SVN. > > The URL at a revision cannot change Yes it can. Let's just say someone decided to move his project off of sourceforge and onto some dedicated hosting. The url has changed. > without filtering the repository > (which you could do with any SCM if you understand the internal > repository format). > But with a DVCS you would then *know* that the repository has been filtered (ie, tampered with), because the commit id would no longer be the same, or perhaps not even exist in the upstream repository. If you filter an SVN repository and ask for revision 10, you'll get different stuff before and after the filtering, and there's no way you can know that. > You're seeing URLs change between revisions. IE: revision 10 has > file:///trunk/foo/README.txt revision 11 has file:///foo/trunk/README.txt > I don't understand this example or what it's supposed to prove at all. My conclusions on this topic is that when the upstream project is managed by , you'd be better off building from a local clone of upstreams dscm repository directly. If it's managed in CVS or SVN or any other scm that cannot be cloned with 100% accuracy (including ancestry), you'd be better off using tarballs and patches. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From drago01 at gmail.com Thu Jul 17 12:06:11 2008 From: drago01 at gmail.com (drago01) Date: Thu, 17 Jul 2008 14:06:11 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: <487E9383.8090800@ioa.s.u-tokyo.ac.jp> References: <1216091968.9625.13.camel@tuxhugs> <487E9383.8090800@ioa.s.u-tokyo.ac.jp> Message-ID: On Thu, Jul 17, 2008 at 2:34 AM, Mamoru Tasaka wrote: > drago01 wrote, at 07/17/2008 06:35 AM +9:00: >> >> dbus-c++ is now packaged and built but it still fails to build. >> >> Peter can you please have a look at >> >> http://code.google.com/p/linkage/issues/detail?id=59&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Opened >> Did the API between 0.13 -> 0.13.1 ? >> > > This is very similar with > https://bugzilla.redhat.com/show_bug.cgi?id=454940#c3 and for this issue > the following can be a workaround: > ----------------------------------------------------------- > sed -i \ > -e 's|\$ac_boost_path/lib|\$libdir|' \ > -e 's|$ac_boost_path_tmp/lib|\$libdir|' \ > configure > ----------------------------------------------------------- > > However even after applying this workaround, the build fails at another > point > (not specific to x86_64): > http://koji.fedoraproject.org/koji/taskinfo?taskID=721548 OK, thanks I fixed this one too and now it builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=722171 But the regular build failed due to a broken dep ....http://koji.fedoraproject.org/koji/taskinfo?taskID=722185 From lmacken at redhat.com Thu Jul 17 14:24:41 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 17 Jul 2008 10:24:41 -0400 Subject: Plan for tomorrows (20080717) FESCO meeting In-Reply-To: <1216246028.10881.2.camel@truman> References: <1216246028.10881.2.camel@truman> Message-ID: <20080717142441.GB22081@x300.bos.redhat.com> On Wed, Jul 16, 2008 at 06:07:08PM -0400, Brian Pepple wrote: > Hi all, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: [...] > /topic FESCo-Meeting -- Changing bodhi karma -- nirik What changes are being proposed to bodhi's karma? I'm in the process of rolling out a new version that contains fully customizable stable/unstable karma thresholds[0], support for adjustment of your vote[1], and the removal of weight from anonymous votes[2]. luke [0]: https://fedorahosted.org/bodhi/ticket/124 [1]: https://fedorahosted.org/bodhi/ticket/104 [2]: https://fedorahosted.org/bodhi/ticket/182 From rawhide at fedoraproject.org Thu Jul 17 14:58:12 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 17 Jul 2008 14:58:12 +0000 (UTC) Subject: rawhide report: 20080717 changes Message-ID: <20080717145812.D1120209D94@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080716/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080717/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package coq Coq proof management system New package cx18-firmware Firmware for Conexant cx23418-based video capture devices New package dbus-c++ Native C++ bindings for D-Bus New package tex-simplecv A simple latex class for writing curricula vitae New package typespeed Test your typing speed and get your fingers' CPS New package udns DNS resolver library for both synchronous and asynchronous DNS queries New package xdemorse GTK based application for decoding and displaying Morse code signals Updated Packages: alexandria-0.6.3-5.fc10 ----------------------- * Wed Jul 16 18:00:00 2008 Mamoru Tasaka - 0.6.3-5 - Remove workaround for bug 436697 (tooltips crash). This was a bug on ruby-gnome2 which is fixed in 0.17.0 rc1 attr-2.4.43-1.fc10 ------------------ * Wed Jul 16 18:00:00 2008 Zdenek Prikryl 2.4.43-1 - New version 2.4.43 cairo-dock-1.6.1.2-1.fc10 ------------------------- * Thu Jul 17 18:00:00 2008 Mamoru Tasaka - 1.6.1.2-1 - 1.6.1.2 clive-0.4.18-1.fc10 ------------------- * Wed Jul 16 18:00:00 2008 Nicoleau Fabien 0.4.18-1 - rebuild for 0.4.18 compiz-manager-0.6.0-8.fc10 --------------------------- * Wed Jul 16 18:00:00 2008 Sebastian Vahl - 0.6.0-8 - re-enable ppc64 - update patch to respect ppc64 coreutils-6.12-6.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Ondrej Vasik - 6.12-6 - Get rid off fuzz in patches dbh-1.0.24-7.fc10 ----------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 1:1.0.24-7 - fix license tag dbus-python-0.82.4-3.fc10 ------------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.82.4-3 - fix license tag dbus-sharp-0.63-10.fc10 ----------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.63-10 - fix license tag dd_rescue-1.14-8.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 1.14-8 - fix license tag ddrescue-1.8-3.fc10 ------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 1.8-3 - fix license tag dejavu-fonts-2.25-4.fc10 ------------------------ * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 2.25-4 - note Public Domain contributions * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 2.25-3 - fix license tag dev86-0.16.17-10.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 0.16.17-10 - fix license tag dhcp-forwarder-0.7-15.fc10 -------------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.7-15 - fix license tag dictd-1.10.11-3 --------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 1.10.11-3 - fix license tag diffstat-1.43-8.fc10 -------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 1.43-8 - fix license tag dircproxy-1.2.0-0.8.beta2.fc10 ------------------------------ * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 1.2.0-0.8.beta2 - fix license tag dirvish-1.2.1-3.fc10 -------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 1.2.1-3 - fix license tag dmidecode-2.9-1.31.fc10 ----------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 1:2.9-1.30 - fix license tag dnsmasq-2.43-2.fc10 ------------------- * Wed Jul 16 18:00:00 2008 Patrick "Jima" Laughton 2.43-2 - New upstream release, contains fixes for CVE-2008-1447/CERT VU#800113 - Dropped patch for newer glibc (merged upstream) dogtail-0.6.90-1.381.fc10.1 --------------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.6.90-1.381.1 - fix license tag dosfstools-2.11-10.fc10 ----------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 2.11-10 - fix license tag - fix patch to apply with fuzz=0 doxygen-1.5.6-3.fc10 -------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 1.5.6-3 - fix license tag drgeo-1.1.0-14.fc10 ------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 1.1.0-14 - fix license tag driftnet-0.1.6-17.20040426cvs.fc10 ---------------------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.1.6-17.20040426cvs - fix license tag dssi-0.9.1-15.fc10 ------------------ * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.9.1-15 - fix license tag - patch0 was unnecessary dtach-0.7-3 ----------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.7-3 - fix license tag dvgrab-3.1-4.fc10 ----------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 3.1-4 - fix license tag dx-samples-4.4.0-4.fc10 ----------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway 4.4.0-4 - fix license tag empathy-0.23.4-1.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Brian Pepple - 0.23.4-1 - Update to 0.23.4. - Update source url. esound-0.2.39-1.fc10 -------------------- * Tue Jul 15 18:00:00 2008 Matthias Clasen 0 1:0.2.39-1 - Update to 0.2.39 - Drop upstreamed patches - Temporarily disable doc build due to xml catalog issues fusecompress-1.99.17-2.fc10 --------------------------- * Wed Jul 16 18:00:00 2008 Lubomir Rintel - 1.99.17-2 - Fix build: - Upstream added manual - Upstream looks for xattr.h in a little non-standard place - GCC 4.3 fix * Wed Jul 16 18:00:00 2008 Lubomir Rintel - 1.99.17-1 - Upstream integrated our fix ganglia-3.1.0-0.4.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Kostas Georgiou 3.1.0-0.4 - Update to the 3.1.0 pre-release - Fixes gmond.conf to use the ganglia user and not nobody - Removal of the ppc64 work-around glibc-2.8.90-9 -------------- * Wed Jul 16 18:00:00 2008 Jakub Jelinek 2.8.90-9 - update from trunk - fix unbuffered vfprintf if writing to the stream fails (#455360) - remove useless "malloc: using debugging hooks" message (#455355) - nscd fixes - fix resolver alignment issues (#454500) - fix setvbuf (BZ#6719) gtksourceview-sharp-2.0.12-4.1.fc10 ----------------------------------- * Mon Jul 14 18:00:00 2008 Paul F. Johnson - 2.0-0.12-4.1 - rebuild for new gtk-sharp2 * Fri Jul 11 18:00:00 2008 Paul F. Johnson - 2.0-0.12-4 - rebuild for new gnome-sharp - fix BR to use gtksourceview rather than gtksourceview-2 - correct exclusivearchs jd-2.0.0-0.8.svn2204_trunk.fc10 ------------------------------- * Thu Jul 17 18:00:00 2008 Mamoru Tasaka - rev 2204 kdebase-workspace-4.0.98-8.fc10 ------------------------------- * Wed Jul 16 18:00:00 2008 Kevin Kofler 4.0.98-8 - fix KDM ConsoleKit patch to use x11-display-device instead of display-device * Wed Jul 16 18:00:00 2008 Kevin Kofler 4.0.98-7 - fix segfault in KDM ConsoleKit patch (#455562) kdesvn-0.14.6-1.fc10 -------------------- * Tue Jul 15 18:00:00 2008 - Orion Poplawski - 0.14.6-1 - Update to 0.14.6 kernel-2.6.27-0.156.rc0.git4.fc10 --------------------------------- * Wed Jul 16 18:00:00 2008 Kristian H??gsberg - Also copy new include/drm directory. * Wed Jul 16 18:00:00 2008 Dave Jones - Remove sparc32 config files. * Wed Jul 16 18:00:00 2008 Dave Jones - Remove extraneous sparc64 config file. * Wed Jul 16 18:00:00 2008 Dave Jones - Merge Linux-2.6 up to commit 8a0ca91e1db5de5eb5b18cfa919d52ff8be375af * Wed Jul 16 18:00:00 2008 Dave Jones - 2.6.26-git4 * Wed Jul 16 18:00:00 2008 Dave Jones - 2.6.26-git3 libextractor-0.5.20b-2.fc10 --------------------------- * Wed Jul 16 18:00:00 2008 Tom "spot" Callaway - 0.5.20b-2 - fix license tag libnetfilter_conntrack-0.0.96-1.fc10 ------------------------------------ * Wed Jul 16 18:00:00 2008 Paul P. Komkoff Jr - 0.0.96-1 - grab new upstream version - use bundled header again libnetfilter_log-0.0.14-1.fc10 ------------------------------ * Wed Jul 16 18:00:00 2008 Paul P. Komkoff Jr - 0.0.14-1 - grab latest upstream version libnetfilter_queue-0.0.16-1.fc10 -------------------------------- * Wed Jul 16 18:00:00 2008 Paul P. Komkoff Jr - 0.0.16-1 - new upstream version libnfnetlink-0.0.39-1.fc10 -------------------------- * Fri Jul 4 18:00:00 2008 Paul P. Komkoff Jr - 0.0.39 - grab latest upstream release lksctp-tools-1.0.8-1.fc10 ------------------------- * Wed Jul 16 18:00:00 2008 Zdenek Prikryl 1.0.8-1 - Update to 1.0.8 lyx-1.6.0-0.4.beta4.fc10 ------------------------ * Wed Jul 16 18:00:00 2008 Jos?? Matos - 1.6.0-0.4.beta4.fc10 - Changelog has been removed from the distribution * Wed Jul 16 18:00:00 2008 Jos?? Matos - 1.6.0-0.3.beta4.fc10 - icon has changed from xpm to png * Wed Jul 16 18:00:00 2008 Jos?? Matos - 1.6.0-0.2.beta4.fc10 - revert to use pre instead of devrel. - require tex-simplecv (#428526) * Wed Jul 16 18:00:00 2008 Jos?? Matos - 1.6.0-0.1.beta4 - lyx-1.6.0beta4 - --enable-build-type=release disables extra debug information (no warnings, debug, assertions, concept-checks and stdlib-debug). mod_nss-1.0.7-8.fc10 -------------------- * Mon Jul 14 18:00:00 2008 Rob Crittenden - 1.0.7-8 - Don't force module de-init during the configuration stage (453508) * Thu Jul 10 18:00:00 2008 Rob Crittenden - 1.0.7-7 - Don't inherit the MP cache in multi-threaded mode (454701) - Don't initialize NSS in each child if SSL isn't configured netmask-2.3.10-1.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Ville Skytt?? - 2.3.10-1 - 2.3.10. notification-daemon-engine-nodoka-0.1.0-3.fc10 ---------------------------------------------- * Wed Jul 16 18:00:00 2008 Martin Sourada - 0.1.0-3 - Don't clip text in message bubbles (rhbz #455617) nss_ldap-261-1.fc10 ------------------- * Wed Jul 16 18:00:00 2008 Nalin Dahyabhai - 261-1 - update to version 261 - remove fuzz from patches perl-IO-Socket-SSL-1.14-1.fc10 ------------------------------ * Wed Jul 16 18:00:00 2008 Paul Howarth - 1.14-1 - Update to latest upstream version: 1.14 - BuildRequire perl(Net::SSLeay) >= 1.21 pygobject2-2.15.1-1.fc10 ------------------------ * Wed Jul 16 18:00:00 2008 Matthew Barnes - 2.15.1-1.fc10 - Update to 2.15.1 - Bump glib2_version to 2.16.0. - Remove ancient automake_version. - Add a pygobject2-codegen subpackage. ruby-RMagick-2.5.2-1.fc10 ------------------------- * Thu Jul 17 18:00:00 2008 Mamoru Tasaka - 2.5.2-1 - 2.5.2 stardict-3.0.1-12.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Caius Chance - 3.0.1-12.fc10 - Resolves: rhbz#455685 (Broken dependency of bonobo-activitation.) subcommander-1.9.93-5.fc10 -------------------------- * Wed Jul 16 18:00:00 2008 Jochen Schmitt 1.9.93-5 - Add forgotten file * Sun Jul 13 18:00:00 2008 Jochen Schmitt 1.9.93-4 - Some more fixes for svn-1.5 * Sun Jul 13 18:00:00 2008 Jochen Schmitt 1.9.93-3 - Rebuild agains new libsvn_ra_dav (#455002) system-config-language-1.3.1-2.fc10 ----------------------------------- * Wed Jul 16 18:00:00 2008 Pravin Satpute - 1.3.1-2 - fix bug 442901 telepathy-sofiasip-0.5.10-1.fc10 -------------------------------- * Wed Jul 16 18:00:00 2008 Brian Pepple - 0.5.10-1 - Update to 0.5.10. - Bump min version of telepathy-glib needed. tog-pegasus-2.7.1-1.fc10 ------------------------ * Tue Jul 15 18:00:00 2008 Vitezslav Crhonek - 2:2.7.1-1 - Update to upstream version 2.7.1 - Fix setElementAt() doesn't copy value of CMPI_char parameter Resolves: #454589 - Fix CMPI MI factories that return errors are unsupported Resolves: #454590 - Fix HTTP 401 responses lack Content-Length headers Resolves: #454591 tomcat-native-1.1.14-1.fc9 -------------------------- * Sat Jul 5 18:00:00 2008 Ville Skytt?? - 1.1.14-1 - 1.1.14. tunctl-1.5-1.fc10 ----------------- * Wed Jul 16 18:00:00 2008 Henrik Nordstrom 1.5-1 - Update to version 1.5 based on separate upstream release vdradmin-am-3.6.2-1.fc9 ----------------------- * Mon Jun 30 18:00:00 2008 Ville Skytt?? - 3.6.2-1 - 3.6.2. wordwarvi-0.19-1.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Hans de Goede 0.19-1 - New upstream release 0.19 xfce4-screenshooter-plugin-1.3.0-1.fc10 --------------------------------------- * Wed Jul 16 18:00:00 2008 Christoph Wickert - 1.3.0-1 - Update to 1.3.0 xinetd-2.3.14-20.fc10 --------------------- * Wed Jul 16 18:00:00 2008 Jan Safranek - 2:2.3.14-20 - fix wrong bind() call (#448069) * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 2:2.3.14-19 - fix sparc fPIE issues xorg-x11-drivers-7.3-8.fc10 --------------------------- * Wed Jul 16 18:00:00 2008 Adam Jackson 7.3-8 - Tee hee, imstt isn't packaged yet. xorg-x11-drv-radeonhd-1.2.1-3.4.20080716git.fc10 ------------------------------------------------ * Wed Jul 16 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.4.20080716git - New snapshot (upstream commit 820187b208ab1ec94a015f07e48abbb381524c89): - 820187b2: Fix hangs when setting up the MC xpa-2.1.8-7.fc10 ---------------- * Tue Jul 15 18:00:00 2008 Sergio Pascual 2.1.8-7 - Minor changes in the patch xscreensaver-5.06-1.fc10 ------------------------ * Thu Jul 17 18:00:00 2008 Mamoru Tasaka - 1:5.06-1 - Update to 5.06 Summary: Added Packages: 7 Removed Packages: 0 Modified Packages: 68 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so checkgmail-1.13-3.fc9.noarch requires perl(FreezeThaw) checkgmail-1.13-3.fc9.noarch requires perl-FreezeThaw claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-CGI-Session-4.20-4.fc9.noarch requires perl(FreezeThaw) perl-Crypt-Simple-0.06-6.fc10.noarch requires perl(FreezeThaw) perl-MLDBM-2.01-6.fc9.noarch requires perl(FreezeThaw) perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-SVK-2.0.2-3.fc9.noarch requires perl(FreezeThaw) ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.i386 requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.x86_64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.ppc requires libtorrent-0.12.1.so linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) linkage-0.1.4-6.fc9.ppc64 requires libtorrent-0.12.1.so()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From drago01 at gmail.com Thu Jul 17 15:06:21 2008 From: drago01 at gmail.com (drago01) Date: Thu, 17 Jul 2008 17:06:21 +0200 Subject: Heads-Up: rb_libtorrent 0.13.x (incompatible API/ABI bump) In-Reply-To: References: <1216091968.9625.13.camel@tuxhugs> <487E9383.8090800@ioa.s.u-tokyo.ac.jp> Message-ID: On Thu, Jul 17, 2008 at 2:06 PM, drago01 wrote: > On Thu, Jul 17, 2008 at 2:34 AM, Mamoru Tasaka > wrote: >> drago01 wrote, at 07/17/2008 06:35 AM +9:00: >>> >>> dbus-c++ is now packaged and built but it still fails to build. >>> >>> Peter can you please have a look at >>> >>> http://code.google.com/p/linkage/issues/detail?id=59&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Opened >>> Did the API between 0.13 -> 0.13.1 ? >>> >> >> This is very similar with >> https://bugzilla.redhat.com/show_bug.cgi?id=454940#c3 and for this issue >> the following can be a workaround: >> ----------------------------------------------------------- >> sed -i \ >> -e 's|\$ac_boost_path/lib|\$libdir|' \ >> -e 's|$ac_boost_path_tmp/lib|\$libdir|' \ >> configure >> ----------------------------------------------------------- >> >> However even after applying this workaround, the build fails at another >> point >> (not specific to x86_64): >> http://koji.fedoraproject.org/koji/taskinfo?taskID=721548 > > OK, thanks I fixed this one too and now it builds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=722171 > But the regular build failed due to a broken dep > ....http://koji.fedoraproject.org/koji/taskinfo?taskID=722185 Fixed this with a hack: http://koji.fedoraproject.org/koji/buildinfo?buildID=56400 and filled bug against w3m (with the fix, but ACLs are closed): http://koji.fedoraproject.org/koji/buildinfo?buildID=56400 From kwade at redhat.com Thu Jul 17 15:25:30 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jul 2008 08:25:30 -0700 Subject: content and beat writers needed for F10 release notes Message-ID: <1216308330.8931.96.camel@calliope.phig.org> Alpha is coming soon and we are light on content. To keep up the pace on the quality and quantity of Fedora release notes, we need all of *you* to start gathering content immediately. https://fedoraproject.org/wiki/Docs/Beats Paul says more here: http://marilyn.frields.org:8080/~paul/wordpress/?p=1066 If you want to take on something different and really cool, add yourself to the beat writers list and take stewardship of a whole area of Fedora technical content. https://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats#Beat_Assignments Questions? #fedora-docs is always open, don't hesitate to ask. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lists at timj.co.uk Thu Jul 17 16:49:12 2008 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 17 Jul 2008 17:49:12 +0100 Subject: Koji web interface slow? Message-ID: <487F7808.2050405@timj.co.uk> Is it just me or has the Fedora Koji web interface been painfully slow recently? From maillist at diffingo.com Thu Jul 17 17:42:03 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 17 Jul 2008 13:42:03 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux Message-ID: <1216316523.11204.0.camel@Diffingo.localdomain> Hi, After the recent SELinux discussion (and the several ones before it), it's pretty clear that users are having problems with SELinux but at the same time SELinux is an important aspect to system security so it isn't going anywhere. Instead of asking to turn SELinux off, let's work towards making SELinux "just work" since that will provide the good user experience and the extra security. I was thinking of ways that Fedora could improve user <--> SELinux interaction, and I thought that creating a kerneloops-like plugin for setroubleshoot would be a good way to collect data about denials. Similar to kerneloops, this would allow for statistics on where denials occur most and that way the policy can be modified accordingly. Ultimately, this leads to a better user experience with Fedora. I took a quick look at the setroubleshoot plugin system and it shouldn't be too hard to get this started but some extra more help would be great. Beyond this it would probably be good to rework the interface of system-config-selinux tool to make it easier to use for the average user. Sure, editing /etc/sysconfig/selinux is easy but the average user doesn't know how and shouldn't have to spend an hour trying to figure it out, especially if this is their first time using Linux. Feedback, ideas and comments are welcome. I'd like to know what you think before starting any work on any of this. Stewart From tcallawa at redhat.com Thu Jul 17 17:47:06 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 Jul 2008 13:47:06 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216316523.11204.0.camel@Diffingo.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> Message-ID: <1216316826.6118.45.camel@localhost.localdomain> On Thu, 2008-07-17 at 13:42 -0400, Stewart Adam wrote: > I was thinking of ways that Fedora could improve user <--> SELinux > interaction, and I thought that creating a kerneloops-like plugin for > setroubleshoot would be a good way to collect data about denials. > Similar to kerneloops, this would allow for statistics on where > denials occur most and that way the policy can be modified > accordingly. Ultimately, this leads to a better user experience with > Fedora. I took a quick look at the setroubleshoot plugin system and it > shouldn't be too hard to get this started but some extra more help > would be great. Great! Do it! :) Keep in mind that like kerneloops, someone should need to know absolutely nothing about SELinux to use it. ~spot From mmcgrath at redhat.com Thu Jul 17 18:21:36 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Jul 2008 13:21:36 -0500 (CDT) Subject: Koji web interface slow? In-Reply-To: <487F7808.2050405@timj.co.uk> References: <487F7808.2050405@timj.co.uk> Message-ID: On Thu, 17 Jul 2008, Tim Jackson wrote: > Is it just me or has the Fedora Koji web interface been painfully slow > recently? > not just you, we're running into database issues and are migrating koji to new hardware next week. -Mike From pemboa at gmail.com Thu Jul 17 18:43:31 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 13:43:31 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216316523.11204.0.camel@Diffingo.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> Message-ID: <16de708d0807171143i49715ebdxf3a2fa318cb5c79b@mail.gmail.com> On Thu, Jul 17, 2008 at 12:42 PM, Stewart Adam wrote: > Hi, > > After the recent SELinux discussion (and the several ones before it), > it's pretty clear that users are having problems with SELinux but at the > same time SELinux is an important aspect to system security so it isn't > going anywhere. Instead of asking to turn SELinux off, let's work > towards making SELinux "just work" since that will provide the good user > experience and the extra security. Seems to me there are three problems in all 1. Some people are lazy 2. Some people want to have more control at all points 3. SELinux does meet unexpected situations > I was thinking of ways that Fedora could improve user <--> SELinux > interaction, and I thought that creating a kerneloops-like plugin for > setroubleshoot would be a good way to collect data about denials. > Similar to kerneloops, this would allow for statistics on where denials > occur most and that way the policy can be modified accordingly. > Ultimately, this leads to a better user experience with Fedora. I took a > quick look at the setroubleshoot plugin system and it shouldn't be too > hard to get this started but some extra more help would be great. > > Beyond this it would probably be good to rework the interface of > system-config-selinux tool to make it easier to use for the average > user. Sure, editing /etc/sysconfig/selinux is easy but the average user > doesn't know how and shouldn't have to spend an hour trying to figure it > out, especially if this is their first time using Linux. > > Feedback, ideas and comments are welcome. I'd like to know what you > think before starting any work on any of this. > > Stewart If you're referring to a an automated/semi-automated opt-in reporter SELinux seems like a great idea to me. I'm guessing at the least it will help with data collection. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dwalsh at redhat.com Thu Jul 17 19:17:03 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Jul 2008 15:17:03 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216316523.11204.0.camel@Diffingo.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> Message-ID: <487F9AAF.2020802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stewart Adam wrote: > Hi, > > After the recent SELinux discussion (and the several ones before it), > it's pretty clear that users are having problems with SELinux but at the > same time SELinux is an important aspect to system security so it isn't > going anywhere. Instead of asking to turn SELinux off, let's work > towards making SELinux "just work" since that will provide the good user > experience and the extra security. > > I was thinking of ways that Fedora could improve user <--> SELinux > interaction, and I thought that creating a kerneloops-like plugin for > setroubleshoot would be a good way to collect data about denials. > Similar to kerneloops, this would allow for statistics on where denials > occur most and that way the policy can be modified accordingly. > Ultimately, this leads to a better user experience with Fedora. I took a > quick look at the setroubleshoot plugin system and it shouldn't be too > hard to get this started but some extra more help would be great. > > Beyond this it would probably be good to rework the interface of > system-config-selinux tool to make it easier to use for the average > user. Sure, editing /etc/sysconfig/selinux is easy but the average user > doesn't know how and shouldn't have to spend an hour trying to figure it > out, especially if this is their first time using Linux. > > Feedback, ideas and comments are welcome. I'd like to know what you > think before starting any work on any of this. > > Stewart > John Dennis designed setroubleshoot to be able to send its messages to an upstream collector, it seems to me that adding a button to report the message upstream would be easy. The problem is where is the upstream infrastructure to handle all the messages. dwalsh at redhat.com. Is probably not a good place. :^) Of course if we took the XML data we could run it through some tools to see if the AVC was fixed by a newer version of policy. audit2why will report when policy is fixed by the current policy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/mq8ACgkQrlYvE4MpobMelwCbBWO87xHrhcR0oXLaCvB9VFOR RvoAn2L1pbj8bmZW2Z2xU72Z8wVLQTzT =CQ+3 -----END PGP SIGNATURE----- From pemboa at gmail.com Thu Jul 17 19:19:07 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 14:19:07 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <487F9AAF.2020802@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> Message-ID: <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stewart Adam wrote: >> Hi, >> >> After the recent SELinux discussion (and the several ones before it), >> it's pretty clear that users are having problems with SELinux but at the >> same time SELinux is an important aspect to system security so it isn't >> going anywhere. Instead of asking to turn SELinux off, let's work >> towards making SELinux "just work" since that will provide the good user >> experience and the extra security. >> >> I was thinking of ways that Fedora could improve user <--> SELinux >> interaction, and I thought that creating a kerneloops-like plugin for >> setroubleshoot would be a good way to collect data about denials. >> Similar to kerneloops, this would allow for statistics on where denials >> occur most and that way the policy can be modified accordingly. >> Ultimately, this leads to a better user experience with Fedora. I took a >> quick look at the setroubleshoot plugin system and it shouldn't be too >> hard to get this started but some extra more help would be great. >> >> Beyond this it would probably be good to rework the interface of >> system-config-selinux tool to make it easier to use for the average >> user. Sure, editing /etc/sysconfig/selinux is easy but the average user >> doesn't know how and shouldn't have to spend an hour trying to figure it >> out, especially if this is their first time using Linux. >> >> Feedback, ideas and comments are welcome. I'd like to know what you >> think before starting any work on any of this. >> >> Stewart >> > > John Dennis designed setroubleshoot to be able to send its messages to > an upstream collector, it seems to me that adding a button to report the > message upstream would be easy. The problem is where is the upstream > infrastructure to handle all the messages. > > dwalsh at redhat.com. Is probably not a good place. I would think not. Does the infrastructure team have any web service or sorts that can accept these log messages? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rnorwood at redhat.com Thu Jul 17 19:55:34 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 17 Jul 2008 15:55:34 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> Message-ID: <20080717155534.0d6141b5@solitude.devel.redhat.com> On Thu, 17 Jul 2008 14:19:07 -0500 "Arthur Pemberton" wrote: > On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh > > John Dennis designed setroubleshoot to be able to send its messages > > to an upstream collector, it seems to me that adding a button to > > report the message upstream would be easy. The problem is where is > > the upstream infrastructure to handle all the messages. > > > > dwalsh at redhat.com. Is probably not a good place. > > > I would think not. Does the infrastructure team have any web service > or sorts that can accept these log messages? Probably not, but it sounds like a fairly easy turbogears project. The data is in XML? Is the format defined anywhere? The app would need to process the XML to check for duplicates, and display the results. If the format is well-defined and we can say "If fields x, y, and z are the same, then this is a duplicate report", then it should be nearly trivial. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From sstarr at platform.com Thu Jul 17 20:07:15 2008 From: sstarr at platform.com (Shawn Starr) Date: Thu, 17 Jul 2008 16:07:15 -0400 Subject: Some initial discussions of a Fedora HPC SIG Message-ID: Hello everyone, There is talk of creating a HPC SIG that will focus on making Fedora HPC/Grid/Cluster ready. It would be great to find out who in Fedora is interested in beginning some discussions. Here's some of my own questions to add to the mix: - How can we make Anaconda support different interconnects? - How do we handle HPC/Grid needs which differ from traditional systems? Using puppet, others? * Should we provide 'sane' defaults needed within a HPC environment out of the box? * Addon packages to modify configurations of other packages? - Which job submission/batch schedulers? more choice is better. - Full OFED integration (Doug Ledford has been working on this) - Provisioning: Multiple methods for provisioning? * Cobbler, Spacewalk, other open source mechanisms? - Packaging of HPC applications/libs * Open MPI, MPICH1/MPICH2?, MVAPICH1/MVAPICH2? * Directory structure - FHS * Using environment-modules or alternatives to allow users to switch between different MPIs etc. - Package Optimization * A lot of people tend to want highly optimized packages such as ATLAS and usually will recompile them against their new processors. Do we just settle on defaults, can't satisfy all people. There are many more questions and getting some initial discussions going will be beneficial to Fedora. -- Shawn Starr Software Developer, Open Source Grid Development Center (OSGDC) Platform Computing 3760 14th Avenue Markham, ON L3R3T7 direct: 905.948.4229 http://www.platform.com From email.ahmedkamal at googlemail.com Thu Jul 17 20:24:45 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 17 Jul 2008 23:24:45 +0300 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <20080717155534.0d6141b5@solitude.devel.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> Message-ID: <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> another idea, is when a denial occurs, and we get this nice balloon, it would contain 2 buttons - AutoFix: automatically attempts changing the offending file's context, as per the recommended action - Exempt: changes the policy such that the offended application runs in an unrestricted selinux domain. IMHO, the policies will never be perfect. Mortals can't really "fix" the policy coz it's too complex. The Exempt is what the end users need, or they turn off the whole thing On Thu, Jul 17, 2008 at 10:55 PM, Robin Norwood wrote: > On Thu, 17 Jul 2008 14:19:07 -0500 > "Arthur Pemberton" wrote: > >> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh >> > John Dennis designed setroubleshoot to be able to send its messages >> > to an upstream collector, it seems to me that adding a button to >> > report the message upstream would be easy. The problem is where is >> > the upstream infrastructure to handle all the messages. >> > >> > dwalsh at redhat.com. Is probably not a good place. >> >> >> I would think not. Does the infrastructure team have any web service >> or sorts that can accept these log messages? > > Probably not, but it sounds like a fairly easy turbogears project. The > data is in XML? Is the format defined anywhere? The app would need to > process the XML to check for duplicates, and display the results. If > the format is well-defined and we can say "If fields x, y, and z are > the same, then this is a duplicate report", then it should be nearly > trivial. > > -RN > > -- > Robin Norwood > Red Hat, Inc. > > "The Sage does nothing, yet nothing remains undone." > -Lao Tzu, Te Tao Ching > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pemboa at gmail.com Thu Jul 17 20:47:14 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 15:47:14 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> Message-ID: <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> On Thu, Jul 17, 2008 at 3:24 PM, Ahmed Kamal wrote: > another idea, is when a denial occurs, and we get this nice balloon, > it would contain 2 buttons > - AutoFix: automatically attempts changing the offending file's > context, as per the recommended action Fair solution, setroubleshoot is normally on the money. > - Exempt: changes the policy such that the offended application runs > in an unrestricted selinux domain. While this would get the job done. It is really a bad idea as it makes having SELinux on useless for most folks -- they might as well just disable it Plus it reminds me of the deny||allow stories i hear about in MS Vista. > IMHO, the policies will never be perfect. Mortals can't really "fix" > the policy coz it's too complex. The Exempt is what the end users > need, or they turn off the whole thing -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dwalsh at redhat.com Thu Jul 17 20:52:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Jul 2008 16:52:45 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> Message-ID: <487FB11D.3070701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ahmed Kamal wrote: > another idea, is when a denial occurs, and we get this nice balloon, > it would contain 2 buttons > - AutoFix: automatically attempts changing the offending file's > context, as per the recommended action > - Exempt: changes the policy such that the offended application runs > in an unrestricted selinux domain. > > IMHO, the policies will never be perfect. Mortals can't really "fix" > the policy coz it's too complex. The Exempt is what the end users > need, or they turn off the whole thing > exempt is coming, (permissive domains) available in Rawhide now. The problem with this is when you get an AVC that really did not block anything. Teaching people to press a button to tell SELinux to disable protection will get them to disable it when a real attack comes a long. Most avc's are caused by mislabled files, leaked or redirected file descriptors, bugs in policy/code. And a hole lot of them can be ignored. As an example, if you run system-config-services from the launch panel. It has stdout redirected to ~/.xsession-errors If you restart a confined domain from this tool, you will generate an avc saying the confined domain tried to write to user_home_t. This is a fairly bogus avc and users should not disable protection since nothing was really blocked. Our job is to figure out how to get rid of the false noice and get to real security problems. We have just added a new access called open. Before we had only read/write. You could get read/write errors from open file descriptors being passed around as explained above. useradd dwalsh > ~/myhome will generate an Read/write avc. This is not some thing to worry about, however if named suddenly got an "open" avc on user_home_t you know you have a problem. Since named should never be opening files in the homedir. > On Thu, Jul 17, 2008 at 10:55 PM, Robin Norwood wrote: >> On Thu, 17 Jul 2008 14:19:07 -0500 >> "Arthur Pemberton" wrote: >> >>> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh >>>> John Dennis designed setroubleshoot to be able to send its messages >>>> to an upstream collector, it seems to me that adding a button to >>>> report the message upstream would be easy. The problem is where is >>>> the upstream infrastructure to handle all the messages. >>>> >>>> dwalsh at redhat.com. Is probably not a good place. >>> >>> I would think not. Does the infrastructure team have any web service >>> or sorts that can accept these log messages? >> Probably not, but it sounds like a fairly easy turbogears project. The >> data is in XML? Is the format defined anywhere? The app would need to >> process the XML to check for duplicates, and display the results. If >> the format is well-defined and we can say "If fields x, y, and z are >> the same, then this is a duplicate report", then it should be nearly >> trivial. >> >> -RN >> >> -- >> Robin Norwood >> Red Hat, Inc. >> >> "The Sage does nothing, yet nothing remains undone." >> -Lao Tzu, Te Tao Ching >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh/sR0ACgkQrlYvE4MpobMunQCdE461uwubJxxsrOPZK1w1pzGv MjYAoMSussoCH57VB6jB21yILPfScviA =cavG -----END PGP SIGNATURE----- From maillist at diffingo.com Thu Jul 17 21:03:12 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 17 Jul 2008 17:03:12 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> Message-ID: <1216328592.4782.0.camel@Diffingo.localdomain> On Thu, 2008-07-17 at 15:47 -0500, Arthur Pemberton wrote: > > While this would get the job done. It is really a bad idea as it makes > having SELinux on useless for most folks -- they might as well just > disable it > > Plus it reminds me of the deny||allow stories i hear about in MS Vista. +1 - The idea of this is to get users to report what's going wrong and get it fixed in the policy instead of exempt/disable which defeats the purpose and trains the user to hit "Exempt" without reading anything. Stewart From maillist at diffingo.com Thu Jul 17 21:05:05 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 17 Jul 2008 17:05:05 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <20080717155534.0d6141b5@solitude.devel.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> Message-ID: <1216328705.4782.2.camel@Diffingo.localdomain> On Thu, 2008-07-17 at 15:55 -0400, Robin Norwood wrote: > > Probably not, but it sounds like a fairly easy turbogears project. The > data is in XML? Is the format defined anywhere? The app would need to > process the XML to check for duplicates, and display the results. If > the format is well-defined and we can say "If fields x, y, and z are > the same, then this is a duplicate report", then it should be nearly > trivial. > > -RN I didn't think of using TurboGears - You're right, so then all that's needed is a (very simple) script, a SQL database. Stewart From Christian.Iseli at unil.ch Thu Jul 17 21:05:26 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Thu, 17 Jul 2008 23:05:26 +0200 Subject: Some initial discussions of a Fedora HPC SIG In-Reply-To: References: Message-ID: <20080717230526.70f4c6d2@ludwig-alpha.unil.ch> On Thu, 17 Jul 2008 16:07:15 -0400, Shawn Starr wrote: > There are many more questions and getting some initial discussions > going will be beneficial to Fedora. I'm interested in HPC. My nits to pick: - hierarchical storage management - petabyte storage management - billions of files - cluster file systems Cheers, Christian From email.ahmedkamal at googlemail.com Thu Jul 17 21:07:02 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 18 Jul 2008 00:07:02 +0300 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216328592.4782.0.camel@Diffingo.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> Message-ID: <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> - Autofix seems like a good idea - Perhaps Exempt button should only appear, if AutoFix doesn't work (not sure how to detect that) - To avoid a system user clicking Exempt, perhaps Exempt should only exempt the application only this time. i.e., when the application is launched again, it will generate a selinux warning again. That way, the user still reports the issue to get it properly fixed, but at the time, has the tools to get his work done and his apps running when he needs them On Fri, Jul 18, 2008 at 12:03 AM, Stewart Adam wrote: > > > On Thu, 2008-07-17 at 15:47 -0500, Arthur Pemberton wrote: >> >> While this would get the job done. It is really a bad idea as it makes >> having SELinux on useless for most folks -- they might as well just >> disable it >> >> Plus it reminds me of the deny||allow stories i hear about in MS Vista. > +1 - The idea of this is to get users to report what's going wrong and > get it fixed in the policy instead of exempt/disable which defeats the > purpose and trains the user to hit "Exempt" without reading anything. > > Stewart > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From cdahlin at redhat.com Thu Jul 17 21:03:56 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 17 Jul 2008 17:03:56 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> Message-ID: <487FB3BC.3030109@redhat.com> Ahmed Kamal wrote: > another idea, is when a denial occurs, and we get this nice balloon, > it would contain 2 buttons > - AutoFix: automatically attempts changing the offending file's > context, as per the recommended action > This is a sharp edge for users to cut themselves on. It would be nice if we would detect when the error was a result of inconsistencies though (such as the file label not matching policy). IMHO, we should be able to do the following: - We should have exempt, which ignores the denial for now. It also flags the issue upstream. Denial messages for the exempt process are then rerouted to a safe place. - Whenever policy-kit is updated, the exemptions are reevaluated and removed if they should be addressed. - We should come up with some secure way of quickly propagating information about known selinux issues, so that denial warnings can be suppressed until a fix is available - There should be more graphical tools for manipulating policy itself. The user should be able to see a list of local policy exceptions they have made. --CJD From ben.lewis at benl.co.uk Thu Jul 17 21:10:42 2008 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Thu, 17 Jul 2008 22:10:42 +0100 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> Message-ID: <487FB552.6020806@benl.co.uk> Ahmed Kamal wrote: > another idea, is when a denial occurs, and we get this nice balloon, > it would contain 2 buttons > - AutoFix: automatically attempts changing the offending file's > context, as per the recommended action > - Exempt: changes the policy such that the offended application runs > in an unrestricted selinux domain. Whilst this can definitely be an option, I would be very, very, wary about putting it on the first screen the user sees, else they will get into the habit of clicking it. Could it be possible, perhaps, to use permissive domains (or whatever they are called) from the .26 kernel inside of s-c-selinux or s-c-services to fulfill this role? > > IMHO, the policies will never be perfect. Mortals can't really "fix" > the policy coz it's too complex. The Exempt is what the end users > need, or they turn off the whole thing > > On Thu, Jul 17, 2008 at 10:55 PM, Robin Norwood wrote: >> On Thu, 17 Jul 2008 14:19:07 -0500 >> "Arthur Pemberton" wrote: >> >>> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh >>>> John Dennis designed setroubleshoot to be able to send its messages >>>> to an upstream collector, it seems to me that adding a button to >>>> report the message upstream would be easy. The problem is where is >>>> the upstream infrastructure to handle all the messages. >>>> >>>> dwalsh at redhat.com. Is probably not a good place. >>> >>> I would think not. Does the infrastructure team have any web service >>> or sorts that can accept these log messages? >> Probably not, but it sounds like a fairly easy turbogears project. The >> data is in XML? Is the format defined anywhere? The app would need to >> process the XML to check for duplicates, and display the results. If >> the format is well-defined and we can say "If fields x, y, and z are >> the same, then this is a duplicate report", then it should be nearly >> trivial. >> >> -RN >> >> -- >> Robin Norwood >> Red Hat, Inc. >> >> "The Sage does nothing, yet nothing remains undone." >> -Lao Tzu, Te Tao Ching >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben_lewis.vcf Type: text/x-vcard Size: 196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From pemboa at gmail.com Thu Jul 17 21:20:56 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 16:20:56 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> Message-ID: <16de708d0807171420s739d1c25jeecac8111abbfc40@mail.gmail.com> On Thu, Jul 17, 2008 at 4:07 PM, Ahmed Kamal wrote: > - Autofix seems like a good idea > - Perhaps Exempt button should only appear, if AutoFix doesn't work > (not sure how to detect that) > - To avoid a system user clicking Exempt, perhaps Exempt should only > exempt the application only this time. i.e., when the application is > launched again, it will generate a selinux warning again. That way, > the user still reports the issue to get it properly fixed, but at the > time, has the tools to get his work done and his apps running when he > needs them While this doesn't avoid the Vistaesque problem, it may be a fair compromise to consider. One more issue however, is there any way to hide the unimportant denials? There are some denials that have no observable side effects. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dtimms at iinet.net.au Thu Jul 17 21:46:44 2008 From: dtimms at iinet.net.au (David Timms) Date: Fri, 18 Jul 2008 07:46:44 +1000 Subject: rakarrack - Guitar Effects Processor In-Reply-To: References: Message-ID: <487FBDC4.2070004@iinet.net.au> Harald Hoyer wrote: > Harald Hoyer wrote: >> Anyone interested to maintain and add this to Fedora? >> >> >> ABOUT >> Rakarrack is a guitar effects processor for GNU / Linux simple and >> easy to use but it contains features that make it unique in this field Was there any takers on making a fedora package for this ? If not I'll use the planetccrma spec, updating to v0.2. Hans: saw your response to HHs next message: is there any special tricks for getting 'realtimeish' apps to work nicely in fedora ? DaveT. From michel.sylvan at gmail.com Thu Jul 17 22:44:38 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 17 Jul 2008 18:44:38 -0400 Subject: Heads-up: rubberband 1.2 API breakage Message-ID: I'm committing vamp-plugins-sdk 1.3 and Rubberband 1.2, the latter of which provides librubberband.so.2 rather than .so.1, to Rawhide. These affected packages link against librubberband.so.1 and need to be rebuild: sonic-visualiser (which I maintain) sooperlooper Also, ardour is listed on Rubber Band's webpage as supporting rubberband, but our package does not use it as yet. Anthony and Hans? Thanks, -- Michel Salim http://hircus.jaiku.com/ From airlied at redhat.com Thu Jul 17 22:53:37 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jul 2008 08:53:37 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> Message-ID: <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: > - Autofix seems like a good idea > - Perhaps Exempt button should only appear, if AutoFix doesn't work > (not sure how to detect that) > - To avoid a system user clicking Exempt, perhaps Exempt should only > exempt the application only this time. i.e., when the application is > launched again, it will generate a selinux warning again. That way, > the user still reports the issue to get it properly fixed, but at the > time, has the tools to get his work done and his apps running when he > needs them > NO NO NO ... DOING IT WRONG. Don't ever ask the user for this kind of info, it would be better to go ping a remote server and download a newer policy than ask the user. The user is not going to have a freaking clue wtf exempting means. Didn't you guys see the Mac vs Windows ADs on TV? kerneloops does it right, opt in, send somewhere useful, next step if somewhere useful has seen the AVC and we knows its safe, maybe send something back saying continue and ignore, but don't involve the user in the mess other than asking for opt-in. Dave. From pemboa at gmail.com Thu Jul 17 22:57:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 17:57:21 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> Message-ID: <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: > On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: >> - Autofix seems like a good idea >> - Perhaps Exempt button should only appear, if AutoFix doesn't work >> (not sure how to detect that) >> - To avoid a system user clicking Exempt, perhaps Exempt should only >> exempt the application only this time. i.e., when the application is >> launched again, it will generate a selinux warning again. That way, >> the user still reports the issue to get it properly fixed, but at the >> time, has the tools to get his work done and his apps running when he >> needs them >> > > NO NO NO ... DOING IT WRONG. > > Don't ever ask the user for this kind of info, it would be better to go > ping a remote server and download a newer policy than ask the user. Well I think in his suggested use case, he's assuming a genuine bug in the policy which hasn't yet been fixed. > The user is not going to have a freaking clue wtf exempting means. Agreed > Didn't you guys see the Mac vs Windows ADs on TV? That came to mind, was kinda scary. > kerneloops does it right, opt in, send somewhere useful, next step if > somewhere useful has seen the AVC and we knows its safe, maybe send > something back saying continue and ignore, but don't involve the user in > the mess other than asking for opt-in. This may be a good idea. Have the service make a decision to continue deny on temporarily allow based on available knowledge from the server. How much private info if any would be in the average AVC? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From airlied at redhat.com Thu Jul 17 23:00:56 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jul 2008 09:00:56 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> Message-ID: <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> On Thu, 2008-07-17 at 17:57 -0500, Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: > > On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: > >> - Autofix seems like a good idea > >> - Perhaps Exempt button should only appear, if AutoFix doesn't work > >> (not sure how to detect that) > >> - To avoid a system user clicking Exempt, perhaps Exempt should only > >> exempt the application only this time. i.e., when the application is > >> launched again, it will generate a selinux warning again. That way, > >> the user still reports the issue to get it properly fixed, but at the > >> time, has the tools to get his work done and his apps running when he > >> needs them > >> > > > > NO NO NO ... DOING IT WRONG. > > > > Don't ever ask the user for this kind of info, it would be better to go > > ping a remote server and download a newer policy than ask the user. > > Well I think in his suggested use case, he's assuming a genuine bug in > the policy which hasn't yet been fixed. Even so, don't let the user know, clearly they won't do the right thing, and you end up training them with the wrong behaviour. stop thinking of the user being someone who knows or cares what a policy/selinux or an exemption is. > > > The user is not going to have a freaking clue wtf exempting means. > > Agreed > > > Didn't you guys see the Mac vs Windows ADs on TV? > > That came to mind, was kinda scary. > > > > kerneloops does it right, opt in, send somewhere useful, next step if > > somewhere useful has seen the AVC and we knows its safe, maybe send > > something back saying continue and ignore, but don't involve the user in > > the mess other than asking for opt-in. > > This may be a good idea. Have the service make a decision to continue > deny on temporarily allow based on available knowledge from the > server. > > How much private info if any would be in the average AVC? Good point I am reminded of some of those totem backtraces with porn movies in the backtrace :) Dave. From pemboa at gmail.com Thu Jul 17 23:15:50 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 18:15:50 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> Message-ID: <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie wrote: > Even so, don't let the user know, clearly they won't do the right thing, > and you end up training them with the wrong behaviour. stop thinking of > the user being someone who knows or cares what a policy/selinux or an > exemption is. While I agree with your statement as is, it is my unverified suspicion that 'fedora user' is significantly different from 'user'. Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think we may be able to expect a bit more from the average Fedora user... which leads me to another idea. Would probably be great if we could have all AVCs copied easily to a central machine for those who use Fedora in enterprise type environments. Example: - Emplyee A does something acceptable, encounters and AVC - AVC reported to sysadmin - Auto fix attempts fail - request denied - sysadmin reviews, decided to allow all such AVCs then - Emplyee A does same acceptable thing, encounters and AVC - AVC reported to sysadmin - activity found whitelisted - auto fix tool allows But that may be overkill. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From abartlet at samba.org Thu Jul 17 23:19:53 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 18 Jul 2008 09:19:53 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> Message-ID: <1216336793.3657.14.camel@naomi.s4.naomi.abartlet.net> On Fri, 2008-07-18 at 09:00 +1000, Dave Airlie wrote: > On Thu, 2008-07-17 at 17:57 -0500, Arthur Pemberton wrote: > > On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: > > > kerneloops does it right, opt in, send somewhere useful, next step if > > > somewhere useful has seen the AVC and we knows its safe, maybe send > > > something back saying continue and ignore, but don't involve the user in > > > the mess other than asking for opt-in. > > > > This may be a good idea. Have the service make a decision to continue > > deny on temporarily allow based on available knowledge from the > > server. > > > > How much private info if any would be in the average AVC? > > Good point I am reminded of some of those totem backtraces with porn > movies in the backtrace :) Perhaps flag backtraces including files covered by (Fedora) RPMs differently to backtraces that reference user files (and specific other files, like .xsession-errors)? (and yes, I realise this might be difficult to do, but is probably the only sane line between private and not-so-private files on a system). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From airlied at redhat.com Thu Jul 17 23:21:47 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jul 2008 09:21:47 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> Message-ID: <1216336907.4965.8.camel@clockmaker.usersys.redhat.com> On Thu, 2008-07-17 at 18:15 -0500, Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie wrote: > > Even so, don't let the user know, clearly they won't do the right thing, > > and you end up training them with the wrong behaviour. stop thinking of > > the user being someone who knows or cares what a policy/selinux or an > > exemption is. > > While I agree with your statement as is, it is my unverified suspicion > that 'fedora user' is significantly different from 'user'. > > Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think > we may be able to expect a bit more from the average Fedora user... > > which leads me to another idea. Would probably be great if we could > have all AVCs copied easily to a central machine for those who use > Fedora in enterprise type environments. You know you just contradicted yourself :) If we want Fedora and by inheritance RHEL/CentOS to be useable on enterprise desktops or even consumer desktops we cannot assume we know what a "Fedora user" is. So we shouldn't be basing any decisions on the fact we might think a Fedora user is inherently smarter than an Ubuntu user. > > - Emplyee A does something acceptable, encounters and AVC > - AVC reported to sysadmin > - Auto fix attempts fail > - request denied > - sysadmin reviews, decided to allow all such AVCs > > then > > - Emplyee A does same acceptable thing, encounters and AVC > - AVC reported to sysadmin > - activity found whitelisted > - auto fix tool allows For Enterprise desktops and RHEL something like that is what I would rather see. For non sysadmin maintained desktop, a community AVC dump with some responsible person who can allow/disallow things. Eventually the policy would be updated of course and rolled out. Dave. From email.ahmedkamal at googlemail.com Thu Jul 17 23:26:23 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 18 Jul 2008 02:26:23 +0300 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> Message-ID: <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> I'd say I am a pretty knowledgeable Linux user. However, when I see an AVC denial, and the recommended chcon doesn't fix it, I'm pretty much lost! I need to launch that server or that application NOW, and selinux is stopping that ... and the policy won't be fixed for days, it won't even be fixed at all if that's a 3rd party app! I need something to help me launch my apps if I so choose! a 95% selinux protected system, is so much better than one with it disabled, which what I always seem to end up doing to get my work done! PS: To all security-aholics, helping the user launch his apps and get his work done, is every bit as important as having a well secured system, if not a tad bit more important On Fri, Jul 18, 2008 at 2:15 AM, Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie wrote: >> Even so, don't let the user know, clearly they won't do the right thing, >> and you end up training them with the wrong behaviour. stop thinking of >> the user being someone who knows or cares what a policy/selinux or an >> exemption is. > > While I agree with your statement as is, it is my unverified suspicion > that 'fedora user' is significantly different from 'user'. > > Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think > we may be able to expect a bit more from the average Fedora user... > > which leads me to another idea. Would probably be great if we could > have all AVCs copied easily to a central machine for those who use > Fedora in enterprise type environments. > > Example: > > - Emplyee A does something acceptable, encounters and AVC > - AVC reported to sysadmin > - Auto fix attempts fail > - request denied > - sysadmin reviews, decided to allow all such AVCs > > then > > - Emplyee A does same acceptable thing, encounters and AVC > - AVC reported to sysadmin > - activity found whitelisted > - auto fix tool allows > > But that may be overkill. > > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.com ) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pemboa at gmail.com Thu Jul 17 23:40:24 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 18:40:24 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216336793.3657.14.camel@naomi.s4.naomi.abartlet.net> References: <1216316523.11204.0.camel@Diffingo.localdomain> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <1216336793.3657.14.camel@naomi.s4.naomi.abartlet.net> Message-ID: <16de708d0807171640s639c6622yfbf656997561b4eb@mail.gmail.com> 2008/7/17 Andrew Bartlett : > On Fri, 2008-07-18 at 09:00 +1000, Dave Airlie wrote: >> On Thu, 2008-07-17 at 17:57 -0500, Arthur Pemberton wrote: >> > On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: > >> > > kerneloops does it right, opt in, send somewhere useful, next step if >> > > somewhere useful has seen the AVC and we knows its safe, maybe send >> > > something back saying continue and ignore, but don't involve the user in >> > > the mess other than asking for opt-in. >> > >> > This may be a good idea. Have the service make a decision to continue >> > deny on temporarily allow based on available knowledge from the >> > server. >> > >> > How much private info if any would be in the average AVC? >> >> Good point I am reminded of some of those totem backtraces with porn >> movies in the backtrace :) > > Perhaps flag backtraces including files covered by (Fedora) RPMs > differently to backtraces that reference user files (and specific other > files, like .xsession-errors)? > > (and yes, I realise this might be difficult to do, but is probably the > only sane line between private and not-so-private files on a system). By backtrace I'm assuming you mean AVC. Finding an RPM file is as easy as `rpm -qf` so that's probably a good idea. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Thu Jul 17 23:43:35 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 18:43:35 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216336907.4965.8.camel@clockmaker.usersys.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <1216336907.4965.8.camel@clockmaker.usersys.redhat.com> Message-ID: <16de708d0807171643g645f340ct52189bcc8d6baf72@mail.gmail.com> On Thu, Jul 17, 2008 at 6:21 PM, Dave Airlie wrote: > On Thu, 2008-07-17 at 18:15 -0500, Arthur Pemberton wrote: >> On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie wrote: >> > Even so, don't let the user know, clearly they won't do the right thing, >> > and you end up training them with the wrong behaviour. stop thinking of >> > the user being someone who knows or cares what a policy/selinux or an >> > exemption is. >> >> While I agree with your statement as is, it is my unverified suspicion >> that 'fedora user' is significantly different from 'user'. >> >> Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think >> we may be able to expect a bit more from the average Fedora user... >> >> which leads me to another idea. Would probably be great if we could >> have all AVCs copied easily to a central machine for those who use >> Fedora in enterprise type environments. > > You know you just contradicted yourself :) > > If we want Fedora and by inheritance RHEL/CentOS to be useable on > enterprise desktops or even consumer desktops we cannot assume we know > what a "Fedora user" is. So we shouldn't be basing any decisions on the > fact we might think a Fedora user is inherently smarter than an Ubuntu > user. Fair enough. I wish we had some evidence either way. A lot of decisions seem to be made with the weakest user in mind. >> >> - Emplyee A does something acceptable, encounters and AVC >> - AVC reported to sysadmin >> - Auto fix attempts fail >> - request denied >> - sysadmin reviews, decided to allow all such AVCs >> >> then >> >> - Emplyee A does same acceptable thing, encounters and AVC >> - AVC reported to sysadmin >> - activity found whitelisted >> - auto fix tool allows > > For Enterprise desktops and RHEL something like that is what I would > rather see. For non sysadmin maintained desktop, a community AVC dump > with some responsible person who can allow/disallow things. Agreed, except I'd pluralize your 'person' to 'persons' > Eventually the policy would be updated of course and rolled out. Of course. I'll admit that I do have SELinux disabled on my desktops and testboxes. But if such a tool was implemented, I would enable it if only to help out. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Thu Jul 17 23:46:56 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jul 2008 18:46:56 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> Message-ID: <16de708d0807171646r76c0a3e4rf9c4b08c2f5b50f@mail.gmail.com> On Thu, Jul 17, 2008 at 6:26 PM, Ahmed Kamal wrote: > I'd say I am a pretty knowledgeable Linux user. However, when I see an > AVC denial, and the recommended chcon doesn't fix it, I'm pretty much > lost! I need to launch that server or that application NOW, and > selinux is stopping that ... and the policy won't be fixed for days, > it won't even be fixed at all if that's a 3rd party app! I need > something to help me launch my apps if I so choose! a 95% selinux > protected system, is so much better than one with it disabled, which > what I always seem to end up doing to get my work done! > > PS: To all security-aholics, helping the user launch his apps and get > his work done, is every bit as important as having a well secured > system, if not a tad bit more important While I understand your sentiments, I have problems empathizing with it as I haven't had such a problem with SELinux since FC2. I do agree that having a user be able to launch an important app/service should take precedence, though I am not sure that a 80% SELinux protected machine is better than one with SELinux disabled -- that's debatable I guess. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From airlied at redhat.com Thu Jul 17 23:53:02 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jul 2008 09:53:02 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171646r76c0a3e4rf9c4b08c2f5b50f@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> <16de708d0807171646r76c0a3e4rf9c4b08c2f5b50f@mail.gmail.com> Message-ID: <1216338782.4965.11.camel@clockmaker.usersys.redhat.com> On Thu, 2008-07-17 at 18:46 -0500, Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 6:26 PM, Ahmed Kamal > wrote: > > I'd say I am a pretty knowledgeable Linux user. However, when I see an > > AVC denial, and the recommended chcon doesn't fix it, I'm pretty much > > lost! I need to launch that server or that application NOW, and > > selinux is stopping that ... and the policy won't be fixed for days, > > it won't even be fixed at all if that's a 3rd party app! I need > > something to help me launch my apps if I so choose! a 95% selinux > > protected system, is so much better than one with it disabled, which > > what I always seem to end up doing to get my work done! > > > > PS: To all security-aholics, helping the user launch his apps and get > > his work done, is every bit as important as having a well secured > > system, if not a tad bit more important > > While I understand your sentiments, I have problems empathizing with > it as I haven't had such a problem with SELinux since FC2. > > I do agree that having a user be able to launch an important > app/service should take precedence, though I am not sure that a 80% > SELinux protected machine is better than one with SELinux disabled -- > that's debatable I guess. Now how do we distinguish between a user launching his essential work to get done app, and a user being pwned. Both scenarios will look the same and if both scenarios end up in a dialog box with exempt in it, the guess what will happen. Dave. From green at redhat.com Fri Jul 18 00:04:29 2008 From: green at redhat.com (Anthony Green) Date: Thu, 17 Jul 2008 17:04:29 -0700 Subject: rakarrack - Guitar Effects Processor In-Reply-To: <487FBDC4.2070004@iinet.net.au> References: <487FBDC4.2070004@iinet.net.au> Message-ID: <487FDE0D.4070107@redhat.com> David Timms wrote: > > Hans: saw your response to HHs next message: is there any special > tricks for getting 'realtimeish' apps to work nicely in fedora ? > Start with /usr/share/doc/jack-audio-connection-kit-0.109.2/README.Fedora AG From green at redhat.com Fri Jul 18 00:08:06 2008 From: green at redhat.com (Anthony Green) Date: Thu, 17 Jul 2008 17:08:06 -0700 Subject: Heads-up: rubberband 1.2 API breakage In-Reply-To: References: Message-ID: <487FDEE6.8040408@redhat.com> Michel Salim wrote: > Also, ardour is listed on Rubber Band's webpage as supporting > rubberband, but our package does not use it as yet. Anthony and Hans? > > I'm upgrading ardour to 2.5 right now (just fighting with build system). I'll add rubber band as a buildrequire and see what happens. Thanks for pointing this out. AG From kanarip at kanarip.com Fri Jul 18 01:31:25 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 18 Jul 2008 03:31:25 +0200 Subject: Fedora Spins and "where will this end?" In-Reply-To: <487D1135.7020500@when.com> References: <487D0918.3010309@when.com> <487D1135.7020500@when.com> Message-ID: <487FF26D.6050701@kanarip.com> Sebastian Dziallas wrote: > By the way: I think, the question is also: Who is going to use all these > spins? Is the average user downloading three different education spins? > Or isn't he just moving to another distribution with an all-in-one > solution? > I'm tempted to create the almighty Everything Spin - this time, a Live Spin. Kind regards, Jeroen van Meeuwen -kanarip From tagoh at redhat.com Fri Jul 18 02:55:52 2008 From: tagoh at redhat.com (Akira TAGOH) Date: Fri, 18 Jul 2008 11:55:52 +0900 (JST) Subject: Broken buildroot? Message-ID: <20080718.115552.625859878544523612.tagoh@redhat.com> Hi, I'm getting a trouble that the package can't build on koji due to the buildroot error: http://koji.fedoraproject.org/koji/getfile?taskID=723809&name=root.log DEBUG util.py:250: Error: Missing Dependency: libgpm.so.1()(64bit) is needed by package w3m I can't see any obvious deps pulling in w3m from the log. if someone can help me to fix that, that would be appreciated. TIA, -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 18 03:00:13 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 18 Jul 2008 12:00:13 +0900 Subject: Broken buildroot? In-Reply-To: <20080718.115552.625859878544523612.tagoh@redhat.com> References: <20080718.115552.625859878544523612.tagoh@redhat.com> Message-ID: <4880073D.1000403@ioa.s.u-tokyo.ac.jp> Akira TAGOH wrote, at 07/18/2008 11:55 AM +9:00: > Hi, > > I'm getting a trouble that the package can't build on koji > due to the buildroot error: > > http://koji.fedoraproject.org/koji/getfile?taskID=723809&name=root.log > > DEBUG util.py:250: Error: Missing Dependency: libgpm.so.1()(64bit) is needed by package w3m > > I can't see any obvious deps pulling in w3m from the log. if > someone can help me to fix that, that would be appreciated. > > TIA, > -- > Akira TAGOH This is https://bugzilla.redhat.com/show_bug.cgi?id=455734 Regards, Mamoru From petersen at redhat.com Fri Jul 18 03:14:18 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 18 Jul 2008 13:14:18 +1000 Subject: libgpm soname problem In-Reply-To: <20080718.115552.625859878544523612.tagoh@redhat.com> References: <20080718.115552.625859878544523612.tagoh@redhat.com> Message-ID: <48800A8A.5080708@redhat.com> --- gpm.spec 4 Jun 2008 12:06:10 -0000 1.61 +++ gpm.spec 17 Jul 2008 10:23:47 -0000 1.64 : -Version: 1.20.3 -Release: 2%{?dist} +Version: 1.20.5 +Release: 1%{?dist} : -%define LIBVER 1.20.0 +%define LIBVER 2.1.0 If it is intentional it would be nice to have a comment in the changelog at least and a nicer, a headsup on this list since packages will require rebuilding. Jens From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 18 03:23:53 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 18 Jul 2008 12:23:53 +0900 Subject: Broken buildroot? In-Reply-To: <4880073D.1000403@ioa.s.u-tokyo.ac.jp> References: <20080718.115552.625859878544523612.tagoh@redhat.com> <4880073D.1000403@ioa.s.u-tokyo.ac.jp> Message-ID: <48800CC9.7080002@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote, at 07/18/2008 12:00 PM +9:00: > Akira TAGOH wrote, at 07/18/2008 11:55 AM +9:00: >> Hi, >> >> I'm getting a trouble that the package can't build on koji >> due to the buildroot error: >> >> http://koji.fedoraproject.org/koji/getfile?taskID=723809&name=root.log >> >> DEBUG util.py:250: Error: Missing Dependency: libgpm.so.1()(64bit) is >> needed by package w3m >> >> I can't see any obvious deps pulling in w3m from the log. if >> someone can help me to fix that, that would be appreciated. >> >> TIA, >> -- >> Akira TAGOH > > This is > https://bugzilla.redhat.com/show_bug.cgi?id=455734 Now this should be okay. Mamoru From bpepple at fedoraproject.org Wed Jul 16 12:27:54 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 16 Jul 2008 08:27:54 -0400 Subject: FESCo Elections open on July 15th Message-ID: <1216211274.2870.2.camel@kennedy> Hi all, Elections for the Fedora Engineering Steering Committee (FESCo) open at 0001 UTC on 15 July 2008. NOTE: this is a copy of the announcement that was sent to the fedora-announce-list, for those not subscribed). The voting system is available at: https://admin.fedoraproject.org/voting The voting system uses the range voting method: http://en.wikipedia.org/wiki/Range_voting ?Any Fedora Account System (FAS) account holder who has completed the CLA, and has an addition account (like ambassadors, art, cvs*, fedorabugs, l10n-commits, web, etc.) in the FAS is eligible to vote. Voting is open until Monday, July 21st, 2008 23:59 UTC. Election results will be announced shortly afterward. The nominees for the nine open seats, in alphabetical order, are: 1. Josh Boyer 2. Steve Dickson 3. Kevin Fenzi 4. Dennis Gilmore 5. Karsten Hopp 6. Christian Iseli 7. Jon Masters 8. Bill Nottingham 9. Brian Pepple 10. Jon Stanley 11. Jarod Wilson 12. David Woodhouse The nominees have also placed some summary information about their background and goals on the wiki nominations page: https://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations These summaries are also available from the "Info" link next to each candidate's name in the voting system. If you have any problems with voting, report them immediately in the ticket system, at: https://admin.fedoraproject.org/tickets Use the "elections" category when you file your ticket so that it is directed quickly to the appropriate parties. Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 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 mspevack at redhat.com Thu Jul 17 12:30:50 2008 From: mspevack at redhat.com (Max Spevack) Date: Thu, 17 Jul 2008 14:30:50 +0200 (CEST) Subject: FUDCon Brno 2008 Message-ID: (re-sending from fedora-announce-list because I know there are a lot of Fedora developers who don't read that list, and I want our contributors in Europe to see this.) ---- The next FUDCon will take place in Brno, Czech Republic, from September 5 - 7, 2008. The main conference day and social event will be on Saturday (to attract the most people), with hackfest days on Friday and Sunday. FUDCon is always free to attend, no matter where in the world it is located. To sign up or get more information, please visit: https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008 If you cannot attend this FUDCon, do not despair! We expect to hold a FUDCon somewhere in Asia or India later in 2008, and in multiple locations worldwide in 2009. --Max _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mmcgrath at redhat.com Fri Jul 18 02:56:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Jul 2008 21:56:27 -0500 (CDT) Subject: Outage Notification - 2008-07-22 04:59 UTC (MAJOR) Message-ID: There will be an outage starting at 2008-07-22 04:59 UTC, which will last approximately 10 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-07-22 04:59 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Fedora Hosted Talk Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/705 Reason for Outage: Re-migrating db1 to its new hardware (memory issues have hopefully been resolved). Moving koji database from db2 to a dedicated new server, db3. The db1 outage will cause the wiki and smolt to be offline for no longer then an hour. The koji move will cause the buildsystem (and whatever depends on the build system) to be down for between 8 and 10 hours. We haven't padded the outage so if something goes wrong, we'll have to abort and re-schedule it for another time. Likely the next night so be prepared. Also please make sure any builds you complete any builds prior to the time of the outage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From martin.langhoff at gmail.com Fri Jul 18 04:20:35 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 18 Jul 2008 16:20:35 +1200 Subject: Strange mock behaviour - buildrequires in the host? Message-ID: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> Hi, while building some packages for the OLPC XS I am seeing some odd behaviour from Mock. I am not certain whether this is expected... 1 - The F9 host had httpd installed (unbeknownst to me) 2 - The install script in the package was (wrongly) trying to do install -o apache /file - which errored out "no such user" 3 - Adding a BuildRequires to the spec file fixed the problem - mock installed httpd in the chroot - however, install would still fail as it was not running as root. 4 - I spotted httpd on the host and removed it. I can no longer build the package - "httpd is needed by ds-backup-x-y-z..." There are 2 weird things in here for me: - In step 4 - the host environment not having httpd should not affect the build chroot. - In step 3, I was expecting the rpmbuild running the "install" target inside mock to be using fakeroot or something similar. Apologies in advance if these questions are basic - a review of the Mock wiki and man pages did not help, and my rpm packaging skills have last been used in late 2000. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From paul at all-the-johnsons.co.uk Fri Jul 18 10:00:12 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 18 Jul 2008 11:00:12 +0100 Subject: Heads up - Mono Message-ID: <1216375212.21361.3.camel@T7.Linux> Hi, I'm expecting the next beta of Mono to hit the servers today. There are quite a few changes since 1.9.1-2, so please be aware that things may be broken and need rebuilding. Sorry about that. In the words of the good book "Normal service will be resumed just as soon as we know what normal is anyway" Also, please note that as of Mono 2.0, the licence changes to MIT rather that the mix and match that it currently is. This is happening right across the mono family as of version 2 (though probably not for the likes of gtk-sharp2 and gnome-sharp) TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 laxathom at fedoraproject.org Fri Jul 18 10:17:10 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 18 Jul 2008 12:17:10 +0200 Subject: Heads up - Mono In-Reply-To: <1216375212.21361.3.camel@T7.Linux> References: <1216375212.21361.3.camel@T7.Linux> Message-ID: <62bc09df0807180317t529ca854ic537a3e1cbaae7a3@mail.gmail.com> 2008/7/18 Paul : > Hi, > > I'm expecting the next beta of Mono to hit the servers today. There are > quite a few changes since 1.9.1-2, so please be aware that things may be > broken and need rebuilding. > > Sorry about that. In the words of the good book "Normal service will be > resumed just as soon as we know what normal is anyway" > > Also, please note that as of Mono 2.0, the licence changes to MIT rather > that the mix and match that it currently is. This is happening right > across the mono family as of version 2 (though probably not for the > likes of gtk-sharp2 and gnome-sharp) > > I think you should wait that the Buildsys outage pass first. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at erwinrol.com Fri Jul 18 11:03:23 2008 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 18 Jul 2008 13:03:23 +0200 Subject: gtester-report in F9 Message-ID: <1216379003.1074.168.camel@eir.home.erwinrol.com> Hello all, on my system /usr/bin/gtester-report (part of glib2-devel-2.16.4-1.fc9.x86_64) is not executable, it can only be run with "python /usr/bin/gtester-report". Is this intentional, or should it be +x ? TIA, Erwin From drago01 at gmail.com Fri Jul 18 11:16:37 2008 From: drago01 at gmail.com (drago01) Date: Fri, 18 Jul 2008 13:16:37 +0200 Subject: gtester-report in F9 In-Reply-To: <1216379003.1074.168.camel@eir.home.erwinrol.com> References: <1216379003.1074.168.camel@eir.home.erwinrol.com> Message-ID: On Fri, Jul 18, 2008 at 1:03 PM, Erwin Rol wrote: > Hello all, > > on my system /usr/bin/gtester-report (part of > glib2-devel-2.16.4-1.fc9.x86_64) is not executable, it can only be run > with "python /usr/bin/gtester-report". Is this intentional, or should it > be +x ? looks like a bug From rawhide at fedoraproject.org Fri Jul 18 11:29:08 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 18 Jul 2008 11:29:08 +0000 (UTC) Subject: rawhide report: 20080718 changes Message-ID: <20080718112908.8C70D209D9A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080717/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080718/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package dnrd A caching, forwarding DNS proxy server New package ocaml-bitstring OCaml library for matching and constructing bitstrings New package padauk-fonts Padauk font for Burmese and the Myanmar script New package python-migrate Schema migration tools for SQLAlchemy New package sitecopy Tool for easily maintaining remote web sites Removed package kdeplasmoids Removed package kickpim Updated Packages: bash-3.2-27.fc10 ---------------- * Thu Jul 17 18:00:00 2008 Roman Rakus - 3.2-27 - Changes in man page - #442018, #445692, #446625, #453409 - Changed patches to satisfy fuzz=0 binutils-2.18.50.0.6-4.fc9 -------------------------- * Wed Jul 16 18:00:00 2008 Jan Kratochvil 2.18.50.0.6-4 - include the `dist' tag in the Release number - libbfd.a symbols visibility is now hidden (for #447426, suggested by Jakub) * Wed Jul 16 18:00:00 2008 Jan Kratochvil 2.18.50.0.6-3 - rebuild libbfd.a with -fPIC for inclusion into shared libraries (#447426) conntrack-tools-0.9.7-2.fc10 ---------------------------- * Wed Jul 16 18:00:00 2008 Paul P. Komkoff Jr - 0.9.7-2 - fix Patch0/%patch. * Wed Jul 16 18:00:00 2008 Paul P. Komkoff Jr - 0.9.7-1 - new upstream version digikam-0.9.4-1.fc10 -------------------- e2tools-0.0.16-11.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 0.0.16-11 - fix license tag echoping-6.0.2-2.fc10 --------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 6.0.2-2 - fix license tag ecryptfs-utils-50-1.fc10 ------------------------ * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway 50-1 - fix license tag efax-0.9a-2.001114.fc10 ----------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway 0.9a-2.001114 - fix license tag eject-2.1.5-12.fc10 ------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway 2.1.5-12 - fix license tag elsa-1.4-4.fc10 --------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 1.4-4 - fix license tag emacs-nxml-mode-0.20041004-7.fc10 --------------------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 0.20041004-7 - fix license tag epiphany-extensions-2.22.1-3.fc9 -------------------------------- * Thu Jul 17 18:00:00 2008 Christopher Aillon - 2.22.1-3 - Rebuild against newer gecko erlang-esdl-0.96.0626-4.fc10 ---------------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 0.96.0626-4 - fix license tag esound-0.2.39-2.fc10 -------------------- * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway 1:0.2.39-2 - fix license tag facter-1.5.0-3.fc10 ------------------- * Thu Jul 17 18:00:00 2008 David Lutterkort - 1.5.0-3 - Change 'mkdir' in install to 'mkdir -p' * Thu Jul 17 18:00:00 2008 David Lutterkort - 1.5.0-2 - Remove files that were listed twice in files section * Mon May 19 18:00:00 2008 James Turnbull - 1.5.0-1 - New version - Added util and plist files gpm-1.20.5-1.fc10 ----------------- * Thu Jul 17 18:00:00 2008 Zdenek Prikryl - 1.20.5-1 - Updated to 1.20.5 - Removed doc patch - Removed lisp stuff, it is part of emacs-common now - Spec clean up highlight-2.6.11-1.fc10 ----------------------- * Thu Jul 17 18:00:00 2008 Jochen Schmitt 2.6.11-1 - New upstream release koffice-1.9.95.9-1.fc10 ----------------------- * Thu Jul 17 18:00:00 2008 Rex Dieter 1.9.95.9-1 - koffice-1.9.95.9 - fix pkg interdependencies, multilib issues ktechlab-0.3.69-8.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Kevin Kofler - 0.3.69-8 - fix gcc42 patch to actually apply (remove hunk already applied in 0.3.69) - adapt Debian g++ 4.3 patch by Georges Khaznadar * Mon Feb 25 17:00:00 2008 Chitlesh Goorah - 0.3.69-7 - fixed for KDE4 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.3.69-6 - Autorebuild for GCC 4.3 libdrm-2.4.0-0.15.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Kristian H??gsberg - 2.4.0-0.15 - Avoid shared-core when doing make install so we don't install kernel header files. Drop kernel header files from -devel pkg files list. * Thu Jul 17 18:00:00 2008 Dave Airlie 2.4.0-0.14 - kernel headers now installs somes of these files for us liberation-fonts-1.04-1.fc10 ---------------------------- * Thu Jul 17 18:00:00 2008 Caius Chance - 1.04-1.fc10 - Resolves: rhbz#455717 (Update sources to version 1.04.) - Improved .spec file. libsemanage-2.0.25-3.fc10 ------------------------- * Tue Jun 17 18:00:00 2008 Dan Walsh - 2.0.25-3 - Another fix for genhomedircon * Wed May 28 18:00:00 2008 Tom "spot" Callaway - 2.0.25-2 - fix license tag linkage-0.2.0-1.fc10 -------------------- * Wed Jul 16 18:00:00 2008 Adel Gadllah 0.2.0-1 - Update to 0.2.0 pcmanfm-0.5-1.fc10 ------------------ * Thu Jul 17 18:00:00 2008 Mamoru Tasaka - 0.5-1 - 0.5 perl-BDB-1.7-1.fc10 ------------------- * Thu Jul 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.7-1 - Update to 1.7 perl-Event-RPC-1.00-1.fc10 -------------------------- * Thu Jul 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.00-1 - Update to 1.00 perl-FileHandle-Unget-0.1622-1.fc10 ----------------------------------- * Thu Jul 17 18:00:00 2008 Paul Howarth 0.1622-1 - Update to 0.1622 - BuildRequire perl(Test::More) - Unget.pm permissions no longer need fixing pixman-0.11.8-1.fc10 -------------------- * Thu Jul 17 18:00:00 2008 Soren Sandmann 0.11.8-1 - Upgrade to 0.11.8. Drop altivec patch. python-2.5.1-30.fc10 -------------------- * Thu Jul 17 18:00:00 2008 Jeremy Katz - 2.5.1-30 - Fix up the build for new rpm - And actually build against db4-4.7 (#455170) qgit-2.2-1.fc10 --------------- * Thu Jul 17 18:00:00 2008 Dan Horak 2.2-1 - update to upstream version 2.2 rubberband-1.2-1.fc10 --------------------- * Thu Jul 17 18:00:00 2008 Michel Alexandre Salim - 1.2-1 - Update to 1.2 scim-1.4.7-28.fc10 ------------------ * Thu Jul 17 18:00:00 2008 Huang Peng - 1.4.7-28.fc10 - add patch scim-1.4.7-menu-pos.patch to fix bug 444711. * Thu Jul 17 18:00:00 2008 Huang Peng - 1.4.7-27.fc10 - add patch scim-1.4.7-timeout.patch to fix bug 444150. - add patch scim-1.4.7-trayicon.patch to fix bug 447848. seamonkey-1.1.11-1.fc9 ---------------------- * Tue Jul 15 18:00:00 2008 Christopher Aillon - 1.1.11-1 - Update to 1.1.11 speech-dispatcher-0.6.6-17.fc10 ------------------------------- tellico-1.3.3-1.fc10 -------------------- * Thu Jul 17 18:00:00 2008 Jos?? Matos - 1.3.3-1 - update to 1.3.3 vamp-plugin-sdk-1.3-1.fc10 -------------------------- * Thu Jul 17 18:00:00 2008 Michel Alexandre Salim - 1.3-1 - Update to 1.3 w3m-0.5.2-11.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Mamoru Tasaka - 0.5.2-11 - Add BR: lynx which provides "text-www-browser" virtual Provides to avoid BR dependency loop between gtk2-devel and w3m (shorter name wins the game with yum) Proposed by drago01 rh#455734 xenner-0.40-2.fc10 ------------------ * Thu Jul 17 18:00:00 2008 Gerd Hoffmann - 0.40-2.fc10 - fix smp on 64-bit. * Thu Jul 17 18:00:00 2008 Gerd Hoffmann - 0.40-1.fc10 - update to version 0.40 * rework xenner <=> emu interfaces. * emu*.elf symbol tables not needed any more. * usual set of bug fixes. - drop debuginfo hack. Summary: Added Packages: 5 Removed Packages: 2 Modified Packages: 38 Broken deps for i386 ---------------------------------------------------------- aalib-1.4.0-0.15.rc5.fc9.i386 requires libgpm.so.1 aalib-libs-1.4.0-0.15.rc5.fc9.i386 requires libgpm.so.1 apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 ekg2-core-0.2-0.3.rc1.fc10.i386 requires libgpm.so.1 epiphany-extensions-2.22.1-3.fc9.i386 requires gecko-libs = 0:1.9.0.1 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sectool-0.8.0-1.fc10.i386 requires librpm-4.4.so sectool-0.8.0-1.fc10.i386 requires librpmio-4.4.so sonic-visualiser-1.2-1.fc9.i386 requires libvamp-hostsdk.so.2.0.0 sonic-visualiser-1.2-1.fc9.i386 requires librubberband.so.1 sooperlooper-1.6.2-1.fc9.i386 requires librubberband.so.1 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.i386 requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.i386 requires libgpm.so.1 xaos-3.2.3-3.fc9.i386 requires libgpm.so.1 xawtv-3.95-8.fc9.i386 requires libgpm.so.1 xemacs-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-nox-21.5.28-8.fc10.i386 requires libgpm.so.1 zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- aalib-1.4.0-0.15.rc5.fc9.x86_64 requires libgpm.so.1()(64bit) aalib-libs-1.4.0-0.15.rc5.fc9.i386 requires libgpm.so.1 aalib-libs-1.4.0-0.15.rc5.fc9.x86_64 requires libgpm.so.1()(64bit) apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) ekg2-core-0.2-0.3.rc1.fc10.x86_64 requires libgpm.so.1()(64bit) epiphany-extensions-2.22.1-3.fc9.x86_64 requires gecko-libs = 0:1.9.0.1 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.x86_64 requires librpm-4.4.so()(64bit) sonic-visualiser-1.2-1.fc9.x86_64 requires libvamp-hostsdk.so.2.0.0()(64bit) sonic-visualiser-1.2-1.fc9.x86_64 requires librubberband.so.1()(64bit) sooperlooper-1.6.2-1.fc9.x86_64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.x86_64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.x86_64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- aalib-1.4.0-0.15.rc5.fc9.ppc requires libgpm.so.1 aalib-libs-1.4.0-0.15.rc5.fc9.ppc requires libgpm.so.1 aalib-libs-1.4.0-0.15.rc5.fc9.ppc64 requires libgpm.so.1()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 ekg2-core-0.2-0.3.rc1.fc10.ppc requires libgpm.so.1 epiphany-extensions-2.22.1-3.fc9.ppc requires gecko-libs = 0:1.9.0.1 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sectool-0.8.0-1.fc10.ppc requires librpm-4.4.so sectool-0.8.0-1.fc10.ppc requires librpmio-4.4.so sonic-visualiser-1.2-1.fc9.ppc requires libvamp-hostsdk.so.2.0.0 sonic-visualiser-1.2-1.fc9.ppc requires librubberband.so.1 sooperlooper-1.6.2-1.fc9.ppc requires librubberband.so.1 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.ppc requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.ppc requires libgpm.so.1 xaos-3.2.3-3.fc9.ppc requires libgpm.so.1 xawtv-3.95-8.fc9.ppc requires libgpm.so.1 xemacs-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc requires libgpm.so.1 zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- aalib-1.4.0-0.15.rc5.fc9.ppc64 requires libgpm.so.1()(64bit) aalib-libs-1.4.0-0.15.rc5.fc9.ppc64 requires libgpm.so.1()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) ekg2-core-0.2-0.3.rc1.fc10.ppc64 requires libgpm.so.1()(64bit) epiphany-extensions-2.22.1-3.fc9.ppc64 requires gecko-libs = 0:1.9.0.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpmio-4.4.so()(64bit) sectool-0.8.0-1.fc10.ppc64 requires librpm-4.4.so()(64bit) sonic-visualiser-1.2-1.fc9.ppc64 requires libvamp-hostsdk.so.2.0.0()(64bit) sonic-visualiser-1.2-1.fc9.ppc64 requires librubberband.so.1()(64bit) sooperlooper-1.6.2-1.fc9.ppc64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.ppc64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.ppc64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From Axel.Thimm at ATrpms.net Fri Jul 18 12:08:37 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Jul 2008 15:08:37 +0300 Subject: "anaconda" package install selection after the install Message-ID: <20080718120837.GC20338@puariko.nirvana> Hi, previous package management solutions would allow to revisit the eye-of-bird package bundling presented by anaconda during install. The functionality moved from system-config-package to pirut/pup, but now on F9 I can't find it anywhere. Packagekit only offers a complete view with several filters to reduce it a bit, but the anaconda preselected applications were human cherry-picked and represented best-of-breed Fedora bits. Is there a way to get to anaconda's package selection after the install? For example how do I pick support for language XYZ w/o digging into yum groups? BTW is anaconda's selection based on yum groups' mandatory/optional packages? I can't find the language groups, though. -- 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 dwalsh at redhat.com Fri Jul 18 12:51:46 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 08:51:46 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171420s739d1c25jeecac8111abbfc40@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <16de708d0807171420s739d1c25jeecac8111abbfc40@mail.gmail.com> Message-ID: <488091E2.1060709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 4:07 PM, Ahmed Kamal > wrote: >> - Autofix seems like a good idea >> - Perhaps Exempt button should only appear, if AutoFix doesn't work >> (not sure how to detect that) >> - To avoid a system user clicking Exempt, perhaps Exempt should only >> exempt the application only this time. i.e., when the application is >> launched again, it will generate a selinux warning again. That way, >> the user still reports the issue to get it properly fixed, but at the >> time, has the tools to get his work done and his apps running when he >> needs them > > While this doesn't avoid the Vistaesque problem, it may be a fair > compromise to consider. > > One more issue however, is there any way to hide the unimportant > denials? There are some denials that have no observable side effects. > Sure if you could write code to understand that this is a denial without side effect. So far I have not figured out a way to do this. setroubleshoot does have an ignore button also. Which will allow a user to ignore avc's that he has deemed to be not important. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAkeIACgkQrlYvE4MpobNfJgCdGj9Gjsm7SxCBiTYj9GBDzRV5 A+4An1671n1pVR8FE/2d/LvEsuh/svKy =95Y+ -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Jul 18 12:56:21 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 08:56:21 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216336907.4965.8.camel@clockmaker.usersys.redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <1216336907.4965.8.camel@clockmaker.usersys.redhat.com> Message-ID: <488092F5.9070806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Airlie wrote: > On Thu, 2008-07-17 at 18:15 -0500, Arthur Pemberton wrote: >> On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie wrote: >>> Even so, don't let the user know, clearly they won't do the right thing, >>> and you end up training them with the wrong behaviour. stop thinking of >>> the user being someone who knows or cares what a policy/selinux or an >>> exemption is. >> While I agree with your statement as is, it is my unverified suspicion >> that 'fedora user' is significantly different from 'user'. >> >> Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think >> we may be able to expect a bit more from the average Fedora user... >> >> which leads me to another idea. Would probably be great if we could >> have all AVCs copied easily to a central machine for those who use >> Fedora in enterprise type environments. > > You know you just contradicted yourself :) > > If we want Fedora and by inheritance RHEL/CentOS to be useable on > enterprise desktops or even consumer desktops we cannot assume we know > what a "Fedora user" is. So we shouldn't be basing any decisions on the > fact we might think a Fedora user is inherently smarter than an Ubuntu > user. > > >> - Emplyee A does something acceptable, encounters and AVC >> - AVC reported to sysadmin >> - Auto fix attempts fail >> - request denied >> - sysadmin reviews, decided to allow all such AVCs >> >> then >> >> - Emplyee A does same acceptable thing, encounters and AVC >> - AVC reported to sysadmin >> - activity found whitelisted >> - auto fix tool allows > > For Enterprise desktops and RHEL something like that is what I would > rather see. For non sysadmin maintained desktop, a community AVC dump > with some responsible person who can allow/disallow things. > > Eventually the policy would be updated of course and rolled out. > > Dave. > Managed desktops in RHEL/Centos should not even be running sealert these messages should be going to a centralized location for the sysadm to monitor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAkvUACgkQrlYvE4MpobOk9ACbBKW5Ixynklr6RYSiYmQbgpb2 bt4An3+Javb+yz3D5prGRQK+3EuSrv18 =kJIc -----END PGP SIGNATURE----- From limb at jcomserv.net Fri Jul 18 12:59:16 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Jul 2008 07:59:16 -0500 (CDT) Subject: Broken gecko-libs? Message-ID: <20823.198.175.55.5.1216385956.squirrel@mail.jcomserv.net> I had to --exclude yelp, firefox, xulrunner, and gecko-libs. I think there's a problem. . . Jon -- novus ordo absurdum From dwalsh at redhat.com Fri Jul 18 13:03:00 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 09:03:00 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> Message-ID: <48809484.1010008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Pemberton wrote: > On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: >> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: >>> - Autofix seems like a good idea >>> - Perhaps Exempt button should only appear, if AutoFix doesn't work >>> (not sure how to detect that) >>> - To avoid a system user clicking Exempt, perhaps Exempt should only >>> exempt the application only this time. i.e., when the application is >>> launched again, it will generate a selinux warning again. That way, >>> the user still reports the issue to get it properly fixed, but at the >>> time, has the tools to get his work done and his apps running when he >>> needs them >>> >> NO NO NO ... DOING IT WRONG. >> >> Don't ever ask the user for this kind of info, it would be better to go >> ping a remote server and download a newer policy than ask the user. > > Well I think in his suggested use case, he's assuming a genuine bug in > the policy which hasn't yet been fixed. > > >> The user is not going to have a freaking clue wtf exempting means. > > Agreed > >> Didn't you guys see the Mac vs Windows ADs on TV? > > That came to mind, was kinda scary. > > >> kerneloops does it right, opt in, send somewhere useful, next step if >> somewhere useful has seen the AVC and we knows its safe, maybe send >> something back saying continue and ignore, but don't involve the user in >> the mess other than asking for opt-in. > > This may be a good idea. Have the service make a decision to continue > deny on temporarily allow based on available knowledge from the > server. > > How much private info if any would be in the average AVC? > Hostname, filename, potentially username, rpm information. What apps they are running. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAlIQACgkQrlYvE4MpobNqnACgv8xf7VjaM7xG2oZnge4Lf6Ya gwcAnAvi3UyIjC7ryCrHxKGTa1H6cc7D =M+Nj -----END PGP SIGNATURE----- From rdieter at math.unl.edu Fri Jul 18 13:11:21 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Jul 2008 08:11:21 -0500 Subject: consolidating on gnupg2 in F10 References: <20080715154726.GB24550@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > For a really long time now, we've shipped both gnupg and gnupg2 > in Fedora. In fact, in Fedora 9 a relatively standard install will > get both installed. ... > It appears a good number of these can be ported to gnupg2, if not > all of them. Should we wire up a feature page? Imo, yes, it's a worthy goal to get these ported so that at least gnupg(1) doesn't land in any default install. fyi, here's my inquiry upstrem on whether it's possible or a good idea to try dropping gnupg1: http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024485.html (come to think of it, my question there wasn't phrased all too well, but the feedback was insightful) answer: probably not a good idea. So, that leaves consolidating/standardizing on gnupg2, as something still worthwhile. -- Rex From dwalsh at redhat.com Fri Jul 18 13:12:09 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 09:12:09 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <48809484.1010008@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> Message-ID: <488096A9.3060408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel J Walsh wrote: > Arthur Pemberton wrote: >> On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: >>> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: >>>> - Autofix seems like a good idea >>>> - Perhaps Exempt button should only appear, if AutoFix doesn't work >>>> (not sure how to detect that) >>>> - To avoid a system user clicking Exempt, perhaps Exempt should only >>>> exempt the application only this time. i.e., when the application is >>>> launched again, it will generate a selinux warning again. That way, >>>> the user still reports the issue to get it properly fixed, but at the >>>> time, has the tools to get his work done and his apps running when he >>>> needs them >>>> >>> NO NO NO ... DOING IT WRONG. >>> >>> Don't ever ask the user for this kind of info, it would be better to go >>> ping a remote server and download a newer policy than ask the user. >> Well I think in his suggested use case, he's assuming a genuine bug in >> the policy which hasn't yet been fixed. > > >>> The user is not going to have a freaking clue wtf exempting means. >> Agreed > >>> Didn't you guys see the Mac vs Windows ADs on TV? >> That came to mind, was kinda scary. > > >>> kerneloops does it right, opt in, send somewhere useful, next step if >>> somewhere useful has seen the AVC and we knows its safe, maybe send >>> something back saying continue and ignore, but don't involve the user in >>> the mess other than asking for opt-in. >> This may be a good idea. Have the service make a decision to continue >> deny on temporarily allow based on available knowledge from the >> server. > >> How much private info if any would be in the average AVC? > > Hostname, filename, potentially username, rpm information. What apps > they are running. One other concern about report this AVC upstream, is a lot of these avc's are handled properly by the troubleshooter. As an example the ldap query about the mislabled file. Some of the plugins currently have a please bugzilla this context while others are pretty sure they know the problem. So we maybe want to have the report this upstream button, only show up when setroubleshoot is baffled. A lot of bugzilla's I get cut and paste the setroubleshoot window and then I respond by saying "Do what the troubleshouter told you to do!" Closed Not a Bug. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAlqkACgkQrlYvE4MpobP8CACgsXuUINAzvqkZKOSDN/mqF3Ip 56AAoOXEga5M8UyxlVYzcZKquP1C8dsb =pDkk -----END PGP SIGNATURE----- From tagoh at redhat.com Fri Jul 18 13:14:17 2008 From: tagoh at redhat.com (Akira TAGOH) Date: Fri, 18 Jul 2008 22:14:17 +0900 (JST) Subject: Broken buildroot? In-Reply-To: <48800CC9.7080002@ioa.s.u-tokyo.ac.jp> References: <20080718.115552.625859878544523612.tagoh@redhat.com> <4880073D.1000403@ioa.s.u-tokyo.ac.jp> <48800CC9.7080002@ioa.s.u-tokyo.ac.jp> Message-ID: <20080718.221417.519459540419524766.tagoh@redhat.com> >>>>> On Fri, 18 Jul 2008 12:23:53 +0900, >>>>> "MT" == Mamoru Tasaka wrote: MT> Mamoru Tasaka wrote, at 07/18/2008 12:00 PM +9:00: >> Akira TAGOH wrote, at 07/18/2008 11:55 AM +9:00: >>> Hi, >>> >>> I'm getting a trouble that the package can't build on koji >>> due to the buildroot error: >>> >>> http://koji.fedoraproject.org/koji/getfile?taskID=723809&name=root.log >>> >>> DEBUG util.py:250: Error: Missing Dependency: libgpm.so.1()(64bit) is needed by package w3m >>> >>> I can't see any obvious deps pulling in w3m from the log. if >>> someone can help me to fix that, that would be appreciated. >>> >>> TIA, >>> -- Akira TAGOH >> This is >> https://bugzilla.redhat.com/show_bug.cgi?id=455734 MT> Now this should be okay. Thanks. it works now. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dtimms at iinet.net.au Fri Jul 18 14:03:48 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 19 Jul 2008 00:03:48 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <488096A9.3060408@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> Message-ID: <4880A2C4.10107@iinet.net.au> Daniel J Walsh wrote: ... > the problem. So we maybe want to have the report this upstream button, > only show up when setroubleshoot is baffled. > > A lot of bugzilla's I get cut and paste the setroubleshoot window and > then I respond by saying "Do what the troubleshouter told you to do!" > Closed Not a Bug. I would say that generally, the user has no idea what might have suddenly caused the visible denial. eg no recent system changes {ie config files}, updates {the tool could mention which rpm installs / updates have been performed since useful period ago} etc. So having the tool suggest they need to run a sort of "let this happen anyway" command should be considered risky, ie maybe something has got to the point where an untrained {selinux} user will be allowing bad things to happen. That's pretty much like the exempt/fix me IMHO. If se-t-s says that I could make it not object by doing X, should I just do it, or is it potentially telling me to do something that would allow the sort of security breakthrough that selinux is trying to stop in the first place ? It could be an improvement if the se-tools notice an selinux denial to: download new policy if available, applies updated policy, relabel, verifies disk files, before suggesting that the user start performing security altering commands. Also, if the selinux note could capture the offending command eg was a gui click, a file copy, a script, a cron task {with params}, might it then be possible to cause a reissue of the triggering command after a policy update, so that a fix can be confirmed as actually correcting the issue. There could be additional help put into common selinux denials caused by out-of-repo packages like vmware - where the tell tale signs could trigger a message like "the installation of a third party application like X may have modified the file context of /etc/blah in a way that disrupted the correct labelling of the file. If you know that you have recently installed X, you will need to fix the file context by ..." That would give enough information for a user to confidently apply the se-t-s command. se-t-s could also attempt to rate the risk of performing the suggested command ? DaveT. From dtimms at iinet.net.au Fri Jul 18 14:08:49 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 19 Jul 2008 00:08:49 +1000 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <487FB3BC.3030109@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> Message-ID: <4880A3F1.1080609@iinet.net.au> Casey Dahlin wrote: > - There should be more graphical tools for manipulating policy itself. > The user should be able to see a list of local policy exceptions they > have made. And a button to disable one/all exceptions so we might see if the issue has been resolved at the policy publishing level, and once we see that we no longer get the AVC, a button to revert the exception. DaveT. From dwalsh at redhat.com Fri Jul 18 14:21:13 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 10:21:13 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <4880A2C4.10107@iinet.net.au> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> <4880A2C4.10107@iinet.net.au> Message-ID: <4880A6D9.8020906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Timms wrote: > Daniel J Walsh wrote: > ... >> the problem. So we maybe want to have the report this upstream button, >> only show up when setroubleshoot is baffled. >> >> A lot of bugzilla's I get cut and paste the setroubleshoot window and >> then I respond by saying "Do what the troubleshouter told you to do!" >> Closed Not a Bug. > > I would say that generally, the user has no idea what might have > suddenly caused the visible denial. eg no recent system changes {ie > config files}, updates {the tool could mention which rpm installs / > updates have been performed since useful period ago} etc. So having the > tool suggest they need to run a sort of "let this happen anyway" command > should be considered risky, ie maybe something has got to the point > where an untrained {selinux} user will be allowing bad things to happen. > > That's pretty much like the exempt/fix me IMHO. If se-t-s says that I > could make it not object by doing X, should I just do it, or is it > potentially telling me to do something that would allow the sort of > security breakthrough that selinux is trying to stop in the first place ? > > It could be an improvement if the se-tools notice an selinux denial to: > download new policy if available, applies updated policy, relabel, > verifies disk files, before suggesting that the user start performing > security altering commands. > > Also, if the selinux note could capture the offending command eg was a > gui click, a file copy, a script, a cron task {with params}, might it > then be possible to cause a reissue of the triggering command after a > policy update, so that a fix can be confirmed as actually correcting the > issue. > > There could be additional help put into common selinux denials caused by > out-of-repo packages like vmware - where the tell tale signs could > trigger a message like "the installation of a third party application > like X may have modified the file context of /etc/blah in a way that > disrupted the correct labelling of the file. If you know that you have > recently installed X, you will need to fix the file context by ..." > That would give enough information for a user to confidently apply the > se-t-s command. > > se-t-s could also attempt to rate the risk of performing the suggested > command ? > > DaveT. > Well I would argue that setroubleshoot does a lot of this, although it has very limited information. Giving the tool the ability to check if a newer version of selinux-policy would fix the issue would be a huge step forward. I think understanding that vmware hosed up the /etc/services file labeling, is a tougher problem. Maintaining a database of offending third party apps would be tough to maintain, and when vmware fixes the problem we would need to make sure setroubleshooter no longer blamed them. :^) One of the goals of the new doc writer will be to improve the text in the setroubleshooter, to be more humanly readable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiAptkACgkQrlYvE4MpobN7rgCg6EOPEQurXLpOv2xUmTXfi6/t HIQAoJY/CV5dlKzNsH5mg+uXqiDWsFqw =7epY -----END PGP SIGNATURE----- From sstarr at platform.com Fri Jul 18 15:05:45 2008 From: sstarr at platform.com (Shawn Starr) Date: Fri, 18 Jul 2008 11:05:45 -0400 Subject: Some initial discussions of a Fedora HPC SIG Message-ID: Sounds good, That makes four people so far. If other people are interested, let's figure out the best way to keep the community informed. We can setup a Fedora meeting on IRC, but there's no formal SIG yet. Thanks, Shawn. > -----Original Message----- > From: Bryan Che > Sent: Friday, July 18, 2008 9:52 AM > To: fedora-nightlife-list; Shawn Starr > Subject: Re: [Fedora-nightlife-list] Some initial discussions of a > Fedora HPC SIG > > > Hi Shawn, I'd be interested. > > Bryan > > Shawn Starr wrote: > > (This was also sent to fedora-devel-list) > > > > Hello everyone, > > > > There is talk of creating a HPC SIG that will focus on > making Fedora HPC/Grid/Cluster ready. It would be great to > find out who in Fedora is interested in beginning some discussions. > > > > Here's some of my own questions to add to the mix: > > > > - How can we make Anaconda support different interconnects? > > > > - How do we handle HPC/Grid needs which differ from > traditional systems? Using puppet, others? > > * Should we provide 'sane' defaults needed within a HPC > environment out of the box? > > * Addon packages to modify configurations of other packages? > > > > - Which job submission/batch schedulers? more choice is better. > > > > - Full OFED integration (Doug Ledford has been working on this) > > > > - Provisioning: Multiple methods for provisioning? > > * Cobbler, Spacewalk, other open source mechanisms? > > > > - Packaging of HPC applications/libs > > * Open MPI, MPICH1/MPICH2?, MVAPICH1/MVAPICH2? > > * Directory structure - FHS > > * Using environment-modules or alternatives to allow > users to switch between different MPIs etc. > > > > - Package Optimization > > * A lot of people tend to want highly optimized packages > such as ATLAS and usually will recompile them against their > > new processors. Do we just settle on defaults, can't > satisfy all people. > > > > There are many more questions and getting some initial > discussions going will be beneficial to Fedora. > > > > -- > > Shawn Starr > > Software Developer, Open Source Grid Development Center (OSGDC) > > Platform Computing > > 3760 14th Avenue > > Markham, ON L3R3T7 > > direct: 905.948.4229 > > http://www.platform.com > > > > _______________________________________________ > > Fedora-nightlife-list mailing list > > Fedora-nightlife-list > > https://www.redhat.com/mailman/listinfo/fedora-nightlife-list > > -- > Bryan Che > Red Hat, Inc. > 314 Littleton Rd > Westford, MA 01886 > 978-392-3107 > bche at redhat d0t com > From kanarip at kanarip.com Fri Jul 18 15:17:46 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 18 Jul 2008 17:17:46 +0200 Subject: Issue with re- or unbranding In-Reply-To: <20080714150709.GC5020@nostromo.devel.redhat.com> References: <4878CF0A.1000405@kanarip.com> <20080714150709.GC5020@nostromo.devel.redhat.com> Message-ID: <4880B41A.6090606@kanarip.com> Bill Nottingham wrote: > Jeroen van Meeuwen (kanarip at kanarip.com) said: >> Resulting in "Welcome to Fedora" when a machine boots -both Live Media >> and Installation media. >> >> No biggy, but I'm not sure whether replacing the contents of >> /etc/fedora-release (from fedora-release) would give my any trouble, and >> if so, whether we need to replace fedora-release when rebranding as well. > > The idea is that if you're adding packages, etc., you'd be pointing > at your own repos, in which case you already want to modify *-release. > This problem is the case where you just want to rebrand, not including other packages or doing anything non-Fedora. For example, live spins that have not been approved by the Board yet, will want to: %packages -fedora-logos +generic-logos %end and the machine booting the live media would still show "Welcome to Fedora". Can one safely do: %post sed -i -e "s/Fedora/Generic/g" /etc/fedora-release %end ? Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Fri Jul 18 15:22:43 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 18 Jul 2008 17:22:43 +0200 Subject: Issue with re- or unbranding In-Reply-To: References: <4878CF0A.1000405@kanarip.com> <20080714150709.GC5020@nostromo.devel.redhat.com> Message-ID: <4880B543.6070603@kanarip.com> Kevin Kofler wrote: > Bill Nottingham redhat.com> writes: >> The idea is that if you're adding packages, etc., you'd be pointing >> at your own repos, in which case you already want to modify *-release. > > Not necessarily. It is usually enough to add a *-release file, without > modifying fedora-release. Even if you modify some packages, you can easily > override Fedora's versions e.g. by using Epochs. > One could add other *-release RPMs, yeah. Those could just install the RPM GPG keys and .repo files -and be done with it. There'd be rebranding involved but it wouldn't force one to not use the Fedora repositories on such a system. Having to provide capability 'system-release', possibly with a higher nevra, is what I'd call "replacing the fedora-release package" as opposed to just replacing 'fedora-logos', which would mean a challenge for the users attempting rebranding/debranding. Kind regards, Jeroen van Meeuwen -kanarip From pemboa at gmail.com Fri Jul 18 15:24:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 18 Jul 2008 10:24:02 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <48809484.1010008@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> Message-ID: <16de708d0807180824k53d7da4dyf141f715bb673214@mail.gmail.com> On Fri, Jul 18, 2008 at 8:03 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Arthur Pemberton wrote: >> On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie wrote: >>> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote: >>>> - Autofix seems like a good idea >>>> - Perhaps Exempt button should only appear, if AutoFix doesn't work >>>> (not sure how to detect that) >>>> - To avoid a system user clicking Exempt, perhaps Exempt should only >>>> exempt the application only this time. i.e., when the application is >>>> launched again, it will generate a selinux warning again. That way, >>>> the user still reports the issue to get it properly fixed, but at the >>>> time, has the tools to get his work done and his apps running when he >>>> needs them >>>> >>> NO NO NO ... DOING IT WRONG. >>> >>> Don't ever ask the user for this kind of info, it would be better to go >>> ping a remote server and download a newer policy than ask the user. >> >> Well I think in his suggested use case, he's assuming a genuine bug in >> the policy which hasn't yet been fixed. >> >> >>> The user is not going to have a freaking clue wtf exempting means. >> >> Agreed >> >>> Didn't you guys see the Mac vs Windows ADs on TV? >> >> That came to mind, was kinda scary. >> >> >>> kerneloops does it right, opt in, send somewhere useful, next step if >>> somewhere useful has seen the AVC and we knows its safe, maybe send >>> something back saying continue and ignore, but don't involve the user in >>> the mess other than asking for opt-in. >> >> This may be a good idea. Have the service make a decision to continue >> deny on temporarily allow based on available knowledge from the >> server. >> >> How much private info if any would be in the average AVC? >> > Hostname, filename, potentially username, rpm information. What apps > they are running. Okay. So definitely can't be an auto service, must be opt-in -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Fri Jul 18 15:25:34 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 18 Jul 2008 10:25:34 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <488096A9.3060408@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> Message-ID: <16de708d0807180825y51790138h90f48e7646a43204@mail.gmail.com> On Fri, Jul 18, 2008 at 8:12 AM, Daniel J Walsh wrote: > One other concern about report this AVC upstream, is a lot of these > avc's are handled properly by the troubleshooter. As an example the > ldap query about the mislabled file. Some of the plugins currently have > a please bugzilla this context while others are pretty sure they know > the problem. So we maybe want to have the report this upstream button, > only show up when setroubleshoot is baffled. Agreed. I haven't had Setroubleshoot in Centos5 fail me yet. > A lot of bugzilla's I get cut and paste the setroubleshoot window and > then I respond by saying "Do what the troubleshouter told you to do!" > Closed Not a Bug. Seems like a human problem. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From notting at redhat.com Fri Jul 18 15:28:06 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jul 2008 11:28:06 -0400 Subject: Issue with re- or unbranding In-Reply-To: <4880B41A.6090606@kanarip.com> References: <4878CF0A.1000405@kanarip.com> <20080714150709.GC5020@nostromo.devel.redhat.com> <4880B41A.6090606@kanarip.com> Message-ID: <20080718152806.GA24330@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > %post > sed -i -e "s/Fedora/Generic/g" /etc/fedora-release > %end Works for me as a special case; I think redoing another -release package is probably overkill. Bill From pemboa at gmail.com Fri Jul 18 15:28:30 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 18 Jul 2008 10:28:30 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <4880A2C4.10107@iinet.net.au> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> <4880A2C4.10107@iinet.net.au> Message-ID: <16de708d0807180828x495562cdl64713b0264b3118d@mail.gmail.com> On Fri, Jul 18, 2008 at 9:03 AM, David Timms wrote: > Daniel J Walsh wrote: > ... >> >> the problem. So we maybe want to have the report this upstream button, >> only show up when setroubleshoot is baffled. >> >> A lot of bugzilla's I get cut and paste the setroubleshoot window and >> then I respond by saying "Do what the troubleshouter told you to do!" >> Closed Not a Bug. > > I would say that generally, the user has no idea what might have suddenly > caused the visible denial. eg no recent system changes {ie config files}, > updates {the tool could mention which rpm installs / updates have been > performed since useful period ago} etc. So having the tool suggest they need > to run a sort of "let this happen anyway" command should be considered > risky, ie maybe something has got to the point where an untrained {selinux} > user will be allowing bad things to happen. > > That's pretty much like the exempt/fix me IMHO. If se-t-s says that I could > make it not object by doing X, should I just do it, or is it potentially > telling me to do something that would allow the sort of security > breakthrough that selinux is trying to stop in the first place ? > > It could be an improvement if the se-tools notice an selinux denial to: > download new policy if available, applies updated policy, relabel, verifies > disk files, before suggesting that the user start performing security > altering commands. Would this really something that could be done without getting permission from a user? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jkeating at redhat.com Fri Jul 18 17:04:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Jul 2008 13:04:28 -0400 Subject: "anaconda" package install selection after the install In-Reply-To: <20080718120837.GC20338@puariko.nirvana> References: <20080718120837.GC20338@puariko.nirvana> Message-ID: <1216400668.3391.17.camel@localhost.localdomain> On Fri, 2008-07-18 at 15:08 +0300, Axel Thimm wrote: > Hi, > > previous package management solutions would allow to revisit the > eye-of-bird package bundling presented by anaconda during install. The > functionality moved from system-config-package to pirut/pup, but now > on F9 I can't find it anywhere. > > Packagekit only offers a complete view with several filters to reduce > it a bit, but the anaconda preselected applications were human > cherry-picked and represented best-of-breed Fedora bits. > > Is there a way to get to anaconda's package selection after the > install? For example how do I pick support for language XYZ w/o > digging into yum groups? > > BTW is anaconda's selection based on yum groups' mandatory/optional > packages? I can't find the language groups, though. Yum won't show the nonvisible groups as set by comps, but anaconda will show some of them IIRC Right now, package kit doesn't work on comps data for the yum backend IIRC, it uses hardcoded groups. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 skvidal at fedoraproject.org Fri Jul 18 17:04:10 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 18 Jul 2008 13:04:10 -0400 Subject: "anaconda" package install selection after the install In-Reply-To: <1216400668.3391.17.camel@localhost.localdomain> References: <20080718120837.GC20338@puariko.nirvana> <1216400668.3391.17.camel@localhost.localdomain> Message-ID: <1216400650.23800.3.camel@rosebud> On Fri, 2008-07-18 at 13:04 -0400, Jesse Keating wrote: > On Fri, 2008-07-18 at 15:08 +0300, Axel Thimm wrote: > > Hi, > > > > previous package management solutions would allow to revisit the > > eye-of-bird package bundling presented by anaconda during install. The > > functionality moved from system-config-package to pirut/pup, but now > > on F9 I can't find it anywhere. > > > > Packagekit only offers a complete view with several filters to reduce > > it a bit, but the anaconda preselected applications were human > > cherry-picked and represented best-of-breed Fedora bits. > > > > Is there a way to get to anaconda's package selection after the > > install? For example how do I pick support for language XYZ w/o > > digging into yum groups? > > > > BTW is anaconda's selection based on yum groups' mandatory/optional > > packages? I can't find the language groups, though. > > > Yum won't show the nonvisible groups as set by comps, but anaconda will > show some of them IIRC this will show them: yum grouplist hidden -sv From dwalsh at redhat.com Fri Jul 18 17:19:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jul 2008 13:19:01 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807180828x495562cdl64713b0264b3118d@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> <4880A2C4.10107@iinet.net.au> <16de708d0807180828x495562cdl64713b0264b3118d@mail.gmail.com> Message-ID: <4880D085.2050606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arthur Pemberton wrote: > On Fri, Jul 18, 2008 at 9:03 AM, David Timms wrote: >> Daniel J Walsh wrote: >> ... >>> the problem. So we maybe want to have the report this upstream button, >>> only show up when setroubleshoot is baffled. >>> >>> A lot of bugzilla's I get cut and paste the setroubleshoot window and >>> then I respond by saying "Do what the troubleshouter told you to do!" >>> Closed Not a Bug. >> I would say that generally, the user has no idea what might have suddenly >> caused the visible denial. eg no recent system changes {ie config files}, >> updates {the tool could mention which rpm installs / updates have been >> performed since useful period ago} etc. So having the tool suggest they need >> to run a sort of "let this happen anyway" command should be considered >> risky, ie maybe something has got to the point where an untrained {selinux} >> user will be allowing bad things to happen. >> >> That's pretty much like the exempt/fix me IMHO. If se-t-s says that I could >> make it not object by doing X, should I just do it, or is it potentially >> telling me to do something that would allow the sort of security >> breakthrough that selinux is trying to stop in the first place ? >> >> It could be an improvement if the se-tools notice an selinux denial to: >> download new policy if available, applies updated policy, relabel, verifies >> disk files, before suggesting that the user start performing security >> altering commands. > > Would this really something that could be done without getting > permission from a user? > > > No but it would be cool if it could say, this bug is already fixes in the lates selinux-policy available in updates. Please yum -y update selinux-policy-targeted -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiA0IUACgkQrlYvE4MpobN4zwCg6t9FvHIPeke3SHF4WuxzW0vi SfQAoMhaEFv00pnKFuxcgIy0ISAYmysn =VTtw -----END PGP SIGNATURE----- From ed at eh3.com Fri Jul 18 18:11:49 2008 From: ed at eh3.com (Ed Hill) Date: Fri, 18 Jul 2008 14:11:49 -0400 Subject: Some initial discussions of a Fedora HPC SIG In-Reply-To: References: Message-ID: <20080718141149.0adc942b@localhost.localdomain> On Fri, 18 Jul 2008 11:05:45 -0400 "Shawn Starr" wrote: > > That makes four people so far. > > If other people are interested, let's figure out the best way to keep > the community informed. We can setup a Fedora meeting on IRC, but > there's no formal SIG yet. Please count me in. I'm very interested in Fedora for scientific computing and HPC purposes and have used it to build a number of small to mid-sized clusters. And, as much as free time allows, I'd like to see Fedora improve for cluster builders, users, etc... Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vpivaini at cs.helsinki.fi Fri Jul 18 18:39:18 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Fri, 18 Jul 2008 21:39:18 +0300 Subject: Packaging xulrunner extensions: dependencies Message-ID: <200807182139.20027.vpivaini@cs.helsinki.fi> Hi, As we just saw with nspluginwrapper, packaging things dependening on xulrunner/Firefox is a bit problematic. My Mozvoikko package was recently approved by Ville Skytt? (https://bugzilla.redhat.com/show_bug.cgi?id=448215) but he had a good question about the dependencies: "If I understand correctly, using xulrunner-unstable makes this prone to breakage on updates - is there some versioned dependency towards some package that could be used so that it would be easier to notice such cases?" I think the answer here is no. Or is there? We just saw what happens if you hardcode a xulrunner version as a dependency, there will be breakage as soon as xulrunner is updated. I had the Mozvoikko package from that review installed as well and it worked fine after the update of Firefox and xulrunner. So I think I should just leave the xulrunner dependency unversioned and rebuild the mozvoikko package if I notice the extension being broken after a xulrunner update. I also noticed something interesting about xulrunner-devel and xulrunner-devel-unstable. Mozvoikko can't be built just with the stable headers which apparently are in /usr/include/xulrunner-sdk-1.9/stable/. For example it needs mozISpellCheckingEngine.h. This file can be found from two locations, however. The xulrunner-devel package puts it in /usr/include/xulrunner-sdk-1.9/spellchecker/mozISpellCheckingEngine.h and the xulrunner-devel-unstable package puts it in /usr/include/xulrunner-sdk-1.9/unstable/mozISpellCheckingEngine.h. Why are there two copies and is it considered stable or unstable? I'm thinking it's "classified" as unstable, but why is it in the "stable devel package" then as well? Anyway, unless someone gives me a big no about this soon, I'll request CVS and start putting mozvoikko into Rawhide and F-9. If there's breakage at some point, I'll deal with it the best I can. -- Ville-Pekka Vainio From maillist at diffingo.com Fri Jul 18 18:47:29 2008 From: maillist at diffingo.com (Stewart Adam) Date: Fri, 18 Jul 2008 14:47:29 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <4880D085.2050606@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> <4880A2C4.10107@iinet.net.au> <16de708d0807180828x495562cdl64713b0264b3118d@mail.gmail.com> <4880D085.2050606@redhat.com> Message-ID: <1216406849.8889.0.camel@Diffingo.localdomain> On Fri, 2008-07-18 at 13:19 -0400, Daniel J Walsh wrote: > No but it would be cool if it could say, this bug is already fixes in > the lates selinux-policy available in updates. Please > yum -y update selinux-policy-targeted > Or even better, integrate with PackageKit and offer to install it for them! Stewart From rdieter at math.unl.edu Fri Jul 18 19:24:26 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Jul 2008 14:24:26 -0500 Subject: warning: F-9 qt-4.4/kde-4.1 update looming Message-ID: <4880EDEA.10209@math.unl.edu> Just a note to folks to be aware that we're beginning to prepare qt-4.4/kde-4.1 updates for F-9, so bits of these will start seeping into F-9 buildroots soonish. So, if you need to do any F-9 qt4/kde4-related builds over the next week or so, might want to drop me (or other kde-sig'er) a line or pop into #fedora-kde on freenode, so that we can coordinate. -- Rex From limb at jcomserv.net Fri Jul 18 19:27:03 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Jul 2008 14:27:03 -0500 (CDT) Subject: warning: F-9 qt-4.4/kde-4.1 update looming In-Reply-To: <4880EDEA.10209@math.unl.edu> References: <4880EDEA.10209@math.unl.edu> Message-ID: <33083.198.175.55.5.1216409223.squirrel@mail.jcomserv.net> > Just a note to folks to be aware that we're beginning to prepare > qt-4.4/kde-4.1 updates for F-9, so bits of these will start seeping into > F-9 buildroots soonish. > > So, if you need to do any F-9 qt4/kde4-related builds over the next week > or so, might want to drop me (or other kde-sig'er) a line or pop into > #fedora-kde on freenode, so that we can coordinate. Is a rebuild of qt4 apps required, suggested or recommended? > -- Rex > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From rdieter at math.unl.edu Fri Jul 18 19:34:37 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Jul 2008 14:34:37 -0500 Subject: warning: F-9 qt-4.4/kde-4.1 update looming References: <4880EDEA.10209@math.unl.edu> <33083.198.175.55.5.1216409223.squirrel@mail.jcomserv.net> Message-ID: Jon Ciesla wrote: > >> Just a note to folks to be aware that we're beginning to prepare >> qt-4.4/kde-4.1 updates for F-9, so bits of these will start seeping into >> F-9 buildroots soonish. >> >> So, if you need to do any F-9 qt4/kde4-related builds over the next week >> or so, might want to drop me (or other kde-sig'er) a line or pop into >> #fedora-kde on freenode, so that we can coordinate. > > Is a rebuild of qt4 apps required, suggested or recommended? For most, no, same goes for kde4 apps as well. Exceptions include bindings, like PyQt4, qscintilla, WebKit. -- Rex From gnomeuser at gmail.com Fri Jul 18 20:16:25 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 18 Jul 2008 22:16:25 +0200 Subject: Heads up - Mono In-Reply-To: <1216375212.21361.3.camel@T7.Linux> References: <1216375212.21361.3.camel@T7.Linux> Message-ID: <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> 18. jul. 2008 12.00 skrev Paul : > Hi, > > I'm expecting the next beta of Mono to hit the servers today. There are > quite a few changes since 1.9.1-2, so please be aware that things may be > broken and need rebuilding. > > Sorry about that. In the words of the good book "Normal service will be > resumed just as soon as we know what normal is anyway" > > Also, please note that as of Mono 2.0, the licence changes to MIT rather > that the mix and match that it currently is. This is happening right > across the mono family as of version 2 (though probably not for the > likes of gtk-sharp2 and gnome-sharp) Rock.. are you planning to push all of this to F8/F9 once it settles down? -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Jul 18 20:22:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jul 2008 16:22:36 -0400 Subject: Heads up - Mono In-Reply-To: <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> Message-ID: <20080718202236.GA9838@nostromo.devel.redhat.com> David Nielsen (gnomeuser at gmail.com) said: > > I'm expecting the next beta of Mono to hit the servers today. There are > > quite a few changes since 1.9.1-2, so please be aware that things may be > > broken and need rebuilding. > > > > Sorry about that. In the words of the good book "Normal service will be > > resumed just as soon as we know what normal is anyway" > > > > Also, please note that as of Mono 2.0, the licence changes to MIT rather > > that the mix and match that it currently is. This is happening right > > across the mono family as of version 2 (though probably not for the > > likes of gtk-sharp2 and gnome-sharp) > > > Rock.. are you planning to push all of this to F8/F9 once it settles down? I can't imagine breaking the entire ABI and licensing of mono in released distros is a *good* thing. Especially Fedora 8. Bill From gnomeuser at gmail.com Fri Jul 18 20:37:56 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 18 Jul 2008 22:37:56 +0200 Subject: Heads up - Mono In-Reply-To: <20080718202236.GA9838@nostromo.devel.redhat.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> Message-ID: <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> 2008/7/18 Bill Nottingham : > David Nielsen (gnomeuser at gmail.com) said: > > > I'm expecting the next beta of Mono to hit the servers today. There are > > > quite a few changes since 1.9.1-2, so please be aware that things may > be > > > broken and need rebuilding. > > > > > > Sorry about that. In the words of the good book "Normal service will be > > > resumed just as soon as we know what normal is anyway" > > > > > > Also, please note that as of Mono 2.0, the licence changes to MIT > rather > > > that the mix and match that it currently is. This is happening right > > > across the mono family as of version 2 (though probably not for the > > > likes of gtk-sharp2 and gnome-sharp) > > > > > > Rock.. are you planning to push all of this to F8/F9 once it settles > down? > > I can't imagine breaking the entire ABI and licensing of mono in released > distros is a *good* thing. Especially Fedora 8. If we can manage to push it out as one big update, then I don't see how having the same mono stack, with all the fixes that has gone into Mono 2.0 would be a bad thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwoods at redhat.com Fri Jul 18 20:50:28 2008 From: wwoods at redhat.com (Will Woods) Date: Fri, 18 Jul 2008 16:50:28 -0400 Subject: Heads up - Mono In-Reply-To: <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> Message-ID: <1216414228.9803.5.camel@metroid.rdu.redhat.com> On Fri, 2008-07-18 at 22:37 +0200, David Nielsen wrote: > If we can manage to push it out as one big update, then I don't see > how having the same mono stack, with all the fixes that has gone into > Mono 2.0 would be a bad thing. Cramming major-version updates of default system components into a stable release is not something to be done lightly. Fedora 10 is only 3 months away; I think this should wait 'til then, unless someone can convince me it's worth the pain of breaking ABI and rebuilding a whole mess of packages. "It's newer!" isn't a very strong argument. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From jwilson at redhat.com Fri Jul 18 20:59:32 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 18 Jul 2008 16:59:32 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' Message-ID: <200807181659.33092.jwilson@redhat.com> Coming Real Soon Now to rawhide is a build of the final libraw1394 2.0.0, which includes a soname bump, which means a number of packages are going to need to be rebuild. A quick glance with repoquery suggests the list is limited to: unicap gstreamer-plugins-good coriander libfreebob pwlib kdebase kdebase3 dvgrab libiec61883 firecontrol libavc1394 The last four are all my packages, so I'll take care of them. The rest I'd rather leave to their respective maintainers, but can take care of those as well, if so desired (just a simple version-bump and rebuild). Should I attempt to figure out the magic to do a fancy chainbuild, or just let rawhide be busted for a day?... (haha, like its not somehow busted most days anyway... ;) -- Jarod Wilson jwilson at redhat.com From gnomeuser at gmail.com Fri Jul 18 21:12:30 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 18 Jul 2008 23:12:30 +0200 Subject: Heads up - Mono In-Reply-To: <1216414228.9803.5.camel@metroid.rdu.redhat.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> <1216414228.9803.5.camel@metroid.rdu.redhat.com> Message-ID: <1dedbbfc0807181412k29e6e339j497cfcf903f3e44@mail.gmail.com> 18. jul. 2008 22.50 skrev Will Woods : > On Fri, 2008-07-18 at 22:37 +0200, David Nielsen wrote: > > > > If we can manage to push it out as one big update, then I don't see > > how having the same mono stack, with all the fixes that has gone into > > Mono 2.0 would be a bad thing. > > Cramming major-version updates of default system components into a > stable release is not something to be done lightly. Fedora 10 is only 3 > months away; I think this should wait 'til then, unless someone can > convince me it's worth the pain of breaking ABI and rebuilding a whole > mess of packages. > > "It's newer!" isn't a very strong argument. Then how about: what we ship right now in F9 is a preview release to this update, having the same Mono throughout our releases is easier to maintain.. this is aside the bugfixes and memory usage/performance enhancements that come with Mono 2.0, all things that will in the end benefit Fedora and our users. Also pushing newer versions of the stack will enable us to support applications more widely across the stack. It's not like we have no done this before, hell the KDE people AFAIK are doing it right now with KDE 4.1 and the matching QT release (at least if I read their announcement correct, if not forgive me). This is naturally all depending on the opinion of the maintainers in question, I merely asked out of interest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Fri Jul 18 21:31:30 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 18 Jul 2008 17:31:30 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807181659.33092.jwilson@redhat.com> References: <200807181659.33092.jwilson@redhat.com> Message-ID: <200807181731.30567.jwilson@redhat.com> On Friday 18 July 2008 04:59:32 pm Jarod Wilson wrote: > Coming Real Soon Now to rawhide is a build of the final libraw1394 2.0.0, > which includes a soname bump, which means a number of packages are going to > need to be rebuild. A quick glance with repoquery suggests the list is > limited to: > > unicap > gstreamer-plugins-good > coriander > libfreebob > pwlib > kdebase > kdebase3 > dvgrab > libiec61883 > firecontrol > libavc1394 > > The last four are all my packages, so I'll take care of them. The rest I'd > rather leave to their respective maintainers, but can take care of those as > well, if so desired (just a simple version-bump and rebuild). > > Should I attempt to figure out the magic to do a fancy chainbuild, or just > let rawhide be busted for a day?... (haha, like its not somehow busted most > days anyway... ;) So I've been told that something like this should do the job: 1) bump and tag each of the above 2) from within one of the dependent package's devel branch (can be anything in the list, just call it pkg11), do: [jwilson at foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10" Unless someone objects, I'll probably just go ahead and do that this weekend, rather than busticate rawhide even temporarily. -- Jarod Wilson jwilson at redhat.com From dwheeler at dwheeler.com Fri Jul 18 22:12:36 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Fri, 18 Jul 2008 18:12:36 -0400 (EDT) Subject: Koji reports wrong version when building for dist-f8 Message-ID: Heads-up, if you're trying to build for Fedora 8 and your spec file detects WHICH version of Fedora you're compiling for. Fedora's Koji installation currently has a serious configuration bug for dist-f8, at least for scratch builds. When it compiles for dist-f8, it incorrectly thinks it's compiling for dist-f9, instead of correctly compiling for dist-f8. That is, when compiling for Fedora 8, %fedora == 9!!! Proof: If your .spec file has: %if %fedora == 9 ExcludeArch: ppc64 %endif then "rpmbuild -bs X.spec" followed by: koji build --scratch dist-f8 ../SRPMS/...src.rpm will NOT build for ppc64 (wrong!). But change "== 9" to "== 8", and it WILL build for ppc64 (wrong!). Ooooops. Maybe it IS building for 9 instead of 8, but the result is the same: No joy when building for Fedora 8. I have already submitted a bug report: https://fedorahosted.org/fedora-infrastructure/ticket/711 But since this is just before a weekend, I don't know how long it'll be before it's fixed. I thought I'd save some grief for the people working over the weekend. Thanks. --- David A. Wheeler From kevin.kofler at chello.at Fri Jul 18 22:31:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 Jul 2008 22:31:45 +0000 (UTC) Subject: Heads up - Mono References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> <1216414228.9803.5.camel@metroid.rdu.redhat.com> <1dedbbfc0807181412k29e6e339j497cfcf903f3e44@mail.gmail.com> Message-ID: David Nielsen gmail.com> writes: > hell the KDE people AFAIK are doing it right now with KDE 4.1 and the > matching QT release But Qt 4.4 and KDE 4.1 aren't breaking binary compatibility (except for libplasma, but there's only one package which isn't part of KDE affected by this, compiz, and we'll take care of that). Kevin Kofler From kevin.kofler at chello.at Fri Jul 18 22:33:48 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 Jul 2008 22:33:48 +0000 (UTC) Subject: heads up: new libraw1394 so, stuff needs rebuildin' References: <200807181659.33092.jwilson@redhat.com> <200807181731.30567.jwilson@redhat.com> Message-ID: Jarod Wilson redhat.com> writes: > Unless someone objects, I'll probably just go ahead and do that this weekend, > rather than busticate rawhide even temporarily. kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding them. Kevin Kofler From dennis at ausil.us Fri Jul 18 22:36:55 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 18 Jul 2008 17:36:55 -0500 Subject: Koji reports wrong version when building for dist-f8 In-Reply-To: References: Message-ID: <200807181737.20891.dennis@ausil.us> On Friday 18 July 2008, David A. Wheeler wrote: > Heads-up, if you're trying to build for Fedora 8 and your spec > file detects WHICH version of Fedora you're compiling for. > > Fedora's Koji installation currently has a serious configuration bug for > dist-f8, at least for scratch builds. When it compiles for dist-f8, > it incorrectly thinks it's compiling for dist-f9, > instead of correctly compiling for dist-f8. > That is, when compiling for Fedora 8, %fedora == 9!!! > > Proof: If your .spec file has: > %if %fedora == 9 > ExcludeArch: ppc64 > %endif > > then "rpmbuild -bs X.spec" followed by: > koji build --scratch dist-f8 ../SRPMS/...src.rpm > will NOT build for ppc64 (wrong!). > But change "== 9" to "== 8", and it WILL build for ppc64 > (wrong!). Ooooops. > > Maybe it IS building for 9 instead of 8, but the result > is the same: No joy when building for Fedora 8. > > I have already submitted a bug report: > https://fedorahosted.org/fedora-infrastructure/ticket/711 > > But since this is just before a weekend, I don't know how long it'll > be before it's fixed. I thought I'd save > some grief for the people working over the weekend. The bug if it is a bug is not in the buildsystem. but will be in fedora- release where the macros are defined. your usage as pointed out in the ticket is incorrect the buildsystem itself has no knowledge of things like rpm macros. all it knows is what is fed into the chroot and what it gets out. nothing more. if you have the appropriate hardware you should be able to reproduce the issue in mock since thats all koji uses. if you dont have ppc64 you could exclude the arch you have and do a mock build. Please read http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals -- Dennis Gilmore -------------- 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 peter at thecodergeek.com Fri Jul 18 22:46:11 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 18 Jul 2008 15:46:11 -0700 Subject: warning: F-9 qt-4.4/kde-4.1 update looming In-Reply-To: References: <4880EDEA.10209@math.unl.edu> <33083.198.175.55.5.1216409223.squirrel@mail.jcomserv.net> Message-ID: <1216421171.3473.4.camel@tuxhugs> On Fri, 2008-07-18 at 14:34 -0500, Rex Dieter wrote: > For most, no, same goes for kde4 apps as well. > > Exceptions include bindings, like PyQt4, qscintilla, WebKit. Just FYI: The WebKit changes should be committed shortly; so it won't include the Qt bindings any longer as of the next release, as we briefly discussed off-list. :) -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 arjan at infradead.org Fri Jul 18 23:20:50 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 18 Jul 2008 16:20:50 -0700 Subject: latency-policy call for review In-Reply-To: <20080716184420.GC11438@redhat.com> References: <1216222962.3204.54.camel@hughsie-work> <20080716165136.GB15103@nostromo.devel.redhat.com> <20080716184420.GC11438@redhat.com> Message-ID: <20080718162050.5d82613c@infradead.org> On Wed, 16 Jul 2008 14:44:20 -0400 Dave Jones wrote: > My vote would be to rip out all of this from latencypolicy, and have > lp set the sampling rate sysfs knobs. which isn't all that useful since the sampling rate is going away ... (replaced by microaccounting) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From paul at all-the-johnsons.co.uk Fri Jul 18 21:27:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 18 Jul 2008 22:27:50 +0100 Subject: Heads up - Mono In-Reply-To: <20080718202236.GA9838@nostromo.devel.redhat.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> Message-ID: <1216416470.25063.7.camel@T7.Linux> Hi, > > Rock.. are you planning to push all of this to F8/F9 once it settles down? > > I can't imagine breaking the entire ABI and licensing of mono in released > distros is a *good* thing. Especially Fedora 8. F9, yes. F8 dunno. It's a hard one to call... I think it will have to wait quite a while. It may possibly even not happen... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 vnpenguin at vnoss.org Sat Jul 19 07:28:56 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 19 Jul 2008 09:28:56 +0200 Subject: cacti rpm: wrong date in %changelog ? Message-ID: To Mike McGrath: in spec file of cacti 0.8.7b-1 : %changelog * Thu Nov 14 2008 Mike McGrath - 0.8.7b-1 - Upstream released new version Do you mean Nov 14 2007 ? Thanks, -- http://vnoss.org From jmorris at namei.org Sat Jul 19 08:16:41 2008 From: jmorris at namei.org (James Morris) Date: Sat, 19 Jul 2008 18:16:41 +1000 (EST) Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <487FB11D.3070701@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB11D.3070701@redhat.com> Message-ID: On Thu, 17 Jul 2008, Daniel J Walsh wrote: > We have just added a new access called open. Before we had only > read/write. You could get read/write errors from open file descriptors > being passed around as explained above. useradd dwalsh > ~/myhome will > generate an Read/write avc. This is not some thing to worry about, > however if named suddenly got an "open" avc on user_home_t you know you > have a problem. Since named should never be opening files in the homedir. Btw, for those that missed it, I covered the new open perm here: http://james-morris.livejournal.com/31714.html One effect of this is that I think you could say it makes SELinux a lot more Unix-y. - James -- James Morris From martin.langhoff at gmail.com Sat Jul 19 08:47:01 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 19 Jul 2008 20:47:01 +1200 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> Message-ID: <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> On Fri, Jul 18, 2008 at 4:20 PM, Martin Langhoff wrote: > - In step 4 - the host environment not having httpd should not affect > the build chroot. Debugged this -- and mock is not to blame. The build scripts I have first build the source package outsider the mock chroot and then use mock to build the binaries. Any reason rpmbuild -bs checks dependencies? > - In step 3, I was expecting the rpmbuild running the "install" target > inside mock to be using fakeroot or something similar. This is still puzzling. Why does the `make install` in mock not get wrapped by a fakeroot-ish trick? cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Sat Jul 19 08:56:03 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 19 Jul 2008 20:56:03 +1200 Subject: mock --shell error on F9 Message-ID: <46a038f90807190156g4cb6c763m7705f547465f6465@mail.gmail.com> While debugging related problems, I found out that on a vanilla F9, mock -r fedora-9-i386 --shell does not work. On the commandline I get # mount -n -t proc mock_chroot_proc /var/lib/mock/fedora-9-i386/root/proc and the tail of /var/log/messages says kernel: Not cloning cgroup for unused subsystem ns any hint as to what might be afoot? No open bugs against mock seem to match. cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mschwendt at gmail.com Sat Jul 19 09:48:34 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 19 Jul 2008 11:48:34 +0200 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> Message-ID: <20080719114834.0273e605.mschwendt@gmail.com> On Sat, 19 Jul 2008 20:47:01 +1200, Martin Langhoff wrote: > Any reason rpmbuild -bs checks dependencies? Yes. To check that you don't build and publish a src.rpm which has unresolved build dependencies. If you want to skip that check, use -bs --nodeps but be careful. From vnpenguin at vnoss.org Sat Jul 19 09:51:28 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 19 Jul 2008 11:51:28 +0200 Subject: Pungi with x86_64 packages only Message-ID: Hi all, I would like to build a customized CD on FC9 x86_64 with pungi. The problem is I dont know how to get only x86_64 packages. So many i386 packages were there. Any idea for help ? Thanks -- http://vnoss.org From mschwendt at gmail.com Sat Jul 19 11:05:38 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 19 Jul 2008 11:05:38 -0000 Subject: Broken dependencies in Fedora 9 - 2008-07-19 Message-ID: <20080719110538.4437.86430@faldor.intranet> Summary of broken packages (by owner): Jochen AT herr-schmitt.de subcommander-1.2.3-1.fc9.i386 subcommander-1.2.3-1.fc9.ppc subcommander-1.2.3-1.fc9.ppc64 subcommander-1.2.3-1.fc9.x86_64 alexl AT users.sourceforge.net blam-1.8.3-13.fc9.i386 blam-1.8.3-13.fc9.ppc blam-1.8.3-13.fc9.x86_64 allisson AT gmail.com ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.i386 ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.ppc ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.ppc64 ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.x86_64 berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch bnocera AT redhat.com gnome-web-photo-0.3-12.fc9.i386 gnome-web-photo-0.3-12.fc9.ppc gnome-web-photo-0.3-12.fc9.ppc64 gnome-web-photo-0.3-12.fc9.x86_64 dcbw AT redhat.com 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 dwmw2 AT infradead.org ppc64-utils-0.14-2.fc9.ppc64 ebmunson AT us.ibm.com libhugetlbfs-test-1.1-6.fc9.ppc libhugetlbfs-test-1.1-6.fc9.ppc64 libhugetlbfs-test-1.1-6.fc9.x86_64 lsvpd-1.6.4-1.fc9.i386 lsvpd-1.6.4-1.fc9.ppc lsvpd-1.6.4-1.fc9.ppc64 lsvpd-1.6.4-1.fc9.x86_64 karlthered AT gmail.com gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 katzj AT redhat.com livecd-tools-017.1-1.fc9.ppc64 martin.sourada AT gmail.com gxine-0.5.11-17.fc9.i386 gxine-0.5.11-17.fc9.ppc gxine-0.5.11-17.fc9.ppc64 gxine-0.5.11-17.fc9.x86_64 mbarnes AT redhat.com gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc64 gnome-python2-gtkmozembed-2.19.1-16.fc9.x86_64 mtasaka AT ioa.s.u-tokyo.ac.jp kazehakase-0.5.4-6.svn3506_trunk.fc9.i386 kazehakase-0.5.4-6.svn3506_trunk.fc9.ppc kazehakase-0.5.4-6.svn3506_trunk.fc9.ppc64 kazehakase-0.5.4-6.svn3506_trunk.fc9.x86_64 oliver AT linux-kernel.at syck-php-0.61-4.3.fc9.i386 syck-php-0.61-4.3.fc9.ppc syck-php-0.61-4.3.fc9.ppc64 syck-php-0.61-4.3.fc9.x86_64 orion AT cora.nwra.com paraview-3.2.1-6.fc9.i386 paraview-mpi-3.2.1-6.fc9.i386 overholt AT redhat.com emma-2.0-0.5312.2jpp.3.fc9.noarch rnorwood AT redhat.com gnome-packagekit-0.2.3-6.fc9.i386 gnome-packagekit-0.2.3-6.fc9.ppc gnome-packagekit-0.2.3-6.fc9.ppc64 gnome-packagekit-0.2.3-6.fc9.x86_64 rpm AT timj.co.uk rapidsvn-0.9.6-1.fc9.i386 rapidsvn-0.9.6-1.fc9.ppc rapidsvn-0.9.6-1.fc9.ppc64 rapidsvn-0.9.6-1.fc9.x86_64 tscherf AT redhat.com Miro-1.2.4-1.fc9.i386 Miro-1.2.4-1.fc9.ppc Miro-1.2.4-1.fc9.ppc64 Miro-1.2.4-1.fc9.x86_64 wart AT kobold.org cyphesis-selinux-0.5.15-6.fc9.i386 cyphesis-selinux-0.5.15-6.fc9.ppc cyphesis-selinux-0.5.15-6.fc9.ppc64 cyphesis-selinux-0.5.15-6.fc9.x86_64 ====================================================================== Broken packages in fedora-9-i686: blam-1.8.3-13.fc9.i386 requires gecko-libs = 0:1.9 cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 gxine-0.5.11-17.fc9.i386 requires gecko-libs = 0:1.9 rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 syck-php-0.61-4.3.fc9.i386 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc64: cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 gxine-0.5.11-17.fc9.ppc64 requires gecko-libs = 0:1.9 libhugetlbfs-test-1.1-6.fc9.ppc64 requires libhugetlbfs = 0:1.1-6.fc9 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) syck-php-0.61-4.3.fc9.ppc64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc: blam-1.8.3-13.fc9.ppc requires gecko-libs = 0:1.9 cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 gxine-0.5.11-17.fc9.ppc requires gecko-libs = 0:1.9 libhugetlbfs-test-1.1-6.fc9.ppc requires libhugetlbfs = 0:1.1-6.fc9 rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 syck-php-0.61-4.3.fc9.ppc requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-x86_64: 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 requires NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 blam-1.8.3-13.fc9.x86_64 requires gecko-libs = 0:1.9 cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 gxine-0.5.11-17.fc9.x86_64 requires gecko-libs = 0:1.9 libhugetlbfs-test-1.1-6.fc9.x86_64 requires libhugetlbfs = 0:1.1-6.fc9 paraview-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) syck-php-0.61-4.3.fc9.x86_64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-updates-9-i686: Miro-1.2.4-1.fc9.i386 requires gecko-libs = 0:1.9 gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 kazehakase-0.5.4-6.svn3506_trunk.fc9.i386 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.i386 requires libvpd_cxx-2.0.so.1 ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.i386 requires gecko-libs = 0:1.9 subcommander-1.2.3-1.fc9.i386 requires libsvn_ra_dav-1.so.0 ====================================================================== Broken packages in fedora-updates-9-ppc64: Miro-1.2.4-1.fc9.ppc64 requires gecko-libs = 0:1.9 emma-2.0-0.5312.2jpp.3.fc9.noarch requires maven2 gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc64 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 kazehakase-0.5.4-6.svn3506_trunk.fc9.ppc64 requires gecko-libs = 0:1.9 livecd-tools-017.1-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc9.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.ppc64 requires gecko-libs = 0:1.9 subcommander-1.2.3-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-9-ppc: Miro-1.2.4-1.fc9.ppc requires gecko-libs = 0:1.9 gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 kazehakase-0.5.4-6.svn3506_trunk.fc9.ppc requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.ppc requires libvpd_cxx-2.0.so.1 ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.ppc requires gecko-libs = 0:1.9 subcommander-1.2.3-1.fc9.ppc requires libsvn_ra_dav-1.so.0 ====================================================================== Broken packages in fedora-updates-9-x86_64: Miro-1.2.4-1.fc9.x86_64 requires gecko-libs = 0:1.9 gnome-python2-gtkmozembed-2.19.1-16.fc9.x86_64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.x86_64 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 kazehakase-0.5.4-6.svn3506_trunk.fc9.x86_64 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) ruby-gtkmozembed-0.17.0-0.2.rc1.fc9.x86_64 requires gecko-libs = 0:1.9 subcommander-1.2.3-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-testing-9-i686: gnome-packagekit-0.2.3-6.fc9.i386 requires libpackagekit.so.3 ====================================================================== Broken packages in fedora-updates-testing-9-ppc64: gnome-packagekit-0.2.3-6.fc9.ppc64 requires libpackagekit.so.3()(64bit) ====================================================================== Broken packages in fedora-updates-testing-9-ppc: gnome-packagekit-0.2.3-6.fc9.ppc requires libpackagekit.so.3 ====================================================================== Broken packages in fedora-updates-testing-9-x86_64: gnome-packagekit-0.2.3-6.fc9.x86_64 requires libpackagekit.so.3()(64bit) From mschwendt at gmail.com Sat Jul 19 11:18:55 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 19 Jul 2008 11:18:55 -0000 Subject: Broken dependencies in Fedora 8 - 2008-07-19 Message-ID: <20080719111855.4461.12698@faldor.intranet> Summary of broken packages (by owner): berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch cooly AT gnome.eu.org evolution-rss-0.0.8-10.fc8.i386 evolution-rss-0.0.8-10.fc8.ppc evolution-rss-0.0.8-10.fc8.ppc64 evolution-rss-0.0.8-10.fc8.x86_64 dcbw AT redhat.com 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 dchen AT redhat.com zhcon-0.2.6-9.fc8.i386 zhcon-0.2.6-9.fc8.ppc zhcon-0.2.6-9.fc8.ppc64 zhcon-0.2.6-9.fc8.x86_64 dev AT nigelj.com mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch ebmunson AT us.ibm.com libhugetlbfs-test-1.1-4.fc8.i386 libhugetlbfs-test-1.1-4.fc8.ppc libhugetlbfs-test-1.1-4.fc8.ppc64 libhugetlbfs-test-1.1-4.fc8.x86_64 ianweller AT gmail.com mediawiki-HNP-1.1.2-1.fc8.noarch mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch mediawiki-StubManager-1.2.0-1.fc8.noarch konrad AT tylerc.org joda-time-1.5.2-6.tzdata2008c.fc8.noarch oliver AT linux-kernel.at syck-php-0.61-2.fc8.i386 syck-php-0.61-2.fc8.ppc syck-php-0.61-2.fc8.ppc64 syck-php-0.61-2.fc8.x86_64 rjones AT redhat.com ocaml-json-static-0.9.6-5.fc8.i386 ocaml-json-static-0.9.6-5.fc8.ppc ocaml-json-static-0.9.6-5.fc8.x86_64 rmeggins AT redhat.com idm-console-framework-1.1.1-3.fc8.noarch skvidal AT linux.duke.edu yum-tmprepo-1.1.14-4.fc8.noarch yum-verify-1.1.14-4.fc8.noarch ====================================================================== Broken packages in fedora-8-i686: libhugetlbfs-test-1.1-4.fc8.i386 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.i386 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc64: libhugetlbfs-test-1.1-4.fc8.ppc64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc: libhugetlbfs-test-1.1-4.fc8.ppc requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-x86_64: 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 requires NetworkManager-glib = 1:0.7.0-0.5.svn3030.fc8 libhugetlbfs-test-1.1-4.fc8.x86_64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.x86_64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-updates-8-i686: evolution-rss-0.0.8-10.fc8.i386 requires gecko-libs = 0:1.8.1.15 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-ppc64: evolution-rss-0.0.8-10.fc8.ppc64 requires gecko-libs = 0:1.8.1.15 idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-6.tzdata2008c.fc8.noarch requires java > 0:1.5.0 mediawiki-HNP-1.1.2-1.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch requires mediawiki < 0:1.11 mediawiki-StubManager-1.2.0-1.fc8.noarch requires mediawiki >= 0:1.10 perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch requires darcs >= 0:1.0.0 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-ppc: evolution-rss-0.0.8-10.fc8.ppc requires gecko-libs = 0:1.8.1.15 idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-6.tzdata2008c.fc8.noarch requires java > 0:1.5.0 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-8-x86_64: evolution-rss-0.0.8-10.fc8.x86_64 requires gecko-libs = 0:1.8.1.15 yum-tmprepo-1.1.14-4.fc8.noarch requires yum >= 0:3.2.11 yum-verify-1.1.14-4.fc8.noarch requires yum >= 0:3.2.12 ====================================================================== Broken packages in fedora-updates-testing-8-i686: ocaml-json-static-0.9.6-5.fc8.i386 requires ocaml-json-wheel zhcon-0.2.6-9.fc8.i386 requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-ppc64: zhcon-0.2.6-9.fc8.ppc64 requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-ppc: ocaml-json-static-0.9.6-5.fc8.ppc requires ocaml-json-wheel zhcon-0.2.6-9.fc8.ppc requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-x86_64: ocaml-json-static-0.9.6-5.fc8.x86_64 requires ocaml-json-wheel zhcon-0.2.6-9.fc8.x86_64 requires ncurses-libs From martin.sourada at gmail.com Sat Jul 19 12:05:41 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Sat, 19 Jul 2008 14:05:41 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: <20080719110538.4437.86430@faldor.intranet> References: <20080719110538.4437.86430@faldor.intranet> Message-ID: <1216469141.3232.56.camel@pc-notebook> On Sat, 2008-07-19 at 11:05 +0000, Michael Schwendt wrote: > Summary of broken packages (by owner): > martin.sourada AT gmail.com > gxine-0.5.11-17.fc9.i386 > gxine-0.5.11-17.fc9.ppc > gxine-0.5.11-17.fc9.ppc64 > gxine-0.5.11-17.fc9.x86_64 Already pending for stable update [1]. However looking at the problematic deps it seems most of them are caused by recent update of xulrunner. Again! First of all we should review whether all these packages need to depend on precise version of gecko-libs, yesterday I checked that gxine does not and removed the versioned deps. Next, there should be some policy in pushing such updates for stable releases. I mean, what is the point in releasing security update for xulrunner while it cannot be installed due to tons of broken deps? We have chain builds, we have support for multiple package updates, why has xulrunner been rebuilt and pushed only with firefox, epiphany(-extensions), yelp and devhelp [2], and without mentioning it on the -devel(-announce) list? Martin References: [1] https://admin.fedoraproject.org/updates/F9/pending/gxine-0.5.11-18.fc9 [2] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-6518 -------------- 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 drago01 at gmail.com Sat Jul 19 12:20:12 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jul 2008 14:20:12 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: <1216469141.3232.56.camel@pc-notebook> References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> Message-ID: 2008/7/19 Martin Sourada : > On Sat, 2008-07-19 at 11:05 +0000, Michael Schwendt wrote: >> Summary of broken packages (by owner): >> martin.sourada AT gmail.com >> gxine-0.5.11-17.fc9.i386 >> gxine-0.5.11-17.fc9.ppc >> gxine-0.5.11-17.fc9.ppc64 >> gxine-0.5.11-17.fc9.x86_64 > > Already pending for stable update [1]. However looking at the > problematic deps it seems most of them are caused by recent update of > xulrunner. Again! First of all we should review whether all these > packages need to depend on precise version of gecko-libs, yesterday I > checked that gxine does not and removed the versioned deps. > > Next, there should be some policy in pushing such updates for stable > releases. I mean, what is the point in releasing security update for > xulrunner while it cannot be installed due to tons of broken deps? We > have chain builds, they only work in devel. >we have support for multiple package updates, why has > xulrunner been rebuilt and pushed only with firefox, > epiphany(-extensions), yelp and devhelp [2], and without mentioning it > on the -devel(-announce) list? bodhi needs to do dep check before pushing updates. If the updates have broken deps the push should fail. From drago01 at gmail.com Sat Jul 19 12:21:51 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jul 2008 14:21:51 +0200 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: References: <200807181659.33092.jwilson@redhat.com> <200807181731.30567.jwilson@redhat.com> Message-ID: On Sat, Jul 19, 2008 at 12:33 AM, Kevin Kofler wrote: > Jarod Wilson redhat.com> writes: >> Unless someone objects, I'll probably just go ahead and do that this weekend, >> rather than busticate rawhide even temporarily. > > kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding them. is there a reason for that? (closed ACLs) From lists at timj.co.uk Sat Jul 19 12:23:16 2008 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 19 Jul 2008 13:23:16 +0100 Subject: source file audit - 2008-07-05 In-Reply-To: <20080705141930.5f42d27f@ohm.scrye.com> References: <20080705141930.5f42d27f@ohm.scrye.com> Message-ID: <4881DCB4.8070703@timj.co.uk> Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. Thanks, this is a really useful tool. Does it run against devel or some other branches? Or all? > timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime I don't see the problem with this one. > timj:BADURL:rapidsvn-0.9.6.tar.gz:rapidsvn > timj:BADURL:rpl_1.5.3.tar.gz:rpl Fixed, thanks. Tim From konrad at tylerc.org Sat Jul 19 12:35:35 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Sat, 19 Jul 2008 05:35:35 -0700 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: References: <200807181659.33092.jwilson@redhat.com> Message-ID: <200807190535.36120.konrad@tylerc.org> Quoth drago01: > On Sat, Jul 19, 2008 at 12:33 AM, Kevin Kofler wrote: > > Jarod Wilson redhat.com> writes: > >> Unless someone objects, I'll probably just go ahead and do that this weekend, > >> rather than busticate rawhide even temporarily. > > > > kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding them. > > is there a reason for that? (closed ACLs) KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing. -- Conrad Meyer -------------- 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 nicolas.mailhot at laposte.net Sat Jul 19 12:56:16 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 19 Jul 2008 14:56:16 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: <1216469141.3232.56.camel@pc-notebook> References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> Message-ID: <1216472176.27197.4.camel@rousalka.okg> Le samedi 19 juillet 2008 ? 14:05 +0200, Martin Sourada a ?crit : > Next, there should be some policy in pushing such updates for stable > releases. I mean, what is the point in releasing security update for > xulrunner while it cannot be installed due to tons of broken deps? Also, why the hell is this stuff not tested in -devel first? We have a packageset which is rushed to stable with little testing. And we have a packageset which is left rotting in rawhide till the release deadlines toll. Do anyone really thinks there is not relation? When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From drago01 at gmail.com Sat Jul 19 13:31:11 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jul 2008 15:31:11 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: <1216472176.27197.4.camel@rousalka.okg> References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> <1216472176.27197.4.camel@rousalka.okg> Message-ID: 2008/7/19 Nicolas Mailhot : > Le samedi 19 juillet 2008 ? 14:05 +0200, Martin Sourada a ?crit : > >> Next, there should be some policy in pushing such updates for stable >> releases. I mean, what is the point in releasing security update for >> xulrunner while it cannot be installed due to tons of broken deps? > > Also, why the hell is this stuff not tested in -devel first? Because it was secutity related fix, so it has to hit stable asap. From gnomeuser at gmail.com Sat Jul 19 13:49:13 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 19 Jul 2008 15:49:13 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> <1216472176.27197.4.camel@rousalka.okg> Message-ID: <1dedbbfc0807190649v6ffc5dd9q6e39e45a6cfb830e@mail.gmail.com> 2008/7/19 drago01 : > 2008/7/19 Nicolas Mailhot : > > Le samedi 19 juillet 2008 ? 14:05 +0200, Martin Sourada a ?crit : > > > >> Next, there should be some policy in pushing such updates for stable > >> releases. I mean, what is the point in releasing security update for > >> xulrunner while it cannot be installed due to tons of broken deps? > > > > Also, why the hell is this stuff not tested in -devel first? > > Because it was secutity related fix, so it has to hit stable asap. > The obvious problem with this approach is naturally that people like myself who have epiphany installed, will not get the update asap because it is rushed into the repos without properly handling the dependencies. The rapid update policy for security fixes should apply equally to all users. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Sat Jul 19 13:52:55 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 19 Jul 2008 15:52:55 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> <1216472176.27197.4.camel@rousalka.okg> Message-ID: <20080719155255.8db4f9a3.mschwendt@gmail.com> On Sat, 19 Jul 2008 15:31:11 +0200, drago01 wrote: > > Le samedi 19 juillet 2008 ? 14:05 +0200, Martin Sourada a ?crit : > > > >> Next, there should be some policy in pushing such updates for stable > >> releases. I mean, what is the point in releasing security update for > >> xulrunner while it cannot be installed due to tons of broken deps? > > > > Also, why the hell is this stuff not tested in -devel first? > > Because it was secutity related fix, so it has to hit stable asap. Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even --skip-broken helps in that case. As you can see in bodhi, it has hit several testers quickly. From rawhide at fedoraproject.org Sat Jul 19 13:58:22 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 19 Jul 2008 13:58:22 +0000 (UTC) Subject: rawhide report: 20080719 changes Message-ID: <20080719135822.B2F6A209D8A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080718/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080719/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package cpqarrayd Cpqarrayd is a daemon to monitor HP (compaq) arraycontrollers New package libvirt-java Java bindings for the libvirt virtualization API New package perl-Config-Augeas Edit configuration files through Augeas C library New package ruby-taglib Ruby library wrapping the Taglib library Updated Packages: NetworkManager-0.7.0-0.11.svn3830.fc10 -------------------------------------- * Fri Jul 18 18:00:00 2008 Dan Williams - 1:0.7.0-0.11.svn3830 - Expose server-returned DHCP options via D-Bus - Use avahi-autoipd rather than old built-in IPv4LL implementation - Send hostname to DHCP server if provided (DHCP_HOSTNAME ifcfg option) - Support sending DHCP Client Identifier to DHCP server - Allow forcing 802.1x PEAP Label to '0' - Make connection sharing more robust - Show status for shared and Ad-Hoc connections if no other connection is active NetworkManager-openvpn-0.7.0-11.svn3832.fc10 -------------------------------------------- * Fri Jul 18 18:00:00 2008 Dan Williams 1:0.7.0-11.svn3832 - Update for NM netmask -> prefix changes NetworkManager-vpnc-0.7.0-0.10.svn3832.fc10 ------------------------------------------- * Fri Jul 18 18:00:00 2008 Dan Williams 1:0.7.0-10.svn3832 - Update for NM netmask -> prefix changes PyOpenGL-3.0.0-0.6.b4.fc10 -------------------------- * Fri Jul 18 18:00:00 2008 Nikolay Vladimirov 3.0.0-0.6.b4 - New upstream release 3.0.0b4 aalib-1.4.0-0.16.rc5.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Caol??n McNamara 1.4.0-0.16.rc5 - rebuild for new libgpm at-3.1.10-24.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Marcela Maslanova - 3.1.10-24 - 446004 hope adding || into scriptlets fix removing old package after upgrade - fixes for fuzz=0 augeas-0.2.2-1.fc10 ------------------- * Fri Jul 18 18:00:00 2008 David Lutterkort - 0.2.2-1 - New version cpio-2.9.90-2.fc10 ------------------ * Fri Jul 18 18:00:00 2008 Kamil Dudka 2.9.90-2 - Support major/minor device numbers over 127 (bz#450109) dayplanner-0.9.1-1.fc10 ----------------------- * Sat Jul 19 18:00:00 2008 Christoph Wickert - 0.9.1-1 - Update to 0.9.1 to fix #446883 - Require perl(Locale::gettext) - Add German descriptions dbus-1.2.1-6.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Matthias Clasen - 1.2.1-6 - Add a patch from upstream git that adds a method for changing the activation environment on the session bus * Thu Jul 17 18:00:00 2008 Casey Dahlin - 1.2.1-5 - Patch to increase max method timeout digikam-0.9.4-2.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter - 0.9.4-2 - --without-included-sqlite3, BR: sqlite-devel * Thu Jul 17 18:00:00 2008 Rex Dieter - 0.9.4-1 - digikam-0.9.4 * Mon Jul 7 18:00:00 2008 Marcin Garski 0.9.3-5 - Don't lose some photos during import (#448235) docbook-simple-1.1-4.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Ondrej Vasik - 1.1-4 - fix loop in post catalog registration(incomplete sed coverage) #455680 - fix broken catalogs for package updates - fix removal of files during updates docbook-slides-3.4.0-4.fc10 --------------------------- * Fri Jul 18 18:00:00 2008 Ondrej Vasik - 3.4.0-4 - fix loop in post catalog registration(incomplete sed coverage) #455680 - fix broken catalogs for package updates - fix removal of files during updates edrip-fonts-20080717-1.fc10 --------------------------- * Thu Jul 17 18:00:00 2008 - 20080717-1 ???? More cyrillic coverage ekg2-0.2-0.4.rc1.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Caol??n McNamara 0.2-0.4.rc1 - rebuild for new gpm evolution-2.23.4-3.fc10 ----------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 2.23.4-3.fc10 - fix license tag - fix patches to apply with fuzz=0 evolution-data-server-2.23.4-3.fc10 ----------------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 2.23.4-3 - fix license tag evolution-sharp-0.17.4-3.fc10 ----------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.17.4-3 - fix license tag - fix patches to apply with fuzz=0 - fix source url * Mon Jul 14 18:00:00 2008 Matthew Barnes - 0.17.4-2.fc10 - Rebuild against newer mono(glib-sharp). evolution-webcal-2.21.92-3.fc10 ------------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 2.21.92-3 - fix license tag - fix source url ez-ipupdate-3.0.11-0.20.b8.fc10 ------------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 3.0.11-0.20.b8 - fix license tag fbset-2.1-26.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 2.1-26 - fix license tag fedora-gnome-theme-8.0.0-3.fc10 ------------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 8.0.0-3 - fix license tag fedora-screensaver-theme-1.0.0-2.fc10 ------------------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0.0-2 - fix license tag fedora-usermgmt-0.10-2.fc10 --------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.10-2 - fix license tag festival-1.96-5.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.96-5 - fix license tag fetchlog-1.0-10.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0-10 - fix license tag fftw-3.1.2-7.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 3.1.2-7 - fix license tag fig2ps-1.3.6-3.fc10 ------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 1.3.6-3 - fix license tag filelight-1.0-13.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0-13 - fix license tag firefox-3.0.1-1.fc10 -------------------- * Wed Jul 16 18:00:00 2008 Christopher Aillon 3.0.1-1 - Update to 3.0.1 firestarter-1.0.3-19.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0.3-19 - fix license tag fityk-0.8.1-14.fc10 ------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.8.1-14 - fix license tag flac123-0.0.11-5.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.0.11-5 - fix license tag flite-1.3-10.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.3-10 - fix license tag fluidsynth-1.0.8-2.fc10 ----------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 1.0.8-2 - fix license tag fluidsynth-dssi-0.9.1-9.fc10 ---------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.9.1-9 - fix license tag fonts-ISO8859-2-1.0-19.fc10 --------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0-19 - fix license tag fonts-hebrew-fancy-0.20051122-4.fc10 ------------------------------------ * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.20051122-4 - fix license tag fortune-firefly-2.1.2-6.fc10 ---------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 2.1.2-6 - fix license tag * Sun Jan 20 17:00:00 2008 Karen Pease - 2.1.2.5 - Upping tag to sync builds. freefont-20080323-1.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 20080323-1 - fix license tag - update to 20080323 freehdl-0.0.6-2.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 0.0.6-2 - fix license tag freetennis-0.4.8-12.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.4.8-12 - fix license tag freeze-2.5.0-9.fc10 ------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway 2.5.0-9 - fix license tag with copyright holder clarification fs_mark-3.2-3.fc10 ------------------ * Fri Jul 18 18:00:00 2008 Eric Sandeen 3.2-3 - Updated tarball from new sf.net home fuse-convmvfs-0.2.4-7.fc10 -------------------------- * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.2.4-7 - fix license tag fwbackups-1.43.2-0.8.rc3.fc10 ----------------------------- * Fri Jul 18 18:00:00 2008 Stewart Adam 1.43.2-0.8.rc3 - BR: gnome-doc-utils * Fri Jul 18 18:00:00 2008 Stewart Adam 1.43.2-0.7.rc3 - Update to 1.43.2rc3 gnome-panel-2.23.4-5.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Matthias Clasen - 2.23.4-5 - Fix one more icon gthumb-2.10.8-4.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Matthias Clasen - 2.10.8-4 - Try to fix a crash (#453181) gv-3.6.5-2.fc10 --------------- * Fri Jul 18 18:00:00 2008 Orion Poplawski 3.6.5-2 - Change install dir patch to be more palatable for upstream * Thu Jul 17 18:00:00 2008 Orion Poplawski 3.6.5-1 - Update to 3.6.5 kazehakase-0.5.4-7.svn3506_trunk.fc10 ------------------------------------- * Sat Jul 19 18:00:00 2008 Mamoru Tasaka - 0.5.4-7.svn3506_trunk - F-9+: relax gecko libs dependency (as GRE_GetGREPathWithProperties properly finds out GRE) - F-10+: add -UGTK_DISABLE_DEPRECATED temporarily kdebase-runtime-4.0.99-1.fc10 ----------------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdebase-workspace-4.0.99-1.fc10 ------------------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdelibs-4.0.99-1.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdepimlibs-4.0.99-1.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kernel-2.6.27-0.159.rc0.git6.fc10 --------------------------------- * Thu Jul 17 18:00:00 2008 Kristian H??gsberg - Add conflicts for older libdrm-devel to kernel-headers. * Thu Jul 17 18:00:00 2008 Dave Jones - 2.6.26-git6 * Thu Jul 17 18:00:00 2008 Dave Jones - 2.6.26-git5 kernel-xen-2.6-2.6.27-0.2.rc0.git6.fc10 --------------------------------------- * Wed Jun 18 18:00:00 2008 Mark McLoughlin - Rebase to kernel-2_6_27-0_159_rc0_git6_fc10 - Drop Eduardo's 64bit tree and switch to Jeremy's x86.git tree - Re-enable SMP etc. kphotobymail-0.4.1-2.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Steven M. Parrish 0.4.1-2 - Fixed unpackaged file causing build errors linkage-0.2.0-2.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Adel Gadllah 0.2.0-2 - Remove buildrequires hack lrzip-0.23-1.fc10 ----------------- * Fri Jul 18 18:00:00 2008 Shawn Starr 0.23-1 - New upstream release mantis-1.1.2-1.fc10 ------------------- * Sat Jul 19 18:00:00 2008 Gianluca Sforna - 1.1.2-1 - new upstream release - add patch for bugnotes notification mksh-35b-1.fc10 --------------- * Sat Jul 19 18:00:00 2008 Robert Scheck 35b-1 - Upgrade to 35b nuttcp-5.5.5-1.fc10 ------------------- * Fri Jul 18 18:00:00 2008 Radek Vok??l - 5.5.5-1 - upgrade to 5.5.5 - remove pre1 from makefile openoffice.org-3.0.0-0.0.25.1.fc10 ---------------------------------- * Thu Jul 17 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.25-1 - next version - drop integrated openoffice.org-2.4.0.ooo85448.emptyrpath.patch - drop inregrated openoffice.org-2.3.0.oooXXXXX.odk.3layer.patch - add workspace.native172.patch for ScriptFramework extention bustage oprofile-0.9.4-1.fc10 --------------------- * Thu Jul 17 18:00:00 2008 Will Cohen - 0.9.4-1 - Update to orprofile 0.9.4. perl-AnyEvent-4.21-1.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 kwizart < kwizart at gmail.com > - 4.21-1 - Update to 4.21 perl-Class-MOP-0.63-1.fc10 -------------------------- * Fri Jul 18 18:00:00 2008 Chris Weyl 0.63-1 - update to 0.63 perl-Class-MethodMaker-2.11-1.fc10 ---------------------------------- * Fri Jul 18 18:00:00 2008 Ralf Cors??pius - 2.11-1 - Upstream update. * Fri Jul 18 18:00:00 2008 Ralf Cors??pius - 2.10-4 - Remove %clean ||: (BZ 449442, FTBFS). - Use %version in Source0-URL. - Don't skip 0-signature.t. - Misc. minor spec-file overhaul. perl-Moose-0.54-1.fc10 ---------------------- * Fri Jul 18 18:00:00 2008 Chris Weyl 0.54-1 - update to 0.54 perl-WWW-Search-2.503-1.fc10 ---------------------------- * Fri Jul 18 18:00:00 2008 Xavier Bachelot - 2.503-1 - New upstream version 2.503. pnp4nagios-0.4.10-2.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Xavier Bachelot 0.4.10-2 - Fix typo in logrotate conf. python-libgmail-0.1.9-1.fc10 ---------------------------- * Fri Jul 18 18:00:00 2008 Nikolay Vladimirov -0.1.9-1 - new upstream 0.1.9 qscintilla-2.2-3.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter - 2.2-2 - fix build (#449423) * Fri Jul 18 18:00:00 2008 Dennis Gilmore - 2.2-3 - rebuild for newer PyQT4 - fix #449423 properly ruby-gnome2-0.17.0-0.4.rc1.fc10 ------------------------------- * Sat Jul 19 18:00:00 2008 Mamoru Tasaka - 0.17.0-0.4.rc1 - F-9+: relax gecko libs dependency - F-9+: bump version to fix EVR problem between F-8 branch sectool-0.8.0-2.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Caol??n McNamara - 0.8.0-2 - rebuild for new rpm sonic-visualiser-1.3-1.fc10 --------------------------- * Thu Jul 17 18:00:00 2008 Michel Alexandre Salim - 1.3-1 - Update to 1.3 thunar-archive-plugin-0.2.4-5.fc10 ---------------------------------- * Sat Jul 19 18:00:00 2008 Christoph Wickert - 0.2.4-5 - When used with file roller "Extract here" now always creates folder uim-1.5.0-4.fc10 ---------------- * Tue Jul 15 18:00:00 2008 Akira TAGOH - 1.5.0-4 - Requires: imsettings instead of im-chooser. - Add ICON parameter to uim.conf. - Use Qt implementation of candidate window if the desktop session is KDE. - set the appropriate immodule for multilib as scim does. vnc-4.1.2-34.fc10 ----------------- * Thu Jul 17 18:00:00 2008 Adam Tkac 4.1.2-34 - vncserver script returns error when Xvnc fails to start * Wed Jul 16 18:00:00 2008 Adam Tkac 4.1.2-33.1 - update patches due rpm 4.6 xfce4-screenshooter-plugin-1.3.1-1.fc10 --------------------------------------- * Fri Jul 18 18:00:00 2008 Christoph Wickert - 1.3.1-1 - Update to 1.3.1 xsane-0.995-5.fc10 ------------------ * Fri Jul 18 18:00:00 2008 Nils Philippsen - 0.995-5 - fix fd leak prevention (#455450) xulrunner-1.9.0.1-1.fc10 ------------------------ * Wed Jul 16 18:00:00 2008 Christopher Aillon 1.9.0.1-1 - Update to 1.9.0.1 Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 81 Broken deps for i386 ---------------------------------------------------------- Miro-1.2.4-2.fc10.i386 requires gecko-libs = 0:1.9 apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so blam-1.8.3-13.fc9.i386 requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.i386 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.i386 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.i386 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.i386 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gxine-0.5.903-1.fc10.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.i386 requires libsqlite3.so muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 nspluginwrapper-1.1.0-1.fc10.i386 requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sooperlooper-1.6.2-1.fc9.i386 requires librubberband.so.1 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.i386 requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.i386 requires libgpm.so.1 xaos-3.2.3-3.fc9.i386 requires libgpm.so.1 xawtv-3.95-8.fc9.i386 requires libgpm.so.1 xemacs-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-nox-21.5.28-8.fc10.i386 requires libgpm.so.1 yelp-2.22.1-2.fc10.i386 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- Miro-1.2.4-2.fc10.x86_64 requires gecko-libs = 0:1.9 apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) blam-1.8.3-13.fc9.x86_64 requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.i386 requires gecko-libs = 0:1.9 devhelp-0.19.1-2.fc10.x86_64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.x86_64 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.i386 requires gecko-devel = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.x86_64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.x86_64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.x86_64 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 gxine-0.5.903-1.fc10.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.x86_64 requires libsqlite3.so()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 nspluginwrapper-1.1.0-1.fc10.i386 requires gecko-libs = 0:1.9 nspluginwrapper-1.1.0-1.fc10.x86_64 requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sooperlooper-1.6.2-1.fc9.x86_64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.x86_64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.x86_64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) yelp-2.22.1-2.fc10.x86_64 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Miro-1.2.4-2.fc10.ppc requires gecko-libs = 0:1.9 apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) blam-1.8.3-13.fc9.ppc requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.ppc requires gecko-libs = 0:1.9 devhelp-0.19.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.ppc requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc requires gecko-devel = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 gxine-0.5.903-1.fc10.ppc requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) liferea-1.4.16b-5.fc10.ppc requires libsqlite3.so muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 nspluginwrapper-1.1.0-1.fc10.ppc requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sooperlooper-1.6.2-1.fc9.ppc requires librubberband.so.1 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.ppc requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.ppc requires libgpm.so.1 xaos-3.2.3-3.fc9.ppc requires libgpm.so.1 xawtv-3.95-8.fc9.ppc requires libgpm.so.1 xemacs-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc requires libgpm.so.1 yelp-2.22.1-2.fc10.ppc requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- Miro-1.2.4-2.fc10.ppc64 requires gecko-libs = 0:1.9 apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc64 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 gxine-0.5.903-1.fc10.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.ppc64 requires libsqlite3.so()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sooperlooper-1.6.2-1.fc9.ppc64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.ppc64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.ppc64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) yelp-2.22.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From dennis at ausil.us Sat Jul 19 14:32:18 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 19 Jul 2008 09:32:18 -0500 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> Message-ID: <200807190932.30560.dennis@ausil.us> On Saturday 19 July 2008, Martin Langhoff wrote: > On Fri, Jul 18, 2008 at 4:20 PM, Martin Langhoff > > wrote: > > - In step 4 - the host environment not having httpd should not affect > > the build chroot. > > Debugged this -- and mock is not to blame. The build scripts I have > first build the source package outsider the mock chroot and then use > mock to build the binaries. > > Any reason rpmbuild -bs checks dependencies? add a --nodeps and it wont > > - In step 3, I was expecting the rpmbuild running the "install" target > > inside mock to be using fakeroot or something similar. > > This is still puzzling. Why does the `make install` in mock not get > wrapped by a fakeroot-ish trick? it installs into a directory on its own you need to support DEST= in your makefiles. it gets installed into its own tree. If you have ideas of features you would like to see in rpm go to rpm.org and work upstream to get them in :) -- Dennis Gilmore -------------- 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 drago01 at gmail.com Sat Jul 19 14:45:52 2008 From: drago01 at gmail.com (drago01) Date: Sat, 19 Jul 2008 16:45:52 +0200 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: <20080719155255.8db4f9a3.mschwendt@gmail.com> References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> <1216472176.27197.4.camel@rousalka.okg> <20080719155255.8db4f9a3.mschwendt@gmail.com> Message-ID: On Sat, Jul 19, 2008 at 3:52 PM, Michael Schwendt wrote: > On Sat, 19 Jul 2008 15:31:11 +0200, drago01 wrote: > >> > Le samedi 19 juillet 2008 ? 14:05 +0200, Martin Sourada a ?crit : >> > >> >> Next, there should be some policy in pushing such updates for stable >> >> releases. I mean, what is the point in releasing security update for >> >> xulrunner while it cannot be installed due to tons of broken deps? >> > >> > Also, why the hell is this stuff not tested in -devel first? >> >> Because it was secutity related fix, so it has to hit stable asap. > > Doesn't matter. It doesn't install at all if it breaks dependencies > of *installed* packages. Not even --skip-broken helps in that case. > As you can see in bodhi, it has hit several testers quickly. I just said why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps. From paul at all-the-johnsons.co.uk Sat Jul 19 15:05:35 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 19 Jul 2008 16:05:35 +0100 Subject: Heads up - Mono In-Reply-To: <1216414228.9803.5.camel@metroid.rdu.redhat.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> <1216414228.9803.5.camel@metroid.rdu.redhat.com> Message-ID: <1216479935.31763.3.camel@T7.Linux> Hi, > > If we can manage to push it out as one big update, then I don't see > > how having the same mono stack, with all the fixes that has gone into > > Mono 2.0 would be a bad thing. > > Cramming major-version updates of default system components into a > stable release is not something to be done lightly. Fedora 10 is only 3 > months away; I think this should wait 'til then, unless someone can > convince me it's worth the pain of breaking ABI and rebuilding a whole > mess of packages. Until I know the full extent of what will be broken, I certainly won't be pushing it into F9 and I doubt Xavier will either. To me, rawhide is there for exactly this purpose - a testing ground to see how much is broken before pushing to stable. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 jkeating at redhat.com Sat Jul 19 15:20:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 19 Jul 2008 11:20:44 -0400 Subject: Pungi with x86_64 packages only In-Reply-To: References: Message-ID: <1216480844.3179.0.camel@localhost.localdomain> On Sat, 2008-07-19 at 11:51 +0200, Vnpenguin wrote: > Hi all, > I would like to build a customized CD on FC9 x86_64 with pungi. The > problem is I dont know how to get only x86_64 packages. So many i386 > packages were there. > > Any idea for help ? In your kickstart file, when you define the repo, add an --exclude *.i?86 to the line. This will prevent yum (which does the package gathering) from seeing any non x86_64 or noarch package. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 vnpenguin at vnoss.org Sat Jul 19 17:45:01 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 19 Jul 2008 19:45:01 +0200 Subject: Pungi with x86_64 packages only In-Reply-To: <1216480844.3179.0.camel@localhost.localdomain> References: <1216480844.3179.0.camel@localhost.localdomain> Message-ID: 2008/7/19 Jesse Keating : > > In your kickstart file, when you define the repo, add an --exclude > *.i?86 to the line. This will prevent yum (which does the package > gathering) from seeing any non x86_64 or noarch package. > Thank you so much, Regards, -- http://vnoss.org From rdieter at math.unl.edu Sat Jul 19 17:49:52 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 19 Jul 2008 12:49:52 -0500 Subject: heads up: new libraw1394 so, stuff needs rebuildin' References: <200807181659.33092.jwilson@redhat.com> <200807181731.30567.jwilson@redhat.com> Message-ID: drago01 wrote: > On Sat, Jul 19, 2008 at 12:33 AM, Kevin Kofler > wrote: >> Jarod Wilson redhat.com> writes: >>> Unless someone objects, I'll probably just go ahead and do that this >>> weekend, rather than busticate rawhide even temporarily. >> >> kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding >> them. > > is there a reason for that? (closed ACLs) for some of the core kde pkgs yes (kde dev platform bits), others not so much (auxilary or leaf packages, such as kdegames). I'll see if we can do something about that. -- Rex From arjan at infradead.org Sat Jul 19 18:34:17 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sat, 19 Jul 2008 11:34:17 -0700 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <488096A9.3060408@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <48809484.1010008@redhat.com> <488096A9.3060408@redhat.com> Message-ID: <20080719113417.0242cd54@infradead.org> On Fri, 18 Jul 2008 09:12:09 -0400 Daniel J Walsh wrote: > A lot of bugzilla's I get cut and paste the setroubleshoot window and > then I respond by saying "Do what the troubleshouter told you to do!" > Closed Not a Bug. .. if it knows what to do, but doesn't just do it, that would be a bug ;-) From mmahut at fedoraproject.org Sat Jul 19 18:53:04 2008 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sat, 19 Jul 2008 20:53:04 +0200 Subject: Fedora Astronomy IRC channel Message-ID: <48823810.30401@fedoraproject.org> Hello folks, Please join us for discussion at any time in #fedora-astronomy on irc.freenode.org. For more information: http://fedoraproject.org/wiki/Communicate/IRCHowTo -- Marek Mahut https://fedoraproject.org/wiki/SIGs/Astronomy/ Fedora Project http://www.jamendo.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Sat Jul 19 19:30:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 19 Jul 2008 11:30:54 -0800 Subject: Heads up - Mono In-Reply-To: <1216479935.31763.3.camel@T7.Linux> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> <1216414228.9803.5.camel@metroid.rdu.redhat.com> <1216479935.31763.3.camel@T7.Linux> Message-ID: <604aa7910807191230k1ad9ec13w5d1b106e34a55378@mail.gmail.com> 2008/7/19 Paul : > To me, rawhide is there for exactly this purpose - a testing ground to > see how much is broken before pushing to stable. If that is how you view rawhide... what is your interpretation as to the purpose of updates-testing? -jef From kraxel at redhat.com Sat Jul 19 22:22:01 2008 From: kraxel at redhat.com (Gerd Hoffmann) Date: Sun, 20 Jul 2008 00:22:01 +0200 Subject: Pungi with x86_64 packages only In-Reply-To: <1216480844.3179.0.camel@localhost.localdomain> References: <1216480844.3179.0.camel@localhost.localdomain> Message-ID: <48826909.2010104@redhat.com> Jesse Keating wrote: > On Sat, 2008-07-19 at 11:51 +0200, Vnpenguin wrote: >> Hi all, >> I would like to build a customized CD on FC9 x86_64 with pungi. The >> problem is I dont know how to get only x86_64 packages. So many i386 >> packages were there. >> >> Any idea for help ? > > > In your kickstart file, when you define the repo, add an --exclude > *.i?86 to the line. This will prevent yum (which does the package > gathering) from seeing any non x86_64 or noarch package. maybe related question: I'm using pungi for selective mirroring, by listing the packages and package groups I wanna have in the kickstart file and then running the gather and createrepo stages. Works quite well, except that there seems to be no way to mirror x86_64 packages on a i386 machine ... any hints how that can be done? cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/ From ob.system at gmail.com Sat Jul 19 22:56:00 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Sat, 19 Jul 2008 17:56:00 -0500 Subject: Another xulrunner breakage [Re: Broken dependencies in Fedora 9 - 2008-07-19] In-Reply-To: References: <20080719110538.4437.86430@faldor.intranet> <1216469141.3232.56.camel@pc-notebook> <1216472176.27197.4.camel@rousalka.okg> <20080719155255.8db4f9a3.mschwendt@gmail.com> Message-ID: <6a28481b0807191556pa7bf474o91cc9249f5f7fbd2@mail.gmail.com> > >> > Also, why the hell is this stuff not tested in -devel first? > +1000 >> Because it was secutity related fix, so it has to hit stable asap. > > > Doesn't matter. It doesn't install at all if it breaks dependencies > > of *installed* packages. Not even --skip-broken helps in that case. > +1000 This never shouldn't happen, stable != rawhide Oscar Bacho -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnocera at redhat.com Sun Jul 20 00:06:45 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 20 Jul 2008 01:06:45 +0100 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807181659.33092.jwilson@redhat.com> References: <200807181659.33092.jwilson@redhat.com> Message-ID: <1216512405.3080.319.camel@cookie.hadess.net> On Fri, 2008-07-18 at 16:59 -0400, Jarod Wilson wrote: > Coming Real Soon Now to rawhide is a build of the final libraw1394 2.0.0, > which includes a soname bump, which means a number of packages are going to > need to be rebuild. A quick glance with repoquery suggests the list is > limited to: > > unicap > gstreamer-plugins-good If you can do the rebuild for that one, go for it. Cheers From jkeating at redhat.com Sun Jul 20 00:07:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 19 Jul 2008 20:07:20 -0400 Subject: Pungi with x86_64 packages only In-Reply-To: <48826909.2010104@redhat.com> References: <1216480844.3179.0.camel@localhost.localdomain> <48826909.2010104@redhat.com> Message-ID: <1216512440.5700.0.camel@localhost.localdomain> On Sun, 2008-07-20 at 00:22 +0200, Gerd Hoffmann wrote: > maybe related question: > > I'm using pungi for selective mirroring, by listing the packages and > package groups I wanna have in the kickstart file and then running the > gather and createrepo stages. Works quite well, except that there > seems > to be no way to mirror x86_64 packages on a i386 machine ... > > any hints how that can be done? You probably want to be using a different tool for that, since pungi won't allow you to gather / compose x86_64 on an i386 system. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 fdinitto at redhat.com Sun Jul 20 04:17:07 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Sun, 20 Jul 2008 06:17:07 +0200 Subject: Some initial discussions of a Fedora HPC SIG In-Reply-To: <20080717230526.70f4c6d2@ludwig-alpha.unil.ch> References: <20080717230526.70f4c6d2@ludwig-alpha.unil.ch> Message-ID: <1216527427.24212.2.camel@daitarn-fedora.int.fabbione.net> On Thu, 2008-07-17 at 23:05 +0200, Christian Iseli wrote: > On Thu, 17 Jul 2008 16:07:15 -0400, Shawn Starr wrote: > > There are many more questions and getting some initial discussions > > going will be beneficial to Fedora. > > I'm interested in HPC. My nits to pick: > - hierarchical storage management > - petabyte storage management > - billions of files > - cluster file systems I maintain a few packages related to cluster filesystems (cman/gfs etc) and I'd be happy to work with you guys if there are changes in my packages required to make your life simpler. Fabio From lists at timj.co.uk Sun Jul 20 05:58:38 2008 From: lists at timj.co.uk (Tim Jackson) Date: Sun, 20 Jul 2008 06:58:38 +0100 Subject: ENVR checking Message-ID: <4882D40E.6050309@timj.co.uk> What happened to that script that used to run and check all the ENVRs across releases to make sure that there was a proper upgrade path (i.e. F8 < F8-updates < F9 etc.)? That was really useful. I have had a disappointing experience on a couple of machines with doing upgrades from F-8 to F-9, where there are a lot of F-8 packages still hanging around that shouldn't be, mostly due to ENVR problems (F-8 updates > F-9) From mschwendt at gmail.com Sun Jul 20 07:10:33 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 20 Jul 2008 09:10:33 +0200 Subject: ENVR checking In-Reply-To: <4882D40E.6050309@timj.co.uk> References: <4882D40E.6050309@timj.co.uk> Message-ID: <20080720091033.7e1bfdf7.mschwendt@gmail.com> On Sun, 20 Jul 2008 06:58:38 +0100, Tim Jackson wrote: > What happened to that script that used to run and check all the ENVRs > across releases to make sure that there was a proper upgrade path (i.e. > F8 < F8-updates < F9 etc.)? That was really useful. > > I have had a disappointing experience on a couple of machines with doing > upgrades from F-8 to F-9, where there are a lot of F-8 packages still > hanging around that shouldn't be, mostly due to ENVR problems (F-8 updates > > F-9) Still in cvs: http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora It used to be run automatically after each Extras push, but when the build system moved to koji and bodhi, this feature was killed. Probably it was considered unimportant or a source of "spam". That's a problem with stuff that isn't backed up or enforced by project leadership. When I started to run it manually after some time prior to the next release of Fedora, the number of negative voices was overwhelming: Those with test updates newer than rawhide complained. Those with F-[n-1] test updates newer than F-[n] complained. Those with pending updates in bodhi complained. Those who found it helpful stayed silent. From those, who didn't understand the private mails they received, only a very few asked for an explanation. Recently I've seen a comment somewhere that Josh Boyer seems to have a similar but different script somewhere. I don't know how it differs. From kraxel at redhat.com Sun Jul 20 08:26:24 2008 From: kraxel at redhat.com (Gerd Hoffmann) Date: Sun, 20 Jul 2008 10:26:24 +0200 Subject: Pungi with x86_64 packages only In-Reply-To: <1216512440.5700.0.camel@localhost.localdomain> References: <1216480844.3179.0.camel@localhost.localdomain> <48826909.2010104@redhat.com> <1216512440.5700.0.camel@localhost.localdomain> Message-ID: <4882F6B0.6000905@redhat.com> Jesse Keating wrote: > On Sun, 2008-07-20 at 00:22 +0200, Gerd Hoffmann wrote: >> maybe related question: >> >> I'm using pungi for selective mirroring, by listing the packages and >> package groups I wanna have in the kickstart file and then running the >> gather and createrepo stages. Works quite well, except that there >> seems >> to be no way to mirror x86_64 packages on a i386 machine ... >> >> any hints how that can be done? > > You probably want to be using a different tool for that, since pungi > won't allow you to gather / compose x86_64 on an i386 system. Is there any reason for that restriction? As I understand it only the BuildInstall stage must run on the architecture (and distro) it is composing due to running anaconda tools. Suggestions for alternatives? The pungi features I like most are (1) easy way to select the packages (and groups!) I want to mirror. (2) the (global) package cache. the package is especially useful when mirroring both i386 and x86_64 versions of a distro, as the i386 packages which are also part of the x86_64 version don't get downloaded twice. It also saves downloads when creating a new repo where you have alot of the packages already on your disk (happens if you track rawhide and some day create a f10 repo). thanks, Gerd -- http://kraxel.fedorapeople.org/xenner/ From rawhide at fedoraproject.org Sun Jul 20 09:39:14 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 20 Jul 2008 09:39:14 +0000 (UTC) Subject: rawhide report: 20080720 changes Message-ID: <20080720093914.23BDD209D33@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080719/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080720/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package ecolier-court-fonts ??colier court cursive fonts New package gfs-jackson-fonts GFS Jackson majuscule Greek font New package gfs-nicefore-fonts GFS Nicefore majuscule Greek font New package kdeplasma-addons Additional plasmoids for KDE New package xpad Sticky notepad for GTK+2 Updated Packages: Miro-1.2.4-3.fc10 ----------------- * Sat Jul 19 18:00:00 2008 Alex Lancaster - 1.2.4-3 - Rebuild for xulrunner-1.9.0.1 - Unfortunately we probably need to make this an exact match because Miro uses the unstable API, so a rebuild may need to be done on every package update to be sure that it will work with new xulrunner updates altermime-0.3.8-1.fc10 ---------------------- * Sat Jul 19 18:00:00 2008 Tim Jackson 0.3.8-1 - Update to version 0.3.8 foobillard-3.0a-7 ----------------- * Sat Jul 19 18:00:00 2008 Miloslav Trma?? - 3.0a-7 - Don't ship the non-free fonts - Update License: - Fix foobillard.desktop - Convert ChangeLog to UTF-8 - Don't ship empty NEWS gnofract4d-3.9-1.fc10 --------------------- * Sat Jul 19 18:00:00 2008 Stewart Adam - 3.9-1 - Update to 3.9 gxine-0.5.903-2.fc10 -------------------- * Sat Jul 19 18:00:00 2008 Martin Sourada - 0.5.903-2 - rebuild for new xulrunner - drop dist checks to keep the spec cleaner - drop versioned dependency on gecko-libs joda-time-1.5.2-7.tzdata2008d.fc10 ---------------------------------- * Sat Jul 19 18:00:00 2008 Conrad Meyer - 1.5.2-7.tzdata2008d - New version with new tzdata (2008d). joni-1.0.3-0.3.svn7235.fc10 --------------------------- * Sat Jul 19 18:00:00 2008 Conrad Meyer - 1.0.3-0.3.svn7235 - Build AOT bits. * Sat Jul 19 18:00:00 2008 Conrad Meyer - 1.0.3-0.2.svn7235 - Bump revision because of stupid packager's mistake. * Sat Jul 19 18:00:00 2008 Conrad Meyer - 1.0.3-0.1.svn7235 - Bump to trunk version of joni for JRuby 1.1.3. - Switch to noarch for fc10 and up. jruby-1.1.3-1.fc10 ------------------ * Sat Jul 19 18:00:00 2008 Conrad Meyer - 1.1.3-1 - Bump to 1.1.3. jvyamlb-0.2.2-1.fc10 -------------------- * Sat Jul 19 18:00:00 2008 Conrad Meyer - 0.2.2-1 - Newer version. kde-i18n-3.5.9-8.fc10 --------------------- * Sun Jul 20 18:00:00 2008 Kevin Kofler 1:3.5.9-8 - also remove kpovmodeler translations on F9+ (#454458) kdeaccessibility-4.0.99-1.fc10 ------------------------------ * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdeartwork-4.0.99-1.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdebase-4.0.99-1.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdebase-workspace-4.0.99-3.fc10 ------------------------------- * Sat Jul 19 18:00:00 2008 Kevin Kofler 4.0.99-3 - BR soprano-devel (optional dependency of the Plasma Engine Explorer) * Sat Jul 19 18:00:00 2008 Kevin Kofler 4.0.99-2 - backport Plasma tooltip manager from KDE 4.2 (fixes regression from 4.0) WARNING: Adds some new APIs from 4.2 (Plasma::popupPosition, Plasma::viewFor, Plasma::ToolTip*), use at your own risk, we have no control to guarantee that they will not change! kdebindings-4.0.99-1.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdeedu-4.0.99-1.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdegames-4.0.99-1.fc10 ---------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdegraphics-4.0.99-1.fc10 ------------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdelibs-4.0.99-2.fc10 --------------------- * Sat Jul 19 18:00:00 2008 Rex Dieter 4.0.99-2 - use better fedora-buildtype patch from F-9 branch kdemultimedia-4.0.99-1.fc10 --------------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdenetwork-4.0.99-1.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdepim-4.0.99-1.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdesdk-4.0.99-1.fc10 -------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdetoys-4.0.99-1.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 kdeutils-4.0.99-1.fc10 ---------------------- * Fri Jul 18 18:00:00 2008 Rex Dieter 4.0.99-1 - 4.0.99 muine-0.8.9-1.fc10 ------------------ * Sat Jul 19 18:00:00 2008 Alex Lancaster - 0.8.9-1 - Update to pre-release upstream (0.8.9) to fix broken deps - Add BR: intltools * Wed Jun 4 18:00:00 2008 Sindre Pedersen Bj??rdal - 0.8.8-10 - rebuild for dependancies nemiver-0.5.5-0.1.svn889.fc10 ----------------------------- * Sat Jul 19 18:00:00 2008 Peter Gordon - 0.5.5-0.1.svn889 - Update to new upstream snapshot (SVN 889): increased performance when stepping in big applications like WebKit, ability to call arbitrary functions in the inferior process being debugged and support for conditional breakpoints, and loads of bug-fixes. Sweet! - Fix typo in previous %changelog entry. nntpgrab-0.3.2-2.fc10 --------------------- * Sat Jul 19 18:00:00 2008 Erik van Pienbroek - 0.3.2-2 - Tarball was respun by upstream * Sat Jul 19 18:00:00 2008 Erik van Pienbroek - 0.3.2-1 - Update to version 0.3.2 python-fedora-0.3.2-1.fc10 -------------------------- * Sun Jul 20 18:00:00 2008 Luke Macken - 0.3.2-1 - Latest upstream release - Add koji to the Requires qt-4.4.0-15.fc10 ---------------- * Sat Jul 19 18:00:00 2008 Rex Dieter 4.4.0-15 - fix/workaround spec syntax * Sat Jul 19 18:00:00 2008 Rex Dieter 4.4.0-14 - macros.qt4: fix %_qt4_datadir, %_qt4_translationdir * Thu Jul 17 18:00:00 2008 Rex Dieter 4.4.0-13 - (re)fix qconfig-multilib.h for sparc64 rpl-1.5.5-1.fc10 ---------------- * Sat Jul 19 18:00:00 2008 Tim Jackson 1.5.5-1 - Update to version 1.5.5 - Move to new upstream distribution location (Sourceforge) rpm-4.5.90-0.git8426.9 ---------------------- * Sat Jul 19 18:00:00 2008 Panu Matilainen - 4.5.90-0.git8426.9 - fix regression in patch number handling (#455872) thunar-shares-0.16-1.fc10 ------------------------- * Sun Jul 20 18:00:00 2008 Christoph Wickert - 0.16-1 - Update to 0.16 xdvik-22.84.14-1.fc10 --------------------- * Fri Jul 18 18:00:00 2008 Jonathan G. Underwood - 22.84.13-20 - Update to version 22.84.14 - Update Japanese patch to 22.84.14-j1.40 - Rework patch allowing both normal and Japanese versions to be built - Remove no longer needed patches that have been merged upstream: - Various spec file fixups xfwm4-4.4.2-4.fc10 ------------------ * Sun Jul 20 18:00:00 2008 Christoph Wickert - 4.4.2-4 - Really switch to Nodoka theme xorg-x11-drv-radeonhd-1.2.1-3.6.20080719git.fc10 ------------------------------------------------ * Sat Jul 19 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.6.20080719git - Compile DRI support. * Sat Jul 19 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.5.20080719git - New snapshot (upstream commit 603a35a670c71d32c4f393e21ed09f87449ebbf6): - 603a35a6: Fix typo in list of supported chips - 3bc154bf: ID: Remove concept of chipset families. - 3ac5a2f5: ID: Update list of supported chipsets, bring in sync with chipsets listed. - edb72452: MC: Make sure MC engine is all idle before setting up the MC. - 4eebf4bc: Define SED var without requiring AC_PROG_SED - 2bc4450a: Use 'git foo' instead of 'git-foo' - 4134177e: Automatically update man page from rhd_id.c - b3717c77: I2C: Fix typo that caused one DDC line to not work properly. - bd14f735: Add proper MCIdle() bits for r6xx/r7xx - 72477c9e: manpage: Add description on the scaling option. - Fix removal of build dir in snapshot script xwnc-0.3.3-6.fc10 ----------------- * Tue Jul 8 18:00:00 2008 Christopher Stone 0.3.3-6 - Try linking with -Wl,--export-dynamic. Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 37 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so blam-1.8.3-13.fc9.i386 requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.i386 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.i386 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.i386 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.i386 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.i386 requires libsqlite3.so nspluginwrapper-1.1.0-1.fc10.i386 requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sooperlooper-1.6.2-1.fc9.i386 requires librubberband.so.1 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.i386 requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.i386 requires libgpm.so.1 xaos-3.2.3-3.fc9.i386 requires libgpm.so.1 xawtv-3.95-8.fc9.i386 requires libgpm.so.1 xemacs-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-nox-21.5.28-8.fc10.i386 requires libgpm.so.1 yelp-2.22.1-2.fc10.i386 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) blam-1.8.3-13.fc9.x86_64 requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.i386 requires gecko-libs = 0:1.9 devhelp-0.19.1-2.fc10.x86_64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.x86_64 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.i386 requires gecko-devel = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.x86_64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.x86_64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.x86_64 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.x86_64 requires libsqlite3.so()(64bit) nspluginwrapper-1.1.0-1.fc10.i386 requires gecko-libs = 0:1.9 nspluginwrapper-1.1.0-1.fc10.x86_64 requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sooperlooper-1.6.2-1.fc9.x86_64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.x86_64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.x86_64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.x86_64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.i386 requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.x86_64 requires libgpm.so.1()(64bit) yelp-2.22.1-2.fc10.x86_64 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) blam-1.8.3-13.fc9.ppc requires gecko-libs = 0:1.9 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.ppc requires gecko-libs = 0:1.9 devhelp-0.19.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.ppc requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc requires gecko-devel = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) liferea-1.4.16b-5.fc10.ppc requires libsqlite3.so nspluginwrapper-1.1.0-1.fc10.ppc requires gecko-libs = 0:1.9 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sooperlooper-1.6.2-1.fc9.ppc requires librubberband.so.1 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so 2:vim-X11-7.1.309-1.fc10.ppc requires libgpm.so.1 2:vim-enhanced-7.1.309-1.fc10.ppc requires libgpm.so.1 xaos-3.2.3-3.fc9.ppc requires libgpm.so.1 xawtv-3.95-8.fc9.ppc requires libgpm.so.1 xemacs-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-common-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc requires libgpm.so.1 xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc requires libgpm.so.1 yelp-2.22.1-2.fc10.ppc requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) devhelp-0.19.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-2.22.1.1-3.fc10.ppc64 requires gecko-libs = 0:1.9 epiphany-devel-2.22.1.1-3.fc10.ppc64 requires gecko-devel = 0:1.9 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gnome-python2-gtkmozembed-2.19.1-16.fc9.ppc64 requires gecko-libs = 0:1.9 gnome-web-photo-0.3-12.fc9.ppc64 requires gecko-libs = 0:1.9 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) liferea-1.4.16b-5.fc10.ppc64 requires libsqlite3.so()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pytrainer-1.5.0.0.1-4.fc10.noarch requires xulrunner = 0:1.9 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sooperlooper-1.6.2-1.fc9.ppc64 requires librubberband.so.1()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) 2:vim-X11-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) 2:vim-enhanced-7.1.309-1.fc10.ppc64 requires libgpm.so.1()(64bit) xaos-3.2.3-3.fc9.ppc64 requires libgpm.so.1()(64bit) xawtv-3.95-8.fc9.ppc64 requires libgpm.so.1()(64bit) xemacs-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-common-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-devel-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) xemacs-nox-21.5.28-8.fc10.ppc64 requires libgpm.so.1()(64bit) yelp-2.22.1-2.fc10.ppc64 requires gecko-libs = 0:1.9 zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From dtimms at iinet.net.au Sun Jul 20 20:15:51 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 21 Jul 2008 06:15:51 +1000 Subject: rakarrack - Guitar Effects Processor In-Reply-To: References: Message-ID: <48839CF7.6050901@iinet.net.au> Harald Hoyer wrote: > Harald Hoyer wrote: >> Anyone interested to maintain and add this to Fedora? >> >> ABOUT >> Rakarrack is a guitar effects processor for GNU / Linux simple and Package submission @ https://bugzilla.redhat.com/show_bug.cgi?id=455953 Anyone interested in reviewing rakarrack (, maybe need reviewer yourself) ? DaveT. From nando at ccrma.Stanford.EDU Sun Jul 20 10:45:09 2008 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sun, 20 Jul 2008 12:45:09 +0200 Subject: Audio SIG - Jacklab spin In-Reply-To: References: <20080710160808.7ef6423a@brian.englab.brq.redhat.com> Message-ID: <1216550709.6668.38.camel@cage.kgw.TU-Berlin.DE> On Thu, 2008-07-10 at 17:40 +0200, Harald Hoyer wrote: > Michal Schmidt wrote: > > On Thu, 10 Jul 2008 13:40:26 +0200 > > Harald Hoyer wrote: > > > >> Anyone interested in an audio SIG? > >> > >> We could create a jacklab like spin ( http://jacklab.org/ ) with > >> jackd as the main audio daemon. (or Ubuntu Studio, the Gentoo pro audio overlay, 64Studio, etc, etc, pretty much all big distros already have it) > > Would the absence of a real-time kernel variant in Fedora be a problem > > for such a spin? Yes. > > Fedora kernel only has voluntary preemption enabled. > > All the audio-specialized distributions I've heard about ship with an > > RT-patched kernel. > > > > Absence is no "problem" on a modern desktop (my desktop :-) ), though a > real-time kernel would definitely improve the latency for slower systems. Nope. It is a problem. A stock Fedora kernel can have latency problems if you use jackd with 64 or 128 frames per period[*]. One hiccup is enough to ruin a performance or a recording session. That is why other audio oriented distros use a realtime patched kernel (as does Planet CCRMA, which I maintain). You could define your "target user base" to not need that level of performance, and then sidestep the issue. But then you can't compare a hypothetical Fedora JackStudio or whatever distro with other audio oriented distros that have a realtime patched kernel. > Maybe we could "maintain" a kernel-rt package or persuade our RHEL5 kernel team > to provide a rt-kernel (with the benefit of more QA :) ). I've been "maintaining" one for Planet CCRMA since 2001. It is not fun (well, it used to be, many years ago) and it is a worthy task for Sisyphus. I made some noise in the fedora audio list a while back about this, but there's no manpower for doing a realtime kernel on Fedora. RedHat itself does have a realtime patched MRG kernel for RHEL. -- Fernando [*] depends on your particular hardware configuration, sound card model, interrupt sharing, usage patterns, and the phase of the moon for all I know :-) From sundaram at fedoraproject.org Sun Jul 20 12:30:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 20 Jul 2008 18:00:58 +0530 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807190535.36120.konrad@tylerc.org> References: <200807181659.33092.jwilson@redhat.com> <200807190535.36120.konrad@tylerc.org> Message-ID: <48833002.2070302@fedoraproject.org> Konrad Meyer wrote: > Quoth drago01: >> On Sat, Jul 19, 2008 at 12:33 AM, Kevin Kofler > wrote: >>> Jarod Wilson redhat.com> writes: >>>> Unless someone objects, I'll probably just go ahead and do that this > weekend, >>>> rather than busticate rawhide even temporarily. >>> kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding them. >> is there a reason for that? (closed ACLs) > > KDE is a major system component and the KDE team (which is something like 6-8 > people) does a very good job of fixing things as soon as they need fixing. That's really not a good reason to keep them closed. Just because a team is doing a good job doesn't mean that they should prevent others from helping. Rahul From nando at ccrma.Stanford.EDU Sun Jul 20 12:35:15 2008 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sun, 20 Jul 2008 14:35:15 +0200 Subject: rakarrack - Guitar Effects Processor In-Reply-To: <487FBDC4.2070004@iinet.net.au> References: <487FBDC4.2070004@iinet.net.au> Message-ID: <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> On Fri, 2008-07-18 at 07:46 +1000, David Timms wrote: > Harald Hoyer wrote: > > Harald Hoyer wrote: > >> Anyone interested to maintain and add this to Fedora? > >> > >> > >> ABOUT > >> Rakarrack is a guitar effects processor for GNU / Linux simple and > >> easy to use but it contains features that make it unique in this field > Was there any takers on making a fedora package for this ? > > If not I'll use the planetccrma spec, updating to v0.2. 0.2.x is now in Planet CCRMA thanks to Arnaud from IRCAM. Great if you can/want to migrate it to Fedora! I would appreciate it if you could keep the extra categories in the desktop file, they are used to classify audio apps in an extra menu I added to Planet CCRMA (and rakarrack would drop out of it if they were ommited). Thanks! -- Fernando > Hans: saw your response to HHs next message: is there any special tricks > for getting 'realtimeish' apps to work nicely in fedora ? From jwboyer at gmail.com Sun Jul 20 13:10:19 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 20 Jul 2008 09:10:19 -0400 Subject: ENVR checking In-Reply-To: <20080720091033.7e1bfdf7.mschwendt@gmail.com> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> Message-ID: <1216559419.13063.15.camel@vader.jdub.homelinux.org> On Sun, 2008-07-20 at 09:10 +0200, Michael Schwendt wrote: > On Sun, 20 Jul 2008 06:58:38 +0100, Tim Jackson wrote: > > > What happened to that script that used to run and check all the ENVRs > > across releases to make sure that there was a proper upgrade path (i.e. > > F8 < F8-updates < F9 etc.)? That was really useful. > > > > I have had a disappointing experience on a couple of machines with doing > > upgrades from F-8 to F-9, where there are a lot of F-8 packages still > > hanging around that shouldn't be, mostly due to ENVR problems (F-8 updates > > > F-9) > > Still in cvs: > http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora > > It used to be run automatically after each Extras push, but when the > build system moved to koji and bodhi, this feature was killed. Probably > it was considered unimportant or a source of "spam". That's a problem It's still important. Apparently not enough to hook into the build/update systems at the moment though, because there are bigger fish to fry. > Recently I've seen a comment somewhere that Josh Boyer seems to have > a similar but different script somewhere. I don't know how it differs. It hooks into koji to see if there are builds that are in koji but not in a repo that would fix things. That feature is mostly only useable during rawhide freezes. josh From sundaram at fedoraproject.org Sun Jul 20 14:36:57 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 20 Jul 2008 20:06:57 +0530 Subject: Playground patches Message-ID: <48834D89.1010806@fedoraproject.org> Hi Pretty interesting. Has been suggested in this list before. Can be quite useful to improve QA http://blogs.gnome.org/tthurman/2008/07/20/playground-patches/ "Today I was thinking, ?Wouldn?t it be nice, and save me quite a bit of time, if when you look at a patch on Bugzilla, there was a Test link next to the Edit and Diff links? And when you clicked it, it would apply the patch to trunk, and if it worked it would configure and make it and then drop you to a shell so you could see what had happened.? So I made it." Rahul From jkeating at redhat.com Sun Jul 20 15:00:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Jul 2008 11:00:43 -0400 Subject: Pungi with x86_64 packages only In-Reply-To: <4882F6B0.6000905@redhat.com> References: <1216480844.3179.0.camel@localhost.localdomain> <48826909.2010104@redhat.com> <1216512440.5700.0.camel@localhost.localdomain> <4882F6B0.6000905@redhat.com> Message-ID: <1216566043.12190.0.camel@localhost.localdomain> On Sun, 2008-07-20 at 10:26 +0200, Gerd Hoffmann wrote: > Is there any reason for that restriction? As I understand it only the > BuildInstall stage must run on the architecture (and distro) it is > composing due to running anaconda tools. Faking out yum as far as the system arch is concerned for the purpose of depresolving is fragile at best. It's really beyond the scope of what Pungi is designed to do, and I don't really want to make it part of the feature set. Is there not a yum-util that would do what you need? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 s-t-rhbugzilla at wwwdotorg.org Sun Jul 20 15:14:03 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Sun, 20 Jul 2008 09:14:03 -0600 Subject: ENVR checking In-Reply-To: <20080720091033.7e1bfdf7.mschwendt@gmail.com> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> Message-ID: <1216567003.3436.TMDA@tmda.severn.wwwdotorg.org> Michael Schwendt wrote: > On Sun, 20 Jul 2008 06:58:38 +0100, Tim Jackson wrote: > >> What happened to that script that used to run and check all the ENVRs >> across releases to make sure that there was a proper upgrade path (i.e. >> F8 < F8-updates < F9 etc.)? That was really useful. >> >> I have had a disappointing experience on a couple of machines with doing >> upgrades from F-8 to F-9, where there are a lot of F-8 packages still >> hanging around that shouldn't be, mostly due to ENVR problems (F-8 updates >> > F-9) > > Still in cvs: > http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora > > It used to be run automatically after each Extras push, but when the > build system moved to koji and bodhi, this feature was killed. Probably > it was considered unimportant or a source of "spam". That's a problem > with stuff that isn't backed up or enforced by project leadership. When > I started to run it manually after some time prior to the next release > of Fedora, the number of negative voices was overwhelming... Hmm. That negative feedback kinda sucks. I was personally hit by this issue upgrading from F-8 to F-9. It didn't actually break my upgrade, but it would have nice not to encounter, and seemingly very easily avoided. Perhaps this issue should be proposed as a discussion point for the next FESCO meeting? I filed bugs, and one of the two rpms I had not-upgraded was re-released as a new update for F-9 which solved that. The other, grub, is a bit more problematic, since there's no way to solve it in the actual preupgrade/CD-upgrade step, (since the install CD and initial F-9 release probably can't be remade to fix it), and any new F-9 features in grub could conceivably be relevant to an upgrade. From kanarip at kanarip.com Sun Jul 20 15:27:06 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 20 Jul 2008 17:27:06 +0200 Subject: Mailing list for Spins SIG Message-ID: <4883594A.4000309@kanarip.com> Hi there, there is a few new mailing lists for the Spin SIG: To watch commits to the spin-kickstarts GIT repository, subscribe to: https://fedorahosted.org/mailman/listinfo/spin-kickstarts-commits For general Fedora Spin SIG things, subscribe to: http://lists.fedoraproject.org/mailman/listinfo/fedora-spins Kind regards, Jeroen van Meeuwen -kanarip From nicolas.mailhot at laposte.net Sun Jul 20 15:39:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 20 Jul 2008 17:39:52 +0200 Subject: ENVR checking In-Reply-To: <20080720091033.7e1bfdf7.mschwendt@gmail.com> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> Message-ID: <1216568392.6585.2.camel@rousalka.okg> Le dimanche 20 juillet 2008 ? 09:10 +0200, Michael Schwendt a ?crit : > It used to be run automatically after each Extras push, but when the > build system moved to koji and bodhi, this feature was killed. Please reinstall it. It had a very beneficial effect on devel, and the deterioration lately is very perceptible. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pasik at iki.fi Sun Jul 20 16:11:41 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sun, 20 Jul 2008 19:11:41 +0300 Subject: Packaging nss-ldapd for fedora Message-ID: <20080720161141.GH3771@edu.joroinen.fi> Hello! Anyone planning to upload/maintain nss-ldapd to fedora? Seems like a better solution than nss-ldap.. http://ch.twi.tudelft.nl/~arthur/nss-ldapd/ -- Pasi From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 20 18:18:08 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 20 Jul 2008 20:18:08 +0200 Subject: Packaging nss-ldapd for fedora In-Reply-To: <20080720161141.GH3771@edu.joroinen.fi> (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen's?= message of "Sun, 20 Jul 2008 19:11:41 +0300") References: <20080720161141.GH3771@edu.joroinen.fi> Message-ID: <87tzekmnbz.fsf@sheridan.bigo.ensc.de> Pasi K?rkk?inen writes: > Seems like a better solution than nss-ldap.. For the beginning, it would be really nice when Fedora 9 and RHEL 5.2 get a *working* nss_ldap and nscd. Current situation makes it nearly impossible to use LDAP NSS with a recent RH distribution :( Enrico From jos at xos.nl Sun Jul 20 19:09:30 2008 From: jos at xos.nl (Jos Vos) Date: Sun, 20 Jul 2008 21:09:30 +0200 Subject: Fedora 9 on ASUS EeePC 900 Message-ID: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> Hi, I'm investigating the issues that I can expect when I want to install Fedora 9 on an ASUS EeePC 900. I found some references, mainly referring to Fedora 8 and the EeePC 701, and I found the Fedora Wiki page , that lists various issues. Will the wired Ethernet still not work for installing F9, for example? Any references to more detailed information are welcome. Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From arjan at infradead.org Sun Jul 20 19:40:48 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 20 Jul 2008 12:40:48 -0700 Subject: Fedora 9 on ASUS EeePC 900 In-Reply-To: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> References: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> Message-ID: <20080720124048.1ae3cd74@infradead.org> On Sun, 20 Jul 2008 21:09:30 +0200 Jos Vos wrote: > Hi, > > I'm investigating the issues that I can expect when I want to install > Fedora 9 on an ASUS EeePC 900. > > I found some references, mainly referring I recently installed F9 on an 901 (the one with an atom cpu) turns out the ethernet is a new chip, for which a patch got posted to lkml 3 days or so ago (search for "L1E") -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jos at xos.nl Sun Jul 20 20:03:53 2008 From: jos at xos.nl (Jos Vos) Date: Sun, 20 Jul 2008 22:03:53 +0200 Subject: Fedora 9 on ASUS EeePC 900 In-Reply-To: <20080720124048.1ae3cd74@infradead.org> References: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> <20080720124048.1ae3cd74@infradead.org> Message-ID: <20080720200353.GA20337@jasmine.xos.nl> On Sun, Jul 20, 2008 at 12:40:48PM -0700, Arjan van de Ven wrote: > I recently installed F9 on an 901 (the one with an atom cpu) > > turns out the ethernet is a new chip, for which a patch got posted to > lkml 3 days or so ago (search for "L1E") I was looking at the 900, as I thought the 901 is not yet available (at least not here in NL). The 901 is still preloaded with Xandros? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From moe at blagblagblag.org Sun Jul 20 20:13:56 2008 From: moe at blagblagblag.org (jeff) Date: Sun, 20 Jul 2008 17:13:56 -0300 Subject: Fedora 9 on ASUS EeePC 900 In-Reply-To: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> References: <200807201909.m6KJ9U7p019750@jasmine.xos.nl> Message-ID: <48839C84.2030406@blagblagblag.org> Jos Vos wrote: > Hi, > > I'm investigating the issues that I can expect when I want to install > Fedora 9 on an ASUS EeePC 900. > > I found some references, mainly referring to Fedora 8 and the EeePC 701, > and I found the Fedora Wiki page , > that lists various issues. > > Will the wired Ethernet still not work for installing F9, for example? > > Any references to more detailed information are welcome. Ethernet works with default fedora kernel with atl2 driver (well, with -libre kernel, I presume fedora's too). Wifi does not work, but just in the last week Nick Kossifidis got a driver built which works (and I'm happily using): http://www.kernel.org/pub/linux/kernel/people/mickflemm/compat-wireless-2008-07-03-ath5k.tar.bz2 Note this ath5k driver does not depend on a binary HAL. Yay Nick! :) This did not build for me against kernel-libre-2.6.25.10-86.fc9.1.i686 packages but did build and work with linux-2.6.26-libre1.tar.bz2. The driver for the camera is uvcvideo and I think is available in stock fedora kernel and hit linus in 2.6.26 iirc. I just install it from an external USB drive. You should be able to pxeboot it too. I have random notes, code, scripts etc here: ftp://ftp.blagblagblag.org/pub/BLAG/developers/jebba/eee/ ftp://ftp.blagblagblag.org/pub/BLAG/developers/jebba/eee/FREEEEE.TXT -Jeff P.S. Now we just need EeePC coreboot v3 ;) From bpepple at fedoraproject.org Sun Jul 20 22:23:54 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 20 Jul 2008 18:23:54 -0400 Subject: [Reminder] FESCo election closes on July 21st Message-ID: <1216592634.28300.14.camel@kennedy> Hi all, This is a reminder that the current FESCo election(1) is open until Monday, July 21st, 2008 23:59 UTC. So, if you haven't gotten around to voting yet, there is still a little over 24 hours to rectify that. (1) https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00005.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From martin.langhoff at gmail.com Sun Jul 20 23:12:00 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 21 Jul 2008 11:12:00 +1200 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <20080719114834.0273e605.mschwendt@gmail.com> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> <46a038f90807190147m21b8b042p67f299013a25b3fe@mail.gmail.com> <20080719114834.0273e605.mschwendt@gmail.com> Message-ID: <46a038f90807201612i4e3abdc1i17c1cc25bf8de13d@mail.gmail.com> On Sat, Jul 19, 2008 at 9:48 PM, Michael Schwendt wrote: > On Sat, 19 Jul 2008 20:47:01 +1200, Martin Langhoff wrote: > >> Any reason rpmbuild -bs checks dependencies? > > Yes. To check that you don't build and publish a src.rpm which > has unresolved build dependencies. If you want to skip that check, > use -bs --nodeps but be careful. Ok. In the script I am using the rpm gets built right after with mock, so it makes sense to use --nodeps. Funny thing though, I had searched the man page for 'dep' hoping to find the 'nodeps' option. It is not mentioned anywhere. Perhaps on purpose? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From konrad at tylerc.org Mon Jul 21 02:51:44 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Sun, 20 Jul 2008 19:51:44 -0700 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <48833002.2070302@fedoraproject.org> References: <200807181659.33092.jwilson@redhat.com> <200807190535.36120.konrad@tylerc.org> <48833002.2070302@fedoraproject.org> Message-ID: <200807201951.45114.konrad@tylerc.org> Quoth Rahul Sundaram: > Konrad Meyer wrote: > > Quoth drago01: > >> On Sat, Jul 19, 2008 at 12:33 AM, Kevin Kofler > > wrote: > >>> Jarod Wilson redhat.com> writes: > >>>> Unless someone objects, I'll probably just go ahead and do that this > > weekend, > >>>> rather than busticate rawhide even temporarily. > >>> kdebase and kdebase3 have closed ACLs. We'll take care of rebuilding them. > >> is there a reason for that? (closed ACLs) > > > > KDE is a major system component and the KDE team (which is something like 6-8 > > people) does a very good job of fixing things as soon as they need fixing. > > That's really not a good reason to keep them closed. Just because a team > is doing a good job doesn't mean that they should prevent others from > helping. > > Rahul With something as large and complicated as kde, a dedicated team who understands the package doesn't prevent others from helping, it prevents others from making mistakes. See also the kernel. -- Conrad Meyer -------------- 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 Mon Jul 21 03:00:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 21 Jul 2008 08:30:52 +0530 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807201951.45114.konrad@tylerc.org> References: <200807181659.33092.jwilson@redhat.com> <200807190535.36120.konrad@tylerc.org> <48833002.2070302@fedoraproject.org> <200807201951.45114.konrad@tylerc.org> Message-ID: <4883FBE4.6050100@fedoraproject.org> Konrad Meyer wrote: > With something as large and complicated as kde, a dedicated team who > understands the package doesn't prevent others from helping, it prevents > others from making mistakes. See also the kernel. Everybody makes mistakes including the KDE team. I simply don't agree with your premise that others cannot make reasonable (even trivial) changes without making mistakes. KDE is also not at the same level as kernel or glibc. Rahul From jonstanley at gmail.com Mon Jul 21 03:15:48 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 20 Jul 2008 23:15:48 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <4883FBE4.6050100@fedoraproject.org> References: <200807181659.33092.jwilson@redhat.com> <200807190535.36120.konrad@tylerc.org> <48833002.2070302@fedoraproject.org> <200807201951.45114.konrad@tylerc.org> <4883FBE4.6050100@fedoraproject.org> Message-ID: On Sun, Jul 20, 2008 at 11:00 PM, Rahul Sundaram wrote: > Everybody makes mistakes including the KDE team. I simply don't agree with > your premise that others cannot make reasonable (even trivial) changes > without making mistakes. KDE is also not at the same level as kernel or > glibc. Let's compare apples to apples and take the GNOME packages - the few I spot checked (nautilus, gnome-desktop, gdm - all obviously critically important to the default GNOME desktop) have open ACL's. I really don't think the KDE team has ground to stand on here - sorry. From howard at cohtech.com Mon Jul 21 08:28:22 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Mon, 21 Jul 2008 09:28:22 +0100 Subject: Packaging nss-ldapd for fedora In-Reply-To: <87tzekmnbz.fsf@sheridan.bigo.ensc.de> References: <20080720161141.GH3771@edu.joroinen.fi> <87tzekmnbz.fsf@sheridan.bigo.ensc.de> Message-ID: <488448A6.4000308@cohtech.com> Enrico Scholz wrote: > Pasi K?rkk?inen writes: > > >> Seems like a better solution than nss-ldap.. >> > > > For the beginning, it would be really nice when Fedora 9 and RHEL 5.2 > get a *working* nss_ldap and nscd. Current situation makes it nearly > impossible to use LDAP NSS with a recent RH distribution :( > > > > Enrico > > Enrico, could you expand on the issues you see with nss_ldap under Fedora. I have recently done some work on the Kerberos ticket handling in nss_ldap and am now not seeing major problems with this combination. I do still see failures in the nss_ldap code occassionally but I think this is in the use of the kerberos/gssapi/sasl/ldap libraries rather than the code itself. Have yet to pin this down. So any more information would be nice. Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Mon Jul 21 08:42:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 21 Jul 2008 10:42:16 +0200 Subject: Heads-up: rubberband 1.2 API breakage In-Reply-To: References: Message-ID: <48844BE8.3040300@hhs.nl> Michel Salim wrote: > I'm committing vamp-plugins-sdk 1.3 and Rubberband 1.2, the latter of > which provides librubberband.so.2 rather than .so.1, to Rawhide. > > These affected packages link against librubberband.so.1 and need to be rebuild: > sonic-visualiser (which I maintain) > sooperlooper > > Also, ardour is listed on Rubber Band's webpage as supporting > rubberband, but our package does not use it as yet. Anthony and Hans? > I've rebuild sooperlooper, but for some reason sooperlooper now freezes on startup on my test (rawhide) system. Since the F-9 version with the F-9 rubberband also freezes on this system, I guess the cause lays elsewhere. So I've submitted a rebuild with a patch for the new rubberband to the buildsys for now. Some testing would be appreciated. Regards, Hans From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 21 09:21:49 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 21 Jul 2008 11:21:49 +0200 Subject: Packaging nss-ldapd for fedora In-Reply-To: <488448A6.4000308@cohtech.com> (Howard Wilkinson's message of "Mon, 21 Jul 2008 09:28:22 +0100") References: <20080720161141.GH3771@edu.joroinen.fi> <87tzekmnbz.fsf@sheridan.bigo.ensc.de> <488448A6.4000308@cohtech.com> Message-ID: <87ljzva8ya.fsf@fc5.bigo.ensc.de> Howard Wilkinson writes: > Enrico, could you expand on the issues you see with nss_ldap under > Fedora. after some time, bash hangs while expanding e.g. ~en; koji/bodhi hang uninterruptible (only 'kill -9' helps; ^Z + ^C are not working) when nscd is not running (which segfaults periodically). Bugzilla is full with deep-red reports against nss_ldap :( Enrico From rjones at redhat.com Mon Jul 21 09:17:17 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 10:17:17 +0100 Subject: Broken dependencies in Fedora 8 - 2008-07-19 In-Reply-To: <20080719111855.4461.12698@faldor.intranet> References: <20080719111855.4461.12698@faldor.intranet> Message-ID: <20080721091717.GA28672@amd.home.annexia.org> On Sat, Jul 19, 2008 at 11:18:55AM -0000, Michael Schwendt wrote: > rjones AT redhat.com > ocaml-json-static-0.9.6-5.fc8.i386 > ocaml-json-static-0.9.6-5.fc8.ppc > ocaml-json-static-0.9.6-5.fc8.x86_64 With any luck I should have (finally) fixed this one. 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 howard at cohtech.com Mon Jul 21 10:10:33 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Mon, 21 Jul 2008 11:10:33 +0100 Subject: Packaging nss-ldapd for fedora In-Reply-To: <87ljzva8ya.fsf@fc5.bigo.ensc.de> References: <20080720161141.GH3771@edu.joroinen.fi> <87tzekmnbz.fsf@sheridan.bigo.ensc.de> <488448A6.4000308@cohtech.com> <87ljzva8ya.fsf@fc5.bigo.ensc.de> Message-ID: <48846099.4030300@cohtech.com> Enrico Scholz wrote: > Howard Wilkinson writes: > > >> Enrico, could you expand on the issues you see with nss_ldap under >> Fedora. >> > > after some time, bash hangs while expanding e.g. ~en; koji/bodhi > hang uninterruptible (only 'kill -9' helps; ^Z + ^C are not working) > when nscd is not running (which segfaults periodically). > > Bugzilla is full with deep-red reports against nss_ldap :( > > > Enrico > > Enrico, can you point me at the bugzilla reports please. I have been following the ones on pdal but if there is another source I would like to see it. Do the problems you see occur when using kerberos to autheticate to the ldap server? Or are they in another path? You may need to set "bind_policy soft" to get rid of the hangs. Things that need some attention in nss_ldap include the ability to fail over to a second ldap server, which may be your real problem. Anyway, the version I run is 259 with my patches for the kerberos library included (see PDAL bugzilla 298) and I get occassional segfaults from nscd but otherwise it works nicely with kerberos keytabs and file based tickets. I have yet to test memory based tickets. Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buc at odusz.so-cdu.ru Mon Jul 21 12:16:08 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 21 Jul 2008 16:16:08 +0400 Subject: Packaging nss-ldapd for fedora In-Reply-To: <20080720161141.GH3771@edu.joroinen.fi> References: <20080720161141.GH3771@edu.joroinen.fi> Message-ID: <48847E08.8020201@odu.neva.ru> Pasi K?rkk?inen wrote: > Hello! > > Anyone planning to upload/maintain nss-ldapd to fedora? > > Seems like a better solution than nss-ldap.. > > http://ch.twi.tudelft.nl/~arthur/nss-ldapd/ > Looks interesting... Besides its useful features (fe. client/server splitting in the same manner as Samba's winbindd does), this project is actively developed now, and even the OpenLDAP upstream has written an overlay that implements their own alternative "server" part for nss-ldapd. I'll try to consider it more closely this week... Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From yersinia.spiros at gmail.com Mon Jul 21 12:37:51 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Mon, 21 Jul 2008 14:37:51 +0200 Subject: Packaging nss-ldapd for fedora In-Reply-To: <48847E08.8020201@odu.neva.ru> References: <20080720161141.GH3771@edu.joroinen.fi> <48847E08.8020201@odu.neva.ru> Message-ID: Just for info, the nss-ldapd design look very similar to AIX 5L ldap client design. Regards On Mon, Jul 21, 2008 at 2:16 PM, Dmitry Butskoy wrote: > Pasi K?rkk?inen wrote: > >> Hello! >> >> Anyone planning to upload/maintain nss-ldapd to fedora? >> Seems like a better solution than nss-ldap.. >> >> http://ch.twi.tudelft.nl/~arthur/nss-ldapd/ >> >> > > Looks interesting... > > Besides its useful features (fe. client/server splitting in the same manner > as Samba's winbindd does), this project is actively developed now, and even > the OpenLDAP upstream has written an overlay that implements their own > alternative "server" part for nss-ldapd. > > I'll try to consider it more closely this week... > > > Dmitry Butskoy > http://www.fedoraproject.org/wiki/DmitryButskoy > > > -- > 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 jkeating at redhat.com Mon Jul 21 14:21:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jul 2008 10:21:21 -0400 Subject: Late reminder, Fedora 10 Alpha (nonblocking) freeze tomorrow! Message-ID: <1216650081.12190.9.camel@localhost.localdomain> We have our first development freeze of the Fedora 10 cycle tomorrow. This is the alpha freeze, which is non-blocking. Release Engineering will be making a freeze inside the buildsystem of tomorrow's rawhide content. This will be the basis of the Fedora 10 Alpha release. Rawhide will continue to move forward with new builds. Things which are critical to have in Alpha should be brought to release engineering's attention via our Trac queue: https://fedorahosted.org/rel-eng/newticket Sorry for the late reminder! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From gdk at redhat.com Mon Jul 21 14:36:08 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 21 Jul 2008 10:36:08 -0400 (EDT) Subject: Announcing the Fedora OLPC Special Interest Group Message-ID: I've already sent this note to a bunch of lists, but this is the list that really counts. You folks are the ones who will make or break this effort. Much of the work that lies before us is exactly the kind of work that all of you have been doing for years now. So please, join up. We could really use the help. Those of you whom I know personally, I will be begging for your help off-list in a somewhat less dignified manner. ;) * * * The engineers at OLPC are busy building an educational experience for the kids of the world. They are basing their excellent work on Fedora. Their time is stretched perilously thin. Every hour an overworked OLPC engineer spends doing Fedora work is an hour they could be spending doing something else. We in the Fedora community can therefore have a huge, direct, and immediate impact on the success of the OLPC project. Thus, I am proud to announce the formation of the Fedora OLPC Special Interest Group. Our mission: to provide the OLPC project with a strong, sustainable, scalable, community-driven base platform for innovation. Immediate Goals: 1. To identify and take responsible ownership of as many OLPC base packages as possible. 2. To maintain an excellent Sugar environment for Fedora, including a dedicated Sugar spin. 3. To identify useful opportunities for collaboration (infrastructure, localization, etc.) We should convene our first meeting as soon as possible. If you are interested in participating, please join the Fedora OLPC mailing list here and introduce yourself: https://www.redhat.com/mailman/listinfo/fedora-olpc-list --g From dominik at greysector.net Mon Jul 21 14:51:14 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 21 Jul 2008 16:51:14 +0200 Subject: Late reminder, Fedora 10 Alpha (nonblocking) freeze tomorrow! In-Reply-To: <1216650081.12190.9.camel@localhost.localdomain> References: <1216650081.12190.9.camel@localhost.localdomain> Message-ID: <20080721145114.GA31896@mokona.greysector.net> On Monday, 21 July 2008 at 16:21, Jesse Keating wrote: > We have our first development freeze of the Fedora 10 cycle tomorrow. > This is the alpha freeze, which is non-blocking. Release Engineering > will be making a freeze inside the buildsystem of tomorrow's rawhide > content. This will be the basis of the Fedora 10 Alpha release. > Rawhide will continue to move forward with new builds. Things which are > critical to have in Alpha should be brought to release engineering's > attention via our Trac queue: https://fedorahosted.org/rel-eng/newticket Is there a chance you could handle ticket #741 before the freeze? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buc at odusz.so-cdu.ru Mon Jul 21 14:55:17 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 21 Jul 2008 18:55:17 +0400 Subject: Packaging nss-ldapd for fedora In-Reply-To: <48847E08.8020201@odu.neva.ru> References: <20080720161141.GH3771@edu.joroinen.fi> <48847E08.8020201@odu.neva.ru> Message-ID: <4884A355.4060903@odu.neva.ru> Dmitry Butskoy wrote: > Pasi K?rkk?inen wrote: >> Hello! >> >> Anyone planning to upload/maintain nss-ldapd to fedora? >> Seems like a better solution than nss-ldap.. >> >> http://ch.twi.tudelft.nl/~arthur/nss-ldapd/ >> > > Looks interesting... > > Besides its useful features (fe. client/server splitting in the same > manner as Samba's winbindd does), this project is actively developed > now, and even the OpenLDAP upstream has written an overlay that > implements their own alternative "server" part for nss-ldapd. > > I'll try to consider it more closely this week... Well, It provides NSS stuff only (whereas the ordinary nss_ldap provides both NSS and PAM with one common config file). It seems that upstream is focused on NSS only. Two possible ways: 1) The current nss_ldap could be split to nss_ldap and pam_ldap (it looks obvious because both have individual source tarballs). Then "alternatives" could be used to switch between the old nss_ldap and new nss-ldapd implementations. 2) Nss-ldapd's "nss_ldap.so" could be just renamed to, say, "nss_ldapd.so" (and use "ldapd" in /etc/nsswitch.conf). This way alternatives are not needed. Anyway, from the current point of view, the switch to nss-ldapd will increase the number of configuration files to edit (/etc/ldap.conf for PAM, and /etc/nss-ldapd.conf for NSS), and both files look very identical... Certainly an alternate PAM implementation seems not needed, the client/server here is useful for NSS only. But it would be very fine if nss-ldapd could use the same config file as pam_ldap uses (IOW, how the current nss_ldap does). I don't know whether it is possible now or intend to be possible in the future. Any comments? Does anyone have good contact with upstream? ~buc From gary at mlbassoc.com Mon Jul 21 15:53:39 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Mon, 21 Jul 2008 09:53:39 -0600 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215269547.10393.848.camel@pmac.infradead.org> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> Message-ID: <4884B103.2060600@mlbassoc.com> David Woodhouse wrote: > On Sat, 2008-07-05 at 16:10 +0200, Enrico Scholz wrote: > >> David Woodhouse writes: >> >> >>>> Something like >>>> >>>> | --enable-targets=%_host >>>> >>>> should be added everytime to allow e.g. 'strip' to work on both native >>>> and on target binaries. This is required when building cross-rpms which >>>> are providing target and native binaries. >>>> >>> Is it really? You already have to use the appropriate compiler and >>> linker for native vs. target binaries -- why can't you use the >>> appropriate version of 'strip', too? >>> >> rpm magic; final %__spec_install_post makes something like >> >> + /usr/lib/rpm/redhat/brp-compress >> + /usr/lib/rpm/redhat/brp-strip-static-archive arm-iwmmxt-linux-gnueabi-strip >> + /usr/lib/rpm/redhat/brp-strip-comment-note arm-iwmmxt-linux-gnueabi-strip arm-iwmmxt-linux-gnueabi-objdump >> + >> >> and does not differ between target and native binaries. >> > > Hm, OK. I suppose it doesn't hurt much. Updated patch then... > <...snip...> Has this work/discussion progressed at all? I'm interested in cross tools (x86->ppc) and would like to get involved in making these happen. Any pointers on how I can get started (where/how to pick up the current work, etc)? Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From poelstra at redhat.com Mon Jul 21 15:39:17 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 21 Jul 2008 08:39:17 -0700 Subject: Feature Process Improvements Message-ID: <4884ADA5.3010701@redhat.com> I was recently talking with Paul Frields about how to make the feature process more accessible... this combined with feedback in the rpm thread have led to a (hopefully) clearer presentation of how the feature process works. FIRST: Paul did a great job reorganizing the content on the main page. None of the content has changed, but the presentation is a lot simpler and less overwhelming. https://fedoraproject.org/wiki/Features/Policy I still need to add definitions and guidance for what belongs in each section of the form. SECOND: We are proposing new category names to make it more self-evident which state a feature page is in. Unless there are objections I plan to run this past FESCo for a sanity check this coming Thursday and start using them thereafter--including converting the category names for existing pages. The new category names would look like this: Category:FeaturePageIncomplete (was ProposedFeature)--every feature starts in this category and returns to this category if it is reviewed or voted on and needs more work. Category:FeatureReadyForWrangler (was ProposedF10)--feature owner signals that their feature page is complete and requests that FESco review and accept it for the release under development Category:FeatureReadyForFesco (was ProposedF10)--Feature wrangler changes features to this category when they are ready for FESCo vote Category:FeatureAcceptedF10 (unchanged)--voted on and accepted by fesco A draft updated illustration is here: http://poelstra.fedorapeople.org/misc/feature-process-flow-v3.2.png Source: http://poelstra.fedorapeople.org/misc/feature-process-flow-v3.2.odg Thanks also to Paul for his ideas and help on the illustration! John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From wwoods at redhat.com Mon Jul 21 16:10:37 2008 From: wwoods at redhat.com (Will Woods) Date: Mon, 21 Jul 2008 12:10:37 -0400 Subject: Heads up - Mono In-Reply-To: <1dedbbfc0807181412k29e6e339j497cfcf903f3e44@mail.gmail.com> References: <1216375212.21361.3.camel@T7.Linux> <1dedbbfc0807181316s328e697dkc1f70c5066f30867@mail.gmail.com> <20080718202236.GA9838@nostromo.devel.redhat.com> <1dedbbfc0807181337q4471ce76nf564a4c5e5cbd3f7@mail.gmail.com> <1216414228.9803.5.camel@metroid.rdu.redhat.com> <1dedbbfc0807181412k29e6e339j497cfcf903f3e44@mail.gmail.com> Message-ID: <1216656637.27048.7.camel@metroid.rdu.redhat.com> On Fri, 2008-07-18 at 23:12 +0200, David Nielsen wrote: > Then how about: what we ship right now in F9 is a preview release to > this update, having the same Mono throughout our releases is easier to > maintain.. this is aside the bugfixes and memory usage/performance > enhancements that come with Mono 2.0, all things that will in the end > benefit Fedora and our users. Also pushing newer versions of the stack > will enable us to support applications more widely across the stack. Ah! I wasn't aware that that mono-1.9.x was actually a preview of Mono 2.0. Indeed, It looks like it provides all the same stuff and doesn't involve an soname bump, either. That's totally reasonable, then - at least for F9. I've got no objections there. Thanks for correcting me. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From stickster at gmail.com Mon Jul 21 16:54:15 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 21 Jul 2008 12:54:15 -0400 Subject: Feature Process Improvements In-Reply-To: <4884ADA5.3010701@redhat.com> References: <4884ADA5.3010701@redhat.com> Message-ID: <1216659255.28722.1.camel@victoria> On Mon, 2008-07-21 at 08:39 -0700, John Poelstra wrote: > I was recently talking with Paul Frields about how to make the feature > process more accessible... this combined with feedback in the rpm thread > have led to a (hopefully) clearer presentation of how the feature > process works. > > FIRST: > Paul did a great job reorganizing the content on the main page. None of > the content has changed, but the presentation is a lot simpler and less > overwhelming. > https://fedoraproject.org/wiki/Features/Policy > > I still need to add definitions and guidance for what belongs in each > section of the form. I put some starters in comment form in the empty template. Maybe they should be more visible? https://fedoraproject.org/wiki/Features/EmptyTemplate -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sgrubb at redhat.com Mon Jul 21 17:12:40 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 21 Jul 2008 13:12:40 -0400 Subject: consolidating on gnupg2 in F10 In-Reply-To: References: <20080715154726.GB24550@nostromo.devel.redhat.com> Message-ID: <200807211312.41243.sgrubb@redhat.com> On Friday 18 July 2008 09:11:21 Rex Dieter wrote: > Bill Nottingham wrote: > > For a really long time now, we've shipped both gnupg and gnupg2 > > in Fedora. In fact, in Fedora 9 a relatively standard install will > > get both installed. > > > It appears a good number of these can be ported to gnupg2, if not > > all of them. Should we wire up a feature page? > > Imo, yes, it's a worthy goal to get these ported so that at least gnupg(1) > doesn't land in any default install. > > fyi, here's my inquiry upstrem on whether it's possible or a good idea to > try dropping gnupg1: > http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024485.html > > answer: probably not a good idea. Why did you come to that conclusion? We don't support IDEA and Suse did mention that they have switched to only GPG2. The only caution is around gpg-agent. > So, that leaves consolidating/standardizing on gnupg2, as something still > worthwhile. Agreed. We need to pursue this as GPG1 cannot take advantage of any FIPS-140-2 certified libraries. We need to find the rough spots and work them out. -Steve From limb at jcomserv.net Mon Jul 21 17:21:24 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 21 Jul 2008 12:21:24 -0500 (CDT) Subject: ENVR checking In-Reply-To: <1216568392.6585.2.camel@rousalka.okg> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <1216568392.6585.2.camel@rousalka.okg> Message-ID: <56358.65.195.245.6.1216660884.squirrel@mail.jcomserv.net> > Le dimanche 20 juillet 2008 ? 09:10 +0200, Michael Schwendt a ??crit : > >> It used to be run automatically after each Extras push, but when the >> build system moved to koji and bodhi, this feature was killed. > > Please reinstall it. It had a very beneficial effect on devel, and the > deterioration lately is very perceptible. +50,000. I miss it. It's particularly critical to Yum upgrade people, which I know is not officially supported, but we do have a SIG: http://fedoraproject.org/wiki/SIGs/LiveUpgrade And I for one would appreciate it if this could be run periodically. Maybe someone could take ownership of a cluster of scripts of this nature: source audit, ENVR, b0rken deps, etc. If no one else wants to run it, I might be interested in doing so. > -- > Nicolas Mailhot > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 21 17:34:54 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 21 Jul 2008 19:34:54 +0200 Subject: Packaging nss-ldapd for fedora In-Reply-To: <48846099.4030300@cohtech.com> (Howard Wilkinson's message of "Mon, 21 Jul 2008 11:10:33 +0100") References: <20080720161141.GH3771@edu.joroinen.fi> <87tzekmnbz.fsf@sheridan.bigo.ensc.de> <488448A6.4000308@cohtech.com> <87ljzva8ya.fsf@fc5.bigo.ensc.de> <48846099.4030300@cohtech.com> Message-ID: <87r69nb0ox.fsf@sheridan.bigo.ensc.de> Howard Wilkinson writes: >>> Enrico, could you expand on the issues you see with nss_ldap under >>> Fedora. > > can you point me at the bugzilla reports please. I have been following > the ones on pdal but if there is another source I would like to see it https://bugzilla.redhat.com/buglist.cgi?component_text=nss_ldap > Do the problems you see occur when using kerberos to autheticate to > the ldap server? Or are they in another path? You may need to set > "bind_policy soft" to get rid of the hangs. No kerberos (at least not for LDAP bind), only a single LDAP server, no SSL/TLS. 'koji list-api' stucks at | open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 5 | fstat(5, {st_mode=S_IFREG|0644, st_size=2693, ...}) = 0 | mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb3c3218000 | read(5, "root:x:0:0:root... | read(5, "", 4096) = 0 | close(5) = 0 | munmap(0x7fb3c3218000, 4096) = 0 | futex(0x7fb3bb1bee00, FUTEX_WAIT_PRIVATE, 2, NULL This futex address is used here the first and only time; there are no childs or threads which could issue a WAKE. nsswitch.conf contains 'ldap' entries for 'passwd' and 'group' only (not for 'shadow' or 'hosts'). The bash lockups are not 100% reproducible, but bash hangs in such a futex() call too. There is a connection to the ldap server in CLOSE_WAIT state and a unix socket (connection to a died nscd?) in this situation. > Things that need some attention in nss_ldap include the ability to > fail over to a second ldap server, which may be your real problem. $ sed '/^\(#.*\|\)$/d' /etc/ldap.conf host ldap.bigo.ensc.de. base dc=bigo,dc=ensc,dc=de pam_min_uid 1000 nss_base_passwd ou=People,dc=bigo,dc=ensc,dc=de?one nss_base_group ou=Group,dc=bigo,dc=ensc,dc=de?one ssl no pam_password md5 > Anyway, the version I run is 259 with my patches for the kerberos > library included (see PDAL bugzilla 298) and I get occassional > segfaults from nscd but otherwise it works nicely with kerberos > keytabs and file based tickets. I have yet to test memory based > tickets. nss_ldap-259-3.fc9.x86_64 Enrico From rdieter at math.unl.edu Mon Jul 21 17:48:18 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 21 Jul 2008 12:48:18 -0500 Subject: consolidating on gnupg2 in F10 In-Reply-To: <200807211312.41243.sgrubb@redhat.com> References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> Message-ID: <4884CBE2.50907@math.unl.edu> Steve Grubb wrote: > On Friday 18 July 2008 09:11:21 Rex Dieter wrote: >> Bill Nottingham wrote: >>> For a really long time now, we've shipped both gnupg and gnupg2 >>> in Fedora. In fact, in Fedora 9 a relatively standard install will >>> get both installed. >>> It appears a good number of these can be ported to gnupg2, if not >>> all of them. Should we wire up a feature page? >> Imo, yes, it's a worthy goal to get these ported so that at least gnupg(1) >> doesn't land in any default install. >> >> fyi, here's my inquiry upstrem on whether it's possible or a good idea to >> try dropping gnupg1: >> http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024485.html >> >> answer: probably not a good idea. > > Why did you come to that conclusion? We don't support IDEA and Suse did > mention that they have switched to only GPG2. The only caution is around > gpg-agent. based on Werner Koch's response: http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024490.html "You should don't remove gnupg-1 from a distribution..." shrug, I'm ok either way. -- Rex From katzj at redhat.com Mon Jul 21 18:08:54 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 Jul 2008 14:08:54 -0400 Subject: consolidating on gnupg2 in F10 In-Reply-To: <4884CBE2.50907@math.unl.edu> References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> <4884CBE2.50907@math.unl.edu> Message-ID: <1216663734.12841.87.camel@aglarond.local> On Mon, 2008-07-21 at 12:48 -0500, Rex Dieter wrote: > Steve Grubb wrote: > > On Friday 18 July 2008 09:11:21 Rex Dieter wrote: > >> Bill Nottingham wrote: > >>> For a really long time now, we've shipped both gnupg and gnupg2 > >>> in Fedora. In fact, in Fedora 9 a relatively standard install will > >>> get both installed. > >>> It appears a good number of these can be ported to gnupg2, if not > >>> all of them. Should we wire up a feature page? > >> Imo, yes, it's a worthy goal to get these ported so that at least gnupg(1) > >> doesn't land in any default install. > >> > >> fyi, here's my inquiry upstrem on whether it's possible or a good idea to > >> try dropping gnupg1: > >> http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024485.html > >> > >> answer: probably not a good idea. > > > > Why did you come to that conclusion? We don't support IDEA and Suse did > > mention that they have switched to only GPG2. The only caution is around > > gpg-agent. > > based on Werner Koch's response: > http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024490.html > > "You should don't remove gnupg-1 from a distribution..." He also says you should ship BIND 8 and 9. And there are people that say you should ship KDE 3.x and KDE 4 desktops. We should cut the cruft and onvert what we ship to use gnupg2. Otherwise, the fact that there are two will persist forever. Jeremy From lists at timj.co.uk Mon Jul 21 18:16:41 2008 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 21 Jul 2008 19:16:41 +0100 Subject: ENVR checking In-Reply-To: <20080720091033.7e1bfdf7.mschwendt@gmail.com> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> Message-ID: <4884D289.1070505@timj.co.uk> Michael Schwendt wrote: > It used to be run automatically after each Extras push, but when the > build system moved to koji and bodhi, this feature was killed. Probably > it was considered unimportant or a source of "spam". That's a problem > with stuff that isn't backed up or enforced by project leadership. When > I started to run it manually after some time prior to the next release > of Fedora, the number of negative voices was overwhelming: Those with > test updates newer than rawhide complained. Those with F-[n-1] test > updates newer than F-[n] complained. Those with pending updates in > bodhi complained. Those who found it helpful stayed silent. From those, > who didn't understand the private mails they received, only a very few > asked for an explanation. OK, well you shouldn't be fighting a lonely battle here. I'm certainly in that silent many (majority?). It's easy to make a mistake with versioning when we have so many branches and complex situations (base, updates etc.) and I'm very grateful when errors are pointed out so that they can be fixed. ENVR checking is really important, because aside from other reasons: a) there's no point in doing all the packaging work we do if half the users don't see it because they get stuck on old versions of packages when they do upgrades (and let's face it, with such a fast-moving distribution that even contributors like myself struggle to keep up with releases, we can't expect everyone to be doing fresh installs each time) b) half-baked systems that don't work properly (due to bad/old versions of software after upgrades) just make Fedora look bad. I've had at least two different F8->F9 upgraded machines end up unbootable after a "yum upgrade", which may or may not be a result of ENVR issues but either way it's really, really bad. (Thankfully I know enough to fix them, but many other users would have given up and gone away with the impression that Fedora trashed their PC.) However, I'm obviously preaching to the converted. What do we have to do to get this run in a regular, official, supported way on the Fedora systems and with backup from FPC and whoever in making sure packagers fix problems? Tim From silfreed at silfreed.net Mon Jul 21 18:24:22 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Mon, 21 Jul 2008 14:24:22 -0400 Subject: qgis 0.11.0 build error (undefined reference in liblapack.so.3) Message-ID: <200807211424.22919.silfreed@silfreed.net> I'm trying to get qgis 0.11.0 built (since I missed 0.10.0 entirely) and am encountering a strange error during the install phase; lots of errors like this related to liblapack.so.3, but only on i386 on F-8 and F-9 (not on any arch on F-10 or x86_64 on F-8 and F-9): /usr/lib/atlas/liblapack.so.3: undefined reference to `ATL_dgbmv' Full build log here: http://koji.fedoraproject.org/koji/taskinfo?taskID=730405 -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon Jul 21 18:26:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jul 2008 14:26:36 -0400 Subject: ENVR checking In-Reply-To: <4884D289.1070505@timj.co.uk> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <4884D289.1070505@timj.co.uk> Message-ID: <1216664796.12190.32.camel@localhost.localdomain> On Mon, 2008-07-21 at 19:16 +0100, Tim Jackson wrote: > However, I'm obviously preaching to the converted. What do we have to do > to get this run in a regular, official, supported way on the Fedora > systems and with backup from FPC and whoever in making sure packagers fix > problems? Ask nicely, perhaps with a ticket over at https://fedorahosted.org/rel-eng/newticket I took this morning and early afternoon to write up an e:n-v-r comparison script that uses koji information as the basis of it's comparison. I've got it compat-complete with the output of the old script, and it runs in about 3 minutes to compare from f8-final all the way up through rawhide. It doesn't currently mail the maintainer directly, I would like the package address aliases to be in place first (like pungi-package at fedoraproject.org) so that I don't have to duplicate a bunch of logic to figure out who all should hear personally about the problem. I'm going to check it into the rel-eng git tree in a moment and run it manually for the first time to get the output sent to fedora-devel-list. The output is somewhat separated from the data generation so it should be easy enough to hack on it for output suggestions. Finally we have to decide on when to run the script. Obviously once daily makes sense, perhaps tied into the rawhide generation. I'm open to ideas other than that, I wouldn't necessarily want to run it more than once a day due to the email it would be sending directly to package (co)maintainers/watchers. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Mon Jul 21 18:29:33 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jul 2008 14:29:33 -0400 Subject: ENVR checking In-Reply-To: <1216664796.12190.32.camel@localhost.localdomain> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <4884D289.1070505@timj.co.uk> <1216664796.12190.32.camel@localhost.localdomain> Message-ID: <1216664973.12190.35.camel@localhost.localdomain> On Mon, 2008-07-21 at 14:26 -0400, Jesse Keating wrote: > I'm going to check it into the rel-eng git tree in a moment and run it > manually for the first time to get the output sent to > fedora-devel-list. Oh, I should point out that it will seem like a very long list because it's noticing a missing feature in Bodhi, automatic obsolesence of older updates, IE things in updates-testing that have been obviated by newer testing updates, which have gone on to final. This leaves behind a number of builds still in updates-testing that are n-v-r lower than those in updates. Luke already has this fixed in upstream code, and maybe today we'll go through and auto-obsolete the current set, but for now the n-v-r report will be a bit...heavy on that info. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 seg at haxxed.com Mon Jul 21 18:49:55 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 21 Jul 2008 13:49:55 -0500 Subject: ENVR checking In-Reply-To: <1216664796.12190.32.camel@localhost.localdomain> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <4884D289.1070505@timj.co.uk> <1216664796.12190.32.camel@localhost.localdomain> Message-ID: <1216666195.4308.3.camel@localhost> On Mon, 2008-07-21 at 14:26 -0400, Jesse Keating wrote: > Finally we have to decide on when to run the script. Obviously once > daily makes sense, perhaps tied into the rawhide generation. I'm open > to ideas other than that, I wouldn't necessarily want to run it more > than once a day due to the email it would be sending directly to package > (co)maintainers/watchers. Ummm, seems to me what really needs to happen is something, somewhere in the build/push system needs to refuse to ever allow broken upgrade chains to get pushed into the repos in the first place. Or at least warn you the very second you request such an action. Rather than trying to detect and clean up the mess after the fact. -------------- 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 jkeating at redhat.com Mon Jul 21 19:03:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jul 2008 15:03:50 -0400 Subject: ENVR checking In-Reply-To: <1216666195.4308.3.camel@localhost> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <4884D289.1070505@timj.co.uk> <1216664796.12190.32.camel@localhost.localdomain> <1216666195.4308.3.camel@localhost> Message-ID: <1216667030.12190.41.camel@localhost.localdomain> On Mon, 2008-07-21 at 13:49 -0500, Callum Lerwick wrote: > Ummm, seems to me what really needs to happen is something, somewhere in > the build/push system needs to refuse to ever allow broken upgrade > chains to get pushed into the repos in the first place. Or at least warn > you the very second you request such an action. Rather than trying to > detect and clean up the mess after the fact. I don't disagree, to an extent. However without that, which is a much longer term project, we should still have info about what breakage has already been done, rather than waiting on bug reports to come in. So we can get to the reactionary world today, while working on the proactive world for the future. Of course putting all these checks into the updates push isn't going to help getting updates out any faster. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 rjones at redhat.com Mon Jul 21 19:02:29 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 20:02:29 +0100 Subject: ENVR checking In-Reply-To: <20080720091033.7e1bfdf7.mschwendt@gmail.com> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> Message-ID: <20080721190229.GA30479@amd.home.annexia.org> On Sun, Jul 20, 2008 at 09:10:33AM +0200, Michael Schwendt wrote: > Still in cvs: > http://cvs.fedoraproject.org/viewcvs/upgradecheck/?root=fedora > > It used to be run automatically after each Extras push, but when the > build system moved to koji and bodhi, this feature was killed. Probably > it was considered unimportant or a source of "spam". That's a problem > with stuff that isn't backed up or enforced by project leadership. I'd just like to offer my support for this feature, and automated emails [not too often though!] about problems. 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 rawhide at fedoraproject.org Mon Jul 21 20:06:29 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 21 Jul 2008 20:06:29 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-21 Message-ID: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates', 'dist-f8-updates-testing', 'dist-f9-updates', 'dist-f9-updates-testing', 'dist-f10'] AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) dist-f8-updates > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) dist-f8-updates-testing > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) dist-f8-updates > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) dist-f8-updates-testing > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) NetworkManager-openvpn: dist-f9-updates > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) dist-f9-updates-testing > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) PyOpenGL: dist-f8-updates-testing > dist-f9-updates (PyOpenGL-3.0.0-0.6.b4.fc8 PyOpenGL-3.0.0-0.5.b1.fc9) R: dist-f8-updates-testing > dist-f9-updates (R-2.7.1-1.fc8 R-2.7.0-5.fc9) TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) dist-f8-updates > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) dist-f8-updates-testing > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) abiword: dist-f8-updates-testing > dist-f9-updates (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) alexandria: dist-f8-updates-testing > dist-f9-updates (alexandria-0.6.3-5.fc8 alexandria-0.6.3-4.fc9) aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) dist-f8-updates > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) dist-f8-updates-testing > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) asunder: dist-f8-updates > dist-f9-updates (asunder-1.5-1.fc8 asunder-1.0.2-1.fc9) dist-f8-updates-testing > dist-f9-updates (asunder-1.6-1.fc8 asunder-1.0.2-1.fc9) audacity: dist-f8-updates-testing > dist-f9-updates (audacity-1.3.5-0.4.beta.fc8.1 audacity-1.3.2-21.fc9) augeas: dist-f8-updates-testing > dist-f9-updates (augeas-0.2.2-1.fc8 augeas-0.2.1-1.fc9) blam: dist-f8-updates > dist-f9-updates (blam-1.8.3-17.fc8 blam-1.8.3-13.fc9) dist-f8-updates > dist-f9-updates-testing (blam-1.8.3-17.fc8 blam-1.8.3-13.fc9) dist-f8-updates-testing > dist-f9-updates (blam-1.8.3-17.fc8 blam-1.8.3-13.fc9) dist-f8-updates-testing > dist-f9-updates-testing (blam-1.8.3-17.fc8 blam-1.8.3-13.fc9) bluez-libs: dist-f8-updates-testing > dist-f9-updates (bluez-libs-3.35-1.fc8 bluez-libs-3.32-1.fc9) bluez-utils: dist-f8-updates-testing > dist-f9-updates (bluez-utils-3.35-3.fc8 bluez-utils-3.32-1.fc9) bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) bzflag: dist-f8-updates-testing > dist-f9-updates (bzflag-2.0.12-3.fc8 bzflag-2.0.10-6.fc9) bzr-gtk: dist-f8-updates-testing > dist-f9-updates (bzr-gtk-0.94.0-4.fc8 bzr-gtk-0.94.0-2.fc9) cfengine: dist-f8-updates-testing > dist-f9-updates (cfengine-2.2.7-1.fc8 cfengine-2.2.3-5.fc9) cfv: dist-f8-updates-testing > dist-f9-updates (cfv-1.18.2-1.fc8 cfv-1.18.1-4.fc8.1) chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.4.0-2.fc8 claws-mail-3.4.0-1.fc10) dist-f8-updates-testing > dist-f10 (claws-mail-3.4.0-2.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) collectl: dist-f8-updates-testing > dist-f9-updates (collectl-3.0.0-1.fc8 collectl-2.6.4-1.fc9) condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) crossfire: dist-f9-updates-testing > dist-f10 (crossfire-1.10.0-5.fc9 crossfire-1.10.0-4.fc9) cyphesis: dist-f9-updates > dist-f10 (cyphesis-0.5.15-8.fc9 cyphesis-0.5.15-7.fc10) dist-f9-updates-testing > dist-f10 (cyphesis-0.5.15-8.fc9 cyphesis-0.5.15-7.fc10) devhelp: dist-f9-updates > dist-f10 (devhelp-0.19.1-3.fc9 devhelp-0.19.1-2.fc10) dist-f9-updates-testing > dist-f10 (devhelp-0.19.1-3.fc9 devhelp-0.19.1-2.fc10) driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) dist-f8-updates-testing > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) dynamite: dist-f8-updates-testing > dist-f9-updates (dynamite-0.1.1-1.fc8 dynamite-0.1-9.fc9) eclipse-changelog: dist-f8-updates-testing > dist-f9-updates (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.2.1-3.fc9) dist-f8-updates > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) dist-f8-updates-testing > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.2.1-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) dist-f8-updates > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) dist-f8-updates-testing > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) elfutils: dist-f8-updates-testing > dist-f9-updates (elfutils-0.135-1.fc8 elfutils-0.133-3.fc9) emelfm2: dist-f8-updates-testing > dist-f9-updates (emelfm2-0.4.1-1.fc8 emelfm2-0.4.0-1.fc9) epiphany: dist-f9-updates > dist-f10 (epiphany-2.22.2-3.fc9 epiphany-2.22.1.1-3.fc10) dist-f9-updates-testing > dist-f10 (epiphany-2.22.2-3.fc9 epiphany-2.22.1.1-3.fc10) evolution-rss: dist-f8-updates > dist-f9-updates (evolution-rss-0.0.8-10.fc8 evolution-rss-0.0.8-7.fc9) dist-f8-updates-testing > dist-f9-updates (evolution-rss-0.0.8-10.fc8 evolution-rss-0.0.8-7.fc9) dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) ext3grep: dist-f8-updates-testing > dist-f9-updates (ext3grep-0.7.0-1.fc8 ext3grep-0.6.0-1.fc9) ez-ipupdate: dist-f8-updates-testing > dist-f9-updates (ez-ipupdate-3.0.11-0.19.b8.fc8 ez-ipupdate-3.0.11-0.18.b8.fc9) f-spot: dist-f8-updates-testing > dist-f9-updates (f-spot-0.4.3.1-1.fc8 f-spot-0.4.2-5.fc9) facter: dist-f8-updates-testing > dist-f9-updates (facter-1.5.0-2.fc8 facter-1.3.8-1.fc8) fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) flashrom: dist-f8-updates-testing > dist-f9-updates (flashrom-0-0.11.20080607svn3418.fc8 flashrom-0-0.9.20080517svn3332.fc9) fuse: dist-f8-updates-testing > dist-f9-updates (fuse-2.7.3-3.fc8 fuse-2.7.3-2.fc9) gajim: dist-f8-updates-testing > dist-f9-updates (gajim-0.11.4-3.fc8 gajim-0.11.4-2.fc9) gamazons: dist-f8-updates-testing > dist-f9-updates (gamazons-0.83-3.fc8 gamazons-0.83-2.fc9) gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) ganyremote: dist-f8-updates > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) dist-f9-updates > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) dist-f8-updates > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) dist-f8-updates-testing > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) gcin: dist-f9-updates > dist-f9-updates-testing (gcin-1.4.2-2.fc9 gcin-1.4.2-1.fc9) geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) geoqo: dist-f8-updates > dist-f9-updates (geoqo-0.97-1.fc8 geoqo-0.96-5.fc9) dist-f8-updates-testing > dist-f9-updates (geoqo-0.97-1.fc8 geoqo-0.96-5.fc9) ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) dist-f8-updates > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) dist-f8-updates-testing > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gl-117: dist-f8-updates-testing > dist-f9-updates (gl-117-1.3.2-7.fc8 gl-117-1.3.2-4.fc7) glpi: dist-f8-updates-testing > dist-f9-updates (glpi-0.71-1.fc8 glpi-0.70.2-3.fc9) glpi-data-injection: dist-f8-updates-testing > dist-f9-updates (glpi-data-injection-1.2-1.fc8 glpi-data-injection-1.1-1.fc9) glpi-mass-ocs-import: dist-f8-updates-testing > dist-f9-updates (glpi-mass-ocs-import-1.2-1.fc8 glpi-mass-ocs-import-1.1-1.fc9) glpi-pdf: dist-f8-updates-testing > dist-f9-updates (glpi-pdf-0.5-1.fc8 glpi-pdf-0.4-1.fc9) gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) dist-f8-updates-testing > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) dist-f8-updates > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) dist-f8-updates-testing > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnome-keyring: dist-f9-updates > dist-f10 (gnome-keyring-2.22.3-1.fc9 gnome-keyring-2.22.2-2.fc10) dist-f9-updates-testing > dist-f10 (gnome-keyring-2.22.3-1.fc9 gnome-keyring-2.22.2-2.fc10) gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-6.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) gnomesword: dist-f9-updates > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) dist-f9-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) gpodder: dist-f8-updates > dist-f8-updates-testing (gpodder-0.10.4-1.fc8 gpodder-0.10.3-1.fc8) gprolog: dist-f8-updates > dist-f8-updates-testing (gprolog-1.3.0-17.fc8 gprolog-1.3.0-16.fc8) dist-f8-updates > dist-f9-updates-testing (gprolog-1.3.0-17.fc8 gprolog-1.3.0-16.fc9) dist-f9-updates > dist-f9-updates-testing (gprolog-1.3.0-17.fc9 gprolog-1.3.0-16.fc9) grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) dist-f8-updates > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) dist-f8-updates-testing > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) gyachi: dist-f8-updates-testing > dist-f9-updates (gyachi-1.1.35-16.fc8 gyachi-1.1.35-6.fc9) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) dist-f8-updates-testing > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) highlight: dist-f8-updates-testing > dist-f9-updates (highlight-2.6.11-1.fc8 highlight-2.6.10-1.fc9) hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) httpd: dist-f8-updates-testing > dist-f9-updates (httpd-2.2.9-1.fc8 httpd-2.2.8-3) httrack: dist-f8-updates-testing > dist-f9-updates (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) imlib: dist-f8-updates > dist-f8-updates-testing (1:imlib-1.9.15-6.fc8 1:imlib-1.9.15-5.fc8) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) iscsi-initiator-utils: dist-f8-updates-testing > dist-f9-updates (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jgoodies-forms: dist-f8-updates-testing > dist-f9-updates (jgoodies-forms-1.2.0-1.fc8 jgoodies-forms-1.1.0-2.fc9) jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) dist-f8-updates-testing > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) kdebase3: dist-f9-updates > dist-f10 (kdebase3-3.5.9-16.fc9 kdebase3-3.5.9-15.fc10) dist-f9-updates-testing > dist-f10 (kdebase3-3.5.9-16.fc9 kdebase3-3.5.9-15.fc10) kdesvn: dist-f8-updates-testing > dist-f9-updates (kdesvn-0.14.4-1.fc8 kdesvn-0.14.1-4.fc9) kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) dist-f8-updates > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) dist-f8-updates-testing > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) kst: dist-f8-updates > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) dist-f9-updates > dist-f9-updates-testing (kst-1.6.0-2.fc9 kst-1.6.0-1.fc9) lam: dist-f8-updates-testing > dist-f9-updates (2:lam-7.1.4-1.fc8 2:lam-7.1.2-11.fc9) libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) libextractor: dist-f8-updates-testing > dist-f9-updates (libextractor-0.5.20b-1.fc8 libextractor-0.5.19a-1.fc9) libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) librapi: dist-f8-updates-testing > dist-f9-updates (librapi-0.11.1-1.fc8 librapi-0.11-2.fc9) librra: dist-f8-updates-testing > dist-f9-updates (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) libsynce: dist-f8-updates-testing > dist-f9-updates (libsynce-0.11.1-1.fc8 libsynce-0.11-3.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) dist-f8-updates > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) dist-f8-updates-testing > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mach: dist-f8-updates-testing > dist-f9-updates (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) mock: dist-f8-updates-testing > dist-f9-updates (mock-0.9.10-1.fc8 mock-0.9.9-1.fc9) mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) dist-f8-updates > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) dist-f8-updates-testing > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) multiget: dist-f8-updates-testing > dist-f9-updates (multiget-1.2.0-3.fc8 multiget-1.1.4-7.fc8) mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) dist-f8-updates > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) dist-f8-updates-testing > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) notification-daemon-engine-nodoka: dist-f8-updates-testing > dist-f9-updates (notification-daemon-engine-nodoka-0.1.0-3.fc8 notification-daemon-engine-nodoka-0.1.0-2.fc9) ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-static: dist-f8-updates-testing > dist-f9-updates (ocaml-json-static-0.9.6-5.fc8 ocaml-json-static-0.9.6-4.fc9) ocaml-openin: dist-f8-updates-testing > dist-f9-updates (ocaml-openin-20070524-4.fc8 ocaml-openin-20070524-3.fc9) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-pa-monad: dist-f8-updates-testing > dist-f9-updates (ocaml-pa-monad-1.2.0-5.fc8 ocaml-pa-monad-1.2.0-4.fc9) ocaml-pgocaml: dist-f8-updates-testing > dist-f9-updates (ocaml-pgocaml-1.1-3.fc8 ocaml-pgocaml-1.1-2.fc9) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) odccm: dist-f8-updates-testing > dist-f9-updates (odccm-0.11.1-1.fc8 odccm-0.11-2.fc9) oddjob: dist-f8-updates-testing > dist-f9-updates (oddjob-0.29.1-1.fc8 oddjob-0.29-2.fc9) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) dist-f8-updates-testing > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) orange: dist-f8-updates-testing > dist-f9-updates (orange-0.3.2-1.fc8 orange-0.3-7.cvs20051118.fc9) pastebin: dist-f8-updates-testing > dist-f9-updates (pastebin-0.60-4.fc8 pastebin-0.60-3.fc9) perl-AnyEvent: dist-f8-updates > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f8-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) dist-f9-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-File-Find-Rule-Perl: dist-f8-updates > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) dist-f9-updates > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc9 perl-File-Find-Rule-Perl-1.04-1.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-Module-Depends: dist-f8-updates-testing > dist-f9-updates (perl-Module-Depends-0.14-1.fc8 perl-Module-Depends-0.13-2.fc9) perl-MooseX-Object-Pluggable: dist-f8-updates-testing > dist-f9-updates (perl-MooseX-Object-Pluggable-0.0007-2.fc8 perl-MooseX-Object-Pluggable-0.0005-2.fc9) perl-MooseX-Params-Validate: dist-f8-updates-testing > dist-f9-updates (perl-MooseX-Params-Validate-0.05-1.fc8 perl-MooseX-Params-Validate-0.03-2.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates-testing > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) perl-XML-Stream: dist-f8-updates-testing > dist-f9-updates (perl-XML-Stream-1.22-8.fc8 perl-XML-Stream-1.22-7.fc9) php-magickwand: dist-f8-updates > dist-f9-updates (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) dist-f8-updates > dist-f9-updates-testing (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) dist-f8-updates-testing > dist-f9-updates (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) php-pear-Net-Socket: dist-f8-updates-testing > dist-f9-updates (php-pear-Net-Socket-1.0.9-1.fc8 php-pear-Net-Socket-1.0.8-1.fc7) pidgin-otr: dist-f8-updates > dist-f9-updates (pidgin-otr-3.2.0-1.fc8 pidgin-otr-3.1.0-3.fc9) dist-f8-updates-testing > dist-f9-updates (pidgin-otr-3.2.0-1.fc8 pidgin-otr-3.1.0-3.fc9) podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pvm: dist-f8-updates-testing > dist-f9-updates (pvm-3.4.5-11.fc8 pvm-3.4.5-9.fc9) pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) f8-final > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates-testing > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyicq-t: dist-f8-updates-testing > dist-f9-updates (pyicq-t-0.8-5.b.fc8 pyicq-t-0.8-4.b.fc9) pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) dist-f8-updates > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) dist-f8-updates-testing > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-beaker: dist-f8-updates-testing > dist-f9-updates (python-beaker-0.9.5-1.fc8 python-beaker-0.9.4-4.fc9) python-biopython: dist-f8-updates-testing > dist-f9-updates (python-biopython-1.47-1.fc8 python-biopython-1.45-1.fc9) python-genshi: dist-f8-updates-testing > dist-f9-updates (python-genshi-0.5-1.fc8 python-genshi-0.4.4-2.fc8) python-libgmail: dist-f8-updates-testing > dist-f9-updates (python-libgmail-0.1.9-1.fc8 python-libgmail-0.1.8-2.fc9) python-lxml: dist-f8-updates-testing > dist-f9-updates (python-lxml-2.0.7-1.fc8 python-lxml-2.0.3-1.fc9) python-paramiko: dist-f8-updates-testing > dist-f9-updates (python-paramiko-1.7.4-1.fc8 python-paramiko-1.7.3-1.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) dist-f8-updates > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) dist-f8-updates-testing > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qlandkarte: dist-f8-updates-testing > dist-f9-updates (qlandkarte-0.7.3-1.fc8 qlandkarte-0.7.2-1.fc9) qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates-testing > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) redet: dist-f8-updates-testing > dist-f9-updates (redet-8.24-1.fc8 redet-8.23-3.fc9) rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) rpy: dist-f8-updates-testing > dist-f9-updates (rpy-1.0.3-2.fc8 rpy-1.0.3-1.fc9) ruby-gnome2: dist-f8-updates > dist-f9-updates (ruby-gnome2-0.17.0-0.3.rc1.fc8 ruby-gnome2-0.17.0-0.2.rc1.fc9) dist-f8-updates > dist-f9-updates-testing (ruby-gnome2-0.17.0-0.3.rc1.fc8 ruby-gnome2-0.17.0-0.2.rc1.fc9) dist-f8-updates-testing > dist-f9-updates (ruby-gnome2-0.17.0-0.3.rc1.fc8 ruby-gnome2-0.17.0-0.2.rc1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (ruby-gnome2-0.17.0-0.3.rc1.fc8 ruby-gnome2-0.17.0-0.2.rc1.fc9) rubygem-activeldap: dist-f8-updates-testing > dist-f9-updates (rubygem-activeldap-1.0.1-1.fc8 rubygem-activeldap-0.10.0-10.fc9) rubygem-hoe: dist-f8-updates-testing > dist-f9-updates (rubygem-hoe-1.7.0-1.fc8 rubygem-hoe-1.5.1-5.fc9) sagator: dist-f8-updates-testing > dist-f9-updates (sagator-1.1.0-1.fc8 sagator-1.0.0-1.fc9) samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) setroubleshoot: dist-f9-updates > dist-f9-updates-testing (setroubleshoot-2.0.8-2.fc9 setroubleshoot-2.0.7-1.fc9) shorewall: dist-f8-updates-testing > dist-f9-updates (shorewall-4.0.12-2.fc8 shorewall-4.0.12-1.fc9) smbldap-tools: dist-f8-updates-testing > dist-f9-updates (smbldap-tools-0.9.5-2.fc8 smbldap-tools-0.9.4-2.fc9) snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) sofia-sip: dist-f8-updates-testing > dist-f9-updates (sofia-sip-1.12.9-1.fc8 sofia-sip-1.12.8-1.fc9) speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) synce-gnomevfs: dist-f8-updates-testing > dist-f9-updates (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-kpm: dist-f8-updates-testing > dist-f9-updates (synce-kpm-0.11.2-0.1.svn3491.fc8 synce-kpm-0.11-3.fc9) synce-sync-engine: dist-f8-updates-testing > dist-f9-updates (synce-sync-engine-0.11.1-1.fc8 synce-sync-engine-0.11-6.fc9) synce-trayicon: dist-f8-updates-testing > dist-f9-updates (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) systemtap: dist-f8-updates-testing > dist-f9-updates (systemtap-0.7-1.fc8 systemtap-0.6.2-1.fc9) tellico: dist-f8-updates-testing > dist-f9-updates (tellico-1.3.3-1.fc8 tellico-1.3.2.1-1.fc9) tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) dist-f8-updates > dist-f10 (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) dist-f8-updates-testing > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) dist-f8-updates-testing > dist-f10 (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) dist-f9-updates-testing > dist-f10 (tilda-0.9.5-2.fc9 tilda-0.9.4-7.fc9) uncrustify: dist-f8-updates-testing > dist-f9-updates (uncrustify-0.47-1.fc8 uncrustify-0.45-1.fc9) unshield: dist-f8-updates-testing > dist-f9-updates (unshield-0.5.1-1.fc8 unshield-0.5-8.fc9) vala: dist-f8-updates-testing > dist-f9-updates (vala-0.3.4-2.fc8 vala-0.3.4-1.fc9) varnish: dist-f8-updates > dist-f8-updates-testing (varnish-1.1.2-5.fc8 varnish-1.1.2-4.fc8) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) wdaemon: dist-f8-updates-testing > dist-f9-updates (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) wings: dist-f8-updates-testing > dist-f9-updates (wings-0.99.02-2.fc8 wings-0.99.02-1.fc9) dist-f8-updates-testing > dist-f10 (wings-0.99.02-2.fc8 wings-0.99.02-1.fc9) dist-f9-updates-testing > dist-f10 (wings-0.99.02-2.fc9 wings-0.99.02-1.fc9) xenner: dist-f8-updates > dist-f9-updates-testing (xenner-0.37-1.fc8 xenner-0.36-1.fc9) dist-f8-updates-testing > dist-f9-updates-testing (xenner-0.37-1.fc8 xenner-0.36-1.fc9) dist-f9-updates > dist-f9-updates-testing (xenner-0.37-1.fc9 xenner-0.36-1.fc9) xine-plugin: dist-f9-updates > dist-f10 (xine-plugin-1.0.1-4.fc9 xine-plugin-1.0.1-3.fc10) dist-f9-updates-testing > dist-f10 (xine-plugin-1.0.1-4.fc9 xine-plugin-1.0.1-3.fc10) xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) yelp: dist-f9-updates > dist-f10 (yelp-2.22.1-4.fc9 yelp-2.22.1-2.fc10) dist-f9-updates-testing > dist-f10 (yelp-2.22.1-4.fc9 yelp-2.22.1-2.fc10) zaptel: dist-f8-updates-testing > dist-f9-updates (zaptel-1.4.11-1.fc8 zaptel-1.4.9-1.fc9) zhcon: dist-f8-updates-testing > dist-f9-updates (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From wtogami at redhat.com Mon Jul 21 20:06:50 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 Jul 2008 16:06:50 -0400 Subject: brctl setfd virbr0 0.1 by default? Message-ID: <4884EC5A.3000100@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=435757 Sometime after F8, something changed where stuff attached to a bridge fails to connect until 15 seconds later. A manual workaround of brctl setfd BRIDGENAME 0.1 makes stuff work immediately. Are there any reasons why don't we do this by default for virbr0 in libvirt? Use cases: - Attach a different tun/tap device to the virbr0 bridge to talk to your virtual machine. - Attach ethX real device to your vribr0 bridge to talk to your virtual machine without NAT (like if you are doing DHCP.) Warren Togami wtogami at redhat.com From pjones at redhat.com Mon Jul 21 21:14:12 2008 From: pjones at redhat.com (Peter Jones) Date: Mon, 21 Jul 2008 17:14:12 -0400 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <20080710130230.GA29114@nostromo.devel.redhat.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> <20080710130230.GA29114@nostromo.devel.redhat.com> Message-ID: <4884FC24.6090303@redhat.com> Bill Nottingham wrote: > Matthew Garrett (mjg59 at srcf.ucam.org) said: >> On Wed, Jul 09, 2008 at 06:32:16AM -0400, Colin Walters wrote: >> >>> Putting syslog on tmpfs by default and limiting the total size to something >>> like 5MB would be something to evaluate for the default desktop. >> I looked into this, and we're not actually doing too badly - our syslogd >> doesn't fsync() after every log entry. I'm broadly in favour of using >> tmpfs, though. There's an argument that certain priorities probably want >> to stay on disk, but otherwise we can simply sync the tmpfs to disk on >> shutdown or reboot. > > Maybe I'm unusual, but I rarely reboot my laptop cleanly. I'm not sure I'd > want X weeks of logs to go away. > > Are there any sorts of mechanisms to do per-directory or per-file writeback > caching, so that /var/log/ could be set to 'sync only every 15 minutes', > or similar? Note that we really want similar functionality for e.g. gnome-power-manager's battery charge history data. -- Peter From maximilianbianco at gmail.com Mon Jul 21 21:34:25 2008 From: maximilianbianco at gmail.com (max bianco) Date: Mon, 21 Jul 2008 17:34:25 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> Message-ID: On Thu, Jul 17, 2008 at 7:26 PM, Ahmed Kamal wrote: > I'd say I am a pretty knowledgeable Linux user. However, when I see an > AVC denial, and the recommended chcon doesn't fix it, I'm pretty much > lost! I need to launch that server or that application NOW, and > selinux is stopping that ... and the policy won't be fixed for days, > it won't even be fixed at all if that's a 3rd party app! I need > something to help me launch my apps if I so choose! a 95% selinux > protected system, is so much better than one with it disabled, which > what I always seem to end up doing to get my work done! > The tools to fix this already exist. man audit2allow man ausearch The man pages explain things pretty well. If I can read them and fix my own problems so can any competent sysadmin. ausearch can be used with audit2allow to generate the needed rules. The rules shouldn't be blindly accepted but they can get you buy for the moment. Its all documented in the man pages, every step. SysAdmins need to get used to SELinux and use the available troubleshooting tools. The Z option is available on a few commands. Max -- If opinions were really like assholes we'd each have just one From email.ahmedkamal at googlemail.com Mon Jul 21 21:36:17 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 22 Jul 2008 00:36:17 +0300 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> Message-ID: <3da3b5b40807211436l71433d7eo8b270e76b0c0ab13@mail.gmail.com> Are we talking sysadmins only, or are we talking users too ?! On Tue, Jul 22, 2008 at 12:34 AM, max bianco wrote: > On Thu, Jul 17, 2008 at 7:26 PM, Ahmed Kamal > wrote: >> I'd say I am a pretty knowledgeable Linux user. However, when I see an >> AVC denial, and the recommended chcon doesn't fix it, I'm pretty much >> lost! I need to launch that server or that application NOW, and >> selinux is stopping that ... and the policy won't be fixed for days, >> it won't even be fixed at all if that's a 3rd party app! I need >> something to help me launch my apps if I so choose! a 95% selinux >> protected system, is so much better than one with it disabled, which >> what I always seem to end up doing to get my work done! >> > The tools to fix this already exist. > > man audit2allow > man ausearch > > The man pages explain things pretty well. If I can read them and fix > my own problems so can any competent sysadmin. > ausearch can be used with audit2allow to generate the needed rules. > The rules shouldn't be blindly accepted but they can get you buy for > the moment. > Its all documented in the man pages, every step. SysAdmins need to get > used to SELinux and use the available troubleshooting tools. The Z > option is available on a few commands. > > > Max > -- > If opinions were really like assholes we'd each have just one > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From cra at WPI.EDU Mon Jul 21 21:40:10 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 21 Jul 2008 17:40:10 -0400 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <4884EC5A.3000100@redhat.com> References: <4884EC5A.3000100@redhat.com> Message-ID: <20080721214010.GJ23765@angus.ind.WPI.EDU> > https://bugzilla.redhat.com/show_bug.cgi?id=435757 > Sometime after F8, something changed where stuff attached to a bridge > fails to connect until 15 seconds later. A manual workaround of brctl > setfd BRIDGENAME 0.1 makes stuff work immediately. > > Are there any reasons why don't we do this by default for virbr0 in libvirt? > > Use cases: > - Attach a different tun/tap device to the virbr0 bridge to talk to your > virtual machine. > - Attach ethX real device to your vribr0 bridge to talk to your virtual > machine without NAT (like if you are doing DHCP.) I would assume that brctl or the kernel became fully 802.1d Spanning Tree Protocol compliant. Compliant bridges MUST delay entering the forwarding state at link up or initialization, transitioning between LISTENING and LEARNING states first. This is required by the standard. That being said, most really switches support a per-port "fast start" mode sometimes called "portfast" or "edge" where the port is designated to be connected directly to an end system rather than another bridge/switch, which causes the forwarding delay to be set to 0. This is not strictly compliant to the standard, but is often used because of the issue where DHCP clients will time out after 15 seconds. From maximilianbianco at gmail.com Mon Jul 21 21:45:19 2008 From: maximilianbianco at gmail.com (max bianco) Date: Mon, 21 Jul 2008 17:45:19 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <3da3b5b40807211436l71433d7eo8b270e76b0c0ab13@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> <3da3b5b40807211436l71433d7eo8b270e76b0c0ab13@mail.gmail.com> Message-ID: On Mon, Jul 21, 2008 at 5:36 PM, Ahmed Kamal wrote: > Are we talking sysadmins only, or are we talking users too ?! > I am user, and far from a Linux expert. I have ,admittedly, a great interest in SELinux which motivates me to learn as much as I can but the man pages explain it all. The man pages are dry but they contain all the info you need, the problem is people are inherently lazy and they think security should be simple. I wouldn't describe the linux kernel, or any other kernel, as simple, the complexity of SELinux is a reflection of the complexity of the linux kernel itself. Read the man pages and find out for yourself if its easy or not. If you think they need improvement then this is the place to bring it up. -- If opinions were really like assholes we'd each have just one From ben.lewis at benl.co.uk Mon Jul 21 22:16:31 2008 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Mon, 21 Jul 2008 23:16:31 +0100 Subject: consolidating on gnupg2 in F10 In-Reply-To: <1216663734.12841.87.camel@aglarond.local> References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> <4884CBE2.50907@math.unl.edu> <1216663734.12841.87.camel@aglarond.local> Message-ID: <48850ABF.2060102@benl.co.uk> Jeremy Katz wrote: > On Mon, 2008-07-21 at 12:48 -0500, Rex Dieter wrote: >> Steve Grubb wrote: >>> On Friday 18 July 2008 09:11:21 Rex Dieter wrote: >>>> Bill Nottingham wrote: >>>>> For a really long time now, we've shipped both gnupg and gnupg2 >>>>> in Fedora. In fact, in Fedora 9 a relatively standard install will >>>>> get both installed. >>>>> It appears a good number of these can be ported to gnupg2, if not >>>>> all of them. Should we wire up a feature page? >>>> Imo, yes, it's a worthy goal to get these ported so that at least gnupg(1) >>>> doesn't land in any default install. >>>> >>>> fyi, here's my inquiry upstrem on whether it's possible or a good idea to >>>> try dropping gnupg1: >>>> http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024485.html >>>> >>>> answer: probably not a good idea. >>> Why did you come to that conclusion? We don't support IDEA and Suse did >>> mention that they have switched to only GPG2. The only caution is around >>> gpg-agent. >> based on Werner Koch's response: >> http://lists.gnupg.org/pipermail/gnupg-devel/2008-July/024490.html >> >> "You should don't remove gnupg-1 from a distribution..." > > He also says you should ship BIND 8 and 9. And there are people that > say you should ship KDE 3.x and KDE 4 desktops. > > We should cut the cruft and onvert what we ship to use gnupg2. > Otherwise, the fact that there are two will persist forever. > > Jeremy > +1 This is the same argument that exists for compatibility libraries: their existence in distributions is a disincentive for developers to port their applications. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben_lewis.vcf Type: text/x-vcard Size: 196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Mon Jul 21 22:29:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 22 Jul 2008 00:29:17 +0200 Subject: consolidating on gnupg2 in F10 In-Reply-To: <48850ABF.2060102@benl.co.uk> References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> <4884CBE2.50907@math.unl.edu> <1216663734.12841.87.camel@aglarond.local> <48850ABF.2060102@benl.co.uk> Message-ID: <20080721222916.GB3706@free.fr> On Mon, Jul 21, 2008 at 11:16:31PM +0100, Benjamin Lewis wrote: > > This is the same argument that exists for compatibility libraries: their > existence in distributions is a disincentive for developers to port > their applications. Please don't force people to do what you wan and leave the choice to them. Or, better, send patches. -- Pat From maillist at diffingo.com Tue Jul 22 00:04:58 2008 From: maillist at diffingo.com (Stewart Adam) Date: Mon, 21 Jul 2008 20:04:58 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: References: <1216316523.11204.0.camel@Diffingo.localdomain> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <16de708d0807171347m29368622o1847858fdac975cf@mail.gmail.com> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> Message-ID: <1216685098.21247.3.camel@Diffingo.localdomain> With all due respect, you've completely missed the point. In many cases, casual users are their own system admin (home machine). Yes, the man pages exist but the whole point of improving SELinux <--> user interaction is to avoid exactly that. Things need to be more user friendly and human-readable so the casual user can understand SELinux instead of getting frustrated and disabling it. Stewart On Mon, 2008-07-21 at 17:34 -0400, max bianco wrote: > On Thu, Jul 17, 2008 at 7:26 PM, Ahmed Kamal > wrote: > > I'd say I am a pretty knowledgeable Linux user. However, when I see an > > AVC denial, and the recommended chcon doesn't fix it, I'm pretty much > > lost! I need to launch that server or that application NOW, and > > selinux is stopping that ... and the policy won't be fixed for days, > > it won't even be fixed at all if that's a 3rd party app! I need > > something to help me launch my apps if I so choose! a 95% selinux > > protected system, is so much better than one with it disabled, which > > what I always seem to end up doing to get my work done! > > > The tools to fix this already exist. > > man audit2allow > man ausearch > > The man pages explain things pretty well. If I can read them and fix > my own problems so can any competent sysadmin. > ausearch can be used with audit2allow to generate the needed rules. > The rules shouldn't be blindly accepted but they can get you buy for > the moment. > Its all documented in the man pages, every step. SysAdmins need to get > used to SELinux and use the available troubleshooting tools. The Z > option is available on a few commands. > > > Max > -- > If opinions were really like assholes we'd each have just one > From maximilianbianco at gmail.com Tue Jul 22 03:50:25 2008 From: maximilianbianco at gmail.com (max bianco) Date: Mon, 21 Jul 2008 23:50:25 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216685098.21247.3.camel@Diffingo.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> <1216328592.4782.0.camel@Diffingo.localdomain> <3da3b5b40807171407n268675chebd4dbdab854cdab@mail.gmail.com> <1216335218.4965.1.camel@clockmaker.usersys.redhat.com> <16de708d0807171557y72fc60e1j57adcf3ef56f678d@mail.gmail.com> <1216335656.4965.4.camel@clockmaker.usersys.redhat.com> <16de708d0807171615ob925233sb80338c78127a3c0@mail.gmail.com> <3da3b5b40807171626w1085e2ccw2ce67a6ac892746f@mail.gmail.com> <1216685098.21247.3.camel@Diffingo.localdomain> Message-ID: On Mon, Jul 21, 2008 at 8:04 PM, Stewart Adam wrote: > With all due respect, you've completely missed the point. In many cases, > casual users are their own system admin (home machine). Yes, the man > pages exist but the whole point of improving SELinux <--> user > interaction is to avoid exactly that. Things need to be more user > friendly and human-readable so the casual user can understand SELinux > instead of getting frustrated and disabling it. > > Stewart > My point is that the tools to fix the issues already exist. Many don't seem to be aware of them at all. Your suggesting a GUI front-end that combines all the command-line tools? Max -- If opinions were really like assholes we'd each have just one From mmcgrath at redhat.com Tue Jul 22 05:50:19 2008 From: mmcgrath at redhat.com (Michael McGrath) Date: Tue, 22 Jul 2008 01:50:19 -0400 (EDT) Subject: Outage Reminder Message-ID: <1401758246.1101591216705819749.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00007.html From berrange at redhat.com Tue Jul 22 09:58:50 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 22 Jul 2008 10:58:50 +0100 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <4884EC5A.3000100@redhat.com> References: <4884EC5A.3000100@redhat.com> Message-ID: <20080722095850.GC5192@redhat.com> On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=435757 > Sometime after F8, something changed where stuff attached to a bridge > fails to connect until 15 seconds later. A manual workaround of brctl > setfd BRIDGENAME 0.1 makes stuff work immediately. > > Are there any reasons why don't we do this by default for virbr0 in libvirt? Because no one has ever suggested it before... Arguably we should just turn off STP on the virbr0 device. Since it is not connected directly to the public LAN[1] there is no risk of network loops and thus spanning tree protocol is pointless for virbr0. I wonder if somewhere along the lines post F8 GA, STP accidentally got toggled from offf by default to on by default on virbr0. Please file a BZ about this problem. Daniel [1] The only connectivity is outbound, masqueraded / NAT traffic. -- |: 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 loupgaroublond at gmail.com Tue Jul 22 12:17:58 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jul 2008 14:17:58 +0200 Subject: Firmware packages with a mislabelled license? Message-ID: <7f692fec0807220517x5ea8348eo45941420a506fe21@mail.gmail.com> Hi List, I've been asked to investigate licensing issues in two packages. zd1211-firmware. This package is labelled as GPLv2+. From what I gather on sourceforge, the distributed tarball distributes binary blobs. There is also the following comments regarding licensing in Debian. http://packages.debian.org/changelogs/pool/non-free/z/zd1211-firmware/zd1211-firmware_2.16.0.0-0.1/zd1211-firmware.copyright I had a look at our CVS repo, and we somehow create a makefile that is used to create some of the files from the C header files. I'm not an expert on firmwares, so I'm not sure of all the details on the process. Even so, it seems like we are including a binary blob here. midisport-firmware This package is also labelled as GPLv2+. It's pretty clear from the lines in the spec file that there is no source to speak of. %build # Nothing to build Sourceforge labels it as: License : BSD License, GNU General Public License (GPL), Other/Proprietary License My understanding is that this is a 100% binary blob. According to the packaging guidelines, binary blob packages like these are allowed but need to be labelled as "Redistributable, no modification permitted". One of the maintainers of Blag Linux asked me to look into this, since according to their policies, these packages are verboten. I'm still not 100% sure on the first package, but is this something that I should file a bug against or are there other considerations I'm missing here? -Yaakov From kevin.kofler at chello.at Tue Jul 22 12:21:44 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Jul 2008 12:21:44 +0000 (UTC) Subject: Firmware packages with a mislabelled license? References: <7f692fec0807220517x5ea8348eo45941420a506fe21@mail.gmail.com> Message-ID: Yaakov Nemoy gmail.com> writes: > Sourceforge labels it as: > > License : BSD License, GNU General Public License (GPL), > Other/Proprietary License And that's essentially correct. As I said in the other thread, the correct license tag for Fedora is: License: (MIT or GPLv2+) and Redistributable, no modification permitted The firmware loader is dual MIT/GPLv2+, the actual firmware is only redistributable. The package contains both. Kevin Kofler From loupgaroublond at gmail.com Tue Jul 22 12:55:39 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jul 2008 14:55:39 +0200 Subject: Firmware packages with a mislabelled license? In-Reply-To: References: <7f692fec0807220517x5ea8348eo45941420a506fe21@mail.gmail.com> Message-ID: <7f692fec0807220555j50e55680qf9aa8dd5ec8c00e@mail.gmail.com> On Tue, Jul 22, 2008 at 2:21 PM, Kevin Kofler wrote: > Yaakov Nemoy gmail.com> writes: >> Sourceforge labels it as: >> >> License : BSD License, GNU General Public License (GPL), >> Other/Proprietary License > > And that's essentially correct. As I said in the other thread, the correct > license tag for Fedora is: > License: (MIT or GPLv2+) and Redistributable, no modification permitted > > The firmware loader is dual MIT/GPLv2+, the actual firmware is only > redistributable. The package contains both. http://cvs.fedoraproject.org/viewcvs/devel/midisport-firmware/midisport-firmware.spec?view=markup Then this is a clear bug. I'll fire up bugzilla. -Yaakov Nemoy From gilboad at gmail.com Tue Jul 22 14:15:44 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 22 Jul 2008 17:15:44 +0300 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <487FB3BC.3030109@redhat.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> Message-ID: <1216736144.11046.8.camel@gilboa-work-dev.localdomain> On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: > Ahmed Kamal wrote: > > another idea, is when a denial occurs, and we get this nice balloon, > > it would contain 2 buttons > > - AutoFix: automatically attempts changing the offending file's > > context, as per the recommended action > > > > This is a sharp edge for users to cut themselves on. It would be nice if > we would detect when the error was a result of inconsistencies though > (such as the file label not matching policy). > > IMHO, we should be able to do the following: > > - We should have exempt, which ignores the denial for now. It also flags > the issue upstream. Denial messages for the exempt process are then > rerouted to a safe place. > - Whenever policy-kit is updated, the exemptions are reevaluated and > removed if they should be addressed. > - We should come up with some secure way of quickly propagating > information about known selinux issues, so that denial warnings can be > suppressed until a fix is available > - There should be more graphical tools for manipulating policy itself. > The user should be able to see a list of local policy exceptions they > have made. > > --CJD > Couldn't exempt be (ab)used to an attacker if/when it becomes common knowledge? - Gilboa From wtogami at redhat.com Tue Jul 22 14:22:12 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 22 Jul 2008 10:22:12 -0400 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <20080722095850.GC5192@redhat.com> References: <4884EC5A.3000100@redhat.com> <20080722095850.GC5192@redhat.com> Message-ID: <4885ED14.9060005@redhat.com> Daniel P. Berrange wrote: > On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=435757 >> Sometime after F8, something changed where stuff attached to a bridge >> fails to connect until 15 seconds later. A manual workaround of brctl >> setfd BRIDGENAME 0.1 makes stuff work immediately. >> >> Are there any reasons why don't we do this by default for virbr0 in libvirt? > > Because no one has ever suggested it before... > > Arguably we should just turn off STP on the virbr0 device. Since it is > not connected directly to the public LAN[1] there is no risk of network > loops and thus spanning tree protocol is pointless for virbr0. I wonder > if somewhere along the lines post F8 GA, STP accidentally got toggled > from offf by default to on by default on virbr0. Please file a BZ about > this problem. > > Daniel > > [1] The only connectivity is outbound, masqueraded / NAT traffic. Disabling STP on virbr0 alone is not enough. I just tested it now. STP enabled or disabled, the default forward delay of 15 seconds makes it fail for 15 seconds, long enough for most DHCP clients to give up. Given this, what should we do? Both disable STP and also reduce the delay? Warren Togami wtogami at redhat.com From ddutile at redhat.com Tue Jul 22 14:56:51 2008 From: ddutile at redhat.com (Don Dutile) Date: Tue, 22 Jul 2008 10:56:51 -0400 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <4885ED14.9060005@redhat.com> References: <4884EC5A.3000100@redhat.com> <20080722095850.GC5192@redhat.com> <4885ED14.9060005@redhat.com> Message-ID: <4885F533.1070702@redhat.com> Warren Togami wrote: > Daniel P. Berrange wrote: >> On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=435757 >>> Sometime after F8, something changed where stuff attached to a bridge >>> fails to connect until 15 seconds later. A manual workaround of >>> brctl setfd BRIDGENAME 0.1 makes stuff work immediately. >>> >>> Are there any reasons why don't we do this by default for virbr0 in >>> libvirt? >> >> Because no one has ever suggested it before... >> >> Arguably we should just turn off STP on the virbr0 device. Since it is >> not connected directly to the public LAN[1] there is no risk of network >> loops and thus spanning tree protocol is pointless for virbr0. I wonder >> if somewhere along the lines post F8 GA, STP accidentally got toggled >> from offf by default to on by default on virbr0. Please file a BZ about >> this problem. >> >> Daniel >> >> [1] The only connectivity is outbound, masqueraded / NAT traffic. > > Disabling STP on virbr0 alone is not enough. I just tested it now. STP > enabled or disabled, the default forward delay of 15 seconds makes it > fail for 15 seconds, long enough for most DHCP clients to give up. > > Given this, what should we do? Both disable STP and also reduce the delay? > Try reducing the delay to 0. I believe this is the same/similar issue that Herbert Xu is dealing with when xen guests are migrated, and the guest doesn't see the network for some number of seconds. I'm trying to find the BZ & thread that had this info in it, but searching through xen-maint bz's is not turning up what I'm looking for. BZ 441716 proposes another solution for rhel5; not sure if fedora needs it as well. - Don > Warren Togami > wtogami at redhat.com > From berrange at redhat.com Tue Jul 22 14:51:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 22 Jul 2008 15:51:23 +0100 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <4885ED14.9060005@redhat.com> References: <4884EC5A.3000100@redhat.com> <20080722095850.GC5192@redhat.com> <4885ED14.9060005@redhat.com> Message-ID: <20080722145123.GI5192@redhat.com> On Tue, Jul 22, 2008 at 10:22:12AM -0400, Warren Togami wrote: > Daniel P. Berrange wrote: > >On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: > >>https://bugzilla.redhat.com/show_bug.cgi?id=435757 > >>Sometime after F8, something changed where stuff attached to a bridge > >>fails to connect until 15 seconds later. A manual workaround of brctl > >>setfd BRIDGENAME 0.1 makes stuff work immediately. > >> > >>Are there any reasons why don't we do this by default for virbr0 in > >>libvirt? > > > >Because no one has ever suggested it before... > > > >Arguably we should just turn off STP on the virbr0 device. Since it is > >not connected directly to the public LAN[1] there is no risk of network > >loops and thus spanning tree protocol is pointless for virbr0. I wonder > >if somewhere along the lines post F8 GA, STP accidentally got toggled > >from offf by default to on by default on virbr0. Please file a BZ about > >this problem. > > > >Daniel > > > >[1] The only connectivity is outbound, masqueraded / NAT traffic. > > Disabling STP on virbr0 alone is not enough. I just tested it now. STP > enabled or disabled, the default forward delay of 15 seconds makes it > fail for 15 seconds, long enough for most DHCP clients to give up. > > Given this, what should we do? Both disable STP and also reduce the delay? I think I understand what's going on here. - The libvirt 'default' network XML config (aka that for virbr0) does not specify any forward delay or STP setting, so it defaults to delay=0, and STP=on - The libvirt in F8 GA had a bug, where it called 'setfd' instead 'stp' when invoking brctl. - Thus, the default config would result in a bridge with STP off and a delay of 1 second. - A libvirt update fixed the bug in the way we call brctl. Fixing the bug means we now by default create a bridge with STP on and the default kernel delay setting of 15 seconds. - There is a further bug in that if you specify delay=0 in the XML it'll never call 'brctl setfd 0', so you'll be stuck with the 15 second default still. So yes, we need to fix things such that it has STP=on and a tiny (or even zer) forward forward delay again, as per F8 GA behaviour. Can you file a BZ about this problem against libvirt. It impacts F9 and rawhide too 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 pemboa at gmail.com Tue Jul 22 15:02:03 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 10:02:03 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1216736144.11046.8.camel@gilboa-work-dev.localdomain> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> Message-ID: <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara wrote: > > On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: >> Ahmed Kamal wrote: >> > another idea, is when a denial occurs, and we get this nice balloon, >> > it would contain 2 buttons >> > - AutoFix: automatically attempts changing the offending file's >> > context, as per the recommended action >> > >> >> This is a sharp edge for users to cut themselves on. It would be nice if >> we would detect when the error was a result of inconsistencies though >> (such as the file label not matching policy). >> >> IMHO, we should be able to do the following: >> >> - We should have exempt, which ignores the denial for now. It also flags >> the issue upstream. Denial messages for the exempt process are then >> rerouted to a safe place. >> - Whenever policy-kit is updated, the exemptions are reevaluated and >> removed if they should be addressed. >> - We should come up with some secure way of quickly propagating >> information about known selinux issues, so that denial warnings can be >> suppressed until a fix is available >> - There should be more graphical tools for manipulating policy itself. >> The user should be able to see a list of local policy exceptions they >> have made. >> >> --CJD >> > > Couldn't exempt be (ab)used to an attacker if/when it becomes common > knowledge? Through social engineering, yes. That's why it's a terrible solution, but I'm not sure there is any good way around it. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Tue Jul 22 15:09:19 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 10:09:19 -0500 Subject: What to do about wireless issues? Message-ID: <16de708d0807220809m43e4253bka5613f72428dfb94@mail.gmail.com> What is the proper method for dealing with wireless issues? Wirless is pretty popular now, and I find myself having issues with the wireless stack even when I specifically choose the hardware to be compatible. Due to the number of pieces in place, I can hardly file a proper bug report due to my own ignorance on the matter. Is their a single medium where users can reach people knowledgeable enough at least give me (or other users) enough information to determine which component is malfunctioning? For example, I have two examples currently with me where wifi worked once, then never well again (so far) with no obvious logged errors. (not giving details as I am not looking to use this list to troubleshoot what is possible an end user problem) Or do I just keep thing to the general list and hope for a response? Arthur Pemberton -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From cra at WPI.EDU Tue Jul 22 15:30:13 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jul 2008 11:30:13 -0400 Subject: What to do about wireless issues? In-Reply-To: <16de708d0807220809m43e4253bka5613f72428dfb94@mail.gmail.com> References: <16de708d0807220809m43e4253bka5613f72428dfb94@mail.gmail.com> Message-ID: <20080722153013.GO23765@angus.ind.WPI.EDU> On Tue, Jul 22, 2008 at 10:09:19AM -0500, Arthur Pemberton wrote: > What is the proper method for dealing with wireless issues? Wirless is > pretty popular now, and I find myself having issues with the wireless > stack even when I specifically choose the hardware to be compatible. > Due to the number of pieces in place, I can hardly file a proper bug > report due to my own ignorance on the matter. Is their a single medium > where users can reach people knowledgeable enough at least give me (or > other users) enough information to determine which component is > malfunctioning? > > For example, I have two examples currently with me where wifi worked > once, then never well again (so far) with no obvious logged errors. > (not giving details as I am not looking to use this list to > troubleshoot what is possible an end user problem) > > Or do I just keep thing to the general list and hope for a response? > > Arthur Pemberton In general, I would use these steps: Edit this file: /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service by adding " -ddd" after /usr/sbin/wpa_supplicant so it looks something like this: Exec=/usr/sbin/wpa_supplicant -ddd -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log Then reboot. This will add lots of debugging information to the log file (which may grow fairly large). Then when you have a problem connecting to a wireless network, open a bug against NetworkManager and attach these files to the bug: /var/log/messages /var/log/wpa_supplicant.log NOTE: /var/log/wpa_supplicant.log might be zero bytes in length. If that happens, find the latest logrotated copy of the file and attach that one instead: ls -ltr /var/log/wpa_supplicant* e.g. /var/log/wpa_supplicant.log-20080722 Also, paste the output of these into the bug: nm-tool dmesg (the latter can be helpful to see kernel messages from your wireless driver) Also, note what you see in the nm-applet drop-down list, whether there is a security icon or a computer icon, etc. From pemboa at gmail.com Tue Jul 22 15:37:41 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 10:37:41 -0500 Subject: What to do about wireless issues? In-Reply-To: <20080722153013.GO23765@angus.ind.WPI.EDU> References: <16de708d0807220809m43e4253bka5613f72428dfb94@mail.gmail.com> <20080722153013.GO23765@angus.ind.WPI.EDU> Message-ID: <16de708d0807220837l1b187f71p836af140d038b1aa@mail.gmail.com> On Tue, Jul 22, 2008 at 10:30 AM, Chuck Anderson wrote: > On Tue, Jul 22, 2008 at 10:09:19AM -0500, Arthur Pemberton wrote: >> What is the proper method for dealing with wireless issues? Wirless is >> pretty popular now, and I find myself having issues with the wireless >> stack even when I specifically choose the hardware to be compatible. >> Due to the number of pieces in place, I can hardly file a proper bug >> report due to my own ignorance on the matter. Is their a single medium >> where users can reach people knowledgeable enough at least give me (or >> other users) enough information to determine which component is >> malfunctioning? >> >> For example, I have two examples currently with me where wifi worked >> once, then never well again (so far) with no obvious logged errors. >> (not giving details as I am not looking to use this list to >> troubleshoot what is possible an end user problem) >> >> Or do I just keep thing to the general list and hope for a response? >> >> Arthur Pemberton > > > In general, I would use these steps: > > Edit this file: > > /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service > > by adding " -ddd" after /usr/sbin/wpa_supplicant so it looks something > like this: > > Exec=/usr/sbin/wpa_supplicant -ddd -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log > > Then reboot. This will add lots of debugging information to the log > file (which may grow fairly large). > > Then when you have a problem connecting to a wireless network, open a > bug against NetworkManager and attach these files to the bug: > > /var/log/messages > /var/log/wpa_supplicant.log > > NOTE: /var/log/wpa_supplicant.log might be zero bytes in length. If > that happens, find the latest logrotated copy of the file and attach > that one instead: > > ls -ltr /var/log/wpa_supplicant* > > e.g. /var/log/wpa_supplicant.log-20080722 > > Also, paste the output of these into the bug: > > nm-tool > > dmesg > > (the latter can be helpful to see kernel messages from your wireless > driver) > > Also, note what you see in the nm-applet drop-down list, whether there > is a security icon or a computer icon, etc. Thank you, this is useful. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From maximilianbianco at gmail.com Tue Jul 22 16:06:06 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 22 Jul 2008 12:06:06 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> Message-ID: <4886056E.3010307@gmail.com> Arthur Pemberton wrote: > On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara wrote: >> On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: >>> Ahmed Kamal wrote: >>>> another idea, is when a denial occurs, and we get this nice balloon, >>>> it would contain 2 buttons >>>> - AutoFix: automatically attempts changing the offending file's >>>> context, as per the recommended action >>>> >>> This is a sharp edge for users to cut themselves on. It would be nice if >>> we would detect when the error was a result of inconsistencies though >>> (such as the file label not matching policy). >>> >>> IMHO, we should be able to do the following: >>> >>> - We should have exempt, which ignores the denial for now. It also flags >>> the issue upstream. Denial messages for the exempt process are then >>> rerouted to a safe place. >>> - Whenever policy-kit is updated, the exemptions are reevaluated and >>> removed if they should be addressed. >>> - We should come up with some secure way of quickly propagating >>> information about known selinux issues, so that denial warnings can be >>> suppressed until a fix is available >>> - There should be more graphical tools for manipulating policy itself. >>> The user should be able to see a list of local policy exceptions they >>> have made. >>> >>> --CJD >>> >> Couldn't exempt be (ab)used to an attacker if/when it becomes common >> knowledge? > > Through social engineering, yes. That's why it's a terrible solution, > but I'm not sure there is any good way around it. > Don't implement it or if you do make that nonsense optional and not the default. Everyone wants things to be simpler, there is no easy way out. System security is not something simple. Developer's continue to indulge in running permissive or turning SELinux off entirely, all this accomplishes is to make it take longer to establish good policy, SELinux isn't going anywhere. People need to get used to it. There are a number of tools available to troubleshoot any issue but nobody seems to want to use any of them. The kerneloops for SELinux is a good idea but it isn't going to instantly solve anyone's problems. All those reports still have to sorted and reviewed to determine how to fix policy to suit the majority of users, it still may take weeks to sort it all out. People often are not even trying the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of suggesting fixes. Audit2allow is great for this until upstream can figure out how to work it out. All this talk of allow/deny buttons is absolute insanity and it will ruin one of the few useful security tools that exist. -Max -- Fortune favors the BOLD From skvidal at fedoraproject.org Tue Jul 22 16:03:00 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jul 2008 12:03:00 -0400 Subject: pushing yum 3.2.17-2 back to f8 Message-ID: <1216742580.30065.1.camel@rosebud> Hi folks, I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. It speeds things up a fair bit and it also fixes a number of minor-ish bugs. However, it also pulls in a few new deps. What are folks thoughts on this? thanks, -sv -- I only speak for me. From pemboa at gmail.com Tue Jul 22 16:10:31 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 11:10:31 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <4886056E.3010307@gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> Message-ID: <16de708d0807220910o1b5c6945p11d3ebea7f9e09b7@mail.gmail.com> On Tue, Jul 22, 2008 at 11:06 AM, max wrote: > Arthur Pemberton wrote: >> >> On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara wrote: >>> >>> On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: >>>> >>>> Ahmed Kamal wrote: >>>>> >>>>> another idea, is when a denial occurs, and we get this nice balloon, >>>>> it would contain 2 buttons >>>>> - AutoFix: automatically attempts changing the offending file's >>>>> context, as per the recommended action >>>>> >>>> This is a sharp edge for users to cut themselves on. It would be nice if >>>> we would detect when the error was a result of inconsistencies though >>>> (such as the file label not matching policy). >>>> >>>> IMHO, we should be able to do the following: >>>> >>>> - We should have exempt, which ignores the denial for now. It also flags >>>> the issue upstream. Denial messages for the exempt process are then >>>> rerouted to a safe place. >>>> - Whenever policy-kit is updated, the exemptions are reevaluated and >>>> removed if they should be addressed. >>>> - We should come up with some secure way of quickly propagating >>>> information about known selinux issues, so that denial warnings can be >>>> suppressed until a fix is available >>>> - There should be more graphical tools for manipulating policy itself. >>>> The user should be able to see a list of local policy exceptions they >>>> have made. >>>> >>>> --CJD >>>> >>> Couldn't exempt be (ab)used to an attacker if/when it becomes common >>> knowledge? >> >> Through social engineering, yes. That's why it's a terrible solution, >> but I'm not sure there is any good way around it. >> > Don't implement it or if you do make that nonsense optional and not the > default. Everyone wants things to be simpler, there is no easy way out. > System security is not something simple. Developer's continue to indulge in > running permissive or turning SELinux off entirely, all this accomplishes is > to make it take longer to establish good policy, SELinux isn't going > anywhere. People need to get used to it. There are a number of tools > available to troubleshoot any issue but nobody seems to want to use any of > them. The kerneloops for SELinux is a good idea but it isn't going to > instantly solve anyone's problems. All those reports still have to sorted > and reviewed to determine how to fix policy to suit the majority of users, > it still may take weeks to sort it all out. People often are not even trying > the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of > suggesting fixes. Audit2allow is great for this until upstream can figure > out how to work it out. All this talk of allow/deny buttons is absolute > insanity and it will ruin one of the few useful security tools that exist. > > -Max Most of the discussion was around a "Fix" button though. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From gnomeuser at gmail.com Tue Jul 22 16:13:28 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 22 Jul 2008 18:13:28 +0200 Subject: pushing yum 3.2.17-2 back to f8 In-Reply-To: <1216742580.30065.1.camel@rosebud> References: <1216742580.30065.1.camel@rosebud> Message-ID: <1dedbbfc0807220913s7852ff06ub52e42c1feb258c2@mail.gmail.com> 2008/7/22 seth vidal : > Hi folks, > I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. > It speeds things up a fair bit and it also fixes a number of minor-ish > bugs. However, it also pulls in a few new deps. What are folks thoughts > on this? > > thanks, > -sv It seems to have undergone a great deal of testing, it truly is a superior yum to the one on f8 currently. I say doing the update would be doing our users a service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnomeuser at gmail.com Tue Jul 22 16:28:55 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 22 Jul 2008 18:28:55 +0200 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <4886056E.3010307@gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> Message-ID: <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> 2008/7/22 max : > Arthur Pemberton wrote: > >> On Tue, Jul 22, 2008 at 9:15 AM, Gilboa Davara wrote: >> >>> On Thu, 2008-07-17 at 17:03 -0400, Casey Dahlin wrote: >>> >>>> Ahmed Kamal wrote: >>>> >>>>> another idea, is when a denial occurs, and we get this nice balloon, >>>>> it would contain 2 buttons >>>>> - AutoFix: automatically attempts changing the offending file's >>>>> context, as per the recommended action >>>>> >>>>> This is a sharp edge for users to cut themselves on. It would be nice >>>> if >>>> we would detect when the error was a result of inconsistencies though >>>> (such as the file label not matching policy). >>>> >>>> IMHO, we should be able to do the following: >>>> >>>> - We should have exempt, which ignores the denial for now. It also flags >>>> the issue upstream. Denial messages for the exempt process are then >>>> rerouted to a safe place. >>>> - Whenever policy-kit is updated, the exemptions are reevaluated and >>>> removed if they should be addressed. >>>> - We should come up with some secure way of quickly propagating >>>> information about known selinux issues, so that denial warnings can be >>>> suppressed until a fix is available >>>> - There should be more graphical tools for manipulating policy itself. >>>> The user should be able to see a list of local policy exceptions they >>>> have made. >>>> >>>> --CJD >>>> >>>> Couldn't exempt be (ab)used to an attacker if/when it becomes common >>> knowledge? >>> >> >> Through social engineering, yes. That's why it's a terrible solution, >> but I'm not sure there is any good way around it. >> >> Don't implement it or if you do make that nonsense optional and not the > default. Everyone wants things to be simpler, there is no easy way out. > System security is not something simple. Developer's continue to indulge in > running permissive or turning SELinux off entirely, all this accomplishes is > to make it take longer to establish good policy, SELinux isn't going > anywhere. People need to get used to it. There are a number of tools > available to troubleshoot any issue but nobody seems to want to use any of > them. The kerneloops for SELinux is a good idea but it isn't going to > instantly solve anyone's problems. All those reports still have to sorted > and reviewed to determine how to fix policy to suit the majority of users, > it still may take weeks to sort it all out. People often are not even trying > the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of > suggesting fixes. Audit2allow is great for this until upstream can figure > out how to work it out. All this talk of allow/deny buttons is absolute > insanity and it will ruin one of the few useful security tools that exist. Any suggested solution that starts with "open a terminal" scares users, additionally if they are required to be root in said terminal I would hestitate to guess that we lose everyone except a bare minimum of users when looking at the big picture - my mother surely should not be asked to do this, the mere thought of her with the root password in hand terrifies me add to that firing off random commands she has no idea what does - it's a wonder Hollywood has yet to make a blockbuster horror movie following this plot. In terms of what SELinux does currently, it's an improvement over the older releases but it's still far from being something I would let my mother ticker with - and the policy currently has plenty of holes in terms of what an average user might do, just the other day I discovered SELinux utter fail when plugging in my iPod (this was fixed within days of being filed and as I recall an update was pushed soon there after, so the response is generally good but that is still some 2 weeks where aunt tilly can't use her iPod). Should asking the user to drop to a terminal as root and issue commands really be our first line of defence.. I certainly hope not. We really need to be more proactive in gathering failures instead of relying on the user to patch up the policy with mysterious cli magic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Tue Jul 22 16:42:35 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 11:42:35 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> Message-ID: <16de708d0807220942u18e5b253yc4a69164cc87e7ff@mail.gmail.com> 2008/7/22 David Nielsen : > > > 2008/7/22 max : [ snip ] >> Don't implement it or if you do make that nonsense optional and not the >> default. Everyone wants things to be simpler, there is no easy way out. >> System security is not something simple. Developer's continue to indulge in >> running permissive or turning SELinux off entirely, all this accomplishes is >> to make it take longer to establish good policy, SELinux isn't going >> anywhere. People need to get used to it. There are a number of tools >> available to troubleshoot any issue but nobody seems to want to use any of >> them. The kerneloops for SELinux is a good idea but it isn't going to >> instantly solve anyone's problems. All those reports still have to sorted >> and reviewed to determine how to fix policy to suit the majority of users, >> it still may take weeks to sort it all out. People often are not even trying >> the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of >> suggesting fixes. Audit2allow is great for this until upstream can figure >> out how to work it out. All this talk of allow/deny buttons is absolute >> insanity and it will ruin one of the few useful security tools that exist. > > Any suggested solution that starts with "open a terminal" scares users, > additionally if they are required to be root in said terminal I would > hestitate to guess that we lose everyone except a bare minimum of users when > looking at the big picture While I understand this sentiment, no one in this thread as suggested this as a solution. > my mother surely should not be asked to do > this, the mere thought of her with the root password in hand terrifies me In this regard, Ubuntu's use of sudo is useful > add to that firing off random commands she has no idea what does - it's a > wonder Hollywood has yet to make a blockbuster horror movie following this > plot. Again, no one in this thread has suggested this. > In terms of what SELinux does currently, it's an improvement over the > older releases but it's still far from being something I would let my mother > ticker with - and the policy currently has plenty of holes in terms of what > an average user might do, just the other day I discovered SELinux utter fail > when plugging in my iPod (this was fixed within days of being filed and as I > recall an update was pushed soon there after, so the response is generally > good but that is still some 2 weeks where aunt tilly can't use her iPod). Fair enough. We can't do everything for the sake of aunty tilly though. > Should asking the user to drop to a terminal as root and issue commands > really be our first line of defence.. I certainly hope not. We really need > to be more proactive in gathering failures instead of relying on the user to > patch up the policy with mysterious cli magic. What are you responding to? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From mschwendt at gmail.com Tue Jul 22 17:02:57 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 22 Jul 2008 19:02:57 +0200 Subject: pushing yum 3.2.17-2 back to f8 In-Reply-To: <1216742580.30065.1.camel@rosebud> References: <1216742580.30065.1.camel@rosebud> Message-ID: <20080722190257.4111f67f.mschwendt@gmail.com> On Tue, 22 Jul 2008 12:03:00 -0400, seth vidal wrote: > Hi folks, > I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. > It speeds things up a fair bit and it also fixes a number of minor-ish > bugs. However, it also pulls in a few new deps. What are folks thoughts > on this? Positive. It would also fix two broken deps in F8 yum-utils. I've been using yum-3.2.16-2.fc10 (incl.deps) on F8 for a few weeks. No problems so far. From mclasen at redhat.com Tue Jul 22 17:08:51 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jul 2008 13:08:51 -0400 Subject: OLPC & package dependency growth In-Reply-To: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> References: <1215610955.2673.17.camel@olpc-desktop01.laptop.org> Message-ID: <1216746531.3514.11.camel@localhost.localdomain> On Wed, 2008-07-09 at 09:42 -0400, Daniel Drake wrote: > Hi, > > I'm working on OS-level issues at OLPC. I saw Greg Dekoenigsberg's mail > about Fedora/OLPC collaboration (thanks Greg!) and have another point to > raise: > > We're currently working on upgrading from F7 to F9 for our next major > software release. One of the challenges here is that by upgrading, over > 100 packages were added to the build as dependencies of packages we were > already including. FYI, we've split out gvfs backends in rawhide now. From gnomeuser at gmail.com Tue Jul 22 17:10:46 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 22 Jul 2008 19:10:46 +0200 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <16de708d0807220942u18e5b253yc4a69164cc87e7ff@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> <16de708d0807220942u18e5b253yc4a69164cc87e7ff@mail.gmail.com> Message-ID: <1dedbbfc0807221010r2d558e73h6053c0c34bee0865@mail.gmail.com> 2008/7/22 Arthur Pemberton : > 2008/7/22 David Nielsen : > > > > > > 2008/7/22 max : > [ snip ] > >> Don't implement it or if you do make that nonsense optional and not the > >> default. Everyone wants things to be simpler, there is no easy way out. > >> System security is not something simple. Developer's continue to > indulge in > >> running permissive or turning SELinux off entirely, all this > accomplishes is > >> to make it take longer to establish good policy, SELinux isn't going > >> anywhere. People need to get used to it. There are a number of tools > >> available to troubleshoot any issue but nobody seems to want to use any > of > >> them. The kerneloops for SELinux is a good idea but it isn't going to > >> instantly solve anyone's problems. All those reports still have to > sorted > >> and reviewed to determine how to fix policy to suit the majority of > users, > >> it still may take weeks to sort it all out. People often are not even > trying > >> the fixes suggested by SETroubleshoot. SETroubleshoot does a good job of > >> suggesting fixes. Audit2allow is great for this until upstream can > figure > >> out how to work it out. All this talk of allow/deny buttons is absolute > >> insanity and it will ruin one of the few useful security tools that > exist. > > What are you responding to? The above seems to indicate to me an opinion that the current solutions are sufficient, though could be expanded with automated gathering of information akin. Every SELinux prompt I have seen so far suggests terminal usage instead of a direct "click to implement this" solution. I merely point out cases where this is not sufficient. If I read this wrong I apologize, I stand by my opinion that SELinux should be useful even in cases where there are holes in the policy, currently it is not. If we want to grab a higher market share we do need to design solutions to encompass Aunt Tilly type people, at least every solution we deploy by default such as SELinux. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Tue Jul 22 17:21:37 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jul 2008 13:21:37 -0400 Subject: pushing yum 3.2.17-2 back to f8 In-Reply-To: <20080722190257.4111f67f.mschwendt@gmail.com> References: <1216742580.30065.1.camel@rosebud> <20080722190257.4111f67f.mschwendt@gmail.com> Message-ID: <1216747297.30065.17.camel@rosebud> On Tue, 2008-07-22 at 19:02 +0200, Michael Schwendt wrote: > On Tue, 22 Jul 2008 12:03:00 -0400, seth vidal wrote: > > > Hi folks, > > I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. > > It speeds things up a fair bit and it also fixes a number of minor-ish > > bugs. However, it also pulls in a few new deps. What are folks thoughts > > on this? > > Positive. It would also fix two broken deps in F8 yum-utils. > I've been using yum-3.2.16-2.fc10 (incl.deps) on F8 for a few > weeks. No problems so far. Okay, I'll push it into updates-testing for f8 today and we can see what bits break that we weren't expecting to break. :) thanks -sv From dwmw2 at infradead.org Tue Jul 22 19:38:39 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Jul 2008 15:38:39 -0400 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <20080722095850.GC5192@redhat.com> References: <4884EC5A.3000100@redhat.com> <20080722095850.GC5192@redhat.com> Message-ID: <1216755519.3019.37.camel@shinybook.infradead.org> On Tue, 2008-07-22 at 10:58 +0100, Daniel P. Berrange wrote: > On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=435757 > > Sometime after F8, something changed where stuff attached to a bridge > > fails to connect until 15 seconds later. A manual workaround of brctl > > setfd BRIDGENAME 0.1 makes stuff work immediately. > > > > Are there any reasons why don't we do this by default for virbr0 in libvirt? > > Because no one has ever suggested it before... > > Arguably we should just turn off STP on the virbr0 device. Since it is > not connected directly to the public LAN[1] there is no risk of network > loops and thus spanning tree protocol is pointless for virbr0. Is there no chance of bridging directly to the outside world by adding a real Ethernet device to the bridge? -- dwmw2 From lists at timj.co.uk Tue Jul 22 19:44:22 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 20:44:22 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216730300.12864.29.camel@weaponx> References: <1216730300.12864.29.camel@weaponx> Message-ID: <48863896.8090407@timj.co.uk> Josh Boyer wrote: > We have several options for the Fedora 10 codename, and you get to help > decide which we use! Please may we have an additional option "None"? I cannot see any useful purpose for this other than to make non-technical or new users wonder why we have two names for one piece of software, one of which nobody uses and doesn't appear to bear any resemblance to anything other than some bad, cliquey in-joke. Fortunately we don't use it *quite* as prominently as some other Linux distributions (why on earth would I want to admit to someone that I use an operating system called "potato"?) but these names still make me cringe. Tim From fche at redhat.com Tue Jul 22 20:10:36 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 22 Jul 2008 16:10:36 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> (Tim Jackson's message of "Tue, 22 Jul 2008 20:44:22 +0100") References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: Tim Jackson writes: >> We have several options for the Fedora 10 codename, and you get to help >> decide which we use! > > Please may we have an additional option "None"? > > I cannot see any useful purpose for this [...] > one of which nobody uses and doesn't appear to bear any > resemblance to anything other than some bad, cliquey in-joke. My cliquey in-joke contribution to your suggestion: "+1". :) - FChE From lists at timj.co.uk Tue Jul 22 20:20:35 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 21:20:35 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216754706.1399.6.camel@Nokia-N800-23-14> References: <1216754706.1399.6.camel@Nokia-N800-23-14> Message-ID: <48864113.4060509@timj.co.uk> Josh Boyer wrote (to a bad address copied from a bad address in my original mail): > Just vote 0 for all of them. If I understand the voting system correctly, that's not equivalent because it means "no opinion" not "none of the above" or "none" [1]. I think under the current system with no quorum that if (hypothetically) everyone except one person wanted "none" and thus voted zero for everything, if one person voted "1" for "Stupidname" then "Stupidname" would win regardless of the clear contrary opinion of the majority. Tim [1] "none" and "none of the above" are, of course, not the same From gnomeuser at gmail.com Tue Jul 22 20:22:23 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 22 Jul 2008 22:22:23 +0200 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> 2008/7/22 Tim Jackson : > Josh Boyer wrote: > > We have several options for the Fedora 10 codename, and you get to help >> decide which we use! >> > > Please may we have an additional option "None"? > > I cannot see any useful purpose for this other than to make > non-technical or new users wonder why we have two names for one piece of > software, one of which nobody uses and doesn't appear to bear any > resemblance to anything other than some bad, cliquey in-joke. > > Fortunately we don't use it *quite* as prominently as some other Linux > distributions (why on earth would I want to admit to someone that I use > an operating system called "potato"?) but these names still make me cringe. When Werewolf came out the name was used prominently in almost every review I read. It seems people like the name in general, just look at Ubuntu, officially they are numbered releases but everyone uses the names. It's a good PR move and it gives our releases a little bit of personality. I, for one, would proudly announce thatI used Potato if it was a Fedora release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Tue Jul 22 20:21:37 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jul 2008 16:21:37 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48864113.4060509@timj.co.uk> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> Message-ID: <1216758097.30065.20.camel@rosebud> On Tue, 2008-07-22 at 21:20 +0100, Tim Jackson wrote: > Josh Boyer wrote (to a bad address copied from a bad address in my > original mail): > > > Just vote 0 for all of them. > > If I understand the voting system correctly, that's not equivalent because > it means "no opinion" not "none of the above" or "none" [1]. I think under > the current system with no quorum that if (hypothetically) everyone except > one person wanted "none" and thus voted zero for everything, if one person > voted "1" for "Stupidname" then "Stupidname" would win regardless of the > clear contrary opinion of the majority. > That'd be correct, though. B/c we don't care if you don't want a name. We care about having a name for the distro. So a result of 'None' doesn't do anything for us. We want a release name - hence why we have this. It's fine if you think it's useless, afaict, the board does not think it's useless and it is somewhat amusing. -sv From lists at timj.co.uk Tue Jul 22 20:32:52 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 21:32:52 +0100 Subject: ENVR checking In-Reply-To: <1216664796.12190.32.camel@localhost.localdomain> References: <4882D40E.6050309@timj.co.uk> <20080720091033.7e1bfdf7.mschwendt@gmail.com> <4884D289.1070505@timj.co.uk> <1216664796.12190.32.camel@localhost.localdomain> Message-ID: <488643F4.6010405@timj.co.uk> Jesse Keating wrote: > I took this morning and early afternoon to write up an e:n-v-r > comparison script that uses koji information as the basis of it's > comparison. I've got it compat-complete with the output of the old > script, and it runs in about 3 minutes to compare from f8-final all the > way up through rawhide. That is fantastic, thanks very much for the work Jesse. Much appreciated. I would say I'm looking forward to seeing the output, but I suspect it may make for some uncomfortable reading all round :) Tim From smooge at gmail.com Tue Jul 22 20:33:42 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 22 Jul 2008 14:33:42 -0600 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216758097.30065.20.camel@rosebud> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> Message-ID: <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> On Tue, Jul 22, 2008 at 2:21 PM, seth vidal wrote: > On Tue, 2008-07-22 at 21:20 +0100, Tim Jackson wrote: >> Josh Boyer wrote (to a bad address copied from a bad address in my >> original mail): >> >> > Just vote 0 for all of them. >> >> If I understand the voting system correctly, that's not equivalent because >> it means "no opinion" not "none of the above" or "none" [1]. I think under >> the current system with no quorum that if (hypothetically) everyone except >> one person wanted "none" and thus voted zero for everything, if one person >> voted "1" for "Stupidname" then "Stupidname" would win regardless of the >> clear contrary opinion of the majority. >> > > That'd be correct, though. B/c we don't care if you don't want a name. > We care about having a name for the distro. > > So a result of 'None' doesn't do anything for us. We want a release name > - hence why we have this. > > It's fine if you think it's useless, afaict, the board does not think > it's useless and it is somewhat amusing. > Well I would like to propose that we shift gears a bit.. the naming contest was moved up to help the art group figure out a visual theme.. and I think that might be backwards.. how about the art group comes up with various visual themes.. that gets voted on and then we come up with a name that meets the chosen theme. [It would actually make for a new game ] -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rdieter at math.unl.edu Tue Jul 22 20:35:18 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Jul 2008 15:35:18 -0500 Subject: Cast your vote for the Fedora 10 Codename! References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: Tim Jackson wrote: > Josh Boyer wrote: > >> We have several options for the Fedora 10 codename, and you get to help >> decide which we use! > > Please may we have an additional option "None"? heh, tried to get "Nothing" on the ballot, but that was NACK'd by legal. :) -- Rex From mschwendt at gmail.com Tue Jul 22 20:46:37 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 22 Jul 2008 22:46:37 +0200 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> Message-ID: <20080722224637.c9447568.mschwendt@gmail.com> On Mon, 21 Jul 2008 20:06:29 +0000 (UTC), Rawhide wrote: > Broken upgrade path report for tags ['f8-final', 'dist-f8-updates', 'dist-f8-updates-testing', 'dist-f9-updates', 'dist-f9-updates-testing', 'dist-f10'] > > audacity: > dist-f8-updates-testing > dist-f9-updates (audacity-1.3.5-0.4.beta.fc8.1 audacity-1.3.2-21.fc9) > That's a false positive, because dist-f9-updates-testing is not taken into account. From jwilson at redhat.com Tue Jul 22 20:47:43 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 22 Jul 2008 16:47:43 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807181731.30567.jwilson@redhat.com> References: <200807181659.33092.jwilson@redhat.com> <200807181731.30567.jwilson@redhat.com> Message-ID: <200807221647.43306.jwilson@redhat.com> On Friday 18 July 2008 05:31:30 pm Jarod Wilson wrote: > On Friday 18 July 2008 04:59:32 pm Jarod Wilson wrote: > > Coming Real Soon Now to rawhide is a build of the final libraw1394 2.0.0, > > which includes a soname bump, which means a number of packages are going > > to need to be rebuild. A quick glance with repoquery suggests the list is > > limited to: > > > > unicap > > gstreamer-plugins-good > > coriander > > libfreebob > > pwlib > > kdebase > > kdebase3 > > dvgrab > > libiec61883 > > firecontrol > > libavc1394 > > > > The last four are all my packages, so I'll take care of them. The rest > > I'd rather leave to their respective maintainers, but can take care of > > those as well, if so desired (just a simple version-bump and rebuild). > > > > Should I attempt to figure out the magic to do a fancy chainbuild, or > > just let rawhide be busted for a day?... (haha, like its not somehow > > busted most days anyway... ;) > > So I've been told that something like this should do the job: > > 1) bump and tag each of the above > > 2) from within one of the dependent package's devel branch (can be anything > in the list, just call it pkg11), do: > > [jwilson at foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 > pkg1 ... pkg10" > > Unless someone objects, I'll probably just go ahead and do that this > weekend, rather than busticate rawhide even temporarily. Didn't get around to this until today, but hey, that gave me a chance to talk to the maintainers of all the packages without open ACLs and have them bump and tag so I can hit everything with a single chain build, which is finally in progress: http://koji.fedoraproject.org/koji/taskinfo?taskID=732486 -- Jarod Wilson jwilson at redhat.com From lists at timj.co.uk Tue Jul 22 21:12:29 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 22:12:29 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216758097.30065.20.camel@rosebud> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> Message-ID: <48864D3D.2040801@timj.co.uk> seth vidal wrote: > That'd be correct, though. B/c we don't care if you don't want a name. > We care about having a name for the distro. Phew, that's me told then. Never again will I have the temerity to question anything. Plus, of course "Fedora 10" isn't a name and thus can't possibly be considered as the canonical name for the tenth release of some software called "Fedora". I don't expect for a moment that everyone agrees with me that these codenames are unfunny and embarrassing, but how do you know for sure that "We" want a name if nobody can vote against it? (Or am I excluded from the "We" for daring to suggest something other than what "we've always done"?) (You may well be right. Maybe the Fedora "We" really does want a hilarious name, perhaps overwhelmingly so. In which case I'll accept that with good grace, and agree to disagree. But I didn't think one "INSERT INTO..." to find out was asking a lot, really...) Tim From lists at timj.co.uk Tue Jul 22 21:30:29 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 22:30:29 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> Message-ID: <48865175.6090801@timj.co.uk> David Nielsen wrote: > When Werewolf came out the name was used prominently in almost every > review I read. Right, so some of the time people call it "Fedora X" and some of the time people call it "Sillyname" (or maybe "Fedora Sillyname"). And that's a good thing for helping people (especially new users) to understand what we're about, which releases are which and in what order they come? > just look at Ubuntu, officially they are numbered releases but everyone uses the > names. Yes, and put off potential new users like me who find the whole thing very cliquey and unfriendly because they're interested in doing something useful with their computer, not trying to remember that Potato is newer than Carrot, but older than Turnip. Or work out that an upgrade from Radish to Cucumber might be possible but awkward due to the 3-release gap, whilst Parsnip is now unsupported, Ginger is a beta release and Onion is actually a vegetable, not an operating system. > I, for one, would proudly announce that I used Potato if it was a Fedora > release. I'd rather eat the entire CD respin, disc by disc. Tim From lists at timj.co.uk Tue Jul 22 21:35:31 2008 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 22 Jul 2008 22:35:31 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> Message-ID: <488652A3.9030409@timj.co.uk> Stephen John Smoogen wrote: > Well I would like to propose that we shift gears a bit.. the naming > contest was moved up to help the art group figure out a visual theme.. > and I think that might be backwards.. how about the art group comes up > with various visual themes.. that gets voted on and then we come up > with a name that meets the chosen theme. [It would actually make for a > new game ] Thanks Stephen, that's constructive. Although I'd still need some convincing, it would at least have a point, plus would have the extra advantage of giving those working on the art more creative freedom instead of being constrained by random wordplay. I like your logic - if we must have a codename, it at least makes sense to base it around something which has value. Art = highly visible and beneficial to users, promotes Fedora in a positive light. In-jokes = does nothing, possibly causes several negative consequences. Tim From snecklifter at gmail.com Tue Jul 22 21:46:02 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 22 Jul 2008 22:46:02 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <488652A3.9030409@timj.co.uk> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <488652A3.9030409@timj.co.uk> Message-ID: <364d303b0807221446i451f5d37n584bc0bd05b2f5ea@mail.gmail.com> 2008/7/22 Tim Jackson : > Stephen John Smoogen wrote: > >> Well I would like to propose that we shift gears a bit.. the naming >> contest was moved up to help the art group figure out a visual theme.. >> and I think that might be backwards.. how about the art group comes up >> with various visual themes.. that gets voted on and then we come up >> with a name that meets the chosen theme. [It would actually make for a >> new game ] > > Thanks Stephen, that's constructive. Although I'd still need some > convincing, it would at least have a point, plus would have the extra > advantage of giving those working on the art more creative freedom instead > of being constrained by random wordplay. > > I like your logic - if we must have a codename, it at least makes sense to > base it around something which has value. Art = highly visible and > beneficial to users, promotes Fedora in a positive light. In-jokes = does > nothing, possibly causes several negative consequences. Nice to see this hurricane is still firmly in full swing in this teacup. Unlike Ubuntu, our version numbers are more recognisable than the codenames. Giving each version of Fedora a name is a bit of fun, nothing more. Whilst I'm sad to see names like "Red Hat Linux" being sent to legal (seriously?) as this is obviously a waste of resources, I think if codenames for software irritates you then you possibly have too much time on your hands. Codenames have been around for years and probably always will be. Please don't piss on other people's fireworks because you don't like the bangs and flashes. -- Christopher Brown http://www.chruz.com From jamatos at fc.up.pt Tue Jul 22 21:47:52 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 22 Jul 2008 22:47:52 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48865175.6090801@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> Message-ID: <200807222247.53886.jamatos@fc.up.pt> On Tuesday 22 July 2008 22:30:29 Tim Jackson wrote: > Yes, and put off potential new users like me who find the whole thing very > cliquey and unfriendly because they're interested in doing something > useful with their computer, not trying to remember that Potato is newer > than Carrot, but older than Turnip. There are certain circles, from where some of our new users come, where releasing a full operating system together with its source code is considered very cliquey and yet we do it. :-) Different culture means different habits, what is wrong with that? If you think that the whole procedure is silly (that is OK) then it seems silly to me not to ignore it or else you look like D. Quixote fighting windmills. ;-) -- Jos? Ab?lio From mclasen at redhat.com Tue Jul 22 22:03:57 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jul 2008 18:03:57 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <200807222247.53886.jamatos@fc.up.pt> References: <1216730300.12864.29.camel@weaponx> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> <200807222247.53886.jamatos@fc.up.pt> Message-ID: <1216764237.3514.13.camel@localhost.localdomain> On Tue, 2008-07-22 at 22:47 +0100, Jos? Matos wrote: > If you think that the whole procedure is silly (that is OK) then it seems > silly to me not to ignore it or else you look like D. Quixote fighting > windmills. ;-) The procedure is silly, but if you simply ignore it, you implicitly agree to have your Fedora work advertised under a name that may be worse than just silly.... From cdahlin at redhat.com Tue Jul 22 21:59:10 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 22 Jul 2008 17:59:10 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48865175.6090801@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> Message-ID: <4886582E.2050106@redhat.com> Tim Jackson wrote: > David Nielsen wrote: > > > I, for one, would proudly announce that I used Potato if it was a > Fedora > > release. > > I'd rather eat the entire CD respin, disc by disc. > And I'd rather watch you do it. --CJD From cra at WPI.EDU Tue Jul 22 22:08:25 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jul 2008 18:08:25 -0400 Subject: What to do about wireless issues? In-Reply-To: <16de708d0807220837l1b187f71p836af140d038b1aa@mail.gmail.com> References: <16de708d0807220809m43e4253bka5613f72428dfb94@mail.gmail.com> <20080722153013.GO23765@angus.ind.WPI.EDU> <16de708d0807220837l1b187f71p836af140d038b1aa@mail.gmail.com> Message-ID: <20080722220825.GR23765@angus.ind.WPI.EDU> On Tue, Jul 22, 2008 at 10:37:41AM -0500, Arthur Pemberton wrote: > > e.g. /var/log/wpa_supplicant.log-20080722 > > > > Also, paste the output of these into the bug: > > > > nm-tool > > > > dmesg > > > > (the latter can be helpful to see kernel messages from your wireless > > driver) > > > > Also, note what you see in the nm-applet drop-down list, whether there > > is a security icon or a computer icon, etc. > > > Thank you, this is useful. A couple more things may be useful as well: iwlist scanning (point out which network in the scan results you are trying to connect to) iwconfig (check if it is Associated to the right ESSID) If you can, you might try disabling NetworkManager and connecting manually, especially if it is an open network (unencrypted): /sbin/service NetworkManager stop /sbin/iwconfig wlan0 essid "Foo" /sbin/iwconfig enc off /sbin/ifconfig wlan0 up /sbin/dhclient wlan0 For WEP encryption, instead of "enc off" use: /sbin/iwconfig key XXXX-XXXX-XXXX-XXXX or: /sbin/iwconfig key XXXXXXXX For WPA encrypted networks, that requires a bit more fussing about with wpa_supplicant.conf, killing wpa_supplicant, and then running wpa_supplicant manually. From jamatos at fc.up.pt Tue Jul 22 22:31:45 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 22 Jul 2008 23:31:45 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216764237.3514.13.camel@localhost.localdomain> References: <1216730300.12864.29.camel@weaponx> <200807222247.53886.jamatos@fc.up.pt> <1216764237.3514.13.camel@localhost.localdomain> Message-ID: <200807222331.45449.jamatos@fc.up.pt> On Tuesday 22 July 2008 23:03:57 Matthias Clasen wrote: > The procedure is silly, but if you simply ignore it, you implicitly > agree to have your Fedora work advertised under a name that may be worse > than just silly.... Then we need to have the code name to pass by Fedora Marketing sieve after passing the legal sieve. ;-) Apple gives names to their OS's release where the number would be enough. Is that silly? Here we have two different kinds of problems, either you disagree with the whole idea or you accept the idea but object to some of the possible choices. While I agree with the later I disagree with the former. -- Jos? Ab?lio From loupgaroublond at gmail.com Tue Jul 22 23:02:37 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 23 Jul 2008 01:02:37 +0200 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: <7f692fec0807221602t447b1386id0f46f7ff6dfe066@mail.gmail.com> On Tue, Jul 22, 2008 at 9:44 PM, Tim Jackson wrote: > Josh Boyer wrote: > >> We have several options for the Fedora 10 codename, and you get to help >> decide which we use! > > Please may we have an additional option "None"? > > I cannot see any useful purpose for this other than to make > non-technical or new users wonder why we have two names for one piece of > software, one of which nobody uses and doesn't appear to bear any > resemblance to anything other than some bad, cliquey in-joke. > > Fortunately we don't use it *quite* as prominently as some other Linux > distributions (why on earth would I want to admit to someone that I use > an operating system called "potato"?) but these names still make me cringe. Because Potato is awesome? Potato was the first Linux distribution I used and will always hold a special place in my heart. I don't know it as anything but Potato. I willingly will admit I used Potato, and would gladly go back if there were no security or compatibility issues. Not to mention potatoes are tasty and a good source of fiber and other nutrition. ;) -Yaakov From lists at timj.co.uk Tue Jul 22 23:02:59 2008 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 23 Jul 2008 00:02:59 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <200807222247.53886.jamatos@fc.up.pt> References: <1216730300.12864.29.camel@weaponx> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> <200807222247.53886.jamatos@fc.up.pt> Message-ID: <48866723.7090608@timj.co.uk> Jos? Matos wrote: > Different culture means different habits, what is wrong with that? Nothing at all; each to their own. But it wouldn't be the first time I've had to explain to a new user who is already dubious about Fedora and suspicious that this Linux thing is some sort of cryptic geeky nonsense why there is a weird obscure name used interchangeably with the more recognisable and user-understandable one. The name by which you distribute a piece of software may be completely unrelated to its merits from the point of view of you or I, but it *is* on the front line of users' awareness of it, and I'd rather Fedora had a reputation for welcoming and encouraging new users, not confusing them :-) I get (no, really) that it's "just a bit of fun" and rather low down the importance scale of world issues, but it *does* raise questions from those new to Fedora, we *did* just get asked for opinions and I'm only asking people to consider the appearance and appeal to users outside the regular Fedora/Linux community. I'm not trying to eat anyone's babies here, nor personally insult anyone who is deeply attached to codenames... Anyway, I've used enough bytes making the point for the first and only time since I started with RHL-5 (and I've thought the same since then), so I'll leave everyone to ponder, support or ridicule as they see fit, although it would be nice if people kept an open mind and sense of proportion and humour whilst doing any or all of the above :-) Tim From maximilianbianco at gmail.com Tue Jul 22 23:37:32 2008 From: maximilianbianco at gmail.com (max bianco) Date: Tue, 22 Jul 2008 19:37:32 -0400 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> References: <1216316523.11204.0.camel@Diffingo.localdomain> <487F9AAF.2020802@redhat.com> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> Message-ID: 2008/7/22 David Nielsen : > > Any suggested solution that starts with "open a terminal" scares users, I understand. However I don't think adding an allow/deny button is the answer. I think the main problem is that most people don't understand what SELinux does, or more accurately how it does things. > additionally if they are required to be root in said terminal I would > hestitate to guess that we lose everyone except a bare minimum of users when > looking at the big picture - my mother surely should not be asked to do > this, the mere thought of her with the root password in hand terrifies me > add to that firing off random commands she has no idea what does - it's a > wonder Hollywood has yet to make a blockbuster horror movie following this > plot. It would make for a good movie:^) My mother uses Fedora and hasn't had any issues that were SELinux related. Email, music, web surfing are all she does. I doubt Aunt Tily is doing much more than that. > In terms of what SELinux does currently, it's an improvement over the > older releases but it's still far from being something I would let my mother > ticker with - and the policy currently has plenty of holes in terms of what > an average user might do, just the other day I discovered SELinux utter fail > when plugging in my iPod (this was fixed within days of being filed and as I > recall an update was pushed soon there after, so the response is generally > good but that is still some 2 weeks where aunt tilly can't use her iPod). > Should asking the user to drop to a terminal as root and issue commands > really be our first line of defence.. I certainly hope not. We really need > to be more proactive in gathering failures instead of relying on the user to > patch up the policy with mysterious cli magic. I agree a better job needs to done but until F9 it was optional was it not? Now you can turn it off but it is enabled by default, combined with the kerneloops twist this should be sufficient for now. These things need time to be effective and implementing allow/deny buttons in the meantime is a recipe for disaster, I have seen the results of not having good host security, it isn't pretty. A little pain now is worth it, a little foresight is all I am asking. An allow/deny button is expedient but it ultimately goes against good security practices. It would be nigh impossible to challenge Microsoft today if they had taken the pains to implement good security from day one. Windows is a security disaster. An allow/deny button will make Fedora a security disaster. The casual user is more likely to hit allow than deny, more likely to blindly implement a bad solution precisely because its expedient. The end user puts their trust in the engineer to anticipate their needs and keep them safe. The developer community needs to make a commitment to SELinux if the issues are going to get resolved. I don't mean waiting for Dan Walsh to solve your problems either. Everyone here should understand that it isn't magic. That's the view of of an end user without a clue. Its hard work to get it to just work. All I am seeing is suggestions of making it easier, lets take the expedient route and worry about the consequences later. This approach isn't going to benefit anyone in the long run. If there are issues then where are all the threads talking about these issues? If everyone is an expert policy writer then why are there issues? A big problem is not many end users know what SELinux does. The process isn't transparent enough. If you need to develop policy for your package then why not do it on list? People can see what's going on and more important people can learn. Mistakes are going to be made, it is a simple fact of life. If end users can see the policy development process, if they can see the developer's working on these issues then I believe you can expect at least two things. 1) More patience because they can see it being worked on 2) faster development of policy I imagine that at some point some Microsoft engineer made the argument that security should take precedence but he/she got overruled. All in the name of expediency, of making it easier for the end user. We'll worry about security later. No you won't. Later it will be harder to implement because it will break everything, security is part of good design. It has to thought of and built in from first step to last. Hopefully the new SELinux documentation project will help educate people and make life easier. I assume everyone here is aware of this effort. -Max > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- If opinions were really like assholes we'd each have just one From pemboa at gmail.com Tue Jul 22 23:47:16 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jul 2008 18:47:16 -0500 Subject: Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux In-Reply-To: References: <1216316523.11204.0.camel@Diffingo.localdomain> <16de708d0807171219o42cae8b7rf10d67057b875d17@mail.gmail.com> <20080717155534.0d6141b5@solitude.devel.redhat.com> <3da3b5b40807171324l5002cbbbx595bee26dae29c6a@mail.gmail.com> <487FB3BC.3030109@redhat.com> <1216736144.11046.8.camel@gilboa-work-dev.localdomain> <16de708d0807220802k537ec2bar3750334b005729cd@mail.gmail.com> <4886056E.3010307@gmail.com> <1dedbbfc0807220928k643f2125oed621071cb4961d6@mail.gmail.com> Message-ID: <16de708d0807221647r1720c29doe71f94f249551a9c@mail.gmail.com> On Tue, Jul 22, 2008 at 6:37 PM, max bianco wrote: > 2008/7/22 David Nielsen : >> >> Any suggested solution that starts with "open a terminal" scares users, > > I understand. However I don't think adding an allow/deny button is the > answer. I think the main problem is that most people don't understand > what SELinux does, or more accurately how it does things. > > >> additionally if they are required to be root in said terminal I would >> hestitate to guess that we lose everyone except a bare minimum of users when >> looking at the big picture - my mother surely should not be asked to do >> this, the mere thought of her with the root password in hand terrifies me >> add to that firing off random commands she has no idea what does - it's a >> wonder Hollywood has yet to make a blockbuster horror movie following this >> plot. > > It would make for a good movie:^) My mother uses Fedora and hasn't had > any issues that were SELinux related. Email, music, web surfing are > all she does. I doubt Aunt Tily is doing much more than that. > > >> In terms of what SELinux does currently, it's an improvement over the >> older releases but it's still far from being something I would let my mother >> ticker with - and the policy currently has plenty of holes in terms of what >> an average user might do, just the other day I discovered SELinux utter fail >> when plugging in my iPod (this was fixed within days of being filed and as I >> recall an update was pushed soon there after, so the response is generally >> good but that is still some 2 weeks where aunt tilly can't use her iPod). >> Should asking the user to drop to a terminal as root and issue commands >> really be our first line of defence.. I certainly hope not. We really need >> to be more proactive in gathering failures instead of relying on the user to >> patch up the policy with mysterious cli magic. > > I agree a better job needs to done but until F9 it was optional was it > not? Now you can turn it off but it is enabled by default, On by default does not mean not optional. And if you meant opt-out, it was opt-out, still is. [ snip ] -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dev at nigelj.com Wed Jul 23 00:00:52 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 23 Jul 2008 12:00:52 +1200 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48864113.4060509@timj.co.uk> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> Message-ID: <488674B4.1040501@nigelj.com> Tim Jackson wrote: > Josh Boyer wrote (to a bad address copied from a bad address in my > original mail): > >> Just vote 0 for all of them. > > If I understand the voting system correctly, that's not equivalent > because it means "no opinion" not "none of the above" or "none" [1]. I > think under the current system with no quorum that if (hypothetically) > everyone except one person wanted "none" and thus voted zero for > everything, if one person voted "1" for "Stupidname" then "Stupidname" > would win regardless of the clear contrary opinion of the majority. Just a clarification to this statement, the voting form states: "Fedora Project has implemented Range Voting for this election, in particular the "Range (score-summing, blanks treated as zero score, no quorum rule)" range voting system. To cast your vote in this election simply select a value between 0 and 9 with 0 as 'least or no preference' and 9 as 'highest preference'. At the end of the election, the highest ranking candidate(s) are marked as the winners." This means: * There is no need for a 'No Opinion' option - "No Opinion" options are only useful for elections using 'averaging', where it basically acts as an abstain. An Averaging variation of Range Voting would add all the numerical 'scores' for a candidate, and then divide by number of non-no opinion voters, it'd then have to (from memory) reach a quorum of x% of the maximum possible vote (this is debated because there are SO MANY different variations)... - As such, use 0 to facilitate a blank ballot/no opinion * It is possible to fill in the form with all zero's - However this will have little/no effect, except to say in the end of ballot that x voted with x including yourself (useful in a way to show the number of people interested in voting) * There is a small mistake in the text - highest 'ranking' candidate(s) should read highest 'scoring' candidates (this is fixed in my working copy. As an extra note, the CFRV, while a useful resource is quite bias to a variation of Range Voting which we don't use, it's particularly focused around promoting Range Voting as a decent format for a presidential election (that's my take anyway). On a side note, there are other forms of voting similar to Range Voting, that form a (in my opinion) much fairer system, one I can think of off the top of my head, is STV, while complicated it does work and is quite effective for single horse and multiple horse races. - Nigel Fedora Elections Guru From mmcgrath at redhat.com Wed Jul 23 02:40:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jul 2008 21:40:38 -0500 (CDT) Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> Message-ID: On Tue, 22 Jul 2008, Stephen John Smoogen wrote: > On Tue, Jul 22, 2008 at 2:21 PM, seth vidal wrote: > > On Tue, 2008-07-22 at 21:20 +0100, Tim Jackson wrote: > >> Josh Boyer wrote (to a bad address copied from a bad address in my > >> original mail): > >> > >> > Just vote 0 for all of them. > >> > >> If I understand the voting system correctly, that's not equivalent because > >> it means "no opinion" not "none of the above" or "none" [1]. I think under > >> the current system with no quorum that if (hypothetically) everyone except > >> one person wanted "none" and thus voted zero for everything, if one person > >> voted "1" for "Stupidname" then "Stupidname" would win regardless of the > >> clear contrary opinion of the majority. > >> > > > > That'd be correct, though. B/c we don't care if you don't want a name. > > We care about having a name for the distro. > > > > So a result of 'None' doesn't do anything for us. We want a release name > > - hence why we have this. > > > > It's fine if you think it's useless, afaict, the board does not think > > it's useless and it is somewhat amusing. > > > > Well I would like to propose that we shift gears a bit.. the naming > contest was moved up to help the art group figure out a visual theme.. > and I think that might be backwards.. how about the art group comes up > with various visual themes.. that gets voted on and then we come up > with a name that meets the chosen theme. [It would actually make for a > new game ] > I wonder if we'll ever get big enough that the art team could make a theme for each proposed name and we could vote on that as part of the name selection... it'd be wicked awesome :) -Mike From airlied at redhat.com Wed Jul 23 02:45:05 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 23 Jul 2008 12:45:05 +1000 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> Message-ID: <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> On Tue, 2008-07-22 at 21:40 -0500, Mike McGrath wrote: > On Tue, 22 Jul 2008, Stephen John Smoogen wrote: > > > On Tue, Jul 22, 2008 at 2:21 PM, seth vidal wrote: > > > On Tue, 2008-07-22 at 21:20 +0100, Tim Jackson wrote: > > >> Josh Boyer wrote (to a bad address copied from a bad address in my > > >> original mail): > > >> > > >> > Just vote 0 for all of them. > > >> > > >> If I understand the voting system correctly, that's not equivalent because > > >> it means "no opinion" not "none of the above" or "none" [1]. I think under > > >> the current system with no quorum that if (hypothetically) everyone except > > >> one person wanted "none" and thus voted zero for everything, if one person > > >> voted "1" for "Stupidname" then "Stupidname" would win regardless of the > > >> clear contrary opinion of the majority. > > >> > > > > > > That'd be correct, though. B/c we don't care if you don't want a name. > > > We care about having a name for the distro. > > > > > > So a result of 'None' doesn't do anything for us. We want a release name > > > - hence why we have this. > > > > > > It's fine if you think it's useless, afaict, the board does not think > > > it's useless and it is somewhat amusing. > > > > > > > Well I would like to propose that we shift gears a bit.. the naming > > contest was moved up to help the art group figure out a visual theme.. > > and I think that might be backwards.. how about the art group comes up > > with various visual themes.. that gets voted on and then we come up > > with a name that meets the chosen theme. [It would actually make for a > > new game ] > > > > I wonder if we'll ever get big enough that the art team could make a theme > for each proposed name and we could vote on that as part of the name > selection... it'd be wicked awesome :) I more wonder why the art team feels the need to use the nick-name of the distro as a basis for the artwork.. surely they are an independent minded bunch, and it would allows to just choose names that we like instead of ones with meaningful artwork.. Notice I didn't see an type of X-rated stuff in Hardy Hardon, or whatever Ubuntus last distro was called.. Dave. From naheemzaffar at gmail.com Wed Jul 23 02:46:20 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 23 Jul 2008 03:46:20 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> Message-ID: <3adc77210807221946s69b29a54u4334a4eb01a0cb42@mail.gmail.com> > > I wonder if we'll ever get big enough that the art team could make a theme > for each proposed name and we could vote on that as part of the name > selection... it'd be wicked awesome :) > Each artwork concept already has a name... it would be as simple as putting them through legal and choosing the name after the winning artwork proposal. (in other words, to nominate a name, you would also nominate a visual concept to go along with it) Ofcourse it would also be massively wasteful of the artwork team if only one the proposals went in... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dledford at redhat.com Wed Jul 23 02:54:31 2008 From: dledford at redhat.com (Doug Ledford) Date: Tue, 22 Jul 2008 22:54:31 -0400 Subject: RFC: Exploded source repo layouts Message-ID: <1216781671.5216.58.camel@firewall.xsintricity.com> I've been working on getting this set up and functional. The first thing that pops up as an issue is the fact that when dealing with exploded source repos, you really want the topdir to be the same as upstream. That means that given a normal upstream source layout, the topdir is the same as the traditional RPM_BUILD_DIR. This promotes the most seamless integration with upstream, and the greatest ability to share things with upstream. It does, however, present problems for our custom make targets. So, what I've been working with is a sort of home grown standard. Obviously, no one to date has really been trying to handle things the way I'm doing now, or at least no one has attempted to even try and standardize it. We have had our dist-cvs setup, and other distros have had their internal setups, and the pkg-vcs people have been talking about other similar systems to our dist system. What people haven't been talking about is exploded source repos where the primary look and feel of the repo is just like a bare upstream repo, and where our distro specific stuff is an add-on to that upstream repo. That's what I'm aiming for. Here's how I've been doing it so far. First, we have to do away with a bunch of our make targets because they are too commonly named and might conflict with legitimate upstream make targets (well, more like some of them might conflict, some of them *definitely* conflict). This is important because our Makefile.common is included in upstream's toplevel Makefile. Second, upstream probably doesn't want to deal with trying to accommodate Fedora, Unbuntu, Gentoo, etc., so we need a simple way that upstream can accommodate us without putting a bunch of stress on them. My method for dealing with that is that everything Fedora specific (and specific to any other distro) goes into $topdir/distropkg. That's where you'll find a simple Makefile that includes our Makefile.common, that's where our spec file goes, that's where any custom source files go, and embedded in that simple distropkg/Makefile are any custom install or make targets that we need for this specific package (there is an example of this in the mdadm/distropkg/Makefile from the git repo below). The standard, as far as upstream is concerned, is this: everything distro specific goes into distropkg and the top level Makefile should include distropkg/Makefile if it exists (or alternatively, upstream can provide their own empty distropkg/Makefile and include it unconditionally in the toplevel Makefile if they want to save the overhead of testing for the distropkg/Makefile). As far as we are concerned, we make the majority of our custom changes, the stuff that we don't expect upstream to ever take because it simply is our goo that we use when building packages, in the distropkg directory and Makefile. Anything that upstream should take, get's done in the main source code repository and pushed upstream (with a git repo that's really easy...make the patch, commit, cherry pick to a for-upstream branch, email upstream about changesets, done). As far as Ubuntu, debian, others are concerned, they do the same thing. We each use distropkg to our own ends, and changes in that area are things we keep local and never send upstream. If people would like to see some examples of what I'm talking about, you can clone the following: git://fedorapeople.org/~dledford/mdadm.git git://fedorapeople.org/~dledford/common.git and see what things look like so far. Note: this is not yet a functional, building setup. For starters, I still need to add some custom headers to rpm (and add an rpm repo to the list above to other people can test with the modified rpm). Then I need to make a modified koji so I can build this into a build system. The above packages give a decent idea of what the repos would look like, and some of the make targets actually work (like the make tarball target). It's mainly there for people to take a look at things like the spec file and the filesystem layout and to provide feedback based upon what they see before things are so far along that it's hard to change anything. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 jwilson at redhat.com Wed Jul 23 04:29:07 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jul 2008 00:29:07 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807221647.43306.jwilson@redhat.com> References: <200807181659.33092.jwilson@redhat.com> <200807181731.30567.jwilson@redhat.com> <200807221647.43306.jwilson@redhat.com> Message-ID: <200807230029.07645.jwilson@redhat.com> On Tuesday 22 July 2008 04:47:43 pm Jarod Wilson wrote: > On Friday 18 July 2008 05:31:30 pm Jarod Wilson wrote: > > On Friday 18 July 2008 04:59:32 pm Jarod Wilson wrote: > > > Coming Real Soon Now to rawhide is a build of the final libraw1394 > > > 2.0.0, which includes a soname bump, which means a number of packages > > > are going to need to be rebuild. A quick glance with repoquery suggests > > > the list is limited to: > > > > > > unicap > > > gstreamer-plugins-good > > > coriander > > > libfreebob > > > pwlib > > > kdebase > > > kdebase3 > > > dvgrab > > > libiec61883 > > > firecontrol > > > libavc1394 > > > > > > The last four are all my packages, so I'll take care of them. The rest > > > I'd rather leave to their respective maintainers, but can take care of > > > those as well, if so desired (just a simple version-bump and rebuild). > > > > > > Should I attempt to figure out the magic to do a fancy chainbuild, or > > > just let rawhide be busted for a day?... (haha, like its not somehow > > > busted most days anyway... ;) > > > > So I've been told that something like this should do the job: > > > > 1) bump and tag each of the above > > > > 2) from within one of the dependent package's devel branch (can be > > anything in the list, just call it pkg11), do: > > > > [jwilson at foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 > > pkg1 ... pkg10" > > > > Unless someone objects, I'll probably just go ahead and do that this > > weekend, rather than busticate rawhide even temporarily. > > Didn't get around to this until today, but hey, that gave me a chance to > talk to the maintainers of all the packages without open ACLs and have them > bump and tag so I can hit everything with a single chain build, which is > finally in progress: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=732486 So something went haywire with the chain build, but just the same, the new libraw1394 somehow made it into the rawhide tree. I'm working on cleaning up the mess now... -- Jarod Wilson jwilson at redhat.com From jkeating at redhat.com Wed Jul 23 05:50:33 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jul 2008 01:50:33 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <20080722224637.c9447568.mschwendt@gmail.com> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> Message-ID: <1216792233.12190.68.camel@localhost.localdomain> On Tue, 2008-07-22 at 22:46 +0200, Michael Schwendt wrote: > That's a false positive, because dist-f9-updates-testing is not taken > into account. Hrm, it both is and isn't. It's plausible that somebody at one time installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing. I still think it's worth noting these occurrences when they happen. That said, it might also be worth doing this in two runs. One that takes the view of F8, F8-updates, f9-updates and another than takes the view of F8-updates-testing, F9-updates-testing. More things to play with when I get back from OLS. Another thought I had was that instead of listing the owners of packages, we could actually list the person whom built the offending E:N-V-R breaker. This is likely more interesting information anyway since the owner can change per branch and the owner often isn't the person doing the build anyway. I'll be looking to wire that up since the builder is in the data set I get back from koji in the initial query set. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Wed Jul 23 05:54:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jul 2008 01:54:29 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <200807222331.45449.jamatos@fc.up.pt> References: <1216730300.12864.29.camel@weaponx> <200807222247.53886.jamatos@fc.up.pt> <1216764237.3514.13.camel@localhost.localdomain> <200807222331.45449.jamatos@fc.up.pt> Message-ID: <1216792469.12190.70.camel@localhost.localdomain> On Tue, 2008-07-22 at 23:31 +0100, Jos? Matos wrote: > > Then we need to have the code name to pass by Fedora Marketing sieve after > passing the legal sieve. ;-) No, the marketing team needs to spend the energy to suggest names that match our criteria and are legally acceptable. Then they need to lobby the Fedora voting body to pick their suggested names. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Wed Jul 23 05:56:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jul 2008 01:56:02 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48866723.7090608@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> <200807222247.53886.jamatos@fc.up.pt> <48866723.7090608@timj.co.uk> Message-ID: <1216792562.12190.73.camel@localhost.localdomain> On Wed, 2008-07-23 at 00:02 +0100, Tim Jackson wrote: > Nothing at all; each to their own. But it wouldn't be the first time I've > had to explain to a new user who is already dubious about Fedora and > suspicious that this Linux thing is some sort of cryptic geeky nonsense > why there is a weird obscure name used interchangeably with the more > recognisable and user-understandable one. The name by which you distribute > a piece of software may be completely unrelated to its merits from the > point of view of you or I, but it *is* on the front line of users' > awareness of it, and I'd rather Fedora had a reputation for welcoming and > encouraging new users, not confusing them :-) Right, because "Windows ME", "Windows 98", "Windows 2000", "Windows XP", "Windows Vista" are instantly understandable and not cryptic at all. Or if you prefer "Leapord", "Panther", etc... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 nicu_fedora at nicubunu.ro Wed Jul 23 07:23:30 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 23 Jul 2008 10:23:30 +0300 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> Message-ID: <4886DC72.2080803@nicubunu.ro> Dave Airlie wrote: > On Tue, 2008-07-22 at 21:40 -0500, Mike McGrath wrote: >> I wonder if we'll ever get big enough that the art team could make a theme >> for each proposed name and we could vote on that as part of the name >> selection... it'd be wicked awesome :) > > I more wonder why the art team feels the need to use the nick-name of > the distro as a basis for the artwork.. surely they are an independent > minded bunch, and it would allows to just choose names that we like > instead of ones with meaningful artwork.. Well, we really have not linked directly the name and the graphics so far... it was an attempt in F9 but the graphic with Sulphur crystal was dropped at the last minute. It was a thought that it may be cool if we can link the two and sometime is useful to have a starting point when developing some graphics. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From j.w.r.degoede at hhs.nl Wed Jul 23 07:43:31 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 23 Jul 2008 09:43:31 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <1216781671.5216.58.camel@firewall.xsintricity.com> References: <1216781671.5216.58.camel@firewall.xsintricity.com> Message-ID: <4886E123.4020407@hhs.nl> Doug Ledford wrote: > I've been working on getting this set up and functional. So Far I've been quiet on this, sort of hoping it would go away by itself, but as a contributor with quite a few packages let me say that I'm deeply worried about this whole distributed VCS / exploded source idea floating around. It seems there are a few people who are a big fan of this, and about as much active opponents. I have no problems with adding the possibility to use a distributed VCS with exploded trees to the mix of ways to maintain and build packages, but this should not replace the current nice and simple setup we have. First of all it does NOT match the way rpm was designed at all, rpm is about pristine sources with _separate_ patches, but most importantly, this is rather complicated making things unnecessary hard for people who don't want to do the stuff some of the distributed VCS proponents want to do. This worries me, I'm esp. worried that the barrier of entry to becoming a Fedora packager will be raised significantly. Also I even fail to see the claimed advantages in using a distributed VCS at all, isn't our mantra upstream upstream upstream, well if this mantra is properly followed and upstream is undergoing active development then most of the time the pristine sources should be fine without any patches at all, since all patches are integrated upstream in a timely manner. Also if someone wants to do so much work on the upstrewam sources, then he/she should just become an upstream developer. Really getting upstream cvs/svn/whatever access isn't that hard, then one can directly commit one's changes in to upstreams VCS. Regards, Hans From vnpenguin at vnoss.org Wed Jul 23 07:41:16 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 23 Jul 2008 09:41:16 +0200 Subject: Anaconda: loss fonts Message-ID: Hi, By using pungi on FC9-i386 (with all updates) I can make 1 installation CD which is bootable. But in Anaconda I loss all fonts. Here is the screenshot: http://vnoss.net/pub/fc9-err.png I miss some packages in my .ks files ? I have already dejavu-lgc-fonts, liberation-fonts & urw-fonts in my ks. Any idea for help ? Thanks, -- http://vnoss.org From ae at op5.se Wed Jul 23 08:16:46 2008 From: ae at op5.se (Andreas Ericsson) Date: Wed, 23 Jul 2008 10:16:46 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <4886E123.4020407@hhs.nl> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> Message-ID: <4886E8EE.5050905@op5.se> Hans de Goede wrote: > Doug Ledford wrote: >> I've been working on getting this set up and functional. > > > > So Far I've been quiet on this, sort of hoping it would go away by > itself, but as a contributor with quite a few packages let me say that > I'm deeply worried about this whole distributed VCS / exploded source > idea floating around. > Does any of those upstream packages use a dvcs as their source control tool? > It seems there are a few people who are a big fan of this, and about as > much active opponents. I have no problems with adding the possibility to > use a distributed VCS with exploded trees to the mix of ways to maintain > and build packages, but this should not replace the current nice and > simple setup we have. > Noone has proposed replacing the existing setup, so the rest of your email can safely be delegated to /dev/null. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From berrange at redhat.com Wed Jul 23 08:27:36 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 23 Jul 2008 09:27:36 +0100 Subject: brctl setfd virbr0 0.1 by default? In-Reply-To: <1216755519.3019.37.camel@shinybook.infradead.org> References: <4884EC5A.3000100@redhat.com> <20080722095850.GC5192@redhat.com> <1216755519.3019.37.camel@shinybook.infradead.org> Message-ID: <20080723082736.GB2291@redhat.com> On Tue, Jul 22, 2008 at 03:38:39PM -0400, David Woodhouse wrote: > On Tue, 2008-07-22 at 10:58 +0100, Daniel P. Berrange wrote: > > On Mon, Jul 21, 2008 at 04:06:50PM -0400, Warren Togami wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=435757 > > > Sometime after F8, something changed where stuff attached to a bridge > > > fails to connect until 15 seconds later. A manual workaround of brctl > > > setfd BRIDGENAME 0.1 makes stuff work immediately. > > > > > > Are there any reasons why don't we do this by default for virbr0 in libvirt? > > > > Because no one has ever suggested it before... > > > > Arguably we should just turn off STP on the virbr0 device. Since it is > > not connected directly to the public LAN[1] there is no risk of network > > loops and thus spanning tree protocol is pointless for virbr0. > > Is there no chance of bridging directly to the outside world by adding a > real Ethernet device to the bridge? Yes, you can do that too using regular Fedora initscripts. Warren is just referring to libvirt's 'Virtual Network' capability which is NAT based. You can read more about both options for network connectivity here: http://wiki.libvirt.org/page/Networking 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 dev at nigelj.com Wed Jul 23 08:32:14 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 23 Jul 2008 20:32:14 +1200 Subject: Anaconda: loss fonts In-Reply-To: References: Message-ID: <4886EC8E.4000009@nigelj.com> Vnpenguin wrote: > Hi, > By using pungi on FC9-i386 (with all updates) I can make 1 > installation CD which is bootable. But in Anaconda I loss all fonts. > Here is the screenshot: http://vnoss.net/pub/fc9-err.png > > I miss some packages in my .ks files ? I have already > dejavu-lgc-fonts, liberation-fonts & urw-fonts in my ks. > > Any idea for help ? > > Thanks, > > Do you have fontconfig? In my rawhide kickstart I added: fontconfig xorg-x11-fonts-100dpi xorg-x11-fonts-ISO8859-1-100dpi fonts-ISO8859-2 bitmap-fonts libXfont liberation-fonts dejavu-fonts I think fontconfig was the missing one and the others were just to entertain me, that said, the xorg-x11-fonts packages would be recommended, and also fonts-ISO8859-2 imo. - Nigel From romal at gmx.de Wed Jul 23 08:33:31 2008 From: romal at gmx.de (Robert M. Albrecht) Date: Wed, 23 Jul 2008 10:33:31 +0200 Subject: /usr/sbin/alternatives Message-ID: <4886ECDB.2030802@gmx.de> Hi, can alternatives only change links or is it able to manipulate config-files ? I wan`t to build an alternative-config-file, but only changing some links is insufficent. I also need to change a setting in one configuration file. Is alternative the right tool or is there another canoncial way ? cu romal www.romal.de blog.romal.de From rjones at redhat.com Wed Jul 23 08:28:39 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 23 Jul 2008 09:28:39 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: <20080723082839.GB668@amd.home.annexia.org> On Tue, Jul 22, 2008 at 08:44:22PM +0100, Tim Jackson wrote: > Please may we have an additional option "None"? > > I cannot see any useful purpose for this other than to make > non-technical or new users wonder why we have two names for one piece of > software, one of which nobody uses and doesn't appear to bear any > resemblance to anything other than some bad, cliquey in-joke. > > Fortunately we don't use it *quite* as prominently as some other Linux > distributions (why on earth would I want to admit to someone that I use > an operating system called "potato"?) but these names still make me cringe. ... and while we're at it, can we please get rid of the "cute" names for ordinary software? I was trying to blow away unused packages yesterday and was wondering what on earth "libpurple" (48MB) "gutenprint-foomatic" (49MB) "poppler" (14MB) etc do. ..... and while I'm grumbling, at least "libgweather" has a useful name. But why on earth is it almost 50MB in size?? And there are three copies of it installed on my machine? 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 yersinia.spiros at gmail.com Wed Jul 23 08:39:27 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 23 Jul 2008 10:39:27 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <4886E123.4020407@hhs.nl> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> Message-ID: I am not think the debian borg are crazy because they have svn-buildpackage, cvs-buildpackage, git-buildpackage from years( http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html). Doesn't exists a rpm equivalent - or better an rpmbuild integration with vcs - only because of rpm fragmentation and, i think, because every other distro want a competive advantage in using the their "buildsystem". But, in 2008, it is time to gave to all the rpm packager an unified vcs integration with RPM JMHO, YMMV On Wed, Jul 23, 2008 at 9:43 AM, Hans de Goede wrote: > Doug Ledford wrote: > >> I've been working on getting this set up and functional. >> > > > > So Far I've been quiet on this, sort of hoping it would go away by itself, > but as a contributor with quite a few packages let me say that I'm deeply > worried about this whole distributed VCS / exploded source idea floating > around. > > It seems there are a few people who are a big fan of this, and about as > much active opponents. I have no problems with adding the possibility to use > a distributed VCS with exploded trees to the mix of ways to maintain and > build packages, but this should not replace the current nice and simple > setup we have. > > First of all it does NOT match the way rpm was designed at all, rpm is > about pristine sources with _separate_ patches, but most importantly, this > is rather complicated making things unnecessary hard for people who don't > want to do the stuff some of the distributed VCS proponents want to do. This > worries me, I'm esp. worried that the barrier of entry to becoming a Fedora > packager will be raised significantly. > > Also I even fail to see the claimed advantages in using a distributed VCS > at all, isn't our mantra upstream upstream upstream, well if this mantra is > properly followed and upstream is undergoing active development then most of > the time the pristine sources should be fine without any patches at all, > since all patches are integrated upstream in a timely manner. Also if > someone wants to do so much work on the upstrewam sources, then he/she > should just become an upstream developer. Really getting upstream > cvs/svn/whatever access isn't that hard, then one can directly commit one's > changes in to upstreams VCS. > > Regards, > > Hans > > -- > 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 nicolas.mailhot at laposte.net Wed Jul 23 09:02:16 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 23 Jul 2008 11:02:16 +0200 (CEST) Subject: Anaconda: loss fonts In-Reply-To: <4886EC8E.4000009@nigelj.com> References: <4886EC8E.4000009@nigelj.com> Message-ID: <8926.192.54.193.58.1216803736.squirrel@rousalka.dyndns.org> Le Mer 23 juillet 2008 10:32, Nigel Jones a ?crit : > Do you have fontconfig? > > In my rawhide kickstart I added: > > fontconfig > xorg-x11-fonts-100dpi > xorg-x11-fonts-ISO8859-1-100dpi Waste of space on constrained media. > liberation-fonts > dejavu-fonts If you need those that means you've forgotten to add the fonts group to your ks. That's the official group i18n checks for every release. > I think fontconfig was the missing one I'm surprised GTK does not require fontconfig directly or indirectly > and the others were just to > entertain me, that said, the xorg-x11-fonts packages would be > recommended, and also fonts-ISO8859-2 imo. Please don't. That's legacy most users do not need. -- Nicolas Mailhot From dev at nigelj.com Wed Jul 23 09:23:34 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 23 Jul 2008 21:23:34 +1200 Subject: Anaconda: loss fonts In-Reply-To: <8926.192.54.193.58.1216803736.squirrel@rousalka.dyndns.org> References: <4886EC8E.4000009@nigelj.com> <8926.192.54.193.58.1216803736.squirrel@rousalka.dyndns.org> Message-ID: <4886F896.6050700@nigelj.com> Nicolas Mailhot wrote: > Le Mer 23 juillet 2008 10:32, Nigel Jones a ?crit : > > >> Do you have fontconfig? >> >> In my rawhide kickstart I added: >> >> fontconfig >> > > >> xorg-x11-fonts-100dpi >> xorg-x11-fonts-ISO8859-1-100dpi >> > > Waste of space on constrained media. > > >> liberation-fonts >> dejavu-fonts >> > > If you need those that means you've forgotten to add the fonts group > to your ks. That's the official group i18n checks for every release. > I had not 'forgotten' I'd purposely moth-balled it. > >> I think fontconfig was the missing one >> > > I'm surprised GTK does not require fontconfig directly or indirectly > > >> and the others were just to >> entertain me, that said, the xorg-x11-fonts packages would be >> recommended, and also fonts-ISO8859-2 imo. >> > > Please don't. That's legacy most users do not need. > I'm only stating what I added (at my own choice) to my kickstart that worked. - Nigel From mschwendt at gmail.com Wed Jul 23 09:32:40 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 23 Jul 2008 11:32:40 +0200 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216792233.12190.68.camel@localhost.localdomain> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> Message-ID: <20080723113240.da7d593a.mschwendt@gmail.com> On Wed, 23 Jul 2008 01:50:33 -0400, Jesse Keating wrote: > Another thought I had was that instead of listing the owners of > packages, we could actually list the person whom built the offending > E:N-V-R breaker. This is likely more interesting information anyway Of course. The old script displayed the primary owner (an old notion from the Extras era), but also mailed all co-maintainers. In the summary that went to the list it would quickly get unreadable, so only one mail addr was shown. > since the owner can change per branch That could be specified in the pkgdb, though. And theoretically, the pkgdb could be queried for such branch-specific ownership data. From thomas.moschny at gmail.com Wed Jul 23 09:48:08 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Wed, 23 Jul 2008 11:48:08 +0200 Subject: Package names and sizes (was: Re: Cast your vote for the Fedora 10 Codename!) Message-ID: 2008/7/23 Richard W.M. Jones : > ..... and while I'm grumbling, at least "libgweather" has a useful > name. But why on earth is it almost 50MB in size?? And there are > three copies of it installed on my machine? While we are at it, what is the reason for the frysk (f9) package to have a size of 146,651,842 bytes? It installs 12 binaries to /usr/bin, each having 7.5MB. Seems they are not dynamically linked against the libfrysk* libs, is that intentional? Also, there are two "test-core" files of 21MB each, what are these needed for? (could they be moved to a separate package?) - Thomas From mspevack at redhat.com Wed Jul 23 09:58:04 2008 From: mspevack at redhat.com (Max Spevack) Date: Wed, 23 Jul 2008 11:58:04 +0200 (CEST) Subject: more information on FUDCon Brno 2008 Message-ID: Hi fedora-devel-list: I know this is a little bit off-topic, but I am trying to make sure that developers and package maintainers that we have in Europe have as much information about FUDCon as possible. The FUDCon wiki page has been updated, with a tentative schedule for each day, and also with a place for people who are traveling from out of town to indicate which nights they will need hotel rooms. https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008 Please continue to sign up if you will attend, and also to add possible hackfest or presentation topics. If you have any questions about FUDCon logistics or travel, please contact me. Thanks, Max From vnpenguin at vnoss.org Wed Jul 23 10:04:54 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 23 Jul 2008 12:04:54 +0200 Subject: Anaconda: loss fonts In-Reply-To: <4886EC8E.4000009@nigelj.com> References: <4886EC8E.4000009@nigelj.com> Message-ID: On Wed, Jul 23, 2008 at 10:32 AM, Nigel Jones wrote: > > Do you have fontconfig? Yes, I have it, > In my rawhide kickstart I added: > > fontconfig > xorg-x11-fonts-100dpi > xorg-x11-fonts-ISO8859-1-100dpi > fonts-ISO8859-2 > bitmap-fonts > libXfont > liberation-fonts > dejavu-fonts Just added them, and it works !!!! Cool :-) Thank you so much Cheers -- http://vnoss.org From mschwendt at gmail.com Wed Jul 23 10:14:09 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 23 Jul 2008 12:14:09 +0200 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: <20080723121409.46d92758.mschwendt@gmail.com> On Tue, 22 Jul 2008 20:44:22 +0100, Tim Jackson wrote: > Josh Boyer wrote: > > > We have several options for the Fedora 10 codename, and you get to help > > decide which we use! > > Please may we have an additional option "None"? Oh, I really enjoyed the release name "(null)". Probably the funniest one so far. In this election I used 0 points. So much effort to come up with a list of codenames. Even Legal had to spend time on this. Is it worth it? Nitrate, Saltpetre, Water : after Sulphur? Nah. Too similar to a chain like "New York -> Boston -> Washington -> Chicago -> Pittsburgh" or so. I know it won't become a chain like that, but it still looks like that. (Books about Ubuntu contain complete chapters on explaining their codenames as if that were important to know.) Terror : "Dynamite" would have fit here, too, it seems. "Terror" as a codename is really bad taste. Mississippi, Nile, Cambridge, Farnsworth : certainly ambiguity plays an important role here -- I don't want to research that -- but to the majority of users these will appear in their geographical context, and that is too unimaginative. Whiskey Run : the only one I entered in Google. The results were unconvincing and didn't invite me to want to "learn" more about this. -- Fedora release 10 (+1) From skvidal at fedoraproject.org Wed Jul 23 11:44:57 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Jul 2008 07:44:57 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <20080723082839.GB668@amd.home.annexia.org> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <20080723082839.GB668@amd.home.annexia.org> Message-ID: <1216813497.10981.9.camel@rosebud> On Wed, 2008-07-23 at 09:28 +0100, Richard W.M. Jones wrote: > ... and while we're at it, can we please get rid of the "cute" names > for ordinary software? I was trying to blow away unused packages > yesterday and was wondering what on earth "libpurple" (48MB) > "gutenprint-foomatic" (49MB) "poppler" (14MB) etc do. > > ..... and while I'm grumbling, at least "libgweather" has a useful > name. But why on earth is it almost 50MB in size?? And there are > three copies of it installed on my machine? > Yes, and let's take away chocolate and all varieties of pie. And maybe let's kick some kittens, people like those too much. -sv From lists at timj.co.uk Wed Jul 23 12:23:22 2008 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 23 Jul 2008 13:23:22 +0100 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216792233.12190.68.camel@localhost.localdomain> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> Message-ID: <488722BA.30509@timj.co.uk> Jesse Keating wrote: Firstly thanks for running the script. As I feared, a rather large number of problems, but that only means it was needed more rather than less :-) > That said, it might also be worth doing this in two runs. One that > takes the view of F8, F8-updates, f9-updates and another than takes the > view of F8-updates-testing, F9-updates-testing. I think that would be sensible, because it makes it easier to see and prioritise the most important ones (that is, ones in the "normal user" upgrade path) rather than those which are important, but only affecting the subset of users that use testing and can probably handle instability/bad versioning better. > Another thought I had was that instead of listing the owners of > packages, we could actually list the person whom built the offending > E:N-V-R breaker. This is likely more interesting information anyway > since the owner can change per branch and the owner often isn't the > person doing the build anyway. Sounds sensible. Thanks again for working on this! Tim From stickster at gmail.com Wed Jul 23 12:35:43 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 23 Jul 2008 12:35:43 +0000 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <4886DC72.2080803@nicubunu.ro> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> <4886DC72.2080803@nicubunu.ro> Message-ID: <1216816543.11972.22.camel@victoria> On Wed, 2008-07-23 at 10:23 +0300, Nicu Buculei wrote: > Dave Airlie wrote: > > On Tue, 2008-07-22 at 21:40 -0500, Mike McGrath wrote: > >> I wonder if we'll ever get big enough that the art team could make a theme > >> for each proposed name and we could vote on that as part of the name > >> selection... it'd be wicked awesome :) > > > > I more wonder why the art team feels the need to use the nick-name of > > the distro as a basis for the artwork.. surely they are an independent > > minded bunch, and it would allows to just choose names that we like > > instead of ones with meaningful artwork.. > > Well, we really have not linked directly the name and the graphics so > far... it was an attempt in F9 but the graphic with Sulphur crystal was > dropped at the last minute. > > It was a thought that it may be cool if we can link the two and sometime > is useful to have a starting point when developing some graphics. And that method would have stood a better chance this time if it hadn't taken so long to get names vetted through Legal. We're cleaning up that process for the next release. I drafted something to use as a starting point: https://fedoraproject.org/wiki/Releases/Naming_Guidelines -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Wed Jul 23 12:40:36 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jul 2008 07:40:36 -0500 Subject: /usr/sbin/alternatives References: <4886ECDB.2030802@gmx.de> Message-ID: Robert M. Albrecht wrote: > can alternatives only change links or is it able to manipulate > config-files ? afaik, the former. -- Rex From nicu_fedora at nicubunu.ro Wed Jul 23 12:47:14 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 23 Jul 2008 15:47:14 +0300 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216816543.11972.22.camel@victoria> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> <4886DC72.2080803@nicubunu.ro> <1216816543.11972.22.camel@victoria> Message-ID: <48872852.4050803@nicubunu.ro> Paul W. Frields wrote: > On Wed, 2008-07-23 at 10:23 +0300, Nicu Buculei wrote: >> Well, we really have not linked directly the name and the graphics so >> far... it was an attempt in F9 but the graphic with Sulphur crystal was >> dropped at the last minute. >> >> It was a thought that it may be cool if we can link the two and sometime >> is useful to have a starting point when developing some graphics. > > And that method would have stood a better chance this time if it hadn't > taken so long to get names vetted through Legal. We're cleaning up that > process for the next release. I drafted something to use as a starting > point: > https://fedoraproject.org/wiki/Releases/Naming_Guidelines It is not a big deal, we can try to link them and get something crappy (pun intended, the "sulphur crystal" was taken down in F9 with one main concern about it looking like "dog poop"). So a link is not a guarantee of success. I think is fun enough to try to match theme proposals with name candidates after the fact, like "liberaProgramaro" seems to be about ghosts and fit the "terror" codename, "Cambridge" is old British just like "steampunk" and so on. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jkeating at redhat.com Wed Jul 23 12:48:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jul 2008 08:48:08 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <20080723113240.da7d593a.mschwendt@gmail.com> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> <20080723113240.da7d593a.mschwendt@gmail.com> Message-ID: <1216817288.12190.77.camel@localhost.localdomain> On Wed, 2008-07-23 at 11:32 +0200, Michael Schwendt wrote: > > since the owner can change per branch > > That could be specified in the pkgdb, though. And theoretically, the pkgdb > could be queried for such branch-specific ownership data. It is already, but I wonder if it's worth the effort. I already have the information about whom built the package, rather than who "owns" the package and that's the important thing I think. As for notification as I state in the source I'm really hoping that the -contact at fedoraproject.org or some such gets created soon so that the script can just email that + the person whom built the problematic package. That would make things sufficiently simple enough. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 skvidal at fedoraproject.org Wed Jul 23 12:47:31 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Jul 2008 08:47:31 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216817288.12190.77.camel@localhost.localdomain> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> <20080723113240.da7d593a.mschwendt@gmail.com> <1216817288.12190.77.camel@localhost.localdomain> Message-ID: <1216817251.10981.28.camel@rosebud> On Wed, 2008-07-23 at 08:48 -0400, Jesse Keating wrote: > On Wed, 2008-07-23 at 11:32 +0200, Michael Schwendt wrote: > > > since the owner can change per branch > > > > That could be specified in the pkgdb, though. And theoretically, the pkgdb > > could be queried for such branch-specific ownership data. > > It is already, but I wonder if it's worth the effort. I already have > the information about whom built the package, rather than who "owns" the > package and that's the important thing I think. > > As for notification as I state in the source I'm really hoping that the > -contact at fedoraproject.org or some such gets created soon so that > the script can just email that + the person whom built the problematic > package. That would make things sufficiently simple enough. > Toshio fixed up pkgdb so I can query the right information via script now. I'll get to the pkg-owner at fp.o address stuff this week. -sv From yersinia.spiros at gmail.com Wed Jul 23 12:58:37 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 23 Jul 2008 14:58:37 +0200 Subject: /usr/sbin/alternatives In-Reply-To: References: <4886ECDB.2030802@gmx.de> Message-ID: The former. For the configuration facility you have to look to: - puppet - func - manual script or configuration rpm if you are inclined Regards On Wed, Jul 23, 2008 at 2:40 PM, Rex Dieter wrote: > Robert M. Albrecht wrote: > > > can alternatives only change links or is it able to manipulate > > config-files ? > > afaik, the former. > > -- Rex > > -- > 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 buc at odusz.so-cdu.ru Wed Jul 23 13:08:39 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 23 Jul 2008 17:08:39 +0400 Subject: Packaging nss-ldapd for fedora In-Reply-To: <20080720161141.GH3771@edu.joroinen.fi> References: <20080720161141.GH3771@edu.joroinen.fi> Message-ID: <48872D57.2090300@odu.neva.ru> Pasi K?rkk?inen wrote: > Hello! > > Anyone planning to upload/maintain nss-ldapd to fedora? > > Seems like a better solution than nss-ldap.. > > http://ch.twi.tudelft.nl/~arthur/nss-ldapd/ > This soft seems to be related to "production environments", hence there are more chances for a reply in some CentOS-related maillists etc. As you see, no real interest in Fedora, for now... (Maybe a time of vacations?). ~buc From bkearney at redhat.com Wed Jul 23 13:46:11 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 23 Jul 2008 09:46:11 -0400 Subject: Fedora, OLPC, and Sugar Labs In-Reply-To: <604aa7910807150855k6296b66am8f9c8a7c4c3e90a7@mail.gmail.com> References: <1215999441.29945.430.camel@dfarning.desktop.org> <604aa7910807141127t9916bas3c045794853a1742@mail.gmail.com> <1216074433.7931.99.camel@dfarning.desktop.org> <16de708d0807150843s61c2c853o27326d55e69ebaa2@mail.gmail.com> <604aa7910807150855k6296b66am8f9c8a7c4c3e90a7@mail.gmail.com> Message-ID: <48873623.60300@redhat.com> Jeff Spaleta wrote: > On Tue, Jul 15, 2008 at 7:50 AM, Camilo Mesias wrote: >> Surely publishing an image for VMWare (ie. a virtual appliance) would >> be the quickest way to let people try out the software (and get >> started with developing it?) > > As a project we have so far not directly sponsored the creation of any > Fedora images..for any purpose. People make them, but at the project > level we do not provide anything that could be considered pre-cooked > for vmware. I have a first cut at a kickstart file for an f9 Sugar appliance using the thincrust appliance creator [1]). I am having some issues with it, are they best directed at this mailing list [2] ? [1] http://www.thincrust.net/tooling.html [2] http://lists.laptop.org/listinfo/sugar -- bk From P at draigBrady.com Wed Jul 23 13:52:31 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 23 Jul 2008 14:52:31 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48863896.8090407@timj.co.uk> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> Message-ID: <4887379F.1090405@draigBrady.com> Tim Jackson wrote: > Josh Boyer wrote: > >> We have several options for the Fedora 10 codename, and you get to help >> decide which we use! > > Please may we have an additional option "None"? Is "Neon" not close enough? P?draig. From bnocera at redhat.com Wed Jul 23 14:07:18 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 23 Jul 2008 15:07:18 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <20080723082839.GB668@amd.home.annexia.org> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <20080723082839.GB668@amd.home.annexia.org> Message-ID: <1216822038.3080.413.camel@cookie.hadess.net> On Wed, 2008-07-23 at 09:28 +0100, Richard W.M. Jones wrote: > ..... and while I'm grumbling, at least "libgweather" has a useful > name. But why on earth is it almost 50MB in size?? Because it has translations for all those foreign people. Did you try to see what was in the files contained in the package? > And there are > three copies of it installed on my machine? Because something/someone screwed up? RPM has the habit of doing that, but it's actually unlikely to amount to any more disk space being used (check the output of "rpm -V" for the older versions). From mclasen at redhat.com Wed Jul 23 14:07:55 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 23 Jul 2008 10:07:55 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <20080723082839.GB668@amd.home.annexia.org> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <20080723082839.GB668@amd.home.annexia.org> Message-ID: <1216822075.3500.1.camel@localhost.localdomain> On Wed, 2008-07-23 at 09:28 +0100, Richard W.M. Jones wrote: > On Tue, Jul 22, 2008 at 08:44:22PM +0100, Tim Jackson wrote: > > Please may we have an additional option "None"? > > > > I cannot see any useful purpose for this other than to make > > non-technical or new users wonder why we have two names for one piece of > > software, one of which nobody uses and doesn't appear to bear any > > resemblance to anything other than some bad, cliquey in-joke. > > > > Fortunately we don't use it *quite* as prominently as some other Linux > > distributions (why on earth would I want to admit to someone that I use > > an operating system called "potato"?) but these names still make me cringe. > > ... and while we're at it, can we please get rid of the "cute" names > for ordinary software? I was trying to blow away unused packages > yesterday and was wondering what on earth "libpurple" (48MB) > "gutenprint-foomatic" (49MB) "poppler" (14MB) etc do. > > ..... and while I'm grumbling, at least "libgweather" has a useful > name. But why on earth is it almost 50MB in size?? And there are > three copies of it installed on my machine? > Sneaky way to change the subject of this thread. To answer your question: libgweather contains a translated location database. That takes up 95% of the package size. From notting at redhat.com Wed Jul 23 13:07:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2008 09:07:26 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <20080723082839.GB668@amd.home.annexia.org> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <20080723082839.GB668@amd.home.annexia.org> Message-ID: <20080723130726.GB13210@nostromo.devel.redhat.com> Richard W.M. Jones (rjones at redhat.com) said: > ..... and while I'm grumbling, at least "libgweather" has a useful > name. But why on earth is it almost 50MB in size?? It consists of local information (weather station, latitude, longitude, etc.) for many cities, and contains translations into 20+ languages for all of them. It's just a lot of data. > And there are three copies of it installed on my machine? That would be a bug. Bill From notting at redhat.com Wed Jul 23 13:10:41 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2008 09:10:41 -0400 Subject: /usr/sbin/alternatives In-Reply-To: <4886ECDB.2030802@gmx.de> References: <4886ECDB.2030802@gmx.de> Message-ID: <20080723131041.GD13210@nostromo.devel.redhat.com> Robert M. Albrecht (romal at gmx.de) said: > can alternatives only change links or is it able to manipulate > config-files ? It does not handle the editing of configuration files. Bill From jreiser at BitWagon.com Wed Jul 23 14:37:29 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 23 Jul 2008 07:37:29 -0700 Subject: Anaconda: loss fonts In-Reply-To: <4886EC8E.4000009@nigelj.com> References: <4886EC8E.4000009@nigelj.com> Message-ID: <48874229.2060108@BitWagon.com> >> By using pungi on FC9-i386 (with all updates) I can make 1 >> installation CD which is bootable. But in Anaconda I loss all fonts. Here's a related problem regarding loss of fonts in the graphical installer: Summary: button labels fail if language support is a subset http://bugzilla.redhat.com/show_bug.cgi?id=445291 -- From jkeating at redhat.com Wed Jul 23 14:38:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jul 2008 10:38:54 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216817251.10981.28.camel@rosebud> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> <20080723113240.da7d593a.mschwendt@gmail.com> <1216817288.12190.77.camel@localhost.localdomain> <1216817251.10981.28.camel@rosebud> Message-ID: <1216823934.12190.85.camel@localhost.localdomain> On Wed, 2008-07-23 at 08:47 -0400, seth vidal wrote: > > Toshio fixed up pkgdb so I can query the right information via script > now. I'll get to the pkg-owner at fp.o address stuff this week. Rock on Seth, thanks! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 alan at redhat.com Wed Jul 23 14:47:19 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 23 Jul 2008 10:47:19 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <20080723082839.GB668@amd.home.annexia.org> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <20080723082839.GB668@amd.home.annexia.org> Message-ID: <20080723144719.GA5395@devserv.devel.redhat.com> On Wed, Jul 23, 2008 at 09:28:39AM +0100, Richard W.M. Jones wrote: > ... and while we're at it, can we please get rid of the "cute" names > for ordinary software? I was trying to blow away unused packages > yesterday and was wondering what on earth "libpurple" (48MB) > "gutenprint-foomatic" (49MB) "poppler" (14MB) etc do. gutenprint is a sensible name, if you get the references... For the rest rpm -qi From dominik at greysector.net Wed Jul 23 14:51:44 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 23 Jul 2008 16:51:44 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <4886E123.4020407@hhs.nl> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> Message-ID: <20080723145144.GC22996@mokona.greysector.net> On Wednesday, 23 July 2008 at 09:43, Hans de Goede wrote: > Doug Ledford wrote: > >I've been working on getting this set up and functional. > > > > So Far I've been quiet on this, sort of hoping it would go away by itself, > but as a contributor with quite a few packages let me say that I'm deeply > worried about this whole distributed VCS / exploded source idea floating > around. > > It seems there are a few people who are a big fan of this, and about as > much active opponents. I have no problems with adding the possibility to > use a distributed VCS with exploded trees to the mix of ways to maintain > and build packages, but this should not replace the current nice and simple > setup we have. Seconded. I'm pretty happy with our current workflow and the only things I'm missing are "svn cp" and "svn mv". [...] > Also I even fail to see the claimed advantages in using a distributed VCS > at all, isn't our mantra upstream upstream upstream, well if this mantra is > properly followed and upstream is undergoing active development then most > of the time the pristine sources should be fine without any patches at all, > since all patches are integrated upstream in a timely manner. Also if > someone wants to do so much work on the upstrewam sources, then he/she > should just become an upstream developer. Really getting upstream > cvs/svn/whatever access isn't that hard, then one can directly commit one's > changes in to upstreams VCS. Apparently a couple of packages (grub, kernel, few others?) maintain a massive patch set over their respective upstream tarballs, so while this change might make life easier for them, it is not necessarily so for the rest of us. Make it an option, yes, but do not disturb the workflow of the majority for the benefit of the few. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Wed Jul 23 14:55:20 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 23 Jul 2008 16:55:20 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <4886E8EE.5050905@op5.se> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <4886E8EE.5050905@op5.se> Message-ID: <20080723145520.GD22996@mokona.greysector.net> On Wednesday, 23 July 2008 at 10:16, Andreas Ericsson wrote: > Hans de Goede wrote: > >Doug Ledford wrote: > >>I've been working on getting this set up and functional. > > > > [...] > >It seems there are a few people who are a big fan of this, and about as > >much active opponents. I have no problems with adding the possibility to > >use a distributed VCS with exploded trees to the mix of ways to maintain > >and build packages, but this should not replace the current nice and > >simple setup we have. > > > > Noone has proposed replacing the existing setup, so the rest of your > email can safely be delegated to /dev/null. Let me provide the missing quote then: > >>First, we have to do away with a bunch of our make targets because they > >>are too commonly named and might conflict with legitimate upstream make > >>targets (well, more like some of them might conflict, some of them > >>*definitely* conflict). This is important because our Makefile.common > >>is included in upstream's toplevel Makefile. If that doesn't touch our existing setup then fine, but I'm afraid Doug really meant what he wrote. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dledford at redhat.com Wed Jul 23 14:58:13 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 23 Jul 2008 10:58:13 -0400 Subject: RFC: Exploded source repo layouts In-Reply-To: <20080723145520.GD22996@mokona.greysector.net> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <4886E8EE.5050905@op5.se> <20080723145520.GD22996@mokona.greysector.net> Message-ID: <1216825093.31637.9.camel@firewall.xsintricity.com> On Wed, 2008-07-23 at 16:55 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 23 July 2008 at 10:16, Andreas Ericsson wrote: > > Hans de Goede wrote: > > >Doug Ledford wrote: > > >>I've been working on getting this set up and functional. > > > > > > > [...] > > >It seems there are a few people who are a big fan of this, and about as > > >much active opponents. I have no problems with adding the possibility to > > >use a distributed VCS with exploded trees to the mix of ways to maintain > > >and build packages, but this should not replace the current nice and > > >simple setup we have. > > > > > > > Noone has proposed replacing the existing setup, so the rest of your > > email can safely be delegated to /dev/null. > > Let me provide the missing quote then: > > > >>First, we have to do away with a bunch of our make targets because they > > >>are too commonly named and might conflict with legitimate upstream make > > >>targets (well, more like some of them might conflict, some of them > > >>*definitely* conflict). This is important because our Makefile.common > > >>is included in upstream's toplevel Makefile. > > If that doesn't touch our existing setup then fine, but I'm afraid > Doug really meant what he wrote. Actually, no. For Makefile.dist-CVS, it is the same as it used to be. Same make targets, same functionality, same, same, same. It's Makefile.repo-git that gets included in the exploded source's top level Makefile, and *that's* where you have new make targets and such. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dominik at greysector.net Wed Jul 23 15:06:15 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 23 Jul 2008 17:06:15 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <1216825093.31637.9.camel@firewall.xsintricity.com> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <4886E8EE.5050905@op5.se> <20080723145520.GD22996@mokona.greysector.net> <1216825093.31637.9.camel@firewall.xsintricity.com> Message-ID: <20080723150615.GE22996@mokona.greysector.net> On Wednesday, 23 July 2008 at 16:58, Doug Ledford wrote: > On Wed, 2008-07-23 at 16:55 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 23 July 2008 at 10:16, Andreas Ericsson wrote: > > > Hans de Goede wrote: > > > >Doug Ledford wrote: > > > >>I've been working on getting this set up and functional. > > > > > > > > > > [...] > > > >It seems there are a few people who are a big fan of this, and about as > > > >much active opponents. I have no problems with adding the possibility to > > > >use a distributed VCS with exploded trees to the mix of ways to maintain > > > >and build packages, but this should not replace the current nice and > > > >simple setup we have. > > > > > > > > > > Noone has proposed replacing the existing setup, so the rest of your > > > email can safely be delegated to /dev/null. > > > > Let me provide the missing quote then: > > > > > >>First, we have to do away with a bunch of our make targets because they > > > >>are too commonly named and might conflict with legitimate upstream make > > > >>targets (well, more like some of them might conflict, some of them > > > >>*definitely* conflict). This is important because our Makefile.common > > > >>is included in upstream's toplevel Makefile. > > > > If that doesn't touch our existing setup then fine, but I'm afraid > > Doug really meant what he wrote. > > Actually, no. For Makefile.dist-CVS, it is the same as it used to be. > Same make targets, same functionality, same, same, same. It's > Makefile.repo-git that gets included in the exploded source's top level > Makefile, and *that's* where you have new make targets and such. So... am I going to have to type make -f Makefile.dist-CVS targetfoo after this change? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dledford at redhat.com Wed Jul 23 15:22:14 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 23 Jul 2008 11:22:14 -0400 Subject: RFC: Exploded source repo layouts In-Reply-To: <20080723145144.GC22996@mokona.greysector.net> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <20080723145144.GC22996@mokona.greysector.net> Message-ID: <1216826534.31637.27.camel@firewall.xsintricity.com> On Wed, 2008-07-23 at 16:51 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 23 July 2008 at 09:43, Hans de Goede wrote: > > Doug Ledford wrote: > > >I've been working on getting this set up and functional. > > > > > > > > So Far I've been quiet on this, sort of hoping it would go away by itself, > > but as a contributor with quite a few packages let me say that I'm deeply > > worried about this whole distributed VCS / exploded source idea floating > > around. > > > > It seems there are a few people who are a big fan of this, and about as > > much active opponents. I have no problems with adding the possibility to > > use a distributed VCS with exploded trees to the mix of ways to maintain > > and build packages, but this should not replace the current nice and simple > > setup we have. > > Seconded. I'm pretty happy with our current workflow and the only things > I'm missing are "svn cp" and "svn mv". > > [...] > > Also I even fail to see the claimed advantages in using a distributed VCS > > at all, isn't our mantra upstream upstream upstream, well if this mantra is > > properly followed and upstream is undergoing active development then most > > of the time the pristine sources should be fine without any patches at all, > > since all patches are integrated upstream in a timely manner. Also if > > someone wants to do so much work on the upstrewam sources, then he/she > > should just become an upstream developer. Really getting upstream > > cvs/svn/whatever access isn't that hard, then one can directly commit one's > > changes in to upstreams VCS. > > Apparently a couple of packages (grub, kernel, few others?) maintain a massive > patch set over their respective upstream tarballs, so while this change might > make life easier for them, it is not necessarily so for the rest of us. Actually, no. A massive patch set is no easier to maintain in a dvcs than it is with patches. The problem is that with a massive patchset, you get conflicts on update. This happens whether the patches are applied in an rpm, or by the dvcs as part of an update process. > Make it an option, yes, but do not disturb the workflow of the majority > for the benefit of the few. I won't force anyone to anything. Of course, a number of the benefits I laid out in the rpm thread have nothing to do with packaging and have everything to do with things like look aside cache growth, source storage size, and limitations of Fedora's infrastructure. Those items, obviously, are of benefit to *all* packages, not just ones those with active developers handling the package. And in order for Fedora to even consider the idea of hosting source for spin makers, something like this would be a requirement. But, obviously, that would be disturbing the majority for the benefit of the few. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 dledford at redhat.com Wed Jul 23 15:26:58 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 23 Jul 2008 11:26:58 -0400 Subject: RFC: Exploded source repo layouts In-Reply-To: <20080723150615.GE22996@mokona.greysector.net> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <4886E8EE.5050905@op5.se> <20080723145520.GD22996@mokona.greysector.net> <1216825093.31637.9.camel@firewall.xsintricity.com> <20080723150615.GE22996@mokona.greysector.net> Message-ID: <1216826818.31637.32.camel@firewall.xsintricity.com> On Wed, 2008-07-23 at 17:06 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 23 July 2008 at 16:58, Doug Ledford wrote: > > On Wed, 2008-07-23 at 16:55 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > On Wednesday, 23 July 2008 at 10:16, Andreas Ericsson wrote: > > > > Hans de Goede wrote: > > > > >Doug Ledford wrote: > > > > >>I've been working on getting this set up and functional. > > > > > > > > > > > > > [...] > > > > >It seems there are a few people who are a big fan of this, and about as > > > > >much active opponents. I have no problems with adding the possibility to > > > > >use a distributed VCS with exploded trees to the mix of ways to maintain > > > > >and build packages, but this should not replace the current nice and > > > > >simple setup we have. > > > > > > > > > > > > > Noone has proposed replacing the existing setup, so the rest of your > > > > email can safely be delegated to /dev/null. > > > > > > Let me provide the missing quote then: > > > > > > > >>First, we have to do away with a bunch of our make targets because they > > > > >>are too commonly named and might conflict with legitimate upstream make > > > > >>targets (well, more like some of them might conflict, some of them > > > > >>*definitely* conflict). This is important because our Makefile.common > > > > >>is included in upstream's toplevel Makefile. > > > > > > If that doesn't touch our existing setup then fine, but I'm afraid > > > Doug really meant what he wrote. > > > > Actually, no. For Makefile.dist-CVS, it is the same as it used to be. > > Same make targets, same functionality, same, same, same. It's > > Makefile.repo-git that gets included in the exploded source's top level > > Makefile, and *that's* where you have new make targets and such. > > So... am I going to have to type > make -f Makefile.dist-CVS targetfoo > after this change? No, of course not. For those people using CVS, things will be totally transparent and they won't have to so much as read a single line of a README file. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 bleanhar at redhat.com Wed Jul 23 15:27:01 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 23 Jul 2008 11:27:01 -0400 Subject: [koji] Help debugging package build failure Message-ID: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> I'm fairly new to the koji build system and a package I've been scratch building started failing today. You can see the details here: http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 From the root.log the most interesting lines are: DEBUG backend.py:490: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' DEBUG util.py:272: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' DEBUG util.py:250: 0:publican-0.33-1.fc9.noarch DEBUG backend.py:490: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' DEBUG util.py:272: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' DEBUG util.py:250: Error: Missing Dependency: libakonadiprotocolinternals.so.0 is needed by package kdepimlibs What I can't understand is what is pulling in kdepimlibs. The spec file only states: BuildRequires: publican Requires: httpd Neither of those packages need kdepimlibs. --Brenton From skvidal at fedoraproject.org Wed Jul 23 15:30:29 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Jul 2008 11:30:29 -0400 Subject: [koji] Help debugging package build failure In-Reply-To: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> Message-ID: <1216827029.10981.33.camel@rosebud> On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: > I'm fairly new to the koji build system and a package I've been > scratch building started failing today. You can see the details here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 > > From the root.log the most interesting lines are: > > DEBUG backend.py:490: /usr/bin/yum --installroot > /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' > DEBUG util.py:272: Executing command: /usr/bin/yum --installroot > /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' > DEBUG util.py:250: 0:publican-0.33-1.fc9.noarch > DEBUG backend.py:490: /usr/bin/yum --installroot > /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' > DEBUG util.py:272: Executing command: /usr/bin/yum --installroot > /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' > DEBUG util.py:250: Error: Missing Dependency: > libakonadiprotocolinternals.so.0 is needed by package kdepimlibs > > What I can't understand is what is pulling in kdepimlibs. The spec > file only states: > > BuildRequires: publican > Requires: httpd > I would guess it is coming from publican's dep on yum deplist publican dependency: /usr/bin/xml2pot provider: kdesdk-utils.i386 -sv From bleanhar at redhat.com Wed Jul 23 15:53:59 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Wed, 23 Jul 2008 11:53:59 -0400 Subject: Help debugging package build failure In-Reply-To: <1216827029.10981.33.camel@rosebud> References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> <1216827029.10981.33.camel@rosebud> Message-ID: <20080723155359.GO31802@tumbolia-jboss-dev.usersys.redhat.com> +++ seth vidal [23/07/08 11:30 -0400]: >On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: >> I'm fairly new to the koji build system and a package I've been >> scratch building started failing today. You can see the details here: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 >> >> From the root.log the most interesting lines are: >> >> DEBUG backend.py:490: /usr/bin/yum --installroot >> /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' >> DEBUG util.py:272: Executing command: /usr/bin/yum --installroot >> /var/lib/mock/dist-f9-build-227923-40553/root/ resolvedep 'publican' >> DEBUG util.py:250: 0:publican-0.33-1.fc9.noarch >> DEBUG backend.py:490: /usr/bin/yum --installroot >> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >> DEBUG util.py:272: Executing command: /usr/bin/yum --installroot >> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >> DEBUG util.py:250: Error: Missing Dependency: >> libakonadiprotocolinternals.so.0 is needed by package kdepimlibs >> >> What I can't understand is what is pulling in kdepimlibs. The spec >> file only states: >> >> BuildRequires: publican >> Requires: httpd >> > >I would guess it is coming from publican's dep on > >yum deplist publican > dependency: /usr/bin/xml2pot > provider: kdesdk-utils.i386 > >-sv I don't understand how I can build the RPM locally then. My local build machine is running Fedora 9. publican-0.33-1.fc9.noarch kdesdk-utils-4.0.5-3.fc9.i386 [root at dhcp226-35 genome-docs]# rpm -qi kdepimlibs package kdepimlibs is not installed --Brenton > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list From rdieter at math.unl.edu Wed Jul 23 15:56:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jul 2008 10:56:14 -0500 Subject: [koji] Help debugging package build failure References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> <1216827029.10981.33.camel@rosebud> Message-ID: seth vidal wrote: > On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: >> I'm fairly new to the koji build system and a package I've been >> scratch building started failing today. You can see the details here: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 ... >> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >> DEBUG util.py:250: Error: Missing Dependency: >> libakonadiprotocolinternals.so.0 is needed by package kdepimlibs >> >> What I can't understand is what is pulling in kdepimlibs. The spec >> file only states: >> >> BuildRequires: publican >> Requires: httpd >> > > I would guess it is coming from publican's dep on > > yum deplist publican > dependency: /usr/bin/xml2pot > provider: kdesdk-utils.i386 See: http://www.redhat.com/archives/fedora-devel-list/2008-July/msg01152.html -- Rex From rdieter at math.unl.edu Wed Jul 23 16:07:56 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jul 2008 11:07:56 -0500 Subject: [koji] Help debugging package build failure References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> <1216827029.10981.33.camel@rosebud> Message-ID: Rex Dieter wrote: > seth vidal wrote: > >> On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: >>> I'm fairly new to the koji build system and a package I've been >>> scratch building started failing today. You can see the details here: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 > ... >>> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >>> DEBUG util.py:250: Error: Missing Dependency: >>> libakonadiprotocolinternals.so.0 is needed by package kdepimlibs >>> >>> What I can't understand is what is pulling in kdepimlibs. The spec >>> file only states: >>> >>> BuildRequires: publican >>> Requires: httpd >>> >> >> I would guess it is coming from publican's dep on >> >> yum deplist publican >> dependency: /usr/bin/xml2pot >> provider: kdesdk-utils.i386 > > See: > http://www.redhat.com/archives/fedora-devel-list/2008-July/msg01152.html And as a followup, looks like the stuff in kdesdk-utils that once didn't pull in any extra kde deps, now does (for some hopefully explainable and revertable reason). -- Rex From ewan at macmahon.me.uk Wed Jul 23 16:33:44 2008 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Wed, 23 Jul 2008 17:33:44 +0100 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> Message-ID: <20080723163344.GE6390@macmahon.me.uk> On Wed, Jul 23, 2008 at 12:45:05PM +1000, Dave Airlie wrote: > > I more wonder why the art team feels the need to use the nick-name of > the distro as a basis for the artwork.. surely they are an independent > minded bunch, and it would allows to just choose names that we like > instead of ones with meaningful artwork.. > > Notice I didn't see an type of X-rated stuff in Hardy Hardon, or > whatever Ubuntus last distro was called.. > Their default Gnome wallpaper is an abstract herron though, which is rather nice. Maybe we could get the F11 code name nailed down a bit further in advance and give the art team a target to work to. The theme still needn't /necessarily/ be codename related, but it would make it possible as an option. As an aside, I've heard Ubuntu be accused of many bad things, but I think this thread is the first time anyone's tried to pin 'putting off new users' on them. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jul 23 16:48:38 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 23 Jul 2008 12:48:38 -0400 Subject: Plan for tomorrows (20080724) FESCO meeting Message-ID: <1216831718.9462.4.camel@truman> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- Elect new chair -- all /topic FESCo-Meeting -- Decide time for FESCo meetings -- all /topic FESCo-Meeting -- sponsor nominations -- Jon Ciesla (limb) -- all /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/GlitchFreeAudio /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/LatencyPolicy /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/NodokaNotificationTheme /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/OpenChange /topic FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/SecurityAudit /topic FESCo-Meeting Feature Acceptance --https://fedoraproject.org/wiki/Features/BetterLIRCSupport /topic FESCo-Meeting Feature Acceptance --https://fedoraproject.org/wiki/Features/Artistic1Removal /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. There is no guarantee that we'll get to tomorrow, though, since the schedule is already fairly full. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Wed Jul 23 16:55:28 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 23 Jul 2008 10:55:28 -0600 Subject: source file audit - 2008-07-05 In-Reply-To: <4881DCB4.8070703@timj.co.uk> References: <20080705141930.5f42d27f@ohm.scrye.com> <4881DCB4.8070703@timj.co.uk> Message-ID: <20080723105528.26658ba0@ohm.scrye.com> On Sat, 19 Jul 2008 13:23:16 +0100 lists at timj.co.uk (Tim Jackson) wrote: > Kevin Fenzi wrote: > > > Here's attached another run of my sources/patches url checker. > > Thanks, this is a really useful tool. > Does it run against devel or some other branches? Or all? Just devel currently. I suppose it could be run against others. > > timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime > > I don't see the problem with this one. Doesn't seem to be a problem now... I downloaded that version from their site and it was bad when the script ran. I wonder if it was just somehow a bad download? > > timj:BADURL:rapidsvn-0.9.6.tar.gz:rapidsvn > > timj:BADURL:rpl_1.5.3.tar.gz:rpl > > Fixed, thanks. Excellent. Thank you. > Tim > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dledford at redhat.com Wed Jul 23 17:04:23 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 23 Jul 2008 13:04:23 -0400 Subject: RFC: Exploded source repo layouts In-Reply-To: <4886E123.4020407@hhs.nl> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> Message-ID: <1216832663.31637.91.camel@firewall.xsintricity.com> On Wed, 2008-07-23 at 09:43 +0200, Hans de Goede wrote: > Doug Ledford wrote: > > I've been working on getting this set up and functional. When you say things like: > and: > the current nice and simple setup we have. it really just points out a simple misconception. If you think our CVS setup is "simple", then you've never spent much time look at Makefile.common, and you've certainly never seen any of the magic goo Cristian Gafton setup in the CVS server to make it all happen the way it does. What I'm talking about here is really no more complicated than our CVS setup, it's simply based on a different set of rules. If I weren't discussing this out in the open, and instead just showed up with a little HowTo and a completed project, it certainly would not seem any more complex than our CVS setup. > So Far I've been quiet on this, sort of hoping it would go away by itself, but > as a contributor with quite a few packages let me say that I'm deeply worried > about this whole distributed VCS / exploded source idea floating around. > > It seems there are a few people who are a big fan of this, and about as much > active opponents. I have no problems with adding the possibility to use a > distributed VCS with exploded trees to the mix of ways to maintain and build > packages, but this should not replace the current nice and simple setup we have. > > First of all it does NOT match the way rpm was designed at all, rpm is about > pristine sources with _separate_ patches, but most importantly, this is rather > complicated making things unnecessary hard for people who don't want to do the > stuff some of the distributed VCS proponents want to do. This worries me, I'm > esp. worried that the barrier of entry to becoming a Fedora packager will be > raised significantly. > > Also I even fail to see the claimed advantages in using a distributed VCS at > all, isn't our mantra upstream upstream upstream, well if this mantra is > properly followed and upstream is undergoing active development then most of > the time the pristine sources should be fine without any patches at all, since > all patches are integrated upstream in a timely manner. Also if someone wants > to do so much work on the upstrewam sources, then he/she should just become an > upstream developer. Really getting upstream cvs/svn/whatever access isn't that > hard, then one can directly commit one's changes in to upstreams VCS. As far as the rest of your email goes Hans, I won't do what you hope for. I won't drop the issue without finding out whether I'm right or wrong that an exploded source repo carries with it significant benefits in terms of work flow, collaboration with upstream, source hosting and management, etc. If I'm wrong, then you have nothing to be afraid of anyway as the whole idea will die away, and if I'm right, then it deserves to be a supported method of doing things. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 pertusus at free.fr Wed Jul 23 17:04:58 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 23 Jul 2008 19:04:58 +0200 Subject: source file audit - 2008-07-05 In-Reply-To: <20080723105528.26658ba0@ohm.scrye.com> References: <20080705141930.5f42d27f@ohm.scrye.com> <4881DCB4.8070703@timj.co.uk> <20080723105528.26658ba0@ohm.scrye.com> Message-ID: <20080723170458.GE7387@free.fr> On Wed, Jul 23, 2008 at 10:55:28AM -0600, Kevin Fenzi wrote: > > Just devel currently. > I suppose it could be run against others. There would certainly be some false positive in that case. For example debian patches disappear rapidly while they don't necessarily need to be updated in old branches. This doesn't mean that this shouldn't be done, though, but it is likely to be less relevant than for devel. -- Pat From dwmw2 at infradead.org Wed Jul 23 17:08:55 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Jul 2008 13:08:55 -0400 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <4884B103.2060600@mlbassoc.com> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> <4884B103.2060600@mlbassoc.com> Message-ID: <1216832935.3019.106.camel@shinybook.infradead.org> On Mon, 2008-07-21 at 09:53 -0600, Gary Thomas wrote: > Has this work/discussion progressed at all? I'm interested in cross > tools (x86->ppc) and would > like to get involved in making these happen. > > Any pointers on how I can get started (where/how to pick up the current > work, etc)? The binutils thing is fairly simple; the hard part is the compiler -- because to build libgcc_shared.so you need to have a glibc to link it against. Building cross-compilers has always been horrid because of this. I was thinking of trying to get a package to build by using a _dummy_ glibc -- it doesn't have to be runnable; we only have to be able to _link_ against it. So any DSO which has the handful of symbols that libgcc_shared uses would probably do the trick. Other people have taken other approaches, like repackaging the target glibc into a noarch package and requiring that for the cross-compiler. Or maybe we should build the cross-toolchain _without_ shared libgcc support, then build the shared libgcc in a separate package. It's kind of an open question. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From lordmorgul at gmail.com Wed Jul 23 17:41:05 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jul 2008 10:41:05 -0700 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216792562.12190.73.camel@localhost.localdomain> References: <1216730300.12864.29.camel@weaponx> <1dedbbfc0807221322la8238e0u704a5a0896ff5f14@mail.gmail.com> <48865175.6090801@timj.co.uk> <200807222247.53886.jamatos@fc.up.pt> <48866723.7090608@timj.co.uk> <1216792562.12190.73.camel@localhost.localdomain> Message-ID: <48876D31.9030705@gmail.com> Jesse Keating wrote: > On Wed, 2008-07-23 at 00:02 +0100, Tim Jackson wrote: >> Nothing at all; each to their own. But it wouldn't be the first time I've >> had to explain to a new user who is already dubious about Fedora and >> suspicious that this Linux thing is some sort of cryptic geeky nonsense >> why there is a weird obscure name used interchangeably with the more >> recognisable and user-understandable one. The name by which you distribute >> a piece of software may be completely unrelated to its merits from the >> point of view of you or I, but it *is* on the front line of users' >> awareness of it, and I'd rather Fedora had a reputation for welcoming and >> encouraging new users, not confusing them :-) > > Right, because "Windows ME", "Windows 98", "Windows 2000", "Windows XP", > "Windows Vista" are instantly understandable and not cryptic at all. Or > if you prefer "Leapord", "Panther", etc... Particularly when Windows Vista was known to the world as 'Longhorn' for more than 3 years before the term 'Vista' ever showed up. I'm not aware of any 'popular' operating system that has no codenaming process at all... I'd be interested in knowing about it. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From rdieter at math.unl.edu Wed Jul 23 17:44:43 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jul 2008 12:44:43 -0500 Subject: [koji] Help debugging package build failure References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> <1216827029.10981.33.camel@rosebud> Message-ID: Rex Dieter wrote: > Rex Dieter wrote: > >> seth vidal wrote: >> >>> On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: >>>> I'm fairly new to the koji build system and a package I've been >>>> scratch building started failing today. You can see the details here: >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 >> ... >>>> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >>>> DEBUG util.py:250: Error: Missing Dependency: >>>> libakonadiprotocolinternals.so.0 is needed by package kdepimlibs >>>> >>>> What I can't understand is what is pulling in kdepimlibs. The spec >>>> file only states: >>>> >>>> BuildRequires: publican >>>> Requires: httpd >>>> >>> >>> I would guess it is coming from publican's dep on >>> >>> yum deplist publican >>> dependency: /usr/bin/xml2pot >>> provider: kdesdk-utils.i386 >> >> See: >> http://www.redhat.com/archives/fedora-devel-list/2008-July/msg01152.html > > And as a followup, looks like the stuff in kdesdk-utils that once didn't > pull in any extra kde deps, now does (for some hopefully explainable and > revertable reason). wee (love responding to myself), found the dep issue too, will be fixed in kdesdk-utils-4.0.99-2 -- Rex From bruno at wolff.to Wed Jul 23 17:55:22 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 23 Jul 2008 12:55:22 -0500 Subject: consolidating on gnupg2 in F10 In-Reply-To: <200807211312.41243.sgrubb@redhat.com> References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> Message-ID: <20080723175522.GA5756@wolff.to> On Mon, Jul 21, 2008 at 13:12:40 -0400, Steve Grubb wrote: > > Why did you come to that conclusion? We don't support IDEA and Suse did > mention that they have switched to only GPG2. The only caution is around > gpg-agent. It's not too hard to provide that support. There is a source file you can grab compile and drop off in gpg's library directory. I don't know if gpg2 works the same way. Thinking about it I am surprised there isn't a Livna rpm providing the encryption plugin. From khc at pm.waw.pl Wed Jul 23 18:33:45 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Wed, 23 Jul 2008 20:33:45 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1216832935.3019.106.camel@shinybook.infradead.org> (David Woodhouse's message of "Wed\, 23 Jul 2008 13\:08\:55 -0400") References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> <4884B103.2060600@mlbassoc.com> <1216832935.3019.106.camel@shinybook.infradead.org> Message-ID: David Woodhouse writes: > Or maybe we should build the cross-toolchain _without_ shared libgcc > support, then build the shared libgcc in a separate package. It looks like a better approach for me. -- Krzysztof Halasa From dwmw2 at infradead.org Wed Jul 23 19:31:52 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 23 Jul 2008 15:31:52 -0400 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> <4884B103.2060600@mlbassoc.com> <1216832935.3019.106.camel@shinybook.infradead.org> Message-ID: <1216841512.3019.132.camel@shinybook.infradead.org> On Wed, 2008-07-23 at 20:33 +0200, Krzysztof Halasa wrote: > David Woodhouse writes: > > > Or maybe we should build the cross-toolchain _without_ shared libgcc > > support, then build the shared libgcc in a separate package. > > It looks like a better approach for me. It's certainly fine for me, because I don't actually care much about compiling userspace anyway -- if I can build kernels, that's perfectly sufficient for my purposes. But it would be nice if we could have a 'clean' dependency chain along the lines of: cross-gcc --> cross-glibc --> cross-libgcc.so -- dwmw2 From seg at haxxed.com Wed Jul 23 19:40:36 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 23 Jul 2008 14:40:36 -0500 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <4887379F.1090405@draigBrady.com> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <4887379F.1090405@draigBrady.com> Message-ID: <1216842036.4308.9.camel@localhost> On Wed, 2008-07-23 at 14:52 +0100, P?draig Brady wrote: > Tim Jackson wrote: > > Josh Boyer wrote: > > > >> We have several options for the Fedora 10 codename, and you get to help > >> decide which we use! > > > > Please may we have an additional option "None"? > > Is "Neon" not close enough? "Neon" apparently didn't make it through legal, despite being popular on the list. I'd like to know why. I have to say, I find the list of names this time around to be rather... uninteresting. Uninspiring. Is legal sucking the life out of the process? -------------- 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 jwilson at redhat.com Wed Jul 23 19:39:38 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jul 2008 15:39:38 -0400 Subject: heads up: new libraw1394 so, stuff needs rebuildin' In-Reply-To: <200807230029.07645.jwilson@redhat.com> References: <200807181659.33092.jwilson@redhat.com> <200807221647.43306.jwilson@redhat.com> <200807230029.07645.jwilson@redhat.com> Message-ID: <200807231539.38683.jwilson@redhat.com> On Wednesday 23 July 2008 12:29:07 am Jarod Wilson wrote: > On Tuesday 22 July 2008 04:47:43 pm Jarod Wilson wrote: > > On Friday 18 July 2008 05:31:30 pm Jarod Wilson wrote: > > > On Friday 18 July 2008 04:59:32 pm Jarod Wilson wrote: > > > > Coming Real Soon Now to rawhide is a build of the final libraw1394 > > > > 2.0.0, which includes a soname bump, which means a number of packages > > > > are going to need to be rebuild. A quick glance with repoquery > > > > suggests the list is limited to: > > > > > > > > unicap > > > > gstreamer-plugins-good > > > > coriander > > > > libfreebob > > > > pwlib > > > > kdebase > > > > kdebase3 > > > > dvgrab > > > > libiec61883 > > > > firecontrol > > > > libavc1394 [...] > So something went haywire with the chain build, but just the same, the new > libraw1394 somehow made it into the rawhide tree. I'm working on cleaning > up the mess now... Almost done with clean-up. unicap, coriander, kdebase, kdebase3, libiec61883, firecontrol and libavc1394 are all in the rawhide tree now. dvgrab and libfreebob got built today, gstreamer-plugins-good is building now, and pwlib was attempted but is failing to build at the moment, so I'm poking at it now... -- Jarod Wilson jwilson at redhat.com From jwboyer at gmail.com Tue Jul 22 12:38:20 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 22 Jul 2008 08:38:20 -0400 Subject: Cast your vote for the Fedora 10 Codename! Message-ID: <1216730300.12864.29.camel@weaponx> We have several options for the Fedora 10 codename, and you get to help decide which we use! https://admin.fedoraproject.org/voting/about/10 is the URL to cast your vote. Log in with your Fedora Account name and password. As long as you have signed the CLA and belong to one additional group in the Fedora Account System, you can cast your vote. Voting will end and be tallied at 23:59:59 28 July 2008 UTC. josh _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 23 20:10:28 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 23 Jul 2008 22:10:28 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1216841512.3019.132.camel@shinybook.infradead.org> (David Woodhouse's message of "Wed, 23 Jul 2008 15:31:52 -0400") References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> <4884B103.2060600@mlbassoc.com> <1216832935.3019.106.camel@shinybook.infradead.org> <1216841512.3019.132.camel@shinybook.infradead.org> Message-ID: <877ibcbbuz.fsf@sheridan.bigo.ensc.de> David Woodhouse writes: > But it would be nice if we could have a 'clean' dependency chain along > the lines of: > > cross-gcc --> cross-glibc --> cross-libgcc.so Not easy with current rpm: * assuming 'rpm' can extract PROVIDES/NEEDED out of cross built binaries, you will run into the problem that there are cross and native packages which are both providing the same 'libc.so.6'. When another native package requires 'libc.so.6', the cross package might get installed. RPM would have to annotate these provides/requires. I hacked around it by disabling automatic dependencies (--> no --file-requires anymore :( ) and using custom find-provides/requires scripts. It's very hacky but surprisingly it works since FC-5 till F-9... * you have to package cross-glibc as 'noarch' or as the native arch; it won't be possible to install a package of target arch (at least not without --ignore-arch). * 'BuildArch: noarch' does not create -debuginfo packages and that's very hardcoded into the rpm macros :( * some post-install scripts (...strip, ...debuginfo) use native binutils which fail on cross-built binaries. This is easy to workaround as recent rpm (FC-6+) allows to customize the %__strip and %__objdump tools When your ambitions stop at cross-libgcc, you can set manual 'Provides:' and 'Requires:'. Providing complete cross environments (e.g. for ARM where you can not/do not want built natively due to hardware restrictions), needs changes to rpm or lots of %macros. Enrico From stickster at gmail.com Wed Jul 23 21:13:42 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 23 Jul 2008 17:13:42 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216842036.4308.9.camel@localhost> References: <1216730300.12864.29.camel@weaponx> <48863896.8090407@timj.co.uk> <4887379F.1090405@draigBrady.com> <1216842036.4308.9.camel@localhost> Message-ID: <1216847622.11972.212.camel@victoria> On Wed, 2008-07-23 at 14:40 -0500, Callum Lerwick wrote: > On Wed, 2008-07-23 at 14:52 +0100, P?draig Brady wrote: > > Tim Jackson wrote: > > > Josh Boyer wrote: > > > > > >> We have several options for the Fedora 10 codename, and you get to help > > >> decide which we use! > > > > > > Please may we have an additional option "None"? > > > > Is "Neon" not close enough? > > "Neon" apparently didn't make it through legal, despite being popular on > the list. I'd like to know why. *koff koff* http://www.google.com/search?q=neon+software > I have to say, I find the list of names this time around to be rather... > uninteresting. Uninspiring. > > Is legal sucking the life out of the process? I think we can do better at the raw naming, frankly. Mea maxima culpa for "Neon" because I put forth that particular name. For the future, something to think about: https://fedoraproject.org/wiki/Releases/Naming_Guidelines -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Wed Jul 23 21:59:51 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 23 Jul 2008 22:59:51 +0100 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! Message-ID: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> Very cool news. I look forward to the SIG, the spin and seeing Fedora on even more cool devices :-) http://www.theregister.co.uk/2008/07/23/moblin_reworked/ Cheers, Peter From kevin.kofler at chello.at Wed Jul 23 22:38:32 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 23 Jul 2008 22:38:32 +0000 (UTC) Subject: consolidating on gnupg2 in F10 References: <20080715154726.GB24550@nostromo.devel.redhat.com> <200807211312.41243.sgrubb@redhat.com> <20080723175522.GA5756@wolff.to> Message-ID: Bruno Wolff III wolff.to> writes: > It's not too hard to provide that support. There is a source file you can > grab compile and drop off in gpg's library directory. I don't know if gpg2 > works the same way. Thinking about it I am surprised there isn't a Livna rpm > providing the encryption plugin. The whole reason they're talking about no longer being able to support IDEA as easily with GPG 2 is that GPG 2 no longer supports plugins, so you have to patch GPG 2 itself to add it. Kevin Kofler From gnomeuser at gmail.com Wed Jul 23 23:15:23 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Thu, 24 Jul 2008 01:15:23 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> Message-ID: <1dedbbfc0807231615n739565eav3b7bc1fca0212540@mail.gmail.com> 2008/7/23 Peter Robinson : > Very cool news. I look forward to the SIG, the spin and seeing Fedora > on even more cool devices :-) > > http://www.theregister.co.uk/2008/07/23/moblin_reworked/ > > Cheers, > Peter > Wow, unexpected but most welcome.. tell the world by digging: http://digg.com/linux_unix/Intel_s_Moblin_dumps_Ubuntu_in_favor_of_Fedora -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjohnstn at redhat.com Wed Jul 23 23:16:05 2008 From: jjohnstn at redhat.com (Jeff Johnston) Date: Wed, 23 Jul 2008 19:16:05 -0400 Subject: eclipse-pydev has been orphaned Message-ID: <4887BBB5.9090800@redhat.com> This is just to inform folks the eclipse-pydev package is orphaned as I don't have the time to properly maintain it. -- Jeff J. From dr.diesel at gmail.com Wed Jul 23 23:18:34 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 23 Jul 2008 19:18:34 -0400 Subject: NFS Mounted volumes drag moves instead of copy? Message-ID: <2a28d2ab0807231618h610f4203r93a2304f6908fe51@mail.gmail.com> Is this a bug, new behaviour if not? Server machine is F6, client is F9. When I drag a file from the server to client it moves the files instead of copying? If I move it back from the client to the server is copies instead of moving? I don't "think" this is the method used before, a bug or did I miss something some time ago? If new and way to change it back? Many thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From jspaleta at gmail.com Thu Jul 24 00:17:49 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 23 Jul 2008 16:17:49 -0800 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> Message-ID: <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> On Wed, Jul 23, 2008 at 1:59 PM, Peter Robinson wrote: > Very cool news. I look forward to the SIG, the spin and seeing Fedora > on even more cool devices :-) > > http://www.theregister.co.uk/2008/07/23/moblin_reworked/ Here's what's not clear.... is intel going to look to talk with us about making this part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name? Or are they planning to just leverage the existing Fedora distribution bits and do their own thing in a way that isn't aligned with existing Fedora contribution guidance? Have I missed a discussion concerning Moblin interaction with Fedora in the "project" sense? If I have please point me to it so I can read up. A number of questions spring to mind, chief among them whether the new Moblin can be incorporated under our secondary arch policy? How different is the Atom processor anyways? If they are serious about making this more attractive to developers, I think we need to have a serious discussion about whether or not the technical work they are doing can and should live under the Fedora project umbrella. Can/Should Moblin be the part of the Fedora project aimed at mobile devices? Sharing to some extent policy, best practices guidance, and contributor-base. Or should it sit outside our project completely? -jef From peter at thecodergeek.com Thu Jul 24 01:51:50 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 23 Jul 2008 18:51:50 -0700 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? Message-ID: <1216864310.3440.54.camel@tuxhugs> Hi, all. [I use X/Mesa stuff as an example only. Many other package updates contain similar problems, and the X/Mesa stuff certainly isn't one of the worst. Also, "notable changes" and similar phrasing in this message hereafter refer to any major bug fixes (such as those which resolve crashers or problems which cause loss of data), new enhancements (new features or changed subpackages), security fixes, and the like.)] Recently, there have been a slew of updates (especially X/Mesa related packages, though not exclusively) that have no helpful message in their update announcements. The last several %changelog entries are included, thankfully; but even those often fail to describe the update properly. I, for one, have not updated my system's mesa-related packages yet, because the new release (-37 versus -35) seems to cause rather severe performance issues. (FPS in Tremulous, for example, drops from a normal 45-55 to barely double-digit.) I can imagine a similar situation with dial-up users or users with limited bandwidth, such as with pay-per-use connections: Is the update useful enough to spend the time and/or money in downloading? The only notification in today's X updates, for example, is that it contains a new RC5 snapshot (and that's from the package %changelog). From the perspective of an end-user, I am thinking "What's changed? What's fixed? Any cool new features? Will the packages fix my DRI/OpenGL slowness?" Noting a new version or snapshot is a good thing, sure; but users should not need to go hunting through down upstream changelogs or bug trackers or to figure out why the package update is being issued. I'd like to propose a short policy of sorts to ensure that users are properly notified of notable changes. 1. Any such notable changes should be briefly described in the Bodhi entry. Essentially, package maintainers should summarize the key points of the upstream changelog for these. 2. Relevant bug numbers or IDs should always in the Bodhi entry, either for Red Hat/Fedora bugs (in Bodhi's "bugs" field), or as bug numbers from an unambiguous tracker (in the update comments). For example: "Fix GNOME Bug 98765" is good; but "Fix b.g.o#98765" is bad, since that could be (at least) bugs.gentoo.org, bugzilla.gnome.org, or even bugs.gobolinux.org, et al. Corollary: However, we don't want to be overly redundant in the notices. If we already include a bug number in Bodhi's "bugs" field, and that bug's title is descriptive enough, then it may very well be that simply referencing that bug in the update will tell users what's fixed - since Bodhi will automagically retrieve that and insert it into the announcement. For example, if your update through Bodhi shows "bug 123456: App crashes: segfault when enabling option foo," then it is not entirely necessary to note this fix in the update comments. Other changes should still be mentioned (if any). Similarly, if the %changelog includes a mention of these notable upstream changes, the update comments do not need to also include them (since the %changelog entry is also inserted as part of the update announcement). 3. Any and all attempted empty Bodhi updates with no bug references should return an error message, telling the maintainer to add a brief comment describing the change and/or referencing appropriate bugs (and perhaps referencing this policy). Simply being a new version is not always a good reason to update! On the contrary, new versions often bring new bugs and potential regressions - especially with snapshots of upstream sources instead of deemed-stable release tarballs. [Rawhide does not use Bodhi updates and is generally not intended to be as stable as releases, so merely noting the version bump is OK in the package %changelog, though I still recommend summarizing some of the more important notable package changes.] Thanks for your time! -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 Thu Jul 24 01:55:26 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 24 Jul 2008 07:25:26 +0530 Subject: Plan for tomorrows (20080724) FESCO meeting In-Reply-To: <1216831718.9462.4.camel@truman> References: <1216831718.9462.4.camel@truman> Message-ID: <4887E10E.3010604@fedoraproject.org> Brian Pepple wrote: > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. There is no guarantee that > we'll get to tomorrow, though, since the schedule is already fairly > full. You can also propose topics in the meeting while it is in the > "Free discussion around Fedora" phase. Probably make a decision on http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance Rahul From peter at thecodergeek.com Thu Jul 24 01:59:40 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 23 Jul 2008 18:59:40 -0700 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? In-Reply-To: <1216864310.3440.54.camel@tuxhugs> References: <1216864310.3440.54.camel@tuxhugs> Message-ID: <1216864780.3440.56.camel@tuxhugs> On Wed, 2008-07-23 at 18:51 -0700, Peter Gordon wrote: Noting a new version or snapshot is a good thing, sure; but users should > not need to go hunting through down upstream changelogs or bug trackers > or to figure out why the package update is being issued. Wow, that wording was horrible. Should read: "Noting a new version or snapshot is a good thing, sure; but users should not need to go hunting through upstream changelogs or bug trackers to figure out why the package update is being issued." Sorry for the confusion.. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 rc040203 at freenet.de Thu Jul 24 04:35:15 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jul 2008 06:35:15 +0200 Subject: RFC: Exploded source repo layouts In-Reply-To: <1216826534.31637.27.camel@firewall.xsintricity.com> References: <1216781671.5216.58.camel@firewall.xsintricity.com> <4886E123.4020407@hhs.nl> <20080723145144.GC22996@mokona.greysector.net> <1216826534.31637.27.camel@firewall.xsintricity.com> Message-ID: <1216874115.3042.104.camel@beck.corsepiu.local> On Wed, 2008-07-23 at 11:22 -0400, Doug Ledford wrote: > On Wed, 2008-07-23 at 16:51 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 23 July 2008 at 09:43, Hans de Goede wrote: > > > Doug Ledford wrote: > > > >I've been working on getting this set up and functional. > > > > > > > > > > > > So Far I've been quiet on this, sort of hoping it would go away by itself, > > > but as a contributor with quite a few packages let me say that I'm deeply > > > worried about this whole distributed VCS / exploded source idea floating > > > around. > > > > > > It seems there are a few people who are a big fan of this, and about as > > > much active opponents. I have no problems with adding the possibility to > > > use a distributed VCS with exploded trees to the mix of ways to maintain > > > and build packages, but this should not replace the current nice and simple > > > setup we have. > > > > Seconded. I'm pretty happy with our current workflow and the only things > > I'm missing are "svn cp" and "svn mv". Seconded. I feel this effort is trying to solve a non-issue. > Actually, no. A massive patch set is no easier to maintain in a dvcs > than it is with patches. ... equally, it's no easier to maintain with a dvcs. Ralf From martin.langhoff at gmail.com Thu Jul 24 05:15:37 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 24 Jul 2008 17:15:37 +1200 Subject: Kickstart partitioning stanzas - make optional? Message-ID: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> When anaconda sees partitioning configuration stanzas in the kickstart file, it takes them on unconditionally. Is there a way to give the user a chance to override them during installation? A search over the kickstart doco does not show any useful hints, and the GUI kickstart configurator doesn't offer any options that seem suitable. Perhaps there is a smart way to do this that I'm not aware of? How do liveCDs say "ah, if you let me, I'll autopartition it like this *whack!*, but if you want to do it yourself, here, have at parted my friend"? cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From vnpenguin at vnoss.org Thu Jul 24 06:23:16 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Thu, 24 Jul 2008 08:23:16 +0200 Subject: Pungi & firstboot Message-ID: Hi, By using pungi, I can make a installable CD. I have already firstboot package but the GUI firstboot does not start at all. I have only "Text Mode Setup Utility 1.19.4" so I can not add user, can not set SELinux option,... I have no gdm in my kickstart. Do I need it or another package for firstboot GUI ? Thanks, -- http://vnoss.org From steven.moix at axianet.ch Thu Jul 24 07:02:53 2008 From: steven.moix at axianet.ch (Steven Moix) Date: Thu, 24 Jul 2008 09:02:53 +0200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> Message-ID: <1216882973.2739.3.camel@hp6710.axianet.ch> If you remove the configuration options from your kickstart file, anaconda will stop and ask the user for input, isn't this what you want? Otherwise create 2 kickstart files on the DVD and chose which one you use depending on the situation, an easy way of doing that is to edit the isolinux/isolinux.cfg file on the DVD, with ISO Master for example. Steven On Thu, 2008-07-24 at 17:15 +1200, Martin Langhoff wrote: > When anaconda sees partitioning configuration stanzas in the kickstart > file, it takes them on unconditionally. Is there a way to give the > user a chance to override them during installation? From pmatilai at laiskiainen.org Thu Jul 24 07:09:42 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 24 Jul 2008 10:09:42 +0300 (EEST) Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <877ibcbbuz.fsf@sheridan.bigo.ensc.de> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> <4884B103.2060600@mlbassoc.com> <1216832935.3019.106.camel@shinybook.infradead.org> <1216841512.3019.132.camel@shinybook.infradead.org> <877ibcbbuz.fsf@sheridan.bigo.ensc.de> Message-ID: On Wed, 23 Jul 2008, Enrico Scholz wrote: > David Woodhouse writes: > >> But it would be nice if we could have a 'clean' dependency chain along >> the lines of: >> >> cross-gcc --> cross-glibc --> cross-libgcc.so > > Not easy with current rpm: > > * assuming 'rpm' can extract PROVIDES/NEEDED out of cross built binaries, > you will run into the problem that there are cross and native packages > which are both providing the same 'libc.so.6'. When another native > package requires 'libc.so.6', the cross package might get installed. > > RPM would have to annotate these provides/requires. There has been some discussion about adding the ISA name to all automatically extracted dependencies for disambiguation. For example where i386 and ppc currently produce 'libc.so.6' dependency names, it would become something like 'libc.so.6(x86-32)' vs 'libc.so.6(ppc-32)' The problem is, this would be a massive compatibility breakdown which would have to be dealt with somehow. > I hacked around it by disabling automatic dependencies (--> no > --file-requires anymore :( ) and using custom find-provides/requires > scripts. It's very hacky but surprisingly it works since FC-5 till > F-9... > > > * you have to package cross-glibc as 'noarch' or as the native arch; it > won't be possible to install a package of target arch (at least not > without --ignore-arch). One possibility that's also been (briefly) discussed at various points is turning the arch compatibility concept into dependencies, at which point an emulator package (such as qemu) could provide the things needed by cross-packages. But this too would have pretty big compatibility issues... - Panu - From yersinia.spiros at gmail.com Thu Jul 24 08:19:01 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 24 Jul 2008 10:19:01 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> Message-ID: For me it is interesting the reason " Dirk Hohndel, Intel's director of Linux and open-source strategy, told *The Reg* there was no falling out with Ubuntu, but the move to Fedora was a technical decision based *on the desire to adopt RPM for package management* . " On Thu, Jul 24, 2008 at 2:17 AM, Jeff Spaleta wrote: > On Wed, Jul 23, 2008 at 1:59 PM, Peter Robinson > wrote: > > Very cool news. I look forward to the SIG, the spin and seeing Fedora > > on even more cool devices :-) > > > > http://www.theregister.co.uk/2008/07/23/moblin_reworked/ > > Here's what's not clear.... is intel going to look to talk with us > about making this part of the larger Fedora project or is it going to > be a downstream derived distribution that will include components such > that it can not carry the Fedora name? Or are they planning to just > leverage the existing Fedora distribution bits and do their own thing > in a way that isn't aligned with existing Fedora contribution > guidance? Have I missed a discussion concerning Moblin interaction > with Fedora in the "project" sense? If I have please point me to it so > I can read up. > > A number of questions spring to mind, chief among them whether the new > Moblin can be incorporated under our secondary arch policy? How > different is the Atom processor anyways? If they are serious about > making this more attractive to developers, I think we need to have a > serious discussion about whether or not the technical work they are > doing can and should live under the Fedora project umbrella. > Can/Should Moblin be the part of the Fedora project aimed at mobile > devices? Sharing to some extent policy, best practices guidance, and > contributor-base. Or should it sit outside our project completely? > > -jef > > -- > 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 pbrobinson at gmail.com Thu Jul 24 08:20:36 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 24 Jul 2008 09:20:36 +0100 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> Message-ID: <5256d0b0807240120o45308dc9qa985caffbab811d@mail.gmail.com> >> Very cool news. I look forward to the SIG, the spin and seeing Fedora >> on even more cool devices :-) >> >> http://www.theregister.co.uk/2008/07/23/moblin_reworked/ > > Here's what's not clear.... is intel going to look to talk with us > about making this part of the larger Fedora project or is it going to > be a downstream derived distribution that will include components such > that it can not carry the Fedora name? Or are they planning to just > leverage the existing Fedora distribution bits and do their own thing > in a way that isn't aligned with existing Fedora contribution > guidance? Have I missed a discussion concerning Moblin interaction > with Fedora in the "project" sense? If I have please point me to it so > I can read up. No idea, would be cool if they contributed and there was a SIG and a MID Spin. > A number of questions spring to mind, chief among them whether the new > Moblin can be incorporated under our secondary arch policy? How > different is the Atom processor anyways? If they are serious about > making this more attractive to developers, I think we need to have a > serious discussion about whether or not the technical work they are > doing can and should live under the Fedora project umbrella. > Can/Should Moblin be the part of the Fedora project aimed at mobile > devices? Sharing to some extent policy, best practices guidance, and > contributor-base. Or should it sit outside our project completely? There's some pretty good details of the atom processor stuff at Tom's hardware. There's two strains, one which is in a lot of the NetBook devices and one for iPhone style devices. http://www.tomshardware.com/reviews/intel-atom-cpu,1947.html Peter From j.w.r.degoede at hhs.nl Thu Jul 24 08:35:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 Jul 2008 10:35:00 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> Message-ID: <48883EB4.7040100@hhs.nl> yersinia wrote: > For me it is interesting the reason > > " Dirk Hohndel, Intel's director of Linux and open-source strategy, told > /The Reg/ there was no falling out with Ubuntu, but the move to Fedora > was a technical decision based *on the desire to adopt RPM for package > management*. > " > I personally find the following reason much more interesting: 'He added: "The other thing we thought about was Moblin one wasn't successful in creating this community push - having a vibrant community push is the winning factor."' I think we (Jeff ?) should contact this guy explain we have a very vibrant community with plenty of interested contributers and that we would really like to see most (iow not any proprietary stuff) of the moblin work happening at the Fedora level, using the Fedora infra. So Jeff, your always good with words, do you feel like contacting Dirk Hohndel? Regards, Hans From yersinia.spiros at gmail.com Thu Jul 24 08:38:03 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 24 Jul 2008 10:38:03 +0200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: <1216882973.2739.3.camel@hp6710.axianet.ch> References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> <1216882973.2739.3.camel@hp6710.axianet.ch> Message-ID: In kickstart it is simple ask the user in %pre, generate the file stanza based on user request, and %include in kickstart the generate file stanza On Thu, Jul 24, 2008 at 9:02 AM, Steven Moix wrote: > If you remove the configuration options from your kickstart file, > anaconda will stop and ask the user for input, isn't this what you want? > > Otherwise create 2 kickstart files on the DVD and chose which one you > use depending on the situation, an easy way of doing that is to edit the > isolinux/isolinux.cfg file on the DVD, with ISO Master for example. > > Steven > > On Thu, 2008-07-24 at 17:15 +1200, Martin Langhoff wrote: > > When anaconda sees partitioning configuration stanzas in the kickstart > > file, it takes them on unconditionally. Is there a way to give the > > user a chance to override them during installation? > > -- > 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 nicolas.mailhot at laposte.net Thu Jul 24 08:45:29 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jul 2008 10:45:29 +0200 (CEST) Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <48883EB4.7040100@hhs.nl> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> Message-ID: <42036.192.54.193.59.1216889129.squirrel@rousalka.dyndns.org> Le Jeu 24 juillet 2008 10:35, Hans de Goede a ?crit : > I personally find the following reason much more interesting: > > 'He added: "The other thing we thought about was Moblin one wasn't > successful > in creating this community push - having a vibrant community push is > the winning factor."' Intel wants a developer community. Intel associates with a end-user oriented non-technical distribution. Developer community fails to materialize. How utterly un-surprising (also lots of frustrated Debianists wrote that it's because of his past as Suse, but surely if it was motivated by his past relations, he'd have chosen OpenSuse instead of Fedora?) -- Nicolas Mailhot From nphilipp at redhat.com Thu Jul 24 09:01:59 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 24 Jul 2008 11:01:59 +0200 Subject: NFS Mounted volumes drag moves instead of copy? In-Reply-To: <2a28d2ab0807231618h610f4203r93a2304f6908fe51@mail.gmail.com> References: <2a28d2ab0807231618h610f4203r93a2304f6908fe51@mail.gmail.com> Message-ID: <1216890119.2850.9.camel@wombat.tiptoe.de> On Wed, 2008-07-23 at 19:18 -0400, Dr. Diesel wrote: > Is this a bug, new behaviour if not? Server machine is F6, client is > F9. When I drag a file from the server to client it moves the files > instead of copying? If I move it back from the client to the server > is copies instead of moving? I don't "think" this is the method used > before, a bug or did I miss something some time ago? If new and way > to change it back? I don't have much insight into this, but you probably should open a Bugzilla about it. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mk at crc.dk Thu Jul 24 09:10:00 2008 From: mk at crc.dk (Mogens Kjaer) Date: Thu, 24 Jul 2008 11:10:00 +0200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> <1216882973.2739.3.camel@hp6710.axianet.ch> Message-ID: <488846E8.2070701@crc.dk> yersinia wrote: > In kickstart it is simple ask the user in %pre, generate the file stanza > based on user request, and %include in kickstart the generate file stanza How does one ask the user in %pre? Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From mschwendt at gmail.com Thu Jul 24 09:13:14 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 24 Jul 2008 09:13:14 -0000 Subject: Broken dependencies in Fedora 9 - 2008-07-24 Message-ID: <20080724091314.4230.52194@faldor.intranet> Summary of broken packages (by owner): Jochen AT herr-schmitt.de subcommander-1.2.3-2.fc9.i386 subcommander-1.2.3-2.fc9.ppc subcommander-1.2.3-2.fc9.ppc64 subcommander-1.2.3-2.fc9.x86_64 berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch dcbw AT redhat.com 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 ebmunson AT us.ibm.com libhugetlbfs-test-1.1-6.fc9.ppc libhugetlbfs-test-1.1-6.fc9.ppc64 libhugetlbfs-test-1.1-6.fc9.x86_64 lsvpd-1.6.4-1.fc9.i386 lsvpd-1.6.4-1.fc9.ppc lsvpd-1.6.4-1.fc9.ppc64 lsvpd-1.6.4-1.fc9.x86_64 karlthered AT gmail.com gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 katzj AT redhat.com livecd-tools-017.1-1.fc9.ppc64 kurzawax AT gmail.com dayplanner-0.9.1-1.fc9.noarch oliver AT linux-kernel.at syck-php-0.61-4.3.fc9.i386 syck-php-0.61-4.3.fc9.ppc syck-php-0.61-4.3.fc9.ppc64 syck-php-0.61-4.3.fc9.x86_64 orion AT cora.nwra.com paraview-3.2.1-6.fc9.i386 paraview-mpi-3.2.1-6.fc9.i386 rpm AT timj.co.uk rapidsvn-0.9.6-1.fc9.i386 rapidsvn-0.9.6-1.fc9.ppc rapidsvn-0.9.6-1.fc9.ppc64 rapidsvn-0.9.6-1.fc9.x86_64 wart AT kobold.org cyphesis-selinux-0.5.15-6.fc9.i386 cyphesis-selinux-0.5.15-6.fc9.ppc cyphesis-selinux-0.5.15-6.fc9.ppc64 cyphesis-selinux-0.5.15-6.fc9.x86_64 ====================================================================== Broken packages in fedora-9-i686: cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 rapidsvn-0.9.6-1.fc9.i386 requires libsvn_ra_dav-1.so.0 syck-php-0.61-4.3.fc9.i386 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc64: cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.ppc64 requires libhugetlbfs = 0:1.1-6.fc9 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 rapidsvn-0.9.6-1.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) syck-php-0.61-4.3.fc9.ppc64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc: cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.ppc requires libhugetlbfs = 0:1.1-6.fc9 rapidsvn-0.9.6-1.fc9.ppc requires libsvn_ra_dav-1.so.0 syck-php-0.61-4.3.fc9.ppc requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-x86_64: 1:NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 requires NetworkManager-glib = 1:0.7.0-0.9.3.svn3623.fc9 cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.x86_64 requires libhugetlbfs = 0:1.1-6.fc9 paraview-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 rapidsvn-0.9.6-1.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) syck-php-0.61-4.3.fc9.x86_64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-updates-9-i686: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.i386 requires libvpd_cxx-2.0.so.1 ====================================================================== Broken packages in fedora-updates-9-ppc64: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 livecd-tools-017.1-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc9.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) ====================================================================== Broken packages in fedora-updates-9-ppc: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.ppc requires libvpd_cxx-2.0.so.1 ====================================================================== Broken packages in fedora-updates-9-x86_64: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) ====================================================================== Broken packages in fedora-updates-testing-9-i686: dayplanner-0.9.1-1.fc9.noarch requires perl(DP::CoreModules) subcommander-1.2.3-2.fc9.i386 requires libsvn_ra_dav-1.so.0 ====================================================================== Broken packages in fedora-updates-testing-9-ppc64: dayplanner-0.9.1-1.fc9.noarch requires perl(DP::CoreModules) subcommander-1.2.3-2.fc9.ppc64 requires libsvn_ra_dav-1.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-testing-9-ppc: dayplanner-0.9.1-1.fc9.noarch requires perl(DP::CoreModules) subcommander-1.2.3-2.fc9.ppc requires libsvn_ra_dav-1.so.0 ====================================================================== Broken packages in fedora-updates-testing-9-x86_64: dayplanner-0.9.1-1.fc9.noarch requires perl(DP::CoreModules) subcommander-1.2.3-2.fc9.x86_64 requires libsvn_ra_dav-1.so.0()(64bit) From mschwendt at gmail.com Thu Jul 24 09:15:36 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 24 Jul 2008 09:15:36 -0000 Subject: Broken dependencies in Fedora 8 - 2008-07-24 Message-ID: <20080724091536.4235.50840@faldor.intranet> Summary of broken packages (by owner): berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch dcbw AT redhat.com 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 dchen AT redhat.com zhcon-0.2.6-9.fc8.i386 zhcon-0.2.6-9.fc8.ppc zhcon-0.2.6-9.fc8.ppc64 zhcon-0.2.6-9.fc8.x86_64 dev AT nigelj.com mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch ebmunson AT us.ibm.com libhugetlbfs-test-1.1-4.fc8.i386 libhugetlbfs-test-1.1-4.fc8.ppc libhugetlbfs-test-1.1-4.fc8.ppc64 libhugetlbfs-test-1.1-4.fc8.x86_64 ianweller AT gmail.com mediawiki-HNP-1.1.2-1.fc8.noarch mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch mediawiki-StubManager-1.2.0-1.fc8.noarch konrad AT tylerc.org joda-time-1.5.2-7.tzdata2008d.fc8.noarch oliver AT linux-kernel.at syck-php-0.61-2.fc8.i386 syck-php-0.61-2.fc8.ppc syck-php-0.61-2.fc8.ppc64 syck-php-0.61-2.fc8.x86_64 rmeggins AT redhat.com idm-console-framework-1.1.1-3.fc8.noarch ====================================================================== Broken packages in fedora-8-i686: libhugetlbfs-test-1.1-4.fc8.i386 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.i386 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc64: libhugetlbfs-test-1.1-4.fc8.ppc64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc: libhugetlbfs-test-1.1-4.fc8.ppc requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-x86_64: 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 requires NetworkManager-glib = 1:0.7.0-0.5.svn3030.fc8 libhugetlbfs-test-1.1-4.fc8.x86_64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.x86_64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-updates-8-ppc64: idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-7.tzdata2008d.fc8.noarch requires java > 0:1.5.0 mediawiki-HNP-1.1.2-1.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch requires mediawiki < 0:1.11 mediawiki-StubManager-1.2.0-1.fc8.noarch requires mediawiki >= 0:1.10 perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch requires darcs >= 0:1.0.0 ====================================================================== Broken packages in fedora-updates-8-ppc: idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-7.tzdata2008d.fc8.noarch requires java > 0:1.5.0 ====================================================================== Broken packages in fedora-updates-testing-8-i686: zhcon-0.2.6-9.fc8.i386 requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-ppc64: zhcon-0.2.6-9.fc8.ppc64 requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-ppc: zhcon-0.2.6-9.fc8.ppc requires ncurses-libs ====================================================================== Broken packages in fedora-updates-testing-8-x86_64: zhcon-0.2.6-9.fc8.x86_64 requires ncurses-libs From mk at crc.dk Thu Jul 24 09:17:35 2008 From: mk at crc.dk (Mogens Kjaer) Date: Thu, 24 Jul 2008 11:17:35 +0200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: <488846E8.2070701@crc.dk> References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> <1216882973.2739.3.camel@hp6710.axianet.ch> <488846E8.2070701@crc.dk> Message-ID: <488848AF.6090007@crc.dk> Mogens Kjaer wrote: ... > How does one ask the user in %pre? Sorry for asking, google had the answer: http://osdir.com/ml/linux.redhat.kickstart.general/2003-09/msg00053.html Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From paul at city-fan.org Thu Jul 24 09:19:11 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 24 Jul 2008 10:19:11 +0100 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> Message-ID: <4888490F.3070203@city-fan.org> Martin Langhoff wrote: > Hi, > > while building some packages for the OLPC XS I am seeing some odd > behaviour from Mock. I am not certain whether this is expected... > > 1 - The F9 host had httpd installed (unbeknownst to me) > 2 - The install script in the package was (wrongly) trying to do > install -o apache /file - which errored out "no such user" > 3 - Adding a BuildRequires to the spec file fixed the problem - mock > installed httpd in the chroot - however, install would still fail as > it was not running as root. > 4 - I spotted httpd on the host and removed it. I can no longer build > the package - "httpd is needed by ds-backup-x-y-z..." > > There are 2 weird things in here for me: > > - In step 4 - the host environment not having httpd should not affect > the build chroot. > > - In step 3, I was expecting the rpmbuild running the "install" target > inside mock to be using fakeroot or something similar. The fix for this is to remove (patch out) the "-o httpd" option from the install section of the Makefile (the chown won't work as a non-root user, and RPMs should always be built as non-root users), and instead use %attr in the spec file's %files section to indicate that the installed file should be owned by the "httpd" user. Check out the specs for most web apps in Fedora for examples. This method will mean that you don't need to buildrequire httpd too (though you will still need to require it as a runtime dependency so ensure that the httpd account exists on the target system). Paul. From yersinia.spiros at gmail.com Thu Jul 24 10:22:56 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 24 Jul 2008 12:22:56 +0200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: <488846E8.2070701@crc.dk> References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> <1216882973.2739.3.camel@hp6710.axianet.ch> <488846E8.2070701@crc.dk> Message-ID: Just a pratical example - i have used it with RHEL5 - , there are many document on this ********************************************************* ****** Begin kickstart ********************************************************* # Use CDROM installation media install cdrom reboot monitor --noprobe #platform=x86, AMD64, o Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr --driveorder=sda --md5pass=$1$LTpksksk$tgrE3JE2fXT/gqvVMUJwz1 # Clear the Master Boot Record zerombr # Partition clearing information clearpart --all --initlabel ...................... ...................... timezone --isUtc Europe/London # Network # %include /tmp/network.cfg *<----------------------------------------* # Disk Layout # %include /tmp/disk.cfg *<----------------------------------------* %packages --nobase @core dbus dbus-python dbus-glib hal httpd openldap-servers openldap-clients ........................ ........................ %pre --interp /usr/bin/ash PATH=/bin:/usr/bin:/sbin:/usr/sbin:$PATH echo_user () { echo >/dev/tty "$@" } ask () { echo_user echo_user -n "$1 [$2] ? " read res /dev/tty 2>&1 # re-do the prompt ask "$@" else echo "$res" fi } confirm () { res=$(ask "$1 (y/n)" "$2") case "$res" in [yYjJ]*) true ;; *) false ;; esac } cmdline_val () { Res=$(cat /proc/cmdline | sed -n 's/.*'"$1"'=\([^ ]*\).*/\1/p') if [ -z "$Res" ] then echo "$2" else echo "$Res" fi } die () { echo_user "FATAL: $*" exit 1 } gen_network() { echo -n "network --device $IFACE --bootproto static" [ ! -z "$IP" ] && echo -n " --ip $IP" [ ! -z "$MASK" ] && echo -n " --netmask $MASK" STTY_SAVE=$(stty -g /dev/tty || clear >/dev/tty echo_user "*****************************************" echo_user "*** EXAMPLE configuration kickstart ***" echo_user "*****************************************" echo_user " - Hope for the better ........... " echo_user " and enjoy " echo_user "*****************************************" echo_user Interactive="y" if [ "$Interactive" ] then while true do while [ -z "${NAME}" ] do echo_user cat </dev/tty ******************************************************* ** This is the list of valid hostname : please pick one ** The dns domain is example.com ******************************************************* example1 example2 EOF NAME=$(ask "Hostname (not fqdn qualified)" "$NAME") case "$NAME" in example1) cat </tmp/network.cfg network --device eth0 --noipv6 --bootproto static --ip x.y.z.h --netmask 255.255.255.128 --nameserver 127.0.0.1 --hostname EOF cat </tmp/disk.cfg clearpart --all --initlabel part /boot --fstype ext3 --size 128 part swap --size=1024 part pv.3 --size 0 --grow --ondisk=sda volgroup rootvg pv.3 logvol / --fstype ext3 --name=lv_root --vgname=rootvg --size=4096 logvol /home --fstype ext3 --name=lv_home --vgname=rootvg --size=1024 logvol /opt --fstype ext3 --name=lv_opt --vgname=rootvg --size=512 logvol /tmp --fstype ext3 --name=lv_tmp --vgname=rootvg --size=1024 logvol /var --fstype ext3 --name=lv_var --vgname=rootvg --size=1024 logvol /var/log --fstype ext3 --name=lv_var_log --vgname=rootvg --size=1024 logvol /var/tmp --fstype ext3 --name=lv_var_tmp --vgname=rootvg --size=1024 logvol /var/www --fstype ext3 --name=lv_var_www --vgname=rootvg --size=1024 logvol /var/log/audit --fstype ext3 --name=lv_audit --vgname=rootvg --size=1024 EOF ;; ......... ......... (for example2) *) clear >/dev/tty NAME="" ;; esac done echo_user echo_user "--------------------- WARNING -------------------------------" echo_user "This is your last chance to stop the installation. Continuing" echo_user "will erase the destination disk and install noninteractively." echo_user "Answer 'n' if you need to reedit your settings." else # noninteractive gen_network > /tmp/network.cfg fi # restore file descriptors and TTY clear >/dev/tty stty $STTY_SAVE : > yersinia wrote: > >> In kickstart it is simple ask the user in %pre, generate the file stanza >> based on user request, and %include in kickstart the generate file stanza >> > > How does one ask the user in %pre? > > Mogens > > -- > Mogens Kjaer, Carlsberg A/S, Computer Department > Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark > Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 > Email: mk at crc.dk Homepage: http://www.crc.dk > > -- > 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 dr.diesel at gmail.com Thu Jul 24 10:33:14 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 24 Jul 2008 05:33:14 -0500 Subject: NFS Mounted volumes drag moves instead of copy? In-Reply-To: <1216890119.2850.9.camel@wombat.tiptoe.de> References: <2a28d2ab0807231618h610f4203r93a2304f6908fe51@mail.gmail.com> <1216890119.2850.9.camel@wombat.tiptoe.de> Message-ID: <2a28d2ab0807240333g2074c23r7136d85c883cf9e1@mail.gmail.com> Done! https://bugzilla.redhat.com/show_bug.cgi?id=456515 On Thu, Jul 24, 2008 at 4:01 AM, Nils Philippsen wrote: > On Wed, 2008-07-23 at 19:18 -0400, Dr. Diesel wrote: >> Is this a bug, new behaviour if not? Server machine is F6, client is >> F9. When I drag a file from the server to client it moves the files >> instead of copying? If I move it back from the client to the server >> is copies instead of moving? I don't "think" this is the method used >> before, a bug or did I miss something some time ago? If new and way >> to change it back? > > I don't have much insight into this, but you probably should open a > Bugzilla about it. > > Nils > -- > Nils Philippsen / Red Hat / nphilipp at redhat.com > "Those who would give up Essential Liberty to purchase a little Temporary > Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From erik at vanpienbroek.nl Thu Jul 24 10:44:09 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Thu, 24 Jul 2008 12:44:09 +0200 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? In-Reply-To: <1216864310.3440.54.camel@tuxhugs> References: <1216864310.3440.54.camel@tuxhugs> Message-ID: <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> Op woensdag 23-07-2008 om 18:51 uur [tijdzone -0700], schreef Peter Gordon: > 1. Any such notable changes should be briefly described in the Bodhi > entry. Essentially, package maintainers should summarize the key points > of the upstream changelog for these. Hi, For the daily rawhide reports I think it is also interesting to have more verbose changelogs. But the issue is this tends to cause a lot of clutter. There are currently some packages which have a more verbose changelog (like gimp), but if all packages will do this, the daily rawhide reports won't get any easier to read. Maybe it is an idea to add a new rule to the packaging policy, something in the line of: "If your package update contains a new release from upstream, add a link to the full changelog of this new release in the %changelog field" In the long term, maybe an extra field in the YUM or RPM database could be used for such a thing, so that user-visible applications (bodhi, packagekit) can present this information in a more sane manner (like clickable links) Regards, Erik van Pienbroek From valent.turkovic at gmail.com Thu Jul 24 11:51:57 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 24 Jul 2008 13:51:57 +0200 Subject: Broken dependencies in Fedora 9 - 2008-07-19 In-Reply-To: <20080719110538.4437.86430@faldor.intranet> References: <20080719110538.4437.86430@faldor.intranet> Message-ID: <64b14b300807240451m2e918176lcfcf9891a61179e5@mail.gmail.com> I have these packages that I can't update: ---> Package yelp.i386 0:2.22.1-4.fc9 set to be updated ---> Package xulrunner.i386 0:1.9.0.1-1.fc9 set to be updated ---> Package epiphany.i386 0:2.22.2-3.fc9 set to be updated ---> Package epiphany-extensions.i386 0:2.22.1-3.fc9 set to be updated ---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated Because they depend on gecko-libs and Miro and gnome-python2-gtkmozembed packages are locking that update and stopping me from updating. I thought that xulrunner feature now in Fedora 9 is supposed to fix that, no? Cheers, Valent. -- 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 pingou at pingoured.fr Thu Jul 24 12:02:48 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Thu, 24 Jul 2008 14:02:48 +0200 Subject: Broken dependencies in Fedora 9 - 2008-07-19 In-Reply-To: <64b14b300807240451m2e918176lcfcf9891a61179e5@mail.gmail.com> References: <20080719110538.4437.86430@faldor.intranet> <64b14b300807240451m2e918176lcfcf9891a61179e5@mail.gmail.com> Message-ID: <48886F68.9080706@pingoured.fr> Valent Turkovic wrote: > I have these packages that I can't update: > > ---> Package yelp.i386 0:2.22.1-4.fc9 set to be updated > ---> Package xulrunner.i386 0:1.9.0.1-1.fc9 set to be updated > ---> Package epiphany.i386 0:2.22.2-3.fc9 set to be updated > ---> Package epiphany-extensions.i386 0:2.22.1-3.fc9 set to be updated > ---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated > > Because they depend on gecko-libs and Miro and > gnome-python2-gtkmozembed packages are locking that update and > stopping me from updating. > > I thought that xulrunner feature now in Fedora 9 is supposed to fix that, no? This is fixed for me since yesterday Pierre From jkeating at redhat.com Thu Jul 24 14:01:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jul 2008 10:01:54 -0400 Subject: Pungi & firstboot In-Reply-To: References: Message-ID: <1216908114.12190.113.camel@localhost.localdomain> On Thu, 2008-07-24 at 08:23 +0200, Vnpenguin wrote: > I have no gdm in my kickstart. Do I need it or another package for > firstboot GUI ? How are you performing the install itself? If you perform the install in text mode you will not get gui firstboot because the system will not do a graphical boot. It's only when the system gets set up to graphically boot (runlevel 5) that you get graphical firstboot. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 rawhide at redhat.com Thu Jul 24 14:20:31 2008 From: rawhide at redhat.com (Rawhide) Date: Thu, 24 Jul 2008 10:20:31 -0400 Subject: Package EVR problems in Fedora (updates) 2008-07-24 Message-ID: <20080724141608.262D7209DA2@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates', 'dist-f9-updates', 'dist-f10'] AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) NetworkManager-openvpn: dist-f9-updates > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.2.1-3.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnomesword: dist-f8-updates > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-AnyEvent: dist-f8-updates > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Crypt-OpenSSL-RSA: dist-f8-updates > dist-f9-updates (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) dist-f8-updates > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) php-magickwand: dist-f8-updates > dist-f9-updates (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) pidgin-otr: dist-f8-updates > dist-f9-updates (pidgin-otr-3.2.0-1.fc8 pidgin-otr-3.1.0-3.fc9) podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) virt-top: dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From rawhide at redhat.com Thu Jul 24 14:21:13 2008 From: rawhide at redhat.com (Rawhide) Date: Thu, 24 Jul 2008 10:21:13 -0400 Subject: Package EVR problems in Fedora (updates-testing) 2008-07-24 Message-ID: <20080724142010.31E1D209DAE@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates-testing', 'dist-f9-updates-testing', 'dist-f10'] AcetoneISO2: dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) GMT: dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) NetworkManager-openvpn: dist-f9-updates-testing > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) TurboGears: dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) abiword: dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) aplus-fsf: dist-f8-updates-testing > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) cowbell: dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) crossfire: dist-f9-updates-testing > dist-f10 (crossfire-1.10.0-5.fc9 crossfire-1.10.0-4.fc9) driftnet: dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-changelog: dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) eclipse-rpm-editor: dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) fedora-release-notes: dist-f9-updates-testing > dist-f10 (fedora-release-notes-9.0.2-1 fedora-release-notes-9.0.1-1) gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) ganyremote: dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) gbrainy: dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnome-do: dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) gnomesword: dist-f8-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) grub: dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) httrack: dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) inadyn: dist-f8-updates-testing > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) iscsi-initiator-utils: dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) itpp: dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) keepassx: dist-f8-updates-testing > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates-testing > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) kst: dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) libcapseo: dist-f9-updates-testing > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) libntlm: dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) librra: dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) logjam: dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mach: dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) mod_geoip: dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) mysqltuner: dist-f9-updates-testing > dist-f10 (mysqltuner-0.9.8-1 mysqltuner-0.9.1-4) nfs-utils-lib: dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-ounit: dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-AnyEvent: dist-f8-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Device-SerialPort: f8-final > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-File-Find-Rule-Perl: dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) perl-Geo-IP: dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) php-magickwand: dist-f8-updates-testing > dist-f9-updates-testing (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) podsleuth: dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: f8-final > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) synce-gnomevfs: dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-trayicon: dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) syncevolution: dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tilda: dist-f8-updates-testing > dist-f9-updates-testing (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) wdaemon: dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) xorg-x11-drv-nv: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates-testing > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) zenon: dist-f8-updates-testing > dist-f9-updates-testing (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates-testing > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) zhcon: dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From mjs at clemson.edu Thu Jul 24 15:38:03 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 24 Jul 2008 11:38:03 -0400 Subject: Scanner woes in F9 Message-ID: <1216913883.531.18.camel@valkyrie.localdomain> I sent this message to fedora-list, but received no reply. I hope somebody here knows enough about HAL and/or SANE to help me out. Apparently, scanner configuration is now handled through HAL rather than UDEV, which means I have no idea how to get my scanner set up. I have an Epson Expression 800 SCSI scanner. It is detected with no problem as /dev/sg0 and gets user root, group lp and permissions -rw-rw---. So root can see the scanner, but regular users and network users can't see it. Changing the permissions to -rw-rw-rw by hand makes the scanner accessible to local users, but still not over the LAN. And of course, it won't be preserved across reboots. I added the network IP range to /etc/sane.d/saned.conf and added localhost to /etc/sane.d/net.conf, configured /etc/xinetd.d/sane-daemon as it was when it worked in F8, and opened port 6566 in the firewall. Any idea what I'm missing? I have sane-backends-1.0.19-10.fc9.i386. The HAL configuration for scanners is in /usr/share/hal/fdi/policy/10osvendor/19-libsane.fdi. TIA. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jspaleta at gmail.com Thu Jul 24 15:46:26 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jul 2008 07:46:26 -0800 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <48883EB4.7040100@hhs.nl> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> Message-ID: <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> On Thu, Jul 24, 2008 at 12:35 AM, Hans de Goede wrote: > So Jeff, your always good with words, do you feel like contacting Dirk > Hohndel? If I could find reliable contact information. But I think we have a Board member, Karsten, at OSCON who can face-to-face with him this week. -jef From stickster at gmail.com Thu Jul 24 15:52:13 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 24 Jul 2008 11:52:13 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> Message-ID: <1216914733.5114.41.camel@victoria> On Thu, 2008-07-24 at 07:46 -0800, Jeff Spaleta wrote: > On Thu, Jul 24, 2008 at 12:35 AM, Hans de Goede wrote: > > So Jeff, your always good with words, do you feel like contacting Dirk > > Hohndel? > > If I could find reliable contact information. But I think we have a > Board member, Karsten, at OSCON who can face-to-face with him this > week. Q.v.: http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00194.html -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Thu Jul 24 15:34:23 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 24 Jul 2008 11:34:23 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <5256d0b0807240120o45308dc9qa985caffbab811d@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <5256d0b0807240120o45308dc9qa985caffbab811d@mail.gmail.com> Message-ID: <1216913663.28941.36.camel@shinybook.infradead.org> On Thu, 2008-07-24 at 09:20 +0100, Peter Robinson wrote: > >> Very cool news. I look forward to the SIG, the spin and seeing Fedora > >> on even more cool devices :-) > >> > >> http://www.theregister.co.uk/2008/07/23/moblin_reworked/ > > > > Here's what's not clear.... is intel going to look to talk with us > > about making this part of the larger Fedora project or is it going to > > be a downstream derived distribution that will include components such > > that it can not carry the Fedora name? Or are they planning to just > > leverage the existing Fedora distribution bits and do their own thing > > in a way that isn't aligned with existing Fedora contribution > > guidance? Have I missed a discussion concerning Moblin interaction > > with Fedora in the "project" sense? If I have please point me to it so > > I can read up. > > No idea, would be cool if they contributed and there was a SIG and a MID Spin. Yeah, that would definitely be cool. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From pemboa at gmail.com Thu Jul 24 16:01:14 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 24 Jul 2008 11:01:14 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> Message-ID: <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> On Wed, Jul 23, 2008 at 7:17 PM, Jeff Spaleta wrote: > On Wed, Jul 23, 2008 at 1:59 PM, Peter Robinson wrote: >> Very cool news. I look forward to the SIG, the spin and seeing Fedora >> on even more cool devices :-) >> >> http://www.theregister.co.uk/2008/07/23/moblin_reworked/ > > Here's what's not clear.... is intel going to look to talk with us > about making this part of the larger Fedora project or is it going to > be a downstream derived distribution that will include components such > that it can not carry the Fedora name? I suspect the later. The Fedora name probably does little for their target market. > Or are they planning to just > leverage the existing Fedora distribution bits and do their own thing > in a way that isn't aligned with existing Fedora contribution > guidance? Most probably. Fedora is pretty restrictive against non-free software (which I like) but which isn't exactly aligned with "just work" consumer devices. > Have I missed a discussion concerning Moblin interaction > with Fedora in the "project" sense? If I have please point me to it so > I can read up. No idea. > A number of questions spring to mind, chief among them whether the new > Moblin can be incorporated under our secondary arch policy? How > different is the Atom processor anyways? If they are serious about > making this more attractive to developers, I think we need to have a > serious discussion about whether or not the technical work they are > doing can and should live under the Fedora project umbrella. > Can/Should Moblin be the part of the Fedora project aimed at mobile > devices? Sharing to some extent policy, best practices guidance, and > contributor-base. Or should it sit outside our project completely? > > -jef Good luck. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rawhide at redhat.com Thu Jul 24 16:04:33 2008 From: rawhide at redhat.com (Rawhide) Date: Thu, 24 Jul 2008 12:04:33 -0400 Subject: Package EVR problems in Fedora (updates) 2008-07-24 Message-ID: <20080724160338.CE1AD209DA7@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates', 'dist-f9-updates', 'dist-f10'] AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) NetworkManager-openvpn: dist-f9-updates > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.2.1-3.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnomesword: dist-f8-updates > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-AnyEvent: dist-f8-updates > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Crypt-OpenSSL-RSA: dist-f8-updates > dist-f9-updates (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) dist-f8-updates > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) php-magickwand: dist-f8-updates > dist-f9-updates (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) pidgin-otr: dist-f8-updates > dist-f9-updates (pidgin-otr-3.2.0-1.fc8 pidgin-otr-3.1.0-3.fc9) podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) virt-top: dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) ----------------------- Broken paths by builder: abompard: keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) ajax: xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) alcapcom: eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.2.1-3.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) awjb: claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) bos: ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) caillon: gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) chitlesh: ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) choeger: NetworkManager-openvpn: dist-f9-updates > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) cweyl: perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) danielm: initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) deji: gnomesword: dist-f8-updates > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) dwheeler: zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) edhill: itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) endur: streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) gd: samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) hardaker: perl-Crypt-OpenSSL-RSA: dist-f8-updates > dist-f9-updates (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) dist-f8-updates > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) james: python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) jsteffan: pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) kvolny: qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) kwizart: iwl4965-firmware: dist-f8-updates > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) perl-AnyEvent: dist-f8-updates > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) laxathom: tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) liquidat: speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) lmacken: TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) lucilanga: evolution-rss: dist-f9-updates > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) mcepl: syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) mfleming: mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) mgarski: krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) mmahut: pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) mrsam: bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) nigelj: podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) nsantos: rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) ondrejj: kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) orion: GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) pbrobinson: geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) pertusus: gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) pjones: grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) pwouters: driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) pidgin-otr: dist-f8-updates > dist-f9-updates (pidgin-otr-3.2.0-1.fc8 pidgin-otr-3.1.0-3.fc9) rcritten: mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) rdieter: cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) rhughes: hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) rjones: ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) virt-top: dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) rmeggins: fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) robert: php-magickwand: dist-f8-updates > dist-f9-updates (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) s4504kr: aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) sereinit: gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) shishz: snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) simo: ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) sindrepb: cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) spot: AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) stalwart: ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) steved: nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) stransky: chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) turki: libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) walters: jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) wwoods: pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From rawhide at redhat.com Thu Jul 24 16:05:16 2008 From: rawhide at redhat.com (Rawhide) Date: Thu, 24 Jul 2008 12:05:16 -0400 Subject: Package EVR problems in Fedora (updates-testing) 2008-07-24 Message-ID: <20080724160347.E063E209DA7@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates-testing', 'dist-f9-updates-testing', 'dist-f10'] AcetoneISO2: dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) GMT: dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) NetworkManager-openvpn: dist-f9-updates-testing > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) TurboGears: dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) abiword: dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) aplus-fsf: dist-f8-updates-testing > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) cowbell: dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) crossfire: dist-f9-updates-testing > dist-f10 (crossfire-1.10.0-5.fc9 crossfire-1.10.0-4.fc9) driftnet: dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-changelog: dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) eclipse-rpm-editor: dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) fedora-release-notes: dist-f9-updates-testing > dist-f10 (fedora-release-notes-9.0.2-1 fedora-release-notes-9.0.1-1) gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) ganyremote: dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) gbrainy: dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnome-do: dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) gnomesword: dist-f8-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) grub: dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) httrack: dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) inadyn: dist-f8-updates-testing > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) iscsi-initiator-utils: dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) itpp: dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) keepassx: dist-f8-updates-testing > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates-testing > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) kst: dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) libcapseo: dist-f9-updates-testing > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) libntlm: dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) librra: dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) logjam: dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mach: dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) mod_geoip: dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) mysqltuner: dist-f9-updates-testing > dist-f10 (mysqltuner-0.9.8-1 mysqltuner-0.9.1-4) nfs-utils-lib: dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-ounit: dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-AnyEvent: dist-f8-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Device-SerialPort: f8-final > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-File-Find-Rule-Perl: dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) perl-Geo-IP: dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) php-magickwand: dist-f8-updates-testing > dist-f9-updates-testing (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) podsleuth: dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: f8-final > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) synce-gnomevfs: dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-trayicon: dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) syncevolution: dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tilda: dist-f8-updates-testing > dist-f9-updates-testing (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) wdaemon: dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) xorg-x11-drv-nv: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates-testing > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) zenon: dist-f8-updates-testing > dist-f9-updates-testing (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates-testing > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) zhcon: dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) ----------------------- Broken paths by builder: abompard: keepassx: dist-f8-updates-testing > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates-testing > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) airlied: xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) ajax: xorg-x11-drv-nv: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) xorg-x11-server: dist-f9-updates-testing > dist-f10 (xorg-x11-server-1.4.99.905-2.20080702.fc9 xorg-x11-server-1.4.99.905-2.20080701.fc10) alcapcom: eclipse-rpm-editor: dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) anyremote: ganyremote: dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) arozansk: wdaemon: dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) ausil: mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) awjb: claws-mail: dist-f8-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) librra: dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) synce-gnomevfs: dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-trayicon: dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) bos: ghc: dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) caillon: gtkmozembedmm: dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) openvrml: dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) chitlesh: ngspice: dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) choeger: NetworkManager-openvpn: dist-f9-updates-testing > dist-f10 (1:NetworkManager-openvpn-0.7.0-14.svn3632.fc9 1:NetworkManager-openvpn-0.7.0-11.svn3832.fc10) corsepiu: perl-File-Find-Rule-Perl: dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) cweyl: perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) danielm: initng-ifiles: dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dchen: zhcon: dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) deji: gnomesword: dist-f8-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc8 gnomesword-2.3.5-1.fc10) dist-f9-updates-testing > dist-f10 (gnomesword-2.3.5-2.fc9 gnomesword-2.3.5-1.fc10) dhavalgiani: libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) drago01: gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) dreier: libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) dwheeler: zenon: dist-f8-updates-testing > dist-f9-updates-testing (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates-testing > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) edhill: itpp: dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) endur: streamtuner: dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) gd: samba: dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) hardaker: perl-QWizard: dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) james: python-urlgrabber: dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) jjohnstn: eclipse-changelog: dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) jorton: subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) jsteffan: pyjigdo: dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) kvolny: qmmp: dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) kwizart: iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) perl-AnyEvent: dist-f8-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc8.1 perl-AnyEvent-4.21-1.fc10) dist-f9-updates-testing > dist-f10 (perl-AnyEvent-4.161-1.fc9 perl-AnyEvent-4.21-1.fc10) laxathom: gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) tilda: dist-f8-updates-testing > dist-f9-updates-testing (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) liquidat: speedcrunch: dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) lmacken: TurboGears: dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) python-tgcaptcha: dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) lucilanga: evolution-rss: dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) matt: condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) mcepl: syncevolution: dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) mfleming: mod_geoip: dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_security: dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) perl-Geo-IP: dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) mgarski: krusader: dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) michaelc: iscsi-initiator-utils: dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) mmahut: pyephem: dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) mrsam: bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) mtruch: kst: dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) nigelj: podsleuth: dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) nsantos: rhm: dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) ondrejj: kronolith: dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) orion: GMT: dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) perl-Device-SerialPort: f8-final > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) otaylor: hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) pbrobinson: geoclue: dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) pfrields: fedora-release-notes: dist-f9-updates-testing > dist-f10 (fedora-release-notes-9.0.2-1 fedora-release-notes-9.0.1-1) pjones: grub: dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) pwouters: driftnet: dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) rcritten: mod_nss: dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) rdieter: cmucl: dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) k3b: dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) libcapseo: dist-f9-updates-testing > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) sbcl: dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) rhughes: PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) hal-info: dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) rishi: httrack: dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) rjones: ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-ounit: dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) rmeggins: fedora-idm-console: dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) robert: php-magickwand: dist-f8-updates-testing > dist-f9-updates-testing (php-magickwand-1.0.6-2.fc8 php-magickwand-1.0.6-1.fc9) s4504kr: aplus-fsf: dist-f8-updates-testing > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) inadyn: dist-f8-updates-testing > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) scop: mysqltuner: dist-f9-updates-testing > dist-f10 (mysqltuner-0.9.8-1 mysqltuner-0.9.1-4) sereinit: gbrainy: dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) shishz: snownews: dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) simo: ipa: dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) sindrepb: cowbell: dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) gnome-do: dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) spot: AcetoneISO2: dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) logjam: dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) stalwart: ecore: dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) steved: nfs-utils-lib: dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) stransky: chmsee: dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) tagoh: Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) thomasvs: mach: dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) turki: libntlm: dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) uwog: abiword: dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) walters: jna: dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) wart: crossfire: dist-f9-updates-testing > dist-f10 (crossfire-1.10.0-5.fc9 crossfire-1.10.0-4.fc9) wwoods: pybluez: f8-final > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From jkeating at redhat.com Thu Jul 24 16:08:05 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jul 2008 12:08:05 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216792233.12190.68.camel@localhost.localdomain> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> Message-ID: <1216915685.12190.122.camel@localhost.localdomain> On Wed, 2008-07-23 at 01:50 -0400, Jesse Keating wrote: > That said, it might also be worth doing this in two runs. One that > takes the view of F8, F8-updates, f9-updates and another than takes the > view of F8-updates-testing, F9-updates-testing. More things to play > with when I get back from OLS. Well I had a bit of time this morning, so I did it in two runs, one taking only -updates into consideration and one only taking -updates-testing into consideration. > > Another thought I had was that instead of listing the owners of > packages, we could actually list the person whom built the offending > E:N-V-R breaker. This is likely more interesting information anyway > since the owner can change per branch and the owner often isn't the > person doing the build anyway. I'll be looking to wire that up since > the builder is in the data set I get back from koji in the initial query > set. > I also did an ugly hack to get this in place. There is now a second list in the mail that is the broken paths sorted by builder, then sorted by package name. I'm still not mailing individual folks though. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 rawhide at redhat.com Thu Jul 24 16:12:38 2008 From: rawhide at redhat.com (Rawhide) Date: Thu, 24 Jul 2008 12:12:38 -0400 Subject: rawhide report: 20080724 changes Message-ID: <20080724161121.1B7D3209DA7@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080723/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080724/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package flute Java CSS parser using SAC New package fotowall Photo collection creativity tool New package hunspell-sr Serbian hunspell dictionaries New package packagekit-qt Qt interface for PackageKit New package perl-Apache2-SOAP A replacement for Apache::SOAP designed to work with mod_perl 2 New package perl-Convert-BER ASN.1 Basic Encoding Rules New package perl-DBIx-Class-Schema-Loader Dynamic definition of a DBIx::Class::Schema New package perl-Text-CSV-Separator Determine the field separator of a CSV file New package plexus-graph Graph data structures manipulation library Updated Packages: akonadi-1.0.0-1.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Than Ngo - 1.0.0-1 - 1.0.0 anaconda-11.4.1.18-1 -------------------- * Wed Jul 23 18:00:00 2008 Chris Lumens - 11.4.1.18-1 - MD_NEW_SIZE_BLOCKS no longer exists in newer kernel headers. (clumens) * Wed Jul 23 18:00:00 2008 Chris Lumens - 11.4.1.17-1 - Add support for filing bugs straight into bugzilla. (clumens) - Running git-tag -f from a makefile rule is a bad idea (katzj) - A text message in rescue.py is not gettext-ized (atodorov) - Code cleanup - handling of --serial (atodorov) - Offer physical NIC identification in stage 1 (#261101) (dcantrell) - Specify a default cio_ignore parameter for s390x (#253075) (dcantrell) - Fix getting the stage2 image when doing kickstart installs. (clumens) - Convert package names to unicode before displaying the error message (#446826). (clumens) - When there is text mode specified in the kickstart file, disable the vnc question (#455612) (msivak) - We no longer add the fstype to the hd: method in loader. (clumens) - Check DHCP by default on the text network configurator screen. (clumens) - Support booting from FCP-attached CD/DVD drive on s390 (#184648) (dcantrell) authd-1.4.3-21.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Roman Rakus - 1.4.3-21 - Corrected config directive for ident.key to noreplace - Fixed some typos in specfile * Tue Apr 29 18:00:00 2008 Roman Rakus - 1.4.3-20 - another corrections of jiffies64 patch automoc-1.0-0.8.rc1.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Rex Dieter 1.0-0.8.rc1 - automoc4-0.9.84 (1.0-rc1) cleanfeed-0.95.7b-23.fc10 ------------------------- * Wed Jul 23 18:00:00 2008 Roman Rakus - 0.95.7b-23 - Mark config file cleanfeed.conf as noreplace clive-0.4.19-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Nicoleau Fabien 0.4.19-1 - rebuild for 0.4.19 culmus-fonts-0.101-5.fc10 ------------------------- * Wed Jul 23 18:00:00 2008 Rahul Bhalerao - 0.101-5.fc10 - Obsoleted dead package fonts-hebrew cyphesis-0.5.16-1.fc10 ---------------------- * Wed Jul 23 18:00:00 2008 Wart 0.5.16-1 - Update to 0.5.16 dbus-1.2.1-7.fc10 ----------------- * Wed Jul 23 18:00:00 2008 Matthias Clasen - 1.2.1-7 - Own /usr/share/dbus-1/interfaces decibel-audio-player-0.10-2.fc10 -------------------------------- * Thu Jul 24 18:00:00 2008 Debarshi Ray - 0.10-2 - Added 'Requires: gnome-python2-gnomekeyring'. Closes Red Hat Bugzilla bug deluge-0.9.03-2.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Peter Gordon - 0.9.03-2 - Add setuptools runtime dependency, to fix "No module named pkg_resources" error messages. devhelp-0.19.1-3.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Christopher Aillon - 0.19.1-3 - Rebuild against newer gecko dvgrab-3.1-5.fc10 ----------------- * Wed Jul 23 18:00:00 2008 Jarod Wilson - 3.1-5 - Bump and rebuild for libraw1394 v2.0.0 epiphany-2.23.5-2.fc10 ---------------------- * Wed Jul 23 18:00:00 2008 Christopher Aillon - 2.23.5-2 - Rebuild against newer gecko * Tue Jul 22 18:00:00 2008 Matthias Clasen - 2.23.5-1 - Update to 2.23.5 * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway 2.22.2-2 - fix license tag gcstar-1.4.1-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Tian - 1.4.1-1 - New upstream version http://svn.gna.org/viewcvs/*checkout*/gcstar/tags/GCstar_1_4_1/CHANGELOG glibmm24-2.17.1-1.fc10 ---------------------- * Wed Jul 23 18:00:00 2008 Denis Leroy - 2.17.1-1 - Update to upstream 2.17.1 gnome-audio-2.22.2-2.fc10 ------------------------- * Wed Jul 23 18:00:00 2008 Tom "spot" Callaway - 2.22.2-2 - fix license tag gnome-icon-theme-2.23.3-2.fc10 ------------------------------ * Wed Jul 23 18:00:00 2008 Matthias Clasen - 2.23.3-2 - Re-add the symlinks for gtk stock icons again gnome-mime-data-2.18.0-3.fc10 ----------------------------- * Wed Jul 23 18:00:00 2008 Tom "spot" Callaway - 2.18.0-3 - fix license tag - fix patches to apply with fuzz=0 gnome-specimen-0.3-2.fc10 ------------------------- * Wed Jul 23 18:00:00 2008 Tom "spot" Callaway - 0.3-2 - fix license tag gnomebaker-0.6.4-1.fc10 ----------------------- * Tue Jul 22 18:00:00 2008 Tomas Smetana - 0.6.4-1 - new upstream version gstreamer-plugins-good-0.10.8-9.fc10 ------------------------------------ * Tue Jul 22 18:00:00 2008 Jarod Wilson 0.10.8-9 - Bump and rebuild for libraw1394 v2.0.0 gtkmm24-2.13.4-1.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Denis Leroy - 2.13.4-1 - Update to upstream 2.13.4 gvfs-0.99.3-1.fc10 ------------------ * Wed Jul 23 18:00:00 2008 Matthias Clasen - 0.99.3-1 - Update to 0.99.3 * Tue Jul 22 18:00:00 2008 Tomas Bzatek - 0.99.2-1 - Update to 0.99.2 - Split out backends to separate packages hwdata-0.220-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Karsten Hopp 0.220-1 - update pci.ids, usb.ids, oui.txt - MonitorsDB: add some Samsung monitors (Ronald Warsow) - MonitorsDB: add Dell E1609W (Matt Domsch) - MonitorsDB: add 7 Dell monitors (Matt Domsch) - MonitorsDB: add a bunch of Hyundai and ImageQuest monitors * Mon Jun 9 18:00:00 2008 Karsten Hopp 0.219-1 - add BenQ FP2091 monitor (Peter Williams) - add a bunch of Hyundai and ImageQuest monitors iproute-2.6.25-5.fc10 --------------------- * Tue Jul 22 18:00:00 2008 Marcela Maslanova - 2.6.25-5 - fix iproute2-2.6.25-segfault.patch iptables-1.4.1.1-2.fc10 ----------------------- * Tue Jul 22 18:00:00 2008 Thomas Woerner 1.4.1.1-2 - fixed TOS value mask problem (rhbz#456244) (upstream patch) - two more cloexec fixes kacst-fonts-1.6.2-4.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Rahul Bhalerao - 1.6.2-4.fc10 - Dropping previous release * Wed Jul 23 18:00:00 2008 Rahul Bhalerao - 1.6.2-3.fc10 - Obsoleted dead package fonts-arabic kdelibs-4.1.0-1.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdepimlibs-4.1.0-1.fc10 ----------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 libarchive-2.5.5-1.fc10 ----------------------- * Tue Jul 22 18:00:00 2008 Tomas Bzatek 2.5.5-1 - Update to 2.5.5 libdvdread-4.1.3-0.2.fc10 ------------------------- * Thu Jul 17 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.2 - resurrect package from new upstream libfreebob-1.0.11-2.fc10 ------------------------ * Tue Jul 22 18:00:00 2008 Jarod Wilson 1.0.11-2 - Bump and rebuild for libraw1394 v2.0.0 * Sat Apr 12 18:00:00 2008 Anthony Green 1.0.11-1 - Upgrade to 1.0.11. mailman-2.1.11-2.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Tomas Smetana - 3:2.1.11-2 - temporary fix for --fuzz=0 * Tue Jul 22 18:00:00 2008 Tomas Smetana - 3:2.1.11-1 - new upstream version - fix #246978 - FHS compliant initscript mapserver-5.2.0-1.fc10 ---------------------- * Wed Jul 23 18:00:00 2008 Balint Cristian 5.2.0-1 - new 5.2 series upstream mpfr-2.3.1-1.fc10 ----------------- * Mon Jul 21 18:00:00 2008 Ivana Varekova - 2.3.1-1 - update to 2.3.1 nautilus-2.23.5.1-1.fc10 ------------------------ nautilus-sendto-1.0.1-1.fc10 ---------------------------- * Wed Jul 23 18:00:00 2008 - Bastien Nocera - 1.0.1 - Update to 1.0.1 ncurses-5.6-19.20080628.fc10 ---------------------------- * Wed Jul 23 18:00:00 2008 Miroslav Lichvar 5.6-19.20080628 - rebuild with new gpm net-snmp-5.4.1-21.fc10 ---------------------- * Tue Jul 22 18:00:00 2008 Jan Safranek 5.4.1-21 - fix perl SNMP::Session::set (#452131) nginx-0.6.32-1.fc10 ------------------- * Tue Jul 22 18:00:00 2008 Jeremy Hinegardner - 0.6.32-1 - update to 0.6.32 - nginx now supports DESTDIR so removed the patches that enabled it openoffice.org-3.0.0-0.0.26.1.fc10 ---------------------------------- * Tue Jul 22 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.26-1 - next version - drop integrated openoffice.org-3.0.0.ooo90306.sw.wrongprotection.patch - move some libs out of core into the database module - Resolves: rhbz#455904 add openoffice.org-3.0.0.ooo91977.sd.holdreference.patch openssh-5.1p1-1.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Tomas Mraz - 5.1p1-1 - upgrade to new upstream release - fixed a problem with public key authentication and explicitely specified SELinux role perl-Config-Record-1.1.2-1.fc10 ------------------------------- * Wed Jul 23 18:00:00 2008 Ralf Cors??pius - 1.1.2-1 - Upstream update. - Minor spec cleanup. perl-Razor-Agent-2.85-1.fc10 ---------------------------- * Wed Jul 23 18:00:00 2008 Tom "spot" Callaway - 2.85-1 - update to 2.85, relicensed to Artistic 2.0 perl-XML-Grove-0.46alpha-33.fc10 -------------------------------- * Tue Jul 22 18:00:00 2008 Marcela Maslanova - 0.46alpha-33 - use utf8 in test -> all are passing phonon-4.2.0-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Rex Dieter 4.2.0-1 - phonon-4.2.0 pwlib-1.10.10-8.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Jarod Wilson 1.10.10-8 - Disable avc support, since pwlib uses a long-since deprecated and now removed libraw1394 interface for it... * Tue Jul 22 18:00:00 2008 Jarod Wilson 1.10.10-7 - Bump and rebuild for libraw1394 v2.0.0 python-slip-0.1.6-1.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Nils Philippsen - 0.1.6 - move proxy.polkit_enable to polkit.enable_proxy - rename polkit.NotAuthorized to NotAuthorizedException, polkit.auth_required to require_auth * Tue Jul 22 18:00:00 2008 Nils Philippsen - 0.1.5 - don't reset timeout on failed polkit authorizations qgtkstyle-0.0-0.2.20080719svn693.fc10 ------------------------------------- * Wed Jul 23 18:00:00 2008 Shawn Starr 0.0-0.2.20080719svn693 - New upstream snapshot, fix display widget issues - Mimic GTK+ behavior better for some widgets - Fix support for KDE color palette - Fixes support for big-endian systems qt-4.4.0-16.fc10 ---------------- * Wed Jul 23 18:00:00 2008 Rex Dieter 4.4.0-16 - qt-copy-patches-20080723 (kde#162793) - omit deprecated phonon bits rsyslog-3.21.0-1.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Peter Vrabec 3.21.0-1 - upgrade sendmail-8.14.3-1.fc10 ---------------------- * Tue Jul 22 18:00:00 2008 Thomas Woerner 8.14.3-1 - new version 8.14.3 shared-mime-info-0.51-1.fc10 ---------------------------- * Wed Jul 23 18:00:00 2008 - Bastien Nocera - 0.51-1 - Update to 0.51 sugar-presence-service-0.81.4-1.fc10 ------------------------------------ * Wed Jul 23 18:00:00 2008 Morgan Collett - 0.81.4-1 - Update to 0.81.4 system-config-services-0.99.19-1.fc10 ------------------------------------- * Wed Jul 23 18:00:00 2008 Nils Philippsen - 0.99.19-1 - use new slip.dbus API as of python-slip-0.1.6 * Wed Jul 23 18:00:00 2008 Nils Philippsen - 0.99.18-1 - require PolicyKit-gnome instead of usermode tilda-0.9.6-1.fc10 ------------------ * Wed Jul 23 18:00:00 2008 Xavier Lamien - 0.9.6-1 - Update release. * Sun Mar 16 18:00:00 2008 Xavier Lamien - 0.9.5-1 - Updated Release. - Added New requires against new release. vim-7.1.330-2.fc10 ------------------ * Fri Jul 4 18:00:00 2008 Karsten Hopp 7.1.330-2 - new rpm doesn't like zero filled, 3 digit patch numbers * Fri Jul 4 18:00:00 2008 Karsten Hopp 7.1.330-1 - patchlevel 330 xen-3.2.0-17.fc10 ----------------- * Wed Jul 23 18:00:00 2008 Mark McLoughlin - 3.2.0-17.fc10 - Enable xen-hypervisor build - Backport support for booting DomU from bzImage - Re-diff all patches for zero fuzz xulrunner-1.9.0.1-2.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Christopher Aillon 1.9.0.1-2 - Disable system hunspell for now as it's causing some crashes (447444) yelp-2.23.1-3.fc10 ------------------ * Tue Jul 22 18:00:00 2008 Martin Stransky - 2.23.1-3 - rebuild for xulrunner update * Fri Jun 20 18:00:00 2008 Matthias Clasen - 2.23.1-2 - Use a standard icon name in the desktop file * Tue Jun 3 18:00:00 2008 Matthew Barnes - 2.23.1-1 - Update to 2.23.1 Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 61 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) 6:kdepim-4.0.99-1.fc10.i386 requires libakonadiprotocolinternals.so.0 packagekit-qt-devel-0.1-4.fc10.i386 requires packagekit-qt-libs-0.1-4.fc10 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) 6:kdepim-4.0.99-1.fc10.x86_64 requires libakonadiprotocolinternals.so.0()(64bit) packagekit-qt-devel-0.1-4.fc10.i386 requires packagekit-qt-libs-0.1-4.fc10 packagekit-qt-devel-0.1-4.fc10.x86_64 requires packagekit-qt-libs-0.1-4.fc10 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) 6:kdepim-4.0.99-1.fc10.ppc requires libakonadiprotocolinternals.so.0 packagekit-qt-devel-0.1-4.fc10.ppc requires packagekit-qt-libs-0.1-4.fc10 packagekit-qt-devel-0.1-4.fc10.ppc64 requires packagekit-qt-libs-0.1-4.fc10 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) dayplanner-0.9.1-1.fc10.noarch requires perl(DP::CoreModules) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) 6:kdepim-4.0.99-1.fc10.ppc64 requires libakonadiprotocolinternals.so.0()(64bit) livecd-tools-017.1-1.fc9.ppc64 requires yaboot packagekit-qt-devel-0.1-4.fc10.ppc64 requires packagekit-qt-libs-0.1-4.fc10 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From limb at jcomserv.net Thu Jul 24 16:22:24 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 24 Jul 2008 11:22:24 -0500 (CDT) Subject: [Fwd: Returned mail: User unknown] Message-ID: <33359.65.195.245.6.1216916544.squirrel@mail.jcomserv.net> Mailman issue? ---------------------------- Original Message ---------------------------- Subject: Returned mail: User unknown From: "Mail Delivery Subsystem" Date: Thu, July 24, 2008 11:00 am To: limb at jcomserv.net -------------------------------------------------------------------------- The original message was received at 2008-07-24T11:00:07-0500 from postoffice.local [10.0.0.1] ----- The following addresses had permanent fatal errors ----- -----Transcript of session follows ----- ... while talking to postoffice.local.: >>> RCPT To: <<< 550 5.1.1 unknown or illegal alias: fedora-php-devel-list at redhat.com 550 ... User unknown Final-Recipient: RFC822; fedora-php-devel-list at redhat.com Original-Recipient: RFC822; fedora-php-devel-list at redhat.com Action: failed Status: 5.1.1 Remote-MTA: DNS; postoffice.local Diagnostic-Code: SMTP;550 5.1.1 unknown or illegal alias: fedora-php-devel-list at redhat.com Last-Attempt-Date: 2008-07-24T11:00:07-0500 ---------- Forwarded message ---------- From: To: Subject: [Fedora-php-devel-list] Review swapsies: Drupal modules Anyone interested in reviewing these?: https://bugzilla.redhat.com/show_bug.cgi?id=359911 https://bugzilla.redhat.com/show_bug.cgi?id=359921 https://bugzilla.redhat.com/show_bug.cgi?id=359931 https://bugzilla.redhat.com/show_bug.cgi?id=359941 https://bugzilla.redhat.com/show_bug.cgi?id=359961 They're Drupal modules, some dependant on each other. I'll happily review a package or two in exchange for each of these. They should be fairly straightforward. Thanks in advance, Jon -- novus ordo absurdum _______________________________________________ Fedora-php-devel-list mailing list Fedora-php-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-php-devel-list -- novus ordo absurdum From nphilipp at redhat.com Thu Jul 24 16:29:05 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 24 Jul 2008 18:29:05 +0200 Subject: Scanner woes in F9 In-Reply-To: <1216913883.531.18.camel@valkyrie.localdomain> References: <1216913883.531.18.camel@valkyrie.localdomain> Message-ID: <1216916945.17031.4.camel@gibraltar.str.redhat.com> On Thu, 2008-07-24 at 11:38 -0400, Matthew Saltzman wrote: > I sent this message to fedora-list, but received no reply. I hope > somebody here knows enough about HAL and/or SANE to help me out. > > Apparently, scanner configuration is now handled through HAL rather than > UDEV, which means I have no idea how to get my scanner set up. > > I have an Epson Expression 800 SCSI scanner. It is detected with no > problem as /dev/sg0 and gets user root, group lp and permissions > -rw-rw---. So root can see the scanner, but regular users and network > users can't see it. Changing the permissions to -rw-rw-rw by hand makes > the scanner accessible to local users, but still not over the LAN. And > of course, it won't be preserved across reboots. > > I added the network IP range to /etc/sane.d/saned.conf and added > localhost to /etc/sane.d/net.conf, configured /etc/xinetd.d/sane-daemon > as it was when it worked in F8, and opened port 6566 in the firewall. > > Any idea what I'm missing? > > I have sane-backends-1.0.19-10.fc9.i386. The HAL configuration for > scanners is in /usr/share/hal/fdi/policy/10osvendor/19-libsane.fdi. Please open a bug report at http://bugzilla.redhat.com against the sane-backends component and attach the output of "lshal" to the ticket (don't paste it as comment). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jspaleta at gmail.com Thu Jul 24 16:29:03 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jul 2008 08:29:03 -0800 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> Message-ID: <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> On Thu, Jul 24, 2008 at 8:01 AM, Arthur Pemberton wrote: > I suspect the later. The Fedora name probably does little for their > target market. There is the Fedora mark, the Fedora distribution, and the Fedora process. The fedora mark is what I care about most as a Board member The fedora distribution is what I care about most as a user The fedora process is what I care about most as a contributor. If their real goal is to increase contributor involvement then I personally think they need to leverage as much of our process as they can..and not just the bits in the distribution. I want to make sure the moblin people have an adequate understanding of our process, so we can have a discussion concerning whether or not they can align how they do things for cross-pollination of contributor effort. > Most probably. Fedora is pretty restrictive against non-free software > (which I like) but which > isn't exactly aligned with "just work" consumer devices. I looked at the moblin 2 playground site briefly, I'm not sure I see any specific items which are problematic. I believe I even ran into a statement that they are committed to pushing the kernel patches they are generating upstream for review. So they at least appear to 'get it' when it comes to our view of kernel work. http://www.moblin.org/playground/?q=node/23 The current moblin 1 SDK includes the intel compiler, but that not one of the moblin subprojects and i didn't see any specific discussion in the moblin 2 playground. Honestly, we just don't know enough about why they've moved over to be based on Fedora, or how strong the commitment is to a full open moblin 2 stack. There are hints in the moblin 2 playground pages, but I do not trust articles to always get motivations and intents correctly prioritized. Dirk's blog seems to indicate he's been using F8 and F9 on an EEE machine, so its not a completely blind jump. -jef From Jochen at herr-schmitt.de Thu Jul 24 16:29:11 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 24 Jul 2008 18:29:11 +0200 Subject: Package EVR problems in Fedora (updates-testing) 2008-07-24 In-Reply-To: <20080724160347.E063E209DA7@releng1.fedora.phx.redhat.com> References: <20080724160347.E063E209DA7@releng1.fedora.phx.redhat.com> Message-ID: <4888ADD7.4000705@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rawhide schrieb: > subversion: > dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) > > This package should remove from update-testing, because it breaks dependencies to subcommander. > > > s4504kr: > aplus-fsf: > dist-f8-updates-testing > dist-f9-updates-testing (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) > inadyn: > dist-f8-updates-testing > dist-f9-updates-testing (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) > dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) > Should be fixed. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiIrcsACgkQT2AHK6txfgyFVACg3K4JdkDwRLNYRG4xo66AQUwS kLIAoNA/n4BS9MzDIMX6fq/TpTciDWBd =F94c -----END PGP SIGNATURE----- From bleanhar at redhat.com Thu Jul 24 16:39:22 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Thu, 24 Jul 2008 12:39:22 -0400 Subject: Help debugging package build failure In-Reply-To: References: <20080723152701.GM31802@tumbolia-jboss-dev.usersys.redhat.com> <1216827029.10981.33.camel@rosebud> Message-ID: <20080724163922.GB13161@tumbolia-jboss-dev.usersys.redhat.com> +++ Rex Dieter [23/07/08 12:44 -0500]: >Rex Dieter wrote: > >> Rex Dieter wrote: >> >>> seth vidal wrote: >>> >>>> On Wed, 2008-07-23 at 11:27 -0400, Brenton Leanhardt wrote: >>>>> I'm fairly new to the koji build system and a package I've been >>>>> scratch building started failing today. You can see the details here: >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=734161 >>> ... >>>>> /var/lib/mock/dist-f9-build-227923-40553/root/ install 'publican' >>>>> DEBUG util.py:250: Error: Missing Dependency: >>>>> libakonadiprotocolinternals.so.0 is needed by package kdepimlibs >>>>> >>>>> What I can't understand is what is pulling in kdepimlibs. The spec >>>>> file only states: >>>>> >>>>> BuildRequires: publican >>>>> Requires: httpd >>>>> >>>> >>>> I would guess it is coming from publican's dep on >>>> >>>> yum deplist publican >>>> dependency: /usr/bin/xml2pot >>>> provider: kdesdk-utils.i386 >>> >>> See: >>> http://www.redhat.com/archives/fedora-devel-list/2008-July/msg01152.html >> >> And as a followup, looks like the stuff in kdesdk-utils that once didn't >> pull in any extra kde deps, now does (for some hopefully explainable and >> revertable reason). > >wee (love responding to myself), found the dep issue too, will be fixed in >kdesdk-utils-4.0.99-2 > >-- Rex Thanks for tracking this down. My package is building for dist-f9 again on koji. :) > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list From pemboa at gmail.com Thu Jul 24 17:33:25 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 24 Jul 2008 12:33:25 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> Message-ID: <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> On Thu, Jul 24, 2008 at 11:29 AM, Jeff Spaleta wrote: > On Thu, Jul 24, 2008 at 8:01 AM, Arthur Pemberton wrote: >> I suspect the later. The Fedora name probably does little for their >> target market. > > There is the Fedora mark, the Fedora distribution, and the Fedora process. > The fedora mark is what I care about most as a Board member > The fedora distribution is what I care about most as a user > The fedora process is what I care about most as a contributor. > > If their real goal is to increase contributor involvement then I > personally think they need to leverage as much of our process as they > can..and not just the bits in the distribution. I want to make sure > the moblin people have an adequate understanding of our process, so we > can have a discussion concerning whether or not they can align how > they do things for cross-pollination of contributor effort. > >> Most probably. Fedora is pretty restrictive against non-free software >> (which I like) but which >> isn't exactly aligned with "just work" consumer devices. > > I looked at the moblin 2 playground site briefly, I'm not sure I see > any specific items which are problematic. I believe I even ran into a > statement that they are committed to pushing the kernel patches they > are generating upstream for review. So they at least appear to 'get > it' when it comes to our view of kernel work. > http://www.moblin.org/playground/?q=node/23 > > The current moblin 1 SDK includes the intel compiler, but that not one > of the moblin subprojects and i didn't see any specific discussion in > the moblin 2 playground. Honestly, we just don't know enough about > why they've moved over to be based on Fedora, or how strong the > commitment is to a full open moblin 2 stack. There are hints in the > moblin 2 playground pages, but I do not trust articles to always get > motivations and intents correctly prioritized. Dirk's blog seems to > indicate he's been using F8 and F9 on an EEE machine, so its not a > completely blind jump. > > -jef What are your thoughts on the reason given? RPM had one feature that was needed. But from what I've heard/read from others, RPM is lacking many other features (better compression methods for example). RPM has been (seemingly) pretty stagnant. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From ianweller at gmail.com Thu Jul 24 17:42:26 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 24 Jul 2008 12:42:26 -0500 (CDT) Subject: Broken dependencies in Fedora 8 - 2008-07-19 In-Reply-To: <20080719111855.4461.12698@faldor.intranet> References: <20080719111855.4461.12698@faldor.intranet> Message-ID: On Sat, 19 Jul 2008, Michael Schwendt wrote: > ianweller AT gmail.com > mediawiki-HNP-1.1.2-1.fc8.noarch > mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch > mediawiki-StubManager-1.2.0-1.fc8.noarch > I'm utterly confused about this. From what I can see, the dependencies should solve just fine. Can anyone take a look at this? -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams From jspaleta at gmail.com Thu Jul 24 18:31:05 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jul 2008 10:31:05 -0800 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> Message-ID: <604aa7910807241131m52684fbeu491b47c8fef27a05@mail.gmail.com> On Thu, Jul 24, 2008 at 9:33 AM, Arthur Pemberton wrote: > What are your thoughts on the reason given? RPM had one feature that > was needed. But from what I've heard/read from others, RPM is lacking > many other features (better compression methods for example). RPM has > been (seemingly) pretty stagnant. I do not trust technical laypress articles to be accurate as to motivating prioritizes for any decision. Nor should you. We have the ability to have an open transparent dialog with Moblin, and we should not react to the interpretation of an article writer who is looking to attract eyeballs. I have come to expect technical laypress articles to be..sensational...and to note the most controversial of statements because they are controversial and not because they are the most important. I would not hold up The Register as a bastion of journalist integrity. I find, like most technical laypress, that articles are highly editorial in nature, and are not designed to be unbiased accounting of 'facts' or anything resembling investigative reporting. Until Dirk or another Moblin member is actually communicating directly with a Fedora community representative, who is looking to understand the Moblin prioritizes that underlie their decision making, I'm not going to assume the article accurately portrays the fundamental decision making process Moblin has gone through for moblin 2.0. Some decisions were made to move to basing Moblin 2 off of the Fedora kernel..that's the only thing I'm taking away from that article. Beyond that, I view the rest as subtle spin on the part of the Register staff to sensationalize the announcement. Especially the bit about RPM since it was not a direct quote attributed to Dirk. -jef From mschwendt at gmail.com Thu Jul 24 18:31:38 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 24 Jul 2008 20:31:38 +0200 Subject: Broken dependencies in Fedora 8 - 2008-07-19 In-Reply-To: References: <20080719111855.4461.12698@faldor.intranet> Message-ID: <20080724203138.7354c3a2.mschwendt@gmail.com> On Thu, 24 Jul 2008 12:42:26 -0500 (CDT), Ian Weller wrote: > On Sat, 19 Jul 2008, Michael Schwendt wrote: > > > ianweller AT gmail.com > > mediawiki-HNP-1.1.2-1.fc8.noarch > > mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch > > mediawiki-StubManager-1.2.0-1.fc8.noarch > > > > I'm utterly confused about this. From what I can see, the dependencies > should solve just fine. Can anyone take a look at this? Good that you ask. mediawiki is not available for ppc64. Hence your packages don't install on ppc64. From the spec: # Ugly workaround, don't do that at home, kids! # #250992 ExcludeArch: ppc64 From tcallawa at redhat.com Thu Jul 24 18:22:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Jul 2008 14:22:09 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> Message-ID: <1216923729.3499.1.camel@localhost.localdomain> On Thu, 2008-07-24 at 12:33 -0500, Arthur Pemberton wrote: > What are your thoughts on the reason given? RPM had one feature that > was needed. But from what I've heard/read from others, RPM is lacking > many other features (better compression methods for example). RPM has > been (seemingly) pretty stagnant. RPM development is kicking into high gear now, just look at rawhide (or the related threads on this very mailing list). One of the notable coming changes are the improved compression methods. :) ~spot From otaylor at redhat.com Thu Jul 24 18:39:34 2008 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 24 Jul 2008 14:39:34 -0400 Subject: A PackageKit browser plugin Message-ID: <1216924774.10458.93.camel@localhost.localdomain> We've been working on a website for browsing (rating, commenting, etc) available applications for Fedora. As part of that we wanted to be able to install/run software from the website. I spent the last day hacking up a quick browser plugin: If the package is not installed but is available in the package repository, the plugin will show: +------------------------------------+ | _Install GNU Backgammon Now_ | | Version: 20061119-14.fc9 | +------------------------------------+ Click on the plugin, and it will fire off gpk-install-package to install the package; the display changes to: +------------------------------------+ | GNU Backgammon | | Installing... | +------------------------------------+ once that is done (or if the package was already installed), the plugin will show: +------------------------------------+ | _Run GNU Backgammon_ | | Installed version: 20061119-14.fc9 | +------------------------------------+ Given wide usage of PackageKit and availability of the plugin, this could also be pretty neat to put on third-party project pages. The information you provide as parameters to the plugin is: The name of the application for display A list of possible package names A list of possible desktop file names for the application So it should be pretty robust against inter-distro differences in package names. README File: http://git.fishsoup.net/cgit/packagekit-plugin/tree/README Getting the source: git clone git://git.fishsoup.net/packagekit-plugin What do people think... does this make sense as part of the PackageKit project? - Owen From tcallawa at redhat.com Thu Jul 24 18:42:38 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Jul 2008 14:42:38 -0400 Subject: A PackageKit browser plugin In-Reply-To: <1216924774.10458.93.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> Message-ID: <1216924958.3499.2.camel@localhost.localdomain> On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote: > What do people think... does this make sense as part of the PackageKit > project? Sure looks interesting, mayber we could integrate it with the Fedora packageDB? ~spot From tgl at redhat.com Thu Jul 24 18:45:11 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 24 Jul 2008 14:45:11 -0400 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? In-Reply-To: <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> References: <1216864310.3440.54.camel@tuxhugs> <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> Message-ID: <9365.1216925111@sss.pgh.pa.us> Erik van Pienbroek writes: > Op woensdag 23-07-2008 om 18:51 uur [tijdzone -0700], schreef Peter > Gordon: >> 1. Any such notable changes should be briefly described in the Bodhi >> entry. Essentially, package maintainers should summarize the key points >> of the upstream changelog for these. > Maybe it is an idea to add a new rule to the packaging policy, something > in the line of: > "If your package update contains a new release from upstream, add a link > to the full changelog of this new release in the %changelog field" +1 for that. The policy Peter proposes is, quite frankly, going to be ignored --- it's far too much work to lay on package maintainers. Not to mention that Bodhi hardly provides an interface conducive to composing large, complex update messages. regards, tom lane From vnpenguin at vnoss.org Thu Jul 24 18:45:41 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Thu, 24 Jul 2008 20:45:41 +0200 Subject: Pungi & firstboot In-Reply-To: <1216908114.12190.113.camel@localhost.localdomain> References: <1216908114.12190.113.camel@localhost.localdomain> Message-ID: 2008/7/24 Jesse Keating : > On Thu, 2008-07-24 at 08:23 +0200, Vnpenguin wrote: >> I have no gdm in my kickstart. Do I need it or another package for >> firstboot GUI ? > > How are you performing the install itself? If you perform the install > in text mode you will not get gui firstboot because the system will not > do a graphical boot. It's only when the system gets set up to > graphically boot (runlevel 5) that you get graphical firstboot. > Hi, I used graphical installation. But because I have no gdm, so system boots in to runlevel 3 and no graphical firstboot. After added gdm + some X packages => that's ok now ;-) Thanks for your reply, -- http://vnoss.org From jspaleta at gmail.com Thu Jul 24 19:01:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jul 2008 11:01:02 -0800 Subject: A PackageKit browser plugin In-Reply-To: <1216924958.3499.2.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> Message-ID: <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> On Thu, Jul 24, 2008 at 10:42 AM, Tom spot Callaway wrote: > Sure looks interesting, mayber we could integrate it with the Fedora > packageDB? Do you mean integrating it with our web interface for the packagedb? I think everything Owen mentioned with regard to the website interface he's been working on should be considered for integration with our packagedb. If for examples users are commenting through the new website interface on a package that I maintain.... shouldn't I have a way to review those comments or in the case of negative comments turn them into bug tickets? I'm not sure I understand what Owen is working on and how its going to help contributors interface with users better. -jef From pemboa at gmail.com Thu Jul 24 19:09:16 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 24 Jul 2008 14:09:16 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807241131m52684fbeu491b47c8fef27a05@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <604aa7910807241131m52684fbeu491b47c8fef27a05@mail.gmail.com> Message-ID: <16de708d0807241209i65cfd62cmde463980bbfec353@mail.gmail.com> On Thu, Jul 24, 2008 at 1:31 PM, Jeff Spaleta wrote: > On Thu, Jul 24, 2008 at 9:33 AM, Arthur Pemberton wrote: >> What are your thoughts on the reason given? RPM had one feature that >> was needed. But from what I've heard/read from others, RPM is lacking >> many other features (better compression methods for example). RPM has >> been (seemingly) pretty stagnant. > > > I do not trust technical laypress articles to be accurate as to > motivating prioritizes for any decision. Nor should you. We have the > ability to have an open transparent dialog with Moblin, and we should > not react to the interpretation of an article writer who is looking to > attract eyeballs. > I have come to expect technical laypress articles to > be..sensational...and to note the most controversial of statements > because they are controversial and not because they are the most > important. I would not hold up The Register as a bastion of > journalist integrity. I find, like most technical laypress, that > articles are highly editorial in nature, and are not designed to be > unbiased accounting of 'facts' or anything resembling investigative > reporting. > > Until Dirk or another Moblin member is actually communicating directly > with a Fedora community representative, who is looking to understand > the Moblin prioritizes that underlie their decision making, I'm not > going to assume the article accurately portrays the fundamental > decision making process Moblin has gone through for moblin 2.0. Some > decisions were made to move to basing Moblin 2 off of the Fedora > kernel..that's the only thing I'm taking away from that article. > Beyond that, I view the rest as subtle spin on the part of the > Register staff to sensationalize the announcement. Especially the bit > about RPM since it was not a direct quote attributed to Dirk. > > -jef Fair enough. I await better information. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dennisml at conversis.de Thu Jul 24 19:14:34 2008 From: dennisml at conversis.de (Dennis J.) Date: Thu, 24 Jul 2008 21:14:34 +0200 Subject: A PackageKit browser plugin In-Reply-To: <1216924774.10458.93.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> Message-ID: <4888D49A.10102@conversis.de> Owen Taylor wrote: > We've been working on a website for browsing (rating, commenting, > etc) available applications for Fedora. As part of that we wanted > to be able to install/run software from the website. > > I spent the last day hacking up a quick browser plugin: Sounds like a great idea. I got the source and tried to compile it but I get this error: src/contents.cpp: In member function 'void PkpContents::recheck()': src/contents.cpp:119: error: cannot convert 'const char*' to 'PkFilterEnum' for argument '2' to 'gboolean pk_client_resolve(PkClient*, PkFilterEnum, const gchar*, GError**)' make[2]: *** [packagekit_plugin_la-contents.lo] Error 1 make[2]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' make: *** [all] Error 2 Does the plugin require a specific version of PackageKit? Regards, Dennis From otaylor at redhat.com Thu Jul 24 19:20:09 2008 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 24 Jul 2008 15:20:09 -0400 Subject: A PackageKit browser plugin In-Reply-To: <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> Message-ID: <1216927209.10458.103.camel@localhost.localdomain> On Thu, 2008-07-24 at 11:01 -0800, Jeff Spaleta wrote: > On Thu, Jul 24, 2008 at 10:42 AM, Tom spot Callaway wrote: > > Sure looks interesting, mayber we could integrate it with the Fedora > > packageDB? > > Do you mean integrating it with our web interface for the packagedb? Basic idea is that the Application Browsing web app feeds off the packagedb to get information about available package versions and to get a first cut at applications which are human-edited and pruned. (Applications are approximately desktop files, but not quite.) Then the Application Browsing Web App uses the package names (which it knows about from the packagedb) when generating the code to embed the plugin. But the actual display in the plugin is coming from yum via PackageKit, since that's what determines what the user can install at the moment, even if something newer is in packagedb. > I think everything Owen mentioned with regard to the website interface > he's been working on should be considered for integration with our > packagedb. If for examples users are commenting through the new > website interface on a package that I maintain.... shouldn't I have a > way to review those comments or in the case of negative comments turn > them into bug tickets? I'm not sure I understand what Owen is working > on and how its going to help contributors interface with users better. The basic idea is that: - Browsing and installing can be done anonymously - Some operations are available to any registered FAS user (comment/rate/upload screenshots) - Some operations are restricted to owner of the package that corresponds to the application (edit the description, perhaps) Email notifications to package owners when comments are made is almost certainly a desirable feature. Catch me or robin on IRC if you want to discuss things in more detail. - Owen From otaylor at redhat.com Thu Jul 24 19:22:52 2008 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 24 Jul 2008 15:22:52 -0400 Subject: A PackageKit browser plugin In-Reply-To: <4888D49A.10102@conversis.de> References: <1216924774.10458.93.camel@localhost.localdomain> <4888D49A.10102@conversis.de> Message-ID: <1216927372.10458.105.camel@localhost.localdomain> On Thu, 2008-07-24 at 21:14 +0200, Dennis J. wrote: > Owen Taylor wrote: > > We've been working on a website for browsing (rating, commenting, > > etc) available applications for Fedora. As part of that we wanted > > to be able to install/run software from the website. > > > > I spent the last day hacking up a quick browser plugin: > > Sounds like a great idea. I got the source and tried to compile it but I > get this error: > > src/contents.cpp: In member function 'void PkpContents::recheck()': > src/contents.cpp:119: error: cannot convert 'const char*' to 'PkFilterEnum' > for argument '2' to 'gboolean pk_client_resolve(PkClient*, PkFilterEnum, > const gchar*, GError**)' > make[2]: *** [packagekit_plugin_la-contents.lo] Error 1 > make[2]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' > make: *** [all] Error 2 > > Does the plugin require a specific version of PackageKit? I developed it against PackageKit-0.1.x, let me upgrade to 0.2.x from updates-testing and see if I can reproduce and fix the above. Richard keeps on telling me that 0.2.x is amazingly better anyways. - Owen From jspaleta at gmail.com Thu Jul 24 19:32:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jul 2008 11:32:29 -0800 Subject: A PackageKit browser plugin In-Reply-To: <1216927209.10458.103.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> Message-ID: <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> On Thu, Jul 24, 2008 at 11:20 AM, Owen Taylor wrote: > Email notifications to package owners when comments are made is almost > certainly a desirable feature. Catch me or robin on IRC if you want to > discuss things in more detail. Email.. take it or leave it. Some people will think its noise.. there's no win-win for email notification as a feature. What I care about is trying to minimize the number of different web interfaces that I or any other contributor needs to interact with to get things done..including communicating with users about the specific packages. We already have a web interface for packagedb related items. Is this new interface that you are working on meant to be a replacement to what we currently have at https://admin.fedoraproject.org/pkgdb/ ? Or is it meant to supplement it? I would strongly suggest working towards replacing the current interface that both contributors and users are expected to interact with. If I'm going to be expected to use the existing interface...while users are expected to use a new and completely different interface...we've widened the communication gap..even with email notifications turned on. -jef From seg at haxxed.com Thu Jul 24 20:14:22 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 24 Jul 2008 15:14:22 -0500 Subject: A PackageKit browser plugin In-Reply-To: <1216924774.10458.93.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> Message-ID: <1216930463.10679.9.camel@localhost> On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote: > We've been working on a website for browsing (rating, commenting, > etc) available applications for Fedora. As part of that we wanted > to be able to install/run software from the website. Awesome. I've been sitting, staring at Xbox Live Arcade and wondering when we can get similar ease of use. > Given wide usage of PackageKit and availability of the plugin, this > could also be pretty neat to put on third-party project pages. The > information you provide as parameters to the plugin is: > > The name of the application for display > A list of possible package names > A list of possible desktop file names for the application > > So it should be pretty robust against inter-distro differences in > package names. Icky. In the long run what we really need is to put a UUID field into the .desktop specification, and instruct upstream projects to generate a UUID for their application. Ta da, a reliable, cross-distribution, and package manager neutral way to uniquely identify an application. -------------- 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 otaylor at redhat.com Thu Jul 24 20:21:08 2008 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 24 Jul 2008 16:21:08 -0400 Subject: A PackageKit browser plugin In-Reply-To: <1216927372.10458.105.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <4888D49A.10102@conversis.de> <1216927372.10458.105.camel@localhost.localdomain> Message-ID: <1216930868.10458.107.camel@localhost.localdomain> On Thu, 2008-07-24 at 15:22 -0400, Owen Taylor wrote: > On Thu, 2008-07-24 at 21:14 +0200, Dennis J. wrote: > > Owen Taylor wrote: > > > We've been working on a website for browsing (rating, commenting, > > > etc) available applications for Fedora. As part of that we wanted > > > to be able to install/run software from the website. > > > > > > I spent the last day hacking up a quick browser plugin: > > > > Sounds like a great idea. I got the source and tried to compile it but I > > get this error: > > > > src/contents.cpp: In member function 'void PkpContents::recheck()': > > src/contents.cpp:119: error: cannot convert 'const char*' to 'PkFilterEnum' > > for argument '2' to 'gboolean pk_client_resolve(PkClient*, PkFilterEnum, > > const gchar*, GError**)' > > make[2]: *** [packagekit_plugin_la-contents.lo] Error 1 > > make[2]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/dennis/Downloads/source/packagekit-plugin' > > make: *** [all] Error 2 > > > > Does the plugin require a specific version of PackageKit? > > I developed it against PackageKit-0.1.x, let me upgrade to 0.2.x from > updates-testing and see if I can reproduce and fix the above. Richard > keeps on telling me that 0.2.x is amazingly better anyways. OK, should compile and work now if you repull. - Owen From notting at redhat.com Thu Jul 24 20:34:16 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jul 2008 16:34:16 -0400 Subject: A PackageKit browser plugin In-Reply-To: <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> Message-ID: <20080724203416.GB7475@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > it? I would strongly suggest working towards replacing the current > interface that both contributors and users are expected to interact > with. If I'm going to be expected to use the existing > interface...while users are expected to use a new and completely > different interface...we've widened the communication gap..even with > email notifications turned on. Does anyone actually use packagedb to browse for available software? Bill From ianweller at gmail.com Thu Jul 24 20:45:22 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 24 Jul 2008 15:45:22 -0500 (CDT) Subject: Broken dependencies in Fedora 8 - 2008-07-19 In-Reply-To: <20080724203138.7354c3a2.mschwendt@gmail.com> References: <20080719111855.4461.12698@faldor.intranet> <20080724203138.7354c3a2.mschwendt@gmail.com> Message-ID: On Thu, 24 Jul 2008, Michael Schwendt wrote: > On Thu, 24 Jul 2008 12:42:26 -0500 (CDT), Ian Weller wrote: > >> On Sat, 19 Jul 2008, Michael Schwendt wrote: >> >>> ianweller AT gmail.com >>> mediawiki-HNP-1.1.2-1.fc8.noarch >>> mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch >>> mediawiki-StubManager-1.2.0-1.fc8.noarch >>> >> >> I'm utterly confused about this. From what I can see, the dependencies >> should solve just fine. Can anyone take a look at this? > > Good that you ask. mediawiki is not available for ppc64. Hence your > packages don't install on ppc64. From the spec: > > # Ugly workaround, don't do that at home, kids! > # #250992 > ExcludeArch: ppc64 > Interesting, I think I've asked about this before. These are noarch packages, and so the only thing I can really do is make it not depend on the ppc64 arch. There's one problem -- how? -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams From arjan at infradead.org Thu Jul 24 20:53:49 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Thu, 24 Jul 2008 13:53:49 -0700 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> Message-ID: <20080724135349.27064bf4@infradead.org> On Thu, 24 Jul 2008 07:46:26 -0800 "Jeff Spaleta" wrote: > On Thu, Jul 24, 2008 at 12:35 AM, Hans de Goede > wrote: > > So Jeff, your always good with words, do you feel like contacting > > Dirk Hohndel? > > If I could find reliable contact information. But I think we have a > Board member, Karsten, at OSCON who can face-to-face with him this > week. > also if you need help feel also free to contact me; for one Dirk sits on the other side of a cube wall from me, and for another I'm also more or less involved in Moblin 2.0 -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jos at xos.nl Thu Jul 24 21:07:21 2008 From: jos at xos.nl (Jos Vos) Date: Thu, 24 Jul 2008 23:07:21 +0200 Subject: Django 1.0 in F10 ? Message-ID: <200807242107.m6OL7LTa011317@jasmine.xos.nl> Hi, A few days ago Django 1.0-alpha has been released. There will be some betas and the 1.0 final release is planned for end of August or begin of September. Will this Django 1.0 release cycle be picked up for F10? As Django users might know, the previous 0.96.2 release is already quite old and many users needed to do their own SVN checkout, while some important features had to be extracted from separate branches. So this 1.0 release is really important and useful for Django users. Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mschwendt at gmail.com Thu Jul 24 21:17:50 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 24 Jul 2008 23:17:50 +0200 Subject: Broken dependencies in Fedora 8 - 2008-07-19 In-Reply-To: References: <20080719111855.4461.12698@faldor.intranet> <20080724203138.7354c3a2.mschwendt@gmail.com> Message-ID: <20080724231750.b604d375.mschwendt@gmail.com> On Thu, 24 Jul 2008 15:45:22 -0500 (CDT), Ian Weller wrote: > >>> ianweller AT gmail.com > >>> mediawiki-HNP-1.1.2-1.fc8.noarch > >>> mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch > >>> mediawiki-StubManager-1.2.0-1.fc8.noarch > >>> > >> > >> I'm utterly confused about this. From what I can see, the dependencies > >> should solve just fine. Can anyone take a look at this? > > > > Good that you ask. mediawiki is not available for ppc64. Hence your > > packages don't install on ppc64. From the spec: > > > > # Ugly workaround, don't do that at home, kids! > > # #250992 > > ExcludeArch: ppc64 > > > > Interesting, I think I've asked about this before. These are noarch > packages, and so the only thing I can really do is make it not depend on > the ppc64 arch. There's one problem -- how? Use ExcludeArch: ppc64 in the spec file and increase release right of %{?dist}. The ExcludeArch tag finds its way into the src.rpm file header where it is recognised by the updates push tools when dealing with noarch builds. Whether the old builds in the ppc64 repo will be removed automatically, I don't know. At least rel-eng should be able to do that. And note that this is only for F8 mediawiki. From bpepple at fedoraproject.org Thu Jul 24 23:01:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 24 Jul 2008 19:01:09 -0400 Subject: FESCo Meeting Summary for 2008-07-10 Message-ID: <1216940469.4180.4.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * David Woodhouse (dwmw2) * Josh Boyer (jwb) * Karsten Hopp (kick_) * Jon Stanley (jds2001) * Jarod Wilson (j-rod) === Absent === * Dennis Gilmore (dgilmore) == Summary == === New Date & Time for FESCo Meetings === * FESCo has moved when they will have their meetings. They will occur every Wednesday on the FreeNode IRC network in #fedora-meeting at 18:00 UTC. === FESCo Chairperson === * bpepple was chosen to be chairperson. === New Package Maintainer Sponsor === * FESCo approved Jon Ciesla's request to be made a sponsor. === Features === * FESCo approved the following features for F10: * https://fedoraproject.org/wiki/Features/GlitchFreeAudio * https://fedoraproject.org/wiki/Features/OpenChange * https://fedoraproject.org/wiki/Features/SecurityAudit * https://fedoraproject.org/wiki/Features/BetterLIRCSupport * https://fedoraproject.org/wiki/Features/Artistic1Removal * FESCo held off on approving the Latency Policy(1) feature, since they had some questions regarding it. * FESCo voted against making the Nodoka Notification Theme(2) a feature, since they felt it didn't meet the criteria(3) of being a new feature. 1. https://fedoraproject.org/wiki/Features/LatencyPolicy 2. https://fedoraproject.org/wiki/Features/NodokaNotificationTheme 3. https://fedoraproject.org/wiki/Features/Policy/Definitions IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-24.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Thu Jul 24 23:43:03 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 24 Jul 2008 16:43:03 -0700 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? In-Reply-To: <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> References: <1216864310.3440.54.camel@tuxhugs> <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> Message-ID: <1216942983.3331.5.camel@tuxhugs> On Thu, 2008-07-24 at 12:44 +0200, Erik van Pienbroek wrote: > "If your package update contains a new release from upstream, add a link > to the full changelog of this new release in the %changelog field" > I strongly disagree. As I said in my original mail, the whole point of such a potential policy would be that users *should not* need to peruse through upstream changelogs and whatnot. More often than not, they tend to be very technical in nature and/or contain a significant amount of relatively insignificant commits (such as porting to a new third-party library API, build script fixes, etc.); and this - to me - contradicts Fedora's goal of showing how helpful and user-friendly FOSS can truly be. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 choeger at cs.tu-berlin.de Thu Jul 24 23:48:41 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 25 Jul 2008 01:48:41 +0200 Subject: strace trap tool needed? Message-ID: <1216943321.3547.16.camel@choeger6> Hi, a little tool came up to my mind today: How about the possibility to strace a given binary upon execution and write the output to some file? That could be easy to do (I've already roughly written the code down), so I am not going to make a package of it. To demonstrate my idea: if you invoke the script like: trap-strace /usr/bin/less -o /tmp/less.strace after invoking less you cat /tmp/less.strace to see what was going on. Does anyone else need such a tool? If so, what package could collect it, and what constraints (language, i/o, etc.) should it comply with? -------------- 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 peter at thecodergeek.com Thu Jul 24 23:51:11 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 24 Jul 2008 16:51:11 -0700 Subject: [RFC] Package Updates/Bodhi Notification Content Policy? In-Reply-To: <9365.1216925111@sss.pgh.pa.us> References: <1216864310.3440.54.camel@tuxhugs> <1216896249.5109.21.camel@alguno.terneuzen.openftd.org> <9365.1216925111@sss.pgh.pa.us> Message-ID: <1216943471.3331.12.camel@tuxhugs> On Thu, 2008-07-24 at 14:45 -0400, Tom Lane wrote: > +1 for that. The policy Peter proposes is, quite frankly, going to be > ignored --- it's far too much work to lay on package maintainers. With respect, a simple "Add feature foo and fix bug bar" seems to me very little extra work at all. Even for my own packages when there are a lot of such notable changes, I include some of the most major in the Bodhi comment, then a link to the full upstream changelog - so it would not be terribly different from your idea alone...perhaps somewhat of a superset (if I may use the term loosely enough). > Not to mention that Bodhi hardly provides an interface conducive to > composing large, complex update messages. You can create one single file for the update notice, then merely use that in combination with the CLI bodhi-client utility. See https://fedorahosted.org/bodhi/wiki/CLI for more details. Copy/paste with some minor editing (for the branch and dist tag) doesn't seem terribly difficult. =P -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 airlied at redhat.com Thu Jul 24 23:56:37 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 25 Jul 2008 09:56:37 +1000 Subject: strace trap tool needed? In-Reply-To: <1216943321.3547.16.camel@choeger6> References: <1216943321.3547.16.camel@choeger6> Message-ID: <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> On Fri, 2008-07-25 at 01:48 +0200, Christoph H?ger wrote: > Hi, > > a little tool came up to my mind today: How about the possibility to > strace a given binary upon execution and write the output to some file? > That could be easy to do (I've already roughly written the code down), > so I am not going to make a package of it. > > To demonstrate my idea: > if you invoke the script like: > > trap-strace /usr/bin/less -o /tmp/less.strace > > after invoking less you cat /tmp/less.strace to see what was going on. > > Does anyone else need such a tool? > If so, what package could collect it, and what constraints (language, > i/o, etc.) should it comply with? > any reason strace -o /tmp/less.strace /usr/bin/less won't work? Or did I miss something? Dave. From sundaram at fedoraproject.org Fri Jul 25 00:07:00 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jul 2008 05:37:00 +0530 Subject: A PackageKit browser plugin In-Reply-To: <20080724203416.GB7475@nostromo.devel.redhat.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724203416.GB7475@nostromo.devel.redhat.com> Message-ID: <48891924.2050904@fedoraproject.org> Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: >> it? I would strongly suggest working towards replacing the current >> interface that both contributors and users are expected to interact >> with. If I'm going to be expected to use the existing >> interface...while users are expected to use a new and completely >> different interface...we've widened the communication gap..even with >> email notifications turned on. > > Does anyone actually use packagedb to browse for available software? I have, at times. Rahul From Bl0ngo067 at aim.com Fri Jul 25 00:10:41 2008 From: Bl0ngo067 at aim.com (brad longo) Date: Thu, 24 Jul 2008 20:10:41 -0400 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <1216816543.11972.22.camel@victoria> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> <4886DC72.2080803@nicubunu.ro> <1216816543.11972.22.camel@victoria> Message-ID: <48891A01.2080506@aim.com> Paul W. Frields wrote: > On Wed, 2008-07-23 at 10:23 +0300, Nicu Buculei wrote: > >> Dave Airlie wrote: >> >>> On Tue, 2008-07-22 at 21:40 -0500, Mike McGrath wrote: >>> >>>> I wonder if we'll ever get big enough that the art team could make a theme >>>> for each proposed name and we could vote on that as part of the name >>>> selection... it'd be wicked awesome :) >>>> >>> I more wonder why the art team feels the need to use the nick-name of >>> the distro as a basis for the artwork.. surely they are an independent >>> minded bunch, and it would allows to just choose names that we like >>> instead of ones with meaningful artwork.. >>> >> Well, we really have not linked directly the name and the graphics so >> far... it was an attempt in F9 but the graphic with Sulphur crystal was >> dropped at the last minute. >> >> It was a thought that it may be cool if we can link the two and sometime >> is useful to have a starting point when developing some graphics. >> > > And that method would have stood a better chance this time if it hadn't > taken so long to get names vetted through Legal. We're cleaning up that > process for the next release. I drafted something to use as a starting > point: > https://fedoraproject.org/wiki/Releases/Naming_Guidelines > > According to the pattern the nth release must be related to the n+1 release. So what do werewolves and sulphur have in common? --Brad From sundaram at fedoraproject.org Fri Jul 25 00:14:12 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jul 2008 05:44:12 +0530 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48891A01.2080506@aim.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> <4886DC72.2080803@nicubunu.ro> <1216816543.11972.22.camel@victoria> <48891A01.2080506@aim.com> Message-ID: <48891AD4.9090308@fedoraproject.org> brad longo wrote: >> > According to the pattern the nth release must be related to the n+1 > release. So what do werewolves and sulphur have in common? > --Brad That page has a link to http://fedoraproject.org/wiki/Releases/Names Rahul From smooge at gmail.com Fri Jul 25 00:16:25 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 24 Jul 2008 18:16:25 -0600 Subject: Cast your vote for the Fedora 10 Codename! In-Reply-To: <48891A01.2080506@aim.com> References: <1216754706.1399.6.camel@Nokia-N800-23-14> <48864113.4060509@timj.co.uk> <1216758097.30065.20.camel@rosebud> <80d7e4090807221333s51424295of33ecf535e1bf0e7@mail.gmail.com> <1216781105.25170.1.camel@clockmaker.usersys.redhat.com> <4886DC72.2080803@nicubunu.ro> <1216816543.11972.22.camel@victoria> <48891A01.2080506@aim.com> Message-ID: <80d7e4090807241716j3aff5be3q3808efcebe643dd2@mail.gmail.com> On Thu, Jul 24, 2008 at 6:10 PM, brad longo wrote: > Paul W. Frields wrote: >> >> On Wed, 2008-07-23 at 10:23 +0300, Nicu Buculei wrote: >> >>> >>> Dave Airlie wrote: >>> >>>> >>>> On Tue, 2008-07-22 at 21:40 -0500, Mike McGrath wrote: >>>> >>>>> >>>>> I wonder if we'll ever get big enough that the art team could make a >>>>> theme >>>>> for each proposed name and we could vote on that as part of the name >>>>> selection... it'd be wicked awesome :) >>>>> >>>> >>>> I more wonder why the art team feels the need to use the nick-name of >>>> the distro as a basis for the artwork.. surely they are an independent >>>> minded bunch, and it would allows to just choose names that we like >>>> instead of ones with meaningful artwork.. >>>> >>> >>> Well, we really have not linked directly the name and the graphics so >>> far... it was an attempt in F9 but the graphic with Sulphur crystal was >>> dropped at the last minute. >>> >>> It was a thought that it may be cool if we can link the two and sometime >>> is useful to have a starting point when developing some graphics. >>> >> >> And that method would have stood a better chance this time if it hadn't >> taken so long to get names vetted through Legal. We're cleaning up that >> process for the next release. I drafted something to use as a starting >> point: >> https://fedoraproject.org/wiki/Releases/Naming_Guidelines >> > > According to the pattern the nth release must be related to the n+1 release. > So what do werewolves and sulphur have in common? Both react violently to silver. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Fri Jul 25 01:50:27 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jul 2008 07:20:27 +0530 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <20080724135349.27064bf4@infradead.org> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> <20080724135349.27064bf4@infradead.org> Message-ID: <48893163.7070900@fedoraproject.org> Arjan van de Ven wrote: > also if you need help feel also free to contact me; for one Dirk sits > on the other side of a cube wall from me, and for another I'm also more > or less involved in Moblin 2.0 It would be nice if you can get someone from Intel to talk and tell us what's their plan beyond tidbits we have been getting from the press. What can Fedora as a project do to interface better? Rahul From rnorwood at redhat.com Fri Jul 25 02:17:41 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 24 Jul 2008 22:17:41 -0400 Subject: A PackageKit browser plugin In-Reply-To: <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> Message-ID: <20080724221741.7a596f3e@solitude.devel.redhat.com> On Thu, 24 Jul 2008 11:32:29 -0800 "Jeff Spaleta" wrote: > On Thu, Jul 24, 2008 at 11:20 AM, Owen Taylor > wrote: > > Email notifications to package owners when comments are made is > > almost certainly a desirable feature. Catch me or robin on IRC if > > you want to discuss things in more detail. > > Email.. take it or leave it. Some people will think its noise.. > there's no win-win for email notification as a feature. > > What I care about is trying to minimize the number of different web > interfaces that I or any other contributor needs to interact with to > get things done..including communicating with users about the specific > packages. We already have a web interface for packagedb related > items. Is this new interface that you are working on meant to be a > replacement to what we currently have at > https://admin.fedoraproject.org/pkgdb/ ? Or is it meant to supplement > it? I would strongly suggest working towards replacing the current > interface that both contributors and users are expected to interact > with. If I'm going to be expected to use the existing > interface...while users are expected to use a new and completely > different interface...we've widened the communication gap..even with > email notifications turned on. Hi, The target audiences are different. The package database is (mostly) targeted at people interested in the plumbing of Fedora. The (upcoming) application list is targeted at people who are looking for applications to install and 'do stuff' with. It isn't quite ready for a public bashing yet (next week), but the feature page is here: http://fedoraproject.org/wiki/Features/ApplicationInstaller To be clear, we're getting our information from the package DB (among other places). Also, Owen's plugin should be easy to add to package DB as well. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jreiser at BitWagon.com Fri Jul 25 02:55:07 2008 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 24 Jul 2008 19:55:07 -0700 Subject: strace trap tool needed? In-Reply-To: <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> References: <1216943321.3547.16.camel@choeger6> <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> Message-ID: <4889408B.9050009@BitWagon.com> > strace -o /tmp/less.strace /usr/bin/less strace has obnoxious bugs, and the maintainer(s) have been slow to fix it, or to make it useful in pipelines and shell scripts. strace may lag behind the addition of new system calls in the kernel. Applying strace can change the *semantics* of the executable, in ways that have mattered to me. Sometimes the bug was fixed quickly: http://bugzilla.redhat.com/show_bug.cgi?id=354261 Lockup on wait on exited child with exited child but sometimes the bugs linger unfixed for years: http://bugzilla.redhat.com/show_bug.cgi?id=162774 strace ignores int3 SIGTRAP [open for 3 years] http://bugzilla.redhat.com/show_bug.cgi?id=105371 RFE: add support to keep exit status of traced processes [open almost 5 years] -- From rc040203 at freenet.de Fri Jul 25 03:03:17 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jul 2008 05:03:17 +0200 Subject: Package EVR problems in Fedora (updates-testing) 2008-07-24 In-Reply-To: <20080724142010.31E1D209DAE@releng1.fedora.phx.redhat.com> References: <20080724142010.31E1D209DAE@releng1.fedora.phx.redhat.com> Message-ID: <1216954997.3042.207.camel@beck.corsepiu.local> On Thu, 2008-07-24 at 10:21 -0400, Rawhide wrote: > Broken upgrade path report for tags ['f8-final', 'dist-f8-updates-testing', 'dist-f9-updates-testing', 'dist-f10'] > perl-File-Find-Rule-Perl: > dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) Both, perl-File-Find-Rule-Perl-1.04-2.fc9 and perl-File-Find-Rule-Perl-1.04-2.fc8 were pushed from "testing" to "stable" one month (2008-06-25) c.f: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5686 http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5705 No idea what the complaint above is about. Ralf From poelstra at redhat.com Fri Jul 25 03:19:53 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 24 Jul 2008 20:19:53 -0700 Subject: FESCo Meeting Summary for 2008-07-10 In-Reply-To: <1216940469.4180.4.camel@kennedy> References: <1216940469.4180.4.camel@kennedy> Message-ID: <48894659.1050509@redhat.com> Brian Pepple wrote: > === Members Present === > * Brian Pepple (bpepple) > * Bill Nottingham (notting) > * Kevin Fenzi (nirik) > * David Woodhouse (dwmw2) > * Josh Boyer (jwb) > * Karsten Hopp (kick_) > * Jon Stanley (jds2001) > * Jarod Wilson (j-rod) > > === Absent === > * Dennis Gilmore (dgilmore) > > == Summary == > === New Date & Time for FESCo Meetings === > * FESCo has moved when they will have their meetings. They will occur > every Wednesday on the FreeNode IRC network in #fedora-meeting at 18:00 > UTC. > > === FESCo Chairperson === > * bpepple was chosen to be chairperson. > > === New Package Maintainer Sponsor === > * FESCo approved Jon Ciesla's request to be made a sponsor. > > === Features === > * FESCo approved the following features for F10: > * https://fedoraproject.org/wiki/Features/GlitchFreeAudio > * https://fedoraproject.org/wiki/Features/OpenChange > * https://fedoraproject.org/wiki/Features/SecurityAudit > * https://fedoraproject.org/wiki/Features/BetterLIRCSupport > * https://fedoraproject.org/wiki/Features/Artistic1Removal > * FESCo held off on approving the Latency Policy(1) feature, since they > had some questions regarding it. > * FESCo voted against making the Nodoka Notification Theme(2) a feature, > since they felt it didn't meet the criteria(3) of being a new feature. > > 1. https://fedoraproject.org/wiki/Features/LatencyPolicy > 2. https://fedoraproject.org/wiki/Features/NodokaNotificationTheme > 3. https://fedoraproject.org/wiki/Features/Policy/Definitions > > IRC log can be found at: > http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-24.html > > Later, > /B > Bravo on the new summary format! I really like it :) John From jkeating at redhat.com Fri Jul 25 03:22:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jul 2008 23:22:43 -0400 Subject: Package EVR problems in Fedora (updates-testing) 2008-07-24 In-Reply-To: <1216954997.3042.207.camel@beck.corsepiu.local> References: <20080724142010.31E1D209DAE@releng1.fedora.phx.redhat.com> <1216954997.3042.207.camel@beck.corsepiu.local> Message-ID: <1216956163.3119.5.camel@localhost.localdomain> On Fri, 2008-07-25 at 05:03 +0200, Ralf Corsepius wrote: > > Both, > perl-File-Find-Rule-Perl-1.04-2.fc9 > and > perl-File-Find-Rule-Perl-1.04-2.fc8 > were pushed from "testing" to "stable" one month (2008-06-25) > > c.f: > http://admin.fedoraproject.org/updates/F8/FEDORA-2008-5686 > http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5705 > > No idea what the complaint above is about. Likely what happened is that the 1.04-1 build never got obsoleted from the f9 updates-testing. It's a bodhi bug that's fixed in upstream code. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 poelstra at redhat.com Fri Jul 25 04:27:39 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 24 Jul 2008 21:27:39 -0700 Subject: consolidating on gnupg2 in F10 In-Reply-To: <20080715154726.GB24550@nostromo.devel.redhat.com> References: <20080715154726.GB24550@nostromo.devel.redhat.com> Message-ID: <4889563B.1000509@redhat.com> Bill Nottingham wrote: > For a really long time now, we've shipped both gnupg and gnupg2 > in Fedora. In fact, in Fedora 9 a relatively standard install will > get both installed. > > This isn't ideal, obviously - we want as much to be using the same > code, keystore, etc. as possible. > > Here's the current list of things that require gnupg 1: > > AcetoneISO2 spot > apt athimm > duplicity robert > ketchup ben > perl-GnuPG-Interface mdomsch > perl-Module-Signature scop > pgp-tools mdomsch > psi abompard > qca-gnupg abompard > spamassassin wtogami > zeroinstall-injector salimma > > It appears a good number of these can be ported to gnupg2, if not > all of them. Should we wire up a feature page? > > Bill > I don't recall seeing a response to this. Are we targetting a feature page? John From debarshi.ray at gmail.com Fri Jul 25 04:33:33 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 25 Jul 2008 10:03:33 +0530 Subject: A PackageKit browser plugin In-Reply-To: <20080724203416.GB7475@nostromo.devel.redhat.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724203416.GB7475@nostromo.devel.redhat.com> Message-ID: <3170f42f0807242133k745e450bl5fad36fcc0c24d66@mail.gmail.com> > Does anyone actually use packagedb to browse for available software? Now that we have the search functionality, I use it even more often. I use http://packages.debian.org/ in the same way as well. Cheers, Debarshi From rawhide at fedoraproject.org Fri Jul 25 05:44:23 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 25 Jul 2008 05:44:23 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-25 (updates) Message-ID: <20080725054423.B5E4F209DA6@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['f8-final', 'dist-f8-updates', 'dist-f9-updates', 'dist-f10'] AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Crypt-OpenSSL-RSA: dist-f8-updates > dist-f9-updates (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) dist-f8-updates > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) virt-top: dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) ----------------------- Broken paths by builder: abompard: keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) ajax: xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) alcapcom: eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) awjb: claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) bos: ghc: dist-f8-updates > dist-f9-updates (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) caillon: gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) chitlesh: ngspice: dist-f8-updates > dist-f9-updates (ngspice-17-15.fc8 ngspice-17-14.fc9) cweyl: perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) danielm: initng-ifiles: dist-f8-updates > dist-f9-updates (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dwheeler: zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) edhill: itpp: dist-f8-updates > dist-f9-updates (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) endur: streamtuner: dist-f8-updates > dist-f9-updates (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) gd: samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) hardaker: perl-Crypt-OpenSSL-RSA: dist-f8-updates > dist-f9-updates (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) dist-f8-updates > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc8 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-QWizard: dist-f8-updates > dist-f9-updates (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f8-updates > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) james: python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) jsteffan: pyjigdo: dist-f8-updates > dist-f9-updates (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) kvolny: qmmp: dist-f8-updates > dist-f9-updates (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f8-updates > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) kwizart: iwl4965-firmware: dist-f8-updates > dist-f9-updates (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) laxathom: tilda: dist-f8-updates > dist-f9-updates (tilda-0.9.5-1.fc8 tilda-0.9.4-7.fc9) liquidat: speedcrunch: dist-f8-updates > dist-f9-updates (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) lmacken: TurboGears: dist-f8-updates > dist-f9-updates (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) python-tgcaptcha: dist-f8-updates > dist-f9-updates (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) lucilanga: evolution-rss: dist-f9-updates > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) mcepl: syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) mfleming: mod_geoip: dist-f8-updates > dist-f9-updates (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_security: dist-f8-updates > dist-f9-updates (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) perl-Geo-IP: dist-f8-updates > dist-f9-updates (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) mgarski: krusader: dist-f8-updates > dist-f9-updates (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) mmahut: pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) mrsam: bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) nigelj: podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) nsantos: rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) ondrejj: kronolith: dist-f8-updates > dist-f9-updates (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) orion: GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) perl-Device-SerialPort: f8-final > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) f8-final > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f9-updates (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) pbrobinson: geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) pertusus: gnash: dist-f8-updates > dist-f9-updates (gnash-0.8.2-3.fc8 gnash-0.8.2-2.fc9) pjones: grub: dist-f8-updates > dist-f9-updates (grub-0.97-33.1.fc8 grub-0.97-33.fc9) pwouters: driftnet: dist-f8-updates > dist-f9-updates (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) rcritten: mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) rdieter: cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) rhughes: hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) rjones: ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) virt-top: dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) rmeggins: fedora-idm-console: dist-f8-updates > dist-f9-updates (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) s4504kr: aplus-fsf: dist-f8-updates > dist-f9-updates (aplus-fsf-4.22.1-3.fc8 aplus-fsf-4.22.1-2.fc9) inadyn: dist-f8-updates > dist-f9-updates (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f8-updates > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) sereinit: gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) shishz: snownews: dist-f8-updates > dist-f9-updates (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) simo: ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) sindrepb: cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) gnome-do: dist-f8-updates > dist-f9-updates (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) spot: AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) stalwart: ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) steved: nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) stransky: chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) turki: libntlm: dist-f8-updates > dist-f9-updates (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) walters: jna: dist-f8-updates > dist-f9-updates (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) wwoods: pybluez: f8-final > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) dist-f8-updates > dist-f9-updates (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From rawhide at fedoraproject.org Fri Jul 25 05:45:47 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 25 Jul 2008 05:45:47 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-25 (updates-testing) Message-ID: <20080725054547.A4DA8209DA6@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags ['dist-f8-updates-testing', 'dist-f9-updates-testing', 'dist-f10'] AcetoneISO2: dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) GMT: dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) TurboGears: dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) abiword: dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) bash-completion: dist-f9-updates-testing > dist-f10 (bash-completion-20060301-12 bash-completion-20060301-10) bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) chmsee: dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) cowbell: dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) driftnet: dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-changelog: dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) eclipse-rpm-editor: dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) evolution-rss: dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) fedora-idm-console: dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) fedora-release-notes: dist-f9-updates-testing > dist-f10 (fedora-release-notes-9.0.2-1 fedora-release-notes-9.0.1-1) gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) ganyremote: dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) gbrainy: dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) ghc: dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) gnome-do: dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) grub: dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) gtkmozembedmm: dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) hal-info: dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) httrack: dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) inadyn: dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f9-updates-testing > dist-f10 (inadyn-1.96.2-4.fc9 inadyn-1.96.2-3.fc9) initng-ifiles: dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) ipa: dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-6.fc9 ipa-1.1.0-2.fc10) iptables: dist-f8-updates-testing > dist-f9-updates-testing (iptables-1.4.1.1-2.fc8 iptables-1.4.1.1-1.fc9) iscsi-initiator-utils: dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) itpp: dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) jna: dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) kde-filesystem: dist-f9-updates-testing > dist-f10 (kde-filesystem-4-17.fc9 kde-filesystem-4-16.fc10) keepassx: dist-f8-updates-testing > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates-testing > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) kronolith: dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) krusader: dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) kst: dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) libcapseo: dist-f9-updates-testing > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) libntlm: dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) librra: dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) logjam: dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mach: dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) mod_geoip: dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_nss: dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) mod_security: dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) mysqltuner: dist-f9-updates-testing > dist-f10 (mysqltuner-0.9.8-1 mysqltuner-0.9.1-4) nfs-utils-lib: dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) ngspice: dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-ounit: dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) perl-Crypt-OpenSSL-RSA: dist-f9-updates-testing > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc9 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-Device-SerialPort: dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) perl-File-Find-Rule-Perl: dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) perl-Geo-IP: dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) perl-QWizard: dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) podsleuth: dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pybluez: dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) pyephem: dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) pyjigdo: dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) python-tgcaptcha: dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) python-urlgrabber: dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qmmp: dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) rhm: dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) samba: dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) snownews: dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) speedcrunch: dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) streamtuner: dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) synce-gnomevfs: dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-trayicon: dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) syncevolution: dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) thunderbird: dist-f8-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc8 thunderbird-2.0.0.14-1.fc10) dist-f9-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc9 thunderbird-2.0.0.14-1.fc10) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) wdaemon: dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) xorg-x11-drv-nv: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) zenon: dist-f8-updates-testing > dist-f9-updates-testing (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates-testing > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) zhcon: dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) ----------------------- Broken paths by builder: abompard: keepassx: dist-f8-updates-testing > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates-testing > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) airlied: xorg-x11-drv-ati: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-ati-6.8.0-16.fc9 xorg-x11-drv-ati-6.8.0-14.fc9) ajax: xorg-x11-drv-nv: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) alcapcom: eclipse-rpm-editor: dist-f8-updates-testing > dist-f9-updates-testing (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates-testing > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) anyremote: ganyremote: dist-f8-updates-testing > dist-f9-updates-testing (ganyremote-3.0-1.fc8 ganyremote-2.8-2.fc9) arozansk: wdaemon: dist-f8-updates-testing > dist-f9-updates-testing (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) dist-f8-updates-testing > dist-f10 (wdaemon-0.13-3.fc8 wdaemon-0.13-1.fc9) ausil: mysql-gui-tools: dist-f9-updates-testing > dist-f10 (mysql-gui-tools-5.0r12-8.fc9 mysql-gui-tools-5.0r12-5.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) awjb: claws-mail: dist-f8-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates-testing > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates-testing > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) librra: dist-f8-updates-testing > dist-f10 (librra-0.11.1-1.fc8 librra-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (librra-0.11.1-1.fc9 librra-0.11-2.fc9) synce-gnomevfs: dist-f8-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc8 synce-gnomevfs-0.11-2.fc9) dist-f9-updates-testing > dist-f10 (synce-gnomevfs-0.11.1-1.fc9 synce-gnomevfs-0.11-2.fc9) synce-trayicon: dist-f8-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc8 synce-trayicon-0.9.0-14.fc9) dist-f9-updates-testing > dist-f10 (synce-trayicon-0.11-1.fc9 synce-trayicon-0.9.0-14.fc9) bos: ghc: dist-f8-updates-testing > dist-f9-updates-testing (ghc-6.8.2-8.fc8 ghc-6.8.2-2.fc9) caillon: gtkmozembedmm: dist-f8-updates-testing > dist-f9-updates-testing (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) dist-f8-updates-testing > dist-f10 (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) openvrml: dist-f8-updates-testing > dist-f9-updates-testing (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates-testing > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) thunderbird: dist-f8-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc8 thunderbird-2.0.0.14-1.fc10) dist-f9-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc9 thunderbird-2.0.0.14-1.fc10) chitlesh: ngspice: dist-f8-updates-testing > dist-f9-updates-testing (ngspice-17-15.fc8 ngspice-17-14.fc9) corsepiu: perl-File-Find-Rule-Perl: dist-f8-updates-testing > dist-f9-updates-testing (perl-File-Find-Rule-Perl-1.04-2.fc8 perl-File-Find-Rule-Perl-1.04-1.fc9) cweyl: perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates-testing > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) danielm: initng-ifiles: dist-f8-updates-testing > dist-f9-updates-testing (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dist-f8-updates-testing > dist-f10 (initng-ifiles-0.1.5-1.fc8 initng-ifiles-0.1.4-5.fc9) dchen: zhcon: dist-f8-updates-testing > dist-f10 (zhcon-0.2.6-9.fc8 zhcon-0.2.6-8.fc9) dist-f9-updates-testing > dist-f10 (zhcon-0.2.6-9.fc9 zhcon-0.2.6-8.fc9) dhavalgiani: libcgroup: dist-f9-updates-testing > dist-f10 (libcgroup-0.1c-2.fc9 libcgroup-0.1c-1.fc10) drago01: gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) dreier: libibverbs: dist-f9-updates-testing > dist-f10 (libibverbs-1.1.2-1.fc9 libibverbs-1.1.1-3.fc9) dwheeler: zenon: dist-f8-updates-testing > dist-f9-updates-testing (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) dist-f8-updates-testing > dist-f10 (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc10) edhill: itpp: dist-f8-updates-testing > dist-f9-updates-testing (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) dist-f8-updates-testing > dist-f10 (itpp-4.0.4-1.fc8 itpp-4.0.0-2.fc9) endur: streamtuner: dist-f8-updates-testing > dist-f9-updates-testing (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) dist-f8-updates-testing > dist-f10 (streamtuner-0.99.99-19.fc8 streamtuner-0.99.99-17.fc9) gd: samba: dist-f9-updates-testing > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) hardaker: perl-Crypt-OpenSSL-RSA: dist-f9-updates-testing > dist-f10 (perl-Crypt-OpenSSL-RSA-0.25-6.fc9 perl-Crypt-OpenSSL-RSA-0.25-5.fc9) perl-QWizard: dist-f8-updates-testing > dist-f10 (perl-QWizard-3.14-1.fc8 perl-QWizard-3.13-3.fc9) dist-f9-updates-testing > dist-f10 (perl-QWizard-3.14-2.fc9 perl-QWizard-3.13-3.fc9) james: python-urlgrabber: dist-f8-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates-testing > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) jjohnstn: eclipse-changelog: dist-f8-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc8 1:eclipse-changelog-2.6.1-3.fc9) dist-f9-updates-testing > dist-f10 (1:eclipse-changelog-2.6.2-1.fc9 1:eclipse-changelog-2.6.1-3.fc9) jorton: subversion: dist-f9-updates-testing > dist-f10 (subversion-1.5.0-8.fc9 subversion-1.5.0-8) jsteffan: pyjigdo: dist-f8-updates-testing > dist-f9-updates-testing (pyjigdo-0.3.0-1.fc8 pyjigdo-0.2-3.fc9) kvolny: qmmp: dist-f8-updates-testing > dist-f10 (qmmp-0.1.6-1.fc8 qmmp-0.1.5-2.fc9) dist-f9-updates-testing > dist-f10 (qmmp-0.1.6-1.fc9 qmmp-0.1.5-2.fc9) kwizart: iwl4965-firmware: dist-f8-updates-testing > dist-f9-updates-testing (iwl4965-firmware-228.57.2.21-1 iwl4965-firmware-4.44.1.20-1) laxathom: gammu: dist-f9-updates-testing > dist-f10 (gammu-1.19.0-3.fc9 gammu-1.19.0-2.fc9) liquidat: speedcrunch: dist-f8-updates-testing > dist-f9-updates-testing (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) dist-f8-updates-testing > dist-f10 (speedcrunch-0.10-1.fc8 speedcrunch-0.9-3.fc9) lmacken: TurboGears: dist-f8-updates-testing > dist-f9-updates-testing (TurboGears-1.0.4.4-3.fc8 TurboGears-1.0.4.4-2.fc9) python-tgcaptcha: dist-f8-updates-testing > dist-f9-updates-testing (python-tgcaptcha-0.11-3.fc8 python-tgcaptcha-0.11-2.fc9) lucilanga: evolution-rss: dist-f9-updates-testing > dist-f10 (evolution-rss-0.1.0-2.fc9 evolution-rss-0.1.0-1.fc10) matt: condor: dist-f9-updates-testing > dist-f10 (condor-7.0.2-1.fc9 condor-7.0.0-8.fc9) mcepl: syncevolution: dist-f8-updates-testing > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates-testing > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) mfleming: mod_geoip: dist-f8-updates-testing > dist-f9-updates-testing (mod_geoip-1.2.2-1.fc8 mod_geoip-1.2.0-2.fc9) mod_security: dist-f8-updates-testing > dist-f9-updates-testing (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) dist-f8-updates-testing > dist-f10 (mod_security-2.1.7-1.fc8 mod_security-2.1.6-1.fc9) perl-Geo-IP: dist-f8-updates-testing > dist-f9-updates-testing (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Geo-IP-1.31-1.fc8 perl-Geo-IP-1.30-3.fc9) mgarski: krusader: dist-f8-updates-testing > dist-f9-updates-testing (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) dist-f8-updates-testing > dist-f10 (krusader-1.90.0-1.fc8 krusader-1.80.0-5.fc9) michaelc: iscsi-initiator-utils: dist-f8-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc8 iscsi-initiator-utils-6.2.0.868-0.7.fc9) dist-f9-updates-testing > dist-f10 (iscsi-initiator-utils-6.2.0.870-0.0.fc9 iscsi-initiator-utils-6.2.0.868-0.7.fc9) mmahut: pyephem: dist-f8-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) dist-f9-updates-testing > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) mrsam: bootconf: dist-f9-updates-testing > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) mtruch: kst: dist-f8-updates-testing > dist-f9-updates-testing (kst-1.6.0-2.fc8 kst-1.6.0-1.fc9) nigelj: podsleuth: dist-f9-updates-testing > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) nsantos: rhm: dist-f8-updates-testing > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates-testing > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) ondrejj: kronolith: dist-f8-updates-testing > dist-f9-updates-testing (kronolith-2.1.8-1.fc8 kronolith-2.1.7-1.fc9) orion: GMT: dist-f8-updates-testing > dist-f9-updates-testing (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates-testing > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) perl-Device-SerialPort: dist-f8-updates-testing > dist-f9-updates-testing (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) dist-f8-updates-testing > dist-f10 (perl-Device-SerialPort-1.003001-1.fc8 perl-Device-SerialPort-1.04-3.fc9) otaylor: hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) pbrobinson: geoclue: dist-f8-updates-testing > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates-testing > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) pfrields: fedora-release-notes: dist-f9-updates-testing > dist-f10 (fedora-release-notes-9.0.2-1 fedora-release-notes-9.0.1-1) pjones: grub: dist-f8-updates-testing > dist-f9-updates-testing (grub-0.97-33.1.fc8 grub-0.97-33.fc9) pwouters: driftnet: dist-f8-updates-testing > dist-f9-updates-testing (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-16.20040426cvs.fc9) dist-f8-updates-testing > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) rcritten: mod_nss: dist-f9-updates-testing > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) rdieter: cmucl: dist-f8-updates-testing > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates-testing > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) gnupg2: dist-f8-updates-testing > dist-f9-updates-testing (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) dist-f8-updates-testing > dist-f10 (gnupg2-2.0.9-2.fc8 gnupg2-2.0.9-1.fc9) k3b: dist-f8-updates-testing > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates-testing > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) kde-filesystem: dist-f9-updates-testing > dist-f10 (kde-filesystem-4-17.fc9 kde-filesystem-4-16.fc10) libcapseo: dist-f9-updates-testing > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) sbcl: dist-f8-updates-testing > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates-testing > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) rhughes: PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) hal-info: dist-f8-updates-testing > dist-f9-updates-testing (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates-testing > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) rishi: httrack: dist-f8-updates-testing > dist-f9-updates-testing (httrack-3.42-10.fc8 httrack-3.42-9.fc9) dist-f8-updates-testing > dist-f10 (httrack-3.42-10.fc8 httrack-3.42-9.fc9) rjones: ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates-testing > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-ounit: dist-f8-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates-testing > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-res: dist-f8-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates-testing > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates-testing > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) rmeggins: fedora-idm-console: dist-f8-updates-testing > dist-f9-updates-testing (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) dist-f8-updates-testing > dist-f10 (fedora-idm-console-1.1.1-3.fc8 fedora-idm-console-1.1.1-2.fc9) s4504kr: inadyn: dist-f8-updates-testing > dist-f10 (inadyn-1.96.2-4.fc8 inadyn-1.96.2-3.fc9) dist-f9-updates-testing > dist-f10 (inadyn-1.96.2-4.fc9 inadyn-1.96.2-3.fc9) scop: bash-completion: dist-f9-updates-testing > dist-f10 (bash-completion-20060301-12 bash-completion-20060301-10) mysqltuner: dist-f9-updates-testing > dist-f10 (mysqltuner-0.9.8-1 mysqltuner-0.9.1-4) sereinit: gbrainy: dist-f8-updates-testing > dist-f9-updates-testing (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) shishz: snownews: dist-f8-updates-testing > dist-f9-updates-testing (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) dist-f8-updates-testing > dist-f10 (snownews-1.5.9-1.fc8 snownews-1.5.8-2.fc9) simo: ipa: dist-f8-updates-testing > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-6.fc9 ipa-1.1.0-2.fc10) sindrepb: cowbell: dist-f9-updates-testing > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) gnome-do: dist-f8-updates-testing > dist-f9-updates-testing (gnome-do-0.4.2.0-1.fc8 gnome-do-0.4.0.1-1.fc9) spot: AcetoneISO2: dist-f8-updates-testing > dist-f9-updates-testing (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) logjam: dist-f8-updates-testing > dist-f9-updates-testing (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) stalwart: ecore: dist-f8-updates-testing > dist-f9-updates-testing (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) steved: nfs-utils-lib: dist-f9-updates-testing > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) stransky: chmsee: dist-f9-updates-testing > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) tagoh: Canna: dist-f9-updates-testing > dist-f10 (Canna-3.7p3-24.fc9 Canna-3.7p3-23.fc9) thomasvs: mach: dist-f8-updates-testing > dist-f10 (mach-0.9.3-1.fc8 mach-0.9.2-4.fc9) dist-f9-updates-testing > dist-f10 (mach-0.9.3-1.fc9 mach-0.9.2-4.fc9) turki: libntlm: dist-f8-updates-testing > dist-f9-updates-testing (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) dist-f8-updates-testing > dist-f10 (libntlm-1.0-1.fc8 libntlm-0.4.2-1.fc9) twoerner: iptables: dist-f8-updates-testing > dist-f9-updates-testing (iptables-1.4.1.1-2.fc8 iptables-1.4.1.1-1.fc9) uwog: abiword: dist-f8-updates-testing > dist-f9-updates-testing (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) walters: jna: dist-f8-updates-testing > dist-f9-updates-testing (jna-3.0.2-8.fc8 jna-3.0.2-7.fc9) dist-f8-updates-testing > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) wwoods: pybluez: dist-f8-updates-testing > dist-f9-updates-testing (pybluez-0.9.2-1.fc7 pybluez-0.9.1-4.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From tim.lauridsen at googlemail.com Fri Jul 25 07:30:26 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 25 Jul 2008 09:30:26 +0200 Subject: pushing yum 3.2.17-2 back to f8 In-Reply-To: <20080722190257.4111f67f.mschwendt@gmail.com> References: <1216742580.30065.1.camel@rosebud> <20080722190257.4111f67f.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: > On Tue, 22 Jul 2008 12:03:00 -0400, seth vidal wrote: > >> Hi folks, >> I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. >> It speeds things up a fair bit and it also fixes a number of minor-ish >> bugs. However, it also pulls in a few new deps. What are folks thoughts >> on this? > > Positive. It would also fix two broken deps in F8 yum-utils. > I've been using yum-3.2.16-2.fc10 (incl.deps) on F8 for a few > weeks. No problems so far. > Yes, it will be a good idea, then i don't have to make exclude the latest added tools in yum-utils, from f8, because they need a higher yum version, than currently in f8. And of cause it will solve a lot issues with the current f8 yum version. Tim From caolanm at redhat.com Fri Jul 25 07:56:25 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 25 Jul 2008 08:56:25 +0100 Subject: strace trap tool needed? In-Reply-To: <4889408B.9050009@BitWagon.com> References: <1216943321.3547.16.camel@choeger6> <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> <4889408B.9050009@BitWagon.com> Message-ID: <1216972585.18789.51.camel@vain.rhgalway> On Thu, 2008-07-24 at 19:55 -0700, John Reiser wrote: > > strace -o /tmp/less.strace /usr/bin/less > > strace has obnoxious bugs, and the maintainer(s) have been slow to fix it, > or to make it useful in pipelines and shell scripts. > strace may lag behind the addition of new system calls in the kernel. > > Applying strace can change the *semantics* of the executable, > in ways that have mattered to me. How about "ftrace" from the frysk suite, I've found that handy to e.g. filter out only e.g. open calls and give a backtrace for each of them C. From yersinia.spiros at gmail.com Fri Jul 25 08:00:39 2008 From: yersinia.spiros at gmail.com (yersinia) Date: Fri, 25 Jul 2008 10:00:39 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> Message-ID: On Thu, Jul 24, 2008 at 7:33 PM, Arthur Pemberton wrote: > On Thu, Jul 24, 2008 at 11:29 AM, Jeff Spaleta wrote: > > On Thu, Jul 24, 2008 at 8:01 AM, Arthur Pemberton > wrote: > >> I suspect the later. The Fedora name probably does little for their > >> target market. > > > > There is the Fedora mark, the Fedora distribution, and the Fedora > process. > > The fedora mark is what I care about most as a Board member > > The fedora distribution is what I care about most as a user > > The fedora process is what I care about most as a contributor. > > > > If their real goal is to increase contributor involvement then I > > personally think they need to leverage as much of our process as they > > can..and not just the bits in the distribution. I want to make sure > > the moblin people have an adequate understanding of our process, so we > > can have a discussion concerning whether or not they can align how > > they do things for cross-pollination of contributor effort. > > > >> Most probably. Fedora is pretty restrictive against non-free software > >> (which I like) but which > >> isn't exactly aligned with "just work" consumer devices. > > > > I looked at the moblin 2 playground site briefly, I'm not sure I see > > any specific items which are problematic. I believe I even ran into a > > statement that they are committed to pushing the kernel patches they > > are generating upstream for review. So they at least appear to 'get > > it' when it comes to our view of kernel work. > > http://www.moblin.org/playground/?q=node/23 > > > > The current moblin 1 SDK includes the intel compiler, but that not one > > of the moblin subprojects and i didn't see any specific discussion in > > the moblin 2 playground. Honestly, we just don't know enough about > > why they've moved over to be based on Fedora, or how strong the > > commitment is to a full open moblin 2 stack. There are hints in the > > moblin 2 playground pages, but I do not trust articles to always get > > motivations and intents correctly prioritized. Dirk's blog seems to > > indicate he's been using F8 and F9 on an EEE machine, so its not a > > completely blind jump. > > > > -jef > > > What are your thoughts on the reason given? RPM had one feature that > was needed. But from what I've heard/read from others, RPM is lacking > many other features (better compression methods for example). RPM has > been (seemingly) pretty stagnant. > Let me respond on this point. Probably i am the wrong person to tell this but rpm4.6, in rawhide, have now lzma payload support via liblzma. Suse rpm4.4.2.xxxxx have the same support, so have, from more time along iirc, rpm5.org. Regards > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.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 jspaleta at gmail.com Fri Jul 25 08:44:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jul 2008 00:44:34 -0800 Subject: A PackageKit browser plugin In-Reply-To: <20080724221741.7a596f3e@solitude.devel.redhat.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724221741.7a596f3e@solitude.devel.redhat.com> Message-ID: <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> On Thu, Jul 24, 2008 at 6:17 PM, Robin Norwood wrote: > The target audiences are different. If you are driving users to a different site than the package maintainers... and allowing them to comment...you are going to cause a communication gap. A driveby commenting and rating system among users where the maintainers are not encouraged to also interact with...does nothing to get that feedback to the people who are doing the work. Nor does it help those of us doing the work figure out which of our users are worth encouraging to take the next step and start helping. Make the same site expose specific functionality for users, and contributors. There's really no reason I should not be able to use the exact same website to see user comments on my packages...and do the packagedb interactions which lets me elevate other contributors/users as co-maintainers on those very same packages. If i have to go to yet another website to see what users are saying about my packages, I will most likely end up forgetting to do it...even though I actually care. Focusing an interface strickly for users...doesn't help us inteact with users in a way that actually matters. Users talking among themselves does not lead to better package quality nor additional contributor manpower. If you want to make a better package browsing interface...great...do it as an extension to the SAME website that I have to already interact with to do my ownership/watching packagedb manipulation as a contributor. -jef From rawhide at fedoraproject.org Fri Jul 25 09:14:16 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 25 Jul 2008 09:14:16 +0000 (UTC) Subject: rawhide report: 20080725 changes Message-ID: <20080725091416.DCF3D209DA8@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080724/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080725/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package fotoxx Photo editor New package immix Immix, an image mixer New package kpackagekit KDE interface for PackageKit New package libmusicbrainz3 Library for accessing MusicBrainz servers New package libspe2 SPE Runtime Management Library New package mozvoikko Finnish Voikko spell-checker extension for Mozilla programs New package perl-DateTime-Format-DBI Find a parser class for a database connection New package perl-Event-ExecFlow High level API for event-based execution flow control New package python-jinja2 General purpose template engine Updated Packages: NetworkManager-0.7.0-0.11.svn3846.fc10 -------------------------------------- * Thu Jul 24 18:00:00 2008 Dan Williams - 1:0.7.0-0.11.svn3846 - Convert stored IPv4 static IP addresses to new prefix-based scheme automatically - Fix pppd connections to some 3G providers (rh #455348) - Make PPPoE "Show Password" option work - Hide IPv4 config options that don't make sense in certain configurations NetworkManager-openvpn-0.7.0-15.svn3846.fc10 -------------------------------------------- * Thu Jul 24 18:00:00 2008 Dan Williams 1:0.7.0-15.svn3846 - Rebuild to sync with F9 release number * Thu Jul 24 18:00:00 2008 Dan Williams 1:0.7.0-11.svn3846 - Fix TLS Authentication direction combo - Only update settings if the advanced dialog's OK button is pressed NetworkManager-vpnc-0.7.0-0.10.svn3846.fc10 ------------------------------------------- * Thu Jul 24 18:00:00 2008 Dan Williams 1:0.7.0-10.svn3846 - Rebuild for updated NetworkManager anaconda-11.4.1.19-1 -------------------- * Thu Jul 24 18:00:00 2008 Chris Lumens - 11.4.1.19-1 - Fix another NFS kickstart segfault (#456461). (clumens) - Remove support for generating a minstg2.img image. (dcantrell) - If the xconfig command is given, do something with it (#455938). (clumens) - METHOD_CDROM is now supported on s390 (jgranado). (clumens) - Fix test for if we could access stage2.img on the CD (wwoods). - Look for updates.img and product.img on the boot.iso. (clumens) - Suspend the curses interface before calling scripts and resume afterwards (#435314) (msivak) beagle-0.3.8-4.fc10 ------------------- * Thu Jul 24 18:00:00 2008 Adel Gadllah - 0.3.8-4 - Fix build against new epiphany - Remove versioned thunderbird requires * Sun Jul 20 18:00:00 2008 Adel Gadllah - 0.3.8-3 - Check if the user exists before creating RH #441175 * Sat Jul 19 18:00:00 2008 Adel Gadllah - 0.3.8-2 - RH #441375 - Don't ship Thunderbird and Evolution backends in the main - package - Install thunderbird-extension correctly busybox-1.10.3-2.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Ivana Varekova - 1:1.10.3-2 - add findfs to static version of busybox (kexec-tools need it #455998) bzr-gtk-0.94.0-5.fc10 --------------------- * Thu Jul 24 18:00:00 2008 Toshio Kuratomi 0.94.0-5 - Upstream has a new patch for bz#455284. control-center-2.23.5-3.fc10 ---------------------------- * Fri Jul 25 18:00:00 2008 - Bastien Nocera - 2.23.5-3 - Remove testing hack * Thu Jul 24 18:00:00 2008 Soren Sandmann - 2.23.5-1 - Update to 2.23.5. Drop randr, standard icon and notification theme patches. - Comment out libcanberra patch for now since it doesn't apply * Thu Jul 24 18:00:00 2008 Soren Sandmann - 2.23.5-1 - Update the packaged files to match reality. * Thu Jul 24 18:00:00 2008 - Bastien Nocera - 2.23.5-2 - Update the libcanberra patch * Thu Jul 24 18:00:00 2008 - Bastien Nocera - 2.23.4-6 - Add patch to support the Free Desktop sound theme spec - Remove gnome-vfs-methods as per upstream * Thu Jul 24 18:00:00 2008 - Bastien Nocera - 2.23.4-5 - Remove some obsolete patches coreutils-6.12-7.fc10 --------------------- * Thu Jul 24 18:00:00 2008 Kamil Dudka - 6.12-7 - dd: iflag=fullblock now read full blocks if possible (#431997, #449263) - ls: --color now highlights files with capabilities (#449985) crossfire-1.11.0-1.fc10 ----------------------- * Thu Jul 24 18:00:00 2008 Wart 1.11.0-1 - Update to 1.11.0 * Tue Jul 22 18:00:00 2008 Wart 1.10.0-6 - Fix selinux policy with regard to sock_file * Wed Jun 18 18:00:00 2008 Wart 1.10.0-5 - Fix creation of the crossfire user (BZ #442384) crossfire-client-1.11.0-1.fc10 ------------------------------ * Thu Jul 24 18:00:00 2008 Wart 1.11.0-1 - Update to 1.11.0 crossfire-maps-1.11.0-1.fc10 ---------------------------- * Thu Jul 24 18:00:00 2008 Wart 1.11.0-1 - Update to 1.11.0 dayplanner-0.9.1-3.fc10 ----------------------- ganyremote-5.0-1.fc10 --------------------- * Mon Jul 21 18:00:00 2008 Mikhail Fedotov - 5.0-1 Fixed to work properly under RHEL4. Internationalization support. Added Austrian, Brazilian Portuguese, German, Hungarian, Spanish, Italian, Polish and Russian translation. * Sun Jun 29 18:00:00 2008 Mikhail Fedotov - 4.0-1 Small enhancements git-1.5.6.4-1.fc10 ------------------ * Thu Jul 24 18:00:00 2008 James Bowes 1.5.6-4 - git-1.5.6.4 glib2-2.17.4-5.fc10 ------------------- * Thu Jul 24 18:00:00 2008 David Zeuthen - 2.17.4-5 - rebuild * Thu Jul 24 18:00:00 2008 David Zeuthen - 2.17.4-4 - autoreconf * Thu Jul 24 18:00:00 2008 David Zeuthen - 2.17.4-3 - Backport patch for g_mount_guess_content_type_sync gnome-session-2.23.5-0.2008.07.21.4.fc10 ---------------------------------------- * Thu Jul 24 18:00:00 2008 Matthias Clasen - 2.23.5.0.2008.07.21.4 - Fix a crash gnome-utils-2.20.0.1-8.fc10 --------------------------- * Thu Jul 24 18:00:00 2008 Matthias Clasen - 1:2.20.0.0.1-8 - Use standard icon names gnome-vfs2-obexftp-0.4-7.fc10 ----------------------------- * Thu Jul 24 18:00:00 2008 Tom "spot" Callaway - 0.4-7 - fix license tag gnomesword-2.3.5-2.fc10 ----------------------- * Thu Jul 24 18:00:00 2008 Deji Akingunola - 2.3.5-2 - Bump EVR gnubiff-2.2.7-5.fc10 -------------------- * Thu Jul 24 18:00:00 2008 Tom "spot" Callaway - 2.2.7-5 - fix license tag gnugo-3.6-7.fc10 ---------------- * Thu Jul 24 18:00:00 2008 Tom "spot" Callaway - 3.6-7 - fix license tag gparted-0.3.8-1.fc10 -------------------- * Sun Jul 13 18:00:00 2008 Deji Akingunola - 0.3.8-1 - New upstream version ikiwiki-2.54-1.fc10 ------------------- * Thu Jul 24 18:00:00 2008 Thomas Moschny - 2.54-1 - Update to 2.54. - Move example plugin file to doc. jakarta-commons-codec-1.3-9.4.fc10 ---------------------------------- * Thu Jul 24 18:00:00 2008 Andrew Overholt 1.3-9.4 - Update OSGi manifest. jakarta-commons-httpclient-3.1-0.3.fc10 --------------------------------------- * Thu Jul 24 18:00:00 2008 Andrew Overholt 1:3.1-0.3 - Update OSGi MANIFEST.MF kanyremote-5.0-1.fc10 --------------------- * Mon Jul 21 18:00:00 2008 Mikhail Fedotov - 5.0-1 Internationalization support. Added Austrian, Brazilian Portuguese, German, Hungarian, Spanish, Italian, Polish and Russian translation. kde-l10n-4.1.0-1.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 * Tue Jul 22 18:00:00 2008 Than Ngo 4.0.98-1 - 4.0.98 (4.1rc1) kdeaccessibility-4.1.0-1.fc10 ----------------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdeadmin-4.1.0-2.fc10 --------------------- * Thu Jul 24 18:00:00 2008 Kevin Kofler 4.1.0-2 - remove broken .pc file (segfaults RPM, #456100), drop Requires: pkgconfig * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 * Fri Jul 18 18:00:00 2008 Rex Dieter 7:4.0.99-1 - 4.0.99 kdeartwork-4.1.0-1.fc10 ----------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdebase-4.1.0-1.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdebase-runtime-4.1.0-1.fc10 ---------------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdebase-workspace-4.1.0-1.fc10 ------------------------------ kdebindings-4.1.0-1.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdeedu-4.1.0-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdegames-4.1.0-1.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdegraphics-4.1.0-1.fc10 ------------------------ * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdelibs-4.1.0-2.fc10 -------------------- * Thu Jul 24 18:00:00 2008 Kevin Kofler 4.1.0-2 - move Sonnet documentation back to the main package - fix #453063 (Sonnet documentation multilib conflict) properly kdemultimedia-4.1.0-1.fc10 -------------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdenetwork-4.1.0-1.fc10 ----------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdepim-4.1.0-2.fc10 ------------------- * Thu Jul 24 18:00:00 2008 Than Ngo 4.1.0-2 - respun * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdeplasma-addons-4.1.0-1.fc10 ----------------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdesdk-4.1.0-1.fc10 ------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 * Wed Jul 23 18:00:00 2008 Rex Dieter 4.0.99-2 - fix -utils dep issues kdetoys-4.1.0-1.fc10 -------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 kdeutils-4.1.0-1.fc10 --------------------- * Wed Jul 23 18:00:00 2008 Than Ngo 4.1.0-1 - 4.1.0 * Mon Jul 21 18:00:00 2008 Kevin Kofler 4.0.99-1.1 - reinclude kjots on F9 (moved to kdepim in 4.1, we don't ship kdepim 4 in F9) kernel-2.6.27-0.180.rc0.git11.fc10 ---------------------------------- * Thu Jul 24 18:00:00 2008 Roland McGrath - Disable sfc module, not compiling. - Disable kernel-doc package. * Thu Jul 24 18:00:00 2008 Roland McGrath - 2.6.26-git11 - kconfig updates for 2.6.26-git11 - utrace update * Thu Jul 24 18:00:00 2008 Mark McLoughlin - Enable Xen guest support in kernel-PAE.i686 and kernel.x86_64 - Obsolete kernel-xen - Remove the hypervisor (xen.gz) - moved to xen-hypervisor package * Wed Jul 23 18:00:00 2008 Dave Jones - 2.6.26-git10 * Tue Jul 22 18:00:00 2008 Dave Jones - 2.6.26-git9 kvm-71-2.fc10 ------------- * Tue Jul 22 18:00:00 2008 Glauber Costa - 71-2 - Apply patches correctly. - Enable ia64. * Mon Jul 21 18:00:00 2008 Glauber Costa - 71-1 - Update to kvm-71 - --enable-alsa is no more, and kvm-71 seem to have troubles yet to be sorted out upstream with parameter passing to qemu. So as a temporary quickfix, add kvm-71-alsa.patch to handle it. libdvdnav-4.1.3-0.3.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.3 - add missing file to -devel * Thu Jul 17 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.2 - update to current SVN - use new external libdvdread mod_fcgid-2.2-5.fc10 -------------------- * Thu Jul 24 18:00:00 2008 Paul Howarth 2.2-5 - Tweak selinux-policy version detection macro to work with current Rawhide nmap-4.68-1.fc10 ---------------- * Thu Jul 24 18:00:00 2008 Tomas Smetana - 2:4.68-1 - new upstream version openoffice.org-3.0.0-0.0.27.1.fc10 ---------------------------------- * Thu Jul 24 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.27-1 - next version - drop integrated workspace.native172.patch - drop integrated openoffice.org-3.0.0.ooo82545.np_sdk.x86_64.patch * Wed Jul 23 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.26-2 - Resolves: rhbz#456292 openoffice.org-3.0.0.ooo92026.sd.disposed_during_disposing.patch - Resolves: rhbz#451708 ensure root certs are available for document signing - Resolves: rhbz#456459 3-layer OOo hits the sdk/odk again packagekit-qt-0.1-0.6.b3.fc10 ----------------------------- * Thu Jul 24 18:00:00 2008 Steven M. Parrish 0.1-0.6.b3 - Fixed changelog to include version & release * Thu Jul 24 18:00:00 2008 Steven M. Parrish 0.1-0.5.b3 - Fixed broken dependency pdns-recursor-3.1.7-2.fc10 -------------------------- * Thu Jul 24 18:00:00 2008 Ruben Kerkhof - 3.1.7-2 - Use OPTFLAGS because CXXFLAGS overrides the defaults * Thu Jul 24 18:00:00 2008 Ruben Kerkhof - 3.1.7-1 - Upstream released new version, now with Lua support perl-AnyEvent-4.220-1.fc10 -------------------------- phonon-4.2.0-2.fc10 ------------------- * Thu Jul 24 18:00:00 2008 Rex Dieter 4.2.0-2 - rename -backend-gstreamer -> backend-gst preload-0.6-1.fc10 ------------------ * Thu Jul 24 18:00:00 2008 Behdad Esfahbod - 0.6-1 - Update to 0.6 - Remove all patches. They are all obsolete by upstream now. - Add preload-0.6-start-late.patch to start preload as last service. We use readahead for boot speedup, and want preload just for login/desktop speedup. So, start it last. publican-fedora-0.13-0.fc10 --------------------------- * Mon Apr 14 18:00:00 2008 Jeff Fearn 0.13-0 - Fix missing list image in html-single articles - QANDA set css fix BZ #442674 - Override PDF Theme - Added package tag BZ #444908 - Added Article and Set Templates pulseaudio-0.9.11-1.fc10 ------------------------ * Thu Jul 24 18:00:00 2008 Lennart Poettering 0.9.11-1 - Final release 0.9.11 * Tue Jul 22 18:00:00 2008 Jon McCann 0.9.11-0.7.git20080626 - Fix for CK API changes python-elixir-0.6.0-1.fc10 -------------------------- * Thu Jul 24 18:00:00 2008 James Bowes 0.6.0-1 - Update to 0.6.0 python-fedora-0.3.3-1.fc10 -------------------------- * Wed Jul 23 18:00:00 2008 Toshio Kuratomi - 0.3.3-1 - A few fixes for the new fas release. python-slip-0.1.7-1.fc10 ------------------------ * Thu Jul 24 18:00:00 2008 Nils Philippsen - 0.1.7 - fix import error (#456511) python-vobject-0.7.0-1.fc10 --------------------------- * Thu Jul 24 18:00:00 2008 James Bowes - 0.7.0-1 - Update to 0.7.0 sectool-0.8.5-1.fc10 -------------------- * Thu Jul 24 18:00:00 2008 Peter Vrabec - 0.8.5-1 - upgrade selinux-policy-3.5.1-2.fc10 --------------------------- * Fri Jul 25 18:00:00 2008 Dan Walsh 3.5.1-2 - Eliminate vbetool duplicate entry * Wed Jul 16 18:00:00 2008 Dan Walsh 3.5.1-1 - Fix xguest -> xguest_mozilla_t -> xguest_openiffice_t - Change dhclient to be able to red networkmanager_var_run * Tue Jul 15 18:00:00 2008 Dan Walsh 3.5.0-1 - Update to latest refpolicy - Fix libsemanage initial install bug shadow-utils-4.1.2-3.fc10 ------------------------- * Thu Jul 24 18:00:00 2008 Peter Vrabec 2:4.1.2-3 - recreate selinux patch * Tue Jul 22 18:00:00 2008 Peter Vrabec 2:4.1.2-2 - provide getspnam by man-pages speex-1.2-0.10.rc1.fc10 ----------------------- * Thu Jul 24 18:00:00 2008 Miroslav Lichvar - 1.2-0.10.rc1 - update to 1.2rc1 - move manual.pdf to -devel system-config-services-0.99.20-1.fc10 ------------------------------------- * Thu Jul 24 18:00:00 2008 Nils Philippsen - 0.99.20-1 - use new slip.dbus API as of python-slip-0.1.7 vino-2.23.5-2.fc10 ------------------ * Fri Jul 25 18:00:00 2008 Matthias Clasen - 2.23.5-2 - Use standard icon names vpnc-0.5.1-6.fc10 ----------------- * Thu Jul 24 18:00:00 2008 Tomas Mraz - 0.5.1-6 - do not modify domain in resolv.conf (#446404) - clean up modified resolv.conf on startup (#455899) xorg-x11-drv-radeonhd-1.2.1-3.7.20080724git.fc10 ------------------------------------------------ * Thu Jul 24 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.7.20080724git - New snapshot (upstream commit 31e46386293fd0c54c99328eee3cfe7b49584f9d): - 31e46386: Connectors: Increase the number of available connectors to 6. - 8b1d3323: I2C: Fix I2C slave address probing for RV620 and later. - d65b67b0: HPD: Add support for HPD_3 found on RV620 and later hardware. - a900052b: DIG: Extend heuristic to check if golden values are available for requested coherent/incoherent mode. - d3e6c7f7: RandR: Log when a 'scaled to' mode doesn't vaildate. - 68592e30: MC/RS600: Fix MC indirect access functions. - fdf5014c: CRTC/Scaler: Log more information about the scaler. - 94d759b9: DDIA: Disable Sync DC Balancer on DDIA block of RS690. - 202f2332: I2C: Check for more error conditions in I2CStatus on RS690. - ec2fbeee: Fix typo in list of supported chips (again) - 435320de: Crtc/Scaler: Disallow interlaced for all modes involving scaler. - c0e0dc7d: ID: Adding M82 chipset name and some more verbose logging info. - 8133d1a4: MC: Enable MC control for RS600, fixed segfault. - f362e5ab: R5xx DRI: increase CP timeout. - 1761d6c5: R5xx Accel: split r5xx2DInfo into XAA and EXA specific structs. xorg-x11-server-1.4.99.906-1.fc10 --------------------------------- * Thu Jul 24 18:00:00 2008 Adam Jackson 1.4.99.906-1 - 1.5RC6. xscreensaver-5.06-2.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Mamoru Tasaka - 1:5.06-2 - Patch from jwz to fix bug 456399 * Thu Jul 24 18:00:00 2008 Mamoru Tasaka - Build some test binaries for debugging Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 73 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pytrainer-1.5.0.0.1-5.fc10.noarch requires xulrunner = 0:1.9.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From nicolas.mailhot at laposte.net Fri Jul 25 10:03:34 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 12:03:34 +0200 Subject: A PackageKit browser plugin In-Reply-To: <48891924.2050904@fedoraproject.org> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724203416.GB7475@nostromo.devel.redhat.com> <48891924.2050904@fedoraproject.org> Message-ID: <1216980214.22751.14.camel@rousalka.okg> On Fri, 2008-07-25 at 05:37 +0530, Rahul Sundaram wrote: > Bill Nottingham wrote: > > Jeff Spaleta (jspaleta at gmail.com) said: > >> it? I would strongly suggest working towards replacing the current > >> interface that both contributors and users are expected to interact > >> with. If I'm going to be expected to use the existing > >> interface...while users are expected to use a new and completely > >> different interface...we've widened the communication gap..even with > >> email notifications turned on. > > > > Does anyone actually use packagedb to browse for available software? > > I have, at times. The fonts SIG maintains this wiki section http://fedoraproject.org/wiki/Fonts It would be mighty nice if we could just point to some semi-automated website instead. The problems as I see them are 1. we need info about not existing wishlist/in-review/rejected packages 2. we need some info not in pkgdb (style and unicode coverage, ideally autogenerated font png previews) Regards, -- Nicolas Mailhot -------------- 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 nicolas.mailhot at laposte.net Fri Jul 25 10:36:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 12:36:40 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <20080724224755.GB2000@mokona.greysector.net> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> Message-ID: <1216982200.22751.32.camel@rousalka.okg> On Fri, 2008-07-25 at 00:47 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 24 July 2008 at 23:10, Nicolas Mailhot wrote: > > I'm proposing the following guidelines amendment: > > https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages > > I'm generally in favour, but ... > [...] > 1. any package that makes use of fonts in a modern format like OpenType TT > (TTF) or OpenType CFF (OTF) MUST have them packaged separately > [...] > > ... what about fonts in other formats which happen to be included in a given > package? I don't have any specific examples, just asking. Frankly, the other font formats are so much less useful than modern font formats, the probability someone did creative legal restructuring is much lower. The big exception are Type1 fonts but I just hope they can die die die (and if the Tex-Gyre situation is fixed and we can use OTF Tex-Gyre fonts instead of all ther URW font variants we currently ship I'll propose Type1 purging from the repository). In the meanwhile, it may make sense to add Type1 to the list. For other formats, the sad truth is no one so far has volunteered writing doc on how they should be packaged, so I'm afraid no one knows how to review them. -- Nicolas Mailhot -------------- 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 pertusus at free.fr Fri Jul 25 11:03:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jul 2008 13:03:53 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <1216982200.22751.32.camel@rousalka.okg> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> <1216982200.22751.32.camel@rousalka.okg> Message-ID: <20080725110353.GB4862@free.fr> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: > > Frankly, the other font formats are so much less useful than modern font > formats, the probability someone did creative legal restructuring is > much lower. The big exception are Type1 fonts but I just hope they can > die die die (and if the Tex-Gyre situation is fixed and we can use OTF I don't think this may happen in a while because some very interesting apps (though not mainstream desktop apps, fortunately) uses type1 fonts, mostly using t1lib, like xfig, xdvi, grace. But in general they don't use directly the t1lib way to find fonts, only to render them but most of the time either use a specific way (like grace) or the tex kpathsea way (if I recall well it is what xdvi does). It is quite painfull for packaging not to have something normalized, but I think it should stay as long as those packages are still in fedora, since I don't think that upstream will use *tf fonts, still these are very useful packages, especially for old-timers. > In the meanwhile, it may make sense to add Type1 to the list. For tex I believe that it will be too complicated to use the system fonts. grace don't use embedded fonts anymore. I don't know for other packages, but indeed trying to use system fonts instead of duplicating them is a worth goal. It always seemed to me that it was a must fix even if it was not ain the guidelines, though. -- Pat From choeger at cs.tu-berlin.de Fri Jul 25 11:20:35 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 25 Jul 2008 13:20:35 +0200 Subject: strace trap tool needed? In-Reply-To: <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> References: <1216943321.3547.16.camel@choeger6> <1216943797.25170.7.camel@clockmaker.usersys.redhat.com> Message-ID: <1216984835.3547.22.camel@choeger6> Am Freitag, den 25.07.2008, 09:56 +1000 schrieb Dave Airlie: > On Fri, 2008-07-25 at 01:48 +0200, Christoph H?ger wrote: > > Hi, > > > > a little tool came up to my mind today: How about the possibility to > > strace a given binary upon execution and write the output to some file? > > That could be easy to do (I've already roughly written the code down), > > so I am not going to make a package of it. > > > > To demonstrate my idea: > > if you invoke the script like: > > > > trap-strace /usr/bin/less -o /tmp/less.strace > > > > after invoking less you cat /tmp/less.strace to see what was going on. > > > > Does anyone else need such a tool? > > If so, what package could collect it, and what constraints (language, > > i/o, etc.) should it comply with? > > > > any reason > > strace -o /tmp/less.strace /usr/bin/less > > won't work? > > Or did I miss something? > > Dave. > well, strace starts the process itself, that is not always usefull. Consider complex scripts or applications that fork-exec alot around. Sometimes you (or, at least I ;) ) just do not want the complete strace with fork() or clone() but just the output of one particular binary in the chain. My tool would set up a trap which invokes strace when the binary is executed (basically you could do that by replacing the binary with a script wrapper). -------------- 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 nicolas.mailhot at laposte.net Fri Jul 25 11:33:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 13:33:01 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <20080725110353.GB4862@free.fr> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> <1216982200.22751.32.camel@rousalka.okg> <20080725110353.GB4862@free.fr> Message-ID: <1216985581.22751.49.camel@rousalka.okg> On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote: > On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: > > > > Frankly, the other font formats are so much less useful than modern font > > formats, the probability someone did creative legal restructuring is > > much lower. Anyway, I've amended the proposal in a less format-oriented version https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages > > The big exception are Type1 fonts but I just hope they can > > die die die (and if the Tex-Gyre situation is fixed and we can use OTF > I don't think this may happen in a while because some very interesting > apps (though not mainstream desktop apps, fortunately) uses type1 > fonts, mostly using t1lib, like xfig, xdvi, grace. Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly. Do we really have so much interecting stuff that depends on Type1 once TEX and GS are out of the way? > > In the meanwhile, it may make sense to add Type1 to the list. > > For tex I believe that it will be too complicated to use the system > fonts. TEX now uses the same formats as everyone else (TTF and OTF). I frankly do not think we can afford (or have the resources) to duplicate megs of fonts in TEX-specific packages. If TEX can not use the fonts in fontconfig directories, it just has to symlink them somewhere it can. Regards, -- Nicolas Mailhot -------------- 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 mjs at clemson.edu Fri Jul 25 11:48:05 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Fri, 25 Jul 2008 07:48:05 -0400 Subject: Scanner woes in F9 In-Reply-To: <1216916945.17031.4.camel@gibraltar.str.redhat.com> References: <1216913883.531.18.camel@valkyrie.localdomain> <1216916945.17031.4.camel@gibraltar.str.redhat.com> Message-ID: <1216986486.4460.36.camel@valkyrie.localdomain> On Thu, 2008-07-24 at 18:29 +0200, Nils Philippsen wrote: > On Thu, 2008-07-24 at 11:38 -0400, Matthew Saltzman wrote: > > I sent this message to fedora-list, but received no reply. I hope > > somebody here knows enough about HAL and/or SANE to help me out. > > > > Apparently, scanner configuration is now handled through HAL rather than > > UDEV, which means I have no idea how to get my scanner set up. > > > > I have an Epson Expression 800 SCSI scanner. It is detected with no > > problem as /dev/sg0 and gets user root, group lp and permissions > > -rw-rw---. So root can see the scanner, but regular users and network > > users can't see it. Changing the permissions to -rw-rw-rw by hand makes > > the scanner accessible to local users, but still not over the LAN. And > > of course, it won't be preserved across reboots. > > > > I added the network IP range to /etc/sane.d/saned.conf and added > > localhost to /etc/sane.d/net.conf, configured /etc/xinetd.d/sane-daemon > > as it was when it worked in F8, and opened port 6566 in the firewall. > > > > Any idea what I'm missing? > > > > I have sane-backends-1.0.19-10.fc9.i386. The HAL configuration for > > scanners is in /usr/share/hal/fdi/policy/10osvendor/19-libsane.fdi. > > Please open a bug report at http://bugzilla.redhat.com against the > sane-backends component and attach the output of "lshal" to the ticket > (don't paste it as comment). https://bugzilla.redhat.com/show_bug.cgi?id=456656 Thanks. > Nils -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Fri Jul 25 13:45:08 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 25 Jul 2008 09:45:08 -0400 Subject: A PackageKit browser plugin In-Reply-To: <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724221741.7a596f3e@solitude.devel.redhat.com> <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> Message-ID: <1216993508.3473.3.camel@localhost.localdomain> On Fri, 2008-07-25 at 00:44 -0800, Jeff Spaleta wrote: > Focusing an interface strickly for users...doesn't help us inteact > with users in a way that actually matters. Users talking among > themselves does not lead to better package quality nor additional > contributor manpower. This is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications. Is it really so hard to see that the use cases and requirements for this are totally different from the pkgdb ? From rnorwood at redhat.com Fri Jul 25 14:09:29 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 25 Jul 2008 10:09:29 -0400 Subject: A PackageKit browser plugin In-Reply-To: <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724221741.7a596f3e@solitude.devel.redhat.com> <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> Message-ID: <20080725100929.3c6d8fa5@solitude.devel.redhat.com> On Fri, 25 Jul 2008 00:44:34 -0800 "Jeff Spaleta" wrote: > On Thu, Jul 24, 2008 at 6:17 PM, Robin Norwood > wrote: > > The target audiences are different. > > If you are driving users to a different site than the package > maintainers... and allowing them to comment...you are going to cause a > communication gap. A driveby commenting and rating system among users > where the maintainers are not encouraged to also interact with...does > nothing to get that feedback to the people who are doing the work. Nor > does it help those of us doing the work figure out which of our users > are worth encouraging to take the next step and start helping. Make > the same site expose specific functionality for users, and > contributors. There's really no reason I should not be able to use > the exact same website to see user comments on my packages...and do > the packagedb interactions which lets me elevate other > contributors/users as co-maintainers on those very same packages. > If i have to go to yet another website to see what users are saying > about my packages, I will most likely end up forgetting to do > it...even though I actually care. > Focusing an interface strickly for users...doesn't help us inteact > with users in a way that actually matters. Users talking among > themselves does not lead to better package quality nor additional > contributor manpower. > > If you want to make a better package browsing interface...great...do > it as an extension to the SAME website that I have to already interact > with to do my ownership/watching packagedb manipulation as a > contributor. I really don't think that a monolithic app is the way to go - serving two masters and all that. OTOH, I'm not trying to build an ivory tower either. I'm already integrating with the rest of the fedora infrastructure to get the package data and FAS. I'm also planning to include easy export of the data. So, for instance, the packagedb could have a 'feed' of comments about a given package. More of a semantic web type idea than an isolated database or a 'one-stop shop'. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From wtogami at redhat.com Fri Jul 25 15:44:06 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 25 Jul 2008 11:44:06 -0400 Subject: Rawhide Orphanarium Purged Message-ID: <4889F4C6.2030000@redhat.com> aasaver AGReader freenx gnome-applet-tvn24 gnome-ppp kbiof lipstik man-pages-da MegaMek nautilus-share sinjdoc system-summary system-switch-java xeuphoric These packages have been removed from rawhide. Please let rel-eng know if you want to revive a retired package. moodss moomps These packages are newly orphans in the last week. If they are not claimed soon they may be removed before F10 beta. Warren Togami wtogami at redhat.com From itamar at ispbrasil.com.br Fri Jul 25 15:47:30 2008 From: itamar at ispbrasil.com.br (Itamar - IspBrasil) Date: Fri, 25 Jul 2008 12:47:30 -0300 Subject: Rawhide Orphanarium Purged In-Reply-To: <4889F4C6.2030000@redhat.com> References: <4889F4C6.2030000@redhat.com> Message-ID: <4889F592.7040404@ispbrasil.com.br> freenx is cool. there are a way to do anything about freenx Warren Togami wrote: > aasaver > AGReader > freenx > gnome-applet-tvn24 > gnome-ppp > kbiof > lipstik > man-pages-da > MegaMek > nautilus-share > sinjdoc > system-summary > system-switch-java > xeuphoric > > These packages have been removed from rawhide. Please let rel-eng > know if you want to revive a retired package. > > moodss > moomps > > These packages are newly orphans in the last week. If they are not > claimed soon they may be removed before F10 beta. > > Warren Togami > wtogami at redhat.com > From bigjoe1008 at gmail.com Fri Jul 25 15:50:56 2008 From: bigjoe1008 at gmail.com (Joe Harnish) Date: Fri, 25 Jul 2008 11:50:56 -0400 Subject: Rawhide Orphanarium Purged In-Reply-To: <4889F592.7040404@ispbrasil.com.br> References: <4889F4C6.2030000@redhat.com> <4889F592.7040404@ispbrasil.com.br> Message-ID: <763fc8580807250850j20ce09fcxfb16d374289f721b@mail.gmail.com> See: https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01062.html On Fri, Jul 25, 2008 at 11:47 AM, Itamar - IspBrasil wrote: > freenx is cool. > > there are a way to do anything about freenx > > > Warren Togami wrote: >> >> aasaver >> AGReader >> freenx >> gnome-applet-tvn24 >> gnome-ppp >> kbiof >> lipstik >> man-pages-da >> MegaMek >> nautilus-share >> sinjdoc >> system-summary >> system-switch-java >> xeuphoric >> >> These packages have been removed from rawhide. Please let rel-eng know if >> you want to revive a retired package. >> >> moodss >> moomps >> >> These packages are newly orphans in the last week. If they are not >> claimed soon they may be removed before F10 beta. >> >> Warren Togami >> wtogami at redhat.com >> > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From oybekfedora at gmail.com Fri Jul 25 16:10:57 2008 From: oybekfedora at gmail.com (Oybek Nuriddinov) Date: Sat, 26 Jul 2008 01:10:57 +0900 Subject: General information About Fedora Message-ID: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> Hello everybody! I have a few questions for you, if you know please fill it. 1.How many decision makers does Fedora have? 2. By whom is Fedora funded? 3. How many members of Fedora 4. Is desktop environment in KDE or in GNOME? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From billcrawford1970 at gmail.com Fri Jul 25 16:15:25 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 25 Jul 2008 17:15:25 +0100 Subject: Rawhide Orphanarium Purged In-Reply-To: <4889F4C6.2030000@redhat.com> References: <4889F4C6.2030000@redhat.com> Message-ID: <544eb990807250915i66f63300sfce3d6f0a02e9063@mail.gmail.com> 2008/7/25 Warren Togami : > lipstik Anyone have any idea how much work would be involved in porting this to KDE4? From jonstanley at gmail.com Fri Jul 25 16:44:14 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 25 Jul 2008 12:44:14 -0400 Subject: General information About Fedora In-Reply-To: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> References: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> Message-ID: 2008/7/25 Oybek Nuriddinov : > Hello everybody! > > I have a few questions for you, if you know please fill it. These questions are pretty off-topic for this list. However, I'm happy to answer them. > 1.How many decision makers does Fedora have? This is a very difficult question. In general, there are two main governance bodies in Fedora - the Fedora Board, and the Fedora Engineering Steering Committee (FESCo). Each of these bodies consist of nine people, and there can be overlap between the two (there is currently one person serving on both FESCo and the Board). The Board consists of 4 seats which are appointed by Red Hat, and 5 elected by the community. FESCo is entirely elected by the community. There is also a Fedora Project Leader (FPL) who serves as chairman of the board, and is required to be a full-time Red Hat employee. This position is currently held by Paul Frields. The mission of the board is to decide strategic direction for Fedora, and the mission of FESCo is to decide technical direction of Fedora. More information about the Board can be found at https://fedoraproject.org/wiki/Board while more information about FESCo can be found at https://fedoraproject.org/wiki/Development/SteeringCommittee Also, various projects within Fedora have their own internal governance models, for example the Ambassadors, have their own elected steering committees. > 2. By whom is Fedora funded? The majority of Fedora's funding comes from Red Hat. However, there are donations of hardware (IBM, Dell), hosting (ServerBeach, Tummy.com to name a few), and other various goods and services. Also, our mirrors are an indirect source of funding by saving Red Hat the bandwidth costs that would otherwise be required in order to distribute Fedora. > 3. How many members of Fedora I'm not sure how you define "members" of Fedora, however, as of the last FESCo election there were approximately 1800 people that had completed the Fedora Contributor License agreement and belonged to at least one other group in the Fedora account system. > 4. Is desktop environment in KDE or in GNOME? The default desktop is GNOME, however there are a large contingent of KDE and Xfce users, and active SIG's around both of those desktop environments. From lordmorgul at gmail.com Fri Jul 25 17:28:09 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 25 Jul 2008 10:28:09 -0700 Subject: A PackageKit browser plugin In-Reply-To: <1216993508.3473.3.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <1216924958.3499.2.camel@localhost.localdomain> <604aa7910807241201s215ef122l341d17721b64c921@mail.gmail.com> <1216927209.10458.103.camel@localhost.localdomain> <604aa7910807241232t40a747b4k4f7b9e5cd9f0e95a@mail.gmail.com> <20080724221741.7a596f3e@solitude.devel.redhat.com> <604aa7910807250144i50c5f0b5tee4d34e02e4d7e20@mail.gmail.com> <1216993508.3473.3.camel@localhost.localdomain> Message-ID: <488A0D29.9070907@gmail.com> Matthias Clasen wrote: > On Fri, 2008-07-25 at 00:44 -0800, Jeff Spaleta wrote: > >> Focusing an interface strickly for users...doesn't help us inteact >> with users in a way that actually matters. Users talking among >> themselves does not lead to better package quality nor additional >> contributor manpower. > > This is not an effort to improve package quality or gain new > contributors. This is an effort to make life of users better. It is not > about packages, but about applications. Is it really so hard to see that > the use cases and requirements for this are totally different from the > pkgdb ? Jeff's point however, is that one web application can, and should, easily accommodate those goals while still exposing a completely different interface to the contributors. Perhaps the argument should be made that no matter where the 'comment database' ends up it... the pkdb interface should be able to show those same comments to the contributors. If a 'different website' is used for the general user to view/rate/install applications that probably works just fine, as long as the contributors do not have to then go find that source of feedback separately. The comments and ratings given on that website could just as easily be accessed/viewed from the pkdb for contributors as well. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From skvidal at fedoraproject.org Fri Jul 25 17:35:44 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 13:35:44 -0400 Subject: Package EVR problems in Fedora 2008-07-21 In-Reply-To: <1216823934.12190.85.camel@localhost.localdomain> References: <20080721200629.58796209D33@releng1.fedora.phx.redhat.com> <20080722224637.c9447568.mschwendt@gmail.com> <1216792233.12190.68.camel@localhost.localdomain> <20080723113240.da7d593a.mschwendt@gmail.com> <1216817288.12190.77.camel@localhost.localdomain> <1216817251.10981.28.camel@rosebud> <1216823934.12190.85.camel@localhost.localdomain> Message-ID: <1217007344.10981.69.camel@rosebud> On Wed, 2008-07-23 at 10:38 -0400, Jesse Keating wrote: > On Wed, 2008-07-23 at 08:47 -0400, seth vidal wrote: > > > > Toshio fixed up pkgdb so I can query the right information via script > > now. I'll get to the pkg-owner at fp.o address stuff this week. > > Rock on Seth, thanks! this is now done. -sv From a.badger at gmail.com Fri Jul 25 06:11:11 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 24 Jul 2008 23:11:11 -0700 Subject: Slight change in how cvs notifications work Message-ID: <48896E7F.9040003@gmail.com> We've had some issues with notification emails being sent on cvs commits. Sometimes generating the list of email addresses to notify was slow, on other occassions it would fail altogether. To alleviate this we've changed from a dynamic determination of who is notified by querying the pkgdb to a static one by sending to an email alias generated from pkgdb information once an hour. There is one major difference (besides speed) to note in this: Before, the owner and people in the watchcommits acls received notifications that a cvs commit was made to a package. Now the owner and people onwatchcommits and watchbugzilla acls are notified. The aliases used to send these messages are all pkg-owner at fedoraproject.org in case you have mail filters you want to setup to handle it. Thank you, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From cdahlin at redhat.com Fri Jul 25 17:39:45 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Fri, 25 Jul 2008 13:39:45 -0400 Subject: CVS/Pkgdb outage Message-ID: <488A0FE1.4000605@redhat.com> Outage Notification - 2008-07-28 01:20 UTC There will be an outage starting at 2008-07-28 01:20 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-07-28 01:20 UTC' Affected Services: PackageDB CVS / Source Control Reason for Outage: Renaming cvsextras group to 'packager' Contact Information: Casey Dahlin Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lb at leenukes.co.uk Fri Jul 25 18:21:16 2008 From: lb at leenukes.co.uk (lb at leenukes.co.uk) Date: Fri, 25 Jul 2008 19:21:16 +0100 (BST) Subject: Fedora 10 Name Suggestion Message-ID: <44932.82.22.124.182.1217010076.squirrel@apollo.krystal.co.uk> My suggestion is Neon as Neon is the 10th element on the Periodic table and Sulphur is also an element. I cannot find any relevant trademark infringements by using this name other then maybe: http://www.neon-project.org/ or the Neon car. From limb at jcomserv.net Fri Jul 25 18:24:44 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 25 Jul 2008 13:24:44 -0500 (CDT) Subject: Fedora 10 Name Suggestion In-Reply-To: <44932.82.22.124.182.1217010076.squirrel@apollo.krystal.co.uk> References: <44932.82.22.124.182.1217010076.squirrel@apollo.krystal.co.uk> Message-ID: <55171.65.195.245.6.1217010284.squirrel@mail.jcomserv.net> > My suggestion is Neon as Neon is the 10th element on the Periodic table > and Sulphur is also an element. > > I cannot find any relevant trademark infringements by using this name > other then maybe: http://www.neon-project.org/ or the Neon car. Already rejected by legal. In fact, voting has already begun. And possibly ended, but I forget the dates. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lb at leenukes.co.uk Fri Jul 25 18:29:48 2008 From: lb at leenukes.co.uk (lb at leenukes.co.uk) Date: Fri, 25 Jul 2008 19:29:48 +0100 (BST) Subject: Fedora 10 Name Suggestion In-Reply-To: <55171.65.195.245.6.1217010284.squirrel@mail.jcomserv.net> References: <44932.82.22.124.182.1217010076.squirrel@apollo.krystal.co.uk> <55171.65.195.245.6.1217010284.squirrel@mail.jcomserv.net> Message-ID: <39596.82.22.124.182.1217010588.squirrel@apollo.krystal.co.uk> Argh, naming is going to get harder in the future. I'll try and find a url for the voting on names, I couldn't find a reference on the wiki, hence my email. Thanks for the prompt reply. > >> My suggestion is Neon as Neon is the 10th element on the Periodic table >> and Sulphur is also an element. >> >> I cannot find any relevant trademark infringements by using this name >> other then maybe: http://www.neon-project.org/ or the Neon car. > > Already rejected by legal. In fact, voting has already begun. And > possibly ended, but I forget the dates. > >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at leemhuis.info Fri Jul 25 18:08:23 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 25 Jul 2008 20:08:23 +0200 Subject: number of Fedora contributer (was: Re: General information About Fedora) In-Reply-To: References: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> Message-ID: <488A1697.3060300@leemhuis.info> On 25.07.2008 18:44, Jon Stanley wrote: > 2008/7/25 Oybek Nuriddinov : >> 3. How many members of Fedora > I'm not sure how you define "members" of Fedora, however, as of the > last FESCo election there were approximately 1800 people that had > completed the Fedora Contributor License agreement and belonged to at > least one other group in the Fedora account system. Just a note: Measurements methods like this are sometimes used in Fedora-land by different people. I'm not completely sure, but Paul for example and *IIRC* mentioned some FAS stats in his "state of the union" talk on Fudcon Boston 2008; some FAS numbers IIRC were also used in the "voter turnout in the board election" discussions on fab-list. I tend to say it's completely wrong and misleading to use those numbers, because - there is no real mechanism that makes sure that all the people in the accounts system are still active. I'm quite sure that there are some "inactive" accounts from people; and also tend to say that is likely there are some accounts from people that tried to became a contributor without succeeding in the end (for example because they found no sponsor) - FAS is used for things that are not specific to Fedora; you IIRC need a FAS account if you want to participate in a fedorahosted project; you need one if you want to edit the wiki; and I accidentally stumbled over the page http://people.redhat.com/lockhart/ols/SVN-tips.html a few days ago. Looks like that everyone that wanted to hand in his paper for OLS had to register in FAS and apply for cla_done and one additional group (there is nothing wrong with using FAS for that IMHO; but it doesn't make those people Fedora contributors...) I even say a few people will highly dislike being counted as Fedora contributer just because they are registered in FAS. Example: I was counted as OpenSuse contributor in the early OpenSuse days just because I had created a account in OpenSuse's FAS-equivalent to get access to their bugzilla. So when Novell a few weeks later made a press release saying "hey, we attracted 1234567 contributes withing four weeks" I was really disappointed because I knew I was one of those, without wanting to be one of those :-/ Cu knurd From mschwendt at gmail.com Fri Jul 25 18:44:05 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 25 Jul 2008 20:44:05 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <48896E7F.9040003@gmail.com> References: <48896E7F.9040003@gmail.com> Message-ID: <20080725204405.eded77b8.mschwendt@gmail.com> On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote: > There is one major difference (besides speed) to note in this: Before, > the owner and people in the watchcommits acls received notifications > that a cvs commit was made to a package. Now the owner and people > onwatchcommits and watchbugzilla acls are notified. So, the separate watchbugzilla now implies watchcommits? Why that change? From dennis at ausil.us Fri Jul 25 18:45:39 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 25 Jul 2008 13:45:39 -0500 Subject: Rawhide Orphanarium Purged In-Reply-To: <4889F4C6.2030000@redhat.com> References: <4889F4C6.2030000@redhat.com> Message-ID: <200807251345.53173.dennis@ausil.us> On Friday 25 July 2008, Warren Togami wrote: > sinjdoc With the removal of sinjdoc gcj now requires openjdk for javadoc. due to a bug its been that way at buildtime for awhile now. but sinjdoc was a Requires and worked for runtime javadoc needs. but now the only javadoc parser is in openjdk. IMO this is bad. -- Dennis Gilmore -------------- 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 jspaleta at gmail.com Fri Jul 25 18:52:03 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jul 2008 14:52:03 -0400 Subject: number of Fedora contributer (was: Re: General information About Fedora) In-Reply-To: <488A1697.3060300@leemhuis.info> References: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> <488A1697.3060300@leemhuis.info> Message-ID: <604aa7910807251152v799f8731gb128045e73d7ea3d@mail.gmail.com> On 7/25/08, Thorsten Leemhuis wrote: > - there is no real mechanism that makes sure that all the people in the > accounts system are still active. I'm quite sure that there are some > "inactive" accounts from people; and also tend to say that is likely there > are some accounts from people that tried to became a contributor without > succeeding in the end (for example because they found no sponsor) I agree that we don't have a mechanism to track 'active' and 'inactive'. I think we should solve that specific question so we can get a better handle on the real manpower growth. I would think we have the ability to at least track sponsored individuals based on a cvs acces flag. But the question of sponsorship is too narrow a definition of what it means to be a contributor. All of this hints as to a larger question.. what does it mean to be a Fedora contributor. It has to mean more than access to the cvs as a package maintainer. We are growing new initiatives outside of what is present in the package collection. Why doesn't contributing to a project of fedorahosted count as contribution under the larger Fedora project umbrella? Just as contributing video screencasts to the re-imagined fedora tv initative? The work that goes on outside the strict definition of the distribution is still important work, and its important for us to be able to point to that work and note that we as a project are providing the space for people to collaborate and get things done. If we can't point to project at fedoraproject as part of a wider sense of sustainable community contribution we can't make the argument that its worth continuing to invest in the colloborative space big enough for something like fedorahosted to be useful. If projects under fedorahosted don't want to stand up and be counted, then we cannot build on the success that is there to extend our community infrastructure into even more areas. What we have to do is be more careful about defining what we mean to contribute and to restate that definition every single time we hand a number out so noone has to attempt to interpret for themselves what that number means. -jef From wtogami at redhat.com Fri Jul 25 19:08:46 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 25 Jul 2008 15:08:46 -0400 Subject: Rawhide Orphanarium Purged In-Reply-To: <200807251345.53173.dennis@ausil.us> References: <4889F4C6.2030000@redhat.com> <200807251345.53173.dennis@ausil.us> Message-ID: <488A24BE.3080308@redhat.com> Dennis Gilmore wrote: > On Friday 25 July 2008, Warren Togami wrote: > >> sinjdoc > With the removal of sinjdoc gcj now requires openjdk for javadoc. due to a > bug its been that way at buildtime for awhile now. but sinjdoc was a Requires > and worked for runtime javadoc needs. but now the only javadoc parser is in > openjdk. IMO this is bad. > This was on the orphan list with repeated warnings for weeks. I'll unblock it now, but someone really needs to take ownership if it is important. Warren Togami wtogami at redhat.com From pemboa at gmail.com Fri Jul 25 19:20:18 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 25 Jul 2008 14:20:18 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> Message-ID: <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> 2008/7/25 yersinia : > On Thu, Jul 24, 2008 at 7:33 PM, Arthur Pemberton wrote: >> >> On Thu, Jul 24, 2008 at 11:29 AM, Jeff Spaleta wrote: >> > On Thu, Jul 24, 2008 at 8:01 AM, Arthur Pemberton >> > wrote: >> >> I suspect the later. The Fedora name probably does little for their >> >> target market. >> > >> > There is the Fedora mark, the Fedora distribution, and the Fedora >> > process. >> > The fedora mark is what I care about most as a Board member >> > The fedora distribution is what I care about most as a user >> > The fedora process is what I care about most as a contributor. >> > >> > If their real goal is to increase contributor involvement then I >> > personally think they need to leverage as much of our process as they >> > can..and not just the bits in the distribution. I want to make sure >> > the moblin people have an adequate understanding of our process, so we >> > can have a discussion concerning whether or not they can align how >> > they do things for cross-pollination of contributor effort. >> > >> >> Most probably. Fedora is pretty restrictive against non-free software >> >> (which I like) but which >> >> isn't exactly aligned with "just work" consumer devices. >> > >> > I looked at the moblin 2 playground site briefly, I'm not sure I see >> > any specific items which are problematic. I believe I even ran into a >> > statement that they are committed to pushing the kernel patches they >> > are generating upstream for review. So they at least appear to 'get >> > it' when it comes to our view of kernel work. >> > http://www.moblin.org/playground/?q=node/23 >> > >> > The current moblin 1 SDK includes the intel compiler, but that not one >> > of the moblin subprojects and i didn't see any specific discussion in >> > the moblin 2 playground. Honestly, we just don't know enough about >> > why they've moved over to be based on Fedora, or how strong the >> > commitment is to a full open moblin 2 stack. There are hints in the >> > moblin 2 playground pages, but I do not trust articles to always get >> > motivations and intents correctly prioritized. Dirk's blog seems to >> > indicate he's been using F8 and F9 on an EEE machine, so its not a >> > completely blind jump. >> > >> > -jef >> >> >> What are your thoughts on the reason given? RPM had one feature that >> was needed. But from what I've heard/read from others, RPM is lacking >> many other features (better compression methods for example). RPM has >> been (seemingly) pretty stagnant. > > Let me respond on this point. Probably i am the wrong person to tell this > but rpm4.6, in rawhide, have now lzma payload support via liblzma. Suse > rpm4.4.2.xxxxx have the same support, so have, from more time along iirc, > rpm5.org. > > Regards Okay. Thanks for the further info on this. Maybe the RPM devs need to have the marketing team whip up an anti FUD campaign. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From paulds at bu.edu Fri Jul 25 19:34:43 2008 From: paulds at bu.edu (Paul Stauffer) Date: Fri, 25 Jul 2008 15:34:43 -0400 Subject: Fedora 10 Name Suggestion In-Reply-To: <39596.82.22.124.182.1217010588.squirrel@apollo.krystal.co.uk> References: <44932.82.22.124.182.1217010076.squirrel@apollo.krystal.co.uk> <55171.65.195.245.6.1217010284.squirrel@mail.jcomserv.net> <39596.82.22.124.182.1217010588.squirrel@apollo.krystal.co.uk> Message-ID: <20080725193443.GB17839@cs.bu.edu> On Fri, Jul 25, 2008 at 07:29:48PM +0100, lb at leenukes.co.uk wrote: > Argh, naming is going to get harder in the future. I'll try and find a url > for the voting on names, I couldn't find a reference on the wiki, hence my > email. https://admin.fedoraproject.org/voting Voting is active through Monday night UTC. cheers, - Paul -- Paul Stauffer Manager of Research Computing Computer Science Department Boston University From gnomeuser at gmail.com Fri Jul 25 19:37:11 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 25 Jul 2008 21:37:11 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> Message-ID: <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> 2008/7/25 Arthur Pemberton > 2008/7/25 yersinia : > > On Thu, Jul 24, 2008 at 7:33 PM, Arthur Pemberton > wrote: > >> > >> On Thu, Jul 24, 2008 at 11:29 AM, Jeff Spaleta > wrote: > >> > On Thu, Jul 24, 2008 at 8:01 AM, Arthur Pemberton > >> > wrote: > >> >> I suspect the later. The Fedora name probably does little for their > >> >> target market. > >> > > >> > There is the Fedora mark, the Fedora distribution, and the Fedora > >> > process. > >> > The fedora mark is what I care about most as a Board member > >> > The fedora distribution is what I care about most as a user > >> > The fedora process is what I care about most as a contributor. > >> > > >> > If their real goal is to increase contributor involvement then I > >> > personally think they need to leverage as much of our process as they > >> > can..and not just the bits in the distribution. I want to make sure > >> > the moblin people have an adequate understanding of our process, so we > >> > can have a discussion concerning whether or not they can align how > >> > they do things for cross-pollination of contributor effort. > >> > > >> >> Most probably. Fedora is pretty restrictive against non-free software > >> >> (which I like) but which > >> >> isn't exactly aligned with "just work" consumer devices. > >> > > >> > I looked at the moblin 2 playground site briefly, I'm not sure I see > >> > any specific items which are problematic. I believe I even ran into a > >> > statement that they are committed to pushing the kernel patches they > >> > are generating upstream for review. So they at least appear to 'get > >> > it' when it comes to our view of kernel work. > >> > http://www.moblin.org/playground/?q=node/23 > >> > > >> > The current moblin 1 SDK includes the intel compiler, but that not one > >> > of the moblin subprojects and i didn't see any specific discussion in > >> > the moblin 2 playground. Honestly, we just don't know enough about > >> > why they've moved over to be based on Fedora, or how strong the > >> > commitment is to a full open moblin 2 stack. There are hints in the > >> > moblin 2 playground pages, but I do not trust articles to always get > >> > motivations and intents correctly prioritized. Dirk's blog seems to > >> > indicate he's been using F8 and F9 on an EEE machine, so its not a > >> > completely blind jump. > >> > > >> > -jef > >> > >> > >> What are your thoughts on the reason given? RPM had one feature that > >> was needed. But from what I've heard/read from others, RPM is lacking > >> many other features (better compression methods for example). RPM has > >> been (seemingly) pretty stagnant. > > > > Let me respond on this point. Probably i am the wrong person to tell > this > > but rpm4.6, in rawhide, have now lzma payload support via liblzma. Suse > > rpm4.4.2.xxxxx have the same support, so have, from more time along iirc, > > rpm5.org. > > > > Regards > > Okay. Thanks for the further info on this. Maybe the RPM devs need to > have the marketing team whip up an anti FUD campaign. 2 words that will save a lot of time in a debate with such fudders, "Evidence Please", watch how they automatically discredit themselves as uninformed trolls who completely misunderstand the burden of proof. It is not up to us to counter FUD, it is up to them to prove the truth of their argument. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Fri Jul 25 19:38:55 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 15:38:55 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> Message-ID: <1217014735.10981.79.camel@rosebud> On Fri, 2008-07-25 at 21:37 +0200, David Nielsen wrote: > > 2 words that will save a lot of time in a debate with such fudders, > "Evidence Please", watch how they automatically discredit themselves > as uninformed trolls who completely misunderstand the burden of proof. > It is not up to us to counter FUD, it is up to them to prove the truth > of their argument. > To be fair yum and rpm have not done a good enough job publicizing useful and interesting changes/features in the last couple of years. There have been a lot. -sv From pemboa at gmail.com Fri Jul 25 19:49:08 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 25 Jul 2008 14:49:08 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <1217014735.10981.79.camel@rosebud> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> <1217014735.10981.79.camel@rosebud> Message-ID: <16de708d0807251249p3b5df697u9d6d3746590d3842@mail.gmail.com> On Fri, Jul 25, 2008 at 2:38 PM, seth vidal wrote: > On Fri, 2008-07-25 at 21:37 +0200, David Nielsen wrote: > >> >> 2 words that will save a lot of time in a debate with such fudders, >> "Evidence Please", watch how they automatically discredit themselves >> as uninformed trolls who completely misunderstand the burden of proof. >> It is not up to us to counter FUD, it is up to them to prove the truth >> of their argument. >> > > To be fair yum and rpm have not done a good enough job publicizing > useful and interesting changes/features in the last couple of years. > > There have been a lot. > > -sv I try my best to follow this list, and the last major RPM related thread that I remember was mostly a debate between the current RPM and RPM5. Either way, glad to see things are progressing. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From gnomeuser at gmail.com Fri Jul 25 19:50:55 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 25 Jul 2008 21:50:55 +0200 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <1217014735.10981.79.camel@rosebud> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> <1217014735.10981.79.camel@rosebud> Message-ID: <1dedbbfc0807251250xd3367d7k377f9dae84074f11@mail.gmail.com> 2008/7/25 seth vidal > On Fri, 2008-07-25 at 21:37 +0200, David Nielsen wrote: > > > > > 2 words that will save a lot of time in a debate with such fudders, > > "Evidence Please", watch how they automatically discredit themselves > > as uninformed trolls who completely misunderstand the burden of proof. > > It is not up to us to counter FUD, it is up to them to prove the truth > > of their argument. > > > > To be fair yum and rpm have not done a good enough job publicizing > useful and interesting changes/features in the last couple of years. > > There have been a lot. I am not suggesting we shouldn't advertise our improvements but there are certain arguments and people not worth our time. Spending time countering every single misinformed RPM/YUM argument out there is probably not as good an investment in time as asking said people to provide evidence for their claims. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Fri Jul 25 19:48:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 15:48:51 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <16de708d0807251249p3b5df697u9d6d3746590d3842@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> <1217014735.10981.79.camel@rosebud> <16de708d0807251249p3b5df697u9d6d3746590d3842@mail.gmail.com> Message-ID: <1217015331.10981.81.camel@rosebud> On Fri, 2008-07-25 at 14:49 -0500, Arthur Pemberton wrote: > On Fri, Jul 25, 2008 at 2:38 PM, seth vidal wrote: > > On Fri, 2008-07-25 at 21:37 +0200, David Nielsen wrote: > > > >> > >> 2 words that will save a lot of time in a debate with such fudders, > >> "Evidence Please", watch how they automatically discredit themselves > >> as uninformed trolls who completely misunderstand the burden of proof. > >> It is not up to us to counter FUD, it is up to them to prove the truth > >> of their argument. > >> > > > > To be fair yum and rpm have not done a good enough job publicizing > > useful and interesting changes/features in the last couple of years. > > > > There have been a lot. > > > > -sv > > > I try my best to follow this list, and the last major RPM related > thread that I remember was mostly a debate between the current RPM and > RPM5. Either way, glad to see things are progressing. This is not the list where rpm-devel goes on. rpm-maint at rpm.org is that list. better yet, follow the git repo checkins. -sv From skvidal at fedoraproject.org Fri Jul 25 19:53:57 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 15:53:57 -0400 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <1dedbbfc0807251250xd3367d7k377f9dae84074f11@mail.gmail.com> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> <1217014735.10981.79.camel@rosebud> <1dedbbfc0807251250xd3367d7k377f9dae84074f11@mail.gmail.com> Message-ID: <1217015637.10981.84.camel@rosebud> On Fri, 2008-07-25 at 21:50 +0200, David Nielsen wrote: > > I am not suggesting we shouldn't advertise our improvements but there > are certain arguments and people not worth our time. Spending time > countering every single misinformed RPM/YUM argument out there is > probably not as good an investment in time as asking said people to > provide evidence for their claims. > > Maybe so - but I think I can do a better job of explaining what things are getting better in yum. Here's a good example of things getting better in yum by a smartpm user: http://lists.labix.org/pipermail/smart-labix.org/2008-July/003662.html -sv From pemboa at gmail.com Fri Jul 25 19:58:29 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 25 Jul 2008 14:58:29 -0500 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <1217015331.10981.81.camel@rosebud> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <16de708d0807240901i5ec3ca03v83c137a9a2d9cf59@mail.gmail.com> <604aa7910807240929k2d641832s28ec8919a15df3e7@mail.gmail.com> <16de708d0807241033k4b321abbyf50d403d0cd79017@mail.gmail.com> <16de708d0807251220x350caa3fs2e2681c9f8fe0d26@mail.gmail.com> <1dedbbfc0807251237g34b991d9m75695f317127d091@mail.gmail.com> <1217014735.10981.79.camel@rosebud> <16de708d0807251249p3b5df697u9d6d3746590d3842@mail.gmail.com> <1217015331.10981.81.camel@rosebud> Message-ID: <16de708d0807251258x39945f0ahe64a0171afa817df@mail.gmail.com> On Fri, Jul 25, 2008 at 2:48 PM, seth vidal wrote: > On Fri, 2008-07-25 at 14:49 -0500, Arthur Pemberton wrote: >> On Fri, Jul 25, 2008 at 2:38 PM, seth vidal wrote: >> > On Fri, 2008-07-25 at 21:37 +0200, David Nielsen wrote: >> > >> >> >> >> 2 words that will save a lot of time in a debate with such fudders, >> >> "Evidence Please", watch how they automatically discredit themselves >> >> as uninformed trolls who completely misunderstand the burden of proof. >> >> It is not up to us to counter FUD, it is up to them to prove the truth >> >> of their argument. >> >> >> > >> > To be fair yum and rpm have not done a good enough job publicizing >> > useful and interesting changes/features in the last couple of years. >> > >> > There have been a lot. >> > >> > -sv >> >> >> I try my best to follow this list, and the last major RPM related >> thread that I remember was mostly a debate between the current RPM and >> RPM5. Either way, glad to see things are progressing. > > This is not the list where rpm-devel goes on. rpm-maint at rpm.org is that > list. > > better yet, follow the git repo checkins. Merci -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From a.badger at gmail.com Fri Jul 25 20:43:19 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 25 Jul 2008 13:43:19 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080725204405.eded77b8.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> Message-ID: <488A3AE7.1030100@gmail.com> Michael Schwendt wrote: > On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote: > >> There is one major difference (besides speed) to note in this: Before, >> the owner and people in the watchcommits acls received notifications >> that a cvs commit was made to a package. Now the owner and people >> onwatchcommits and watchbugzilla acls are notified. > > So, the separate watchbugzilla now implies watchcommits? Why that change? > Possibly oversight or possibly removing a wart. Here was my reasoning: We have a lot of things that want to send notification when a change occurs to a package. This includes: bugzilla pkgdb (acl changes) cvs commits bodhi koji various reports: broken deps, broken upgrade, fails to rebuild, etc When the packageDB started I wasn't envisioning all of those uses and the list of notifications is only growing over time. So what should we do? We can add more watch* acls to the db and the interface. Or we can glom onto existing acls -- but if I want to get reports from bodhi, do I need to sign up for watchcommits or watchbugzilla? Or does it depend on the commit acl? Looking at this problem I didn't see any difference between bugzilla, cvs, and bodhi, or koji. So pruning the list of watch* acls with the goal of consolidating on a single acl for notification seems to make sense. OTOH, I haven't done any coding towards this in the core of pkgdb, just made the new notifylist give out the list of usernames in owner, watchcommit, watchbugzilla. If you could come up with criteria to use to determine what makes a good watch* acl (or revamping the system even further), we can make changes. With a list of what is suitable for having its own watch* acl we could have multiple aliases that match up with the acls that meet those criteria. -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 jwboyer at gmail.com Sat Jul 26 00:17:24 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 25 Jul 2008 20:17:24 -0400 Subject: Rawhide Orphanarium Purged In-Reply-To: <200807251345.53173.dennis@ausil.us> References: <4889F4C6.2030000@redhat.com> <200807251345.53173.dennis@ausil.us> Message-ID: <20080725201724.50faf9b2@zod.rchland.ibm.com> On Fri, 25 Jul 2008 13:45:39 -0500 Dennis Gilmore wrote: > On Friday 25 July 2008, Warren Togami wrote: > > > sinjdoc > With the removal of sinjdoc gcj now requires openjdk for javadoc. due to a > bug its been that way at buildtime for awhile now. but sinjdoc was a Requires > and worked for runtime javadoc needs. but now the only javadoc parser is in > openjdk. IMO this is bad. Why is that bad? josh From abartlet at samba.org Sat Jul 26 00:30:15 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 26 Jul 2008 10:30:15 +1000 Subject: Rawhide Orphanarium Purged In-Reply-To: <4889F4C6.2030000@redhat.com> References: <4889F4C6.2030000@redhat.com> Message-ID: <1217032215.4646.15.camel@ruth> On Fri, 2008-07-25 at 11:44 -0400, Warren Togami wrote: > nautilus-share The purpose of this tool is to make it easier to share folders with windows clients (using Samba) - users get the ability to share their own folders. It is sad to see it so unloved, but it really needs to be part of the default configuration of the Samba deamon (as having to edit the smb.conf is the part it was trying to avoid). It would be nice to see a Fedora owner for it again some day, them maybe Samba won't be the target of the linux-hater as much :-) http://linuxhaters.blogspot.com/2008/07/of-silos-and-samba.html (I think this tool got written when SuSE was working really hard on making this stuff 'just work' for their distribution). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jan.kratochvil at redhat.com Sat Jul 26 04:02:52 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 26 Jul 2008 06:02:52 +0200 Subject: [PATCH] cross-compilation for binutils. In-Reply-To: <1215269547.10393.848.camel@pmac.infradead.org> References: <1215258444.3189.87.camel@shinybook.infradead.org> <87od5csda6.fsf@sheridan.bigo.ensc.de> <1215264745.10393.837.camel@pmac.infradead.org> <87k5g0s9p0.fsf@sheridan.bigo.ensc.de> <1215269547.10393.848.camel@pmac.infradead.org> Message-ID: <20080726040252.GA12270@host0.dyn.jankratochvil.net> Hi David, made some minor updates upon yours: * Fixed the testsuite run for cross-builds. * Fixed omitted --with-sysroot for the cross-builds. * Replaced --with-sysroot /usr with %{_prefix}. * Fixed %if F-10 rpm compatibility. OK to commit it for Rawhide? Regards, Jan -------------- next part -------------- --- ./binutils.spec 16 Jul 2008 18:39:54 -0000 1.134 +++ ./binutils.spec 26 Jul 2008 03:48:29 -0000 @@ -1,7 +1,19 @@ +# rpmbuild parameters: +# --define "binutils_target arm-linux-gnu" to create arm-linux-gnu-binutils. +# --without testsuite: Do not run the testsuite. Default is to run it. + +%if 0%{!?binutils_target:1} +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.18.50.0.6 -Release: 4%{?dist} +Release: 5%{?dist} License: GPLv3+ Group: Development/Tools URL: http://sources.redhat.com/binutils @@ -54,7 +66,7 @@ have a stable ABI. Developers starting to consider using libelf instead of BFD. %prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -68,7 +80,7 @@ to consider using libelf instead of BFD. %patch7 -p0 -b .version~ %patch8 -p0 -b .pclmul~ -# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i\[3-7\]86/i[34567]86/g' */conf* @@ -80,38 +92,65 @@ sed -i -e 's/^libbfd_la_LDFLAGS = /&-Wl, sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +# $PACKAGE is used for the gettext catalog name. +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure +# Undo the name change to run the testsuite. +for tool in binutils gas ld +do + sed -i -e "2aDEJATOOL = $tool" $tool/Makefile.am + sed -i -e "s/^DEJATOOL = .*/DEJATOOL = $tool/" $tool/Makefile.in +done %build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +echo target is %{binutils_target} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux -%endif +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS="--enable-64-bit-bfd" + ;; + ia64*) + CARGS="--enable-targets=i386-linux" + ;; +esac +# We could optimize the cross builds size by --enable-shared but the produced +# binaries may be less convenient in the embedded environment. CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ +%if %{isnative} + %{binutils_target} \ + --enable-shared \ +%else + --target %{binutils_target} --enable-targets=%{_host} \ + --disable-shared \ + --with-sysroot=%{_prefix}/%{binutils_target}/sys-root \ +%endif + $CARGS \ + --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror \ + --infodir=%{_infodir} --disable-werror \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info +%if 0%{?_without_testsuite:1} +echo ====================TESTSUITE DISABLED========================= +%else make -k check < /dev/null > check.log 2>&1 || : echo ====================TESTING========================= cat check.log echo ====================TESTING END===================== cd .. +%endif %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %{isnative} make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info* @@ -141,10 +180,6 @@ rm -f %{buildroot}%{_prefix}/%{_lib}/lib # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la -# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include ~;}' \ %ifarch %{ix86} x86_64 @@ -162,22 +197,36 @@ sed -i -e '/^#include "ansidecl.h"/{p;s~ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h +%else # !%{isnative} +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +# We keep these as one can have native + cross binutils of different versions. +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # !%{isnative} + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +rm -rf %{buildroot}%{_prefix}/%{binutils_target} + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang %clean rm -rf %{buildroot} +%if %{isnative} %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -208,12 +257,14 @@ exit 0 if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # %{isnative} -%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if %{isnative} %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -223,8 +274,15 @@ fi %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # %{isnative} %changelog +* Sat Jul 26 2008 Jan Kratochvil 2.18.50.0.6-5 +- Add %%{binutils_target} macro to support building cross-binutils. + (David Woodhouse) +- Support `--without testsuite' to suppress the testsuite run. +- Refresh the patchset with fuzz 0 (for new rpmbuild). + * Wed Jul 16 2008 Jan Kratochvil 2.18.50.0.6-4 - include the `dist' tag in the Release number - libbfd.a symbols visibility is now hidden (for #447426, suggested by Jakub) --- ./binutils-2.18.50.0.6-place-orphan.patch 4 Apr 2008 09:48:39 -0000 1.1 +++ ./binutils-2.18.50.0.6-place-orphan.patch 26 Jul 2008 03:48:29 -0000 @@ -2,8 +2,8 @@ * emulparams/elf64ppc.sh (OTHER_GOT_RELOC_SECTIONS): Add .rela.opd. ---- ld/emulparams/elf64ppc.sh.jj 2003-07-28 10:24:45.000000000 -0400 -+++ ld/emulparams/elf64ppc.sh 2003-08-05 08:35:58.000000000 -0400 +--- ld/emulparams/elf64ppc.sh 2007-03-16 16:48:30.000000000 +0100 ++++ ld/emulparams/elf64ppc.sh 2008-07-25 20:11:20.000000000 +0200 @@ -28,7 +28,8 @@ else .toc 0 : { *(.toc) }" fi @@ -12,5 +12,5 @@ + .rela.toc ${RELOCATING-0} : { *(.rela.toc) } + .rela.opd ${RELOCATING-0} : { *(.rela.opd) }" OTHER_READWRITE_SECTIONS=" - .toc1 ${RELOCATING-0}${RELOCATING+ALIGN(8)} : { *(.toc1) } - .opd ${RELOCATING-0}${RELOCATING+ALIGN(8)} : { KEEP (*(.opd)) }" + .toc1 ${RELOCATING-0} :${RELOCATING+ ALIGN(8)} { *(.toc1) } + .opd ${RELOCATING-0} :${RELOCATING+ ALIGN(8)} { KEEP (*(.opd)) } From martin.langhoff at gmail.com Sat Jul 26 04:25:09 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 26 Jul 2008 16:25:09 +1200 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> I am using a F9 host to build a F7 liveCD -- the School Server image -- and I am finding that livecd-creator never manages to unmount the temporary partition, and the resulting image fails to boot (tested with qemu and on real hw). When livecd-creator tries to unmount the CD, two processes are still running - httpd, and a custom network daemon written in python. lsof shows them as the only processes keeping files open. Once I kill those processes, I can unmount cleanly. Is this expected? Are any incompatibilities with F7 known? Should livecd-creator try to run all the relevant init scripts with stop, and perhaps run lsof to see if any programs need to be killed or kill-9'ed? The boot failures (fails to load the kernel modules, and kills init) probably have to do with the image being incomplete. This is the kickstart file I am using... http://dev.laptop.org/git?p=projects/xs-livecd;a=blob;f=kickstarts/livecd-auto.ks;h=4dd17a317501701464f6e880ad0ba708145fd1ba;hb=HEAD cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From debarshi.ray at gmail.com Sat Jul 26 05:44:40 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 26 Jul 2008 11:14:40 +0530 Subject: General information About Fedora In-Reply-To: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> References: <7bb426480807250910k1b8829k3513da215543694a@mail.gmail.com> Message-ID: <3170f42f0807252244j7852f6e0r6fae50cb4ca582de@mail.gmail.com> > I have a few questions for you, if you know please fill it. > > 1.How many decision makers does Fedora have? > 2. By whom is Fedora funded? > 3. How many members of Fedora > 4. Is desktop environment in KDE or in GNOME? Much of this information is publicly available. Looks like you are too lazy to find them yourself. Regards, Debarshi From martin.langhoff at gmail.com Sat Jul 26 06:21:21 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 26 Jul 2008 18:21:21 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> Message-ID: <46a038f90807252321r5ca3cb4wd9f16ef682a2ecd9@mail.gmail.com> On Sat, Jul 26, 2008 at 4:25 PM, Martin Langhoff wrote: > I am using a F9 host to build a F7 liveCD -- the School Server image > -- and I am finding that livecd-creator never manages to unmount the > temporary partition, and the resulting image fails to boot (tested > with qemu and on real hw). With a bit more work into it, I can resolve the unmounting issue by stopping the daemons late in %post, however, the boot failures continue. They look like this: Loading vmlinuz0... Loading initrd0.img... Ready. Uncompressing Linux... Ok, booting the kernel. PCI: PIIX3L Enabling Passive Release on 0000"00:01.0 Red Hat nash version 6.0.9 starting insmod: error inserting '/lib/ehci-hcd.ko' : -1 File exists insmod: error inserting '/lib/uhci-hcd.ko' : -1 File exists insmod: error inserting '/lib/ohci-hcd.ko' : -1 File exists stabilized: stat /proc/bus/usb/devices: No such file or directory ... and eventually ... Kernel panic - non syncing: Attempted to kill init! Any hints as to what to try next, doco or source to read? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From debarshi.ray at gmail.com Sat Jul 26 07:20:11 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 26 Jul 2008 12:50:11 +0530 Subject: Fedora, meet OLPC. OLPC, meet Fedora. In-Reply-To: References: Message-ID: <3170f42f0807260020u5b7fd322u306b2159b4f0bb53@mail.gmail.com> > Did you know that the OLPC project is the largest single "customer" of > Fedora in the entire world? > > [...] > > OLPC has shipped over 300,000 units to kids around the world. They plan to > ship at least another 50,000 more each month, and very likely more than > that. It's entirely possible that by the end of 2008, there will be a > million OLPC systems deployed worldwide. > > Of those systems, 100% of them currently run Fedora, and 0% of them > currently run Windows -- despite the press clippings you may have read. > > The OLPC project is based on Fedora. Do the machines shipped by the OLPC project contribute towards Smolt statistics? I could not locate them under the vendor tag on http://www.smolts.org/static/stats/stats.html Cheers, Debarshi From mschwendt at gmail.com Sat Jul 26 07:55:17 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 26 Jul 2008 09:55:17 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <488A3AE7.1030100@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> Message-ID: <20080726095517.e3461f45.mschwendt@gmail.com> On Fri, 25 Jul 2008 13:43:19 -0700, Toshio Kuratomi wrote: > Michael Schwendt wrote: > > On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote: > > > >> There is one major difference (besides speed) to note in this: Before, > >> the owner and people in the watchcommits acls received notifications > >> that a cvs commit was made to a package. Now the owner and people > >> onwatchcommits and watchbugzilla acls are notified. > > > > So, the separate watchbugzilla now implies watchcommits? Why that change? > > > Possibly oversight or possibly removing a wart. Here was my reasoning: > > We have a lot of things that want to send notification when a change > occurs to a package. This includes: > > bugzilla > pkgdb (acl changes) > cvs commits > bodhi > koji > various reports: > broken deps, broken upgrade, fails to rebuild, etc > > When the packageDB started I wasn't envisioning all of those uses and > the list of notifications is only growing over time. So what should we > do? We can add more watch* acls to the db and the interface. Or we can > glom onto existing acls -- but if I want to get reports from bodhi, do I > need to sign up for watchcommits or watchbugzilla? Or does it depend on > the commit acl? Comments in bodhi are similar to comments in bugzilla and ought to be delivered via watchbugzilla. Not everyone who gives negative karma also opens a ticket in bugzilla. New update notifications in bodhi are more like a commit [to a repo] and therefore should be posted to watchcommits. Helpful for collaboration. Koji notifications tell whether a package built successfully, which is like a commit to the repo, and ought to be forwarded to watchcommits. OTOH, if someone requests watchbugzilla access only, receiving all cvs commits is unexpected. Especially as long as the watchcommits acl is a separate opt-in. It's not called "watchpkg" unless you plan to take your consolidation into that direction. > Looking at this problem I didn't see any difference between bugzilla, > cvs, and bodhi, or koji. So pruning the list of watch* acls with the > goal of consolidating on a single acl for notification seems to make sense. Whether it makes sense depends on the original definition of the several watch* options. watchbugzilla as a fine-grained choice appeared helpful, because bugzilla itself doesn't offer such a feature (monitoring other email addresses increases the spam). watchbugzilla is different. It's like "I depend on Foo, so I want to learn about bug reports regarding Foo". Instead, you want to submit also all cvs commits, which quickly increases the email traffic an observer has to process (minor updates, cosmetical spec changes, commits with no immediate build). This gives reason to worry. Maintainers are said to be flooded with bugzilla spam already. With a change of the pkgdb watch* acls, co-maintainers could not opt-out from some of the notifications (only with filtering on their own). From mschwendt at gmail.com Sat Jul 26 08:49:00 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 26 Jul 2008 10:49:00 +0200 Subject: Hunspell ABI breakage Message-ID: <20080726104900.c769ad67.mschwendt@gmail.com> With hunspell-1.2.4.2-2.fc10 the ABI changed and broke Enchant. I've bumped and rebuilt Enchant already, but other packages may need a rebuild, too. $ repoquery --whatrequires libhunspell-1.2.so.0 | sort enchant-1:1.4.2-3.fc10.i386 hunspell-0:1.2.4.2-2.fc10.i386 hunspell-devel-0:1.2.4.2-2.fc10.i386 openoffice.org-core-1:3.0.0-0.0.27.1.fc10.i386 sunbird-0:0.8-4.fc10.i386 thunderbird-lightning-0:0.8-4.fc10.i386 From rawhide at fedoraproject.org Sat Jul 26 08:54:28 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 26 Jul 2008 08:54:28 +0000 (UTC) Subject: rawhide report: 20080726 changes Message-ID: <20080726085429.0F73215005D@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080725/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080726/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package calamaris Squid native log format (NLF) analyzer and report generator New package merkaartor QT-Based OpenStreetMap editor New package python-mwlib MediaWiki conversion library for Python Removed package AGReader Removed package MegaMek Removed package aasaver Removed package fonts-arabic Removed package fonts-hebrew Removed package fonts-japanese Removed package freenx Removed package gnome-applet-tvn24 Removed package gnome-ppp Removed package kbiof Removed package kernel-xen-2.6 Removed package lipstik Removed package man-pages-da Removed package nautilus-share Removed package system-summary Removed package system-switch-java Removed package xeuphoric Updated Packages: anaconda-11.4.1.20-1 -------------------- * Fri Jul 25 18:00:00 2008 Chris Lumens - 11.4.1.20-1 - Clean up some mistakes in the minstg2 removal. (dcantrell) - Fix passing the language to anaconda (katzj) asterisk-1.6.0-0.19.beta9.fc10 ------------------------------ * Fri Jul 25 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.19.beta9 - Add patch pulled from upstream SVN that fixes AST-2008-010 and AST-2008-011. * Fri Jul 25 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.18.beta9 - Add patch for LDAP extracted from upstream SVN (#442011) evolution-rss-0.1.0-2.fc10 -------------------------- * Thu Jul 24 18:00:00 2008 Lucian Langa - 0.1.0-2 - Fix firefox import RH bug #452322 filezilla-3.1.0.1-1.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.0.1-1 - Update to 3.1.0.1 firmware-addon-dell-1.4.8-2.fc10 -------------------------------- firmware-tools-1.5.6-2.fc10 --------------------------- gnome-settings-daemon-2.23.5-3.fc10 ----------------------------------- * Fri Jul 25 18:00:00 2008 Matthias Clasen - 2.23.5-3 - Use standard icon names in the volume OSD * Fri Jul 25 18:00:00 2008 - Bastien Nocera - 2.23.5-2 - Fix build, call gtk-update-icon-cache as required * Thu Jul 24 18:00:00 2008 Soren Sandmann - 2.23.5-1 - Update to 2.23.5 gperiodic-2.0.10-4.fc10 ----------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 2.0.10-4 - fix license tag granule-1.3.0-2.fc10 -------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 1.3.0-2 - fix license tag grep-2.5.1-60.fc10 ------------------ * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 2.5.1-60 - fix license tag gsf-sharp-0.8.1-8.fc10 ---------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 0.8.1-8 - fix license tag gshutdown-0.2-4.fc10 -------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 0.2-4 - fix license tag gtk-doc-1.10-2.fc10 ------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 1.10-2 - fix license tag gtk-murrine-engine-0.53.1-3.fc10 -------------------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 0.53.1-3 - fix license tag gtkglarea2-1.99.0-9.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 1.99.0-9 - fix license tag gtkglextmm-1.2.0-7.fc10 ----------------------- * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 1.2.0-7 - fix license tag intltool-0.40.3-1.fc10 ---------------------- * Fri Jul 25 18:00:00 2008 Matthias Clasen - 0.40.3-1 - Update to 0.40.3 jakarta-commons-lang-2.3-2.3.fc10 --------------------------------- * Thu Jul 24 18:00:00 2008 Andrew Overholt 0:2.3-2.3 - Add OSGi MANIFEST.MF kdebindings-4.1.0-4.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Than Ngo 4.1.0-2 - respun * Fri Jul 25 18:00:00 2008 Kevin Kofler 4.1.0-4 - fix Python and Ruby bindings overwriting each other (#456722, kde#167450) * Fri Jul 25 18:00:00 2008 Kevin Kofler 4.1.0-3 - drop unneeded BR kdegraphics4-devel (Ruby Okular bindings disabled by default) - add BR kdepimlibs-devel for Python Akonadi bindings kdegraphics-4.1.0-2.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Than Ngo 4.1.0-2 - respun kdenetwork-4.1.0-2.fc10 ----------------------- * Fri Jul 25 18:00:00 2008 Than Ngo 4.1.0-2 - respun klamav-0.44-2.fc10 ------------------ * Sun Jul 20 18:00:00 2008 Andy Shevchenko 0.44-2 - update to 0.44 - bump clamav requirements to have their at least for 0.93 - remove upstreamed patches libcanberra-0.4-1.fc10 ---------------------- * Fri Jul 25 18:00:00 2008 Lennart Poettering 0.4-1 - New version - Install libcanberra-gtk-module.sh libgnome-2.23.4-2.fc10 ---------------------- * Fri Jul 25 18:00:00 2008 - Bastien Nocera - 2.23.4-2 - Remove the "esound by default" patch, it's obsoleted by changes in gnome-settings-daemon - Add patch to support the new sound theme XSettings libgweather-2.23.5-2 -------------------- * Fri Jul 25 18:00:00 2008 Matthias Clasen 2.23.5-2 - Fix pending request accounting libmusicbrainz3-3.0.1-3.fc10 ---------------------------- * Fri Jul 25 18:00:00 2008 Rex Dieter 3.0.1-3 - fix recursive linking against libdiscid neon liferea-1.4.17-1.fc10 --------------------- * Thu Jul 24 18:00:00 2008 Steven M. Parrish - 1.4.17-1 - New upstream release ocsinventory-1.02-0.6.rc2.fc10 ------------------------------ * Tue Jul 22 18:00:00 2008 Remi Collet 1.02-0.6.rc2 - add missing requires perl(SOAP::Transport::HTTP2) (with mod_perl2) - AddDefaultCharset ISO-8859-1 in httpd config - fix SElinux path openoffice.org-voikko-3.0-0.1.pre4.fc10 --------------------------------------- * Fri Jul 25 18:00:00 2008 Ville-Pekka Vainio - 3.0-0.1.pre4 - New pre-release - License changed to GPLv3+ - Require openoffice.org >= 3.0.0 - Drop unneeded 3 layer patch - Build with new SHOW_UGLY_WARNINGS=1 option as this is a test release perl-Catalyst-Manual-5.7013-1.fc10 ---------------------------------- * Fri Jul 25 18:00:00 2008 Chris Weyl - update to 5.7013 - don't just exclude Catalyst::Manual's man page, but the .pm as well. (RH BZ#455151) phpMyAdmin-2.11.8-0.1.fc10 -------------------------- * Fri Jul 25 18:00:00 2008 Robert Scheck 2.11.8-0.1 - Upstream released 2.11.8-rc1 (#456637) publican-0.34-0.fc10 -------------------- python-alsa-1.0.17-1.fc10 ------------------------- * Fri Jul 25 18:00:00 2008 Andy Shevchenko - 1.0.17-1 - update to release 1.0.17 python-lxml-2.1.1-1.fc10 ------------------------ * Fri Jul 25 18:00:00 2008 Jeffrey C. Ollie - 2.1.1-1 - Update to 2.1.1 pytrainer-1.5.0.0.1-6.fc10 -------------------------- s3cmd-0.9.8.2-1.fc10.1 ---------------------- * Fri Jul 25 18:00:00 2008 Lubomir Rintel (Good Data) - 0.9.8.2-1.1 - Fix a typo selinux-policy-3.5.1-3.fc10 --------------------------- setup-2.7.1-1.fc10 ------------------ * Fri Jul 25 18:00:00 2008 Phil Knirsch 2.7.1-1 - Bump to 2.7.1 to avoid version problems with F-9 - Removed group news as well (#437462) tcl-8.5.3-1.fc10 ---------------- * Fri Jul 25 18:00:00 2008 Marcela Maslanova - 1:8.5.3-1 - update to 8.5.3 - create vers macro for provides, obsoletes tcl-html-8.5.3-1.fc10 --------------------- telepathy-butterfly-0.3.2-1.fc10 -------------------------------- * Sun Jul 20 18:00:00 2008 Brian Pepple - 0.3.2-1 - Update to 0.3.2. tk-8.5.3-1.fc10 --------------- * Fri Jul 25 18:00:00 2008 Marcela Maslanova - 1:8.5.3-1 - update to 8.5.3 wireshark-1.0.2-2.fc10 ---------------------- * Thu Jul 17 18:00:00 2008 Steve Dickson 1.0.2-2 - Added patches to support NFSv4.1 zenon-0.5.0-3.fc10 ------------------ Summary: Added Packages: 3 Removed Packages: 17 Modified Packages: 44 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From chitlesh.goorah at gmail.com Sat Jul 26 09:06:35 2008 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sat, 26 Jul 2008 11:06:35 +0200 Subject: Retiring compat-guile-16 Message-ID: <50baabb30807260206j55c66d91k435a2d0c837e45c9@mail.gmail.com> Hello there, None of my packages is using compat-guile-16. Guile 1.8 is now widely used, instead of guile 1.6. Thus I'm retiring compat-guile-16 on rawhide, next week. Any objections ? Kind Regards, Chitlesh From promac at gmail.com Sat Jul 26 11:28:39 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Sat, 26 Jul 2008 08:28:39 -0300 Subject: Fn+F8 and laptop keys Message-ID: <68720af30807260428l15844d1dy876b55546a7fb05f@mail.gmail.com> Hi, I have had some problems for making my laptop special keys to work. First of all, hall-info from F8 is not updated. In my case, a Dell owner, the file /usr/share/hal/fdi/information/10freedesktop/30-keymap-dell.fdi is divided based on Dell models (very few). The current hall-info has only one configuration for all models. Anyway, fixing the keymap made all my keys working: Fn+F1 hibernate Fn+F3 battery status (just show the status once, a second hit does not show anything. Why?) and all the multimedia keys. This is good, because there is no need to include setkeycodes in /etc/rc.local. The only key that is really not working is the Fn+F8, to switch between the LCD and an external monitor. Although I have e00b:displaytoggle in my file, it does not make any difference at all. If I press Fn+F8, dmesg gives me: atkbd.c: Unknown key pressed (translated set 2, code 0x8b on isa0060/serio0). atkbd.c: Use 'setkeycodes e00b ' to make it known. Therefore, the key is not mapped. Well, I tried mapping it to 214 (XF86Video), 227, etc ... and no joy. I have an nvidia 8400 GS card. If during the boot I press Fn+F8 before entering X, I can switch to the external monitor, but I cannot go back to the laptop LCD. I tried the nv and the nvidia binary driver in xorg.conf. Using the nv driver, the login screen appears on both, LCD+monitor, but after loging in, only the external monitor is active. Using the binary driver, not even that, the login screen appears onto only one. I saw some posts about using xrandr for this purpose: http://ubuntuforums.org/archive/index.php/t-634675.html My question is: is it possible to switch using an nvidia card on Fedora? Would xrandr work? I also think that an updated hall-info for F8 is in order. It would be really nice if those keys worked just out of the box. This is the type of issue that is very difficult to fix without some knowledge, and makes users look for other distros. In fact, switching to an external monitor is essential for presentations using a projector. Since I wiped out my Vista OS, I do not even know if switching worked on Windows for my Vostro 1400. Any suggestion will be really welcome, and sorry if this is the wrong list (I guess not). Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwheeler at dwheeler.com Sat Jul 26 14:04:13 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Sat, 26 Jul 2008 10:04:13 -0400 (EDT) Subject: pushing yum 3.2.17-2 back to f8 (Tim Lauridsen) In-Reply-To: <20080725103818.82B24619FC2@hormel.redhat.com> References: <20080725103818.82B24619FC2@hormel.redhat.com> Message-ID: > > On Tue, 22 Jul 2008 12:03:00 -0400, seth vidal wrote: > >> I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. > >> It speeds things up a fair bit and it also fixes a number of minor-ish > >> bugs. However, it also pulls in a few new deps. What are folks thoughts > >> on this? Please do. I think it's especially important to support Fedora 8, because people who use Xen domain0 _cannot_ upgrade to Fedora 9. --- David A. Wheeler From arjan at infradead.org Sat Jul 26 15:21:09 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sat, 26 Jul 2008 08:21:09 -0700 Subject: Intel moves moblin MIDs from Ubuntu to Fedora! In-Reply-To: <48893163.7070900@fedoraproject.org> References: <5256d0b0807231459s17a31fe0o3d75f3dcd282b1ba@mail.gmail.com> <604aa7910807231717x7344f0aep85fc86733205b3e@mail.gmail.com> <48883EB4.7040100@hhs.nl> <604aa7910807240846sa5940e4xd2fb9a7b73ab9c6e@mail.gmail.com> <20080724135349.27064bf4@infradead.org> <48893163.7070900@fedoraproject.org> Message-ID: <20080726082109.10e90c73@infradead.org> On Fri, 25 Jul 2008 07:20:27 +0530 Rahul Sundaram wrote: > Arjan van de Ven wrote: > > also if you need help feel also free to contact me; for one Dirk > > sits on the other side of a cube wall from me, and for another I'm > > also more or less involved in Moblin 2.0 > > It would be nice if you can get someone from Intel to talk and tell > us what's their plan beyond tidbits we have been getting from the > press. What can Fedora as a project do to interface better? first of all, by no means believe everything you read in the press; a lot of that is just made up by the journalists. second, a lot of the questions I've seen here have a "eh we don't know yet" as answer.... but I'll get some folks together so that the right person will engage.. -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From skvidal at fedoraproject.org Sat Jul 26 15:55:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 26 Jul 2008 11:55:51 -0400 Subject: pushing yum 3.2.17-2 back to f8 (Tim Lauridsen) In-Reply-To: References: <20080725103818.82B24619FC2@hormel.redhat.com> Message-ID: <1217087751.10981.113.camel@rosebud> On Sat, 2008-07-26 at 10:04 -0400, David A. Wheeler wrote: > > > On Tue, 22 Jul 2008 12:03:00 -0400, seth vidal wrote: > > >> I've been debating a bit pushing yum 3.2.17-2 as an update back to f8. > > >> It speeds things up a fair bit and it also fixes a number of minor-ish > > >> bugs. However, it also pulls in a few new deps. What are folks thoughts > > >> on this? > > Please do. I think it's especially important to support Fedora 8, because > people who use Xen domain0 _cannot_ upgrade to Fedora 9. > 3.2.17 is in updates-testing for f8, now. please add karma if it works for you. thanks, -sv From buildsys at fedoraproject.org Sat Jul 26 16:31:38 2008 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 26 Jul 2008 16:31:38 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 Message-ID: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> Broken upgrade path report for tags f8-final -> dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing -> dist-f10: AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) abiword: dist-f8-updates-testing > dist-f9-updates (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) augeas: dist-f8-updates-testing > dist-f9-updates (augeas-0.2.2-1.fc8 augeas-0.2.1-1.fc9) bluez-libs: dist-f8-updates-testing > dist-f9-updates (bluez-libs-3.35-1.fc8 bluez-libs-3.32-1.fc9) bluez-utils: dist-f8-updates-testing > dist-f9-updates (bluez-utils-3.35-3.fc8 bluez-utils-3.32-1.fc9) bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) bzr-gtk: dist-f8-updates-testing > dist-f9-updates (bzr-gtk-0.94.0-5.fc8 bzr-gtk-0.94.0-2.fc9) chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) collectl: dist-f8-updates-testing > dist-f9-updates (collectl-3.0.0-1.fc8 collectl-2.6.4-1.fc9) cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) decibel-audio-player: dist-f8-updates-testing > dist-f9-updates (decibel-audio-player-0.10-2.fc8 decibel-audio-player-0.10-1.fc9) driftnet: dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) ext3grep: dist-f8-updates-testing > dist-f9-updates (ext3grep-0.7.0-1.fc8 ext3grep-0.6.0-1.fc9) ez-ipupdate: dist-f8-updates-testing > dist-f9-updates (ez-ipupdate-3.0.11-0.19.b8.fc8 ez-ipupdate-3.0.11-0.18.b8.fc9) flashrom: dist-f8-updates-testing > dist-f9-updates (flashrom-0-0.11.20080607svn3418.fc8 flashrom-0-0.9.20080517svn3332.fc9) gamazons: dist-f8-updates-testing > dist-f9-updates (gamazons-0.83-3.fc8 gamazons-0.83-2.fc9) gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) gyachi: dist-f8-updates-testing > dist-f9-updates (gyachi-1.1.35-16.fc8 gyachi-1.1.35-6.fc9) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-6.fc9 ipa-1.1.0-2.fc10) iptables: dist-f8-updates-testing > dist-f9-updates (iptables-1.4.1.1-2.fc8 iptables-1.4.1.1-1.fc9) jna: dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) kde-filesystem: dist-f9-updates-testing > dist-f10 (kde-filesystem-4-17.fc9 kde-filesystem-4-16.fc10) keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) nautilus-sendto: dist-f8-updates-testing > dist-f9-updates (nautilus-sendto-1.0.1-1.fc8 nautilus-sendto-1.0.0-1.fc9) nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) notification-daemon-engine-nodoka: dist-f8-updates-testing > dist-f9-updates (notification-daemon-engine-nodoka-0.1.0-3.fc8 notification-daemon-engine-nodoka-0.1.0-2.fc9) ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-static: dist-f8-updates-testing > dist-f9-updates (ocaml-json-static-0.9.6-5.fc8 ocaml-json-static-0.9.6-4.fc9) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-openin: dist-f8-updates-testing > dist-f9-updates (ocaml-openin-20070524-4.fc8 ocaml-openin-20070524-3.fc9) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-pa-monad: dist-f8-updates-testing > dist-f9-updates (ocaml-pa-monad-1.2.0-5.fc8 ocaml-pa-monad-1.2.0-4.fc9) ocaml-pgocaml: dist-f8-updates-testing > dist-f9-updates (ocaml-pgocaml-1.1-3.fc8 ocaml-pgocaml-1.1-2.fc9) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) pcmanfm: dist-f8-updates-testing > dist-f9-updates (pcmanfm-0.5-1.fc8 pcmanfm-0.4.6.2-1.fc9) perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) pinot: dist-f8-updates-testing > dist-f9-updates (pinot-0.87-1.fc8 pinot-0.86-1.fc9) podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) python-fedora: dist-f8-updates-testing > dist-f9-updates (python-fedora-0.3.3-1.fc8 python-fedora-0.2.99.11.1-1.fc9) python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) qlandkarte: dist-f8-updates-testing > dist-f9-updates (qlandkarte-0.7.3-1.fc8 qlandkarte-0.7.2-1.fc9) rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) rubygem-activeldap: dist-f8-updates-testing > dist-f9-updates (rubygem-activeldap-1.0.1-1.fc8 rubygem-activeldap-0.10.0-10.fc9) rubygem-hoe: dist-f8-updates-testing > dist-f9-updates (rubygem-hoe-1.7.0-1.fc8 rubygem-hoe-1.5.1-5.fc9) samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) strigi: dist-f8-updates-testing > dist-f9-updates (strigi-0.5.11-1.fc8 strigi-0.5.9-2.fc9) syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) tellico: dist-f8-updates-testing > dist-f9-updates (tellico-1.3.3-1.fc8 tellico-1.3.2.1-1.fc9) thunar-shares: dist-f8-updates-testing > dist-f9-updates (thunar-shares-0.16-1.fc8 thunar-shares-0.12-1.fc9) thunderbird: dist-f8-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc8 thunderbird-2.0.0.14-1.fc10) dist-f9-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc9 thunderbird-2.0.0.14-1.fc10) vala: dist-f8-updates-testing > dist-f9-updates (vala-0.3.4-2.fc8 vala-0.3.4-1.fc9) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) xenner: dist-f8-updates-testing > dist-f9-updates (xenner-0.41-1.fc8 xenner-0.37-1.fc9) xfce4-screenshooter-plugin: dist-f8-updates-testing > dist-f9-updates (xfce4-screenshooter-plugin-1.3.1-1.fc8 xfce4-screenshooter-plugin-1.2.0-1.fc9) xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) ----------------------- Broken paths by builder: abompard: keepassx: dist-f8-updates > dist-f10 (keepassx-0.3.2-1.fc8 keepassx-0.3.1-1.fc10) dist-f9-updates > dist-f10 (keepassx-0.3.2-1.fc9 keepassx-0.3.1-1.fc10) ajax: xorg-x11-drv-nv: dist-f9-updates > dist-f10 (xorg-x11-drv-nv-2.1.10-1.fc9 xorg-x11-drv-nv-2.1.8-2.fc10) alcapcom: eclipse-rpm-editor: dist-f8-updates > dist-f9-updates (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc9) dist-f8-updates > dist-f10 (eclipse-rpm-editor-0.4.0-3.fc8 eclipse-rpm-editor-0.4.0-1.fc10) ausil: xorg-x11-drv-geode: dist-f9-updates-testing > dist-f10 (xorg-x11-drv-geode-2.10.0-1.fc9 xorg-x11-drv-geode-2.9.0-2.fc10) awjb: claws-mail: dist-f8-updates > dist-f10 (claws-mail-3.5.0-1.fc8 claws-mail-3.4.0-1.fc10) dist-f9-updates > dist-f10 (claws-mail-3.5.0-1.fc9 claws-mail-3.4.0-1.fc10) claws-mail-plugins: dist-f8-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc8 claws-mail-plugins-3.4.0-1.fc10.1) dist-f9-updates > dist-f10 (claws-mail-plugins-3.5.0-1.fc9 claws-mail-plugins-3.4.0-1.fc10.1) caillon: gtkmozembedmm: dist-f8-updates > dist-f9-updates (gtkmozembedmm-1.4.2.cvs20060817-22.fc8 gtkmozembedmm-1.4.2.cvs20060817-20.fc9) openvrml: dist-f8-updates > dist-f9-updates (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc9) dist-f8-updates > dist-f10 (openvrml-0.17.6-6.fc8 openvrml-0.17.6-2.fc10) thunderbird: dist-f8-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc8 thunderbird-2.0.0.14-1.fc10) dist-f9-updates-testing > dist-f10 (thunderbird-2.0.0.16-1.fc9 thunderbird-2.0.0.14-1.fc10) cweyl: perl-Catalyst-Plugin-CGI-Untaint: dist-f8-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc8 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) dist-f9-updates > dist-f10 (perl-Catalyst-Plugin-CGI-Untaint-0.05-4.fc9 perl-Catalyst-Plugin-CGI-Untaint-0.05-3.fc10) cwickert: thunar-shares: dist-f8-updates-testing > dist-f9-updates (thunar-shares-0.16-1.fc8 thunar-shares-0.12-1.fc9) xfce4-screenshooter-plugin: dist-f8-updates-testing > dist-f9-updates (xfce4-screenshooter-plugin-1.3.1-1.fc8 xfce4-screenshooter-plugin-1.2.0-1.fc9) drago01: gnome-packagekit: dist-f9-updates-testing > dist-f10 (gnome-packagekit-0.2.3-7.fc9 gnome-packagekit-0.2.3-4.20080618.fc10) pinot: dist-f8-updates-testing > dist-f9-updates (pinot-0.87-1.fc8 pinot-0.86-1.fc9) dwheeler: zenon: dist-f8-updates > dist-f9-updates (zenon-0.5.0-2.1.fc8 zenon-0.5.0-2.fc9) gd: samba: dist-f9-updates > dist-f10 (samba-3.2.0-2.17.fc9 samba-3.2.0-1.rc2.16.fc10) ghosler: gyachi: dist-f8-updates-testing > dist-f9-updates (gyachi-1.1.35-16.fc8 gyachi-1.1.35-6.fc9) hadess: bluez-libs: dist-f8-updates-testing > dist-f9-updates (bluez-libs-3.35-1.fc8 bluez-libs-3.32-1.fc9) nautilus-sendto: dist-f8-updates-testing > dist-f9-updates (nautilus-sendto-1.0.1-1.fc8 nautilus-sendto-1.0.0-1.fc9) jamatos: tellico: dist-f8-updates-testing > dist-f9-updates (tellico-1.3.3-1.fc8 tellico-1.3.2.1-1.fc9) james: python-urlgrabber: dist-f8-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc8 python-urlgrabber-3.0.0-8.fc10) dist-f9-updates > dist-f10 (python-urlgrabber-3.0.0-9.fc9 python-urlgrabber-3.0.0-8.fc10) jlayton: ez-ipupdate: dist-f8-updates-testing > dist-f9-updates (ez-ipupdate-3.0.11-0.19.b8.fc8 ez-ipupdate-3.0.11-0.18.b8.fc9) kkofler: strigi: dist-f8-updates-testing > dist-f9-updates (strigi-0.5.11-1.fc8 strigi-0.5.9-2.fc9) kraxel: xenner: dist-f8-updates-testing > dist-f9-updates (xenner-0.41-1.fc8 xenner-0.37-1.fc9) lutter: augeas: dist-f8-updates-testing > dist-f9-updates (augeas-0.2.2-1.fc8 augeas-0.2.1-1.fc9) mcepl: syncevolution: dist-f8-updates > dist-f10 (syncevolution-0.7-3.fc8 syncevolution-0.7-2.fc10) dist-f9-updates > dist-f10 (syncevolution-0.7-3.fc9 syncevolution-0.7-2.fc10) mcpierce: rubygem-activeldap: dist-f8-updates-testing > dist-f9-updates (rubygem-activeldap-1.0.1-1.fc8 rubygem-activeldap-0.10.0-10.fc9) rubygem-hoe: dist-f8-updates-testing > dist-f9-updates (rubygem-hoe-1.7.0-1.fc8 rubygem-hoe-1.5.1-5.fc9) mjakubicek: ext3grep: dist-f8-updates-testing > dist-f9-updates (ext3grep-0.7.0-1.fc8 ext3grep-0.6.0-1.fc9) mmahut: pyephem: dist-f8-updates > dist-f10 (pyephem-3.7.2.3-2.fc8 pyephem-3.7.2.3-1.fc10) mrsam: bootconf: dist-f9-updates > dist-f10 (bootconf-1.3-1.fc9 bootconf-1.3-1) mso: notification-daemon-engine-nodoka: dist-f8-updates-testing > dist-f9-updates (notification-daemon-engine-nodoka-0.1.0-3.fc8 notification-daemon-engine-nodoka-0.1.0-2.fc9) mtasaka: pcmanfm: dist-f8-updates-testing > dist-f9-updates (pcmanfm-0.5-1.fc8 pcmanfm-0.4.6.2-1.fc9) nigelj: podsleuth: dist-f9-updates > dist-f10 (podsleuth-0.6.0-6.fc9 podsleuth-0.6.0-5.fc10) nsantos: rhm: dist-f8-updates > dist-f10 (rhm-0.2.2153-2.fc8 rhm-0.2.2060-3.fc10) dist-f9-updates > dist-f10 (rhm-0.2.2153-2.fc9 rhm-0.2.2060-3.fc10) orion: GMT: dist-f8-updates > dist-f9-updates (GMT-4.3.1-2.fc8 GMT-4.3.1-1.fc9) GMT-coastlines: dist-f8-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) dist-f9-updates > dist-f10 (GMT-coastlines-1.10-1 GMT-coastlines-1.9-3) otaylor: hippo-canvas: dist-f9-updates-testing > dist-f10 (hippo-canvas-0.3.0-2.fc9 hippo-canvas-0.2.34-1.fc10) pbrobinson: geoclue: dist-f8-updates > dist-f10 (geoclue-0.11.1-8.fc8 geoclue-0.11.1-6.fc10) dist-f9-updates > dist-f10 (geoclue-0.11.1-10.fc9 geoclue-0.11.1-6.fc10) peter: flashrom: dist-f8-updates-testing > dist-f9-updates (flashrom-0-0.11.20080607svn3418.fc8 flashrom-0-0.9.20080517svn3332.fc9) pwouters: driftnet: dist-f8-updates > dist-f10 (driftnet-0.1.6-19.20040426cvs.fc8 driftnet-0.1.6-17.20040426cvs.fc10) rcritten: mod_nss: dist-f9-updates > dist-f10 (mod_nss-1.0.7-9.fc9 mod_nss-1.0.7-8.fc10) rdieter: cmucl: dist-f8-updates > dist-f10 (cmucl-19e-1.fc8 cmucl-19e-0.3.pre2.fc10) dist-f9-updates > dist-f10 (cmucl-19e-1.fc9 cmucl-19e-0.3.pre2.fc10) k3b: dist-f8-updates > dist-f10 (k3b-1.0.5-3.fc8 k3b-1.0.5-2.fc10) dist-f9-updates > dist-f10 (k3b-1.0.5-3.fc9 k3b-1.0.5-2.fc10) kde-filesystem: dist-f9-updates-testing > dist-f10 (kde-filesystem-4-17.fc9 kde-filesystem-4-16.fc10) libcapseo: dist-f9-updates > dist-f10 (libcapseo-0.2.0-0.1.20080603gita6ec446.fc9 libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10) sbcl: dist-f8-updates > dist-f10 (sbcl-1.0.17-3.fc8 sbcl-1.0.17-2.fc10) dist-f9-updates > dist-f10 (sbcl-1.0.17-3.fc9 sbcl-1.0.17-2.fc10) rhughes: PackageKit: dist-f9-updates-testing > dist-f10 (PackageKit-0.2.3-6.fc9 PackageKit-0.2.3-4.20080618.fc10) hal-info: dist-f8-updates > dist-f9-updates (hal-info-20080607-2.fc8 hal-info-20080607-1.fc9) dist-f8-updates > dist-f10 (hal-info-20080607-2.fc8 hal-info-20080607-1.fc10) rishi: decibel-audio-player: dist-f8-updates-testing > dist-f9-updates (decibel-audio-player-0.10-2.fc8 decibel-audio-player-0.10-1.fc9) rjones: ocaml-bitstring: dist-f8-updates-testing > dist-f9-updates-testing (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc9) dist-f8-updates-testing > dist-f10 (ocaml-bitstring-1.9.7-2.fc8 ocaml-bitstring-1.9.7-1.fc10) ocaml-deriving: dist-f8-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc8 ocaml-deriving-0.1.1a-3.fc10) dist-f9-updates > dist-f10 (ocaml-deriving-0.1.1a-4.fc9 ocaml-deriving-0.1.1a-3.fc10) ocaml-gsl: dist-f8-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc8 ocaml-gsl-0.6.0-3.fc10) dist-f9-updates > dist-f10 (ocaml-gsl-0.6.0-4.fc9 ocaml-gsl-0.6.0-3.fc10) ocaml-json-static: dist-f8-updates-testing > dist-f9-updates (ocaml-json-static-0.9.6-5.fc8 ocaml-json-static-0.9.6-4.fc9) ocaml-json-wheel: dist-f9-updates-testing > dist-f10 (ocaml-json-wheel-1.0.4-6.fc9 ocaml-json-wheel-1.0.4-5.fc10) ocaml-openin: dist-f8-updates-testing > dist-f9-updates (ocaml-openin-20070524-4.fc8 ocaml-openin-20070524-3.fc9) ocaml-ounit: dist-f8-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc8 ocaml-ounit-1.0.2-2.fc10) dist-f9-updates > dist-f10 (ocaml-ounit-1.0.2-3.fc9 ocaml-ounit-1.0.2-2.fc10) ocaml-pa-monad: dist-f8-updates-testing > dist-f9-updates (ocaml-pa-monad-1.2.0-5.fc8 ocaml-pa-monad-1.2.0-4.fc9) ocaml-pgocaml: dist-f8-updates-testing > dist-f9-updates (ocaml-pgocaml-1.1-3.fc8 ocaml-pgocaml-1.1-2.fc9) ocaml-res: dist-f8-updates > dist-f10 (ocaml-res-2.2.5-3.fc8 ocaml-res-2.2.5-1.fc10) dist-f9-updates > dist-f10 (ocaml-res-2.2.5-3.fc9 ocaml-res-2.2.5-1.fc10) virt-top: dist-f8-updates-testing > dist-f10 (virt-top-1.0.1-4.fc8 virt-top-1.0.1-2.fc10) dist-f9-updates > dist-f10 (virt-top-1.0.1-4.fc9 virt-top-1.0.1-2.fc10) salimma: gamazons: dist-f8-updates-testing > dist-f9-updates (gamazons-0.83-3.fc8 gamazons-0.83-2.fc9) vala: dist-f8-updates-testing > dist-f9-updates (vala-0.3.4-2.fc8 vala-0.3.4-1.fc9) sereinit: gbrainy: dist-f8-updates > dist-f9-updates (gbrainy-0.70-3.fc8 gbrainy-0.70-1.fc9) sharkcz: collectl: dist-f8-updates-testing > dist-f9-updates (collectl-3.0.0-1.fc8 collectl-2.6.4-1.fc9) qlandkarte: dist-f8-updates-testing > dist-f9-updates (qlandkarte-0.7.3-1.fc8 qlandkarte-0.7.2-1.fc9) simo: ipa: dist-f8-updates > dist-f10 (ipa-1.1.0-3.fc8 ipa-1.1.0-2.fc10) dist-f9-updates > dist-f10 (ipa-1.1.0-4.fc9 ipa-1.1.0-2.fc10) dist-f9-updates-testing > dist-f10 (ipa-1.1.0-6.fc9 ipa-1.1.0-2.fc10) sindrepb: cowbell: dist-f9-updates > dist-f10 (cowbell-0.3-0.svn34.4.2.fc9 cowbell-0.3-0.svn34.4.fc10) spot: AcetoneISO2: dist-f8-updates > dist-f9-updates (AcetoneISO2-2.0.2-4.fc8 AcetoneISO2-2.0.2-3.fc9) logjam: dist-f8-updates > dist-f9-updates (1:logjam-4.5.3-24.fc8.1 1:logjam-4.5.3-23.fc9) stalwart: ecore: dist-f8-updates > dist-f9-updates (ecore-0.9.9.042-4.fc8 ecore-0.9.9.042-3.fc9) steved: nfs-utils-lib: dist-f9-updates > dist-f10 (nfs-utils-lib-1.1.1-5.fc9 nfs-utils-lib-1.1.1-4.fc10) stransky: chmsee: dist-f9-updates > dist-f10 (chmsee-1.0.1-4.fc9 chmsee-1.0.1-3.fc10) toshio: bzr-gtk: dist-f8-updates-testing > dist-f9-updates (bzr-gtk-0.94.0-5.fc8 bzr-gtk-0.94.0-2.fc9) python-fedora: dist-f8-updates-testing > dist-f9-updates (python-fedora-0.3.3-1.fc8 python-fedora-0.2.99.11.1-1.fc9) twoerner: iptables: dist-f8-updates-testing > dist-f9-updates (iptables-1.4.1.1-2.fc8 iptables-1.4.1.1-1.fc9) uwog: abiword: dist-f8-updates-testing > dist-f9-updates (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) walters: jna: dist-f8-updates > dist-f10 (jna-3.0.2-8.fc8 jna-3.0.2-7.fc10) wwoods: bluez-utils: dist-f8-updates-testing > dist-f9-updates (bluez-utils-3.35-3.fc8 bluez-utils-3.32-1.fc9) --------------- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD From jkeating at redhat.com Sat Jul 26 16:38:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jul 2008 12:38:47 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> Message-ID: <1217090327.6624.0.camel@localhost.localdomain> On Sat, 2008-07-26 at 16:31 +0000, buildsys at fedoraproject.org wrote: > Broken upgrade path report for tags f8-final -> dist-f8-updates -> > dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing > -> dist-f10: This now sends mail to A) the people who built the offending build, and B) the people who own or watch the package itself. Please let me know if you run into issues with this. It is not yet automated, that will come soon when I'm happy that it's not overly spammy. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 s-t-rhbugzilla at wwwdotorg.org Sat Jul 26 17:02:06 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Sat, 26 Jul 2008 11:02:06 -0600 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> Message-ID: <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> buildsys at fedoraproject.org wrote: > Broken upgrade path report for tags f8-final -> dist-f8-updates > -> dist-f8-updates-testing -> dist-f9-updates > -> dist-f9-updates-testing -> dist-f10: Shouldn't dist-f9-final (or whatever the correct name is) be inserted in this path list between dist-f8-updates-testing and dist-f9-updates. Whilst it's hard to fix such issues (it'd require one to block the specific update from F8 and rebuild, or re-issue the F9 initial release!), it'd still be useful to let people know that they made a mistake, so they learn not to do it next time. I guess for F10, having dist-10 in the list will prevent this happening for the initial F10 release, which means people using the release CD won't see any issues even before they apply updates, which is good. Thanks for the work on this, BTW. From a.badger at gmail.com Sat Jul 26 17:38:11 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 26 Jul 2008 10:38:11 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080726095517.e3461f45.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> Message-ID: <488B6103.7030500@gmail.com> Michael Schwendt wrote: > On Fri, 25 Jul 2008 13:43:19 -0700, Toshio Kuratomi wrote: > >> Michael Schwendt wrote: >>> On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote: >>> >>>> There is one major difference (besides speed) to note in this: Before, >>>> the owner and people in the watchcommits acls received notifications >>>> that a cvs commit was made to a package. Now the owner and people >>>> onwatchcommits and watchbugzilla acls are notified. >>> So, the separate watchbugzilla now implies watchcommits? Why that change? >>> >> Possibly oversight or possibly removing a wart. Here was my reasoning: >> >> We have a lot of things that want to send notification when a change >> occurs to a package. This includes: >> >> bugzilla >> pkgdb (acl changes) >> cvs commits >> bodhi >> koji >> various reports: >> broken deps, broken upgrade, fails to rebuild, etc >> >> When the packageDB started I wasn't envisioning all of those uses and >> the list of notifications is only growing over time. So what should we >> do? We can add more watch* acls to the db and the interface. Or we can >> glom onto existing acls -- but if I want to get reports from bodhi, do I >> need to sign up for watchcommits or watchbugzilla? Or does it depend on >> the commit acl? > > Comments in bodhi are similar to comments in bugzilla and ought to be > delivered via watchbugzilla. Not everyone who gives negative karma > also opens a ticket in bugzilla. > > New update notifications in bodhi are more like a commit [to a repo] > and therefore should be posted to watchcommits. Helpful for collaboration. > The answer to: "What acl do I need to know what's going on with this package's updates" becomes "watchcommits and watchbugzilla" which is decidedly confusing. > Koji notifications tell whether a package built successfully, which > is like a commit to the repo, and ought to be forwarded to watchcommits. > > OTOH, if someone requests watchbugzilla access only, receiving all cvs > commits is unexpected. Especially as long as the watchcommits acl is a > separate opt-in. It's not called "watchpkg" unless you plan to take > your consolidation into that direction. > So this is kinda the question I'm asking... do people here think taking things in the direction of a single watchpkg makes sense? If so, that's the next step in this... merging watchbugzilla and watchcommits into a single watchpkg acl. OTOH, if there is significant value in having separate notification acls then I think we need to have separate acls for most everything. (A side note: I don't think we can control koji, unfortunately. I think it uses its own idea of pkg owners coupled with who submitted a build to send out notification) >> Looking at this problem I didn't see any difference between bugzilla, >> cvs, and bodhi, or koji. So pruning the list of watch* acls with the >> goal of consolidating on a single acl for notification seems to make sense. > > Whether it makes sense depends on the original definition of the > several watch* options. > > watchbugzilla as a fine-grained choice appeared helpful, because > bugzilla itself doesn't offer such a feature (monitoring other email > addresses increases the spam). watchbugzilla is different. It's like > "I depend on Foo, so I want to learn about bug reports regarding > Foo". Instead, you want to submit also all cvs commits, which quickly > increases the email traffic an observer has to process (minor updates, > cosmetical spec changes, commits with no immediate build). This gives > reason to worry. Maintainers are said to be flooded with bugzilla spam > already. With a change of the pkgdb watch* acls, co-maintainers could > not opt-out from some of the notifications (only with filtering on > their own). > This makes sense. Now, how do we make this general? For instance, if we're worried about the level of bugzilla mail, adding bodhi comments to the watchbugzilla acl becomes less attractive. Also the names don't imply anything about what other things will be attached to the acl... we should either rename the acl to encompass those things or split out separate acls for them. After we solve the criteria issue, we have to solve the UI issue: making more acls makes the current UI more and more cluttered. I've been thinking that we want to have a single button for most things. If you're not yet a maintainer of the package you see this: = Simple view = Package: qa-assistant _/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______ Active Releases: F-8 F-9 devel Role: (o) Just Watch Package (_) Help Develop Package (_) Full Co-Maintainership [view advanced] = Advanced View = Package: qa-assistant _/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______ _/*F-8*\_F-9_\_devel_\_________ Acls: Req Apprv [X] [X] watch commits [X] [_] watch bugzilla [X] [X] watch updates [_] [_] Commit [_] [_] Update [_] [_] Approve Acl Requests [simple view] Maintainers would see something similar to the current view but they will also have a simple approval queue (from the /users/ space) (Note, this needs more work): Approval Queue: abadger requests qa-assistant [X] watch bugzilla [X] commit [X] update [ ] approve acl requests [Approve Request] [Deny Request] [...] [Approve all Requests] I've got to get together with a UI designer to work out whether I'm on the right track but something like this will definitely be needed if we keep adding acls. -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 kevin.kofler at chello.at Sat Jul 26 22:16:02 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 26 Jul 2008 22:16:02 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> Message-ID: Stephen Warren wwwdotorg.org> writes: > buildsys fedoraproject.org wrote: > > Broken upgrade path report for tags f8-final -> dist-f8-updates > > -> dist-f8-updates-testing -> dist-f9-updates > > -> dist-f9-updates-testing -> dist-f10: > > Shouldn't dist-f9-final (or whatever the correct name is) be inserted > in this path list between dist-f8-updates-testing and dist-f9-updates. dist-f8-updates (and dist-f8-updates-testing even more so) will ALWAYS have some packages with higher EVRs than dist-f9, this is normal and unavoidable, how else would you suggest to backport a new version of a package which wasn't in F9 final to F8 updates? Of course dist-f9-updates should get the same update, but that's all we can do, we can't magically go back in time and change what was released with F9 final! Similarly, but more subtly, comparing dist-f8-updates-testing with dist-f9-updates as the script now does also makes no sense. If an update should hit F8 and F9 updates at the same time, it also has to be tested at the same time! So the only thing we can reasonably compare dist-f8-updates-testing with (other than dist-f10) is dist-f9-updates-testing. dist-f8-updates-testing will ALWAYS have some packages with higher EVRs than dist-f9-updates. Kevin Kofler From j.w.r.degoede at hhs.nl Sat Jul 26 22:40:47 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 Jul 2008 00:40:47 +0200 Subject: Looking for review for F-10 better webcam support feature Message-ID: <488BA7EF.2080900@hhs.nl> Hi All, Could someone please review this: https://bugzilla.redhat.com/show_bug.cgi?id=456772 Its a really easy review and I need to get this into place so that I can continue my work on the F-10 better webcam support feature: https://fedoraproject.org/wiki/Features/BetterWebcamSupport Thanks & Regards, Hans From dominik at greysector.net Sat Jul 26 22:39:14 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 27 Jul 2008 00:39:14 +0200 Subject: libdvdread slight API breakage Message-ID: <20080726223914.GC19598@mokona.greysector.net> Since libdvdnav (and libdvdread) have been forked by one of MPlayer's developers, there's been a significant bugfixing effort going on. Unfortunately, the new upstream broke the API a bit. While before you'd use #include now you have to use #include . A libdvdread build that requires the above change has already landed in rawhide. The ABI hasn't changed, so there's no immediate need to rebuild. Affected packages: dvdauthor k3b lsdvd python-kaa-metadata Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From wolfy at nobugconsulting.ro Sat Jul 26 22:51:45 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 27 Jul 2008 01:51:45 +0300 Subject: Looking for review for F-10 better webcam support feature In-Reply-To: <488BA7EF.2080900@hhs.nl> References: <488BA7EF.2080900@hhs.nl> Message-ID: <488BAA81.8050803@nobugconsulting.ro> On 07/27/2008 01:40 AM, Hans de Goede wrote: > Hi All, > > Could someone please review this: > https://bugzilla.redhat.com/show_bug.cgi?id=456772 > > Its a really easy review and I need to get this into place so that I > can continue my work on the F-10 better webcam support feature: > https://fedoraproject.org/wiki/Features/BetterWebcamSupport > > Thanks & Regards, > > Hans > Welcome :) M. -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting SRL A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? From j.w.r.degoede at hhs.nl Sat Jul 26 23:08:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 Jul 2008 01:08:46 +0200 Subject: Looking for review for F-10 better webcam support feature In-Reply-To: <488BAA81.8050803@nobugconsulting.ro> References: <488BA7EF.2080900@hhs.nl> <488BAA81.8050803@nobugconsulting.ro> Message-ID: <488BAE7E.4020002@hhs.nl> Manuel Wolfshant wrote: > On 07/27/2008 01:40 AM, Hans de Goede wrote: >> Hi All, >> >> Could someone please review this: >> https://bugzilla.redhat.com/show_bug.cgi?id=456772 >> >> Its a really easy review and I need to get this into place so that I >> can continue my work on the F-10 better webcam support feature: >> https://fedoraproject.org/wiki/Features/BetterWebcamSupport >> >> Thanks & Regards, >> >> Hans >> > Welcome :) > Wow, fast, thanks!! Regards, Hans From s-t-rhbugzilla at wwwdotorg.org Sun Jul 27 00:49:31 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Sat, 26 Jul 2008 18:49:31 -0600 (MDT) Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1217119772.13907.TMDA@tmda.severn.wwwdotorg.org> On Sat, July 26, 2008 4:16 pm, Kevin Kofler wrote: > dist-f8-updates (and dist-f8-updates-testing even more so) will ALWAYS > have > some packages with higher EVRs than dist-f9, this is normal and > unavoidable, > how else would you suggest to backport a new version of a package which > wasn't > in F9 final to F8 updates? Of course dist-f9-updates should get the same > update, but that's all we can do, we can't magically go back in time and > change > what was released with F9 final! No, that should never happen. Consider the situation where: F8: pkg-1.fc8 F9 (original): pkg-1.fc9 To put a fix in F8, you version it pkg-1.fc8.1 *not* pkg-2.fc8. I don't recall exactly where, but this is somewhere in the wiki area on packaging. From kevin.kofler at chello.at Sun Jul 27 01:33:02 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 01:33:02 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217119772.13907.TMDA@tmda.severn.wwwdotorg.org> Message-ID: Stephen Warren wwwdotorg.org> writes: > To put a fix in F8, you version it pkg-1.fc8.1 *not* pkg-2.fc8. That doesn't work if it's a new version. This technique is useful, but to prevent dist-f8-updates > dist-f9-updates situations (which are true packaging errors), not dist-f8-updates > dist-f9 situations (which are normal). If you push a new version to F8, you have to push it to F9 too, but it'll be only in dist-f9-updates, not in dist-f9. Only packaging-related issues which don't affect F9 should be fixed in F8 with the n%{?dist}.1 trick. Kevin Kofler From martin.langhoff at gmail.com Sun Jul 27 02:38:49 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 14:38:49 +1200 Subject: Strange mock behaviour - buildrequires in the host? In-Reply-To: <4888490F.3070203@city-fan.org> References: <46a038f90807172120l249d41b8m75a4603945c5db78@mail.gmail.com> <4888490F.3070203@city-fan.org> Message-ID: <46a038f90807261938m6d5d1e21xc5a6e7045b828a78@mail.gmail.com> On Thu, Jul 24, 2008 at 9:19 PM, Paul Howarth wrote: > The fix for this is to remove (patch out) the "-o httpd" option from the > install section of the Makefile (the chown won't work as a non-root user, > and RPMs should always be built as non-root users), and instead use %attr in > the spec file's %files section to indicate that the installed file should be Thanks! I hadn't seen the reply earlier - probably due to the odd reply-to settings in the list). This is the same conclusion I came to. For tools other software tools that expect to chown from within their Makefile, this is probably a bit awkward. > This method will mean that you don't need to buildrequire httpd too Yes. Removed that one too. thanks! martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Sun Jul 27 02:42:30 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 14:42:30 +1200 Subject: Kickstart partitioning stanzas - make optional? In-Reply-To: References: <46a038f90807232215y2645bebr192011ff9147cba5@mail.gmail.com> <1216882973.2739.3.camel@hp6710.axianet.ch> <488846E8.2070701@crc.dk> Message-ID: <46a038f90807261942o46b6c3c0pcbcf6dd02baa905c@mail.gmail.com> 2008/7/24 yersinia : > Just a pratical example - i have used it with RHEL5 - , there are many Interesting! I will have a play with this - thanks! cheers. martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Sun Jul 27 03:25:28 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 15:25:28 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807252321r5ca3cb4wd9f16ef682a2ecd9@mail.gmail.com> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> <46a038f90807252321r5ca3cb4wd9f16ef682a2ecd9@mail.gmail.com> Message-ID: <46a038f90807262025y4aa49c2fyda00d383680d497@mail.gmail.com> On Sat, Jul 26, 2008 at 6:21 PM, Martin Langhoff wrote: > Any hints as to what to try next, doco or source to read? After a bit more investigation. the livecd-tools package in F9 (017.1-1.fc9) can only build F9 correctly, and the problem boils down to incorrect placement of the .ko files in the initrd. Here is how to repro with F9 vs F7. In my testing, F8 shows the same problems. 1 - Take the fedora-minimal.ks file and replace "rawhide" with 'fedora-9', 'fedora-7' - as follows: --8<----8<----8<-- lang en_US.UTF-8 keyboard us timezone US/Eastern auth --useshadow --enablemd5 selinux --disabled firewall --disabled part / --size 1024 repo --name=released --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=$basearch %packages @core bash kernel passwd policycoreutils chkconfig authconfig rootfiles %end --8<----8<----8<-- 2 - Build one minimal Liveimage for each. The image should boot to a login prompt - though it will not allow logins as no root pw has been set. 3 - Boot the images with qemu -m 512 --cdrom -- the F7 iso will panic 4 - mount -o loop both ISOs, in my case in /tmp/f7 /tmp/f9 and extract the initrd in each 5 - find initrd-7 initrd-9 -type f -name '*.ko' initrd-7/lib/mbcache.ko initrd-7/lib/sr_mod.ko initrd-7/lib/msdos.ko initrd-7/lib/ext3.ko initrd-7/lib/ehci-hcd.ko initrd-7/lib/uhci-hcd.ko initrd-7/lib/pata_pcmcia.ko initrd-7/lib/mmc_block.ko initrd-7/lib/jbd.ko (...snipped...) initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_jmicron.ko initrd-9/lib/modules/2.6.25-14.fc9.i686/ata_generic.ko initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_qdi.ko initrd-9/lib/modules/2.6.25-14.fc9.i686/sata_vsc.ko initrd-9/lib/modules/2.6.25-14.fc9.i686/sata_sil24.ko initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_hpt366.ko Additionally, I have a F7 liveCD built elsewhere (with an earlier, patched version of livecd-tools) that boots successfully - the initrd of that liveCD looks like find initrd-7-good -type f -name '*.ko' | head initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_jmicron.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/ata_generic.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_qdi.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_vsc.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_sil24.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_hpt366.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/mbcache.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_sx4.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_serverworks.ko initrd-7-good/lib/modules/2.6.23.1-21.fc7/sr_mod.ko I am not sure why this is happening, but I keep working on this. regards, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From s-t-rhbugzilla at wwwdotorg.org Sun Jul 27 04:40:44 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Sat, 26 Jul 2008 22:40:44 -0600 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217119772.13907.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1217133666.9027.TMDA@tmda.severn.wwwdotorg.org> Kevin Kofler wrote: >Stephen Warren wwwdotorg.org> writes: >>To put a fix in F8, you version it pkg-1.fc8.1 *not* pkg-2.fc8. > > That doesn't work if it's a new version. That's a great argument for not bumping package version (rather than release) too much!: In F9 before F10 final is frozen, any package version bumps must be reflected in rawhide/F10 too (by current policy in the existing EVR script, ignoring strange stuff like epochs making the base version number irrelevant), so people are free to bump versions without using the above technique. Only after F10 is frozen would the above technique be required, and prohibit verion bumps. I'd argue that by that time, it'd be good policy to disallow version bumps in F9 anyway, since any requirement for a version bump that didn't exist in the first ~5 months of a release doesn't exactly seem to qualify as maintenance; instead significant new stuff should be in the new/latest distro release. If something like the above is not the policy, how are CD/preupgrade upgrades possibly going to be reliable? An upgrade would end up installing whatever random subset of Fn was newer than Fn-1. Whilst I appreciate that a "yum update" after the upgrade would solve the issue, that fact doesn't address what happens when running rpm scripts during the install against a random mix of Fn/Fn-1, nor how the system is supposed to sanely boot with the same random mix before the yum update. > This technique is useful, but to prevent dist-f8-updates > dist-f9-updates > situations (which are true packaging errors), not dist-f8-updates > dist-f9 > situations (which are normal). If you push a new version to F8, you have to > push it to F9 too, but it'll be only in dist-f9-updates, not in dist-f9. Only > packaging-related issues which don't affect F9 should be fixed in F8 with the > n%{?dist}.1 trick. From martin.langhoff at gmail.com Sun Jul 27 05:10:00 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 17:10:00 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807262025y4aa49c2fyda00d383680d497@mail.gmail.com> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> <46a038f90807252321r5ca3cb4wd9f16ef682a2ecd9@mail.gmail.com> <46a038f90807262025y4aa49c2fyda00d383680d497@mail.gmail.com> Message-ID: <46a038f90807262210xde7f013qcd859bfce5f0b526@mail.gmail.com> On Sun, Jul 27, 2008 at 3:25 PM, Martin Langhoff wrote: > After a bit more investigation. the livecd-tools package in F9 > (017.1-1.fc9) can only build F9 correctly, and the problem boils down > to incorrect placement of the .ko files in the initrd. Here is how to > repro with F9 vs F7. In my testing, F8 shows the same problems. I tracked this down to the switch from mayflower to mkinitrd, which lead me to commit 11dbd0bb5ba4b845e80109e990e4e780ca402218 where mayflower gets installed and called during %post. So I updated my ks file as below. This still fails to build a bootable F8 or F7, both drop to an emergency shell after failing to find root (see below for more details). I am using git's master for these builds. Current kickstart file --8<----8<----8<-- lang en_US.UTF-8 keyboard us timezone US/Eastern auth --useshadow --enablemd5 selinux --disabled firewall --disabled part / --size 1024 repo --name=released --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch %packages @core bash kernel passwd policycoreutils chkconfig authconfig rootfiles # for live initrd livecd-tools # livecd bits to set up the livecd and be able to install anaconda #isomd5sum %end %post # make the initrd we care about rm -f /boot/initrd*.img cp /etc/sysconfig/mkinitrd /etc/mayflower.conf ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'` /usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver rm -f /etc/mayflower.conf %end %post --nochroot # move the initrd we created to be the booted one mv $INSTALL_ROOT/boot/initrd-*.img $LIVE_ROOT/isolinux/initrd0.img %end --8<----8<----8<-- With this ks file, the initrd is now built correctly. But during boot with F8 I see all sorts of odd errors: WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device for / ... starting udevd creating devices waiting for system to settle ... SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem SQUASHFS error: Please update your kernel mount: wrong fstype ... Once on the shell, the dmesg output looks normal except for the Squashfs errors, and ls /dev/ does not contain anything that looks like a usable block device. Trying to mount /dev/loop0 gives me the same squashfs error as before. hmmmm? hints? m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From hughsient at gmail.com Sun Jul 27 06:28:20 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 27 Jul 2008 07:28:20 +0100 Subject: pm-utils for F8 and Advanced power management In-Reply-To: <4884FC24.6090303@redhat.com> References: <68720af30807061627ld991cf4t73acdf38b5c3eb55@mail.gmail.com> <1218b5bc0807080944w232e81b2nf19e960a62d1377b@mail.gmail.com> <200807081944.50114.opensource@till.name> <1218b5bc0807081549wbd351d4i4488fbdc9d3a4feb@mail.gmail.com> <1215568390.4382.6.camel@localhost.localdomain> <20080709075758.GA14801@srcf.ucam.org> <20080710102915.GB5017@srcf.ucam.org> <20080710130230.GA29114@nostromo.devel.redhat.com> <4884FC24.6090303@redhat.com> Message-ID: <1217140100.3151.1.camel@hughsie-work> On Mon, 2008-07-21 at 17:14 -0400, Peter Jones wrote: > Note that we really want similar functionality for e.g. > gnome-power-manager's battery charge history data. Yes, I'm going to push this into DeviceKit-power and hopefully we can do something more sane with caching and only writing when we need to. Richard. From vnpenguin at vnoss.org Sun Jul 27 07:55:12 2008 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sun, 27 Jul 2008 09:55:12 +0200 Subject: Pungi: how to set priority for repos ? Message-ID: Hi, I would like setup my local repo for pungi, but I don't know how to define priority for this repo in order to get my rpms instead of rpms from standard repos. For this moment, I have to play with "Epoch", but I think priority solution will be better, right ? Thanks, -- http://vnoss.org From jvonau at shaw.ca Sun Jul 27 08:00:08 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 27 Jul 2008 03:00:08 -0500 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <1217145608.25653.3.camel@S010600e029961c54.wp.shawcable.net> Martin Langhoff wrote: > On Sun, Jul 27, 2008 at 3:25 PM, Martin Langhoff > wrote: >> After a bit more investigation. the livecd-tools package in F9 >> (017.1-1.fc9) can only build F9 correctly, and the problem boils down >> to incorrect placement of the .ko files in the initrd. Here is how to >> repro with F9 vs F7. In my testing, F8 shows the same problems. > > I tracked this down to the switch from mayflower to mkinitrd, which > lead me to commit > 11dbd0bb5ba4b845e80109e990e4e780ca402218 where mayflower gets > installed and called during %post. > > So I updated my ks file as below. This still fails to build a bootable > F8 or F7, both drop to an emergency shell after failing to find root > (see below for more details). I am using git's master for these > builds. > > Current kickstart file > > --8<----8<----8<-- > lang en_US.UTF-8 > keyboard us > timezone US/Eastern > auth --useshadow --enablemd5 > selinux --disabled > firewall --disabled > part / --size 1024 > > repo --name=released > --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch > > %packages > @core > bash > kernel > passwd > policycoreutils > chkconfig > authconfig > rootfiles > > # for live initrd > livecd-tools > # livecd bits to set up the livecd and be able to install > anaconda > #isomd5sum > > %end > > %post > # make the initrd we care about > rm -f /boot/initrd*.img > cp /etc/sysconfig/mkinitrd /etc/mayflower.conf > ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'` > /usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver > rm -f /etc/mayflower.conf > %end > > %post --nochroot > # move the initrd we created to be the booted one > mv $INSTALL_ROOT/boot/initrd-*.img $LIVE_ROOT/isolinux/initrd0.img > %end > --8<----8<----8<-- > > With this ks file, the initrd is now built correctly. But during boot > with F8 I see all sorts of odd errors: > > WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device for / > ... > starting udevd > creating devices > waiting for system to settle > ... > SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem > SQUASHFS error: Please update your kernel > mount: wrong fstype ... > The squsashfs-tools/kernel module on the fc7/8 live disks is to old to mount the squashfs.img created on the newer f9 box. > Once on the shell, the dmesg output looks normal except for the > Squashfs errors, and ls /dev/ does not contain anything that looks > like a usable block device. Trying to mount /dev/loop0 gives me the > same squashfs error as before. > > hmmmm? hints? > > > > m Think you would need to include, maybe recompile, the squashfs-tools rpm from the f9. Then I think you'll need to recompile the kernel module and include it in the initrd. I can't recall when this update to squashfs occurred, but I believe it was tied to a kernel update between fedora releases 8-9. so I'm not sure if the above will even work. Jerry From martin.langhoff at gmail.com Sun Jul 27 08:45:42 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 20:45:42 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <1217145608.25653.3.camel@S010600e029961c54.wp.shawcable.net> References: <1217145608.25653.3.camel@S010600e029961c54.wp.shawcable.net> Message-ID: <46a038f90807270145w69e49062qd6a2c50827d65ed5@mail.gmail.com> On Sun, Jul 27, 2008 at 8:00 PM, Jerry Vonau wrote: > The squsashfs-tools/kernel module on the fc7/8 live disks is to old to > mount the squashfs.img created on the newer f9 box. Interesting. F7 contains squashfs-tools-3.2-1, vs 3.3-2 in F9 and the changelog doesn't say anything too explicit about a break on storage format. Two things look suspicious - sparse files support and the change in default block size. > Think you would need to include, maybe recompile, the squashfs-tools rpm > from the f9. Then I think you'll need to recompile the kernel module and > include it in the initrd. I can't recall when this update to squashfs > occurred, but I believe it was tied to a kernel update between fedora > releases 8-9. so I'm not sure if the above will even work. Sounds complex. I will try going in the opposite direction: downgrade the package on F9 or pass flags to disable the new fanciness. thanks for the hints! m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From rawhide at fedoraproject.org Sun Jul 27 08:55:04 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 27 Jul 2008 08:55:04 +0000 (UTC) Subject: rawhide report: 20080727 changes Message-ID: <20080727085504.5939F209DA8@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080726/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080727/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gtest Google C++ testing framework New package lxlauncher Open source replacement for Asus Launcher on the EeePC New package nautilus-share Easy sharing folder via Samba (CIFS protocol) Updated Packages: bootconf-1.3-2.fc10 ------------------- * Sat Jul 26 18:00:00 2008 Mr. Sam - 1.3-2% - Added .fc10 to release control-center-2.23.5-4.fc10 ---------------------------- * Sat Jul 26 18:00:00 2008 Matthias Clasen - 2.23.5-4 - Use standard icon names in more places enchant-1.4.2-4.fc10 -------------------- * Sat Jul 26 18:00:00 2008 Michael Schwendt 1:1.4.2-4 - Rebuild for ABI-incompatible hunspell-1.2.4.2-2.fc10 epiphany-extensions-2.23.0-0.1.fc10 ----------------------------------- * Sat Jul 26 18:00:00 2008 Peter Gordon - 2.23.0-0.1 - Adapt internal build scripts so that the Extensions are built against and run with Ephy 2.23/2.24: + 2.22_23-api.diff - Rebuild for XULrunner 1.9.0.1 while we're at it. :) fatsort-0.9.8.3-1.fc10 ---------------------- * Tue Jul 15 18:00:00 2008 Till Maas - 0.9.8.3-1 - Update to new version - Fix Makefile install target gconf-editor-2.22.0-2.fc10 -------------------------- * Sat Jul 26 18:00:00 2008 Matthias Clasen - 2.22.0-2 - Fix missing icon gobby-0.4.6-1.fc10 ------------------ * Sat Jul 26 18:00:00 2008 Luke Macken - 0.4.6-1 - Update to the latest upstream release. grip-3.2.0-20.fc10 ------------------ * Sat Jul 26 18:00:00 2008 Adrian Reber - 1:3.2.0-20 - fixed "Grip silently crahses on F8" (#456721) (converted non UTF-8 .po files to UTF-8) gsynaptics-0.9.14-1.fc10 ------------------------ * Sun Jul 27 18:00:00 2008 Christoph Wickert - 0.9.14-1 - Use dist tag * Sun Jul 27 18:00:00 2008 Christoph Wickert - 0.9.14-1 - Update 0.9.14 kde-filesystem-4-17.fc10 ------------------------ * Mon Jul 14 18:00:00 2008 Rex Dieter 4-17 - + %_kde4_sharedir/kde4 kde-i18n-3.5.9-9.fc10 --------------------- * Sat Jul 26 18:00:00 2008 Kevin Kofler 1:3.5.9-9 - on F10+, remove translations for kdepim apps now part of KDE 4.1 (#456745) kernel-2.6.27-0.183.rc0.git14.fc10 ---------------------------------- * Sat Jul 26 18:00:00 2008 Roland McGrath - 2.6.26-git14 - Disable lirc patch, not building. * Fri Jul 25 18:00:00 2008 unknown - 2.6.26-git13 * Fri Jul 25 18:00:00 2008 Roland McGrath - 2.6.26-git13 - utrace update * Fri Jul 25 18:00:00 2008 Dave Jones - 2.6.26-git12 net6-1.3.6-1.fc10 ----------------- * Sat Jul 26 18:00:00 2008 Luke Macken - 1.3.6-1 - Update to the latest upstream release. obby-0.4.5-1.fc10 ----------------- * Sat Jul 26 18:00:00 2008 Luke Macken - 0.4.5-1 - Update to the latest upstream release openhpi-2.12.0-1.fc10 --------------------- * Sat Jul 26 18:00:00 2008 Dan Horak - 2.12.0-1 - update to 2.12.0 pyflowtools-0.3.4-1.fc10 ------------------------ * Fri Jul 18 18:00:00 2008 Paul P. Komkoff Jr - 0.3.4-1 - fix integer size-related bugs - add some pydocs pygobject2-2.15.2-1.fc10 ------------------------ * Sat Jul 26 18:00:00 2008 Matthew Barnes - 2.15.2-1.fc10 - Update to 2.15.2 rhythmbox-0.11.6-3.fc10 ----------------------- * Sat Jul 26 18:00:00 2008 Matthias Clasen 0.11.6-3 - Use standard icon names in a few places sobby-0.4.4-4.fc10 ------------------ * Sat Jul 26 18:00:00 2008 Luke Macken - 0.4.4-4 - Rebuild against obby 0.4.5 tlock-1.4-2.fc10 ---------------- * Sat Jul 26 18:00:00 2008 _pjp_ - 1.4-2 - Fixed the share/info/dir menu entry of tlock. xorg-x11-drv-geode-2.10.0-1.fc10 -------------------------------- * Fri Jun 13 18:00:00 2008 Dennis Gilmore 2.10.0-1 - update to 2.10.0 drop upstreamed patches Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 21 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sobby-0.4.4-4.fc10.i386 requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sobby-0.4.4-4.fc10.x86_64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sobby-0.4.4-4.fc10.ppc requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sobby-0.4.4-4.fc10.ppc64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From ville.skytta at iki.fi Sun Jul 27 09:11:53 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 Jul 2008 12:11:53 +0300 Subject: libdvdread slight API breakage In-Reply-To: <20080726223914.GC19598@mokona.greysector.net> References: <20080726223914.GC19598@mokona.greysector.net> Message-ID: <200807271211.53572.ville.skytta@iki.fi> On Sunday 27 July 2008, Dominik 'Rathann' Mierzejewski wrote: > Since libdvdnav (and libdvdread) have been forked by one of MPlayer's > developers, there's been a significant bugfixing effort going on. > Unfortunately, the new upstream broke the API a bit. While before > you'd use > #include > now you have to use > #include . Any ideas why they did that and if similar breakage is expected to happen with dvdnav soon (it's still )? > A libdvdread build that requires the above change has already landed > in rawhide. Quite a while ago actually. I placed an ugly hack in dvdauthor that should keep the package backwards compatible almost three weeks ago to take this into account. From hughsient at gmail.com Sun Jul 27 08:00:03 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 27 Jul 2008 09:00:03 +0100 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1216924774.10458.93.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> Message-ID: <1217145603.3151.16.camel@hughsie-work> On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote: > What do people think... I think it looks great. Some comments tho: * You are using gpk-install-package-name -- you probably don't want to call the binary name, you want to call the InstallPackageName DBUS method -- see http://www.packagekit.org/pk-faq.html#session-methods for more info. * You are using the libpackagekit Resolve() -- which is fine, but you're using the status boolean to check for installed. It's perfectly valid for PackageKit to emit installed foo-0.1.2, available foo-0.1.3 if there is a package update available. Maybe one to check for. * The destop file checking code is already present in gpk-client-run.c -- maybe we can share some code there. > does this make sense as part of the PackageKit project? Yes, but the licence could be tricky. All of stuff in PackageKit has to be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things. Thanks! Richard. From martin.langhoff at gmail.com Sun Jul 27 10:16:17 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 27 Jul 2008 22:16:17 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807270145w69e49062qd6a2c50827d65ed5@mail.gmail.com> References: <1217145608.25653.3.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807270145w69e49062qd6a2c50827d65ed5@mail.gmail.com> Message-ID: <46a038f90807270316p4e35ee84lfd269df0da597ad6@mail.gmail.com> On Sun, Jul 27, 2008 at 8:45 PM, Martin Langhoff wrote: > Sounds complex. I will try going in the opposite direction: downgrade > the package on F9 or pass flags to disable the new fanciness. Right - with the following patch to fs.py the F7 kernel won't panic anymore, and a basic F8 will boot. The mkfs tweak is probably unneeded, the main difference seems to come from -no-sparse: --- a/imgcreate/fs.py +++ b/imgcreate/fs.py @@ -38,7 +38,7 @@ def makedirs(dirname): raise def mksquashfs(in_img, out_img): - args = ["/sbin/mksquashfs", in_img, out_img] + args = ["/sbin/mksquashfs", in_img, out_img, '-no-sparse', '-b', '131072'] if not sys.stdout.isatty(): args.append("-no-progress") @@ -200,7 +200,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): def __format_filesystem(self): rc = subprocess.call(["/sbin/mkfs." + self.fstype, - "-F", "-L", self.fslabel, + '-I', '128', "-F", "-L", self.fslabel, "-m", "1", "-b", str(self.blocksize), self.lofile, str(self.size / self.blocksize)]) On F7 - my actual target ATM - the problem is not gone through. Init is dropping me to a panic shell, and I cannot figure out how to get something I can mount there. When I get dropped in the shell, lsmod makes it seem like no interesting modules have been loaded. modprobe-ing libata, cdrom and other modules works. I don't know the major/minor numbers enough to mknod my way around here. So I suspect of the initrd, but I am unsure of what to do next. The mayflower initrd seems to work though it does throw some (IMO) meaningless errors - complaining about old module names that are not relevant to the 2.6.23 kernel I have: Building an initramfs at /boot/initrd-2.6.23.1-21.fc7.img for kernel 2.6.23.1-21.fc7 FATAL: Module ide_cd not found. FATAL: Module =ata not found. FATAL: Module usbhid not found. FATAL: Module ieee1394 not found. Done; initramfs is 4.2M. any more hints on this track? TIA, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From walters at verbum.org Sun Jul 27 12:18:48 2008 From: walters at verbum.org (Colin Walters) Date: Sun, 27 Jul 2008 08:18:48 -0400 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217145603.3151.16.camel@hughsie-work> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> Message-ID: On Sun, Jul 27, 2008 at 4:00 AM, Richard Hughes wrote: > > > Yes, but the licence could be tricky. All of stuff in PackageKit has to > be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't > know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things. Well, keep in mind that this isn't the same target use case as the pk shared libraries; i.e. nothing except Firefox-derived codebases is going to be linking in Firefox extensions. And that LGPL 2.1 and LGPLv2+ are certainly compatible, it's effectively LGPL 2.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From promac at gmail.com Sun Jul 27 13:13:43 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 27 Jul 2008 10:13:43 -0300 Subject: Fn+F8 and laptop keys In-Reply-To: <68720af30807260428l15844d1dy876b55546a7fb05f@mail.gmail.com> References: <68720af30807260428l15844d1dy876b55546a7fb05f@mail.gmail.com> Message-ID: <68720af30807270613u5702724dj88043c7e4afdf8e2@mail.gmail.com> On Sat, Jul 26, 2008 at 8:28 AM, Paulo Cavalcanti wrote: > Hi, > > I have had some problems for making my laptop special keys > to work. First of all, hall-info from F8 is not updated. In my case, > a Dell owner, the file > > /usr/share/hal/fdi/information/10freedesktop/30-keymap-dell.fdi > > is divided based on Dell models (very few). The current hall-info has only > one configuration > for all models. Anyway, fixing the keymap made all my keys working: > > Fn+F1 hibernate > Fn+F3 battery status (just show the status once, a second hit does not show > anything. Why?) > and all the multimedia keys. > > This is good, because there is no need to include setkeycodes in > /etc/rc.local. > > The only key that is really not working is the Fn+F8, to switch between the > LCD and > an external monitor. Although I have > > e00b:displaytoggle > > > in my file, it does not make any difference at all. If I press Fn+F8, dmesg > gives me: > > atkbd.c: Unknown key pressed (translated set 2, code 0x8b on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e00b ' to make it known. > > Therefore, the key is not mapped. Well, I tried mapping it to 214 > (XF86Video), 227, etc ... and no joy. > > I have an nvidia 8400 GS card. If during the boot I press Fn+F8 before > entering X, I can switch to the > external monitor, but I cannot go back to the laptop LCD. I tried the nv > and the nvidia binary driver in xorg.conf. > Using the nv driver, the login screen appears on both, LCD+monitor, but > after loging in, only the external monitor is active. Using the binary > driver, not even that, the login screen appears onto only one. > > I saw some posts about using xrandr for this purpose: > > http://ubuntuforums.org/archive/index.php/t-634675.html > > My question is: is it possible to switch using an nvidia card on Fedora? > Would xrandr work? > > I also think that an updated hall-info for F8 is in order. It would be > really nice if those keys worked just out of the box. > This is the type of issue that is very difficult to fix without some > knowledge, and makes users look for other distros. In fact, switching to an > external monitor is essential for presentations using a projector. Since I > wiped out my Vista OS, I do not even know if switching worked on Windows for > my Vostro 1400. > > Well, the scheme works surprisinly well. I tested it on my desktop and a TV, and my laptop and an external Samsung CRT. I also managed to make mplayer send its output automatically to the secondary display when in full screen mode (using SDL). Unfortunately, everything depends on the graphics driver. I used the binary nvidia driver (177.13). But definitively, it is something very useful, and should be supported out of the box, in my opinion. #!/bin/bash # # Toggles display (0: TwinView, 1: TV/CRT, and 2:LCD) # by switching through xorg resolutions. # It is neessary to use 'MetaModes' in # the Nvidia driver to set up a few # different resolutions. # if [ -f ~/.changeres ]; then . ~/.changeres fi if [ -z $INDEX ]; then INDEX=-1 fi let INDEX "INDEX += 1" if [[ $INDEX > 2 ]]; then INDEX=0 fi # Interfaces to RandR extension. # Sets the screen size using an index # into the list of available sizes. # In case of error, it prints: # "Size index 4 is too large, there are only 3 sizes" xrandr -s $INDEX if [ $? == "0" ]; then echo "OK" else INDEX=0 xrandr -s $INDEX fi echo "#!/bin/bash" > ~/.changeres echo "INDEX=$INDEX" >> ~/.changeres ----------------------------------------------------------- This is the contents of my ~/.xbindkeysrc: #Toggle Display "/home/roma/bin/changeres.sh" m:0x0 + c:214 XF86Display -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Sun Jul 27 14:01:58 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jul 2008 16:01:58 +0200 Subject: Argyllcms 1.0.1 packaged in fedora-devel Message-ID: <1217167318.25486.30.camel@rousalka.okg> Hi, Argyll CMS is now packaged in Fedora Devel and should be included in Fedora 10 (missed Fedora 10 Alpha though) http://cvs.fedoraproject.org/viewcvs/devel/argyllcms/ http://koji.fedoraproject.org/koji/buildinfo?buildID=57682 I must say it I always take a new Argyll release with lots expectations, and not a little dread, since it has consistently proved a pig to package. (and this version is no different). Thus, I don't plan a backport to previous Fedora releases. Many thanks to Graeme for his continued efforts and Alastair M. Robinson for removing a huge thorn from my side and autotooling it all. Anyway, some packaging notes. I've applied: ? V1.0.1_patches.txt (not easy to find, not referenced anywhere) ? argyll_V1.0.1_autotools.patch.gz But I had to disable parallel building, Alastair it would be great if make -jX worked ? http://cvs.fedoraproject.org/viewcvs/devel/argyllcms/argyllcms-1.0.1-printf.patch This patch had already been submitted but some parts haven't been merged by Graeme yet ? http://cvs.fedoraproject.org/viewcvs/devel/argyllcms/argyllcms-1.0.1-remove-libusb-fork-check.patch Why oh why do we have to do this? I Notice Mandriva had to do something similar. As we said before if there's a specific problem in libusb report it and we'll get it fixed ? http://cvs.fedoraproject.org/viewcvs/devel/argyllcms/argyllcms-1.0.1-legal.patch While most sane countries (mine included) do not recognize software patents, there's no need to wave a red flag before patent lawyers. (esp. since cameras are now used instead of scanners). ? http://cvs.fedoraproject.org/viewcvs/devel/argyllcms/argyllcms-1.0.1-19-color.fdi This includes Graeme's last changes. I'm not sure if a blanket ACL for serial devices is good, if Devid Zeuthen complains I'll drop it Also, the install routine change the timestamps of the files in /usr/share/color/argyll/ref/. We'd really like those files to have an invariant timestamp as long as they're not modified. Anyway, we build with a fairly recent toolchain and very anal build flags. I expect the non-i386 build logs at http://koji.fedoraproject.org/koji/buildinfo?buildID=57682 include many interesting warnings about code that should be cleaned up. I hope Argyll CMS will continue to normalise and will reach the no-patching-needed stage someday. Best regards, -- Nicolas Mailhot -------------- 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 Sun Jul 27 14:08:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 14:08:12 +0000 (UTC) Subject: livecd-creator unmounting temp image, running daemons. References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> Message-ID: Martin Langhoff gmail.com> writes: > I am using a F9 host to build a F7 liveCD -- the School Server image How about not running the school server on an OS which gets no more upgrades, not even critical security upgrades??? Fedora 7 is no longer supported, so of course there will be no efforts made to make modern live CD tools work with it. Kevin Kofler From kevin.kofler at chello.at Sun Jul 27 14:23:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 14:23:57 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217119772.13907.TMDA@tmda.severn.wwwdotorg.org> <1217133666.9027.TMDA@tmda.severn.wwwdotorg.org> Message-ID: Stephen Warren wwwdotorg.org> writes: > That's a great argument for not bumping package version (rather than > release) too much!: Sorry, that's not how Fedora works. Fedora is not Debian stable nor RHEL. Version upgrades are the norm rather than the exception. > In F9 before F10 final is frozen, any package version bumps must be > reflected in rawhide/F10 too (by current policy in the existing EVR > script, ignoring strange stuff like epochs making the base version > number irrelevant), so people are free to bump versions without using > the above technique. And that makes sense, as Rawhide has no updates repository and it's where new stuff should get tested first anyway. > Only after F10 is frozen would the above technique be required, and > prohibit verion bumps. I'd argue that by that time, it'd be good policy > to disallow version bumps in F9 anyway, This is your opinion, but it does NOT reflect current Fedora practices and policies, and I'm very strongly opposed to making that a policy, ever. The policy which the upgrade path script is enforcing is that a version bump in an F9 update will have to also be pushed to F10 updates. > since any requirement for a version bump that didn't exist in the first ~5 > months of a release doesn't exactly seem to qualify as maintenance; instead > significant new stuff should be in the new/latest distro release. You're missing several reasons for a version bump: * security fixes: Fedora explicitly encourages upgrading rather than backporting to fix security issues. * upstream bugfix releases, which can fix bugs experienced by Fedora users (including security bugs, see above) * upgrades required to keep a client working with current servers: We've had that situation quite often with IM clients. Some maintainers also like pushing updates for new hardware support and/or new features even to older releases. That practice may be up for debate (I personally don't think it's a bad thing unless this happens when the release is almost EOL and/or introduces breakage), but the other 3 reasons I have given apply to old releases just as much as to new ones. > If something like the above is not the policy, how are CD/preupgrade > upgrades possibly going to be reliable? An upgrade would end up > installing whatever random subset of Fn was newer than Fn-1. Whilst I > appreciate that a "yum update" after the upgrade would solve the issue, > that fact doesn't address what happens when running rpm scripts during > the install against a random mix of Fn/Fn-1, nor how the system is > supposed to sanely boot with the same random mix before the yum update. Yet this is the status quo and works just good enough for us. In fact the first real breakage due to this issue that I know of has been sighted very recently with F8 Python and F9 OpenSSL not being compatible, preventing the final yum update. It has been fixed by pushing new Python and Python-urlgrabber to F8 which make yum work with no working OpenSSL. But this is really an argument for online upgrades or upgrades with the updates repository enabled, not an argument for making Fedora no longer Fedora. Kevin Kofler From kevin.kofler at chello.at Sun Jul 27 15:41:31 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 15:41:31 +0000 (UTC) Subject: [packagekit] A PackageKit browser plugin References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> Message-ID: Colin Walters verbum.org> writes: > Well, keep in mind that this isn't the same target use case as the pk shared > libraries; i.e. nothing except Firefox-derived codebases is going to be > linking in Firefox extensions. Is it an extension or a traditional plugin? Other browsers, such as Konqueror, can also load classic Mozilla plugins (but not Firefox extensions, of course). Kevin Kofler From jvonau at shaw.ca Sun Jul 27 16:52:34 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 27 Jul 2008 11:52:34 -0500 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> Martin: Your cc to the livecd list are not appearing there, are you subscribed? Martin Langhoff wrote: > On Sun, Jul 27, 2008 at 8:45 PM, Martin Langhoff > wrote: >> Sounds complex. I will try going in the opposite direction: downgrade >> the package on F9 or pass flags to disable the new fanciness. > > Right - with the following patch to fs.py the F7 kernel won't panic > anymore, and a basic F8 will boot. The mkfs tweak is probably > unneeded, the main difference seems to come from -no-sparse: > Think the issue is going to be how the kernel modules differ from version 3.2 and 3.3 of squashfs-tools. So lets get this clear, F7 is using the 2.6.23.?? and does not boot, F8 is now booting correctly? with which kernel? > --- a/imgcreate/fs.py > +++ b/imgcreate/fs.py > @@ -38,7 +38,7 @@ def makedirs(dirname): > raise > > def mksquashfs(in_img, out_img): > - args = ["/sbin/mksquashfs", in_img, out_img] > + args = ["/sbin/mksquashfs", in_img, out_img, '-no-sparse', '-b', '131072'] > > if not sys.stdout.isatty(): > args.append("-no-progress") > @@ -200,7 +200,7 @@ class SparseExtLoopbackMount(SparseLoopbackMount): > > def __format_filesystem(self): > rc = subprocess.call(["/sbin/mkfs." + self.fstype, > - "-F", "-L", self.fslabel, > + '-I', '128', "-F", "-L", self.fslabel, > "-m", "1", "-b", str(self.blocksize), > self.lofile, > str(self.size / self.blocksize)]) > > > On F7 - my actual target ATM - the problem is not gone through. Init > is dropping me to a panic shell, and I cannot figure out how to get > something I can mount there. When I get dropped in the shell, lsmod > makes it seem like no interesting modules have been loaded. > modprobe-ing libata, cdrom and other modules works. I don't know the > major/minor numbers enough to mknod my way around here. > see above > So I suspect of the initrd, but I am unsure of what to do next. The > mayflower initrd seems to work though it does throw some (IMO) > meaningless errors - complaining about old module names that are not > relevant to the 2.6.23 kernel I have: > > Building an initramfs at /boot/initrd-2.6.23.1-21.fc7.img for kernel > 2.6.23.1-21.fc7 > FATAL: Module ide_cd not found. > FATAL: Module =ata not found. > FATAL: Module usbhid not found. > FATAL: Module ieee1394 not found. > Done; initramfs is 4.2M. > > any more hints on this track? > Think the only way you'll get this to fly is to get the source for squashfs-tools3.3 http://www.squashfs-lzma.org/dl/squashfs3.3.tar.gz and patch your 2.6.23 kernel and recompile the module and replace the module in the initrd. There is a good post on the livecd list about patching squashfs for lsma support and covers all the steps, perhaps you could adapt the steps(leave out the lzma patches). https://www.redhat.com/archives/fedora-livecd-list/2008-July/msg00007.html https://www.redhat.com/archives/fedora-livecd-list/2008-July/msg00005.html Repacking is initrd and iso are not that hard, but I have some notes around if you need them. Jerry From walters at verbum.org Sun Jul 27 17:33:35 2008 From: walters at verbum.org (Colin Walters) Date: Sun, 27 Jul 2008 13:33:35 -0400 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> Message-ID: On Sun, Jul 27, 2008 at 11:41 AM, Kevin Kofler wrote: > Colin Walters verbum.org> writes: > > Well, keep in mind that this isn't the same target use case as the pk > shared > > libraries; i.e. nothing except Firefox-derived codebases is going to be > > linking in Firefox extensions. > > Is it an extension or a traditional plugin? Other browsers, such as > Konqueror, > can also load classic Mozilla plugins (but not Firefox extensions, of > course). Actually you're right, it is a plugin and not an extension. However I think the generic-interface exception would apply here (i.e. it doesn't count as linking). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgl at redhat.com Sun Jul 27 18:31:45 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 27 Jul 2008 14:31:45 -0400 Subject: Putting --fuzz=0 into rpmbuild on older versions? Message-ID: <16378.1217183505@sss.pgh.pa.us> So, sure enough, I got blindsided by the fact that rawhide's RPM now applies patches with --fuzz=0. I don't object to tightening the policy like that, but it's pretty unhappy-making that having tested an SRPM on my Fedora 9 system offers no protection against the koji build failing. I looked around for a place to inject --fuzz=0 into the patch arguments on F-9, and couldn't find one. Is the definition of %patch really hardwired into rpmbuild? It's not supposed to be according to the documentation, but I can't find the macro definition anyplace ... regards, tom lane From kevin.kofler at chello.at Sun Jul 27 18:53:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 18:53:33 +0000 (UTC) Subject: Putting --fuzz=0 into rpmbuild on older versions? References: <16378.1217183505@sss.pgh.pa.us> Message-ID: Tom Lane redhat.com> writes: > So, sure enough, I got blindsided by the fact that rawhide's RPM now > applies patches with --fuzz=0. I don't object to tightening the policy > like that, but it's pretty unhappy-making that having tested an SRPM on > my Fedora 9 system offers no protection against the koji build failing. For the KDE packages, we're simply adding %define _default_patch_fuzz 2 to our specfiles whenever a patch doesn't apply due to fuzz. Kevin Kofler From arjan at infradead.org Sun Jul 27 19:10:50 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 27 Jul 2008 12:10:50 -0700 Subject: Putting --fuzz=0 into rpmbuild on older versions? In-Reply-To: References: <16378.1217183505@sss.pgh.pa.us> Message-ID: <20080727121050.425c5aab@infradead.org> On Sun, 27 Jul 2008 18:53:33 +0000 (UTC) Kevin Kofler wrote: > Tom Lane redhat.com> writes: > > So, sure enough, I got blindsided by the fact that rawhide's RPM now > > applies patches with --fuzz=0. I don't object to tightening the > > policy like that, but it's pretty unhappy-making that having tested > > an SRPM on my Fedora 9 system offers no protection against the koji > > build failing. > > For the KDE packages, we're simply adding %define _default_patch_fuzz > 2 to our specfiles whenever a patch doesn't apply due to fuzz. eww... why not rebase the patch instead? (while making sure it's still a valid result) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From jvonau at shaw.ca Sun Jul 27 19:13:27 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 27 Jul 2008 14:13:27 -0500 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <1217186007.25653.59.camel@S010600e029961c54.wp.shawcable.net> Kevin Kofler wrote: > Martin Langhoff gmail.com> writes: >> I am using a F9 host to build a F7 liveCD -- the School Server image > > How about not running the school server on an OS which gets no more upgrades, > not even critical security upgrades??? Fedora 7 is no longer supported, so of > course there will be no efforts made to make modern live CD tools work with it. > > Kevin Kofler > Yea, you should try to get "School Server image" working as a "spin". Have you tried the --base-on= option to livecd-tools and try to re-spin, with the f7 live disk as the source, with a later distro? This, I think, would be the same as doing a yum upgrade on the F7 release and re-rolling it. Jerry From jvonau at shaw.ca Sun Jul 27 20:54:49 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 27 Jul 2008 15:54:49 -0500 Subject: Pungi: how to set priority for repos ? Message-ID: <1217192089.25653.68.camel@S010600e029961c54.wp.shawcable.net> Vnpenguin wrote: > Hi, > I would like setup my local repo for pungi, but I don't know how to > define priority for this repo in order to get my rpms instead of rpms > from standard repos. > > For this moment, I have to play with "Epoch", but I think priority > solution will be better, right ? > > Thanks, Think you just have to append --cost="value", where "value" is < 1000, to your local repo line in the config file. Hope it works, Jerry From ricky at fedoraproject.org Sun Jul 27 21:21:26 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 27 Jul 2008 17:21:26 -0400 Subject: cvs-import.sh patch (add a cvs up) Message-ID: <20080727212126.GD21504@Max> 15:44 < ricky> Hmm, looks like my make build is hanging somewhere (not showing up in koji) ... snip ... 15:51 < ricky> Haha, I forgot to cvs up :-) thanks 15:51 < f13-1> ricky: no problem. Hey, wanna generate a Makefile patch that makes this error more obvious? So here's a tiny patch to just run a cvs up after at the end of a cvs-import: http://ricky.fedorapeople.org/cvs-import.sh-cvs-up.patch Thanks, Ricky -------------- 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 Sun Jul 27 21:42:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 27 Jul 2008 17:42:38 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1217194958.6624.7.camel@localhost.localdomain> On Sat, 2008-07-26 at 22:16 +0000, Kevin Kofler wrote: > > Similarly, but more subtly, comparing dist-f8-updates-testing with > dist-f9-updates as the script now does also makes no sense. Actually yes it does. There are often times when an update is only issued on an older branch and not issued on a newer branch, therefor it is necessary to compare all of the older branch against the newer branch. This will lead to some false positives and can be ignored, but it can also detect real situations that require fixing. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 mschwendt at gmail.com Sun Jul 27 21:56:52 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 27 Jul 2008 23:56:52 +0200 Subject: cvs-import.sh patch (add a cvs up) In-Reply-To: <20080727212126.GD21504@Max> References: <20080727212126.GD21504@Max> Message-ID: <20080727235652.6c4741b7.mschwendt@gmail.com> On Sun, 27 Jul 2008 17:21:26 -0400, Ricky Zhou wrote: > 15:44 < ricky> Hmm, looks like my make build is hanging somewhere (not showing up in koji) > ... snip ... > 15:51 < ricky> Haha, I forgot to cvs up :-) thanks > 15:51 < f13-1> ricky: no problem. Hey, wanna generate a Makefile patch that makes this error more obvious? > > So here's a tiny patch to just run a cvs up after at the end of a > cvs-import: http://ricky.fedorapeople.org/cvs-import.sh-cvs-up.patch Are you sure? It could be that I'm no longer up-to-date wrt the cvs-import script, but the line you've patched starts with "cvs -Q update" already, and I think it is done somewhere below $TMPDIR not $WORKDIR. Your IRC log looks like you want a cvs up in $WORKDIR (which doesn't need to be package directory). From kevin.kofler at chello.at Sun Jul 27 22:10:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jul 2008 22:10:30 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > > On Sat, 2008-07-26 at 22:16 +0000, Kevin Kofler wrote: > > > > Similarly, but more subtly, comparing dist-f8-updates-testing with > > dist-f9-updates as the script now does also makes no sense. > > Actually yes it does. There are often times when an update is only > issued on an older branch and not issued on a newer branch, therefor it > is necessary to compare all of the older branch against the newer > branch. This will lead to some false positives and can be ignored, but > it can also detect real situations that require fixing. But won't comparing dist-f8-updates-testing with dist-f9-updates-testing and dist-f8-updates with dist-f9-updates already catch those cases, without causing false positives? Kevin Kofler From dominik at greysector.net Sun Jul 27 22:16:46 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 28 Jul 2008 00:16:46 +0200 Subject: libdvdread slight API breakage In-Reply-To: <200807271211.53572.ville.skytta@iki.fi> References: <20080726223914.GC19598@mokona.greysector.net> <200807271211.53572.ville.skytta@iki.fi> Message-ID: <20080727221646.GB25605@mokona.greysector.net> On Sunday, 27 July 2008 at 11:11, Ville Skytt? wrote: > On Sunday 27 July 2008, Dominik 'Rathann' Mierzejewski wrote: > > Since libdvdnav (and libdvdread) have been forked by one of MPlayer's > > developers, there's been a significant bugfixing effort going on. > > Unfortunately, the new upstream broke the API a bit. While before > > you'd use > > #include > > now you have to use > > #include . > > Any ideas why they did that To avoid clash with MPlayer's internal libdvdread copy. I'm trying to convince Nico to reverse that and change MPlayer's internal copy instead (or remove it alltogether) before the next release. > and if similar breakage is expected to happen with > dvdnav soon (it's still )? I don't think it will happen. There was no need. > > A libdvdread build that requires the above change has already landed > > in rawhide. > > Quite a while ago actually. I placed an ugly hack in dvdauthor that should > keep the package backwards compatible almost three weeks ago to take this > into account. Thanks and sorry for the late notice. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dbhole at redhat.com Sun Jul 27 23:01:30 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Sun, 27 Jul 2008 19:01:30 -0400 Subject: Rawhide Orphanarium Purged In-Reply-To: <488A24BE.3080308@redhat.com> References: <4889F4C6.2030000@redhat.com> <200807251345.53173.dennis@ausil.us> <488A24BE.3080308@redhat.com> Message-ID: <20080727230130.GA18769@redhat.com> * Warren Togami [2008-07-25 15:09]: > Dennis Gilmore wrote: >> On Friday 25 July 2008, Warren Togami wrote: >> >>> sinjdoc >> With the removal of sinjdoc gcj now requires openjdk for javadoc. due to >> a bug its been that way at buildtime for awhile now. but sinjdoc was a >> Requires and worked for runtime javadoc needs. but now the only javadoc >> parser is in openjdk. IMO this is bad. > > This was on the orphan list with repeated warnings for weeks. I'll unblock > it now, but someone really needs to take ownership if it is important. > Done. I am now the owner of sinjdoc. Deepak > Warren Togami > wtogami at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From martin.langhoff at gmail.com Sun Jul 27 23:02:16 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 28 Jul 2008 11:02:16 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <1217186007.25653.59.camel@S010600e029961c54.wp.shawcable.net> References: <1217186007.25653.59.camel@S010600e029961c54.wp.shawcable.net> Message-ID: <46a038f90807271602r60974697t5ee8c5ce99a35a30@mail.gmail.com> On Mon, Jul 28, 2008 at 7:13 AM, Jerry Vonau wrote: >> How about not running the school server on an OS which gets no more > upgrades, >> not even critical security upgrades??? Fedora 7 is no longer > supported, so of >> course there will be no efforts made to make modern live CD tools work > with it. I can understand Kevin's sentiments, but at the time we are in development, and the port to F9 is a major undertaking that I cannot focus on right now. We will tackle it, but there are more pressing needs. And some of the stuff we have on F7 will be really hard to reimplement on F9 - if anyone is keen on lending a hand with porting our odd network setup scripts to F9, he or she will earn my deepest thanks. And possibly a gig with us too if desired :-) > Yea, you should try to get "School Server image" working as a "spin". > Have you tried the --base-on= option to livecd-tools and try to re-spin, > with the f7 live disk as the source, with a later distro? This, I think, > would be the same as doing a yum upgrade on the F7 release and > re-rolling it. Is there a "base" commandline liveCD for F7? Our current spin is a X-less server setup. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Sun Jul 27 23:44:18 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 28 Jul 2008 11:44:18 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> References: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> Message-ID: <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> On Mon, Jul 28, 2008 at 4:52 AM, Jerry Vonau wrote: > Your cc to the livecd list are not appearing there, are you subscribed? No - I thought it was an open list. I'll sub... ... > Think the issue is going to be how the kernel modules differ from > version 3.2 and 3.3 of squashfs-tools. > > So lets get this clear, F7 is using the 2.6.23.?? and does not boot, > F8 is now booting correctly? with which kernel? Correct. This is with 2.6.23.1-21.fc7 > Think the only way you'll get this to fly is to get the source for > squashfs-tools3.3 http://www.squashfs-lzma.org/dl/squashfs3.3.tar.gz > and patch your 2.6.23 kernel and recompile the module and replace the > module in the initrd. Thanks for pointing me to lzma. So the squashfs 3.3 on F9 is patched to have lzma support? Good to know... after a bit of investigation, it turns out that between 3.2 and 3.3 the squashfs project took the lzma pactches, and forgot to mention it in the changelog. How misterious and cute :-/ After a bit of testing, squashfs-3.2 on F9 produces a squashfs I can mount on F7. But the image still does not boot. Something else in the initrd must be messing up. cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From jkeating at redhat.com Mon Jul 28 00:19:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 27 Jul 2008 20:19:54 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> Message-ID: <1217204394.6624.9.camel@localhost.localdomain> On Sun, 2008-07-27 at 22:10 +0000, Kevin Kofler wrote: > > But won't comparing dist-f8-updates-testing with dist-f9-updates-testing and > dist-f8-updates with dist-f9-updates already catch those cases, without causing > false positives? Nope, because once a package only has things in updates, there is nothing tagged with updates-testing, so the checker if it didn't check against dist-f9-updates it would miss that comparison. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 Mon Jul 28 00:28:13 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jul 2008 00:28:13 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> <1217204394.6624.9.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > Nope, because once a package only has things in updates, there is > nothing tagged with updates-testing, so the checker if it didn't check > against dist-f9-updates it would miss that comparison. OK, so it needs like the tester needs to be smarter and realize that if there's a newer build in updates-testing it's OK. I guess dist-fn-updates-testing needs to be compared with the most recent of dist-f(n+1)-updates and dist-f(n+1)-updates-testing, but dist-fn-updates only with dist-f(n+1)-updates (because I don't think we want updates being pushed for the older release when they're still in testing in the newer one). I can take a look at the code of the script to see if I can fix it. Kevin Kofler From jkeating at redhat.com Mon Jul 28 00:39:04 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 27 Jul 2008 20:39:04 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> <1217204394.6624.9.camel@localhost.localdomain> Message-ID: <1217205544.3151.1.camel@localhost.localdomain> On Mon, 2008-07-28 at 00:28 +0000, Kevin Kofler wrote: > > OK, so it needs like the tester needs to be smarter and realize that if there's > a newer build in updates-testing it's OK. I guess dist-fn-updates-testing needs > to be compared with the most recent of dist-f(n+1)-updates and > dist-f(n+1)-updates-testing, but dist-fn-updates only with dist-f(n+1)-updates > (because I don't think we want updates being pushed for the older release when > they're still in testing in the newer one). > > I can take a look at the code of the script to see if I can fix it. I think you're too focused on the scenario where the same update is being pushed to all the branches, when that isn't always what is happening. It's quite possible that different updates are being pushed, could be at the same time, could be at different times, and those updates could be completely unrelated to each other. Since this is just an informative mailing, I think it's safe to let the maintainer decide if there is an actual problem or not, just like they will when they've requested an update that will fix any N-V-R issues, but it just hasn't been pushed yet. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Mon Jul 28 00:40:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 27 Jul 2008 20:40:59 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: <1217205544.3151.1.camel@localhost.localdomain> References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> <1217204394.6624.9.camel@localhost.localdomain> <1217205544.3151.1.camel@localhost.localdomain> Message-ID: <1217205659.3151.4.camel@localhost.localdomain> On Sun, 2008-07-27 at 20:39 -0400, Jesse Keating wrote: > On Mon, 2008-07-28 at 00:28 +0000, Kevin Kofler wrote: > > > > OK, so it needs like the tester needs to be smarter and realize that if there's > > a newer build in updates-testing it's OK. I guess dist-fn-updates-testing needs > > to be compared with the most recent of dist-f(n+1)-updates and > > dist-f(n+1)-updates-testing, but dist-fn-updates only with dist-f(n+1)-updates > > (because I don't think we want updates being pushed for the older release when > > they're still in testing in the newer one). > > > > I can take a look at the code of the script to see if I can fix it. > > I think you're too focused on the scenario where the same update is > being pushed to all the branches, when that isn't always what is > happening. It's quite possible that different updates are being pushed, > could be at the same time, could be at different times, and those > updates could be completely unrelated to each other. > > Since this is just an informative mailing, I think it's safe to let the > maintainer decide if there is an actual problem or not, just like they > will when they've requested an update that will fix any N-V-R issues, > but it just hasn't been pushed yet. Also I'm trying to keep any "domain" knowledge out of the script so that it's more easily usable for other sites making use of koji. The only real domain knowledge in it is the variable definitions at the top of the script and the one place where we assume -owner@ is a valid contact for the package. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 Mon Jul 28 01:31:25 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jul 2008 01:31:25 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-07-26 References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> <1217204394.6624.9.camel@localhost.localdomain> <1217205544.3151.1.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > I think you're too focused on the scenario where the same update is > being pushed to all the branches, when that isn't always what is > happening. Well, it is a quite common case, I at least tend to do this often, and I think spamming maintainers with bogus EVR problem reports for this is really unhelpful, and may lead to them ignoring the real problems. In a test run (of course with a script hacked not to spam maintainers or mailing lists, just me ;-) ) for a patch I have developed (see the end of this mail) for the checker (using the current real Koji data), a total of 30 bogus reports [1] were there (all removed with the fix)! That's out of a total of 76 reports, i.e. 39% of the reports are bogus! > It's quite possible that different updates are being pushed, > could be at the same time, could be at different times, and those > updates could be completely unrelated to each other. The case where there is no matching update in dist-f9-updates-testing isn't affected by my patch at all, e.g. it still reports this one (where the F9 update hasn't hit testing yet, so of course the script can't know it's pending for testing; but this is the exception rather than the norm, for example it just affects 1 package in this run): iptables: dist-f8-updates-testing > dist-f9-updates (iptables-1.4.1.1-2.fc8 iptables-1.4.1.1-1.fc9) > Since this is just an informative mailing, I think it's safe to let the > maintainer decide if there is an actual problem or not, just like they > will when they've requested an update that will fix any N-V-R issues, > but it just hasn't been pushed yet. I think they will be really confused about whether the reports are real issues or not, and start ignoring the reports even if they complain about real issues. > Also I'm trying to keep any "domain" knowledge out of the script so that > it's more easily usable for other sites making use of koji. The only > real domain knowledge in it is the variable definitions at the top of > the script and the one place where we assume -owner@ is a valid > contact for the package. With my patch, no special domain information is needed, you only have to prepend a / to an updates tag following an updates-testing tag, i.e. invoke it like this: ./check-upgrade-paths.py f8-final dist-f8-updates \ dist-f8-updates-testing /dist-f9-updates dist-f9-updates-testing dist-f10 The way this is handled is described in the code: prepending a / is special: A /B C means A will not be checked against B, but against the union of B and C Only A is affected, everything preceding A will still be checked against B normally, as will B against C. But enough talking, here's the patch: http://repo.calcforge.org/f10/check-upgrade-paths.py.diff Apologies if the code is suboptimal, Python is not my preferred programming language. ;-) Kevin Kofler [1] abiword: dist-f8-updates-testing > dist-f9-updates (1:abiword-2.6.4-2.fc8 1:abiword-2.6.4-1.fc9) augeas: dist-f8-updates-testing > dist-f9-updates (augeas-0.2.2-1.fc8 augeas-0.2.1-1.fc9) bluez-libs: dist-f8-updates-testing > dist-f9-updates (bluez-libs-3.35-1.fc8 bluez-libs-3.32-1.fc9) bluez-utils: dist-f8-updates-testing > dist-f9-updates (bluez-utils-3.35-3.fc8 bluez-utils-3.32-1.fc9) bzr-gtk: dist-f8-updates-testing > dist-f9-updates (bzr-gtk-0.94.0-5.fc8 bzr-gtk-0.94.0-2.fc9) collectl: dist-f8-updates-testing > dist-f9-updates (collectl-3.0.0-1.fc8 collectl-2.6.4-1.fc9) decibel-audio-player: dist-f8-updates-testing > dist-f9-updates (decibel-audio-player-0.10-2.fc8 decibel-audio-player-0.10-1.fc9) ext3grep: dist-f8-updates-testing > dist-f9-updates (ext3grep-0.7.0-1.fc8 ext3grep-0.6.0-1.fc9) ez-ipupdate: dist-f8-updates-testing > dist-f9-updates (ez-ipupdate-3.0.11-0.19.b8.fc8 ez-ipupdate-3.0.11-0.18.b8.fc9) flashrom: dist-f8-updates-testing > dist-f9-updates (flashrom-0-0.11.20080607svn3418.fc8 flashrom-0-0.9.20080517svn3332.fc9) gamazons: dist-f8-updates-testing > dist-f9-updates (gamazons-0.83-3.fc8 gamazons-0.83-2.fc9) gyachi: dist-f8-updates-testing > dist-f9-updates (gyachi-1.1.35-16.fc8 gyachi-1.1.35-6.fc9) nautilus-sendto: dist-f8-updates-testing > dist-f9-updates (nautilus-sendto-1.0.1-1.fc8 nautilus-sendto-1.0.0-1.fc9) notification-daemon-engine-nodoka: dist-f8-updates-testing > dist-f9-updates (notification-daemon-engine-nodoka-0.1.0-3.fc8 notification-daemon-engine-nodoka-0.1.0-2.fc9) ocaml-json-static: dist-f8-updates-testing > dist-f9-updates (ocaml-json-static-0.9.6-5.fc8 ocaml-json-static-0.9.6-4.fc9) ocaml-openin: dist-f8-updates-testing > dist-f9-updates (ocaml-openin-20070524-4.fc8 ocaml-openin-20070524-3.fc9) ocaml-pa-monad: dist-f8-updates-testing > dist-f9-updates (ocaml-pa-monad-1.2.0-5.fc8 ocaml-pa-monad-1.2.0-4.fc9) ocaml-pgocaml: dist-f8-updates-testing > dist-f9-updates (ocaml-pgocaml-1.1-3.fc8 ocaml-pgocaml-1.1-2.fc9) pcmanfm: dist-f8-updates-testing > dist-f9-updates (pcmanfm-0.5-1.fc8 pcmanfm-0.4.6.2-1.fc9) pinot: dist-f8-updates-testing > dist-f9-updates (pinot-0.87-1.fc8 pinot-0.86-1.fc9) python-fedora: dist-f8-updates-testing > dist-f9-updates (python-fedora-0.3.3-1.fc8 python-fedora-0.2.99.11.1-1.fc9) qlandkarte: dist-f8-updates-testing > dist-f9-updates (qlandkarte-0.7.3-1.fc8 qlandkarte-0.7.2-1.fc9) rubygem-activeldap: dist-f8-updates-testing > dist-f9-updates (rubygem-activeldap-1.0.1-1.fc8 rubygem-activeldap-0.10.0-10.fc9) rubygem-hoe: dist-f8-updates-testing > dist-f9-updates (rubygem-hoe-1.7.0-1.fc8 rubygem-hoe-1.5.1-5.fc9) strigi: dist-f8-updates-testing > dist-f9-updates (strigi-0.5.11-1.fc8 strigi-0.5.9-2.fc9) tellico: dist-f8-updates-testing > dist-f9-updates (tellico-1.3.3-1.fc8 tellico-1.3.2.1-1.fc9) thunar-shares: dist-f8-updates-testing > dist-f9-updates (thunar-shares-0.16-1.fc8 thunar-shares-0.12-1.fc9) vala: dist-f8-updates-testing > dist-f9-updates (vala-0.3.4-2.fc8 vala-0.3.4-1.fc9) xenner: dist-f8-updates-testing > dist-f9-updates (xenner-0.41-1.fc8 xenner-0.37-1.fc9) xfce4-screenshooter-plugin: dist-f8-updates-testing > dist-f9-updates (xfce4-screenshooter-plugin-1.3.1-1.fc8 xfce4-screenshooter-plugin-1.2.0-1.fc9) From martin.langhoff at gmail.com Mon Jul 28 03:41:34 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 28 Jul 2008 15:41:34 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> References: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> Message-ID: <46a038f90807272041h5ca0e168ocad1dfca5ac41e68@mail.gmail.com> On Mon, Jul 28, 2008 at 11:44 AM, Martin Langhoff wrote: > After a bit of testing, squashfs-3.2 on F9 produces a squashfs I can > mount on F7. > > But the image still does not boot. Something else in the initrd must > be messing up. FWIW, I can build the liveCD inside mock -r fedora-7-i386, as long as I add the (undeclared) kudzu dependency and mknod a loop device. It looks like only F7 livecd-tools can build F7 livecds -- I perceive livecd-tools to be a build tool so my expectations (perhaps misplaced) were of more flexibility. thanks for the help! martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From gilboad at gmail.com Mon Jul 28 04:28:27 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 28 Jul 2008 07:28:27 +0300 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. Message-ID: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> Hello all, It seems that Fedora-list have replaced Fedora-devel as the prime staging place for useless, 100-post-long political debates. As far as I could count, there are at-least 4 different political threads current running in -users: (All by the same individuals, BTW) - "Misunderstanding GPL's terms and conditions as restrictions" - "That old GNU/Linux argument" - "A long rebuttal to the Linux-is-the-engine fallacy" - "Why is Fedora not a Free GNU/Linux distributions?" Now I am aware that I could setup a toll filter, deleting all messages that are being posted by said individuals (I already do), but never-the-less, filling my Internet pipe with 100's of useless messages is -very- annoying. Would it be possible to create a Fedora-policy ML and get people to stop spamming (either willingly or by using blacklists) the main MLs? Thanks, - Gilboa From sundaram at fedoraproject.org Mon Jul 28 04:44:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 28 Jul 2008 10:14:14 +0530 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> Message-ID: <488D4E9E.3040108@fedoraproject.org> Gilboa Davara wrote: > > Would it be possible to create a Fedora-policy ML and get people to > stop spamming (either willingly or by using blacklists) the main MLs? I suggested a code of conduct such as the ones other projects have adopted, long back in Fedora advisory board list and that idea got rejected. For reference http://live.gnome.org/CodeOfConduct http://www.gentoo.org/proj/en/council/coc.xml http://www.ubuntu.com/community/conduct http://en.opensuse.org/Code_of_Conduct Now we are going about addressing the issue with specific policies such as the one recently enacted for IRC conversations. Note that there are mailing list guidelines at http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Enforcing it is different matter though. I don't think moderators are even reading the list in the first place. Rahul From jspaleta at gmail.com Mon Jul 28 04:46:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Jul 2008 20:46:47 -0800 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> Message-ID: <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> On Sun, Jul 27, 2008 at 8:28 PM, Gilboa Davara wrote: > Would it be possible to create a Fedora-policy ML and get people to > stop spamming (either willingly or by using blacklists) the main MLs? Basically you want a mailinglist for all the discussions that experienced users and contributors are tired of seeing repeated? -jef From ricky at fedoraproject.org Mon Jul 28 05:04:25 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 28 Jul 2008 01:04:25 -0400 Subject: cvs-import.sh patch (add a cvs up) In-Reply-To: <20080727235652.6c4741b7.mschwendt@gmail.com> References: <20080727212126.GD21504@Max> <20080727235652.6c4741b7.mschwendt@gmail.com> Message-ID: <20080728050425.GA8965@Max> On 2008-07-27 11:56:52 PM, Michael Schwendt wrote: > It could be that I'm no longer up-to-date wrt the cvs-import script, > but the line you've patched starts with "cvs -Q update" already, and > I think it is done somewhere below $TMPDIR not $WORKDIR. Your IRC > log looks like you want a cvs up in $WORKDIR (which doesn't need to > be package directory). Hm, I think you're right about about this being under $TMPDIR. Ignore this for now, and I'll have a tested patch the next time I need to run cvs-import.sh. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From anders at trudheim.co.uk Mon Jul 28 05:40:52 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 07:40:52 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> Message-ID: <20080728054052.GA6648@localhost.localdomain> * Jeff Spaleta [20080728 06:47]: > On Sun, Jul 27, 2008 at 8:28 PM, Gilboa Davara wrote: > > Would it be possible to create a Fedora-policy ML and get people to > > stop spamming (either willingly or by using blacklists) the main MLs? > > Basically you want a mailinglist for all the discussions that > experienced users and contributors are tired of seeing repeated? Jeff, comp.os.linux.advocacy - something along those lines. If you call it "fedora-advocacy", "fedora-politics" or "fedora-welcome-to-where-idiots-roam", I don't really mind. The threads that Gilboa mentions is the sole reason I implemented Sieve in my mailserver at home. fedora-devel and fedora-list became interesting and useful about as soon as those threads were filtered out. Read in to it what you want. /Anders From jspaleta at gmail.com Mon Jul 28 06:38:27 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Jul 2008 22:38:27 -0800 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728054052.GA6648@localhost.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> Message-ID: <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> On Sun, Jul 27, 2008 at 9:40 PM, Anders Karlsson wrote: > The threads that Gilboa mentions is the sole reason I implemented > Sieve in my mailserver at home. fedora-devel and fedora-list became > interesting and useful about as soon as those threads were filtered > out. > > Read in to it what you want. You miss my point. Are these discussions valuable or not. If they are not... then we shouldn't make a place for them.... period. I don't see anyone who actually standing up and saying these things are valued and thus worth preparing a special place for in our resource pool. If we are only considering making more channels so some of us can ignore others among us because they are talking about things we don't care about... I'm not prepared to support that. I'll consider supporting additional dedicated communications channel for things when the people who find value in the discussion in question ask for a dedicated list. They must be able to make the case that such dedicated communication will actually be useful in helping a team of people work together towards some identified task or goal which helps moves the project forward. -jef"I never read what I write, my spam filter it smart enough to flag my own posts as trash"spaleta From anders at trudheim.co.uk Mon Jul 28 07:00:51 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 09:00:51 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> Message-ID: <20080728070051.GC6648@localhost.localdomain> * Jeff Spaleta [20080728 08:39]: > On Sun, Jul 27, 2008 at 9:40 PM, Anders Karlsson wrote: > > The threads that Gilboa mentions is the sole reason I implemented > > Sieve in my mailserver at home. fedora-devel and fedora-list became > > interesting and useful about as soon as those threads were filtered > > out. > > > > Read in to it what you want. > > You miss my point. Are these discussions valuable or not. If they > are not... then we shouldn't make a place for them.... period. I > don't see anyone who actually standing up and saying these things are > valued and thus worth preparing a special place for in our resource > pool. If we are only considering making more channels so some of us > can ignore others among us because they are talking about things we > don't care about... I'm not prepared to support that. I see what you mean. Are the discussions in question valuable? No, they are about as useful as a chocolate teapot. > I'll consider supporting additional dedicated communications channel > for things when the people who find value in the discussion in > question ask for a dedicated list. They must be able to make the case > that such dedicated communication will actually be useful in helping a > team of people work together towards some identified task or goal > which helps moves the project forward. Cool, I'll carry on with the kill-lists then. If any of the participants would ever consider contributing anything remotely valuable in future, I'll remain in blissful ignorance. Despite me participating in one or two of the threads, I consider them to be ultimately harmful to the Fedora Project, and to Red Hat, a point I have stated. It's a shame there is no facility to block at source though, on the list server. That would be a useful addition, as that would cut down on the amount of bandwidth used. > -jef"I never read what I write, my spam filter it smart enough to flag > my own posts as trash"spaleta *lol* I better disable Amavis on outgoing mail then. I think I'm in the same boat. ;-) /Anders From hughsient at gmail.com Mon Jul 28 07:12:17 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 28 Jul 2008 08:12:17 +0100 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> Message-ID: <1217229137.3151.52.camel@hughsie-work> On Sun, 2008-07-27 at 13:33 -0400, Colin Walters wrote: > On Sun, Jul 27, 2008 at 11:41 AM, Kevin Kofler > wrote: > Colin Walters verbum.org> writes: > > Well, keep in mind that this isn't the same target use case > as the pk shared > > libraries; i.e. nothing except Firefox-derived codebases is > going to be > > linking in Firefox extensions. > > > Is it an extension or a traditional plugin? Other browsers, > such as Konqueror, > can also load classic Mozilla plugins (but not Firefox > extensions, of course). > > Actually you're right, it is a plugin and not an extension. However I > think the generic-interface exception would apply here (i.e. it > doesn't count as linking). Sure, then I think it makes perfect sense to include this in the PackageKit source tree. I think it just needs a --enable-mozilla-plugin in configure.ac and stick the files in contrib/mozilla-plugin If we change it to use the dbus interface, then it's not gnome specific -- and we get the native KDE stuff when the KPackageKit guys implement the same session interface. Plus, putting it in tree allows me to keep it compiling even if we change API/ABI in the future. Could you prepare a patch, of do you want me to have a go? Richard. From rawhide at fedoraproject.org Mon Jul 28 09:18:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 28 Jul 2008 09:18:45 +0000 (UTC) Subject: rawhide report: 20080728 changes Message-ID: <20080728091845.C7193209D40@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080727/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080728/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package python-webob WSGI request and response object Updated Packages: ImageMagick-6.4.0.10-2.fc10 --------------------------- * Sun Jul 27 18:00:00 2008 Hans de Goede 6.4.0.10-2 - Fix ownership of /usr/include/ImageMagick (bz 444647) argyllcms-1.0.1-1.fc10 ---------------------- * Sun Jul 27 18:00:00 2008 Nicolas Mailhot - 1.0.1-1 ??? Lots of workarounds dropped ??? Argyll continues progressing towards ???normal package??? state ??? No more jam hell ???, autotooling patch by Alastair M. Robinson ????????? ??? New workaround added for private libusb check ??? We build againt system libusb, and will fix ??? any problem people care to report ??? Re-applied some patches still not merged upstream, including the legal ??? one ??? It builds, what can go wrong??? ??? Changed Huey policy file. Huey users, please test control-center-2.23.5-7.fc10 ---------------------------- * Mon Jul 28 18:00:00 2008 Matthias Clasen - 2.23.5-7 - Fix the icon name patch * Mon Jul 28 18:00:00 2008 Matthias Clasen - 2.23.5-6 - Use standard icon names in more places * Sun Jul 27 18:00:00 2008 Matthias Clasen - 2.23.5-5 - Fix up gconf schema installation dejavu-fonts-2.26-1.fc10 ------------------------ * Sat Jul 26 18:00:00 2008 Nicolas Mailhot - 2.26-1 ?? New release at last duplicity-0.4.12-1.fc10 ----------------------- * Sun Jul 27 18:00:00 2008 Robert Scheck 0.4.12-1 - Upgrade to 0.4.12 ebview-0.3.6-5.fc10.1 --------------------- * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - 0.3.6-5 - Change Japanese fonts Requires (F-10+) gcalctool-5.23.5-2.fc10 ----------------------- * Mon Jul 28 18:00:00 2008 Matthias Clasen - 5.23.5-2 - Use standard icon names gnome-screensaver-2.23.3-0.2008.05.29.3.fc10 -------------------------------------------- * Sun Jul 27 18:00:00 2008 Matthias Clasen - 2.23.3-0.2008.05.29.3 - Use standard icon names gvfs-0.99.3-2.fc10 ------------------ * Sun Jul 27 18:00:00 2008 Matthias Clasen - 0.99.3-2 - Use standard icon names hunspell-1.2.5-1.fc10 --------------------- * Sun Jul 27 18:00:00 2008 Caolan McNamara - 1.2.5-1 - latest version jd-2.0.0-2.fc10 --------------- * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - 2.0.0-2 - Change Japanese fonts Requires (F-10+) jfbterm-0.4.7-18.fc10 --------------------- * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - 0.4.7-18 - Fix Japanese font search path (F-10+: fonts-japanese renamed to japanese-bitmap-fonts) - %{_datadir}/fonts is owned by filesystem (F-9+) kdebase-workspace-4.1.0-2.fc10 ------------------------------ * Sun Jul 27 18:00:00 2008 Kevin Kofler 4.1.0-2 - updated tooltip manager from 4.2 (fixes Plasma crash on theme change, #456820) kernel-2.6.27-0.186.rc0.git15.fc10 ---------------------------------- * Sun Jul 27 18:00:00 2008 Roland McGrath - 2.6.26-git15 - Disable powerpc64 ibmveth driver, not compiling. kita-0.177.3-13.fc10.1 ---------------------- * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - 0.177.3-13 - Change Japanese fonts Requires (F-10+) libedit-2.11-1.20080712cvs.fc10 ------------------------------- * Mon Jul 28 18:00:00 2008 Debarshi Ray - 2.11-1.20080712cvs - Version bump to 20080712-2.11. libical-0.31-3.fc10 ------------------- * Sun Jul 27 18:00:00 2008 Jeff Perry - 0.31-3 - Added 'BuildRequires: bison byacc flex'. * Sun Jul 27 18:00:00 2008 Debarshi Ray - 0.31-2 - Fixed linkage problems and disabled parallel build till upstream accepts fix. * Thu Jul 17 18:00:00 2008 Jeff Perry - 0.31-1 - Version bump to 0.31. * Thu Jul 17 18:00:00 2008 Debarshi Ray - 0.30-4 - Changed value of License according to Fedora licensing guidelines. - Enabled reentrant system calls and C++ bindings. - Omitted unused direct shared library dependencies. - Added ChangeLog, COPYING, LICENSE, NEWS and README to doc and dropped examples. * Wed Apr 2 18:00:00 2008 Jakub 'Livio' Rusinek - 0.30-3 - Source URL... Fixed * Wed Apr 2 18:00:00 2008 Jakub 'Livio' Rusinek - 0.30-2 - Removed untrue note about libical's homepage (to get rid of eventuall mess) mousetweaks-2.23.5-2.fc10 ------------------------- * Sun Jul 27 18:00:00 2008 Matthias Clasen - 2.23.5-2 - Use standard icon name mypaint-0.5.1-1.fc10 -------------------- * Sun Jul 27 18:00:00 2008 Marc Wiriadisastra - 0.5.1-1 - New version mysql-5.0.51a-2.fc10 -------------------- * Sun Jul 27 18:00:00 2008 Tom Lane 5.0.51a-2 - Enable ndbcluster support Resolves: #163758 - Suppress odd crash messages during package build, caused by trying to build dbug manual (which we don't install anyway) with dbug disabled Resolves: #437053 - Improve mysql.init to pass configured datadir to mysql_install_db, and to force user=mysql for both mysql_install_db and mysqld_safe. Related: #450178 nautilus-2.23.5.1-3.fc10 ------------------------ * Sun Jul 27 18:00:00 2008 Matthias Clasen - 2.23.5-3 - More icon name fixes * Sun Jul 27 18:00:00 2008 Matthias Clasen - 2.23.5-2 - Use standard icon names ochusha-0.5.99.66.1-0.5.cvs070110.fc10 -------------------------------------- * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - ochusha-0.5.99.66-0.5.cvs070110 - Change Japanese fonts Requires (F-10+) osmo-0.2.2-2.fc10 ----------------- * Sun Jul 27 18:00:00 2008 Debarshi Ray - 0.2.2-2 - Added post and postun scriptlets to update Gtk icon cache. * Sun Jul 27 18:00:00 2008 Debarshi Ray - 0.2.2-1 - Version bump to 0.2.2. - Added 'Requires: tzdata' and fixed the sources since libical does not provide timezone information anymore. - Added 'BuildRequires: hicolor-icon-theme' and moved icons to /usr/share/icons/hicolor from /usr/share/pixmaps. php-pear-Console-Table-1.1.2-1.fc10 ----------------------------------- * Sun Jul 27 18:00:00 2008 Remi Collet 1.1.2-1 - update to 1.1.2 pyephem-3.7.2.3-2.fc10 ---------------------- * Sun Jul 27 18:00:00 2008 Marek Mahut - 3.7.2.3-2 - Revision increase python-html2text-2.31-1.1 ------------------------- * Sun Jul 27 18:00:00 2008 Thorsten Leemhuis - 2.31-1 - update to 2.31 (GPLv3 now) python-migrate-0.4.5-2.fc10 --------------------------- python-sqlalchemy-0.4.7-1.fc10 ------------------------------ * Sun Jul 27 18:00:00 2008 Toshio Kuratomi 0.4.7-1 - Update to 0.4.7. python-toscawidgets-0.9.2-2.fc10 -------------------------------- * Sun Jul 27 18:00:00 2008 Toshio Kuratomi - 0.9.2-2 - Require python-webob python-urlgrabber-3.0.0-9.fc10 ------------------------------ * Thu Jul 10 18:00:00 2008 James Antill 3.0.0-9 - Make urlgrabber usable if openssl is broken - Relates: bug#454179 * Sun Jun 15 18:00:00 2008 James Antill 3.0.0-9 - Don't count partial downloads toward the total scribus-1.3.5-0.3.12419svn.fc10 ------------------------------- * Sun Jul 27 18:00:00 2008 Andreas Bierfert - 1.3.5-0.3.12419svn - new svn snapshot * Mon Jul 21 18:00:00 2008 Andreas Bierfert - 1.3.5-0.2.12404svn - svn snapshot toped-0.9.0-2.fc10 ------------------ * Sat Jul 26 18:00:00 2008 Chitlesh Goorah - 0.9.0-2 - Bug fix 451218 uniconvertor-1.1.3-2.fc10 ------------------------- * Sun Jul 27 18:00:00 2008 Andy Shevchenko 1.1.3-2 - update to 1.1.3 - new requirement python-reportlab xorg-x11-utils-7.4-3.fc10 ------------------------- * Sun Jul 27 18:00:00 2008 Adam Jackson 7.4-3 - Drop xdriinfo. Would be better suited to being in Mesa's glx-utils subpackage anyway. (#456609) zabbix-1.4.6-1.fc10 ------------------- * Fri Jul 25 18:00:00 2008 Jeffrey C. Ollie - 1.4.6-1 - Update to 1.4.6 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 35 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sobby-0.4.4-4.fc10.i386 requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sobby-0.4.4-4.fc10.x86_64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sobby-0.4.4-4.fc10.ppc requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sobby-0.4.4-4.fc10.ppc64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 28 10:19:05 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 28 Jul 2008 19:19:05 +0900 Subject: rawhide report: 20080728 changes In-Reply-To: <20080728091845.C7193209D40@releng1.fedora.phx.redhat.com> References: <20080728091845.C7193209D40@releng1.fedora.phx.redhat.com> Message-ID: <488D9D19.2020307@ioa.s.u-tokyo.ac.jp> Rawhide wrote, at 07/28/2008 06:18 PM +9:00: > ochusha-0.5.99.66.1-0.5.cvs070110.fc10 > -------------------------------------- > * Mon Jul 28 18:00:00 2008 Mamoru Tasaka - ochusha-0.5.99.66-0.5.cvs070110 > - Change Japanese fonts Requires (F-10+) Ah, sorry, the version of this rpm must be 0.5.99.66, not 0.5.99.66.1 . I am untagging this. Please don't update ochusha until tomorrow. Mamoru From alan at redhat.com Mon Jul 28 10:26:15 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jul 2008 06:26:15 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728054052.GA6648@localhost.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> Message-ID: <20080728102615.GC26801@devserv.devel.redhat.com> On Mon, Jul 28, 2008 at 07:40:52AM +0200, Anders Karlsson wrote: > * Jeff Spaleta [20080728 06:47]: > > On Sun, Jul 27, 2008 at 8:28 PM, Gilboa Davara wrote: > > > Would it be possible to create a Fedora-policy ML and get people to > > > stop spamming (either willingly or by using blacklists) the main MLs? > > > > Basically you want a mailinglist for all the discussions that > > experienced users and contributors are tired of seeing repeated? > > Jeff, > > comp.os.linux.advocacy - something along those lines. If you call it > "fedora-advocacy", "fedora-politics" or > "fedora-welcome-to-where-idiots-roam", I don't really mind. Seconded. I've given up on the fedora-list for the most part, and its driving users way from the Fedora project. I don't care if its fedora-ranting, or just fedora-without-alexanfre-and-les we set up but soemthing needs doing before it has a debian-legal like toxic effect on the whole userbase That or the fedora board could actually tell them to shut up and kick them off if they don't From alan at redhat.com Mon Jul 28 10:27:23 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jul 2008 06:27:23 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> Message-ID: <20080728102723.GD26801@devserv.devel.redhat.com> On Sun, Jul 27, 2008 at 10:38:27PM -0800, Jeff Spaleta wrote: > You miss my point. Are these discussions valuable or not. If they > are not... then we shouldn't make a place for them.... period. I Wrong. Very wrong. If there is a mountain of turd flowing through your house do you - decide it isn't valuable and leave it to flow - provide somewhere else for it to go so that you can use your house again Alan From anders at trudheim.co.uk Mon Jul 28 10:54:52 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 12:54:52 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728102615.GC26801@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> Message-ID: <20080728105452.GN6648@localhost.localdomain> * Alan Cox [20080728 12:26]: > On Mon, Jul 28, 2008 at 07:40:52AM +0200, Anders Karlsson wrote: > > * Jeff Spaleta [20080728 06:47]: > > > On Sun, Jul 27, 2008 at 8:28 PM, Gilboa Davara wrote: > > > > Would it be possible to create a Fedora-policy ML and get people to > > > > stop spamming (either willingly or by using blacklists) the main MLs? > > > > > > Basically you want a mailinglist for all the discussions that > > > experienced users and contributors are tired of seeing repeated? > > > > Jeff, > > > > comp.os.linux.advocacy - something along those lines. If you call it > > "fedora-advocacy", "fedora-politics" or > > "fedora-welcome-to-where-idiots-roam", I don't really mind. > > Seconded. I've given up on the fedora-list for the most part, and its driving > users way from the Fedora project. I don't care if its fedora-ranting, or > just fedora-without-alexanfre-and-les we set up but soemthing needs doing > before it has a debian-legal like toxic effect on the whole userbase Considering the length, and amount, of threads that topic spawned, there seems to be excessive willingness and energy to debate that topic. Splitting out the advocacy / hairsplitting / holy-war / I'm-more-right-than-you-are type debates to a separate list ought to be a "Project Self Preservation" action. Bit like the -sounder list in Ubuntu (like someone else mentioned) where I even think you're warned that topics will be inflammatory. fedora-list, do correct me if I am off base, intention was for users to be able to turn to with queries or requests for help, or just to get advise on how to go about doing things with Fedora. Not to get sunk in a veritable swamp of irrelevant, rehashed religious style diatrabe. If users first interaction with Fedora is fedora-list, "the August 2008 archives", I'll understand if they punt the Fedora ISO's into the trash and hop off elsewhere. No, really. > That or the fedora board could actually tell them to shut up and kick them off > if they don't Something equivalent to the Code Of Conduct that Canonical implemented. It worked on the ubuntu lists. No reason it would not work here. /Anders From jwboyer at gmail.com Mon Jul 28 12:21:48 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 28 Jul 2008 08:21:48 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488D4E9E.3040108@fedoraproject.org> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <488D4E9E.3040108@fedoraproject.org> Message-ID: <1217247708.12864.40.camel@weaponx> On Mon, 2008-07-28 at 10:14 +0530, Rahul Sundaram wrote: > Now we are going about addressing the issue with specific policies such > as the one recently enacted for IRC conversations. Note that there are > mailing list guidelines at That IRC policy was scoped to the people doing the helping on #fedora, and not project wide. josh From skvidal at fedoraproject.org Mon Jul 28 12:24:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 08:24:09 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728105452.GN6648@localhost.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> Message-ID: <1217247849.4468.15.camel@rosebud> On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: > Something equivalent to the Code Of Conduct that Canonical > implemented. It worked on the ubuntu lists. No reason it would not > work here. I've got no problem with a separate list. I have A LOT of problems with a code of conduct for fedora. -sv From dex.mbox at googlemail.com Mon Jul 28 12:30:32 2008 From: dex.mbox at googlemail.com (dexter) Date: Mon, 28 Jul 2008 13:30:32 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728102615.GC26801@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> Message-ID: <200807281330.32526.dex.mbox@gmail.com> On Mon July 28 2008 11:26:15 Alan Cox wrote: > Seconded. I've given up on the fedora-list for the most part, and its > driving users way from the Fedora project. I don't care if its > fedora-ranting, or just fedora-without-alexanfre-and-les we set up but > soemthing needs doing before it has a debian-legal like toxic effect on the > whole userbase I like the lawless-ness of the fedora-list (it reminds me of just outside my window :-) ). Generally its self policing and its always worked upto now, but Alexandre Oliva was told on this list to STFU and he obliged that aint quite worked on the fedora-list. > That or the fedora board could actually tell them to shut up and kick them > off if they don't I also like the fact this is one list in fedora the board fears to tread. :-) I've seen codes of conduct mentioned in this thread but this requires offical list police, who's up for that? ...dex p.s this is on topic (subj. changed) From aph at redhat.com Mon Jul 28 13:10:14 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jul 2008 14:10:14 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <200807281330.32526.dex.mbox@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> Message-ID: <488DC536.30302@redhat.com> dexter wrote: > On Mon July 28 2008 11:26:15 Alan Cox wrote: >> Seconded. I've given up on the fedora-list for the most part, and its >> driving users way from the Fedora project. I don't care if its >> fedora-ranting, or just fedora-without-alexanfre-and-les we set up but >> soemthing needs doing before it has a debian-legal like toxic effect on the >> whole userbase > > I like the lawless-ness of the fedora-list (it reminds me of just > outside my window :-) ). Generally its self policing and its always > worked upto now, but Alexandre Oliva was told on this list to STFU > and he obliged that aint quite worked on the fedora-list. It surely was on-topic here to talk about whether unfree binary blobs should be included in Fedora. Do we really want to say that if any ethical question arises during discussion on Fedora lists, people may not address it? Andrew. From otaylor at redhat.com Mon Jul 28 13:18:54 2008 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 28 Jul 2008 09:18:54 -0400 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217145603.3151.16.camel@hughsie-work> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> Message-ID: <1217251134.10458.148.camel@localhost.localdomain> On Sun, 2008-07-27 at 09:00 +0100, Richard Hughes wrote: > On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote: > > What do people think... > > I think it looks great. Some comments tho: > > * You are using gpk-install-package-name -- you probably don't want to > call the binary name, you want to call the InstallPackageName DBUS > method -- see http://www.packagekit.org/pk-faq.html#session-methods for > more info. OK, I'll look at switching it over. I actually would like something a little different ... since it isn't 100% clear that clicking somewhere on a web page is going to install a package on your system directly (possibly taking quite some time to download, possibly keeping you from suspending, etc.) I'd really prefer to always show a confirmation dialog like the one you get when there are additional dependencies to install. It would be nice if that was an option through the D-BUS interface. I could obviously pop up a dialog myself but: A) Wouldn't have the download size B) Would suck if there was then also going to be the additional dependencies dialog C) Some hopes of making the plugin GTK+ independent > * You are using the libpackagekit Resolve() -- which is fine, but you're > using the status boolean to check for installed. It's perfectly valid > for PackageKit to emit installed foo-0.1.2, available foo-0.1.3 if there > is a package update available. Maybe one to check for. I'm not sure I understand this comment ... do you mean the enum PackageStatus { IN_PROGRESS, INSTALLED, AVAILABLE, UNAVAILABLE, INSTALLING }; Enumeration? Actually despite this enum, the code does handle INSTALLED and also available for upgrade, since it has separate "availablePackage" and "availableVersion" fields, but it probably would be clearer with a UPGRADABLE status. What I don't do at the moment is show a user interface for that case.. it just look like the INSTALLLED case. I'm not completely sure that handling it is necessary... basically if the user hits that dialog more than infrequently, then the right user interface is "Fix automatic updates on your system!". But certainly you could imagine cases where it might be hit for newly released packages. My main reason for avoiding it was that having multiple links made the UI code considerably trickier :-) I'll take a look at a "_Run 1.2.1 now_. _Upgrade to version 1.2.3_" user interface. > * The destop file checking code is already present in gpk-client-run.c > -- maybe we can share some code there. > > > does this make sense as part of the PackageKit project? > > Yes, but the licence could be tricky. All of stuff in PackageKit has to > be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't > know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things. If you read the details of the license it's actually MPL 1.1/GPL 2.0 or greater/LGPL 2.1 or greater. So stripping down to any GPL or LGPL variety is feasible. I was just keeping things simple by sticking to the tri-license license of the Mozilla stub code. In fact the Mozilla stub code could be eliminated with moderate work if there was a desire to change the license to something oddball or move the codebase from C++ to C. - Owen From alan at redhat.com Mon Jul 28 13:38:41 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jul 2008 09:38:41 -0400 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DC536.30302@redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <20080728133841.GB8681@devserv.devel.redhat.com> On Mon, Jul 28, 2008 at 02:10:14PM +0100, Andrew Haley wrote: > It surely was on-topic here to talk about whether unfree binary blobs > should be included in Fedora. I think it was. But the million message circular arguments about GPL interpretation were most definitely not, and the result of that was that everyone put the participants, subject or even the entire list on kill > Do we really want to say that if any ethical question arises during > discussion on Fedora lists, people may not address it? Do you really want everyone to unsubscribe and run something else. I know many people who left Debian for exactly this reason. From jkeating at redhat.com Mon Jul 28 13:39:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jul 2008 09:39:21 -0400 Subject: Package EVR problems in Fedora 2008-07-26 In-Reply-To: References: <20080726163138.C179D209D2A@releng1.fedora.phx.redhat.com> <1217091882.4394.TMDA@tmda.severn.wwwdotorg.org> <1217194958.6624.7.camel@localhost.localdomain> <1217204394.6624.9.camel@localhost.localdomain> <1217205544.3151.1.camel@localhost.localdomain> Message-ID: <1217252361.3151.9.camel@localhost.localdomain> On Mon, 2008-07-28 at 01:31 +0000, Kevin Kofler wrote: > But enough talking, here's the patch: > http://repo.calcforge.org/f10/check-upgrade-paths.py.diff > Apologies if the code is suboptimal, Python is not my preferred > programming > language. ;-) I'll take a look into this later this week. I appreciate what you're trying to accomplish, and I don't disagree. I've just got alpha to concentrate on right now. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 krh at redhat.com Mon Jul 28 13:39:51 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Mon, 28 Jul 2008 09:39:51 -0400 Subject: Hunspell ABI breakage In-Reply-To: <20080726104900.c769ad67.mschwendt@gmail.com> References: <20080726104900.c769ad67.mschwendt@gmail.com> Message-ID: <1217252391.4283.2.camel@gaara.bos.redhat.com> Thanks for posting the heads up! On Sat, 2008-07-26 at 10:49 +0200, Michael Schwendt wrote: > With hunspell-1.2.4.2-2.fc10 the ABI changed and broke Enchant. > I've bumped and rebuilt Enchant already, but other packages may > need a rebuild, too. > > $ repoquery --whatrequires libhunspell-1.2.so.0 | sort > enchant-1:1.4.2-3.fc10.i386 > hunspell-0:1.2.4.2-2.fc10.i386 > hunspell-devel-0:1.2.4.2-2.fc10.i386 > openoffice.org-core-1:3.0.0-0.0.27.1.fc10.i386 > sunbird-0:0.8-4.fc10.i386 > thunderbird-lightning-0:0.8-4.fc10.i386 > From otaylor at redhat.com Mon Jul 28 13:40:07 2008 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 28 Jul 2008 09:40:07 -0400 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217229137.3151.52.camel@hughsie-work> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> <1217229137.3151.52.camel@hughsie-work> Message-ID: <1217252407.10458.164.camel@localhost.localdomain> [ Adding back the packagekit list CC: ] On Mon, 2008-07-28 at 08:12 +0100, Richard Hughes wrote: > On Sun, 2008-07-27 at 13:33 -0400, Colin Walters wrote: > > On Sun, Jul 27, 2008 at 11:41 AM, Kevin Kofler > > wrote: > > Colin Walters verbum.org> writes: > > > Well, keep in mind that this isn't the same target use case > > as the pk shared > > > libraries; i.e. nothing except Firefox-derived codebases is > > going to be > > > linking in Firefox extensions. > > > > > > Is it an extension or a traditional plugin? Other browsers, > > such as Konqueror, > > can also load classic Mozilla plugins (but not Firefox > > extensions, of course). > > > > Actually you're right, it is a plugin and not an extension. However I > > think the generic-interface exception would apply here (i.e. it > > doesn't count as linking). > > Sure, then I think it makes perfect sense to include this in the > PackageKit source tree. I think it just needs a --enable-mozilla-plugin > in configure.ac and stick the files in contrib/mozilla-plugin > > If we change it to use the dbus interface, then it's not gnome specific > -- and we get the native KDE stuff when the KPackageKit guys implement > the same session interface. It won't be GNOME specific, but it is going to link to at least Glib (for main loop) Pango and Cairo (for drawing the UI) And without some work: GTK+ (to get colors and fonts and X server timestamp) It's pretty hard to build a useful open source OS without having those libraries installed, but maybe people would object to having them as build dependencies of a core system component? (It also depends on the 'mozilla-plugin' .pc file from xulrunner for header files, though that dependency is pretty shallow.) > Plus, putting it in tree allows me to keep it compiling even if we > change API/ABI in the future. Yeah, that definitely is an argument for keeping it in tree. Keeping a separate package for ~1000 lines of real code is a pain. > Could you prepare a patch, of do you want me to have a go? I'll probably do a couple of more revision as a standalone thing to cover some of the points you brought up in your other mail, and then we can discuss moving forward from there. - Owen From anders at trudheim.co.uk Mon Jul 28 13:42:05 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 15:42:05 +0200 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DC536.30302@redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <20080728134205.GU6648@localhost.localdomain> * Andrew Haley [20080728 15:10]: [snip] > It surely was on-topic here to talk about whether unfree binary blobs > should be included in Fedora. About the technical implementation, sure. How do you 'devel'op the mechanism to separate out the firmware and still be able to deliver it. > Do we really want to say that if any ethical question arises during > discussion on Fedora lists, people may not address it? Then migrate the subsequent flame-fest and inflamatory statements to fedora-political, fedora-flames or fedora-legal ? Let it rot in peace in obscurity, where such quasi-religious discussions belong. The .advocacy groups on usenet is well known for being the playground to hone your argumentation skills. Do we want fedora-list (where users ask for help) or fedora-devel (where serious development discussions are supposed to take place) to be this playground? I'd be somewhat surprised if anyone answered yes to that question. /Anders From maximilianbianco at gmail.com Mon Jul 28 13:46:14 2008 From: maximilianbianco at gmail.com (max) Date: Mon, 28 Jul 2008 09:46:14 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728070051.GC6648@localhost.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> <20080728070051.GC6648@localhost.localdomain> Message-ID: <488DCDA6.3010600@gmail.com> Anders Karlsson wrote: > * Jeff Spaleta [20080728 08:39]: >> On Sun, Jul 27, 2008 at 9:40 PM, Anders Karlsson wrote: >>> The threads that Gilboa mentions is the sole reason I implemented >>> Sieve in my mailserver at home. fedora-devel and fedora-list became >>> interesting and useful about as soon as those threads were filtered >>> out. >>> >>> Read in to it what you want. >> You miss my point. Are these discussions valuable or not. If they >> are not... then we shouldn't make a place for them.... period. I >> don't see anyone who actually standing up and saying these things are >> valued and thus worth preparing a special place for in our resource >> pool. If we are only considering making more channels so some of us >> can ignore others among us because they are talking about things we >> don't care about... I'm not prepared to support that. > > I see what you mean. > > Are the discussions in question valuable? No, they are about as useful > as a chocolate teapot. > Speak for yourself. >> I'll consider supporting additional dedicated communications channel >> for things when the people who find value in the discussion in >> question ask for a dedicated list. They must be able to make the case >> that such dedicated communication will actually be useful in helping a >> team of people work together towards some identified task or goal >> which helps moves the project forward. > > Cool, I'll carry on with the kill-lists then. If any of the > participants would ever consider contributing anything remotely > valuable in future, I'll remain in blissful ignorance. Despite me > participating in one or two of the threads, I consider them to be > ultimately harmful to the Fedora Project, and to Red Hat, a point I > have stated. > How can a discussion of open source and the GPL be harmful to Fedora or Red Hat? In what bizarro universe does that even begin to make sense. People that don't find the conversation useful should ignore it, that is after all what mail filters were created to do. People that understand and respect freedom don't advocate censorship in any form. If you don't have the discipline to ignore the conversation then that's your problem. I am willing to accept that perhaps I have missed the point of the Fedora Project entirely. So maybe one of you generous souls could enlighten me. -Max -- Fortune favors the BOLD From pingou at pingoured.fr Mon Jul 28 13:50:19 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 28 Jul 2008 15:50:19 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DCDA6.3010600@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> <20080728070051.GC6648@localhost.localdomain> <488DCDA6.3010600@gmail.com> Message-ID: <488DCE9B.9010101@pingoured.fr> max wrote: > Anders Karlsson wrote: >> * Jeff Spaleta [20080728 08:39]: >>> On Sun, Jul 27, 2008 at 9:40 PM, Anders Karlsson >>> wrote: >>>> The threads that Gilboa mentions is the sole reason I implemented >>>> Sieve in my mailserver at home. fedora-devel and fedora-list became >>>> interesting and useful about as soon as those threads were filtered >>>> out. >>>> >>>> Read in to it what you want. >>> You miss my point. Are these discussions valuable or not. If they >>> are not... then we shouldn't make a place for them.... period. I >>> don't see anyone who actually standing up and saying these things are >>> valued and thus worth preparing a special place for in our resource >>> pool. If we are only considering making more channels so some of us >>> can ignore others among us because they are talking about things we >>> don't care about... I'm not prepared to support that. >> >> I see what you mean. >> >> Are the discussions in question valuable? No, they are about as useful >> as a chocolate teapot. >> > Speak for yourself. > >>> I'll consider supporting additional dedicated communications channel >>> for things when the people who find value in the discussion in >>> question ask for a dedicated list. They must be able to make the case >>> that such dedicated communication will actually be useful in helping a >>> team of people work together towards some identified task or goal >>> which helps moves the project forward. >> >> Cool, I'll carry on with the kill-lists then. If any of the >> participants would ever consider contributing anything remotely >> valuable in future, I'll remain in blissful ignorance. Despite me >> participating in one or two of the threads, I consider them to be >> ultimately harmful to the Fedora Project, and to Red Hat, a point I >> have stated. >> > How can a discussion of open source and the GPL be harmful to Fedora or > Red Hat? > In what bizarro universe does that even begin to make sense. > People that don't find the conversation useful should ignore it, that > is after all what mail filters were created to do. Sure let's create new filter for each thread that I can not read because - I do not have the time to follow - I do not have the knowledge to understand hm... I gonna like it ! Pierre From hughsient at gmail.com Mon Jul 28 13:50:25 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 28 Jul 2008 14:50:25 +0100 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217251134.10458.148.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> <1217251134.10458.148.camel@localhost.localdomain> Message-ID: <1217253025.3556.30.camel@hughsie-work> On Mon, 2008-07-28 at 09:18 -0400, Owen Taylor wrote: > On Sun, 2008-07-27 at 09:00 +0100, Richard Hughes wrote: > > On Thu, 2008-07-24 at 14:39 -0400, Owen Taylor wrote: > > > What do people think... > > > > I think it looks great. Some comments tho: > > > > * You are using gpk-install-package-name -- you probably don't want to > > call the binary name, you want to call the InstallPackageName DBUS > > method -- see http://www.packagekit.org/pk-faq.html#session-methods for > > more info. > > OK, I'll look at switching it over. Cool, yell if you get stuck. > I actually would like something a little different ... since it isn't > 100% clear that clicking somewhere on a web page is going to install a > package on your system directly (possibly taking quite some time to > download, possibly keeping you from suspending, etc.) I'd really prefer > to always show a confirmation dialog like the one you get when there > are additional dependencies to install. It would be nice if that was > an option through the D-BUS interface. Right at the moment the DBUS interface honours the "don't show me this again" checkbox that you might have already clicked. > I could obviously pop up a dialog myself but: > > A) Wouldn't have the download size > B) Would suck if there was then also going to be the additional > dependencies dialog > C) Some hopes of making the plugin GTK+ independent Right. > > * You are using the libpackagekit Resolve() -- which is fine, but you're > > using the status boolean to check for installed. It's perfectly valid > > for PackageKit to emit installed foo-0.1.2, available foo-0.1.3 if there > > is a package update available. Maybe one to check for. > > I'm not sure I understand this comment ... do you mean the > > enum PackageStatus { IN_PROGRESS, INSTALLED, AVAILABLE, UNAVAILABLE, INSTALLING }; > > Enumeration? Actually despite this enum, the code does handle INSTALLED > and also available for upgrade, since it has separate "availablePackage" > and "availableVersion" fields, but it probably would be clearer with > a UPGRADABLE status. Ahh right. > What I don't do at the moment is show a user interface for that case.. > it just look like the INSTALLLED case. I'm not completely sure that > handling it is necessary... basically if the user hits that dialog > more than infrequently, then the right user interface is > "Fix automatic updates on your system!". But certainly you could imagine > cases where it might be hit for newly released packages. My main > reason for avoiding it was that having multiple links made the UI > code considerably trickier :-) Understood. > I'll take a look at a "_Run 1.2.1 now_. _Upgrade to version 1.2.3_" > user interface. That would rock. > > * The destop file checking code is already present in gpk-client-run.c > > -- maybe we can share some code there. > > > > > does this make sense as part of the PackageKit project? > > > > Yes, but the licence could be tricky. All of stuff in PackageKit has to > > be (L)GPLv2+ -- I can't confess to being a licence expert, so I don't > > know how MPL 1.1/GPL 2.0/LGPL 2.1 would affect things. > > If you read the details of the license it's actually MPL 1.1/GPL 2.0 or > greater/LGPL 2.1 or greater. So stripping down to any GPL or LGPL > variety is feasible. I was just keeping things simple by sticking to the > tri-license license of the Mozilla stub code. Right. > In fact the Mozilla stub code could be eliminated with moderate work if > there was a desire to change the license to something oddball or move > the codebase from C++ to C. I would love it to move to C, but I didn't ask as I figured this was too much work. I can do C++, but I much prefer C for this low level stuff. Richard. From hughsient at gmail.com Mon Jul 28 13:52:00 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 28 Jul 2008 14:52:00 +0100 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217252407.10458.164.camel@localhost.localdomain> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> <1217229137.3151.52.camel@hughsie-work> <1217252407.10458.164.camel@localhost.localdomain> Message-ID: <1217253120.3556.33.camel@hughsie-work> On Mon, 2008-07-28 at 09:40 -0400, Owen Taylor wrote: > It won't be GNOME specific, but it is going to link to at least > > Glib (for main loop) > Pango and Cairo (for drawing the UI) > > And without some work: > > GTK+ (to get colors and fonts and X server timestamp) I think glib, pango and gtk+ are fine. > (It also depends on the 'mozilla-plugin' .pc file from xulrunner > for header files, though that dependency is pretty shallow.) Fine for me. > > Plus, putting it in tree allows me to keep it compiling even if we > > change API/ABI in the future. > > Yeah, that definitely is an argument for keeping it in tree. Keeping a > separate package for ~1000 lines of real code is a pain. Agreed. > I'll probably do a couple of more revision as a standalone thing to > cover some of the points you brought up in your other mail, and then we > can discuss moving forward from there. Excellent. If you send me your public ssh key as an attachment and chosen username I'll add you to the commit group on packagekit.org. Thanks, Richard. From gilboad at gmail.com Mon Jul 28 14:04:18 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 28 Jul 2008 17:04:18 +0300 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DC536.30302@redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <1217253858.22766.16.camel@gilboa-work-dev.localdomain> On Mon, 2008-07-28 at 14:10 +0100, Andrew Haley wrote: > dexter wrote: > > On Mon July 28 2008 11:26:15 Alan Cox wrote: > >> Seconded. I've given up on the fedora-list for the most part, and its > >> driving users way from the Fedora project. I don't care if its > >> fedora-ranting, or just fedora-without-alexanfre-and-les we set up but > >> soemthing needs doing before it has a debian-legal like toxic effect on the > >> whole userbase > > > > I like the lawless-ness of the fedora-list (it reminds me of just > > outside my window :-) ). Generally its self policing and its always > > worked upto now, but Alexandre Oliva was told on this list to STFU > > and he obliged that aint quite worked on the fedora-list. > > It surely was on-topic here to talk about whether unfree binary blobs > should be included in Fedora. Sure. But not in -devel and not -users. > > Do we really want to say that if any ethical question arises during > discussion on Fedora lists, people may not address it? > Again, ethical/political/etc questions have no place in an ML that -should- be dedicated to users who seek help. I doubt that they even have place in -testing and/or -devel. I've been subscribed to fedora-* more-or-less since FC2. For the first time in years I'm thinking about unsubscribing. - Gilboa From tom at impact-crater.com Mon Jul 28 14:29:00 2008 From: tom at impact-crater.com (Tom Rivers) Date: Mon, 28 Jul 2008 10:29:00 -0400 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217253858.22766.16.camel@gilboa-work-dev.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> Message-ID: <488DD7AC.2040607@impact-crater.com> On 7/28/2008 10:04 AM, Gilboa Davara wrote: > Again, ethical/political/etc questions have no place in an ML that > -should- be dedicated to users who seek help. I doubt that they even > have place in -testing and/or -devel. > > I've been subscribed to fedora-* more-or-less since FC2. > For the first time in years I'm thinking about unsubscribing I've been on these lists from the early days as well. I've seen some interesting discussions, however I was never under the impression that this was as big of a problem as some people seem to portray it. Does anyone have any metrics on how many of these "inappropriate" threads there truly are in relation to how many are "appropriate"? I think it would help make this issue much more clear. For example, if we are talking about less than 1% of all posts are "inappropriate", then that is a heck of a lot different than if it is 35%. Similarly, if there are say 10,000 posts in a month, 1% is a bigger problem than if there are only 100 posts per month. So, do we have some actual numbers or is it just a "gut feel"? Tom From dsd at laptop.org Mon Jul 28 14:33:12 2008 From: dsd at laptop.org (Daniel Drake) Date: Mon, 28 Jul 2008 10:33:12 -0400 Subject: trouble building OLPC's evince fork Message-ID: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> Hi, I'm new to RPM building, so apologies if I am missing anything obvious. For OLPC we need to build our forked version of evince. Our forked version is a little out of date, and requires a poppler version older than the one in F9. We'll update our evince fork and hopefully get things upstreamed soon, but for now we need things working for our efforts to stabilise our new software builds. So, I first built our old poppler version in the OLPC-3 disttag, as poppler-0.6.2-5.olpc3: http://koji.fedoraproject.org/koji/buildinfo?buildID=57583 That seems to have worked. Next, locally, I have modified our sugar-evince spec file to do this: %define poppler_version 0.6.2-5 BuildRequires: poppler-devel = %{poppler_version} I tried to scratch build it, but it failed: http://koji.fedoraproject.org/koji/taskinfo?taskID=743472 The error seems to be: DEBUG util.py:250: No Package Found for poppler-devel = 0.6.2-5 Why is it unable to find that build? What am I missing? Thanks, Daniel From jvonau at shaw.ca Mon Jul 28 14:33:51 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Mon, 28 Jul 2008 09:33:51 -0500 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <1217255631.25653.83.camel@S010600e029961c54.wp.shawcable.net> Martin Langhoff wrote: > On Mon, Jul 28, 2008 at 4:52 AM, Jerry Vonau wrote: >> Your cc to the livecd list are not appearing there, are you subscribed? > > No - I thought it was an open list. I'll sub... > So did I.... > ... >> Think the issue is going to be how the kernel modules differ from >> version 3.2 and 3.3 of squashfs-tools. >> >> So lets get this clear, F7 is using the 2.6.23.?? and does not boot, >> F8 is now booting correctly? with which kernel? > > Correct. This is with 2.6.23.1-21.fc7 > >> Think the only way you'll get this to fly is to get the source for >> squashfs-tools3.3 http://www.squashfs-lzma.org/dl/squashfs3.3.tar.gz >> and patch your 2.6.23 kernel and recompile the module and replace the >> module in the initrd. > > Thanks for pointing me to lzma. So the squashfs 3.3 on F9 is patched > to have lzma support? Good to know... after a bit of investigation, it > turns out that between 3.2 and 3.3 the squashfs project took the lzma > pactches, and forgot to mention it in the changelog. How misterious > and cute :-/ > Hold it, lzma is not part of Fedora's squash support, but could be patched it. The link just has all the steps the are needed to patch a kernel, then recompile the kernel's modules. Just happens to be squashfs as the example. ;-) There is something "cute" between 3.2 and 3.3 thou... > After a bit of testing, squashfs-3.2 on F9 produces a squashfs I can > mount on F7. > > But the image still does not boot. Something else in the initrd must > be messing up. What is the message now? Jerry From debarshi.ray at gmail.com Mon Jul 28 14:45:51 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon, 28 Jul 2008 20:15:51 +0530 Subject: trouble building OLPC's evince fork In-Reply-To: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> References: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> Message-ID: <3170f42f0807280745i4b73aaf6he6448bc9f1f90583@mail.gmail.com> Looks like the poppler you just built is not yet in the Koji buildroots. You could try a chain build [1] in this case. Happy hacking, Debarshi [1] http://fedoraproject.org/wiki/Koji/UsingKoji#Chained_builds From rdieter at math.unl.edu Mon Jul 28 14:49:37 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 28 Jul 2008 09:49:37 -0500 Subject: trouble building OLPC's evince fork References: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> Message-ID: Daniel Drake wrote: > So, I first built our old poppler version in the OLPC-3 disttag, as > poppler-0.6.2-5.olpc3: > http://koji.fedoraproject.org/koji/buildinfo?buildID=57583 > That seems to have worked. > > Next, locally, I have modified our sugar-evince spec file to do this: > > %define poppler_version 0.6.2-5 > BuildRequires: poppler-devel = %{poppler_version} > > I tried to scratch build it, but it failed: > http://koji.fedoraproject.org/koji/taskinfo?taskID=743472 NOTE: 0.6.2-5 != 0.6.2-5.olpc3 :) -- Rex From walters at verbum.org Mon Jul 28 15:00:34 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 28 Jul 2008 11:00:34 -0400 Subject: [packagekit] A PackageKit browser plugin In-Reply-To: <1217253025.3556.30.camel@hughsie-work> References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> <1217251134.10458.148.camel@localhost.localdomain> <1217253025.3556.30.camel@hughsie-work> Message-ID: On Mon, Jul 28, 2008 at 9:50 AM, Richard Hughes wrote: > > > Right at the moment the DBUS interface honours the "don't show me this > again" checkbox that you might have already clicked. > This is only tangentially related, but we really should move away from the "don't show again" buttons - either the notification is useful, and you should see it, or it's not useful, and you shouldn't see it. We could also just be smarter about when the notification appears - for example, security updates as soon as they're available, other updates once a day at most, etc. The other problem with them is that if you accidentally click "don't show again", there is no obvious way to undo that operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Mon Jul 28 15:01:26 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jul 2008 11:01:26 -0400 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> Message-ID: <1217257286.12821.15.camel@aglarond.local> On Sat, 2008-07-26 at 16:25 +1200, Martin Langhoff wrote: > When livecd-creator tries to unmount the CD, two processes are still > running - httpd, and a custom network daemon written in python. lsof > shows them as the only processes keeping files open. Once I kill those > processes, I can unmount cleanly. > > Is this expected? If you start a process in your %post, then you need to clean up after yourself at the end of %post > Are any incompatibilities with F7 known? Should > livecd-creator try to run all the relevant init scripts with stop, and > perhaps run lsof to see if any programs need to be killed or > kill-9'ed? How do you know what's relevant? Packaging policy states (for reasons including this one) that services shouldn't be started in the %post of a package install. Which means that it's something you're starting yourself. Which means you need to kill it off also. > The boot failures (fails to load the kernel modules, and kills init) > probably have to do with the image being incomplete. Will leave this as a reply for some of your later mails... Jeremy From katzj at redhat.com Mon Jul 28 15:06:43 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jul 2008 11:06:43 -0400 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807262210xde7f013qcd859bfce5f0b526@mail.gmail.com> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> <46a038f90807252321r5ca3cb4wd9f16ef682a2ecd9@mail.gmail.com> <46a038f90807262025y4aa49c2fyda00d383680d497@mail.gmail.com> <46a038f90807262210xde7f013qcd859bfce5f0b526@mail.gmail.com> Message-ID: <1217257603.12821.21.camel@aglarond.local> On Sun, 2008-07-27 at 17:10 +1200, Martin Langhoff wrote: > On Sun, Jul 27, 2008 at 3:25 PM, Martin Langhoff > wrote: > > After a bit more investigation. the livecd-tools package in F9 > > (017.1-1.fc9) can only build F9 correctly, and the problem boils down > > to incorrect placement of the .ko files in the initrd. Here is how to > > repro with F9 vs F7. In my testing, F8 shows the same problems. > > I tracked this down to the switch from mayflower to mkinitrd, which > lead me to commit > 11dbd0bb5ba4b845e80109e990e4e780ca402218 where mayflower gets > installed and called during %post. Yes, if you are building for newer than Fedora 9's mkinitrd, then you have to do the initrd build by hand as you've done. This is because this had no place being in livecd-creator to begin with really. I updated the stock configs and put blinking warnings in the commit log for that reason :-) > WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device for / This is a warning that I should just kill. In fact, done :-) > ... > starting udevd > creating devices > waiting for system to settle > ... > SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem > SQUASHFS error: Please update your kernel > mount: wrong fstype ... squashfs is (still) notorious about changing things, unfortunately -- although I'd think that the current F7 update kernel would have a new enough squashfs in the kernel for the squashfs-tools. Unfortunately, the only real way to be able to handle this is 1) Install an older version of squashfs-tools on your build host 2) Build your image without compression (--skip-compression) 3) Have a kernel with a newer squashfs kernel module Jeremy From katzj at redhat.com Mon Jul 28 15:07:47 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jul 2008 11:07:47 -0400 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> References: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> Message-ID: <1217257667.12821.22.camel@aglarond.local> On Mon, 2008-07-28 at 11:44 +1200, Martin Langhoff wrote: > On Mon, Jul 28, 2008 at 4:52 AM, Jerry Vonau wrote: > > Your cc to the livecd list are not appearing there, are you subscribed? > > No - I thought it was an open list. I'll sub... Due to a ridiculous amount of spam, posts are limited to members only and everything else just gets dropped. Anything else is just not practical at this point for most lists :-/ Jeremy From jvonau at shaw.ca Mon Jul 28 15:03:02 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Mon, 28 Jul 2008 10:03:02 -0500 Subject: livecd-creator unmounting temp image, running daemons. Message-ID: <1217257382.25653.108.camel@S010600e029961c54.wp.shawcable.net> Martin Langhoff wrote: > On Mon, Jul 28, 2008 at 7:13 AM, Jerry Vonau wrote: >>> How about not running the school server on an OS which gets no more >> upgrades, >>> not even critical security upgrades??? Fedora 7 is no longer >> supported, so of >>> course there will be no efforts made to make modern live CD tools work >> with it. > > I can understand Kevin's sentiments, but at the time we are in > development, and the port to F9 is a major undertaking that I cannot > focus on right now. We will tackle it, but there are more pressing > needs. > > And some of the stuff we have on F7 will be really hard to reimplement > on F9 - if anyone is keen on lending a hand with porting our odd > network setup scripts to F9, he or she will earn my deepest thanks. > And possibly a gig with us too if desired :-) > Networking, right up my ally, I don't think you would need to change anything, just don't use NetworkManager. I'll have a look, off list, if you like. >> Yea, you should try to get "School Server image" working as a "spin". >> Have you tried the --base-on= option to livecd-tools and try to re-spin, >> with the f7 live disk as the source, with a later distro? This, I think, >> would be the same as doing a yum upgrade on the F7 release and >> re-rolling it. > > Is there a "base" commandline liveCD for F7? Our current spin is a > X-less server setup. > The livecd-fedora-minimal.ks is X-less. What base-on= does, is when the new ext3 filesystem is created for the new cd, the old filesystem is copied over before any rpms are installed. Then more or less does a "yum upgrade" is done on the old setup, and the new iso is created. I'd try the minimal.ks(might need a bit of fiddling) with the base-on= pointing to your old livecd. Just a thought, Jerry From katzj at redhat.com Mon Jul 28 15:08:45 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jul 2008 11:08:45 -0400 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <46a038f90807272041h5ca0e168ocad1dfca5ac41e68@mail.gmail.com> References: <1217177555.25653.40.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807271644t524c9a31s798ec84f9240dbb5@mail.gmail.com> <46a038f90807272041h5ca0e168ocad1dfca5ac41e68@mail.gmail.com> Message-ID: <1217257725.12821.23.camel@aglarond.local> On Mon, 2008-07-28 at 15:41 +1200, Martin Langhoff wrote: > On Mon, Jul 28, 2008 at 11:44 AM, Martin Langhoff > wrote: > > After a bit of testing, squashfs-3.2 on F9 produces a squashfs I can > > mount on F7. > > > > But the image still does not boot. Something else in the initrd must > > be messing up. > > FWIW, I can build the liveCD inside mock -r fedora-7-i386, as long as > I add the (undeclared) kudzu dependency and mknod a loop device. > > It looks like only F7 livecd-tools can build F7 livecds -- I perceive > livecd-tools to be a build tool so my expectations (perhaps misplaced) > were of more flexibility. Progress is being made on making things a bit more flexible about building across versions, but when tools that we call don't maintain compatibility, there's little we can do :-/ Jeremy From kevin.kofler at chello.at Mon Jul 28 15:20:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jul 2008 15:20:54 +0000 (UTC) Subject: [packagekit] A PackageKit browser plugin References: <1216924774.10458.93.camel@localhost.localdomain> <1217145603.3151.16.camel@hughsie-work> <1217229137.3151.52.camel@hughsie-work> <1217252407.10458.164.camel@localhost.localdomain> Message-ID: Owen Taylor redhat.com> writes: > Glib (for main loop) > Pango and Cairo (for drawing the UI) [...] > GTK+ (to get colors and fonts and X server timestamp) > > It's pretty hard to build a useful open source OS without having those > libraries installed, but maybe people would object to having them as > build dependencies of a core system component? For the KDE spin, we have a bazillion other things which drag in GTK+ (and thus also the other stuff) anyway, so it won't make a big difference for us. Kevin Kofler From dsd at laptop.org Mon Jul 28 15:29:04 2008 From: dsd at laptop.org (Daniel Drake) Date: Mon, 28 Jul 2008 11:29:04 -0400 Subject: trouble building OLPC's evince fork In-Reply-To: References: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> Message-ID: <1217258944.2740.12.camel@olpc-desktop01.laptop.org> On Mon, 2008-07-28 at 09:49 -0500, Rex Dieter wrote: > > I tried to scratch build it, but it failed: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=743472 > > NOTE: 0.6.2-5 != 0.6.2-5.olpc3 Thanks! That was the problem. Daniel From kevin.kofler at chello.at Mon Jul 28 15:37:49 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jul 2008 15:37:49 +0000 (UTC) Subject: trouble building OLPC's evince fork References: <1217255592.2740.10.camel@olpc-desktop01.laptop.org> Message-ID: Daniel Drake laptop.org> writes: > For OLPC we need to build our forked version of evince. Our forked > version is a little out of date, and requires a poppler version older > than the one in F9. While actually using the new Poppler's features requires more work, simply getting it to build with it shouldn't be that much work. AFAICT you only need this changeset, which is fairly small: http://svn.gnome.org/viewvc/evince?view=revision&revision=2965 and this one (just a trivial fix) too if you want it to still work with the old poppler: http://svn.gnome.org/viewvc/evince?view=revision&revision=2967 (I know this isn't the question you asked, but Rex Dieter already answered that one. ;-) ) Kevin Kofler From gilboad at gmail.com Mon Jul 28 16:06:59 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 28 Jul 2008 19:06:59 +0300 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DD7AC.2040607@impact-crater.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <488DD7AC.2040607@impact-crater.com> Message-ID: <1217261219.22766.25.camel@gilboa-work-dev.localdomain> On Mon, 2008-07-28 at 10:29 -0400, Tom Rivers wrote: > On 7/28/2008 10:04 AM, Gilboa Davara wrote: > > Again, ethical/political/etc questions have no place in an ML that > > -should- be dedicated to users who seek help. I doubt that they even > > have place in -testing and/or -devel. > > > > I've been subscribed to fedora-* more-or-less since FC2. > > For the first time in years I'm thinking about unsubscribing > > I've been on these lists from the early days as well. I've seen some > interesting discussions, however I was never under the impression that > this was as big of a problem as some people seem to portray it. Does > anyone have any metrics on how many of these "inappropriate" threads > there truly are in relation to how many are "appropriate"? I think it > would help make this issue much more clear. For example, if we are > talking about less than 1% of all posts are "inappropriate", then that > is a heck of a lot different than if it is 35%. Similarly, if there are > say 10,000 posts in a month, 1% is a bigger problem than if there are > only 100 posts per month. > > So, do we have some actual numbers or is it just a "gut feel"? > > > Tom I don't have solid numbers, but at least according to my gmail trash contents, around ~1/4-1/5 of the posts that were sent to -users between, say, Tuesday and Saturday belonged to one of the 4 "GPL" threads. ... And even if I'm wrong by an order of magnitude, and we are only talking about 10% of all the -users traffic, given the fact that these threads are off-topic to being with, this is way-too-much. - Gilboa From lyos.gemininorezel at gmail.com Mon Jul 28 16:11:50 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Mon, 28 Jul 2008 12:11:50 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217247849.4468.15.camel@rosebud> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> Message-ID: <488DEFC6.8080809@gmail.com> seth vidal wrote: > On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: > >> Something equivalent to the Code Of Conduct that Canonical >> implemented. It worked on the ubuntu lists. No reason it would not >> work here. >> > > I've got no problem with a separate list. I have A LOT of problems with > a code of conduct for fedora. > > -sv I agree with Seth. Most of the "flame-fest" threads mentioned, while mostly boring, idiotic, and several other adjectives I can think of... they do, on occaision, produce *something* of value, albeit rarely. Shall we ban idiots, simply because they're moronic? How about we just shoot 90% of the world and be done with it? Jeff Spaleta wrote: > You miss my point. Are these discussions valuable or not. If they > are not... then we shouldn't make a place for them.... period. I > don't see anyone who actually standing up and saying these things are > valued and thus worth preparing a special place for in our resource > pool. If we are only considering making more channels so some of us > can ignore others among us because they are talking about things we > don't care about... I'm not prepared to support that. > > I'll consider supporting additional dedicated communications channel > for things when the people who find value in the discussion in > question ask for a dedicated list. They must be able to make the case > that such dedicated communication will actually be useful in helping a > team of people work together towards some identified task or goal > which helps moves the project forward. > > -jef"I never read what I write, my spam filter it smart enough to flag > my own posts as trash"spaleta > > They are *sometimes* valuable... in the sense of a room full of monkeys on a typewriter will eventually produce the works of Shakespear. I'd seriously consider supporting it... if for no other reason than the rare pearl it'll produce. max wrote: > How can a discussion of open source and the GPL be harmful to Fedora > or Red Hat? > In what bizarro universe does that even begin to make sense. > People that don't find the conversation useful should ignore it, that > is after all what mail filters were created to do. > People that understand and respect freedom don't advocate censorship > in any form. If you don't have the discipline to ignore the > conversation then that's your problem. > > I am willing to accept that perhaps I have missed the point of the > Fedora Project entirely. So maybe one of you generous souls could > enlighten me. > > > -Max I could not have stated that better myself. If ya'll are going to insist on censorship and bureaucracy... please let me know... I've got a lot of other distros to look at if that's the case. I've been around Fedora/Redhat since ~1998/9... mostly because I'm stubborn... and I'd really hate to have to kick it to the curb. No Censorship in *ANY* form... period. Lyos Gemini Norezel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jul 28 16:32:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Jul 2008 11:32:58 -0500 (CDT) Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DEFC6.8080809@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> Message-ID: On Mon, 28 Jul 2008, Lyos Gemini Norezel wrote: > seth vidal wrote: > > On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: > > > Something equivalent to the Code Of Conduct that Canonical > implemented. It worked on the ubuntu lists. No reason it would not > work here. > It did? http://www.fabianrodriguez.com/blog/archives/2008/07/21/have-you-noticed-a-friendly-reminder/ -Mike From jspaleta at gmail.com Mon Jul 28 17:29:51 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Jul 2008 09:29:51 -0800 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728102723.GD26801@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> <20080728102723.GD26801@devserv.devel.redhat.com> Message-ID: <604aa7910807281029q789f9789ubdd13ed9bc7bed9b@mail.gmail.com> On Mon, Jul 28, 2008 at 2:27 AM, Alan Cox wrote: > Wrong. Very wrong. > > If there is a mountain of turd flowing through your house do you > > - decide it isn't valuable and leave it to flow I never said that i was going to specifically condone it. I said I'm not going to support making a specific space for it. If its not constructive then perhaps it shouldn't be happening in the controlled space of this project. There is no direct mandate or requirement that we allow or condone all speech. If someone wants to propose a reasonable and fair moderation scheme and the manpower to sustain it.. they are free to do that. > > - provide somewhere else for it to go so that you can use your house again It has the whole internet to go to. I certainly do not have to provide that somewhere else if I do not value the discussion. -jef"Like my local bartender says: you don't have to go home, but you can't stay here"spaleta From bnocera at redhat.com Mon Jul 28 17:39:11 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 28 Jul 2008 18:39:11 +0100 Subject: Rawhide Orphanarium Purged In-Reply-To: <1217032215.4646.15.camel@ruth> References: <4889F4C6.2030000@redhat.com> <1217032215.4646.15.camel@ruth> Message-ID: <1217266751.3080.544.camel@cookie.hadess.net> On Sat, 2008-07-26 at 10:30 +1000, Andrew Bartlett wrote: > On Fri, 2008-07-25 at 11:44 -0400, Warren Togami wrote: > > > nautilus-share > > The purpose of this tool is to make it easier to share folders with > windows clients (using Samba) - users get the ability to share their own > folders. > > It is sad to see it so unloved, but it really needs to be part of the > default configuration of the Samba deamon (as having to edit the > smb.conf is the part it was trying to avoid). > > It would be nice to see a Fedora owner for it again some day, them maybe > Samba won't be the target of the linux-hater as much :-) > > http://linuxhaters.blogspot.com/2008/07/of-silos-and-samba.html > > (I think this tool got written when SuSE was working really hard on > making this stuff 'just work' for their distribution). The problem is that the implementation is broken in a number of ways. From jspaleta at gmail.com Mon Jul 28 17:46:44 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Jul 2008 09:46:44 -0800 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217253858.22766.16.camel@gilboa-work-dev.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> Message-ID: <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> On Mon, Jul 28, 2008 at 6:04 AM, Gilboa Davara wrote: > Sure. > But not in -devel and not -users. Just a point of fact... fedora-list is not spelled fedora-users-list. Perhaps the people are asking for the wrong solution to the wrong problem. Perhaps fedora-list is meant to be widely scoped, and perhaps people want a narrow list focused just on users. I wonder what such a list would end up being named? I'll drop my hint just one more time. I'm perfectly happy to support the creation of lists for specific constructive purposes. If you feel fedora-list isn't servicing a specific purpose well, perhaps you and others can manage the creation of a new list, specific in scope, to the user issues that you actually care about, instead of attempting to muscle noisy discussions to a new place. -jef From markg85 at gmail.com Mon Jul 28 17:50:57 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jul 2008 19:50:57 +0200 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <47E7DAE9.3020001@inetwork.ru> <47EA96DB.9080906@leemhuis.info> <47EA9A06.2090106@inetwork.ru> <47EB243B.2000103@gmail.com> <6e24a8e80803270345l3d4d6583l3d87e7e11a511043@mail.gmail.com> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> Message-ID: <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> On Fri, Apr 4, 2008 at 7:12 PM, Mark wrote: > 2008/4/4, Callum Lerwick : >> >> On Thu, 2008-03-27 at 20:23 +0100, Mark wrote: >> > About the language it needs to be written in.. (Python).. byw bye >> > oppertunity for me to make it unless i learn python :) i do know Java >> > and PHP. >> >> >> Seriously, just learn Python. Java should have already taught you OOP, >> and PHP should have already taught you loosely-typed "script" style >> programming, and the use of lists and hashes as fundamental data types, >> and that's maybe 95% of what underlies Python you know already. >> > I have enough on my todo list already for the coming months. > python together with this project isn't high on it. i'm more then > willing to help when needed but not a full time SoC application. I > will help in: > - template stuff > - mocking the design up > - ajax technology stuff > > And there is more then enough to do in those 3 alone. > When you (the one who is gonna do this project) need my help on this > just drop me a line and i will give it my best shot. > Hey all, This thread kinda died after my last post but i'm really wondering how this project stands now at this moment in the middle of the GSoC. If it made it in in the first place.. where i can track the development.. things like that. O btw. i still am more then willing to help with it! I hope to hear about this project. Mark. From pemboa at gmail.com Mon Jul 28 17:54:30 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 28 Jul 2008 12:54:30 -0500 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <47EA96DB.9080906@leemhuis.info> <47EA9A06.2090106@inetwork.ru> <47EB243B.2000103@gmail.com> <6e24a8e80803270345l3d4d6583l3d87e7e11a511043@mail.gmail.com> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> Message-ID: <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> On Mon, Jul 28, 2008 at 12:50 PM, Mark wrote: > On Fri, Apr 4, 2008 at 7:12 PM, Mark wrote: >> 2008/4/4, Callum Lerwick : >>> >>> On Thu, 2008-03-27 at 20:23 +0100, Mark wrote: >>> > About the language it needs to be written in.. (Python).. byw bye >>> > oppertunity for me to make it unless i learn python :) i do know Java >>> > and PHP. >>> >>> >>> Seriously, just learn Python. Java should have already taught you OOP, >>> and PHP should have already taught you loosely-typed "script" style >>> programming, and the use of lists and hashes as fundamental data types, >>> and that's maybe 95% of what underlies Python you know already. >>> >> I have enough on my todo list already for the coming months. >> python together with this project isn't high on it. i'm more then >> willing to help when needed but not a full time SoC application. I >> will help in: >> - template stuff >> - mocking the design up >> - ajax technology stuff >> >> And there is more then enough to do in those 3 alone. >> When you (the one who is gonna do this project) need my help on this >> just drop me a line and i will give it my best shot. >> > > Hey all, > > This thread kinda died after my last post but i'm really wondering how > this project stands now at this moment in the middle of the GSoC. If > it made it in in the first place.. where i can track the development.. > things like that. > > O btw. i still am more then willing to help with it! > > I hope to hear about this project. > Mark. The student who applied for this did not have their application accepted. I guess they decided not to do it otherwise. I myself have not had the time to try it. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From lists at bress.net Mon Jul 28 17:57:43 2008 From: lists at bress.net (Josh Bressers) Date: Mon, 28 Jul 2008 13:57:43 -0400 (EDT) Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DEFC6.8080809@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> Message-ID: <41413.24.208.214.89.1217267863.squirrel@www.bress.net> On Mon, July 28, 2008 12:11 pm, Lyos Gemini Norezel wrote: > seth vidal wrote: >> On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: >> >>> Something equivalent to the Code Of Conduct that Canonical >>> implemented. It worked on the ubuntu lists. No reason it would not >>> work here. >>> >> >> I've got no problem with a separate list. I have A LOT of problems with >> a code of conduct for fedora. >> >> -sv > > I agree with Seth. > Most of the "flame-fest" threads mentioned, while mostly boring, > idiotic, and several other adjectives > I can think of... they do, on occaision, produce *something* of value, > albeit rarely. > > Shall we ban idiots, simply because they're moronic? > How about we just shoot 90% of the world and be done with it? > The real question becomes, is who is an idiot? There are certainly people who are trouble, but how long until a policy such as this just turns into a witch hunt? You don't like someone? Great, just bait them into breaking the policy and get them kicked out! If you don't like a thread, just ignore it. That's a lot less work than creating an overly elaborate code of conduct nobody is really going to follow anyway. I compare this to talking to a boring person at a party. Are you going to stand there and complain how boring they are, or go find someone more interesting to talk to? -- JB From anders at trudheim.co.uk Mon Jul 28 18:06:55 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 20:06:55 +0200 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> Message-ID: <20080728180655.GB7357@shuttle.trudheim.co.uk> * Jeff Spaleta [20080728 19:47]: > On Mon, Jul 28, 2008 at 6:04 AM, Gilboa Davara wrote: > > Sure. > > But not in -devel and not -users. > > Just a point of fact... fedora-list is not spelled fedora-users-list. > Perhaps the people are asking for the wrong solution to the wrong problem. > Perhaps fedora-list is meant to be widely scoped, and perhaps people > want a narrow list focused just on users. I wonder what such a list > would end up being named? > > I'll drop my hint just one more time. I'm perfectly happy to support > the creation of lists for specific constructive purposes. If you feel > fedora-list isn't servicing a specific purpose well, perhaps you and > others can manage the creation of a new list, specific in scope, to > the user issues that you actually care about, instead of attempting to > muscle noisy discussions to a new place. Jeff, Do you have a link to the documentation for how to do the creation request, the criteria and supporting docs required for it to be granted and what would be required to point new users at this new list for the location to go for technical help from users of Fedora, i.e. changing the wiki/website to point at the new list? The way I read your response - you are stating that fedora-list is the "everything and the kitchen sink" list, and I believe that is a bit broad to point users at that need help or support. Many thanks for your assistance. /Anders "If Mohammed won't leave the mountain, the mountain will leave Mohammed" From jspaleta at gmail.com Mon Jul 28 18:27:38 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Jul 2008 10:27:38 -0800 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728180655.GB7357@shuttle.trudheim.co.uk> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> <20080728180655.GB7357@shuttle.trudheim.co.uk> Message-ID: <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> On Mon, Jul 28, 2008 at 10:06 AM, Anders Karlsson wrote: > Do you have a link to the documentation for how to do the creation > request, the criteria and supporting docs required for it to be > granted and what would be required to point new users at this new list > for the location to go for technical help from users of Fedora, > i.e. changing the wiki/website to point at the new list? No I have no specific link, because I have never needed to create a list. Surely its not different than creating a SIG list. > > The way I read your response - you are stating that fedora-list is the > "everything and the kitchen sink" list, and I believe that is a bit > broad to point users at that need help or support. I am saying, that I require that people asking for new lists care about the subject matter of the new list and are going to be active participants and can be counted on to craft a productive list culture in the new list. The people currently having the noisy discussion in fedora-list could make a request for a fedora-policy-debate-list and I'd have a much easier time following up on that request, because it would be coming from the people who want to use the list. If the people currently in the discussion are having it in fedora-list because its the most subscribed list and are doing it there specifically to increase the changes of having a lot of people see their opinions... creating a separate list won't solve the trolling problem. The issue of it being on-topic or off-topic for fedora-list is orthogonal to whether we should create separate list for the discussion. Someone who actually wants to use the dedicated list should be making the request. -jef From davej at redhat.com Sun Jul 27 21:08:28 2008 From: davej at redhat.com (Dave Jones) Date: Sun, 27 Jul 2008 17:08:28 -0400 Subject: Putting --fuzz=0 into rpmbuild on older versions? In-Reply-To: <16378.1217183505@sss.pgh.pa.us> References: <16378.1217183505@sss.pgh.pa.us> Message-ID: <20080727210828.GA11610@redhat.com> On Sun, Jul 27, 2008 at 02:31:45PM -0400, Tom Lane wrote: > So, sure enough, I got blindsided by the fact that rawhide's RPM now > applies patches with --fuzz=0. I don't object to tightening the policy > like that, but it's pretty unhappy-making that having tested an SRPM on > my Fedora 9 system offers no protection against the koji build failing. > > I looked around for a place to inject --fuzz=0 into the patch arguments > on F-9, and couldn't find one. Is the definition of %patch really > hardwired into rpmbuild? Yes. See the ApplyPatch macro in the kernel specfile for a way to work around it. We've been doing fuzz=0 patches since circa fc7 after a fuzzy patch caused a "can't boot" regression that was a nightmare to track down. Dave -- http://www.codemonkey.org.uk From rayvd at bludgeon.org Mon Jul 28 19:03:57 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 28 Jul 2008 12:03:57 -0700 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <41413.24.208.214.89.1217267863.squirrel@www.bress.net> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> <41413.24.208.214.89.1217267863.squirrel@www.bress.net> Message-ID: <20080728190357.GA14965@bludgeon.org> > The real question becomes, is who is an idiot? > > There are certainly people who are trouble, but how long until a > policy such as this just turns into a witch hunt? > > You don't like someone? Great, just bait them into breaking the > policy and get them kicked out! > > If you don't like a thread, just ignore it. That's a lot less work > than creating an overly elaborate code of conduct nobody is really > going to follow anyway. Agreed. The noise can be annoying, but it's pretty subjective from person to person as to what is and what isn't. I think this is why a "topical" approach would be more appropriate vs trying set up some code of ethics. It's a lot easier to argue in favor of a new list because a certain topic or group of topics continue to come up (otherwise we'd just have one big list for everything and "filter" as needed). So, fedora-advocacy or fedora-argue makes a lot of sense framed like that IMO; less so on a "we need to regulate this" basis. > I compare this to talking to a boring person at a party. Are you going to > stand there and complain how boring they are, or go find someone more > interesting to talk to? Ray From loupgaroublond at gmail.com Mon Jul 28 19:04:07 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 28 Jul 2008 21:04:07 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DEFC6.8080809@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> Message-ID: <7f692fec0807281204n3697e9dbv54034dcd2bfe651e@mail.gmail.com> 2008/7/28 Lyos Gemini Norezel : > seth vidal wrote: > > On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: > > > Something equivalent to the Code Of Conduct that Canonical > implemented. It worked on the ubuntu lists. No reason it would not > work here. > > > I've got no problem with a separate list. I have A LOT of problems with > a code of conduct for fedora. > > -sv > > I agree with Seth. > Most of the "flame-fest" threads mentioned, while mostly boring, idiotic, > and several other adjectives > I can think of... they do, on occaision, produce *something* of value, > albeit rarely. > > Shall we ban idiots, simply because they're moronic? > How about we just shoot 90% of the world and be done with it? Can we? Please? -Yaakov From martin.langhoff at gmail.com Mon Jul 28 19:30:06 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 29 Jul 2008 07:30:06 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <1217257286.12821.15.camel@aglarond.local> References: <46a038f90807252125v4d8d0970x7e7c29ff4db9d5db@mail.gmail.com> <1217257286.12821.15.camel@aglarond.local> Message-ID: <46a038f90807281230o479cd731m3ec7f58714afbf3e@mail.gmail.com> On Tue, Jul 29, 2008 at 3:01 AM, Jeremy Katz wrote: > On Sat, 2008-07-26 at 16:25 +1200, Martin Langhoff wrote: >> When livecd-creator tries to unmount the CD, two processes are still >> running - httpd, and a custom network daemon written in python. lsof >> shows them as the only processes keeping files open. Once I kill those >> processes, I can unmount cleanly. >> >> Is this expected? > > If you start a process in your %post, then you need to clean up after > yourself at the end of %post The custom network daemon I am ready to take blame for, but what is intriguing is that httpd - from the standard httpd rpm - starts and is left running. Perhaps I'm doing something wrong. >> Are any incompatibilities with F7 known? Should >> livecd-creator try to run all the relevant init scripts with stop, and >> perhaps run lsof to see if any programs need to be killed or >> kill-9'ed? > > How do you know what's relevant? Packaging policy states (for reasons > including this one) that services shouldn't be started in the %post of a > package install. Which means that it's something you're starting > yourself. Which means you need to kill it off also. Hmmm. httpd might be buggy in that regard. We are also installing mod_perl, mod_python and mod_php, any of those might be trying to (incorrectly) reload httpd. >> The boot failures (fails to load the kernel modules, and kills init) >> probably have to do with the image being incomplete. > > Will leave this as a reply for some of your later mails... - thanks! m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Mon Jul 28 19:35:12 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 29 Jul 2008 07:35:12 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: <1217255631.25653.83.camel@S010600e029961c54.wp.shawcable.net> References: <1217255631.25653.83.camel@S010600e029961c54.wp.shawcable.net> Message-ID: <46a038f90807281235x60ef6fe0n80f4349cc28263c4@mail.gmail.com> On Tue, Jul 29, 2008 at 2:33 AM, Jerry Vonau wrote: > Hold it, lzma is not part of Fedora's squash support, but could be > patched it. The link just has all the steps the are needed to patch a > kernel, then recompile the kernel's modules. Just happens to be squashfs > as the example. ;-) There is something "cute" between 3.2 and 3.3 > thou... Well, the squashfs3.3 tarballs from the SF page and from the squashfs-lzma site are identical, and the credits page in both mention 'lzma patches', though no word of it appears in CHANGES or README. My interpretation is that v3.3 incorporates the patches. >> But the image still does not boot. Something else in the initrd must >> be messing up. > > What is the message now? We no longer see any errors, but init cannot find root, so itdrops me to an emergency shell. In there I find nothing interesting in /dev . Not even loop devices. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From a.badger at gmail.com Mon Jul 28 19:33:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Jul 2008 12:33:14 -0700 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <47EA96DB.9080906@leemhuis.info> <47EA9A06.2090106@inetwork.ru> <47EB243B.2000103@gmail.com> <6e24a8e80803270345l3d4d6583l3d87e7e11a511043@mail.gmail.com> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> Message-ID: <488E1EFA.6090602@gmail.com> Arthur Pemberton wrote: > On Mon, Jul 28, 2008 at 12:50 PM, Mark wrote: >> On Fri, Apr 4, 2008 at 7:12 PM, Mark wrote: >>> 2008/4/4, Callum Lerwick : >>>> On Thu, 2008-03-27 at 20:23 +0100, Mark wrote: >>>> > About the language it needs to be written in.. (Python).. byw bye >>>> > oppertunity for me to make it unless i learn python :) i do know Java >>>> > and PHP. >>>> >>>> >>>> Seriously, just learn Python. Java should have already taught you OOP, >>>> and PHP should have already taught you loosely-typed "script" style >>>> programming, and the use of lists and hashes as fundamental data types, >>>> and that's maybe 95% of what underlies Python you know already. >>>> >>> I have enough on my todo list already for the coming months. >>> python together with this project isn't high on it. i'm more then >>> willing to help when needed but not a full time SoC application. I >>> will help in: >>> - template stuff >>> - mocking the design up >>> - ajax technology stuff >>> >>> And there is more then enough to do in those 3 alone. >>> When you (the one who is gonna do this project) need my help on this >>> just drop me a line and i will give it my best shot. >>> >> Hey all, >> >> This thread kinda died after my last post but i'm really wondering how >> this project stands now at this moment in the middle of the GSoC. If >> it made it in in the first place.. where i can track the development.. >> things like that. >> >> O btw. i still am more then willing to help with it! >> >> I hope to hear about this project. >> Mark. > > > The student who applied for this did not have their application > accepted. I guess they decided not to do it otherwise. I myself have > not had the time to try it. > However, some people are working on this problem as a different application rather than the PackageDB. Look at https://fedorahosted.org/amber or talk with rnorwood and otaylor on irc.freenode.net -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 alan at redhat.com Mon Jul 28 19:39:03 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jul 2008 15:39:03 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <41413.24.208.214.89.1217267863.squirrel@www.bress.net> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> <41413.24.208.214.89.1217267863.squirrel@www.bress.net> Message-ID: <20080728193903.GA27649@devserv.devel.redhat.com> On Mon, Jul 28, 2008 at 01:57:43PM -0400, Josh Bressers wrote: > I compare this to talking to a boring person at a party. Are you going to > stand there and complain how boring they are, or go find someone more > interesting to talk to? What do you do when they follow you around continually talking ? You leave the party, just like Fedora From alan at redhat.com Mon Jul 28 19:40:01 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jul 2008 15:40:01 -0400 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> <20080728180655.GB7357@shuttle.trudheim.co.uk> <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> Message-ID: <20080728194001.GB27649@devserv.devel.redhat.com> On Mon, Jul 28, 2008 at 10:27:38AM -0800, Jeff Spaleta wrote: > The issue of it being on-topic or off-topic for fedora-list is > orthogonal to whether we should create separate list for the > discussion. Someone who actually wants to use the dedicated list > should be making the request. Good I'd like to request a list fedora-useful which is everything fedora-list is except the stupid politics Alan From gilboad at gmail.com Mon Jul 28 19:48:14 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 28 Jul 2008 22:48:14 +0300 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> Message-ID: <9050516b0807281248n7072193crf2a5d8e82cb55ffb@mail.gmail.com> On Mon, Jul 28, 2008 at 8:46 PM, Jeff Spaleta wrote: > On Mon, Jul 28, 2008 at 6:04 AM, Gilboa Davara wrote: >> Sure. >> But not in -devel and not -users. > > Just a point of fact... fedora-list is not spelled fedora-users-list. > Perhaps the people are asking for the wrong solution to the wrong problem. > Perhaps fedora-list is meant to be widely scoped, and perhaps people > want a narrow list focused just on users. I wonder what such a list > would end up being named? > > I'll drop my hint just one more time. I'm perfectly happy to support > the creation of lists for specific constructive purposes. If you feel > fedora-list isn't servicing a specific purpose well, perhaps you and > others can manage the creation of a new list, specific in scope, to > the user issues that you actually care about, instead of attempting to > muscle noisy discussions to a new place. > > -jef Jef, If it was up to me, people who misbehave, abuse or spam the ML would have been banned from fedora-* and forced to pay for the wasted bandwidth they consumed.... But that's me. However, I understand that we are living in an imperfect world that is being governed by a set of imperfect rules. As such, we are left with one of two choice: Continue being hammered by 100's of OT messages per day or get these discussions off-main-list. (Unless you're willing to give -me- the keys to the ML's - the peace loving dove that I am... :)) - Gilboa "One more GPL message and I'm switching to Windows 3.11 WFW" Davara. From gilboad at gmail.com Mon Jul 28 19:50:16 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 28 Jul 2008 22:50:16 +0300 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728194001.GB27649@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> <20080728180655.GB7357@shuttle.trudheim.co.uk> <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> <20080728194001.GB27649@devserv.devel.redhat.com> Message-ID: <9050516b0807281250t6928d7e0m39794ce9dc1338d3@mail.gmail.com> On Mon, Jul 28, 2008 at 10:40 PM, Alan Cox wrote: > On Mon, Jul 28, 2008 at 10:27:38AM -0800, Jeff Spaleta wrote: >> The issue of it being on-topic or off-topic for fedora-list is >> orthogonal to whether we should create separate list for the >> discussion. Someone who actually wants to use the dedicated list >> should be making the request. > > Good I'd like to request a list > > fedora-useful > > which is everything fedora-list is except the stupid politics > > Alan > /+65536 - Gilboa From kevin at scrye.com Mon Jul 28 20:06:19 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 28 Jul 2008 14:06:19 -0600 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <9050516b0807281250t6928d7e0m39794ce9dc1338d3@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> <20080728180655.GB7357@shuttle.trudheim.co.uk> <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> <20080728194001.GB27649@devserv.devel.redhat.com> <9050516b0807281250t6928d7e0m39794ce9dc1338d3@mail.gmail.com> Message-ID: <20080728140619.1290dc9d@ohm.scrye.com> On Mon, 28 Jul 2008 22:50:16 +0300 gilboad at gmail.com ("Gilboa Davara") wrote: > On Mon, Jul 28, 2008 at 10:40 PM, Alan Cox wrote: > > On Mon, Jul 28, 2008 at 10:27:38AM -0800, Jeff Spaleta wrote: > >> The issue of it being on-topic or off-topic for fedora-list is > >> orthogonal to whether we should create separate list for the > >> discussion. Someone who actually wants to use the dedicated list > >> should be making the request. Just to throw in my 2 cents here: I've been trying to help improve IRC support using the #fedora channel of late. I think we have made some progress. One of the things that I think has helped is to point folks who are not people with fedora related questions (Or those willing to assist them) to other venues. I think this could be useful for the mailing list as well. I would note that currently the fedora lists says: "fedora-list -- For users of Fedora" Which is a pretty wide open topic list. > > > > Good I'd like to request a list > > > > fedora-useful > > > > which is everything fedora-list is except the stupid politics > > > > Alan > > > > /+65536 > > - Gilboa I would suggest one of: fedora-support or fedora-users-help or fedora-community-help or something like those. Alternately, we could look at reusing the fedora-list, but then make a 'fedora-offtopic' or 'fedora-defocus' or 'fedora-advocacy' list for the non support lists. Also, it would be good to narrow down the topic such as: "Peer support for currently supported Fedora Releases" I would love to see this setup and added into a Support SIG with the IRC helpers so both groups could share info and try to improve support in both places. Any takers? I would be happy to help some, but my time is pretty streched already. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From anders at trudheim.co.uk Mon Jul 28 20:11:31 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Mon, 28 Jul 2008 22:11:31 +0200 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728140619.1290dc9d@ohm.scrye.com> References: <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <604aa7910807281046gcc6608cx25d474c6d85d4598@mail.gmail.com> <20080728180655.GB7357@shuttle.trudheim.co.uk> <604aa7910807281127w6143cfa0pccd49afb1042d690@mail.gmail.com> <20080728194001.GB27649@devserv.devel.redhat.com> <9050516b0807281250t6928d7e0m39794ce9dc1338d3@mail.gmail.com> <20080728140619.1290dc9d@ohm.scrye.com> Message-ID: <20080728201131.GD6648@localhost.localdomain> * Kevin Fenzi [20080728 22:07]: [snip] > I would suggest one of: > > fedora-support > or > fedora-users-help > or > fedora-community-help > > or something like those. Alternately, we could look at reusing the > fedora-list, but then make a 'fedora-offtopic' or 'fedora-defocus' or > 'fedora-advocacy' list for the non support lists. It's easier to move the support to a new dedicated list, than dislodge the advocacy group. > Also, it would be good to narrow down the topic > such as: > > "Peer support for currently supported Fedora Releases" +1 > I would love to see this setup and added into a Support SIG with the > IRC helpers so both groups could share info and try to improve support > in both places. +1 > Any takers? I would be happy to help some, but my time is pretty > streched already. I'll chip in and help. Workload is dropping *a little* at work, so I can spare some private time to help out. I'll make an effort to attend IRC as well, but the ML will probably be where I'll focus. /Anders From mike at miketc.net Mon Jul 28 20:43:14 2008 From: mike at miketc.net (Mike Chambers) Date: Mon, 28 Jul 2008 15:43:14 -0500 Subject: Mailing list support [Fwd: New support lists?] Message-ID: <1217277794.2823.5.camel@scrappy.miketc.net> I sent the original email below to fedora-list, after seeing a certain topic or two on that list as well as devel-list and wanted to forward it here as well. Just something along the lines of the other topic about cleaning up fedora-list. Note, fedora-testers-list below should be fedora-test-list as I accidentally called it by different name and didn't mean to create a new list. Anyway, just something that might make things easier. BTW, we all know Red Hat is main primary sponsor/contributor and what not to Fedora, but shouldn't fedora related material be behind fedoraproject.org domain or something instead? No biggie or complain, just asking/putting it out there. Peace out muh bruthahs LOL - Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org -------- Forwarded Message -------- > From: Mike Chambers > Reply-to: For users of Fedora > To: Fedora > Subject: New support lists? > Date: Mon, 28 Jul 2008 14:15:54 -0500 > > Hi all, > > Reading the last couple emails from another thread on maybe new list or > two, and to segregate the content to them was brought up and have couple > new list names that might help make sense or to get the ball rolling? > > fedora-list(this one) - General Fedora talk, opinions, suggestions, > comments, distro wars, all that type stuff not support related. > > fedora-user-list or fedora-support-list - Bug references, problems with > software, computer won't boot, email don't work, firefox plugins not > working, etc.. where problems are asked about and responded to on > *official releases*. > > fedora-testers-list - as is, for testing alpha, beta, preview, rc > releases when preparing a new release. > > fedora-devel-list - as is, for development of fedora, and the rest that > is currently used on that list. > > See the url below for currently created lists already being used.. > > https://listman.redhat.com/mailman/listinfo/ > > Would this help make things better? From rayvd at bludgeon.org Mon Jul 28 20:49:59 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 28 Jul 2008 13:49:59 -0700 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728193903.GA27649@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> <41413.24.208.214.89.1217267863.squirrel@www.bress.net> <20080728193903.GA27649@devserv.devel.redhat.com> Message-ID: <20080728204959.GA16875@bludgeon.org> On Mon, Jul 28, 2008 at 03:39:03PM -0400, Alan Cox wrote: > On Mon, Jul 28, 2008 at 01:57:43PM -0400, Josh Bressers wrote: > > I compare this to talking to a boring person at a party. Are you going to > > stand there and complain how boring they are, or go find someone more > > interesting to talk to? > > What do you do when they follow you around continually talking ? > > You leave the party, just like Fedora Punch them in the face depending on what kind of party it is. :-) I think a better analogy is being at a party where 80 or so people are all around you hollering and arguing about politics when you're there to just have a good time. Then you'd leave for sure :) Ray From tom at impact-crater.com Mon Jul 28 20:52:14 2008 From: tom at impact-crater.com (Tom Rivers) Date: Mon, 28 Jul 2008 16:52:14 -0400 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217261219.22766.25.camel@gilboa-work-dev.localdomain> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <1217253858.22766.16.camel@gilboa-work-dev.localdomain> <488DD7AC.2040607@impact-crater.com> <1217261219.22766.25.camel@gilboa-work-dev.localdomain> Message-ID: <488E317E.7060704@impact-crater.com> On 7/28/2008 12:06 PM, Gilboa Davara wrote: > I don't have solid numbers, but at least according to my gmail trash > contents, around ~1/4-1/5 of the posts that were sent to -users between, > say, Tuesday and Saturday belonged to one of the 4 "GPL" threads. > The reason I wanted to get some metrics is to make it is easier to understand the true nature of the problem and its impact on everyone Using your date range of 7/22/2008 - 7/26/2008, I went back and counted the total number of messages that were sent to both lists: List: 763 Devel: 275 Here are the number of total threads in both lists for the same period: List: 72 Devel: 58 You said that there are 4 threads that are the problem. That means that for the time period in question, 4 of 72 threads are what you would consider inappropriate. That doesn't sound like a lot of threads to me. In fact, it's about 5.5% of all the threads. Still, that's not the whole picture because we need to look at the total number of posts these threads contain: 3 - Misunderstanding GPL... 25 - That old... 7 - A long rebuttal... 7 - Why is Fedora not free.. Total: 42 posts That means that approximately 5.5% of the posts made in this period are what you consider inappropriate. Personally, I don't think this is a lot of posts considering that the gripe is merely that they are Off-Topic and even that point is arguable. Since they are in only 4 distinct threads which are labeled quite conspicuously and accurately, I would imagine that you can avoid reading those posts quite readily. I find it's a lot easier to simply not read what doesn't interest me - it requires a lot less effort than trying to get others to agree with my personal tastes in posts. > ... And even if I'm wrong by an order of magnitude, and we are only > talking about 10% of all the -users traffic, given the fact that these > threads are off-topic to being with, this is way-too-much. > While I understand that some have an aversion to Off-Topic posts, I (and I hope many others do as well) have more of a problem with the 26 posts in the thread that complains about this very topic entitled "SHUT THE F*CK UP ALREADY...". I think if there's any general agreement on what is inappropriate, that's the kind of post that cries out for administrative attention. I liken this whole situation to commercial television. Most of the time, not much interests me. When I do find something I like, I have to put up with a far greater percentage of commercials cutting into my program than OT posts cutting into my email management time of these Fedora lists. However, that's OK because I have learned to use my DVR appropriately so I can skip the stuff I don't want and watch the parts I do want. Is it perfect? Nope. Is it reasonable? Maybe. Is it asking too much? I really don't think so. If people are being rude, that's one thing - they should be disciplined and/or removed. If the content of the posts doesn't violate the terms of the list, then I'm afraid you'll be stuck ignoring them just like I do. I wish there was a better answer, but taking a look at the big picture, it really isn't that hard of a problem to deal with if you just relax and read only what interests you. There is no horrific waste of bandwidth, nor is it difficult to delete or simply ignore those posts that lack the requisite appeal. Besides, I don't really like discussions like this one any more than you seem to like Off-Topic posts. Already today, we have had 35 posts on the thread you started which is considerable when looking at the numbers of the posts you don't like over the entire 5 day period you mentioned. If I used your logic, then I am certainly justified to tell you to stop posting off-topic. Get them to move to another list if you want to try, but please don't try to make a case for censoring conversations that are about Fedora and don't violate the terms of the lists on which they take place. Regardless of what your personal opinions are, it's really not fair to stop others from being able to read the content that appeals to them. Tom From phillip at lougher.demon.co.uk Mon Jul 28 21:04:02 2008 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Mon, 28 Jul 2008 21:04:02 +0000 (UTC) Subject: livecd-creator unmounting temp image, running daemons. References: <1217145608.25653.3.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807270145w69e49062qd6a2c50827d65ed5@mail.gmail.com> Message-ID: Martin Langhoff gmail.com> writes: > > Interesting. F7 contains squashfs-tools-3.2-1, vs 3.3-2 in F9 and the > changelog doesn't say anything too explicit about a break on storage > format. > > Two things look suspicious - sparse files support and the change in > default block size. Both sparse file support and larger block sizes (if used), cause a bump in filesystem version to 3.1 (from 3.0 used by Squashfs version 3.2). > Sounds complex. I will try going in the opposite direction: downgrade > the package on F9 or pass flags to disable the new fanciness. To force Mksquashfs 3.3 to generate a filesystem compatible with Squashfs 3.2, you have to specify both the "-no-sparse" and "-b 64K" options. Phillip From markg85 at gmail.com Mon Jul 28 21:20:02 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jul 2008 23:20:02 +0200 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <488E1EFA.6090602@gmail.com> References: <47E6CF76.5070305@inetwork.ru> <47EB243B.2000103@gmail.com> <6e24a8e80803270345l3d4d6583l3d87e7e11a511043@mail.gmail.com> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> Message-ID: <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> >>> Hey all, >>> >>> This thread kinda died after my last post but i'm really wondering how >>> this project stands now at this moment in the middle of the GSoC. If >>> it made it in in the first place.. where i can track the development.. >>> things like that. >>> >>> O btw. i still am more then willing to help with it! >>> >>> I hope to hear about this project. >>> Mark. >> >> >> The student who applied for this did not have their application >> accepted. I guess they decided not to do it otherwise. I myself have >> not had the time to try it. >> > However, some people are working on this problem as a different application > rather than the PackageDB. Look at https://fedorahosted.org/amber or talk > with rnorwood and otaylor on irc.freenode.net > > -Toshio Good to see atleast some development. I was just hoping to see something visual.. I will see if i can get in contact with those 2 you mentioned. From sundaram at fedoraproject.org Mon Jul 28 21:23:00 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jul 2008 02:53:00 +0530 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <47EB243B.2000103@gmail.com> <6e24a8e80803270345l3d4d6583l3d87e7e11a511043@mail.gmail.com> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> Message-ID: <488E38B4.2040604@fedoraproject.org> Mark wrote: > Good to see atleast some development. > I was just hoping to see something visual.. > I will see if i can get in contact with those 2 you mentioned. https://fedoraproject.org/wiki/Features/ApplicationInstaller Mockups: http://yipyop.com/fedora/images/fedora_apps.png http://yipyop.com/fedora/images/fedora_app_page.png Rahul From sstarr at platform.com Mon Jul 28 21:29:07 2008 From: sstarr at platform.com (Shawn Starr) Date: Mon, 28 Jul 2008 17:29:07 -0400 Subject: Application for GSoC Project - Package WebUI Message-ID: Someone add a KDE Category please. > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of > Rahul Sundaram > Sent: Monday, July 28, 2008 5:23 PM > To: Development discussions related to Fedora > Subject: Re: Application for GSoC Project - Package WebUI > > > Mark wrote: > > > Good to see atleast some development. > > I was just hoping to see something visual.. > > I will see if i can get in contact with those 2 you mentioned. > > https://fedoraproject.org/wiki/Features/ApplicationInstaller > > Mockups: > > http://yipyop.com/fedora/images/fedora_apps.png > http://yipyop.com/fedora/images/fedora_app_page.png > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From markg85 at gmail.com Mon Jul 28 21:28:32 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jul 2008 23:28:32 +0200 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <488E38B4.2040604@fedoraproject.org> References: <47E6CF76.5070305@inetwork.ru> <47EBD0AA.5060000@gmail.com> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> <488E38B4.2040604@fedoraproject.org> Message-ID: <6e24a8e80807281428h2b4ddaecvb83e68969b858df4@mail.gmail.com> On Mon, Jul 28, 2008 at 11:23 PM, Rahul Sundaram wrote: > Mark wrote: > >> Good to see atleast some development. >> I was just hoping to see something visual.. >> I will see if i can get in contact with those 2 you mentioned. > > https://fedoraproject.org/wiki/Features/ApplicationInstaller > Thanx for the link > Mockups: > > http://yipyop.com/fedora/images/fedora_apps.png > http://yipyop.com/fedora/images/fedora_app_page.png > > Rahul Damn! those images look nice! Good job! From sundaram at fedoraproject.org Mon Jul 28 21:29:53 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jul 2008 02:59:53 +0530 Subject: Application for GSoC Project - Package WebUI In-Reply-To: References: Message-ID: <488E3A51.3030308@fedoraproject.org> Shawn Starr wrote: > Someone add a KDE Category please. The app installer would use the yum groups that already exists IIUC. Doing it again here would be redundant. Rahul > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com >> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of >> Rahul Sundaram >> Sent: Monday, July 28, 2008 5:23 PM >> To: Development discussions related to Fedora >> Subject: Re: Application for GSoC Project - Package WebUI >> >> >> Mark wrote: >> >>> Good to see atleast some development. >>> I was just hoping to see something visual.. >>> I will see if i can get in contact with those 2 you mentioned. >> https://fedoraproject.org/wiki/Features/ApplicationInstaller >> >> Mockups: >> >> http://yipyop.com/fedora/images/fedora_apps.png >> http://yipyop.com/fedora/images/fedora_app_page.png >> >> Rahul >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From pemboa at gmail.com Mon Jul 28 21:37:29 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 28 Jul 2008 16:37:29 -0500 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <6e24a8e80807281428h2b4ddaecvb83e68969b858df4@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <6e24a8e80803271223j6fe20642keed854c84ab549ea@mail.gmail.com> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> <488E38B4.2040604@fedoraproject.org> <6e24a8e80807281428h2b4ddaecvb83e68969b858df4@mail.gmail.com> Message-ID: <16de708d0807281437y486ef2dbud9b3d5fb8fee3834@mail.gmail.com> On Mon, Jul 28, 2008 at 4:28 PM, Mark wrote: > On Mon, Jul 28, 2008 at 11:23 PM, Rahul Sundaram > wrote: >> Mark wrote: >> >>> Good to see atleast some development. >>> I was just hoping to see something visual.. >>> I will see if i can get in contact with those 2 you mentioned. >> >> https://fedoraproject.org/wiki/Features/ApplicationInstaller >> > > Thanx for the link > >> Mockups: >> >> http://yipyop.com/fedora/images/fedora_apps.png >> http://yipyop.com/fedora/images/fedora_app_page.png >> >> Rahul Would be interesting to see a Qt version of this which would just use the web as the UI with WebKit -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From markg85 at gmail.com Mon Jul 28 21:43:37 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jul 2008 23:43:37 +0200 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <16de708d0807281437y486ef2dbud9b3d5fb8fee3834@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> <488E38B4.2040604@fedoraproject.org> <6e24a8e80807281428h2b4ddaecvb83e68969b858df4@mail.gmail.com> <16de708d0807281437y486ef2dbud9b3d5fb8fee3834@mail.gmail.com> Message-ID: <6e24a8e80807281443i58609092vc3300cc89e416251@mail.gmail.com> > Would be interesting to see a Qt version of this which would just use > the web as the UI with WebKit > I don't get what QT has to do with it.. it's a web based project! And for the real life demo: http://publictest10.fedoraproject.org/amber/ That... doesn't look as good as the mockups.. any reason why that's the case? If it's just because the mockup hasn't been made in html file yet then i can help with that. From sundaram at fedoraproject.org Mon Jul 28 21:53:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jul 2008 03:23:34 +0530 Subject: Application for GSoC Project - Package WebUI In-Reply-To: <6e24a8e80807281443i58609092vc3300cc89e416251@mail.gmail.com> References: <47E6CF76.5070305@inetwork.ru> <1207296576.17819.24.camel@localhost> <6e24a8e80804041012p53bce5b0l3f4225655af742f5@mail.gmail.com> <6e24a8e80807281050u4ce5a1a8ua87fbff844a3c456@mail.gmail.com> <16de708d0807281054i5a1eb205p4dcf3844406f3019@mail.gmail.com> <488E1EFA.6090602@gmail.com> <6e24a8e80807281420s6e7e7879v277f95f24a53d935@mail.gmail.com> <488E38B4.2040604@fedoraproject.org> <6e24a8e80807281428h2b4ddaecvb83e68969b858df4@mail.gmail.com> <16de708d0807281437y486ef2dbud9b3d5fb8fee3834@mail.gmail.com> <6e24a8e80807281443i58609092vc3300cc89e416251@mail.gmail.com> Message-ID: <488E3FDE.6080202@fedoraproject.org> Mark wrote: >> Would be interesting to see a Qt version of this which would just use >> the web as the UI with WebKit >> > > I don't get what QT has to do with it.. it's a web based project! > > And for the real life demo: > http://publictest10.fedoraproject.org/amber/ > > That... doesn't look as good as the mockups.. any reason why that's the case? > If it's just because the mockup hasn't been made in html file yet then > i can help with that. Read the discussions at https://www.redhat.com/archives/fedora-websites-list/2008-July/msg00034.html Contact Robin Norwood if you can help. Rahul From valent.turkovic at gmail.com Mon Jul 28 22:10:12 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 29 Jul 2008 00:10:12 +0200 Subject: great news for Asus eee users Message-ID: <64b14b300807281510o403f64c8i3da9a7269c42ce87@mail.gmail.com> I have posted a question on ath5k wireless devel list on support for AR2425 (AR5007EG) chipset (one that Asus eee 701 has) and got an answer that the patches have been sent upstream. So when they got included Asus eee's wireless will work in Fedora out of the box, right? This is a great news for me as a Asus eee user because wireless is the only part of Asus eee that isn't working out of the box on Fedora 9. For me as a future Fedora 10 user this is a great because Fedora 10 will work on Asus eee out of the box, including working wireless. Cheers, Valent. -- 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 moe at blagblagblag.org Mon Jul 28 22:35:33 2008 From: moe at blagblagblag.org (jeff) Date: Mon, 28 Jul 2008 19:35:33 -0300 Subject: great news for Asus eee users In-Reply-To: <64b14b300807281510o403f64c8i3da9a7269c42ce87@mail.gmail.com> References: <64b14b300807281510o403f64c8i3da9a7269c42ce87@mail.gmail.com> Message-ID: <488E49B5.3040100@blagblagblag.org> Valent Turkovic wrote: > I have posted a question on ath5k wireless devel list on support for > AR2425 (AR5007EG) chipset (one that Asus eee 701 has) and got an > answer that the patches have been sent upstream. So when they got > included Asus eee's wireless will work in Fedora out of the box, > right? Yes, they will be part of the main ath5k driver in the kernel. Here's the patches in preparation, below: I believe he's submitted them to wireless testing, so they are making their way up to the vanilla kernel. ftp://ftp.kernel.org/pub/linux/kernel/people/mickflemm/compat-wireless-2008-07-03-ath5k.tar.bz2 > This is a great news for me as a Asus eee user because wireless is the > only part of Asus eee that isn't working out of the box on Fedora 9. > For me as a future Fedora 10 user this is a great because Fedora 10 > will work on Asus eee out of the box, including working wireless. The wireless is already working very well in Managed mode. I've been using it for a week or so without problems. :) In ad-hoc, it's not quite perfect yet, but I can get two eees to talk each other. -Jeff From tgl at redhat.com Mon Jul 28 23:40:05 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jul 2008 19:40:05 -0400 Subject: Putting --fuzz=0 into rpmbuild on older versions? In-Reply-To: <20080727210828.GA11610@redhat.com> References: <16378.1217183505@sss.pgh.pa.us> <20080727210828.GA11610@redhat.com> Message-ID: <625.1217288405@sss.pgh.pa.us> Dave Jones writes: > On Sun, Jul 27, 2008 at 02:31:45PM -0400, Tom Lane wrote: >>> I looked around for a place to inject --fuzz=0 into the patch arguments >>> on F-9, and couldn't find one. Is the definition of %patch really >>> hardwired into rpmbuild? > Yes. Ick. > See the ApplyPatch macro in the kernel specfile for a way to work > around it. Double ick. After some poking at rpm I found that making F-9 support fuzz specification decently is really a very small patch (attached). With this, I can put "%_default_patch_fuzz 0" into ~/.rpmmacros and get rawhide-equivalent behavior. I think I'll be using a locally patched rpm if I can't get the maintainer to apply this... regards, tom lane diff -Naur rpm-4.4.2.3.orig/build/parsePrep.c rpm-4.4.2.3/build/parsePrep.c --- rpm-4.4.2.3.orig/build/parsePrep.c 2008-04-01 03:28:21.000000000 -0400 +++ rpm-4.4.2.3/build/parsePrep.c 2008-07-28 16:20:03.000000000 -0400 @@ -61,7 +61,7 @@ * @param strip patch level (i.e. patch -p argument) * @param db saved file suffix (i.e. patch --suffix argument) * @param reverse include -R? - * @param fuzz include -F? + * @param fuzz fuzz factor, fuzz<0 means no fuzz set * @param removeEmpties include -E? * @return expanded %patch macro (NULL on error) */ @@ -98,7 +98,7 @@ #endif t = stpcpy( stpcpy(t, "--suffix "), db); } - if (fuzz) { + if (fuzz>=0) { t = stpcpy(t, " -F"); sprintf(t, "%d", fuzz); t += strlen(t); @@ -463,7 +463,8 @@ int patch_index, x; memset(patch_nums, 0, sizeof(patch_nums)); - opt_P = opt_p = opt_R = opt_E = opt_F = 0; + opt_P = opt_p = opt_R = opt_E = 0; + opt_F = rpmExpandNumeric("%{_default_patch_fuzz}"); /* get default fuzz factor for %patch */ opt_b = NULL; patch_index = 0; @@ -515,7 +516,7 @@ fnum = strtok(NULL, " \t\n"); } opt_F = (fnum ? strtol(fnum, &end, 10) : 0); - if (! opt_F || *end) { + if (opt_F < 0 || *end) { rpmError(RPMERR_BADSPEC, _("line %d: Bad arg to %%patch -F: %s\n"), spec->lineNum, spec->line); diff -Naur rpm-4.4.2.3.orig/macros.in rpm-4.4.2.3/macros.in --- rpm-4.4.2.3.orig/macros.in 2008-04-01 03:28:22.000000000 -0400 +++ rpm-4.4.2.3/macros.in 2008-07-28 16:21:42.000000000 -0400 @@ -340,6 +340,9 @@ # #%vendor +# Default fuzz level for %patch in spec file (-1 means don't set it). +%_default_patch_fuzz -1 + #============================================================================== # ---- Build configuration macros. # From phillip at lougher.demon.co.uk Tue Jul 29 00:12:19 2008 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Tue, 29 Jul 2008 00:12:19 +0000 (UTC) Subject: livecd-creator unmounting temp image, running daemons. References: <1217255631.25653.83.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807281235x60ef6fe0n80f4349cc28263c4@mail.gmail.com> Message-ID: Martin Langhoff gmail.com> writes: > > Well, the squashfs3.3 tarballs from the SF page and from the > squashfs-lzma site are identical, and the credits page in both mention > 'lzma patches', though no word of it appears in CHANGES or README. My > interpretation is that v3.3 incorporates the patches. Just to clear up any confusion, v3.3 from sourceforge doesn't incorporate the LZMA patches. The squashfs3.3 tarballs from sourceforge and squashfs-lzma.org are identical because the tarball on squashfs-lzma is taken unchanged from sourceforge, there's additional patches on squashfs-lzma.org which add LZMA support. Obviously the CHANGES and README files don't mention LZMA because v3.3 doesn't use it, the credits file (ACKNOWLEDGEMENTS file) simply acknowledges the work that squashfs-lzma.org has done in providing third-party LZMA support for those that want it (I don't officially support LZMA compression in Squashfs because it is not yet officially supported in the vanilla Linux kernel). > > >> But the image still does not boot. Something else in the initrd must > >> be messing up. > > > > What is the message now? > > We no longer see any errors, but init cannot find root, so itdrops me > to an emergency shell. In there I find nothing interesting in /dev . > Not even loop devices. > Failing to find root may be because you're still not generating a Squashfs v3.2 compatible filesystem. The patch you mention elsewhere which adds '-no-sparse' to mksquashfs, also adds '-b 131072' which will still generate an incompatible filesystem, the block size must be 64K or less - the patch should be adding '-no-sparse -b 64k'. If you see the following error message after the initrd tries to mount root, you still have an incompatible filesystem. SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem SQUASHFS error: Please update your kernel The filesystem should be version '3.0', you can use file or unsquashfs -stat on the Squashfs filesystem to check the version. Phillip From tgl at redhat.com Tue Jul 29 00:31:13 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jul 2008 20:31:13 -0400 Subject: koji build dies with "Bad arg to %patch: %build" Message-ID: <1178.1217291473@sss.pgh.pa.us> Can someone explain what's up with this? http://koji.fedoraproject.org/koji/getfile?taskID=744488&name=srpm.log Don't tell me we've obsoleted %build in the last 24 hours ... regards, tom lane From skvidal at fedoraproject.org Tue Jul 29 00:42:41 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 20:42:41 -0400 Subject: Putting --fuzz=0 into rpmbuild on older versions? In-Reply-To: <625.1217288405@sss.pgh.pa.us> References: <16378.1217183505@sss.pgh.pa.us> <20080727210828.GA11610@redhat.com> <625.1217288405@sss.pgh.pa.us> Message-ID: <1217292161.4468.55.camel@rosebud> Tom, Please send this patch up to rpm-maint at rpm.org - I think that's a better place for patches to rpm. thanks, -sv From jkeating at redhat.com Tue Jul 29 00:50:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jul 2008 20:50:59 -0400 Subject: koji build dies with "Bad arg to %patch: %build" In-Reply-To: <1178.1217291473@sss.pgh.pa.us> References: <1178.1217291473@sss.pgh.pa.us> Message-ID: <1217292659.3151.36.camel@localhost.localdomain> On Mon, 2008-07-28 at 20:31 -0400, Tom Lane wrote: > Can someone explain what's up with this? > > http://koji.fedoraproject.org/koji/getfile?taskID=744488&name=srpm.log > > Don't tell me we've obsoleted %build in the last 24 hours ... It's actually having problems with one of your %patch arguments. The srpm is initially created on a RHEL5 system, before passed to mock, so perhaps rpm on RHEL5 doesn't accept the -F flag... that is the recent thing you changed right? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 martin.langhoff at gmail.com Tue Jul 29 01:02:36 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 29 Jul 2008 13:02:36 +1200 Subject: livecd-creator unmounting temp image, running daemons. In-Reply-To: References: <1217255631.25653.83.camel@S010600e029961c54.wp.shawcable.net> <46a038f90807281235x60ef6fe0n80f4349cc28263c4@mail.gmail.com> Message-ID: <46a038f90807281802g2d696644wcfe9b0231069d9e9@mail.gmail.com> On Tue, Jul 29, 2008 at 12:12 PM, Phillip Lougher wrote: > The squashfs3.3 tarballs from sourceforge and squashfs-lzma.org > are identical because the tarball on squashfs-lzma is taken unchanged from > sourceforge, Ah, thanks for the clarification. I had assumed the tarball form the squashfs-lzma site was patches. > Failing to find root may be because you're still not generating a Squashfs v3.2 > compatible filesystem. The patch you mention elsewhere which adds '-no-sparse' > to mksquashfs, also adds '-b 131072' which will still generate an incompatible > filesystem, the block size must be 64K or less - the patch should be adding > '-no-sparse -b 64k'. You are right about that - but I later switched to using mksquashfs from the 3.2 tarball, and tested the squashfs file by mounting it on a 2.6.23 kernel w/o problems. > If you see the following error message after the initrd tries to mount root, you > still have an incompatible filesystem. > > SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem > SQUASHFS error: Please update your kernel When using mksquashfs from v3.2 I did not see those errors anymore. In fact, there are no obvious errors anymore - attempting to boot we see init=/sbin/init root=CDLABEL=TEST_MINIMAL_f7_03 rootflags= rootfstype=iso9660 root_ro=1 root_rw=0 Added udev rule 00-cdlabel.rules: [some noise about udev] SCSI subsystem initialized starting udevd creating devices waiting for system to settle no root yet, udev will write symlink... waiting up to 60 seconds before dropping to emergency shell ----- WARNING: Cannot find root file system! ----- Create symlink /dev/root and then exit this shell to continue the boot sequence I don't really know where to find the squashfs/ext3 file to try to mount it. cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From jwboyer at gmail.com Tue Jul 29 01:15:31 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 28 Jul 2008 21:15:31 -0400 Subject: The results are in for the Fedroa 10 naming Message-ID: <1217294131.2843.5.camel@weaponx> Drum roll... And the winner of the Fedora 10 codename is: Cambridge The full GPG-signed information from our election coordinator, Nigel Jones, including vote totals, is located here: http://jwboyer.fedorapeople.org/fedora10relname.txt.asc Many thanks to the Board, Paul Frields, and Nigel Jones for their effort in getting the name candidates and vote set up. josh _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tgl at redhat.com Tue Jul 29 01:35:39 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jul 2008 21:35:39 -0400 Subject: Putting --fuzz=0 into rpmbuild on older versions? In-Reply-To: <1217292161.4468.55.camel@rosebud> References: <16378.1217183505@sss.pgh.pa.us> <20080727210828.GA11610@redhat.com> <625.1217288405@sss.pgh.pa.us> <1217292161.4468.55.camel@rosebud> Message-ID: <1866.1217295339@sss.pgh.pa.us> seth vidal writes: > Tom, > Please send this patch up to rpm-maint at rpm.org - I think that's a > better place for patches to rpm. I filed it here: https://bugzilla.redhat.com/show_bug.cgi?id=456636 Do you think additional nagging is required? The only reason I sent it to fedora-devel-list was I thought some other people might want the patch right away. I've just been going through my own packages using a locally patched rpm ... regards, tom lane From tgl at redhat.com Tue Jul 29 01:39:53 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jul 2008 21:39:53 -0400 Subject: koji build dies with "Bad arg to %patch: %build" In-Reply-To: <1217292659.3151.36.camel@localhost.localdomain> References: <1178.1217291473@sss.pgh.pa.us> <1217292659.3151.36.camel@localhost.localdomain> Message-ID: <1915.1217295593@sss.pgh.pa.us> Jesse Keating writes: > It's actually having problems with one of your %patch arguments. The > srpm is initially created on a RHEL5 system, before passed to mock, so > perhaps rpm on RHEL5 doesn't accept the -F flag... that is the recent > thing you changed right? Doh, that must be it. Thanks for the clue. (Is it really a good idea to be using a back-rev rpm for one part of the build process, and the latest and greatest for other parts? It certainly calls future build reproducibility into question, if you ask me.) regards, tom lane From roland at redhat.com Tue Jul 29 01:46:23 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 28 Jul 2008 18:46:23 -0700 (PDT) Subject: koji build dies with "Bad arg to %patch: %build" In-Reply-To: Tom Lane's message of Monday, 28 July 2008 21:39:53 -0400 <1915.1217295593@sss.pgh.pa.us> References: <1178.1217291473@sss.pgh.pa.us> <1217292659.3151.36.camel@localhost.localdomain> <1915.1217295593@sss.pgh.pa.us> Message-ID: <20080729014623.459AF15427E@magilla.localdomain> > (Is it really a good idea to be using a back-rev rpm for one part of > the build process, and the latest and greatest for other parts? It > certainly calls future build reproducibility into question, if you ask > me.) A problem like this came up before when kernel.spec started using fancy macros. (I think this was in koji's previous life as the RH-internal brew.) I thought they told me they fixed it. But now it occurs to me that while I talked about this very issue and took "fixed it" to mean using the rpmbuild from the buildroot for all steps of srpm-making, they might have just upgraded the servers to RHEL5 from RHEL4 and that was a new enough rpm version to fix the particular case that had come up, and that's what "they fixed it" really meant. Thanks, Roland From a.badger at gmail.com Tue Jul 29 01:58:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Jul 2008 18:58:16 -0700 Subject: CVS/Pkgdb outage In-Reply-To: <488A0FE1.4000605@redhat.com> References: <488A0FE1.4000605@redhat.com> Message-ID: <488E7938.2010100@gmail.com> Casey Dahlin wrote: > Outage Notification - 2008-07-28 01:20 UTC > > There will be an outage starting at 2008-07-28 01:20 UTC, which will last > approximately 1 hour. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2008-07-28 01:20 UTC' > > Affected Services: > > PackageDB > CVS / Source Control > > Reason for Outage: > Renaming cvsextras group to 'packager' > > Contact Information: > Casey Dahlin > The outage should now be over. The cvsextras group is now known as packager. if you are unable to commit to packages now or notice that something strange is going on with cvs commits please drop by #fedora-admin to report it. If you had any scripts that were querying for the cvsextras group, please have them query the packager group 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 rc040203 at freenet.de Tue Jul 29 02:13:18 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 29 Jul 2008 04:13:18 +0200 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217247849.4468.15.camel@rosebud> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> Message-ID: <1217297598.3042.295.camel@beck.corsepiu.local> On Mon, 2008-07-28 at 08:24 -0400, seth vidal wrote: > On Mon, 2008-07-28 at 12:54 +0200, Anders Karlsson wrote: > > Something equivalent to the Code Of Conduct that Canonical > > implemented. It worked on the ubuntu lists. No reason it would not > > work here. > > I've got no problem with a separate list. ACK. May-be we should have a fedora-support list which is restricted to addressing technical questions only? Though some people don't seem to like these discussions or the sizes they have evolved to, I consider a _general_ list like fedora-list to be an appropriate place for them. > I have A LOT of problems with > a code of conduct for fedora. ACK. Ralf From martin.langhoff at gmail.com Tue Jul 29 07:01:20 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 29 Jul 2008 19:01:20 +1200 Subject: Pungi as CD installer build tool Message-ID: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> The OLPC School Server image is a "cli" spin for a server role, and it is based on F7. Right now the install CDs are created using livecd-tools, mostly due to hysterical raisins. An old-style text installer would suit me -- and the task -- a lot better. What I am looking for then is to be able to build an install ISO that - fits on CD-sized media (but then, I only have a small set of packages) - has a text installer that ideally works well on low-end hw, and supports serial console for headless machines - has better support for off-the-beaten path arches - the same CD can be used for installs and upgrades - the kickstart environment is closer to the env you get when customising a RH build - is resilient and produces consistent builds - extra points if it can build F7 installers from F9 :-) Looking around, pungi seems to be the right tool for this, but some of the documentation options are confusing, and it doesn't seem to like the F7 repos I've thrown at it in my early lukewarm attempts. I am happy to debug things through (and join the fedora-buildsys-list), but I would really appreciate some hints as to whether I'm on the right path, or perhaps I should be using something else. cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From aph at redhat.com Tue Jul 29 08:47:08 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Jul 2008 09:47:08 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <20080728133841.GB8681@devserv.devel.redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <20080728133841.GB8681@devserv.devel.redhat.com> Message-ID: <488ED90C.9040606@redhat.com> Alan Cox wrote: > On Mon, Jul 28, 2008 at 02:10:14PM +0100, Andrew Haley wrote: >> It surely was on-topic here to talk about whether unfree binary blobs >> should be included in Fedora. > > I think it was. But the million message circular arguments about GPL > interpretation were most definitely not, and the result of that was that > everyone put the participants, subject or even the entire list on kill Sure, that's true, and perhaps we need a little more taste and restraint. However, there were some untruths about the GPL that needed to be corrected on the list. >> Do we really want to say that if any ethical question arises during >> discussion on Fedora lists, people may not address it? > > Do you really want everyone to unsubscribe and run something else. Their call. I'm not sure I really understand the problem; a thread gets boring and repetitive, so can it. Andrew. From rawhide at fedoraproject.org Tue Jul 29 08:55:33 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 29 Jul 2008 08:55:33 +0000 (UTC) Subject: rawhide report: 20080729 changes Message-ID: <20080729085533.6FCB4209D2A@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080728/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080729/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package chm2pdf A tool to convert CHM files to PDF files New package drupal-service_links Enables admins to add links to a number of sites New package gspiceui A GUI to freely available Spice Electronic circuit similators New package libasyncns Asynchronous Name Service Library New package libatasmart ATA S.M.A.R.T. Disk Health Monitoring Library New package libv4l Collection of video4linux support libraries New package oggvideotools Toolbox for manipulating Ogg video files New package perl-File-LibMagic Perlwrapper for libmagic New package sportrop-fonts A multiline decorative font New package stapitrace Instruction Tracing Tool New package xfce-mcs-plugin-gsynaptics GSynaptics icon for the Xfce Settings Manager Updated Packages: PyOpenGL-3.0.0-0.7.b5.fc10 -------------------------- * Mon Jul 28 18:00:00 2008 Nikolay Vladimirov 3.0.0-0.7.b5 - New upstream release 3.0.0b5 cacti-0.8.7b-4.fc10 ------------------- * Mon Jul 28 18:00:00 2008 Mike McGrath - 0.8.7b-4 - Added cli directory * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 0.8.7b-3 - fix my own mistake in the license tag cups-1.3.8-1.fc10 ----------------- * Mon Jul 28 18:00:00 2008 Tim Waugh 1:1.3.8-1 - 1.3.8. * Fri Jul 18 18:00:00 2008 Tim Waugh - Removed autoconf requirement by applying autoconf-generated changes to patches that caused them. Affected patches: cups-lspp. dtach-0.8-1 ----------- * Mon Jul 28 18:00:00 2008 Lon Hohberger - 0.8-1 - New upstream version 0.8 of dtach gcc-4.3.1-5 ----------- * Mon Jul 28 18:00:00 2008 Jakub Jelinek 4.3.1-5 - update from gcc-4_3-branch - PRs c++/36407, fortran/36132, fortran/36366, fortran/36824, fortran/36852, libfortran/36852, libstdc++/36552, libstdc++/36729, libstdc++/36832, middle-end/36369, middle-end/36811, middle-end/36877, rtl-optimization/35281, rtl-optimization/36419, rtl-optimization/36753, target/35492, target/35802, target/36780, target/36782, target/36784, target/36827, tree-optimization/36830 - OpenMP 3.0 bugfixes from trunk - fix occassional hangs of libgomp.c/ordered-3.c - PR middle-end/36790 gdm-2.23.1-0.2008.07.28.1.fc10 ------------------------------ * Mon Jul 28 18:00:00 2008 Jon McCann - 1:2.23.1.0.2008.07.28.1 - Update to newer snapshot gsl-1.11-3.fc10 --------------- * Mon Jul 28 18:00:00 2008 Ivana Varekova - 1.11-3 - add -fgnu89-inline flag to solve gcc4.3 problem remove gcc43 patch hplip-2.8.6b-1.fc10 ------------------- * Mon Jul 28 18:00:00 2008 Tim Waugh 2.8.6b-1 - 2.8.6b. jack-audio-connection-kit-0.109.2-3.fc10 ---------------------------------------- * Mon Jul 28 18:00:00 2008 Andy Shevchenko 0.109.2-3 - add a new requirement to be ensure we have /etc/security for postinstall script (#359291, #456830) - provide a pulseaudio start script from README.Fedora - append values for pulse-rt group to the limits.conf - update README.Fedora regarding to the recent changes kdebase-workspace-4.1.0-3.fc10 ------------------------------ * Mon Jul 28 18:00:00 2008 Rex Dieter 4.1.0-3 - respun tarball kdebindings-4.1.0-5.fc10 ------------------------ * Mon Jul 28 18:00:00 2008 Than Ngo - 4.1.0-5 - respun - get rid of kdebindings-4.1.0-kde#167450.patch that is included in new upstream * Sat Jul 26 18:00:00 2008 Rex Dieter 4.1.0-4.1 - BR: qscintilla-devel >= 2.2 kexec-tools-1.102pre-14.fc10 ---------------------------- * Mon Jul 28 18:00:00 2008 Neil Horman - 1.102pre-14 - Add video reset section to docs (bz 456572) ksh-20080725-1.fc10 ------------------- * Mon Jul 28 18:00:00 2008 Tomas Smetana 20080725-1 - new upstream version * Thu Jun 26 18:00:00 2008 Tomas Smetana 20080624-1 - new upstream version kvm-72-1.fc10 ------------- * Mon Jul 28 18:00:00 2008 Glauber Costa - 72-1 - kvm-72 libcanberra-0.4-3.fc10 ---------------------- * Mon Jul 28 18:00:00 2008 Lennart Poettering 0.4-3 - Add versioned dependency on libpulse * Sun Jul 27 18:00:00 2008 Lennart Poettering 0.4-2 - Fix module name in libcanberra-gtk-module.sh libdaemon-0.13-1.fc10 --------------------- * Tue Jul 29 18:00:00 2008 Lennart Poettering - 0.13-1 - New release 0.13 logjam-4.5.3-25.fc10 -------------------- * Mon Jul 28 18:00:00 2008 Tom "spot" Callaway - 4.5.3-25 - fix docked behavior again (bz 447146) - fix config option to start in dock again (bz 445998) - fix patch8 to apply with fuzz=0 - add patch to enable/disable "logged in since" history popup as config option merkaartor-0.0.11-0.1.rc1.fc10 ------------------------------ * Mon Jul 28 18:00:00 2008 slankes - 0.0.11-0.1.rc1 - update to release candidate mkinitrd-6.0.55-2.fc10 ---------------------- * Mon Jul 28 18:00:00 2008 Peter Jones - 6.0.55-2 - Require plymouth. mod_nss-1.0.7-9.fc10 -------------------- * Mon Jul 28 18:00:00 2008 Rob Crittenden - 1.0.7-9 - rebuild to bump NVR mutt-1.5.18-4.fc10 ------------------ * Mon Jul 28 18:00:00 2008 Miroslav Lichvar 5:1.5.18-4 - rebuild with db4.7 (Robert Scheck) (#455144) nfs-utils-1.1.3-1.fc10 ---------------------- * Mon Jul 28 18:00:00 2008 Steve Dickson 1.1.3-1 - Updated to latest upstream version: 1.1.3 ntp-4.2.4p4-7.fc10 ------------------ * Mon Jul 28 18:00:00 2008 Miroslav Lichvar 4.2.4p4-7 - reload resolv.conf after temporary failure in name resolution (#456743) - use clock_gettime - make subpackages for perl scripts and ntpdate (#452097, #456116) ochusha-0.5.99.66-0.5.cvs070110.fc10.1 -------------------------------------- perl-DBD-Pg-2.8.7-1.fc10 ------------------------ * Mon Jul 28 18:00:00 2008 Marcela Maslanova - 2.8.7-1 - new version has Pg.pm twice in two locations - update perl-DBI-1.607-1.fc10 --------------------- * Mon Jul 28 18:00:00 2008 Marcela Maslanova - 1.607-1 - update perl-Net-SSLeay-1.35-1.fc10 --------------------------- * Mon Jul 28 18:00:00 2008 Paul Howarth - 1.35-1 - update to 1.35 - drop flag and patch for enabling/disabling external tests - patch now upstream - external hosts patch no longer needed as we don't do external tests - filter out unversioned provide for perl(Net::SSLeay) - use the distro openssl flags rather than guessing them phpMyAdmin-2.11.8.1-1.fc10 -------------------------- * Mon Jul 28 18:00:00 2008 Robert Scheck 2.11.8.1-1 - Upstream released 2.11.8.1 (#456637, #456950) * Mon Jul 28 18:00:00 2008 Robert Scheck 2.11.8-1 - Upstream released 2.11.8 (#456637) postgresql-8.3.3-3.fc10 ----------------------- * Mon Jul 28 18:00:00 2008 Tom Lane 8.3.3-3 - Fix build failure caused by new default patch fuzz = 0 policy in rawhide. preload-0.6.3-1.fc10 -------------------- * Mon Jul 28 18:00:00 2008 Behdad Esfahbod - 0.6.3-1 - Update to 0.6.3 * Mon Jul 28 18:00:00 2008 Behdad Esfahbod - 0.6.2-1 - Update to 0.6.2 - Actually resolves bug #456742 this time * Mon Jul 28 18:00:00 2008 Behdad Esfahbod - 0.6.1-1 - Update to 0.6.1 - Resolves bug #456742 puppet-0.24.5-1.fc10 -------------------- * Mon Jul 28 18:00:00 2008 David Lutterkort - 0.24.5-1 - Add /usr/bin/puppetdoc * Thu Jul 24 18:00:00 2008 Brenton Leanhardt - New version - man pages now ship with tarball - examples/code moved to root examples dir in upstream tarball python-fedora-0.3.4-1.fc10 -------------------------- * Mon Jul 28 18:00:00 2008 Toshio Kuratomi - 0.3.4-1 - Small fix to proxyclient.send_request() for sequence types. shadow-utils-4.1.2-4.fc10 ------------------------- * Mon Jul 28 18:00:00 2008 Peter Vrabec 2:4.1.2-4 - fix configure options (#456748) snake-0.11-0.9.fc10 ------------------- * Mon Jul 28 18:00:00 2008 James Laska 0.11-0.9 - ticket#60 - Added snake/anamon.py to packaging * Mon Jul 28 18:00:00 2008 James Laska 0.11-0.8 - ticket#59 - snake-install-tui will auto-register an unregistered system when using server-side kickstarts - ticket#57 - Fixed snake-install -c argument handling - Enable 'writefp' support for python templates subversion-1.5.1-2 ------------------ * Mon Jul 28 18:00:00 2008 Joe Orton 1.5.1-2 - update to 1.5.1 - require suitable APR telepathy-glib-0.7.12-2.fc10 ---------------------------- * Mon Jul 28 18:00:00 2008 Brian Pepple - 0.7.12-2 - Update broken-pkgconfig patch. (#456621) tix-8.4.3-1.fc10 ---------------- * Mon Jul 28 18:00:00 2008 Tom "spot" Callaway - 1:8.4.3-1 - update to 8.4.3 - don't apply tix-8.4.2-tcl8.5.patch, no longer needed unixODBC-2.2.12-9.fc10 ---------------------- * Mon Jul 28 18:00:00 2008 Tom Lane 2.2.12-9 - Fix build failure caused by new default patch fuzz = 0 policy in rawhide. xapian-bindings-1.0.7-2.fc10 ---------------------------- * Mon Jul 28 18:00:00 2008 Adel Gadllah 1.0.7-2 - Enable ruby bindings RH #456951, patch by Scott Seago Summary: Added Packages: 11 Removed Packages: 0 Modified Packages: 39 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sobby-0.4.4-4.fc10.i386 requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so zhcon-0.2.6-8.fc9.i386 requires libgpm.so.1 Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sobby-0.4.4-4.fc10.x86_64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.x86_64 requires libgpm.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sobby-0.4.4-4.fc10.ppc requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so zhcon-0.2.6-8.fc9.ppc requires libgpm.so.1 Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sobby-0.4.4-4.fc10.ppc64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) zhcon-0.2.6-8.fc9.ppc64 requires libgpm.so.1()(64bit) From jwboyer at gmail.com Tue Jul 29 01:31:20 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 29 Jul 2008 03:31:20 +0200 Subject: The results are in for the Fedroa 10 naming Message-ID: <000301c8f11a$cde8d110$ba00000a@grecom.local> Drum roll... And the winner of the Fedora 10 codename is: Cambridge The full GPG-signed information from our election coordinator, Nigel Jones, including vote totals, is located here: http://jwboyer.fedorapeople.org/fedora10relname.txt.asc Many thanks to the Board, Paul Frields, and Nigel Jones for their effort in getting the name candidates and vote set up. josh -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rjones at redhat.com Tue Jul 29 12:48:53 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 29 Jul 2008 13:48:53 +0100 Subject: latrace Message-ID: <20080729124853.GA1483@amd.home.annexia.org> Has anyone looked at packaging 'latrace', apparently a library call tracer similar to strace? I don't see it in Rawhide at the moment anyway. http://freshmeat.net/projects/latrace/ http://latrace.sourceforge.net/ 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 zprikryl at redhat.com Tue Jul 29 12:59:44 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Tue, 29 Jul 2008 14:59:44 +0200 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <1212672120.29467.644.camel@localhost.localdomain> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> <4847E203.9020607@kanarip.com> <1212672120.29467.644.camel@localhost.localdomain> Message-ID: <488F1440.7080608@redhat.com> Adam Jackson wrote: > * Tue Oct 10 2006 Petr Rockai - 1.20-1-76 > - align sleeps to tick boundary, should reduce cpu wakeups > on laptops, fixes #205064 (patch by Arjan van de Ven) > - disable gpm altogether in runlevel 5, it is probably not > worth the overhead considering it is barely used at all > > Sigh. The constant struggle. Please turn it off again, thanks. This bug shouldn't occur in new version of gpm. -- Zdenek Prikryl From nikolay at vladimiroff.com Tue Jul 29 12:45:19 2008 From: nikolay at vladimiroff.com (Nikolay Vladimirov) Date: Tue, 29 Jul 2008 15:45:19 +0300 Subject: wine unstable releases Message-ID: <20080729124518.GA10094@marvin> Now there are stable and unstable releases of wine and in fedora only the stable release is available. I think this isn't very useful. The stable branch is not that good and bugfix releases will be quite rare. There is no point in sticking with the stable branch since for 9 years or so there have been only development releases. Also if the unstable branch is maintained it will be easier for fedora users to submit bug reports and application reviewes relevant to the latest version. I'm willing to comaintain wine and update it in rawhide as frequently as I can. So I'm thinking about maintaining the unstable branch in rawhide and when that becomes a fedora release I'll just wait until a stable wine released then push it as an update and leave it(the stable wine branch releases are tied to major gnome and xorg releases). And also continue with the frequent releases in rawhide. Also latest wine for stable fedora releases will be great. The problem is with the 2 week release cycle. It's 2 days for packaging and building, 5 days in testing and 2-3 days as pending, it will be up to date a week in the best case and then it will be outdated again. Any ideas how can we have the latest wine with a day or two delay? There are frequent requests in bugzilla for the latest wine to be available as update. So is this a problem of some sort? Wine is somewhat major application and I don't want to mess up with some release policy or some other stuff. -- NV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From zprikryl at redhat.com Tue Jul 29 13:00:33 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Tue, 29 Jul 2008 15:00:33 +0200 Subject: gpm - Re: rawhide report: 20080605 changes In-Reply-To: <4847E203.9020607@kanarip.com> References: <20080605094243.32E3E209CE5@releng1.fedora.phx.redhat.com> <200806050840.56826.sgrubb@redhat.com> <4847E203.9020607@kanarip.com> Message-ID: <488F1471.5030309@redhat.com> Jeroen van Meeuwen wrote: > Steve Grubb wrote: >> On Thursday 05 June 2008 05:42:42 Rawhide wrote: >>> gpm-1.20.3-2.fc10 >>> ----------------- >>> * Wed Jun ? 4 18:00:00 2008 Zdenek Prikryl - >>> 1.20.3-2 >>> - Enable gpm in runlevel 5 >> >> I have to ask why? From rpm -qi: >> >> Description : >> Gpm provides mouse support to text-based Linux applications like the >> Emacs editor and the Midnight Commander file management system. >> >> That would be runlevel 4 and lower. >> > > Pressing ctrl-alt-f{1,2,3,4,5,6} might get you to appreciate gpm in > runlevel 5 Yes, that is the reason, why I enabled it again. -- Zdenek Prikryl From rakesh.pandit at gmail.com Tue Jul 29 13:04:02 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 29 Jul 2008 18:34:02 +0530 Subject: latrace In-Reply-To: <20080729124853.GA1483@amd.home.annexia.org> References: <20080729124853.GA1483@amd.home.annexia.org> Message-ID: 2008/7/29 Richard W.M. Jones : > Has anyone looked at packaging 'latrace', apparently a library call > tracer similar to strace? I don't see it in Rawhide at the moment > anyway. > > http://freshmeat.net/projects/latrace/ > http://latrace.sourceforge.net/ > I too cannot see it in pkgdb nor can find any bugzilla review request. I will package it this weekend, if no one picks it up till then. -- Regards, Rakesh Pandit From cra at WPI.EDU Tue Jul 29 13:27:21 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 29 Jul 2008 09:27:21 -0400 Subject: latrace In-Reply-To: References: <20080729124853.GA1483@amd.home.annexia.org> Message-ID: <20080729132721.GL5960@angus.ind.WPI.EDU> On Tue, Jul 29, 2008 at 06:34:02PM +0530, Rakesh Pandit wrote: > 2008/7/29 Richard W.M. Jones : > > Has anyone looked at packaging 'latrace', apparently a library call > > tracer similar to strace? I don't see it in Rawhide at the moment > > anyway. > > > > http://freshmeat.net/projects/latrace/ > > http://latrace.sourceforge.net/ > > > > I too cannot see it in pkgdb nor can find any bugzilla review request. > > I will package it this weekend, if no one picks it up till then. How is it different than ltrace? >rpm -qif `which ltrace` Name : ltrace Relocations: (not relocatable) Version : 0.5 Vendor: Fedora Project Release : 10.45svn.fc9 Build Date: Mon 10 Mar 2008 06:59:12 AM EDT Install Date: Mon 07 Apr 2008 08:39:52 PM EDT Build Host: xenbuilder1.fedora.redhat.com Group : Development/Debuggers Source RPM: ltrace-0.5-10.45svn.fc9.src.rpm Size : 113682 License: GPLv2+ Signature : DSA/SHA1, Mon 10 Mar 2008 09:00:23 AM EDT, Key ID da84cbd430c9ecf8Packager : Fedora Project URL : http://ltrace.alioth.debian.org/ Summary : Tracks runtime library calls from dynamically linked executables Description : Ltrace is a debugging program which runs a specified command until the command exits. While the command is executing, ltrace intercepts and records both the dynamic library calls called by the executed process and the signals received by the executed process. Ltrace can also intercept and print system calls executed by the process. You should install ltrace if you need a sysadmin tool for tracking the execution of processes. From jwboyer at gmail.com Tue Jul 29 13:27:59 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 29 Jul 2008 09:27:59 -0400 Subject: latrace In-Reply-To: <20080729124853.GA1483@amd.home.annexia.org> References: <20080729124853.GA1483@amd.home.annexia.org> Message-ID: <1217338079.8883.0.camel@weaponx> On Tue, 2008-07-29 at 13:48 +0100, Richard W.M. Jones wrote: > Has anyone looked at packaging 'latrace', apparently a library call > tracer similar to strace? I don't see it in Rawhide at the moment > anyway. > > http://freshmeat.net/projects/latrace/ > http://latrace.sourceforge.net/ We already have 'ltrace'. Is that not suitable? Description : Ltrace is a debugging program which runs a specified command until the command exits. While the command is executing, ltrace intercepts and records both the dynamic library calls called by the executed process and the signals received by the executed process. Ltrace can also intercept and print system calls executed by the process. josh From ajax at redhat.com Tue Jul 29 13:46:54 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 29 Jul 2008 09:46:54 -0400 Subject: koji build dies with "Bad arg to %patch: %build" In-Reply-To: <1915.1217295593@sss.pgh.pa.us> References: <1178.1217291473@sss.pgh.pa.us> <1217292659.3151.36.camel@localhost.localdomain> <1915.1217295593@sss.pgh.pa.us> Message-ID: <1217339214.3747.69.camel@localhost.localdomain> On Mon, 2008-07-28 at 21:39 -0400, Tom Lane wrote: > Jesse Keating writes: > > It's actually having problems with one of your %patch arguments. The > > srpm is initially created on a RHEL5 system, before passed to mock, so > > perhaps rpm on RHEL5 doesn't accept the -F flag... that is the recent > > thing you changed right? > > Doh, that must be it. Thanks for the clue. > > (Is it really a good idea to be using a back-rev rpm for one part of > the build process, and the latest and greatest for other parts? It > certainly calls future build reproducibility into question, if you ask > me.) I have suggested - multiple times - that for mock the only thing the system's rpm should be used for is generating the chroot, and that after doing that (and chrooting inside and rebuilding the rpmdb) all further use of rpm would be from inside the chroot. There is a minor issue in doing so, which is that you'd either need to teach yum about how to run in a chroot, or you'd need to modify mock to get packages into the buildroot before running (the chroot's) yum on them. The reason is that if you don't, then the chroot's yum needs access to the network, which is generally taken to be a bad idea. The other problem with this is the construction of the SRPM itself, which should also be done with the rpm that's expected to build it. Again, we could do this by constructing a chroot containing rpm and the scm tool of choice for checkout, and at least in principle that bit of network access is no more problematic than what we're already doing. The patch, I'm sure, would be gratefully accepted. - ajax -------------- 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 pmachata at redhat.com Tue Jul 29 14:13:11 2008 From: pmachata at redhat.com (Petr Machata) Date: Tue, 29 Jul 2008 16:13:11 +0200 Subject: latrace In-Reply-To: <20080729132721.GL5960@angus.ind.WPI.EDU> References: <20080729124853.GA1483@amd.home.annexia.org> <20080729132721.GL5960@angus.ind.WPI.EDU> Message-ID: <20080729141311.GA18226@hridell.englab.brq.redhat.com> On Tue, Jul 29, 2008 at 09:27:21AM -0400, Chuck Anderson wrote: > On Tue, Jul 29, 2008 at 06:34:02PM +0530, Rakesh Pandit wrote: > > I too cannot see it in pkgdb nor can find any bugzilla review request. > > > > I will package it this weekend, if no one picks it up till then. > > How is it different than ltrace? ltrace doesn't handle multi-threaded applications, but can trace system calls. It has extensible parameter formatter (dunno about latrace). latrace will have considerably better performance, because there is no context switch involved in tracing, like is the case for traditional breakpoint based tracing. Other related project is dltrace, which like latrace uses LD_AUDIT mechanism. It resides in elfutils repository, which is unfortunate, because fedorahosted doesn't (yet, hopefully) give read-only access for some monotone-related reason. Essentially no work is done on dltrace. I can upload srpm of latest greatest if there is an interest, e.g. among latrace upstream. Yet another related project is ftrace from the "frysk" suite. That uses traditional ptrace approach. It handles threads, allows cherry picking of symbols to trace, and is not limited to symbols with PLT entries. The downside is that it's a bulky monster written in java. Personally I believe the way for future is to write all the tracing and event-handling tools on top of / as part of systemtap, as soon as it's capable of userspace tracing that is. That would give Linux single tool for analysis and debugging of everything from the kernel up. I don't really know much about systemtap though. PM -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From behdad at behdad.org Tue Jul 29 14:23:18 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 29 Jul 2008 07:23:18 -0700 Subject: latrace In-Reply-To: <20080729141311.GA18226@hridell.englab.brq.redhat.com> References: <20080729124853.GA1483@amd.home.annexia.org> <20080729132721.GL5960@angus.ind.WPI.EDU> <20080729141311.GA18226@hridell.englab.brq.redhat.com> Message-ID: <1217341398.7557.1.camel@behdad.behdad.org> On Tue, 2008-07-29 at 16:13 +0200, Petr Machata wrote: > > Personally I believe the way for future is to write all the tracing > and event-handling tools on top of / as part of systemtap, as soon as > it's capable of userspace tracing that is. That would give Linux > single tool for analysis and debugging of everything from the kernel > up. I don't really know much about systemtap though. Which requires root access... -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From fche at redhat.com Tue Jul 29 15:07:40 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 29 Jul 2008 11:07:40 -0400 Subject: latrace In-Reply-To: <1217341398.7557.1.camel@behdad.behdad.org> (Behdad Esfahbod's message of "Tue, 29 Jul 2008 07:23:18 -0700") References: <20080729124853.GA1483@amd.home.annexia.org> <20080729132721.GL5960@angus.ind.WPI.EDU> <20080729141311.GA18226@hridell.englab.brq.redhat.com> <1217341398.7557.1.camel@behdad.behdad.org> Message-ID: Behdad Esfahbod writes: > On Tue, 2008-07-29 at 16:13 +0200, Petr Machata wrote: >> Personally I believe the way for future is to write all the tracing >> and event-handling tools on top of / as part of systemtap [...] > > Which requires root access... FWIW, that is temporary. - FChE From wwoods at redhat.com Tue Jul 29 15:54:51 2008 From: wwoods at redhat.com (Will Woods) Date: Tue, 29 Jul 2008 11:54:51 -0400 Subject: XULRunner and you Message-ID: <1217346891.3273.31.camel@metroid.rdu.redhat.com> In last week's QA meeting, Chris Aillon (aka caillon, our fearless firefox/xulrunner maintainer) stopped by to tell us what happened with xulrunner dep breakage, and how package maintainers can help reduce / prevent it in the future. Here's a quick summary: There are two APIs provided by xulrunner - the stable API (gecko-devel), and the unstable one (gecko-devel-unstable). The stable API, as you might guess, is not expected to change. So if a package uses the stable API, it won't have any problems when the xulrunner package is updated. The unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated. Packages using the stable API should have: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9 Packages using the unstable API should have: %define gecko_ver 1.9.0.1 Requires: gecko-libs = %{gecko_ver} BuildRequires: gecko-devel-unstable = %{gecko_ver} Anything with BuildRequire: xulrunner-devel or xulrunner-devel-unstable should be changed to gecko-devel or gecko-devel-unstable. (The xulrunner-devel packages provide those things). Also: if your package uses the -unstable API, please send caillon at redhat.com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update. caillon is out 'til next week, so it would be really good if you can help clean this stuff up in his absence. Thanks! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From bpepple at fedoraproject.org Tue Jul 29 15:56:35 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 29 Jul 2008 11:56:35 -0400 Subject: Plan for tomorrows (20080730) FESCO meeting Message-ID: <1217346995.10585.4.camel@truman> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 UTC (NOTE: the new day and time) in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance -- all /topic FESCo-Meeting -- Clarification of spins as features - http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20071206 - bpepple, all /topic FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/BetterWebcamSupport - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From braden at endoframe.com Tue Jul 29 16:22:58 2008 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 29 Jul 2008 12:22:58 -0400 Subject: XULRunner and you In-Reply-To: <1217346891.3273.31.camel@metroid.rdu.redhat.com> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> Message-ID: <1217348578.764.141.camel@hinge.endoframe.net> On Tue, 2008-07-29 at 11:54 -0400, Will Woods wrote: > In last week's QA meeting, Chris Aillon (aka caillon, our fearless > firefox/xulrunner maintainer) stopped by to tell us what happened with > xulrunner dep breakage, and how package maintainers can help reduce / > prevent it in the future. Here's a quick summary: > > There are two APIs provided by xulrunner - the stable API (gecko-devel), > and the unstable one (gecko-devel-unstable). Why does xulrunner-devel-unstable provide some of the same headers (at a different path) that xulrunner-devel does? I'm specifically noticing SpiderMonkey headers; though there might be others. -- Braden McDaniel e-mail: Jabber: From silfreed at silfreed.net Tue Jul 29 16:26:30 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 29 Jul 2008 09:26:30 -0700 Subject: XULRunner and you In-Reply-To: <1217346891.3273.31.camel@metroid.rdu.redhat.com> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> Message-ID: <200807290926.48293.silfreed@silfreed.net> On Tuesday 29 July 2008 08:54:51 Will Woods wrote: > Packages using the stable API should have: > ? Requires: gecko-libs >= 1.9 > ? BuildRequires: gecko-devel >= 1.9 How would we go about requiring only 1.9* versions? I would like the spec/package to break if/when xulrunner goes to the next version (obviously not in this release, but at some point in the future). For example, I can't do: Requires: gecko-libs < 2.0 Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example). Perhaps it would be best if xulrunner also added something like: Provides: gecko-libs-api = 1.9 -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From vpivaini at cs.helsinki.fi Tue Jul 29 16:29:23 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 29 Jul 2008 19:29:23 +0300 Subject: XULRunner and you In-Reply-To: <1217348578.764.141.camel@hinge.endoframe.net> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> <1217348578.764.141.camel@hinge.endoframe.net> Message-ID: <200807291929.26143.vpivaini@cs.helsinki.fi> Braden McDaniel wrote: > Why does xulrunner-devel-unstable provide some of the same headers (at a > different path) that xulrunner-devel does? I'm specifically noticing > SpiderMonkey headers; though there might be others. Good question, I asked about the same thing in my mail a while ago: . My package mozvoikko needs e.g. mozISpellCheckingEngine.h, which is in /usr/include/xulrunner-sdk-1.9/spellchecker/ (xulrunner-devel) and in /usr/include/xulrunner-sdk-1.9/unstable/ (xulrunner-devel-unstable). Using directories like "spellchecker" I can get mozvoikko to build without the unstable devel package, but I wonder if I need the "unstable requirements style" or will the "stable requirements style" do. -- Ville-Pekka Vainio From jkeating at redhat.com Tue Jul 29 16:59:04 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jul 2008 12:59:04 -0400 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> Message-ID: <1217350744.3151.60.camel@localhost.localdomain> On Tue, 2008-07-29 at 19:01 +1200, Martin Langhoff wrote: > Looking around, pungi seems to be the right tool for this, but some of > the documentation options are confusing, and it doesn't seem to like > the F7 repos I've thrown at it in my early lukewarm attempts. I am > happy to debug things through (and join the fedora-buildsys-list), but > I would really appreciate some hints as to whether I'm on the right > path, or perhaps I should be using something else. Pungi is mostly meant to run for the release it exists on. So if you wanted to compose F7 releases, you need to run the F7 pungi on F7. This is due to a number of reasons, mostly the APIs of the tools it uses as well as the kernel version that will be booted, etc... F7's pungi was really a first attempt and I don't think it was that good. Rawhide's pungi is far better, but in some of the problems I discovered along the way we've fixed in other pieces of software like yum and anaconda. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 leemhuis.info Tue Jul 29 17:25:57 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 29 Jul 2008 19:25:57 +0200 Subject: Plan for tomorrows (20080730) FESCO meeting In-Reply-To: <1217346995.10585.4.camel@truman> References: <1217346995.10585.4.camel@truman> Message-ID: <488F52A5.5050609@leemhuis.info> On 29.07.2008 17:56, Brian Pepple wrote: > > /topic FESCo-Meeting -- > http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance -- all Hmmm. Looks to me like the "The Solution" section needs to be integrated into http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers should it be accepted by FESCo. Sure, a separate document could work, but that way seems confusing to me and will not help making live easier for contributors. So why not propose the whole concept as text patch to that page? Then it's - easy to see what will be changed and how the page will look afterwards - just a single easy commit that needs to be done once the whole idea got accepted Could be even done on a temporary wiki page, then it's quite easy to do with the standard wiki diff tools. Just my 2 cent. Cu knurd From kwade at redhat.com Tue Jul 29 17:38:40 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 29 Jul 2008 10:38:40 -0700 Subject: F10 Alpha relnotes one-pager Message-ID: <1217353120.10618.56.camel@calliope.phig.org> The F10 (Cambridge) Alpha release notes one-page is stubbed out and ready for filling in. In particular, you all want to put content under this section: https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes#Release_Overview It is generally broken in to: * Desktop * Applications * System That is our working structure for these one-sheet notes. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Tue Jul 29 17:53:37 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 29 Jul 2008 17:53:37 +0000 Subject: F10 Alpha relnotes one-pager In-Reply-To: <1217353120.10618.56.camel@calliope.phig.org> References: <1217353120.10618.56.camel@calliope.phig.org> Message-ID: <1217354017.26818.47.camel@victoria> On Tue, 2008-07-29 at 10:38 -0700, Karsten 'quaid' Wade wrote: > The F10 (Cambridge) Alpha release notes one-page is stubbed out and > ready for filling in. > > In particular, you all want to put content under this section: > > https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes#Release_Overview > > It is generally broken in to: > > * Desktop > * Applications > * System > > That is our working structure for these one-sheet notes. And Karsten's right, you *do* want to put content into this page. The press is paying attention to our feature and punch lists. You don't need to write anything fancy, the Docs team can help with that part. You may even be able to copy from the feature page, if you think what you have there works well. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Tue Jul 29 17:56:45 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Jul 2008 13:56:45 -0400 Subject: F10 Alpha relnotes one-pager In-Reply-To: <1217354017.26818.47.camel@victoria> References: <1217353120.10618.56.camel@calliope.phig.org> <1217354017.26818.47.camel@victoria> Message-ID: <1217354205.5596.10.camel@localhost.localdomain> On Tue, 2008-07-29 at 17:53 +0000, Paul W. Frields wrote: > On Tue, 2008-07-29 at 10:38 -0700, Karsten 'quaid' Wade wrote: > > The F10 (Cambridge) Alpha release notes one-page is stubbed out and > > ready for filling in. > > > > In particular, you all want to put content under this section: > > > > https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes#Release_Overview > > > > It is generally broken in to: > > > > * Desktop > > * Applications > > * System > > > > That is our working structure for these one-sheet notes. > > And Karsten's right, you *do* want to put content into this page. The > press is paying attention to our feature and punch lists. You don't > need to write anything fancy, the Docs team can help with that part. > You may even be able to copy from the feature page, if you think what > you have there works well. Its a bit hard to know what to put there, though. "Around the time the alpha was frozen", session management may have been busted...". Are there candidate isos for the alpha available for inspection somewhere ? From moe at blagblagblag.org Tue Jul 29 17:57:41 2008 From: moe at blagblagblag.org (jeff) Date: Tue, 29 Jul 2008 14:57:41 -0300 Subject: Anaconda: loss fonts In-Reply-To: References: Message-ID: <488F5A15.5000202@blagblagblag.org> Vnpenguin wrote: > Hi, > By using pungi on FC9-i386 (with all updates) I can make 1 > installation CD which is bootable. But in Anaconda I loss all fonts. > Here is the screenshot: http://vnoss.net/pub/fc9-err.png > > I miss some packages in my .ks files ? I have already > dejavu-lgc-fonts, liberation-fonts & urw-fonts in my ks. > > Any idea for help ? Try with adding dejavu-fonts to your kickstart (maybe xorg-x11-font-utils needed there too?). -Jeff From eric.tanguy at univ-nantes.fr Tue Jul 29 18:04:43 2008 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Tue, 29 Jul 2008 20:04:43 +0200 Subject: Presto Message-ID: <488F5BBB.3070500@univ-nantes.fr> Will presto be a feature for fedora 10 ? Thanks Eric From kwade at redhat.com Tue Jul 29 18:09:18 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 29 Jul 2008 11:09:18 -0700 Subject: F10 Alpha relnotes one-pager In-Reply-To: <1217354205.5596.10.camel@localhost.localdomain> References: <1217353120.10618.56.camel@calliope.phig.org> <1217354017.26818.47.camel@victoria> <1217354205.5596.10.camel@localhost.localdomain> Message-ID: <1217354958.10618.83.camel@calliope.phig.org> On Tue, 2008-07-29 at 13:56 -0400, Matthias Clasen wrote: > Its a bit hard to know what to put there, though. > > "Around the time the alpha was frozen", session management may have been > busted...". > > Are there candidate isos for the alpha available for inspection > somewhere ? Several things to keep in mind: 1. This wiki page should be updated even after the Alpha ISO is released. It is a living set of notes. 2. Your testing audience is your first focus, tech journalists second. 3. Tell people what you want them to test. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Tue Jul 29 18:45:37 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 29 Jul 2008 19:45:37 +0100 Subject: XULRunner and you In-Reply-To: <200807290926.48293.silfreed@silfreed.net> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> <200807290926.48293.silfreed@silfreed.net> Message-ID: <5256d0b0807291145o41f29cd2mcb0444b356cab2fa@mail.gmail.com> >> Packages using the stable API should have: >> Requires: gecko-libs >= 1.9 >> BuildRequires: gecko-devel >= 1.9 > > How would we go about requiring only 1.9* versions? I would like the > spec/package to break if/when xulrunner goes to the next version (obviously > not in this release, but at some point in the future). > > For example, I can't do: > Requires: gecko-libs < 2.0 > > Because I'm not guaranteed that the next version will *be* 2.0 (it might be > 1.10, for example). It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though. Peter From drago01 at gmail.com Tue Jul 29 18:48:53 2008 From: drago01 at gmail.com (drago01) Date: Tue, 29 Jul 2008 20:48:53 +0200 Subject: XULRunner and you In-Reply-To: <5256d0b0807291145o41f29cd2mcb0444b356cab2fa@mail.gmail.com> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> <200807290926.48293.silfreed@silfreed.net> <5256d0b0807291145o41f29cd2mcb0444b356cab2fa@mail.gmail.com> Message-ID: On Tue, Jul 29, 2008 at 8:45 PM, Peter Robinson wrote: >>> Packages using the stable API should have: >>> Requires: gecko-libs >= 1.9 >>> BuildRequires: gecko-devel >= 1.9 >> >> How would we go about requiring only 1.9* versions? I would like the >> spec/package to break if/when xulrunner goes to the next version (obviously >> not in this release, but at some point in the future). >> >> For example, I can't do: >> Requires: gecko-libs < 2.0 >> >> Because I'm not guaranteed that the next version will *be* 2.0 (it might be >> 1.10, for example). > > It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF > 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though. < 1.9.1 ? From stickster at gmail.com Tue Jul 29 18:54:32 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 29 Jul 2008 14:54:32 -0400 Subject: F10 Alpha relnotes one-pager In-Reply-To: <1217354958.10618.83.camel@calliope.phig.org> References: <1217353120.10618.56.camel@calliope.phig.org> <1217354017.26818.47.camel@victoria> <1217354205.5596.10.camel@localhost.localdomain> <1217354958.10618.83.camel@calliope.phig.org> Message-ID: <1217357672.26818.53.camel@victoria> On Tue, 2008-07-29 at 11:09 -0700, Karsten 'quaid' Wade wrote: > On Tue, 2008-07-29 at 13:56 -0400, Matthias Clasen wrote: > > > Its a bit hard to know what to put there, though. > > > > "Around the time the alpha was frozen", session management may have been > > busted...". > > > > Are there candidate isos for the alpha available for inspection > > somewhere ? > > Several things to keep in mind: > > 1. This wiki page should be updated even after the Alpha ISO is > released. It is a living set of notes. > > 2. Your testing audience is your first focus, tech journalists second. > > 3. Tell people what you want them to test. Thanks for clarifying this, Karsten. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cdahlin at redhat.com Tue Jul 29 19:37:08 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 29 Jul 2008 15:37:08 -0400 Subject: Presto In-Reply-To: <488F5BBB.3070500@univ-nantes.fr> References: <488F5BBB.3070500@univ-nantes.fr> Message-ID: <488F7164.6040200@redhat.com> Tanguy Eric wrote: > Will presto be a feature for fedora 10 ? > Thanks > Eric > We're hoping so :) I just committed some changes to presto that should make it easier to work with from a developer perspective, which in turn should speed its introduction into Bodhi. Luke Macken is working on the Bodhi integration. Once that's done, there shouldn't be any obstacles to deploying it for F10. --CJD From j.w.r.degoede at hhs.nl Tue Jul 29 20:01:17 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 29 Jul 2008 22:01:17 +0200 Subject: Orphaning 8Kingdoms Message-ID: <488F770D.2070006@hhs.nl> Hi All, I've just orphaned 8KingDoms, as I've been receiving several bug reports about crashes left and right, upstream is dead and I have other priorities then fixing bugs in a dead code base for a fun but nothing really special game. So if anyone wants it, take it please, I've accumulated all the bugs here: https://bugzilla.redhat.com/show_bug.cgi?id=456844 Regards, Hans From markg85 at gmail.com Tue Jul 29 21:01:08 2008 From: markg85 at gmail.com (Mark) Date: Tue, 29 Jul 2008 23:01:08 +0200 Subject: GTKEntry and all that uses it don't have a default transparent background Message-ID: <6e24a8e80807291401n5ea8fbd3qddaeead13920295f@mail.gmail.com> Hi, Before i get the messages again like: have you made a bugzilla report? Yea: http://bugzilla.gnome.org/show_bug.cgi?id=536121 And got marked as duplicate of: http://bugzilla.gnome.org/show_bug.cgi?id=534611 Now what is the issue? ------------------------------------------- Ever since i see rounded entry fields in linux i keep seeing a damn gray stroke around it that fills the entry till it's... not round anymore.. With some themes that doesn't make a difference and still looks nice but as soon as a theme stasts using just gradient and just one gtkentry widget or one that's related of it you will notice the annoying gray border around it. The bug report itself is "just" 2 months old but the issue itself is visible for far longer. Not understanding the following --------------------------------------------- What i don't understand is that some widgets have this issue and some don't For example a radio widget doesn't have this bug. So to me that comes like: "see we can make it right but refuse it for other widgets".. now why exactly in understandable terms is this bug (that's what is it) still in GTK? The solution?? -------------------------------------------- In the bugzilla report Matthias Clasen (RedHat employee) says: "...and it is still a theme issue. This border is drawn by nodoka, clearlooks or whatever theme you choose." Now to say that is fine. perhaps he is right perhaps not. But because he also is a GTK developer and this issue is so wide spread at the moment (visible in every distribution that uses gnome and rounded corners.. Fedora, Ubuntu.. you name it.) so to quote myself on what i had to say about it: "Why do you say it's a issue of the theme engines? your a GTK programmer so you can tell the engine developers what they do wrong and how to fix it. But because big distributions like Fedora (you know all about it ^_^) and Ubuntu are released with those ugly borders and while they both have more then enough resources to adjust the theme engine to show those borders normally.. So How to fix this issue that all theme engine developers encounter and can't fix when they use rounded borders?" Do i need to say more? Why do i care about this? -------------------------------------------- Well.. i said it more often here. I want to learn c++ and it's finally gonna happen in about a month then for about 4 months to start. I already looked at QT and GTK to develop Linux application. For me QT is fine but seems so much and hard to learn.. (i know.. looking at it way to early but just looking at what i need to learn). GTK seems more friendly to learn but i absolutely hate the small little bugs that are in it and open and probably easy to fix. It's just 2 bugs a.t.m. that really bother me. 1 is solved: line truncating and saying like 2 lines then truncate the rest. Which is a bug that was open for 7 years or so!!! and still not in Gnome!! (really something to be ashamed of. i did even got it working here but then encountered other issues.. so the gnome people should just take a look at it.. for them it's probably a 5 minute job and a 7 year old bug can be closed) and the other one is this bug. Just minor really but does give me a nasty feeling about GTK. Another annoying point is that bugs stay unconfirmed for so long while they are just confirmed or even solved! For me.. i still don't know if i need to start learning QT or GTK or even abandon those 2 completely and try wxWidgets.. And that's why i care. I don't want to learn a "product" that's (sorry) poorly maintained or where i get the feeling that filling bugs is useless (got both with Gnome and GTK). Why did i posted this here? -------------------------------------------- I wanted information of this and give it some attention. GTK is mostly developed by redhat people and fedora is using the latest GTK version. And because Fedora is now in development for version 10 this is the perfect time to look at that darn bug as well. That's why i post it here. My goal -------------------------------------------- First just to get the attention of this bug! Second to get this bug fixed! once and for all with the next fedora release. Anything i said above is just how i feel about it. It might not be the case for others! Don't take anything personal. (oke, the part about Matthias Clasen excluded). cc's him just in case. From martin.langhoff at gmail.com Tue Jul 29 21:06:22 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 30 Jul 2008 09:06:22 +1200 Subject: Pungi as CD installer build tool In-Reply-To: <1217350744.3151.60.camel@localhost.localdomain> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> Message-ID: <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> 2008/7/30 Jesse Keating : > Pungi is mostly meant to run for the release it exists on. So if you > wanted to compose F7 releases, you need to run the F7 pungi on F7. This > is due to a number of reasons, mostly the APIs of the tools it uses as > well as the kernel version that will be booted, etc... Ok. I don't particularly like the idea, but I can live with that if it can run inside mock. > F7's pungi was really a first attempt and I don't think it was that > good. Rawhide's pungi is far better, but in some of the problems I > discovered along the way we've fixed in other pieces of software like > yum and anaconda. Does F7's pungi build a good F7 distro installer? What did RH/Fedora use to build F1~F6? The RH/Fedora team has been building installer CDs for a long time... I am sure you guys have some well-worn tools for that :-) maybe I should be using something old and time-tested? I don't mind it being written in ksh... In any case, I am most interested in understanding whether it is designed to do what I am trying to do. If I fix/workaround its limitations, is it the right tool to build installer CDs that... ? - fit on CD-sized media (but then, I only have a small set of packages) - have a text installer that ideally works well on low-end hw, and supports serial console for headless machines - have good support for off-the-beaten path arches - can be used for installs and upgrades - the kickstart environment - during install! - is close to the env you get when customising a RH build - are resilient and produces consistent builds Are there other good alternatives I should be considering? So far I have been working with livecd-tools, which is designed to do something else. I want to switch to the right tool. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From aoliva at redhat.com Tue Jul 29 21:09:02 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Tue, 29 Jul 2008 18:09:02 -0300 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DC536.30302@redhat.com> (Andrew Haley's message of "Mon\, 28 Jul 2008 14\:10\:14 +0100") References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: On Jul 28, 2008, Andrew Haley wrote: > It surely was on-topic here to talk about whether unfree binary blobs > should be included in Fedora. +1 I wonder why nobody's complaining about all this traffic on this non-technical thread on a list that people complained was supposed to be restricted to technical content. Heck, why was the discussion even started here? Double standards, as usual? > Do we really want to say that if any ethical question arises during > discussion on Fedora lists, people may not address it? Seems like that's the general feeling of those who demand silence about it. Perhaps a separate list named "fedora-truth" or "fedora-ethics", for this kind of discussion, would make it clear enough that truth and ethics are not welcome on other lists. Or maybe the support list should be named fedora-immoralist ;-P :-D -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jkeating at redhat.com Tue Jul 29 21:30:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jul 2008 17:30:10 -0400 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> Message-ID: <1217367010.3151.87.camel@localhost.localdomain> On Wed, 2008-07-30 at 09:06 +1200, Martin Langhoff wrote: > Ok. I don't particularly like the idea, but I can live with that if it > can run inside mock. Yes, it can be ran in mock. > > > F7's pungi was really a first attempt and I don't think it was that > > good. Rawhide's pungi is far better, but in some of the problems I > > discovered along the way we've fixed in other pieces of software like > > yum and anaconda. > > Does F7's pungi build a good F7 distro installer? Well, it built F7, so you tell me (: > What did RH/Fedora > use to build F1~F6? Some ungodly complicated tool sets that sat above anaconda-runtime's buildinstall and pkgorder and splittree > The RH/Fedora team has been building installer CDs > for a long time... I am sure you guys have some well-worn tools for > that :-) maybe I should be using something old and time-tested? I > don't mind it being written in ksh... A) it's not really opensource, B) it's directly tied to the buildsystem, and C) it won't really work without kerberos setup, D) did I mention it's ungodly complicated? > > In any case, I am most interested in understanding whether it is > designed to do what I am trying to do. If I fix/workaround its > limitations, is it the right tool to build installer CDs that... ? Yes. You could use buildinstall directly to prepare the directory tree for installability, and then call mkisofs yourself, but pungi helps you with the preparation steps. > > - fit on CD-sized media (but then, I only have a small set of packages) Yes > - have a text installer that ideally works well on low-end hw, and supports > serial console for headless machines You get that for free with anaconda > - have good support for off-the-beaten path arches How off the beaten path? I've used it for x86 and ppc, I've seen it used for ia64, sparc, and I think I've got patches somewhere for s390. Basically anything anaconda can support, pungi can easily be made to support. The only tricky parts is finding said arch to run on, and getting the mkisofs calls right to make the isos bootable. > - can be used for installs and upgrades You get that for free with anaconda > - the kickstart environment - during install! - is close to the env you > get when customising a RH build Again, anaconda > - are resilient and produces consistent builds Provided you don't change out the repos you point pungi at, you'll get the same thing over and over again. > > Are there other good alternatives I should be considering? There is reviser, not sure if it landed in F7 timeframe. It puts a gui on top of things, has some of it's own code for the things that pungi does, although it does use bits and parts of pungi. > > So far I have been working with livecd-tools, which is designed to do > something else. I want to switch to the right tool. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 wolfy at nobugconsulting.ro Tue Jul 29 21:41:42 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 30 Jul 2008 00:41:42 +0300 Subject: Pungi as CD installer build tool In-Reply-To: <1217367010.3151.87.camel@localhost.localdomain> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> Message-ID: <488F8E96.1080404@nobugconsulting.ro> On 07/30/2008 12:30 AM, Jesse Keating wrote: > >> Are there other good alternatives I should be considering? >> > > There is reviser, not sure if it landed in F7 timeframe. It puts a gui > on top of things, has some of it's own code for the things that pungi > does, although it does use bits and parts of pungi. > s/reviser/revisor/ :) http://revisor.fedoraunity.org/ http://revisor.fedoraunity.org/news-releases/article-create-a-fedora-7-cd-in-3-easy-steps From martin.langhoff at gmail.com Tue Jul 29 21:47:11 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 30 Jul 2008 09:47:11 +1200 Subject: Pungi as CD installer build tool In-Reply-To: <1217367010.3151.87.camel@localhost.localdomain> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> Message-ID: <46a038f90807291447o7dce20c3j8cf657ddcfe5fee0@mail.gmail.com> 2008/7/30 Jesse Keating : > Yes, it can be ran in mock. Fantastic. >> Does F7's pungi build a good F7 distro installer? > Well, it built F7, so you tell me (: Thanks for the confirmation - for a moment I wasn't sure ;-) > D) did I mention > it's ungodly complicated? Ok, I get it - >> In any case, I am most interested in understanding whether it is >> designed to do what I am trying to do. If I fix/workaround its >> limitations, is it the right tool to build installer CDs that... ? > > Yes. You could use buildinstall directly to prepare the directory tree > for installability, and then call mkisofs yourself, but pungi helps you > with the preparation steps. Great. That is the key answer. >> - have good support for off-the-beaten path arches > > How off the beaten path? I've used it for x86 and ppc, ARM? Assuming the rest if F9 supports it, of course... I guess my remaining questions are "if I use it on F7, what should I worry about?", plus some specific errors I am seeing, but I'm happy to take that to the buildtools list. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From silfreed at silfreed.net Tue Jul 29 22:04:17 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 29 Jul 2008 15:04:17 -0700 Subject: XULRunner and you In-Reply-To: References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> <5256d0b0807291145o41f29cd2mcb0444b356cab2fa@mail.gmail.com> Message-ID: <200807291504.17969.silfreed@silfreed.net> On Tuesday 29 July 2008 11:48:53 drago01 wrote: > > It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF > > 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though. > > < 1.9.1 ? Like I suggested; perhaps: Provides: gecko-libs-api = 1.9 So packages could require this specific version without allowing allowing future versions that would possibly break. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From moe at blagblagblag.org Tue Jul 29 22:06:37 2008 From: moe at blagblagblag.org (jeff) Date: Tue, 29 Jul 2008 19:06:37 -0300 Subject: Pungi as CD installer build tool In-Reply-To: <1217367010.3151.87.camel@localhost.localdomain> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> Message-ID: <488F946D.9010700@blagblagblag.org> Jesse Keating wrote: > On Wed, 2008-07-30 at 09:06 +1200, Martin Langhoff wrote: >> Ok. I don't particularly like the idea, but I can live with that if it >> can run inside mock. > > Yes, it can be ran in mock. Along these lines: mock -r fedora-7 --chroot "/usr/bin/pungi --force --discs=1 --nosplitmedia --bugurl=http://foo.org --name=bar --ver=1.0 --flavor=chocolate --nosource -c ks-boo.cfg" -Jeff From denis at poolshark.org Tue Jul 29 22:10:23 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 30 Jul 2008 00:10:23 +0200 Subject: XULRunner and you In-Reply-To: <200807291504.17969.silfreed@silfreed.net> References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> <5256d0b0807291145o41f29cd2mcb0444b356cab2fa@mail.gmail.com> <200807291504.17969.silfreed@silfreed.net> Message-ID: <488F954F.2000407@poolshark.org> Douglas E. Warner wrote: > On Tuesday 29 July 2008 11:48:53 drago01 wrote: >>> It won't be 2. Firefox 3.1.x will ship with gecko 1.9.1.x where as FF >>> 3.0 uses gecko 1.9.0.x. No idea how you'd specify that in rpm though. >> < 1.9.1 ? > > Like I suggested; perhaps: > > Provides: gecko-libs-api = 1.9 Could xulrunner please use libtool-style soname versions like all other libraries in Fedora ? So we don't need to add the version numbers in the spec file in the first place... Frankly, this would never pass a standard fedora package review. From tmz at pobox.com Tue Jul 29 22:21:59 2008 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 29 Jul 2008 18:21:59 -0400 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <20080729222159.GW5655@inocybe.teonanacatl.org> Alexandre Oliva wrote: > Or maybe the support list should be named fedora-immoralist ;-P :-D Or perhaps you could see that posting 200+ messages to a single thread (debating the nuances of the GPL and whether GNU/Linux is the proper name for the OS) on fedora-list over the past several weeks is just a little bit excessive? If you'd been a long-time contributor on fedora-list it would be one thing (though still annoying). But as far as I can tell you haven't posted anything on fedora-list other than a religious-style holy crusade to convince everyone of the righteousness of your cause. Perhaps if you continue to say it over and over and over no one will be left listening to argue with you? Hooray for your awesome powers of persuasion. I feel sorry for the poor folks just learning linux that come to fedora-list for some help installing or using Fedora and have their mailboxes overrun with your philosophical debate. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ How am I supposed to hallucinate with all these swirling colors distracting me? -- Lisa Simpson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From martin.langhoff at gmail.com Tue Jul 29 22:32:51 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 30 Jul 2008 10:32:51 +1200 Subject: Pungi as CD installer build tool In-Reply-To: <488F8E96.1080404@nobugconsulting.ro> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> <488F8E96.1080404@nobugconsulting.ro> Message-ID: <46a038f90807291532l2c062491h776c6a16a4d4d03a@mail.gmail.com> On Wed, Jul 30, 2008 at 9:41 AM, Manuel Wolfshant wrote: > On 07/30/2008 12:30 AM, Jesse Keating wrote: >> There is reviser, not sure if it landed in F7 timeframe. It puts a gui >> on top of things, has some of it's own code for the things that pungi >> does, although it does use bits and parts of pungi. >> > > s/reviser/revisor/ :) I've looked at revisor on F9 but it seems to be geared to build a livecd. Or can it build regular installer ISOs? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From wolfy at nobugconsulting.ro Tue Jul 29 22:41:47 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 30 Jul 2008 01:41:47 +0300 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807291532l2c062491h776c6a16a4d4d03a@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> <488F8E96.1080404@nobugconsulting.ro> <46a038f90807291532l2c062491h776c6a16a4d4d03a@mail.gmail.com> Message-ID: <488F9CAB.4030607@nobugconsulting.ro> On 07/30/2008 01:32 AM, Martin Langhoff wrote: > On Wed, Jul 30, 2008 at 9:41 AM, Manuel Wolfshant > wrote: > >> On 07/30/2008 12:30 AM, Jesse Keating wrote: >> >>> There is reviser, not sure if it landed in F7 timeframe. It puts a gui >>> on top of things, has some of it's own code for the things that pungi >>> does, although it does use bits and parts of pungi. >>> >>> >> s/reviser/revisor/ :) >> > > I've looked at revisor on F9 but it seems to be geared to build a > livecd. Or can it build regular installer ISOs? > > The first sentence on their website says " Revisor enables you to customize and compose your own Fedora based installation and live media." The last "and" from this phrase, together with the explanations found later in the page, make me pretty sure that it can create regular installer ISOs as well. From fedora at slated.org Tue Jul 29 22:49:27 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Tue, 29 Jul 2008 23:49:27 +0100 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> Message-ID: Verily I say unto thee, that Martin Langhoff spake thusly: > So far I have been working with livecd-tools, which is designed to do > something else. I want to switch to the right tool. This looks interesting: http://www.t2-project.org -- Regards, Keith G. Robertson-Turner From sundaram at fedoraproject.org Wed Jul 30 00:07:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Jul 2008 05:37:22 +0530 Subject: Plan for tomorrows (20080730) FESCO meeting In-Reply-To: <488F52A5.5050609@leemhuis.info> References: <1217346995.10585.4.camel@truman> <488F52A5.5050609@leemhuis.info> Message-ID: <488FB0BA.5080603@fedoraproject.org> Thorsten Leemhuis wrote: > On 29.07.2008 17:56, Brian Pepple wrote: >> >> /topic FESCo-Meeting -- >> http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance -- all > > Hmmm. Looks to me like the "The Solution" section needs to be integrated > into > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers > > should it be accepted by FESCo. Sure, a separate document could work, > but that way seems confusing to me and will not help making live easier > for contributors. I have said so many times and it is in the page already that this is a modification of the non responsive maintainers page. Diff against the wiki IMO doesn't really work well but if you want to try, go ahead. Rahul From jwboyer at gmail.com Wed Jul 30 00:39:33 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 29 Jul 2008 20:39:33 -0400 Subject: Presto In-Reply-To: <488F7164.6040200@redhat.com> References: <488F5BBB.3070500@univ-nantes.fr> <488F7164.6040200@redhat.com> Message-ID: <1217378373.13523.0.camel@weaponx> On Tue, 2008-07-29 at 15:37 -0400, Casey Dahlin wrote: > Tanguy Eric wrote: > > Will presto be a feature for fedora 10 ? > > Thanks > > Eric > > > > We're hoping so :) > > I just committed some changes to presto that should make it easier to > work with from a developer perspective, which in turn should speed its > introduction into Bodhi. Luke Macken is working on the Bodhi > integration. Once that's done, there shouldn't be any obstacles to > deploying it for F10. Bodhi works for updates. What are you going to do for rawhide? We _really_ want it working on rawhide first to get good testing. josh From peter at thecodergeek.com Wed Jul 30 01:13:55 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 29 Jul 2008 18:13:55 -0700 Subject: Presto In-Reply-To: <1217378373.13523.0.camel@weaponx> References: <488F5BBB.3070500@univ-nantes.fr> <488F7164.6040200@redhat.com> <1217378373.13523.0.camel@weaponx> Message-ID: <1217380435.3319.2.camel@tuxhugs> On Tue, 2008-07-29 at 20:39 -0400, Josh Boyer wrote: > Bodhi works for updates. What are you going to do for rawhide? We > _really_ want it working on rawhide first to get good testing. > As another plus, Rawhide tends to have far more churn than a stable release (daily updates of a few hundred MB often are not unexpected from my experiences). Having a delta-based update system would decrease these amounts considerably (especially for mass-rebuilds and similar), which could in turn give more people (such as dial-up users, etc.) the opportunity to help test/break it. :) -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 Wed Jul 30 01:18:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Jul 2008 06:48:23 +0530 Subject: Presto In-Reply-To: <1217378373.13523.0.camel@weaponx> References: <488F5BBB.3070500@univ-nantes.fr> <488F7164.6040200@redhat.com> <1217378373.13523.0.camel@weaponx> Message-ID: <488FC15F.1000406@fedoraproject.org> Josh Boyer wrote: > On Tue, 2008-07-29 at 15:37 -0400, Casey Dahlin wrote: >> Tanguy Eric wrote: >>> Will presto be a feature for fedora 10 ? >>> Thanks >>> Eric >>> >> We're hoping so :) >> >> I just committed some changes to presto that should make it easier to >> work with from a developer perspective, which in turn should speed its >> introduction into Bodhi. Luke Macken is working on the Bodhi >> integration. Once that's done, there shouldn't be any obstacles to >> deploying it for F10. > > Bodhi works for updates. What are you going to do for rawhide? We > _really_ want it working on rawhide first to get good testing. https://fedorahosted.org/bodhi/ticket/160 for discussions. Whoever is working on this should probably get in touch with Spacewalk developers (or viceversa). https://fedorahosted.org/spacewalk/wiki/DeltaRpmSupport Rahul From jkeating at redhat.com Wed Jul 30 01:49:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jul 2008 21:49:38 -0400 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807291447o7dce20c3j8cf657ddcfe5fee0@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> <46a038f90807291447o7dce20c3j8cf657ddcfe5fee0@mail.gmail.com> Message-ID: <1217382578.3151.93.camel@localhost.localdomain> On Wed, 2008-07-30 at 09:47 +1200, Martin Langhoff wrote: > ARM? Assuming the rest if F9 supports it, of course... I honestly don't know what magic mkisofs needs to make things bootable on arm, and I don't think anaconda itself has a mk-images.arm so you may be in some trouble here. Pungi is easy, anaconda is going to be some more effort. Thankfully most the hard work is done with other mk-images files, you just have to port one to arm. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 jkeating at redhat.com Wed Jul 30 01:51:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jul 2008 21:51:38 -0400 Subject: Presto In-Reply-To: <1217378373.13523.0.camel@weaponx> References: <488F5BBB.3070500@univ-nantes.fr> <488F7164.6040200@redhat.com> <1217378373.13523.0.camel@weaponx> Message-ID: <1217382698.3151.95.camel@localhost.localdomain> On Tue, 2008-07-29 at 20:39 -0400, Josh Boyer wrote: > > Bodhi works for updates. What are you going to do for rawhide? We > _really_ want it working on rawhide first to get good testing. We asked him to look at the bodhi case as well, as having it in rawhide doesn't help much come release time. The work he's doing to make it work with bodhi will only help along the work for rawhide. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 debarshi.ray at gmail.com Wed Jul 30 04:32:01 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 30 Jul 2008 10:02:01 +0530 Subject: RFC: FEver and RPath checks in Koji In-Reply-To: <20071221122741.3ab8265a@redhat.com> References: <3170f42f0712210916t2dc2c21es2df4d9da8b5774d1@mail.gmail.com> <20071221122256.463f61c4@redhat.com> <20071221122741.3ab8265a@redhat.com> Message-ID: <3170f42f0807292132i3f2d415ar41d7426d0ec9d130@mail.gmail.com> >> I'm pretty sure rpath checking is done in koji, due to the macros we >> install in redhat-config-rpm. > Looks like I'm mistaken. There was discussion on this, but apparently > it didn't happen. Any updates on this? Cheers, Debarshi From talk90091e at gmail.com Wed Jul 30 05:48:11 2008 From: talk90091e at gmail.com (talk90091e) Date: Wed, 30 Jul 2008 13:48:11 +0800 Subject: scsi_id has "no match" messages on RedHat Message-ID: <4890009B.2080407@gmail.com> Hi All, When run command scsi_id on my RedHat4.6 Linux box, I got some messages with "no match". In /etc/scsi_id.config, there is a line *options=-b* There is a valid line in configure file, I can not understand why there is a "no match" message when treat this line? *Is this a bug*? more detail outputs and the whole scsi_id.config have been listed as below. ------------- [root at wjiang-RHEL4-32-1 ~]# scsi_id -v -s /block/sda set_options: option 's' arg '/block/sda' scsi_id: target_path /sys/block/sda scsi_id: class_dev 0x0x9a044a8; class_dev_parent 0x(nil) create_tmp_dev: (/sys/block/sda) sysfs_get_attr: /sys/block/sda/dev get_major_minor: dev value 8:0 create_tmp_dev: tmpdev '/dev/tmp-scsi-maj8-min0-20880' sysfs_get_attr: /sys/devices/platform/host0/target0:0:0/0:0:0:0/vendor sysfs_get_attr: /sys/devices/platform/host0/target0:0:0/0:0:0:0/model get_file_options: vendor='DGC '; model='RAID 5 ' get_file_options: config file line 28: vendor '(null)'; model '(null)'; options '-b' *get_file_options: no match* get_file_options: config file line 33: vendor 'someone'; model 'nicedrive'; options '-g' *get_file_options: no match* scsi_id: per dev options: good 0; page code 0x0; callout '' scsi_id: buffer unaligned 0x0x9a047f8; aligned 0x0x9a04800 [root at wjiang-RHEL4-32-1 ~]# cat /etc/scsi_id.config ... # If you normally don't need scsi id's, or might be attaching devices of # an unknown functionality, black list everyone. This is the default # behaviour (if no -b or -g is specified). # *options=-b* # # Then white list devices on your system that have correct and useful id's: # *vendor=someone, model=nicedrive, options=-g* ... Thanks, --Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: From dex.mbox at googlemail.com Wed Jul 30 07:19:11 2008 From: dex.mbox at googlemail.com (dexter) Date: Wed, 30 Jul 2008 08:19:11 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <488DC536.30302@redhat.com> Message-ID: <200807300819.12747.dex.mbox@gmail.com> Ok since I've talked about you Its right I should talk to you. (but just this once, I am a man of very few emails :-) ) On Tue July 29 2008 22:09:02 Alexandre Oliva wrote: > I wonder why nobody's complaining about all this traffic on this > non-technical thread on a list that people complained was supposed to > be restricted to technical content. ?Heck, why was the discussion even > started here? ?Double standards, as usual? Keep replying in this thread and see what happens. No double standards at all, the 'technical content' card is shown when discussion breaks down or has little or no relevance/benefit to day to day fedora or the un-stoppable force meets the un-movable object :-) > > Do we really want to say that if any ethical question arises during > > discussion on Fedora lists, people may not address it? > > Seems like that's the general feeling of those who demand silence > about it. ?Perhaps a separate list named "fedora-truth" or > "fedora-ethics", for this kind of discussion, would make it clear > enough that truth and ethics are not welcome on other lists. > > Or maybe the support list should be named fedora-immoralist ;-P :-D I plan not to respond further in this thread and refer you back to the excellent post by Mr T Zullinger. ...dex From rawhide at fedoraproject.org Wed Jul 30 09:12:48 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 30 Jul 2008 09:12:48 +0000 (UTC) Subject: rawhide report: 20080730 changes Message-ID: <20080730091249.057EC209DFE@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080729/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080730/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package libtrash Libraries to move files to a trash-folder on delete New package perl-Tk-TableMatrix Perl module for creating and manipulating tables New package presto A tilemap engine using the Allegro game programming library Updated Packages: Canna-3.7p3-24.fc9 ------------------ * Tue Apr 8 18:00:00 2008 Akira TAGOH - 3.7p3-24 - Don't start the service by default. (#441276) OpenIPMI-2.0.14-1.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Phil Knirsch - 2.0.14-1 - Fixed several specfile problems (#453751) - Update to OpenIPMI-2.0.14 alsa-oss-1.0.17-1.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Jaroslav Kysela 1.0.17-1 - New upstream version asterisk-1.6.0-0.20.beta9.fc10 ------------------------------ * Tue Jul 29 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.20.beta9 - Bump release and rebuild with new libpri and zaptel. ctags-5.7-3.fc10 ---------------- * Tue Jul 29 18:00:00 2008 Than Ngo 5.7-3 - add subpackage ctags-etags dhcpv6-1.0.21-1.fc10 -------------------- * Tue Jul 29 18:00:00 2008 David Cantrell - 1.0.21-1 - Upgrade to dhcpv6-1.0.21, changes include: Remove old dadlist variable reference in dhcp6c * Tue Jul 29 18:00:00 2008 David Cantrell - 1.0.20-1 - Upgrade to dhcpv6-1.0.20, changes include: Allow all legal device names in dhcp6c Delay sending Confirm until DAD completes for link-local addr Copy preferred address correctly when receiving Advertise Point to addrlist member when creating DNS server option Add the status option length to the IA option length Other bug fixes dovecot-1.1.2-2.fc10 -------------------- * Tue Jul 29 18:00:00 2008 Dan Horak - 1:1.1.2-2 - really ask for the password during start-up * Tue Jul 29 18:00:00 2008 Dan Horak - 1:1.1.2-1 - update to upstream version 1.1.2 - final solution for #445200 (add /etc/sysconfig/dovecot for start-up options) eclipse-changelog-2.6.2-1.fc9 ----------------------------- * Thu Jun 26 18:00:00 2008 Jeff Johnston 1:2.6.2-1 - Rebase to 2.6.2 - Resolves Bugzilla #452574 freeipmi-0.6.4-1.fc10 --------------------- * Mon Jul 28 18:00:00 2008 Phil Knirsch - 0.6.4-1 - Update to freeipmi-0.6.4 - Fixed unecessary logrotate message for bmc-watchdog (#456648) ganglia-3.1.0-0.5.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Kostas Georgiou 3.1.0-0.5 - Add the config files for the python module glibc-2.8.90-10 --------------- * Tue Jul 29 18:00:00 2008 Jakub Jelinek 2.8.90-10 - update from trunk - resolver fixes - misc fixes (BZ#6771, BZ#6763, BZ#6698, BZ#6712) - s390{,x} utmp/utmpx bi-arch support (BZ#6724) - popen "e" flag - fr_FR locale changes reenabled gnome-commander-1.2.7-2.fc10 ---------------------------- * Wed Jul 30 18:00:00 2008 Mamoru Tasaka - 1.2.7-2 - F-10+: Fix icon name due to gnome-icon-theme 2.23.x change * Wed Jul 30 18:00:00 2008 Mamoru Tasaka - 1.2.7-1 - 1.2.7 gnome-session-2.23.6-0.2008.07.29.1.fc10 ---------------------------------------- * Tue Jul 29 18:00:00 2008 Jon McCann - 2.23.6.0.2008.07.29.1 - New snapshot from DBus branch * Mon Jul 28 18:00:00 2008 Jon McCann - 2.23.5.0.2008.07.28.1 - New snapshot from DBus branch gnu-efi-3.0d-6.fc10 ------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 3.0d-6 - fix license tag * Mon Jul 28 18:00:00 2008 Peter Jones - 3.0d-5 - Remove ia64 palproc code since its license isn't usable. - Remove ia64 from ExclusiveArch since it can't build... * Thu Mar 27 18:00:00 2008 Peter Jones - 3.0d-4 - Fix uefi_call_wrapper(x, 10, ...) . - Add efi_main wrappers and EFI_CALL() macro so drivers are possible. gtkhtml2-2.11.1-4.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 2.11.1-4 - Fix license tag gtkhtml3-3.23.5-2.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 3.23.5-2.fc10 - Fix license tag * Mon Jul 21 18:00:00 2008 Matthew Barnes - 3.23.5-1.fc10 - Update to 3.23.5 - Remove patch for GNOME bug #538703 (fixed upstream). - Remove patch for GNOME bug #539289 (fixed upstream). gtkmathview-0.8.0-1.fc10 ------------------------ * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 0.8.0-1 - update to 0.8.0 - fix rpath - fix gcc43 patch for 0.8.0 gtksourceview-1.8.5-5.fc10 -------------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 1:1.8.5-5 - fix license tag gtksourceview-sharp-2.0.12-5.fc10 --------------------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 2.0-0.12-5 - fix license tag gtranslator-1.1.7-9.fc10 ------------------------ * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 1.1.7-9 - fix license tag gucharmap-2.23.4-2.fc10 ----------------------- * Tue Jul 29 18:00:00 2008 Tom "spot" Callaway - 2.23.4-2 - fix license tag htdig-3.2.0-0.3.b6.fc10 ----------------------- * Tue Jul 29 18:00:00 2008 Adam Tkac 4:3.2.0-0.3.b6 - removed unneded patches - htdig-3.2.0b3-glibc222.patch and htdig-3.2.0b4-h_hash.patch * Mon Jul 28 18:00:00 2008 Adam Tkac 4:3.2.0-0.2.b6 - mark configuration files as noreplace hunspell-1.2.6-1.fc10 --------------------- * Tue Jul 29 18:00:00 2008 Caolan McNamara - 1.2.6-1 - latest version im-chooser-1.2.1-1.fc10 ----------------------- * Tue Jul 29 18:00:00 2008 Akira TAGOH - 1.2.1-1 - New upstream release. - Display IM icon in the list. (#454371) imsettings-0.102.0-1.fc10 ------------------------- * Tue Jul 29 18:00:00 2008 Akira TAGOH - 0.102.0-1 - New upstream release. - Fix no recommendation updated. (#455363) - Work on WMs not own/bring up XSETTINGS manager. (#455228) inadyn-1.96.2-4.fc9 ------------------- * Thu Apr 10 18:00:00 2008 Jochen Schmitt 1.96.2-4 - Fix some LSB-compilant issues initscripts-8.80-1 ------------------ * Tue Jul 29 18:00:00 2008 Bill Nottingham - 8.80-1 - Fix translation typo (#455804, ) - Turn off syncookies - Cleanups for proper plymouth support - Move the mcheck code to a debugmode package, make it more generic * Mon Jul 14 18:00:00 2008 Bill Nottingham - 8.79-1 - fix mcheck stuff to be installed correctly - don't do an arping check for loopback interfaces - console_init: don't wait () - rc: clean up extraneous set -x noise - remove references to static dmraid/multipath binaries (#453987) - translation updates: lv ipsec-tools-0.7.1-1.fc10 ------------------------ * Tue Jul 29 18:00:00 2008 Tomas Mraz - 0.7.1-1 - Update to a new upstream version jd-2.0.1-0.1.svn2242_trunk.fc10 ------------------------------- * Wed Jul 30 18:00:00 2008 Mamoru Tasaka - rev. 2242 jruby-1.1.3-2.fc10 ------------------ * Tue Jul 29 18:00:00 2008 Conrad Meyer - 1.1.3-2 - Update jruby-fix-jruby-start-script.patch to work with faster class-loading mechanism introduced in JRuby 1.1.2. kazehakase-0.5.5-1.fc10 ----------------------- * Wed Jul 30 18:00:00 2008 Mamoru Tasaka - 0.5.5-1 - 0.5.5 kde-l10n-4.1.0-2.fc10 --------------------- * Tue Jul 29 18:00:00 2008 Kevin Kofler 4.1.0-2 - get rid of kdepim documentation from kdenetwork * Sun Jul 27 18:00:00 2008 Rex Dieter 4.1.0-1.2 - file conflict between kde-l10n and libkdcraw (#456797) * Sat Jul 26 18:00:00 2008 Kevin Kofler 4.1.0-1.1 - on F9, remove translations for kdepim apps we don't ship (#456745) kdegraphics-4.1.0-3.fc10 ------------------------ * Tue Jul 29 18:00:00 2008 Than Ngo 4.1.0-3 - respun libcanberra-0.5-3.fc10 ---------------------- * Wed Jul 30 18:00:00 2008 Lennart Poettering 0.5-3 - Ship libcanberra-gtk-module.sh directly in CVS * Wed Jul 30 18:00:00 2008 Lennart Poettering 0.5-2 - Fix build * Wed Jul 30 18:00:00 2008 Lennart Poettering 0.5-1 - New version libgsasl-0.2.27-1.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Nikolay Vladimirov - 0.2.27-1 - new upstream release 0.2.27 libibverbs-1.1.2-1.fc9 ---------------------- * Wed Apr 16 18:00:00 2008 Roland Dreier - 1.1.2-1 - New upstream release - Update description to mention RDMA and iWARP, not just InfiniBand - Add "Requires" tag for libibverbs base package to -devel libpri-1.4.6-1.fc10 ------------------- * Tue Jul 29 18:00:00 2008 Jeffrey C. Ollie - 1.4.6-1 - Update to 1.4.6 libselinux-2.0.69-2.fc10 ------------------------ * Tue Jul 29 18:00:00 2008 Dan Walsh - 2.0.69-1 - Update to Upstream * Handle duplicate file context regexes as a fatal error from Stephen Smalley. This prevents adding them via semanage. * Fix audit2why shadowed variables from Stephen Smalley. * Note that freecon NULL is legal in man page from Karel Zak. libsemanage-2.0.26-1.fc10 ------------------------- * Tue Jul 29 18:00:00 2008 Dan Walsh - 2.0.26-1 - Update to upstream * Fix bug in genhomedircon fcontext matches logic from Dan Walsh. Strip any trailing slash before appending /*$. libspe2-2.2.80.129-2.fc10 ------------------------- * Tue Jul 29 18:00:00 2008 Jochen Roth 2.2.80.129-2 - Prepared for spu cross toolchain includes * Tue Jul 29 18:00:00 2008 Jochen Roth 2.2.80.129-1 - update to latest open source version to solve some bugs libv4l-0.3.8-1.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Hans de Goede 0.3.8-1 - New upstream release 0.3.8 mach-0.9.3-1.fc9 ---------------- * Thu May 22 18:00:00 2008 Thomas Vander Stichele - 0.9.3-1 - new release mailx-12.3-1.fc10 ----------------- * Tue Jul 29 18:00:00 2008 Dmitry Butskoy - 12.3-1 - Place mailx to /bin/mailx, to avoid extra symlink in redhat-lsb package - /bin/mailx is now a base binary, another symlinked to it. * Thu Jun 26 18:00:00 2008 Dmitry Butskoy - add missed BR for krb5-devel - activate IPv6 support - change config to /etc/mail.rc for compatibility - add triggerpostun scriptlets against previous mailx and nail to check and merge (when possible) their user config changes - use proper config filename in manuals - use "less" instead of non-provided "pg" for nobsdcompat mode msmtp-1.4.16-1.fc10 ------------------- * Tue Jul 29 18:00:00 2008 Nikolay Vladimirov - 1.4.16-1 - new upstream release - 1.4.16 mysql-gui-tools-5.0r12-8.fc9 ---------------------------- * Tue Jul 8 18:00:00 2008 Dennis Gilmore - 5.0r12-8 - apply patch for gcc-4.3 from gentoo - use openjdk for building * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 5.0r12-7 - fix conditional comparison * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 5.0r12-6 - Autorebuild for GCC 4.3 mysqltuner-0.9.8-1 ------------------ * Mon Jul 21 18:00:00 2008 Ville Skytt?? - 0.9.8-1 - 0.9.8, --checkversion patch applied upstream. netbsd-iscsi-20071205-3.fc10 ---------------------------- * Mon Jul 28 18:00:00 2008 Lubomir Rintel 20071205-3 - Init script (thanks to Saturo Sato) newsx-1.6-10.fc10 ----------------- * Tue Jul 29 18:00:00 2008 Dominik Mierzejewski 1.6-10 - recognize single quotes (fixes bug #455806, patch by Enrico Scholz) openoffice.org-3.0.0-0.0.28.1.fc10 ---------------------------------- * Mon Jul 28 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.28-1 - next version - drop (finally!) integrated ooo#64726 bengali translation fix (April 2006) - drop integrated workspace.cmcfixes46.patch - Move hsqldb stuff into database rpm pcmanfm-0.5-4.fc10 ------------------ * Wed Jul 30 18:00:00 2008 Mamoru Tasaka - 0.5-4 - More fallback for gnome-icon-theme 2.23.X (F-10) * Tue Jul 29 18:00:00 2008 Mamoru Tasaka - 0.5-2 - F-10+: Use more generic icon name due to gnome-icon-theme 2.23.X change First try (need more fix) pem-0.7.3-1.fc10 ---------------- * Tue Jul 29 18:00:00 2008 P J P - 0.7.3-1 - Changed the ..share/info/dir menu entry of pem, in pem.texi. pigment-0.3.7-1.fc10 -------------------- * Tue Jul 29 18:00:00 2008 Matthias Saou 0.3.7-1 - Update to 0.3.7. policycoreutils-2.0.53-1.fc10 ----------------------------- * Tue Jul 29 18:00:00 2008 Dan Walsh 2.0.53-1 - Update to upstream * Change setfiles to validate all file_contexts files when using -c from Stephen Smalley. * Tue Jul 29 18:00:00 2008 Dan Walsh 2.0.52-6 - Fix boolean handling - Upgrade to latest sepolgen - Update po patch python-libgmail-0.1.10-1.fc10 ----------------------------- * Tue Jul 29 18:00:00 2008 Nikolay Vladimirov - 0.1.10-1 - new upstream 0.1.10 - drop ClientCookie patch(upstream) python-migrate-0.4.5-3.fc10 --------------------------- * Tue Jul 29 18:00:00 2008 Toshio Kuratomi 0.4.5-3 - Patch to generate a script for the repository migrate script. - Move the script rename into a patch to setup.py. shorewall-4.0.13-1.fc10 ----------------------- * Tue Jul 29 18:00:00 2008 Jonathan G. Underwood - 4.0.13-1 - Update to version 4.0.13 - Remove patch-perl-4.0.12.1 - Update BuildRoot to mktemp variant smc-fonts-04.1-1.fc10 --------------------- * Tue Jul 29 18:00:00 2008 Pravin Satpute 04.1-1 - new upstream release - fontconfig rule for size adjustment of Meera is added - two new fonts kalyani and anjalioldlipi - bugfix 448078 telepathy-glib-0.7.13-1.fc10 ---------------------------- * Tue Jul 29 18:00:00 2008 Brian Pepple - 0.7.13-1 - Update to 0.7.13. telepathy-haze-0.2.0-2.fc10 --------------------------- * Tue Jul 29 18:00:00 2008 Peter Gordon - 0.2.0-2 - Fix the ICQ Mission Control profile to properly use the "icq" configuration UI, rather than the one for jabber. - Resolves: bug #456565 (Wrong entry in haze-icq.profile) tk-8.5.3-2.fc10 --------------- * Tue Jul 29 18:00:00 2008 Marcela Maslanova - 1:8.5.3-2 - fix 456922 - crash gitk resolved wine-1.1.2-1.fc10 ----------------- * Sun Jul 27 18:00:00 2008 Andreas Bierfert - 1.1.2-1 - version upgrade (#455960, #456831) - require freetype (#452417) - disable wineprefixcreate patch for now * Fri Jul 11 18:00:00 2008 Andreas Bierfert - 1.1.1-1 - version upgrade xorg-x11-drv-ati-6.8.0-19.fc10 ------------------------------ * Wed Jul 30 18:00:00 2008 Dave Airlie 6.8.0-19 - Update to latest upstream release + fixes * Thu Jun 26 18:00:00 2008 Dave Airlie 6.8.0-18 - update to latest git 6.8.192 beta * Wed May 28 18:00:00 2008 Dave Airlie 6.8.0-17 - fix multiple VT switch issues on r600 cards - assorted upstream goodness * Sat May 24 18:00:00 2008 Dave Airlie 6.8.0-16 - Fix PLL on r600 LVDS (#444542) - update to other upstream fixes zhcon-0.2.6-11.fc10 ------------------- * Tue Jul 29 18:00:00 2008 Caol??n McNamara - 0.2.6-11 - add zhcon-0.2.6-processor-flags.patch to build on rawhide * Tue Jul 15 18:00:00 2008 Ding-Yi Chen - 0.2.6-9 - [Bug 454228] [zhcon] Cannot start input method for x86_64 user - [Bug 449625] FTBFS zhcon-0.2.6-8.fc9 - [Bug 441203] [zhcon] The input methods other than the default one were not changable for use * Tue Jul 15 18:00:00 2008 Ding-Yi Chen - 0.2.6-10 - Address the dependence in RHEL5 and Fedora <= 8 which do not have ncurses-libs. - Add gpm as Required Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 63 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 requires libpri.so.1.0 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) openhpi-2.12.0-1.fc10.i386 requires libOpenIPMIposix.so.0 perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sobby-0.4.4-4.fc10.i386 requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.x86_64 requires libpri.so.1.0()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) openhpi-2.12.0-1.fc10.x86_64 requires libOpenIPMIposix.so.0()(64bit) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sobby-0.4.4-4.fc10.x86_64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc requires libpri.so.1.0 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) openhpi-2.12.0-1.fc10.ppc requires libOpenIPMIposix.so.0 perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sobby-0.4.4-4.fc10.ppc requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc64 requires libpri.so.1.0()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot openhpi-2.12.0-1.fc10.ppc64 requires libOpenIPMIposix.so.0()(64bit) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sobby-0.4.4-4.fc10.ppc64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From aph at redhat.com Wed Jul 30 09:16:51 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Jul 2008 10:16:51 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <48903183.2070406@redhat.com> Alexandre Oliva wrote: > On Jul 28, 2008, Andrew Haley wrote: > >> It surely was on-topic here to talk about whether unfree binary blobs >> should be included in Fedora. > > +1 > > I wonder why nobody's complaining about all this traffic on this > non-technical thread on a list that people complained was supposed to > be restricted to technical content. Heck, why was the discussion even > started here? Double standards, as usual? Someone probably will... >> Do we really want to say that if any ethical question arises during >> discussion on Fedora lists, people may not address it? > > Seems like that's the general feeling of those who demand silence > about it. Some people really don't want to see any discussion of the political/ ethical issues around free software, I suppose, and what it banished to a list they don't have to read. More likely, however, is that people are using Thunderbird. Thunderbird doesn't by default have a "Delete Thread" button, so people are forced to select all the messages of a huge thread and delete them. Now you might argue that any mailer without a "Delete Thread" button simply isn't fit for purpose, and I would find it hard to argue with you, but that's the fact. Andrew. From emmanuel.seyman at club-internet.fr Wed Jul 30 09:51:09 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 30 Jul 2008 11:51:09 +0200 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> Message-ID: <20080730095109.GA19062@orient.maison.lan> * Alexandre Oliva [30/07/2008 00:24] : > > I wonder why nobody's complaining about all this traffic on this > non-technical thread on a list that people complained was supposed to > be restricted to technical content. Heck, why was the discussion even > started here? Double standards, as usual? Common sense. The list moderators read this list but not fedora-list. > > Do we really want to say that if any ethical question arises during > > discussion on Fedora lists, people may not address it? To be honest, I lost intrest in the debate that went on in this list not because it was asking ethical question but because it devolved into a group of non-lawyers posting theirs opinions on a legal matter, all the while comparing writing Free Software to stabbing and shooting people. > Seems like that's the general feeling of those who demand silence > about it. Perhaps a separate list named "fedora-truth" or > "fedora-ethics", for this kind of discussion, would make it clear > enough that truth and ethics are not welcome on other lists. Since fedora-list is a general list, I think it makes perfect sense that topics that make up a significant amount of its trafic should get promoted to its own list. I'm sorry you feel otherwise. Emmanuel From rc040203 at freenet.de Wed Jul 30 09:54:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 30 Jul 2008 11:54:05 +0200 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <48903183.2070406@redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <48903183.2070406@redhat.com> Message-ID: <1217411645.3042.346.camel@beck.corsepiu.local> On Wed, 2008-07-30 at 10:16 +0100, Andrew Haley wrote: > Alexandre Oliva wrote: > > On Jul 28, 2008, Andrew Haley wrote: > > > >> It surely was on-topic here to talk about whether unfree binary blobs > >> should be included in Fedora. > > > > +1 > Some people really don't want to see any discussion of the political/ > ethical issues around free software, I suppose, and what it banished > to a list they don't have to read. These people should learn that much about using Linux, GNU, Fedora and more general, OSS and Free/Libre-SW is inevitably political. Ralf From caolanm at redhat.com Wed Jul 30 10:15:19 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 30 Jul 2008 11:15:19 +0100 Subject: rawhide report: 20080730 changes In-Reply-To: <20080730091249.057EC209DFE@releng1.fedora.phx.redhat.com> References: <20080730091249.057EC209DFE@releng1.fedora.phx.redhat.com> Message-ID: <1217412919.18789.101.camel@vain.rhgalway> On Wed, 2008-07-30 at 09:12 +0000, Rawhide wrote: > Broken deps for i386 > ---------------------------------------------------------- > apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so > apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so > apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so FWIW, I hacked up a patch to at least get apt to build against the new librpm at https://bugzilla.redhat.com/show_bug.cgi?id=456872 which would unblock the broken apt-based dependency chain C. From mschwendt at gmail.com Wed Jul 30 11:55:59 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 30 Jul 2008 13:55:59 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <488B6103.7030500@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> Message-ID: <20080730135559.b6c06767.mschwendt@gmail.com> On Sat, 26 Jul 2008 10:38:11 -0700, Toshio Kuratomi wrote: > (A side note: I don't think we can control koji, unfortunately. I think > it uses its own idea of pkg owners coupled with who submitted a build to > send out notification) Which shows that the new %{name}-owner email addresses are insufficient. In particular, koji would need to learn about package owners elsewhere (the separate list in koji of which pkgs to monitor is not connected to the pkgdb either). Theoretically, koji *could* simply mail to those new -owner addresses in addition to the person who requested a build (so all pkg co-maintainers learn about the build job), but that doesn't take into account multiple projects (such as olpc, epel) unless there will be more email addresses. Like epel-%{name}-owner once epel pkgs will be built in koji. > After we solve the criteria issue, we have to solve the UI issue: > making more acls makes the current UI more and more cluttered. I've > been thinking that we want to have a single button for most things. This topic is an example of where bottom-up and top-down don't meet eachother. We want to support co-maintainership. We've got several pieces of infrastructure (including web UIs), some of which don't communicate with eachother [yet]. Simple co-maintenance: multiple persons get exactly the same privileges with regard to a package in various places: cvs : commit pkgdb : give privileges (in "admin" role) koji : permission to build pkg bodhi : permission to release builds as updates bz : either be the assignee or in Cc (and be able to modify tickets) A simple way of communicating (besides irc or private mail) is to commit messages to a README file in pkg cvs. All pkg co-owners receive the commit diff via private mail. It's like a pinboard. It's not a substitute for a mailing-list and not suitable for long discussions. With that design of co-maintenance, however, it takes extra effort to distribute work-load among the co-maintainers. One co-maintainer might want to be the release master (and take care of issueing updates in bodhi). Another one would focus on bug triaging. Even another two can't handle the bz traffic and prefer spending time on actual assignments done by the bug triager. And what about pkg-specific testers? Do they fit into the scheme at all? Or does it need privately maintained email lists to notify them of version upgrades or updates? One can easily see that sending all sorts of notifications to all co-maintainers is suboptimal. From rdieter at math.unl.edu Wed Jul 30 12:08:32 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 30 Jul 2008 07:08:32 -0500 Subject: XULRunner and you References: <1217346891.3273.31.camel@metroid.rdu.redhat.com> Message-ID: Will Woods wrote: > In last week's QA meeting, Chris Aillon (aka caillon, our fearless > firefox/xulrunner maintainer) stopped by to tell us what happened with > xulrunner dep breakage, and how package maintainers can help reduce / > prevent it in the future. Here's a quick summary: > > There are two APIs provided by xulrunner - the stable API (gecko-devel), > and the unstable one (gecko-devel-unstable). > > The stable API, as you might guess, is not expected to change. So if a > package uses the stable API, it won't have any problems when the > xulrunner package is updated. The unstable API could change at any time, > so if your app is using the unstable API it must be rebuilt *every time* > xulrunner is updated. > > Packages using the stable API should have: > Requires: gecko-libs >= 1.9 > BuildRequires: gecko-devel >= 1.9 > > Packages using the unstable API should have: > %define gecko_ver 1.9.0.1 > Requires: gecko-libs = %{gecko_ver} > BuildRequires: gecko-devel-unstable = %{gecko_ver} Maybe consider something like this to help both stable/unstable camps: Provides: gecko-libs(1.9) = 1.9.0.1 Then "stable" folks could Requires: gecko-libs(1.9) and "unstable" folks Requires: gecko-libs(1.9) = 1.9.0.1 -- Rex From seg at haxxed.com Mon Jul 28 22:01:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 28 Jul 2008 17:01:53 -0500 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <488DCDA6.3010600@gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <604aa7910807272338o7f0ba43qc888f88b8f41c844@mail.gmail.com> <20080728070051.GC6648@localhost.localdomain> <488DCDA6.3010600@gmail.com> Message-ID: <1217282513.7387.16.camel@localhost> On Mon, 2008-07-28 at 09:46 -0400, max wrote: > How can a discussion of open source and the GPL be harmful to Fedora or > Red Hat? > In what bizarro universe does that even begin to make sense. When the "discussion" is driven by the misinformed and willfully ignorant, spreading FUD and beating old horses so rotten and dead that those with any clue are driven from the argument by the overwhelming stench. Creating a pungent cesspool of stupid that draws in more raving lunatics from every dark corner of the internet, building momentum and spreading like a cancer that threatens to destroy the entire project. Short answer: Not every "discussion" is productive. -------------- 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 jkeating at redhat.com Wed Jul 30 13:49:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 Jul 2008 09:49:49 -0400 Subject: Slight change in how cvs notifications work In-Reply-To: <20080730135559.b6c06767.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> Message-ID: <1217425789.3151.110.camel@localhost.localdomain> On Wed, 2008-07-30 at 13:55 +0200, Michael Schwendt wrote: > Which shows that the new %{name}-owner email addresses are insufficient. > In particular, koji would need to learn about package owners elsewhere > (the separate list in koji of which pkgs to monitor is not connected to > the pkgdb either). > Theoretically, koji *could* simply mail to those new -owner addresses in > addition to the person who requested a build (so all pkg co-maintainers > learn about the build job), but that doesn't take into account multiple > projects (such as olpc, epel) unless there will be more email > addresses. Like epel-%{name}-owner once epel pkgs will be built in koji. In the future, where we have a common message bus, things like koji and cvs etc... will just drop messages on the bus, stating that some action occurred, and perhaps who created the action. It would be up to a messaging server to consume those messages and decide whom to email about it. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 gnomeuser at gmail.com Wed Jul 30 13:52:13 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 30 Jul 2008 15:52:13 +0200 Subject: Heads up - Mono In-Reply-To: <1216375212.21361.3.camel@T7.Linux> References: <1216375212.21361.3.camel@T7.Linux> Message-ID: <1dedbbfc0807300652i6f61ff44ra7fea27ec620bbf3@mail.gmail.com> Den 18. jul. 2008 12.00 skrev Paul : > Hi, > > I'm expecting the next beta of Mono to hit the servers today. There are > quite a few changes since 1.9.1-2, so please be aware that things may be > broken and need rebuilding. > > Sorry about that. In the words of the good book "Normal service will be > resumed just as soon as we know what normal is anyway" > > Also, please note that as of Mono 2.0, the licence changes to MIT rather > that the mix and match that it currently is. This is happening right > across the mono family as of version 2 (though probably not for the > likes of gtk-sharp2 and gnome-sharp) Whatever happened to this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Wed Jul 30 15:04:36 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jul 2008 08:04:36 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080730135559.b6c06767.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> Message-ID: <48908304.9090103@gmail.com> Michael Schwendt wrote: > On Sat, 26 Jul 2008 10:38:11 -0700, Toshio Kuratomi wrote: > >> (A side note: I don't think we can control koji, unfortunately. I think >> it uses its own idea of pkg owners coupled with who submitted a build to >> send out notification) > > Which shows that the new %{name}-owner email addresses are insufficient. > In particular, koji would need to learn about package owners elsewhere > (the separate list in koji of which pkgs to monitor is not connected to > the pkgdb either). > Theoretically, koji *could* simply mail to those new -owner addresses in > addition to the person who requested a build (so all pkg co-maintainers > learn about the build job), but that doesn't take into account multiple > projects (such as olpc, epel) unless there will be more email > addresses. Like epel-%{name}-owner once epel pkgs will be built in koji. > Which is no better or worse than what we deal with now. (ie: the pkggdb doesn't have build or watchbuild acls because koji lacks the former and has its own idea about the latter). If someone wanted to build up a notification sync process similar to what we do for bugzilla, we could make this work. Patches would be cheerfully accepted for this. >> After we solve the criteria issue, we have to solve the UI issue: >> making more acls makes the current UI more and more cluttered. I've >> been thinking that we want to have a single button for most things. > > This topic is an example of where bottom-up and top-down don't meet > eachother. > > We want to support co-maintainership. We've got several pieces of > infrastructure (including web UIs), some of which don't communicate with > eachother [yet]. > > Simple co-maintenance: multiple persons get exactly the same privileges > with regard to a package in various places: > cvs : commit > pkgdb : give privileges (in "admin" role) > koji : permission to build pkg > bodhi : permission to release builds as updates > bz : either be the assignee or in Cc (and be able to modify tickets) I notice that you only have the active privileges listed here. The passive privileges (being notified of changes in an area) need to be available as well so that upstreams, users, and other people who are not Fedora packagers can be aware of what's going on with packages. > A simple way of communicating (besides irc or private mail) is to commit > messages to a README file in pkg cvs. All pkg co-owners receive the commit > diff via private mail. It's like a pinboard. It's not a substitute for a > mailing-list and not suitable for long discussions. > > With that design of co-maintenance, however, it takes extra effort to > distribute work-load among the co-maintainers. One co-maintainer might > want to be the release master (and take care of issueing updates in > bodhi). Another one would focus on bug triaging. Even another two can't > handle the bz traffic and prefer spending time on actual assignments done > by the bug triager. And what about pkg-specific testers? Do they fit into > the scheme at all? Or does it need privately maintained email lists to > notify them of version upgrades or updates? One can easily see that > sending all sorts of notifications to all co-maintainers is suboptimal. > I would love a better designed UI and better designed acls. So please, give me a design to implement instead of merely criticising what's there. Don't take me wrong, I love that you're criticising it because it's horrible. But without a notion of what the better system looks like we're never going to replace what we have. -Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lyos.gemininorezel at gmail.com Wed Jul 30 15:08:06 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Wed, 30 Jul 2008 11:08:06 -0400 Subject: OT: (?) Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <7f692fec0807281204n3697e9dbv54034dcd2bfe651e@mail.gmail.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <604aa7910807272146o740b0cfaw1b031fc8f0f8ee65@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <20080728105452.GN6648@localhost.localdomain> <1217247849.4468.15.camel@rosebud> <488DEFC6.8080809@gmail.com> <7f692fec0807281204n3697e9dbv54034dcd2bfe651e@mail.gmail.com> Message-ID: <489083D6.50009@gmail.com> Yaakov Nemoy wrote: > 2008/7/28 Lyos Gemini Norezel : > >> I agree with Seth. >> Most of the "flame-fest" threads mentioned, while mostly boring, idiotic, >> and several other adjectives >> I can think of... they do, on occaision, produce *something* of value, >> albeit rarely. >> >> Shall we ban idiots, simply because they're moronic? >> How about we just shoot 90% of the world and be done with it? >> > > Can we? Please? > > > -Yaakov Yes. Lyos Gemini Norezel From gilboad at gmail.com Wed Jul 30 16:09:32 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 30 Jul 2008 19:09:32 +0300 Subject: kdebluetooth4... update? new review? Message-ID: <1217434172.816.18.camel@gilboa-work-dev.localdomain> Hello all, I'm maintaining the kdebluetooth package. While working under F8/KDE3.5, the package is hopelessly broken under F9/KDE4. (Due to various reasons; not all of them fixable). Luckily for me, mere minutes before I was about to orphan/EOL it (due to upstream's early death), the kdebluetooth team woke up and released a new version, kdebluetooth4 (QT4/KDE4) which is an early alpha release. (v0.1) Two questions: A. Does major version bump require a new review? B. Should I push an early alpha as an update that obsoletes an existing, yet broken package? - Gilboa From mschwendt at gmail.com Wed Jul 30 16:37:52 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 30 Jul 2008 18:37:52 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <48908304.9090103@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> <48908304.9090103@gmail.com> Message-ID: <20080730183752.df3c8ac3.mschwendt@gmail.com> On Wed, 30 Jul 2008 08:04:36 -0700, Toshio Kuratomi wrote: > > Simple co-maintenance > I notice that you only have the active privileges listed here. Because it only described the much simplified model, which recent consolidation seems to have as a goal. > The > passive privileges (being notified of changes in an area) need to be > available as well so that upstreams, users, and other people who are not > Fedora packagers can be aware of what's going on with packages. That's the less simple design with fine-grained options for the various types of notifications, so e.g. "watchbugzilla" and "watchcommits" are distinct from eachother. > I would love a better designed UI and better designed acls. So please, > give me a design to implement instead of merely criticising what's > there. Don't take me wrong, I love that you're criticising it because > it's horrible. But without a notion of what the better system looks > like we're never going to replace what we have. > > -Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi I'm not talking UI design yet, as that can only follow backend feature design. Whether the user may need to mark checkboxes or move items from one listbox to another and vice versa, is still unimportant. Imagine users in bodhi could click a "monitor this package" icon and confirm subscription with their credentials. Only if that's possible in the backend software, you can start worrying about the UI. I can't either comment on UI proposals like > Acls: > Req Apprv > [X] [X] watch commits > [X] [_] watch bugzilla > [X] [X] watch updates > Approval Queue: > > abadger requests > qa-assistant > [X] watch bugzilla without any background on why pkg maintainers must approve such monitoring requests at all. Bugzilla is world-readable except for tickets with special flags (e.g. only visible to Fedora Contributors). Same for cvs, unless mechanisms are in place which hide branches in embargo situations. Approval of requests for access to non-public data (or write-privileges) is something else, of course. Jesse mentioned work on a "common message bus" and a "messaging server", which is something in the area of the notification queueing server proposed long ago, but more versatile. From rdieter at math.unl.edu Wed Jul 30 17:06:11 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 30 Jul 2008 12:06:11 -0500 Subject: kdebluetooth4... update? new review? References: <1217434172.816.18.camel@gilboa-work-dev.localdomain> Message-ID: Gilboa Davara wrote: > Hello all, > > I'm maintaining the kdebluetooth package. > While working under F8/KDE3.5, the package is hopelessly broken under > F9/KDE4. (Due to various reasons; not all of them fixable). > Luckily for me, mere minutes before I was about to orphan/EOL it (due to > upstream's early death), the kdebluetooth team woke up and released a > new version, kdebluetooth4 (QT4/KDE4) which is an early alpha release. > (v0.1) > > Two questions: > A. Does major version bump require a new review? (imo) not required. > B. Should I push an early alpha as an update that obsoletes an existing, > yet broken package? probably isn't any worse than the status quo, so yeah. any ideas of a release schedule? -- Rex From a.badger at gmail.com Wed Jul 30 17:12:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jul 2008 10:12:53 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080730183752.df3c8ac3.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> <48908304.9090103@gmail.com> <20080730183752.df3c8ac3.mschwendt@gmail.com> Message-ID: <4890A115.2040609@gmail.com> Michael Schwendt wrote: > On Wed, 30 Jul 2008 08:04:36 -0700, Toshio Kuratomi wrote: > >>> Simple co-maintenance > >> I notice that you only have the active privileges listed here. > > Because it only described the much simplified model, which recent > consolidation seems to have as a goal. > This doesn't answer my question of whether you and others want consolidation or not, though. And it doesn't tell me what to do with the notification acls which are more problematic than the acls for things that actually allow you to do things. >> The >> passive privileges (being notified of changes in an area) need to be >> available as well so that upstreams, users, and other people who are not >> Fedora packagers can be aware of what's going on with packages. > > That's the less simple design with fine-grained options for the various > types of notifications, so e.g. "watchbugzilla" and "watchcommits" > are distinct from eachother. > Not entirely. There must always be at least one notification acl. If you like consolidation, then you have to list at least that one acl. If you dislike notification, then you should propose something with an expanded list of notification acls. >> I would love a better designed UI and better designed acls. So please, >> give me a design to implement instead of merely criticising what's >> there. Don't take me wrong, I love that you're criticising it because >> it's horrible. But without a notion of what the better system looks >> like we're never going to replace what we have. >> >> -Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi > > I'm not talking UI design yet, as that can only follow backend feature > design. > Sure. But backend feature design is driven by what the user wants in the front end. I can implement either a single backend acl or multiple. But it makes little sense for me to continue adding backend notification acls if you don't want to see them in the front-end. And it makes it impossible for us to have multiple front-end acls if I code a single backend acl. If you give me UI, then I can code the backend to enable it. If you give me criteria for when to add new notification acls, I can code the backend to have acls that meet those criteria. > Whether the user may need to mark checkboxes or move items from one > listbox to another and vice versa, is still unimportant. Imagine users in > bodhi could click a "monitor this package" icon and confirm subscription > with their credentials. Only if that's possible in the backend software, > you can start worrying about the UI. I can't either comment on UI > proposals like > Your example is too simple. Whether there's one notification acl or five, it is still possible to have a "monitor this package" icon in bodhi. The question is what you want such an icon to do. Monitor all notifications to the package? Monitor only changes in bodhi? Monitor only comments on that particular build? this is what I need to know in order to build a backend that supports it. >> Acls: >> Req Apprv >> [X] [X] watch commits >> [X] [_] watch bugzilla >> [X] [X] watch updates > >> Approval Queue: >> >> abadger requests >> qa-assistant >> [X] watch bugzilla > > without any background on why pkg maintainers must approve such monitoring > requests at all. Bugzilla is world-readable except for tickets with > special flags (e.g. only visible to Fedora Contributors). Same for cvs, > unless mechanisms are in place which hide branches in embargo > situations. Approval of requests for access to non-public data (or > write-privileges) is something else, of course. > Well, I can't work on the backend without knowing what people actually want to be able to do. Tell me that and I can change the pkgdb to accommodate it or put it on the wishlist for when we have a message bus and notification service. (Re: approving watchbugzilla: I asked a while ago to make watchbugzilla and watchcommits auto-approved but hadess objected because bugzilla can be used to file tickets that are under embargo, for instance, security related. Therefore, the desire was to manually approve who was able to join this. watchcommits, OTOH, goes to a public mailing list already so I don't see any point in continuing to manually approve that.) > Jesse mentioned work on a "common message bus" and a "messaging server", > which is something in the area of the notification queueing server > proposed long ago, but more versatile. > Yep. I was excited whe Jesse first mentioned this at FUDCon and then asked for a server to work up a proof of concept on as it addresses that need very well. It still needs to have a way to associate the user with the notifications they're interested in, though, so there still needs to be a backend store somewhere. -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 bnocera at redhat.com Wed Jul 30 18:11:37 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 30 Jul 2008 19:11:37 +0100 Subject: Does your app use LIRC? Message-ID: <1217441497.5809.20.camel@cookie.hadess.net> If your app uses liblirc_client, it would be nice if you could follow the instructions, and the two examples at: https://fedoraproject.org/wiki/Features/BetterLIRCSupport#User_Experience to make your application work out-of-the-box in Fedora 10. Elisa, Totem and Rhythmbox are already fixed. I'd have had a nice list using repoquery, but it just seems to hang there doing nothing (and then gives me useless answers, might just be me...). Let me know if you have any questions about the setup. Cheers From stickster at gmail.com Wed Jul 30 18:43:13 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 30 Jul 2008 18:43:13 +0000 Subject: Release Planning Recap :: 2008-07-30, UTC 1700 Message-ID: <1217443393.3694.96.camel@victoria> = Release planning meeting, 2008-07-30 = == Attendance == ''Present:'' Tom Callaway (Engineering/Legal), Paul Frields (moderator), Jesse Keating (RelEng), Jonathan Roberts (Marketing), Seth Vidal (Infrastructure), Karsten Wade (Docs) == Agenda == === Reiterating purpose === * Not policy setting, nor decision making * Progress reporting and schedule debugging only * Making sure that dependencies that affect releases are being satisfied across Fedora community teams * Any action items are potential only, until pushed out into the community space for discussion and follow-through === Current Alpha status (RelEng) === * Not finished ** Number of composes happening internally on f13's workstation ** Not enough got done during OLS/OSCON - not enough people doing anything with looking at bits ** We can't compose yet in PHX, which is why it happens on f13's station ** Chasing down issues with anaconda currently, hopefully on the last few now ** f13 hopes to have a candidate release tree ** New problem in installer right now * Not yet in danger of slipping ** If we don't have a tree by tomorrow, that's not good === Infrastructure === * uncomfortable problems in existing BT server, it keeps dying (serverbeach1) ** Might be routing, or hardware... testing to figure it out ** skvidal is going to keep a very close eye on making sure the old and new servers are sync'd '''DEBUGGING:''' Should f13's routine change? No. * Space issues? 261GB available on netapps ** many terabytes coming back online "soon" ** drives hopefully coming in next week, then it's just reconfiguring, no onsite required === Docs === * Alpha and Beta release notes are a one-sheet on the wiki ** Living document, can change after release day ** QA, Desktop, and RelEng have done a great job of adding some important content ** Priority is to let testers know what you want them to do with the Alpha '''DEBUGGING:''' We need a list of pre-approved URLs for release announcement * Docs can handle the majority of the text for the release announcement email, and check URLs, so releng can concentrate on sending it out when final * Release notes production is hopefully going to change with F10 to use an in-distro tool, publican, to build === Marketing === * Not much on plate for Alpha in particular * Geek news will be all over the Alpha, are we doing anything to publicize it? ** Paul has been working with Kara on e.g. a press blog entry ** Our announcement should also serve as testing recruitment === Legal === * Nothing at this time == Next meeting == * Post-partum Alpha meeting would probably be useful ** if no agenda items, no meeting * Definitely one a few days ahead of Beta freeze ** Announcements to go to fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mschwendt at gmail.com Wed Jul 30 19:06:11 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 30 Jul 2008 21:06:11 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <4890A115.2040609@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> <48908304.9090103@gmail.com> <20080730183752.df3c8ac3.mschwendt@gmail.com> <4890A115.2040609@gmail.com> Message-ID: <20080730210611.10a6b8d2.mschwendt@gmail.com> On Wed, 30 Jul 2008 10:12:53 -0700, Toshio Kuratomi wrote: > This doesn't answer my question of whether you and others want > consolidation or not, though. I did answer that in my 2nd reply in this thread. I can only speak for myself, though, but I have doubts that others prefer a single "watchpkg" option to receive *all* sorts of notifications. Client-side filtering as the only way to opt-out from some of the messages always bears a risk. In addition to "watchcommits" and "watchbugzilla", the following two would make sense: "watchbuilds" and "watchupdates". So far, co-maintainers need to create/forward such messages manually. I understand that someone may like to subscribe to "watchcommits" and unsubscribe from "watchbugzilla", and vice versa. > backend feature design is driven by what the user wants in > the front end. Make that "backend feature design is driven by what features the user wants" and I agree. ;) Talking about the actual look'n'feel of a web UI is something entirely different. > I can implement either a single backend acl or multiple. > But it makes little sense for me to continue adding backend > notification acls if you don't want to see them in the front-end. ?? They are available in the front-end, but you've chosen to redefine "watchbugzilla" as it now implies "watchcommits". > Whether there's one notification acl or > five, it is still possible to have a "monitor this package" icon in > bodhi. The question is what you want such an icon to do. Monitor all > notifications to the package? Monitor only changes in bodhi? Monitor > only comments on that particular build? this is what I need to know in > order to build a backend that supports it. Well, sure, you need to find such a feature useful before you want to work on it. Or you implement what your manager tells you or if you see the demand. You could add a clickable button or icon to bodhi and koji and even bugzilla, and it could point the user to the central place (e.g. the pgkdb) where to maintain settings related to notifications. Or it would be a shortcut to subscribe to a specific type of notification, e.g. "Monitor updates to this package" in bodhi, "Monitor builds of this package" in koji, "Monitor comments about this package" in bugzilla, and so on. > Well, I can't work on the backend without knowing what people actually > want to be able to do. If you want to foster co-maintainership, it should become possible for co-maintainers to monitor every detail related to maintaining and publishing a package. I would consider a fine-grained choice of what messages to receive superior than a single "get everything" option. Further, you need to ask yourself about the power of the backend and its options. What does it need to do with regard to embargoes and private tickets? Who can aquire the "watchbugzilla" privilege? Is it available only to Fedora Contributors? Does it take precedence over the "Only visible to Fedora Project Contributors" flag in bugzilla? Is a different mechanism used to decide who is permitted to see private data? Perhaps you want multiple watchbugzilla options. One for Fedora Contributors, another one for arbitrary users. Also, if you worry about UI design. Consider somebody who maintains the notification acls for a dozen [or more] packages. It sounds plausible that such a person would like a UI where to display a complete list of all approved privileges for all packages the person is in charge of. Else you would need to query each pkg individually to find out whether maybe you approved somebody as "observer" for one of your pkgs two years ago. > (Re: approving watchbugzilla: I asked a while ago to make watchbugzilla > and watchcommits auto-approved but hadess objected because bugzilla can > be used to file tickets that are under embargo, for instance, security > related. Therefore, the desire was to manually approve who was able to > join this. watchcommits, OTOH, goes to a public mailing list already > so I don't see any point in continuing to manually approve that.) That's a matter of definition. You say watchbugzilla already overrides bugzilla's group permissions ("Security Sensitive Bug" and "Fedora Project Contributors"). Perhaps in the future embargoed scm commits become possible. Then you don't want watchcommits to send them to arbitrary subscribers. From bpepple at fedoraproject.org Wed Jul 30 19:58:07 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 30 Jul 2008 15:58:07 -0400 Subject: FESCo Meeting Summary for 2008-07-30 Message-ID: <1217447887.3274.4.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * David Woodhouse (dwmw2) * Josh Boyer (jwb) * Jon Stanley (jds2001) * Dennis Gilmore (dgilmore) === Absent === * Karsten Hopp (kick_) * Jarod Wilson (j-rod) == Summary == === Collective Maintenance Proposal === * FESCo rejected the collective maintenance proposal (1) for now. They had some concerns about the extra bureaucracy, and they wanted to see how the new maintainer containment policy (2) and opening acls (3) to packagers helps first, since these are to be implemented in the very near future. If there is still a problem, this proposal could be revisited. 1. http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance 2. http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment 3. http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening === Spins === * FESCo approved a proposal to give Release Engineering final say in acking spins for a release based on the Feature criteria. If there are disagreements between spins sig/owner they can be escalated to FESCo if needed === Features === * FESCo approved the following feature for F10: ** http://fedoraproject.org/wiki/Features/BetterWebcamSupport * FESCo discussed briefly the Better Startup(1) feature, but held off on voting on it, until it's feature page was completed. 1. http://fedoraproject.org/wiki/Features/BetterStartup IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-07-30.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Jul 30 20:30:10 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jul 2008 13:30:10 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080730210611.10a6b8d2.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080725204405.eded77b8.mschwendt@gmail.com> <488A3AE7.1030100@gmail.com> <20080726095517.e3461f45.mschwendt@gmail.com> <488B6103.7030500@gmail.com> <20080730135559.b6c06767.mschwendt@gmail.com> <48908304.9090103@gmail.com> <20080730183752.df3c8ac3.mschwendt@gmail.com> <4890A115.2040609@gmail.com> <20080730210611.10a6b8d2.mschwendt@gmail.com> Message-ID: <4890CF52.8010705@gmail.com> Michael Schwendt wrote: > On Wed, 30 Jul 2008 10:12:53 -0700, Toshio Kuratomi wrote: > >> This doesn't answer my question of whether you and others want >> consolidation or not, though. > > I did answer that in my 2nd reply in this thread. I can only speak for > myself, though, but I have doubts that others prefer a single "watchpkg" > option to receive *all* sorts of notifications. Client-side filtering as > the only way to opt-out from some of the messages always bears a risk. > > In addition to "watchcommits" and "watchbugzilla", the following two would > make sense: "watchbuilds" and "watchupdates". So far, co-maintainers need > to create/forward such messages manually. > > I understand that someone may like to subscribe to "watchcommits" and > unsubscribe from "watchbugzilla", and vice versa. > >> backend feature design is driven by what the user wants in >> the front end. > > Make that "backend feature design is driven by what features > the user wants" and I agree. ;) > > Talking about the actual look'n'feel of a web UI is something > entirely different. > >> I can implement either a single backend acl or multiple. >> But it makes little sense for me to continue adding backend >> notification acls if you don't want to see them in the front-end. > > ?? They are available in the front-end, but you've chosen to > redefine "watchbugzilla" as it now implies "watchcommits". > I'm talking about whether to get rid of the distinction throughout the code or not. I have had requests to streamline the UI for just having two roles: Package Watcher and Package Maintainer. So I need input on whether that's the end-all-be-all. Is this the only real use case (in which case, why should I implement more acls in the backend; they're always going to be hidden in the front end) or just the optimized use case (For which I posted a straw man with multiple acls available for those that want them.) >> Whether there's one notification acl or >> five, it is still possible to have a "monitor this package" icon in >> bodhi. The question is what you want such an icon to do. Monitor all >> notifications to the package? Monitor only changes in bodhi? Monitor >> only comments on that particular build? this is what I need to know in >> order to build a backend that supports it. > > Well, sure, you need to find such a feature useful before you want to work > on it. Or you implement what your manager tells you or if you see the > demand. You could add a clickable button or icon to bodhi and koji and even > bugzilla, and it could point the user to the central place (e.g. the > pgkdb) where to maintain settings related to notifications. Or it would be > a shortcut to subscribe to a specific type of notification, e.g. "Monitor > updates to this package" in bodhi, "Monitor builds of this package" in > koji, "Monitor comments about this package" in bugzilla, and so on. > Exactly. >> Well, I can't work on the backend without knowing what people actually >> want to be able to do. > > If you want to foster co-maintainership, it should become possible for > co-maintainers to monitor every detail related to maintaining and > publishing a package. I would consider a fine-grained choice of what > messages to receive superior than a single "get everything" option. > So do you like my straw man or not? If so, I still need to know: What is the criteria for having a watch* acl? Should everything that can send a notification have a separate acl? Should automated reports like broken deps and fails to rebuild from source? If there's a line, what are the criteria for determining which things fall to one side of the line or the other? Phrased more specifically, why do you want to have watchbugzilla, watchupdates, watchcommits, watchbuilds? What makes those four different from other watch* acls? -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 seg at haxxed.com Wed Jul 30 21:09:13 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 30 Jul 2008 16:09:13 -0500 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <48903183.2070406@redhat.com> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <48903183.2070406@redhat.com> Message-ID: <1217452153.7387.31.camel@localhost> On Wed, 2008-07-30 at 10:16 +0100, Andrew Haley wrote: > Some people really don't want to see any discussion of the political/ > ethical issues around free software, I suppose, and what it banished > to a list they don't have to read. Nice straw man. Some of us have have been involved in the FLOSS community for some time. Some of us settled our ideological positions decades ago, and have more productive things to do than suffer through the same old Frequently Waged Flamewars over and over again every time someone new comes along. It's not that we don't care. Its that your radical ideas about the ethics of Free Software have already occurred to other people. (...Who are much more eloquent, diplomatic and productive than you are.) -------------- 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 opensource at till.name Wed Jul 30 21:07:49 2008 From: opensource at till.name (Till Maas) Date: Wed, 30 Jul 2008 23:07:49 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <4890CF52.8010705@gmail.com> References: <48896E7F.9040003@gmail.com> <20080730210611.10a6b8d2.mschwendt@gmail.com> <4890CF52.8010705@gmail.com> Message-ID: <200807302308.03120.opensource@till.name> On Wed July 30 2008, Toshio Kuratomi wrote: > What is the criteria for having a watch* acl? Should everything that > can send a notification have a separate acl? Should automated reports > like broken deps and fails to rebuild from source? If there's a line, > what are the criteria for determining which things fall to one side of > the line or the other? Phrased more specifically, why do you want to > have watchbugzilla, watchupdates, watchcommits, watchbuilds? What makes > those four different from other watch* acls? Watchbugzilla is imho also interesting for people who only want to triage bugs that belong to one package, but are not interested in maintaining them. For testers watchbugzilla and -updates /-builds would be useful, but they may not be interested in the scm commits. For maintainers that maintain a pacakge that depends on another, the watch(updates,builds) can be enough that they need to know, because they may not care about bug reports for the package and cvs commits. Also upstream of a package might be interested to use watchbugzilla for the package in Fedora, but not in the other watch possibilities. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Wed Jul 30 22:28:56 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jul 2008 15:28:56 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <200807302308.03120.opensource@till.name> References: <48896E7F.9040003@gmail.com> <20080730210611.10a6b8d2.mschwendt@gmail.com> <4890CF52.8010705@gmail.com> <200807302308.03120.opensource@till.name> Message-ID: <4890EB28.2040208@gmail.com> Till Maas wrote: > On Wed July 30 2008, Toshio Kuratomi wrote: > >> What is the criteria for having a watch* acl? Should everything that >> can send a notification have a separate acl? Should automated reports >> like broken deps and fails to rebuild from source? If there's a line, >> what are the criteria for determining which things fall to one side of >> the line or the other? Phrased more specifically, why do you want to >> have watchbugzilla, watchupdates, watchcommits, watchbuilds? What makes >> those four different from other watch* acls? > > Watchbugzilla is imho also interesting for people who only want to triage bugs > that belong to one package, but are not interested in maintaining them. For > testers watchbugzilla and -updates /-builds would be useful, but they may not > be interested in the scm commits. For maintainers that maintain a pacakge > that depends on another, the watch(updates,builds) can be enough that they > need to know, because they may not care about bug reports for the package and > cvs commits. Also upstream of a package might be interested to use > watchbugzilla for the package in Fedora, but not in the other watch > possibilities. > So let me phrase this again: "Hi Toshio, I'd like to have a watch*acl for people to sign up to receive notices when their package doesn't have complete deps satisfied from within the repository." What criteria do I apply to this request to determine if I should create an acl for this request or tell them to use an existing acl? -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 mschwendt at gmail.com Wed Jul 30 23:31:13 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 31 Jul 2008 01:31:13 +0200 Subject: Slight change in how cvs notifications work In-Reply-To: <4890EB28.2040208@gmail.com> References: <48896E7F.9040003@gmail.com> <20080730210611.10a6b8d2.mschwendt@gmail.com> <4890CF52.8010705@gmail.com> <200807302308.03120.opensource@till.name> <4890EB28.2040208@gmail.com> Message-ID: <20080731013113.f24e1646.mschwendt@gmail.com> On Wed, 30 Jul 2008 15:28:56 -0700, Toshio Kuratomi wrote: > Till Maas wrote: > > On Wed July 30 2008, Toshio Kuratomi wrote: > > > >> What is the criteria for having a watch* acl? Should everything that > >> can send a notification have a separate acl? Should automated reports > >> like broken deps and fails to rebuild from source? If there's a line, > >> what are the criteria for determining which things fall to one side of > >> the line or the other? Phrased more specifically, why do you want to > >> have watchbugzilla, watchupdates, watchcommits, watchbuilds? What makes > >> those four different from other watch* acls? > > > > Watchbugzilla is imho also interesting for people who only want to triage bugs > > that belong to one package, but are not interested in maintaining them. For > > testers watchbugzilla and -updates /-builds would be useful, but they may not > > be interested in the scm commits. For maintainers that maintain a pacakge > > that depends on another, the watch(updates,builds) can be enough that they > > need to know, because they may not care about bug reports for the package and > > cvs commits. Also upstream of a package might be interested to use > > watchbugzilla for the package in Fedora, but not in the other watch > > possibilities. > > > So let me phrase this again: > > "Hi Toshio, I'd like to have a watch*acl for people to sign up to > receive notices when their package doesn't have complete deps satisfied > from within the repository." > > What criteria do I apply to this request to determine if I should create > an acl for this request or tell them to use an existing acl? Hmmm? What "existing acl" would that be? Somebody asks you for a way to monitor broken deps reports. What communication "channel" are those reports posted through? Let's say, for Rawhide. To "package owners"? Is that equal to the list of e-mail addresses in bugzilla assigned to and Cc fields? Surely, when somebody wants to subscribe to a specific channel only, it must be an entirely new watch* acl. Or else you would want the person to subscribe to watchbugzilla in order to receive broken deps reports *and* lots of bugzilla mail. Broken deps can only be fixed by somebody with scm commit access. Mailing those people is one option. Is that possible already? I mean, not just with the new %{name}-owner addresses, but also for EPEL? Can the "commit" acl per pkg name be retrieved? But if such reports are sent to commits acl, it cannot be subscribed to. :) OTOH, it might be that the report is python-bugzilla'ed automatically, and in that case only the watchbugzilla people learn about the broken dep. It could also be that they are flooded with bugzilla spam, however, or that those with commit permission don't watchbugzilla. ;) Or it's a report about a broken dep because of a test update. In that case, a special QA monkey might want to stop the test update and give it -1 karma in bodhi and possibly take further action. A week later you're asked for a way to monitor "broken upgrade path" notifications and "bad pkg urls" reports. *Conclusively*, it sounds like a a new watch* acl is needed in such cases. It can be "on" by default for all package maintainers and be opt-in for other people. From mschwendt at gmail.com Wed Jul 30 23:43:29 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 30 Jul 2008 23:43:29 -0000 Subject: Broken dependencies in Fedora 9 - 2008-07-31 Message-ID: <20080730234329.11188.98262@faldor.intranet> Summary of broken packages (by owner): berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch cweyl AT alumni.drew.edu perl-Catalyst-Devel-1.07-1.fc9.noarch dwmw2 AT infradead.org callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc64 callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.x86_64 ebmunson AT us.ibm.com libhugetlbfs-test-1.1-6.fc9.ppc libhugetlbfs-test-1.1-6.fc9.ppc64 libhugetlbfs-test-1.1-6.fc9.x86_64 lsvpd-1.6.4-1.fc9.i386 lsvpd-1.6.4-1.fc9.ppc lsvpd-1.6.4-1.fc9.ppc64 lsvpd-1.6.4-1.fc9.x86_64 karlthered AT gmail.com gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 katzj AT redhat.com livecd-tools-017.1-1.fc9.ppc64 lxtnow AT gmail.com gspiceui-0.9.65-2.fc9.ppc64 oliver AT linux-kernel.at syck-php-0.61-4.3.fc9.i386 syck-php-0.61-4.3.fc9.ppc syck-php-0.61-4.3.fc9.ppc64 syck-php-0.61-4.3.fc9.x86_64 orion AT cora.nwra.com paraview-3.2.1-6.fc9.i386 paraview-mpi-3.2.1-6.fc9.i386 wart AT kobold.org cyphesis-selinux-0.5.15-6.fc9.i386 cyphesis-selinux-0.5.15-6.fc9.ppc cyphesis-selinux-0.5.15-6.fc9.ppc64 cyphesis-selinux-0.5.15-6.fc9.x86_64 ====================================================================== Broken packages in fedora-9-i686: callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 requires libpri.so.1.0 cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 syck-php-0.61-4.3.fc9.i386 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc64: callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc64 requires libpri.so.1.0()(64bit) cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.ppc64 requires libhugetlbfs = 0:1.1-6.fc9 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 syck-php-0.61-4.3.fc9.ppc64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-ppc: callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc requires libpri.so.1.0 cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.ppc requires libhugetlbfs = 0:1.1-6.fc9 syck-php-0.61-4.3.fc9.ppc requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-9-x86_64: callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.x86_64 requires libpri.so.1.0()(64bit) cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 libhugetlbfs-test-1.1-6.fc9.x86_64 requires libhugetlbfs = 0:1.1-6.fc9 paraview-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 syck-php-0.61-4.3.fc9.x86_64 requires php = 0:5.2.5 ====================================================================== Broken packages in fedora-updates-9-i686: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.i386 requires libvpd_cxx-2.0.so.1 perl-Catalyst-Devel-1.07-1.fc9.noarch requires perl(Catalyst::Manual) >= 0:5.7000 ====================================================================== Broken packages in fedora-updates-9-ppc64: gspiceui-0.9.65-2.fc9.ppc64 requires gwave gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 livecd-tools-017.1-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc9.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Devel-1.07-1.fc9.noarch requires perl(Catalyst::Manual) >= 0:5.7000 ====================================================================== Broken packages in fedora-updates-9-ppc: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.ppc requires libvpd_cxx-2.0.so.1 perl-Catalyst-Devel-1.07-1.fc9.noarch requires perl(Catalyst::Manual) >= 0:5.7000 ====================================================================== Broken packages in fedora-updates-9-x86_64: gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 lsvpd-1.6.4-1.fc9.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Devel-1.07-1.fc9.noarch requires perl(Catalyst::Manual) >= 0:5.7000 From wart at kobold.org Wed Jul 30 23:48:34 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 30 Jul 2008 16:48:34 -0700 Subject: Broken dependencies in Fedora 9 - 2008-07-31 In-Reply-To: <20080730234329.11188.98262@faldor.intranet> References: <20080730234329.11188.98262@faldor.intranet> Message-ID: <4890FDD2.6040609@kobold.org> Michael Schwendt wrote: > Summary of broken packages (by owner): > [..] > wart AT kobold.org > cyphesis-selinux-0.5.15-6.fc9.i386 > cyphesis-selinux-0.5.15-6.fc9.ppc > cyphesis-selinux-0.5.15-6.fc9.ppc64 > cyphesis-selinux-0.5.15-6.fc9.x86_64 > > > ====================================================================== > Broken packages in fedora-9-i686: > > callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 requires libpri.so.1.0 > cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 cyphesis-selinux has been merged into the selinux-policy package and is now obsolete, and has been marked as such by the updated cyphesis-0.5.16 package. I'm not sure what magic I need to perform to get the broken deps reports to stop complaining about it. Also, cyphesis-selinux needs to be blocked from F10. --Wart From mschwendt at gmail.com Wed Jul 30 23:51:14 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 30 Jul 2008 23:51:14 -0000 Subject: Broken dependencies in Fedora 8 - 2008-07-31 Message-ID: <20080730235114.11220.72874@faldor.intranet> Summary of broken packages (by owner): berrange AT redhat.com perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch dcbw AT redhat.com 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 dev AT nigelj.com mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch dwmw2 AT infradead.org callweaver-zaptel-1.2-0.3.rc4.20070822.i386 callweaver-zaptel-1.2-0.3.rc4.20070822.ppc callweaver-zaptel-1.2-0.3.rc4.20070822.ppc64 callweaver-zaptel-1.2-0.3.rc4.20070822.x86_64 ebmunson AT us.ibm.com libhugetlbfs-test-1.1-4.fc8.i386 libhugetlbfs-test-1.1-4.fc8.ppc libhugetlbfs-test-1.1-4.fc8.ppc64 libhugetlbfs-test-1.1-4.fc8.x86_64 ianweller AT gmail.com mediawiki-HNP-1.1.2-1.fc8.noarch mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch mediawiki-StubManager-1.2.0-1.fc8.noarch python-mwlib-0.8.0-2.fc8.i386 python-mwlib-0.8.0-2.fc8.ppc python-mwlib-0.8.0-2.fc8.ppc64 python-mwlib-0.8.0-2.fc8.x86_64 jeff AT ocjtech.us asterisk-zaptel-1.4.21.2-1.fc8.i386 asterisk-zaptel-1.4.21.2-1.fc8.ppc asterisk-zaptel-1.4.21.2-1.fc8.ppc64 asterisk-zaptel-1.4.21.2-1.fc8.x86_64 konrad AT tylerc.org joda-time-1.5.2-7.tzdata2008d.fc8.noarch lxtnow AT gmail.com gspiceui-0.9.65-2.fc8.ppc64 oliver AT linux-kernel.at syck-php-0.61-2.fc8.i386 syck-php-0.61-2.fc8.ppc syck-php-0.61-2.fc8.ppc64 syck-php-0.61-2.fc8.x86_64 rmeggins AT redhat.com idm-console-framework-1.1.1-3.fc8.noarch ====================================================================== Broken packages in fedora-8-i686: callweaver-zaptel-1.2-0.3.rc4.20070822.i386 requires libpri.so.1.0 libhugetlbfs-test-1.1-4.fc8.i386 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.i386 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc64: callweaver-zaptel-1.2-0.3.rc4.20070822.ppc64 requires libpri.so.1.0()(64bit) libhugetlbfs-test-1.1-4.fc8.ppc64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-ppc: callweaver-zaptel-1.2-0.3.rc4.20070822.ppc requires libpri.so.1.0 libhugetlbfs-test-1.1-4.fc8.ppc requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.ppc requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-8-x86_64: 1:NetworkManager-0.7.0-0.5.svn3030.fc8.i386 requires NetworkManager-glib = 1:0.7.0-0.5.svn3030.fc8 callweaver-zaptel-1.2-0.3.rc4.20070822.x86_64 requires libpri.so.1.0()(64bit) libhugetlbfs-test-1.1-4.fc8.x86_64 requires libhugetlbfs = 0:1.1-4.fc8 syck-php-0.61-2.fc8.x86_64 requires php = 0:5.2.4 ====================================================================== Broken packages in fedora-updates-8-i686: asterisk-zaptel-1.4.21.2-1.fc8.i386 requires libpri.so.1.0 python-mwlib-0.8.0-2.fc8.i386 requires tex(latex) ====================================================================== Broken packages in fedora-updates-8-ppc64: asterisk-zaptel-1.4.21.2-1.fc8.ppc64 requires libpri.so.1.0()(64bit) gspiceui-0.9.65-2.fc8.ppc64 requires gwave idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-7.tzdata2008d.fc8.noarch requires java > 0:1.5.0 mediawiki-HNP-1.1.2-1.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch requires mediawiki >= 0:1.10 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch requires mediawiki < 0:1.11 mediawiki-StubManager-1.2.0-1.fc8.noarch requires mediawiki >= 0:1.10 perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch requires darcs >= 0:1.0.0 python-mwlib-0.8.0-2.fc8.ppc64 requires tex(latex) ====================================================================== Broken packages in fedora-updates-8-ppc: asterisk-zaptel-1.4.21.2-1.fc8.ppc requires libpri.so.1.0 idm-console-framework-1.1.1-3.fc8.noarch requires java > 0:1.5.0 joda-time-1.5.2-7.tzdata2008d.fc8.noarch requires java > 0:1.5.0 python-mwlib-0.8.0-2.fc8.ppc requires tex(latex) ====================================================================== Broken packages in fedora-updates-8-x86_64: asterisk-zaptel-1.4.21.2-1.fc8.x86_64 requires libpri.so.1.0()(64bit) python-mwlib-0.8.0-2.fc8.x86_64 requires tex(latex) From mschwendt at gmail.com Wed Jul 30 23:54:15 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 31 Jul 2008 01:54:15 +0200 Subject: Broken dependencies in Fedora 9 - 2008-07-31 In-Reply-To: <4890FDD2.6040609@kobold.org> References: <20080730234329.11188.98262@faldor.intranet> <4890FDD2.6040609@kobold.org> Message-ID: <20080731015415.5b0f6fd2.mschwendt@gmail.com> On Wed, 30 Jul 2008 16:48:34 -0700, Michael Thomas wrote: > Michael Schwendt wrote: > > Summary of broken packages (by owner): > > > [..] > > wart AT kobold.org > > cyphesis-selinux-0.5.15-6.fc9.i386 > > cyphesis-selinux-0.5.15-6.fc9.ppc > > cyphesis-selinux-0.5.15-6.fc9.ppc64 > > cyphesis-selinux-0.5.15-6.fc9.x86_64 > > > > > > ====================================================================== > > Broken packages in fedora-9-i686: > > > > callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 requires libpri.so.1.0 > > cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 > > cyphesis-selinux has been merged into the selinux-policy package and is > now obsolete, and has been marked as such by the updated cyphesis-0.5.16 > package. I'm not sure what magic I need to perform to get the broken > deps reports to stop complaining about it. Fix your package. Your "Obsoletes" is not high enough. 0.5.15-6.fc9 > 0.5.15-6 From a.badger at gmail.com Thu Jul 31 00:02:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jul 2008 17:02:13 -0700 Subject: Slight change in how cvs notifications work In-Reply-To: <20080731013113.f24e1646.mschwendt@gmail.com> References: <48896E7F.9040003@gmail.com> <20080730210611.10a6b8d2.mschwendt@gmail.com> <4890CF52.8010705@gmail.com> <200807302308.03120.opensource@till.name> <4890EB28.2040208@gmail.com> <20080731013113.f24e1646.mschwendt@gmail.com> Message-ID: <48910105.2050206@gmail.com> Michael Schwendt wrote: > On Wed, 30 Jul 2008 15:28:56 -0700, Toshio Kuratomi wrote: > >> Till Maas wrote: >>> On Wed July 30 2008, Toshio Kuratomi wrote: >>> >>>> What is the criteria for having a watch* acl? Should everything that >>>> can send a notification have a separate acl? Should automated reports >>>> like broken deps and fails to rebuild from source? If there's a line, >>>> what are the criteria for determining which things fall to one side of >>>> the line or the other? Phrased more specifically, why do you want to >>>> have watchbugzilla, watchupdates, watchcommits, watchbuilds? What makes >>>> those four different from other watch* acls? >>> Watchbugzilla is imho also interesting for people who only want to triage bugs >>> that belong to one package, but are not interested in maintaining them. For >>> testers watchbugzilla and -updates /-builds would be useful, but they may not >>> be interested in the scm commits. For maintainers that maintain a pacakge >>> that depends on another, the watch(updates,builds) can be enough that they >>> need to know, because they may not care about bug reports for the package and >>> cvs commits. Also upstream of a package might be interested to use >>> watchbugzilla for the package in Fedora, but not in the other watch >>> possibilities. >>> >> So let me phrase this again: >> >> "Hi Toshio, I'd like to have a watch*acl for people to sign up to >> receive notices when their package doesn't have complete deps satisfied >> from within the repository." >> >> What criteria do I apply to this request to determine if I should create >> an acl for this request or tell them to use an existing acl? > > Hmmm? What "existing acl" would that be? Somebody asks you for a way to > monitor broken deps reports. What communication "channel" are those > reports posted through? Let's say, for Rawhide. To "package owners"? Is > that equal to the list of e-mail addresses in bugzilla assigned to and Cc > fields? > > Surely, when somebody wants to subscribe to a specific channel only, > it must be an entirely new watch* acl. Or else you would want the > person to subscribe to watchbugzilla in order to receive broken deps > reports *and* lots of bugzilla mail. > > Broken deps can only be fixed by somebody with scm commit access. > Mailing those people is one option. Is that possible already? > I mean, not just with the new %{name}-owner addresses, but also for > EPEL? Can the "commit" acl per pkg name be retrieved? > But if such reports are sent to commits acl, it cannot be > subscribed to. :) > > OTOH, it might be that the report is python-bugzilla'ed automatically, and > in that case only the watchbugzilla people learn about the broken dep. > It could also be that they are flooded with bugzilla spam, however, > or that those with commit permission don't watchbugzilla. ;) > > Or it's a report about a broken dep because of a test update. In that > case, a special QA monkey might want to stop the test update and give > it -1 karma in bodhi and possibly take further action. > > A week later you're asked for a way to monitor "broken upgrade path" > notifications and "bad pkg urls" reports. > > *Conclusively*, it sounds like a a new watch* acl is needed in such > cases. It can be "on" by default for all package maintainers and > be opt-in for other people. > To summarize, if I'm asked for a new watch* acl I should create it . Is that correct? -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 gilboad at gmail.com Thu Jul 31 05:26:40 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 31 Jul 2008 08:26:40 +0300 Subject: kdebluetooth4... update? new review? In-Reply-To: References: <1217434172.816.18.camel@gilboa-work-dev.localdomain> Message-ID: <9050516b0807302226h22c796f2h4f3c26c2c2bbad2d@mail.gmail.com> On Wed, Jul 30, 2008 at 8:06 PM, Rex Dieter wrote: > Gilboa Davara wrote: > >> Hello all, >> >> I'm maintaining the kdebluetooth package. >> While working under F8/KDE3.5, the package is hopelessly broken under >> F9/KDE4. (Due to various reasons; not all of them fixable). >> Luckily for me, mere minutes before I was about to orphan/EOL it (due to >> upstream's early death), the kdebluetooth team woke up and released a >> new version, kdebluetooth4 (QT4/KDE4) which is an early alpha release. >> (v0.1) >> >> Two questions: >> A. Does major version bump require a new review? > > (imo) not required. > >> B. Should I push an early alpha as an update that obsoletes an existing, >> yet broken package? > > probably isn't any worse than the status quo, so yeah. any ideas of a > release schedule? > > -- Rex I'm a bit swamped (work-wise), but hopefully this weekend. - Gilboa From dev at nigelj.com Thu Jul 31 06:26:47 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 31 Jul 2008 18:26:47 +1200 Subject: Outage Notification - 2008-07-31 03:30 UTC to 2008-07-31 06:20 UTC Message-ID: <48915B27.4060500@nigelj.com> An unplanned outage occurred at approximately 2008-07-31 03:30 UTC and is mostly resolved as of 2008-07-31 06:20 UTC Affected Services where: - Websites - Package DB, Mirror Manager Admin Interface, Bodhi, Translate - Account System (FAS) - Any other authenticated requests - Buildsystem Partial Outages: - Hosted (Trac authentication) - Wiki (Read Only, some pages may appear broken as well) Unaffected Services: - CVS / Source Control - Database - DNS - Mail - Torrent - Fedora Talk Reason for Outage: Our main filer took a turn for the worst, and took down one of our main database servers and other associated infrastructure. We have now for the most part resolved the issue, and diagnostic work has begun, we apologise for any inconvenience. Ticket Information: More information will be made available to https://fedorahosted.org/fedora-infrastructure/ticket/735 when it comes to hand. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. Regards, Nigel Jones _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jamatos at fc.up.pt Thu Jul 31 07:23:00 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 31 Jul 2008 08:23:00 +0100 Subject: kdebluetooth4... update? new review? In-Reply-To: <9050516b0807302226h22c796f2h4f3c26c2c2bbad2d@mail.gmail.com> References: <1217434172.816.18.camel@gilboa-work-dev.localdomain> <9050516b0807302226h22c796f2h4f3c26c2c2bbad2d@mail.gmail.com> Message-ID: <200807310823.02996.jamatos@fc.up.pt> On Thursday 31 July 2008 06:26:40 Gilboa Davara wrote: > I'm a bit swamped (work-wise), but hopefully this weekend. While not pretending to know Rex's thought I suspect that he meant the schedule for a stable release of the project itself not about the release in Fedora. :-) > - Gilboa -- Jos? Ab?lio From hughsient at gmail.com Thu Jul 31 07:54:15 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 31 Jul 2008 08:54:15 +0100 Subject: repoquery question Message-ID: <1217490855.3514.31.camel@hughsie-work> Anyone got any ideas why this fails (as user and root)? repoquery --arch=src --whatrequires unique-devel I want to update the version of unique in fedora rawhide, and need to know what's building against the old version of the library. Thanks. Richard. From ivazqueznet at gmail.com Thu Jul 31 08:12:30 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 31 Jul 2008 04:12:30 -0400 Subject: repoquery question In-Reply-To: <1217490855.3514.31.camel@hughsie-work> References: <1217490855.3514.31.camel@hughsie-work> Message-ID: <1217491950.31053.36.camel@ignacio.lan> On Thu, 2008-07-31 at 08:54 +0100, Richard Hughes wrote: > Anyone got any ideas why this fails (as user and root)? > > repoquery --arch=src --whatrequires unique-devel > > I want to update the version of unique in fedora rawhide, and need to > know what's building against the old version of the library. repoquery --enablerepo=\*-source --arch=src --whatrequires unique-devel -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twaugh at redhat.com Thu Jul 31 08:14:25 2008 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 31 Jul 2008 09:14:25 +0100 Subject: strace trap tool needed? In-Reply-To: <1216943321.3547.16.camel@choeger6> References: <1216943321.3547.16.camel@choeger6> Message-ID: <1217492065.4203.12.camel@cyberelk.elk> On Fri, 2008-07-25 at 01:48 +0200, Christoph H?ger wrote: > a little tool came up to my mind today: How about the possibility to > strace a given binary upon execution and write the output to some file? [...] > Does anyone else need such a tool? Yes! Being able to do this for CUPS backends and filters (for example) would be invaluable. > If so, what package could collect it, and what constraints (language, > i/o, etc.) should it comply with? Don't know. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Thu Jul 31 08:30:23 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 31 Jul 2008 09:30:23 +0100 Subject: repoquery question In-Reply-To: <1217491950.31053.36.camel@ignacio.lan> References: <1217490855.3514.31.camel@hughsie-work> <1217491950.31053.36.camel@ignacio.lan> Message-ID: <1217493023.3514.63.camel@hughsie-work> On Thu, 2008-07-31 at 04:12 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-07-31 at 08:54 +0100, Richard Hughes wrote: > > I want to update the version of unique in fedora rawhide, and need to > > know what's building against the old version of the library. > > repoquery --enablerepo=\*-source --arch=src --whatrequires unique-devel Legend, that worked. Somebody probably wants to update http://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks with that bit. Thanks again. Richard. From aph at redhat.com Thu Jul 31 08:35:19 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Jul 2008 09:35:19 +0100 Subject: Calling on Fedora/RedHat ML managers to clean up Fedora-list. In-Reply-To: <1217452153.7387.31.camel@localhost> References: <9050516b0807272128v5e1f680cg2857d7e0ece8c33c@mail.gmail.com> <20080728054052.GA6648@localhost.localdomain> <20080728102615.GC26801@devserv.devel.redhat.com> <200807281330.32526.dex.mbox@gmail.com> <488DC536.30302@redhat.com> <48903183.2070406@redhat.com> <1217452153.7387.31.camel@localhost> Message-ID: <48917947.6040909@redhat.com> Callum Lerwick wrote: > On Wed, 2008-07-30 at 10:16 +0100, Andrew Haley wrote: >> Some people really don't want to see any discussion of the political/ >> ethical issues around free software, I suppose, and what it banished >> to a list they don't have to read. > > Nice straw man. It's not so much a straw man as a guess: I genuinely don't understand the problem, so I can only speculate. > Some of us have have been involved in the FLOSS community for some time. > Some of us settled our ideological positions decades ago, and have more > productive things to do than suffer through the same old Frequently > Waged Flamewars over and over again every time someone new comes along. > > It's not that we don't care. Its that your radical ideas about the > ethics of Free Software have already occurred to other people. *My* radical ideas? Now there's a straw man! > (...Who are much more eloquent, diplomatic and productive than you are.) Huh? Baffled, Andrew. From rawhide at fedoraproject.org Thu Jul 31 08:44:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 31 Jul 2008 08:44:45 +0000 (UTC) Subject: rawhide report: 20080731 changes Message-ID: <20080731084445.75EEF209E4E@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080730/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080731/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package inadyn-mt Dynamic DNS Client New package perl-Filesys-Df Perl extension for filesystem disk space information New package pyroom PyRoom is a full screen text editor and a clone of Writeroom Updated Packages: ConsoleKit-0.3.0-1.fc10 ----------------------- * Wed Jul 30 18:00:00 2008 Jon McCann - 0.3.0-1 - Update to 0.3.0 MAKEDEV-3.23-5 -------------- * Mon Jun 16 18:00:00 2008 Jesse Keating - 3.23-5 - Make sure we have getent installed for our %pre section. OpenIPMI-2.0.14-2.fc10 ---------------------- * Wed Jul 30 18:00:00 2008 Phil Knirsch - 2.0.14-2 - Fixed rpath problem in libOpenIPMIposix.so.0.0.1 PackageKit-0.2.4-1.fc10 ----------------------- * Wed Jul 30 18:00:00 2008 Richard Hughes - 0.2.4-1 - New upstream version, only bugfixes. * Tue Jul 15 18:00:00 2008 Richard Hughes - 0.2.3-6 - Silence the output of update-mime-database to fix rh#454782 * Mon Jun 23 18:00:00 2008 Richard Hughes - 0.2.3-5.20080618 - Own the /etc/bash_completion.d directory as we don't depend on the bash-completion package. Fixes rh#450964. VLGothic-fonts-20080624-1.fc10 ------------------------------ * Thu Jul 31 18:00:00 2008 Jens Petersen - 20080624-1.fc10 - update to 20080624 release akonadi-1.0.0-3.fc10 -------------------- * Wed Jul 30 18:00:00 2008 Rex Dieter 1.0.0-3 - Requires: mysql-server * Wed Jul 30 18:00:00 2008 Rex Dieter 1.0.0-2 - BR: mysql-server - Requires: qt-mysql - cleanup spec anaconda-11.4.1.23-1 -------------------- * Wed Jul 30 18:00:00 2008 Chris Lumens - 11.4.1.23-1 - Fix mke2fs argument passing (#457285). (clumens) - Disable logging in the firmware loader, since it clobbers other log messages. (pjones) * Wed Jul 30 18:00:00 2008 Chris Lumens - 11.4.1.22-1 - udevsettle takes forever, so display a waitWindow. (clumens) - Leave anaconda-runtime around for mk-images run. (dcantrell) * Tue Jul 29 18:00:00 2008 Jeremy Katz - 11.4.1.21-1 - Remove an instance of NEEDGR still existing to fix graphical isolinux (#457144) (katzj) - use newer mke2fs arguments for different filesystems (sandeen) - Use attributes to tell us whether filesystems are bootable (#457037). (clumens) - Make sure we drag in gzip, used by the image creation stuff. (jkeating) asterisk-1.6.0-0.21.beta9.fc10 ------------------------------ * Wed Jul 30 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.21.beta9 - Replace app_rxfax/app_txfax with app_fax taken from upstream SVN. bacula-2.2.8-2.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Andreas Thienemann - 2.2.8-2 - Fixed %{fedora} comparision, making bacula-sqlite build on rawhide * Fri Jul 25 18:00:00 2008 Jon Ciesla - 2.2.8-1 - Update to 2.2.8. BZ 446461. - Dropped director and storage DB-server hard Reqs. BZ 426788. - .desktop fixes. BZ 450278, 426789. - Updated config patch. - Dropped wxconsole patch, applied upstream. - Updated pamd patch. - Dropped ampm patch, applied upstream. - Dropped maxbyteslist patch, N/A. - Dropped maxwaittime patch, applied upstream. - Dropped scheduler-next-hour patch, applied upstream. - Dropped verify patch, applied upstream. - Dropped tls-disconnect patch, applied upstream. - Fix for 426791. - Introduced patch fuzz workaround, will fix. * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 2.0.3-14 - fix conditional comparison - fix license tag banshee-1.2.0-2.1.fc10 ---------------------- * Thu Jul 31 18:00:00 2008 Nigel Jones - 1.2.0-2.1 - ifarching foo broke... now fixed * Wed Jul 30 18:00:00 2008 Nigel Jones - 1.2.0-2 - Reenable boo, I can't see why not now... * Wed Jul 30 18:00:00 2008 Nigel Jones - 1.2.0-1 - Update to 1.2.0 (new upstream release) - Refer to: http://banshee-project.org/download/archives/1.2.0/ for more details callweaver-1.2.0.1-1.1.fc10 --------------------------- * Wed Jul 30 18:00:00 2008 Jeffrey C. Ollie - 1.2.0.1-1.1 - Package manpage again. * Wed Jul 30 18:00:00 2008 Jeffrey C. Ollie - 1.2.0.1-1 - Update to release 1.2.0.1 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.2-0.5.rc5.20071230 - Autorebuild for GCC 4.3 checkgmail-1.13-3.svn20080730.fc10 ---------------------------------- * Wed Jul 30 18:00:00 2008 Rahul Sundaram - 1.13-3.svn20080730 - Pull svn snapshot date * Wed Jul 30 18:00:00 2008 Rahul Sundaram - 1.13-3.svn20080630 - Pull svn snapshot to fix auth issue clive-0.4.20-1.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Nicoleau Fabien 0.4.20-1 - rebuild for 0.4.20 - licence is now GPLv3+ cyphesis-0.5.16-2.fc10 ---------------------- * Wed Jul 30 18:00:00 2008 Wart 0.5.16-2 - Increase version in Obsoletes: for cyphesis-selinux deskbar-applet-2.23.5-1.fc10 ---------------------------- * Wed Jul 30 18:00:00 2008 Luke Macken - 2.23.5-1 - Latest upstream release of the 2.23.x branch * Thu Jul 17 18:00:00 2008 Luke Macken - 2.23.4-1 - Latest upstream release of the 2.23.x branch dialog-1.1-6.20080727.fc10 -------------------------- * Wed Jul 30 18:00:00 2008 Miroslav Lichvar - 1.1-6.20080727 - update to 1.1-20080727 ecryptfs-utils-53-0.fc10 ------------------------ * Wed Jul 30 18:00:00 2008 Eric Sandeen 53-0 - New upstream version - Many new manpages, new ecryptfs-stat util elice-0.289-1.fc10 ------------------ * Wed Jul 30 18:00:00 2008 Hans de Goede 0.289-1 - New upstream release 0.289 emacs-vm-8.0.10.575-1.fc10 -------------------------- * Wed Jul 30 18:00:00 2008 Jonathan G. Underwood - 8.0.10.575-1 - Update to version 8.0.10-575 - Update BuildRoot to preferred mktemp variant freeradius-2.0.5-2.fc10 ----------------------- * Wed Jul 30 18:00:00 2008 John Dennis - 2.0.5-2 - Resolves: bug #453761: FreeRADIUS %post should not include chown -R specify file attributes for /etc/raddb/ldap.attrmap fix consistent use of tabs/spaces (rpmlint warning) gazpacho-0.7.2-3.fc10 --------------------- * Wed Jul 30 18:00:00 2008 Konstantin Ryabitsev - 0.7.2-3 - Small fixes (#440859) - Include egg-info (#440859) - Remove X-Fedora from desktop file categories gdm-2.23.2-1.fc10 ----------------- * Wed Jul 30 18:00:00 2008 Jon McCann - 1:2.23.2-1 - Update to 2.23.2 gnome-packagekit-0.2.4-1.fc10 ----------------------------- * Wed Jul 30 18:00:00 2008 Richard Hughes - 0.2.4-1 - New upstream version, only bugfixes. gnome-session-2.23.6-0.2008.07.30.1.fc10 ---------------------------------------- * Wed Jul 30 18:00:00 2008 Jon McCann - 2.23.6.0.2008.07.30.1 - New snapshot from DBus branch gstreamer-plugins-good-0.10.8-10.fc10 ------------------------------------- * Wed Jul 30 18:00:00 2008 - Bastien Nocera 0.10.8-10 - Build the docs ourselves gts-0.7.6-11.fc10 ----------------- * Wed Jul 30 18:00:00 2008 Ralf Cors??pius - 0.7.6-11 - Let *-devel Require: glib2-devel (BZ: 457099). - Pass LIBS=-lm to %configure (avoid non-weak refs to libm). - Add gts-0.7.6-hacks.diff (Various configuration fixes). - Add gts-0.7.6-autotools.diff (regenerate autotool-generated files). - Add %check. * Fri May 23 18:00:00 2008 Jon Stanley - 0.7.6-10 - Fix license tag hedgewars-0.9.6-1.fc10 ---------------------- * Wed Jul 30 18:00:00 2008 Hans de Goede 0.9.6-1 - New upstream release 0.9.6 hippo-canvas-0.3.0-2.fc10 ------------------------- * Sun Jul 6 18:00:00 2008 Owen Taylor - 0.3.0-2 - Update to 0.3.0 (adds SVG support) ipsec-tools-0.7.1-2.fc10 ------------------------ * Wed Jul 30 18:00:00 2008 Tomas Mraz - 0.7.1-2 - Different approach to allow racoon to add loopback SAs for labeled IPSec (without ISAKMP) jd-2.0.1-0.1.svn2244_trunk.fc10 ------------------------------- * Thu Jul 31 18:00:00 2008 Mamoru Tasaka - rev. 2244 kde-settings-4.0-25.fc10 ------------------------ * Wed Jul 30 18:00:00 2008 Rex Dieter 4.0-25 - kcminputrc: [Mouse] cursorTheme=default kdelibs-4.1.0-3.fc10 -------------------- * Wed Jul 30 18:00:00 2008 Rex Dieter 4.1.0-3 - (Build)Requires: soprano(-devel) >= 2.1 libcanberra-0.5-4.fc10 ---------------------- libsoup-2.23.1-6.fc10 --------------------- * Wed Jul 30 18:00:00 2008 Matthew Barnes - 2.23.1-6 - Omit unused direct shared library dependencies (RH bug #226046). lostlabyrinth-3.0.2-1.fc10 -------------------------- * Wed Jul 30 18:00:00 2008 Hans de Goede 3.0.2-1 - New upstream release 3.0.2 mkinitrd-6.0.56-1.fc10 ---------------------- * Tue Jul 29 18:00:00 2008 Peter Jones - 6.0.56-1 - Move a bunch of functions to /usr/libexec/initrd-functions so so that plymouth-populate-initrd can use it instead of duplicating them. - Change how we're calling plymouth for password UI mugshot-1.2.2-1.fc10 -------------------- * Wed Jul 30 18:00:00 2008 Owen Taylor - 1.2.2-1 - Update to 1.2.2 - Fixes Firefox min version to 3.0.x, #451918 again - Rebuild against hippo-canvas-0.3 newt-0.52.10-1.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Miroslav Lichvar - 0.52.10-1 - improve --noitem description (#456305) - add setHeight to Textbox class - fix fixedheight forms - free keymap in newtFinished() - fix memory leak in textbox - fix valgrind error in checkboxtree - don't crash when running empty form - don't crash or hang when form has no focusable elements - before checkboxtree drawing return first item in GetCurrent() - redraw textbox in SetText() - add setColor description to SnackScreen docstring (Greg Swift) - make sure Widget isn't used directly (Greg Swift) (#452920) - add Serbian translations (Milo?? Komar??evi??) - add Balochi translation (Mostafa Daneshvar) perl-Frontier-RPC-0.07b4-4.fc10 ------------------------------- perl-MailTools-2.04-1.fc10 -------------------------- * Wed Jul 30 18:00:00 2008 Paul Howarth 2.04-1 - Update to 2.04 pigment-python-0.3.5-1.fc10 --------------------------- * Tue Jul 29 18:00:00 2008 Matthias Saou 0.3.5-1 - Update to 0.3.5. plymouth-0.5.0-6.fc10 --------------------- * Wed Jul 30 18:00:00 2008 Ray Strode - 0.5.0-6 - Add nash requires qmmp-0.2.0-1.fc10 ----------------- * Wed Jul 30 18:00:00 2008 Karel Volny 0.2.0-1 - new version - updated %description to match upstream - added BuildRequires: libsndfile-devel wavpack-devel pulseaudio-libs-devel - added BuildRequires: libmodplug-devel libcurl-devel openssl-devel - xpm icon is not used anymore (several pngs available) - created devel subpackage * Mon May 19 18:00:00 2008 Karel Volny 0.1.6-2 - fixed %description not to include patent-encumbered formats (bug #447141) * Tue May 13 18:00:00 2008 Karel Volny 0.1.6-1 - new version redhat-lsb-3.1-21.fc10 ---------------------- * Fri Jul 31 18:00:00 2009 Lawrence Lim - 3.1-21 - remove symlink for mailx (Bug #457241) * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.1-20 - Autorebuild for GCC 4.3 ruby-mechanize-0.7.7-1.fc10 --------------------------- * Thu Jul 31 18:00:00 2008 Mamoru Tasaka - 0.7.7-1 - 0.7.7 sbcl-1.0.19-1.fc10 ------------------ * Wed Jul 30 18:00:00 2008 Rex Dieter - 1.0.19-1 - sbcl-1.0.19 * Thu May 29 18:00:00 2008 Rex Dieter - 1.0.17-3 - info removal should be done in %preun (#448933) - omit ppc only on f9+ (#448734) selinux-policy-3.5.1-4.fc10 --------------------------- smb4k-0.9.6-1.fc10 ------------------ * Wed Jul 30 18:00:00 2008 Marcin Garski 0.9.6-1 - Update to 0.9.6 spandsp-0.0.5-0.1.pre4.fc10 --------------------------- splat-1.2.3-1.fc10 ------------------ * Wed Jul 30 18:00:00 2008 Steve Conklin - 1.2.3-1 - New upstream - added delivery of postdownload script and the new bearing utility - added man pages for bearing and postdownload swfdec-0.7.4-1.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Brian Pepple - 0.7.4-1 - Update to 0.7.4. swfdec-gnome-2.23.2-1.fc10 -------------------------- * Wed Jul 30 18:00:00 2008 Brian Pepple - 2.23.2-1 - Update to 2.23.2. - Drop configure patch. Fixed upstream. swfdec-mozilla-0.7.4-1.fc10 --------------------------- * Wed Jul 30 18:00:00 2008 Brian Pepple - 0.7.4-1 - Update to 0.7.4. xterm-236-1.fc10 ---------------- * Wed Jul 30 18:00:00 2008 Miroslav Lichvar 236-1 - update to 236 - enable support for spawn-new-terminal action (#457130) Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 54 Broken deps for i386 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) maxima-runtime-sbcl-5.15.0-1.fc10.i386 requires sbcl = 0:1.0.17 perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so sobby-0.4.4-4.fc10.i386 requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.i386 requires librpmio-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.i386 requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.i386 requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.x86_64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.i386 requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.x86_64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.i386 requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.x86_64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) maxima-runtime-sbcl-5.15.0-1.fc10.x86_64 requires sbcl = 0:1.0.17 perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) sobby-0.4.4-4.fc10.x86_64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc requires librpmdb-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpm-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc requires librpmio-4.4.so apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 fuse-encfs-1.4.2-2.fc10.ppc requires librlog.so.1 fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc requires gecko-libs = 0:1.9 gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so sobby-0.4.4-4.fc10.ppc requires libobby-0.4.so.0 synaptic-0.57.2-16.fc9.ppc requires librpmio-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpmdb-4.4.so synaptic-0.57.2-16.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpm-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmdb-4.4.so()(64bit) apt-0.5.15lorg3.94-3.fc9.ppc64 requires librpmio-4.4.so()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) fuse-encfs-1.4.2-2.fc10.ppc64 requires librlog.so.1()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave gtkmozembedmm-1.4.2.cvs20060817-20.fc9.ppc64 requires gecko-libs = 0:1.9 highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) livecd-tools-017.1-1.fc9.ppc64 requires yaboot perl-Catalyst-Devel-1.07-1.fc10.noarch requires perl(Catalyst::Manual) >= 0:5.7000 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sobby-0.4.4-4.fc10.ppc64 requires libobby-0.4.so.0()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmdb-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpmio-4.4.so()(64bit) synaptic-0.57.2-16.fc9.ppc64 requires librpm-4.4.so()(64bit) From pingou at pingoured.fr Thu Jul 31 08:50:59 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Thu, 31 Jul 2008 10:50:59 +0200 Subject: rawhide report: 20080731 changes In-Reply-To: <20080731084445.75EEF209E4E@releng1.fedora.phx.redhat.com> References: <20080731084445.75EEF209E4E@releng1.fedora.phx.redhat.com> Message-ID: <48917CF3.60406@pingoured.fr> Rawhide wrote: > libcanberra-0.5-4.fc10 > ---------------------- > perl-Frontier-RPC-0.07b4-4.fc10 > ------------------------------- > selinux-policy-3.5.1-4.fc10 > --------------------------- > spandsp-0.0.5-0.1.pre4.fc10 > --------------------------- That's not a lot of changes... Has something gone wrong somewhere ?? Regards, Pierre From hughsient at gmail.com Thu Jul 31 08:42:20 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 31 Jul 2008 09:42:20 +0100 Subject: heads up: breaking ABI for libunique Message-ID: <1217493740.3514.70.camel@hughsie-work> Unique in rawhide 1.0.0 breaks ABI with 0.9.4: * Thu Jul 31 2008 Richard Hughes - 1.0.0-1 - Update to latest upstream version * First stable release * API is frozen * D-Bus and socket backends supported The only thing this affects in rawhide is gnome-packagekit and gnome-power-manager, which I'll tag and chain build now. I'll update unique in F9 in a few weeks (if there are no problems in rawhide) as there are a couple of nice bugfixes. Richard. From caolanm at redhat.com Thu Jul 31 09:14:24 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 31 Jul 2008 10:14:24 +0100 Subject: java, possible to package the gcj aot stuff separately ? Message-ID: <1217495664.18789.144.camel@vain.rhgalway> Given that we've got openjdk on most platforms. Would it make sense to package our java things so that the gcj ahead-of-time compiled stuff is packaged into separate subrpms. e.g. taking hsqldb as a random example the package takes 3696k but the aot /usr/lib/gcj/hsqldb contents takes 2928k of that and it's unused except for the java-is-gij case right ? We typically end up with openjdk installed due to the web plugin and then with java-1.5.0-gcj + dependencies installed due to the /usr/bin/rebuild-gcj-db and .so requires of the java packaging guidelines when installing any additional java package. I'd like to e.g. have the option of just having openjdk installed and not have to haul around the 45Megs in my /usr/lib/gcj dir C. From aph at redhat.com Thu Jul 31 09:20:21 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Jul 2008 10:20:21 +0100 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: <1217495664.18789.144.camel@vain.rhgalway> References: <1217495664.18789.144.camel@vain.rhgalway> Message-ID: <489183D5.3000304@redhat.com> Caolan McNamara wrote: > Given that we've got openjdk on most platforms. Would it make sense to > package our java things so that the gcj ahead-of-time compiled stuff is > packaged into separate subrpms. e.g. taking hsqldb as a random example > the package takes 3696k but the aot /usr/lib/gcj/hsqldb contents takes > 2928k of that and it's unused except for the java-is-gij case right ? > > We typically end up with openjdk installed due to the web plugin and > then with java-1.5.0-gcj + dependencies installed due to > the /usr/bin/rebuild-gcj-db and .so requires of the java packaging > guidelines when installing any additional java package. > > I'd like to e.g. have the option of just having openjdk installed and > not have to haul around the 45Megs in my /usr/lib/gcj dir Sure, but it's potentially a lot of work to make the change, and how would the people who are running gcj know that they need to download the gcj ahead-of-time compiled stuff to get decent performance? Andrew. From j.w.r.degoede at hhs.nl Thu Jul 31 10:09:31 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 31 Jul 2008 12:09:31 +0200 Subject: Looking for someone to pull / manage Games Spin for F-10 Message-ID: <48918F5B.8010006@hhs.nl> Hi All, I know most of us (fedora-games-list subscribers) have grown from game packagers to contributors also doing more "serious" Fedora work. Still Games are fun and having good Games support in Fedora is important and I know we are all still working hard to keep our game packages in top notch state. Given that we have all these top notch state game packages its really a shame that we've not done a Games Spin for F-9, and we might miss the boat for F-10 too. So I'm looking for someone to pull and coordinate the efforts needed to get a Games Spin for F-10, as always I'm willing to help but: http://fedoraproject.org/wiki/Features/BetterWebcamSupport Is taking almost all my time so I have no time to take the lead on this one, so any takers? The first task would be to fill in the details of: https://fedoraproject.org/wiki/Features/GamesSpin And ask for the spin to be approved. Thanks & Regards, Hans From stickster at gmail.com Thu Jul 31 12:01:41 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 31 Jul 2008 12:01:41 +0000 Subject: Broken dependencies in Fedora 8 - 2008-07-31 In-Reply-To: <20080730235114.11220.72874@faldor.intranet> References: <20080730235114.11220.72874@faldor.intranet> Message-ID: <1217505701.12970.11.camel@victoria> On Wed, 2008-07-30 at 23:51 +0000, Michael Schwendt wrote: > ianweller AT gmail.com > mediawiki-HNP-1.1.2-1.fc8.noarch > mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch > mediawiki-StubManager-1.2.0-1.fc8.noarch > python-mwlib-0.8.0-2.fc8.i386 > python-mwlib-0.8.0-2.fc8.ppc > python-mwlib-0.8.0-2.fc8.ppc64 > python-mwlib-0.8.0-2.fc8.x86_64 I fixed python-mwlib this morning; updates are in testing in bodhi for F-8 (and F-9 to keep the upgrade path clean). -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu Jul 31 12:07:17 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 31 Jul 2008 08:07:17 -0400 Subject: repoquery question In-Reply-To: <1217493023.3514.63.camel@hughsie-work> References: <1217490855.3514.31.camel@hughsie-work> <1217491950.31053.36.camel@ignacio.lan> <1217493023.3514.63.camel@hughsie-work> Message-ID: <1217506037.12970.15.camel@victoria> On Thu, 2008-07-31 at 09:30 +0100, Richard Hughes wrote: > On Thu, 2008-07-31 at 04:12 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2008-07-31 at 08:54 +0100, Richard Hughes wrote: > > > I want to update the version of unique in fedora rawhide, and need to > > > know what's building against the old version of the library. > > > > repoquery --enablerepo=\*-source --arch=src --whatrequires unique-devel > > Legend, that worked. Somebody probably wants to update > http://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks with > that bit. Done: https://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks#Application_binary_interface_changes -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Thu Jul 31 12:22:44 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 31 Jul 2008 07:22:44 -0500 Subject: rawhide report: 20080731 changes In-Reply-To: <48917CF3.60406@pingoured.fr> References: <20080731084445.75EEF209E4E@releng1.fedora.phx.redhat.com> <48917CF3.60406@pingoured.fr> Message-ID: <935ead450807310522r4943894dic13a281608113635@mail.gmail.com> On Thu, Jul 31, 2008 at 3:50 AM, Pierre-Yves wrote: > Rawhide wrote: > >> spandsp-0.0.5-0.1.pre4.fc10 >> --------------------------- > > That's not a lot of changes... > > Has something gone wrong somewhere ?? In the case of spandsp I forgot to update the changelog before issuing the build. I updated the changelog in CVS but I didn't think that it was important enough to issue a new build. Jeff From overholt at redhat.com Thu Jul 31 12:40:45 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 31 Jul 2008 08:40:45 -0400 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: <489183D5.3000304@redhat.com> References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> Message-ID: <20080731124045.GB16851@redhat.com> * Andrew Haley [2008-07-31 05:20]: > Caolan McNamara wrote: > > Given that we've got openjdk on most platforms. Would it make sense to > > package our java things so that the gcj ahead-of-time compiled stuff is > > packaged into separate subrpms. e.g. taking hsqldb as a random example > > the package takes 3696k but the aot /usr/lib/gcj/hsqldb contents takes > > 2928k of that and it's unused except for the java-is-gij case right ? > > > > We typically end up with openjdk installed due to the web plugin and > > then with java-1.5.0-gcj + dependencies installed due to > > the /usr/bin/rebuild-gcj-db and .so requires of the java packaging > > guidelines when installing any additional java package. > > > > I'd like to e.g. have the option of just having openjdk installed and > > not have to haul around the 45Megs in my /usr/lib/gcj dir > > Sure, but it's potentially a lot of work to make the change, and how > would the people who are running gcj know that they need to download > the gcj ahead-of-time compiled stuff to get decent performance? Yeah, one of the reasons we didn't do this to begin with was because RPM has no notion of Suggests or Recommends like dpkg does. Debian went this route, but I've seen reports of people not realizing they needed to install the associated -gcj package. Andrew From aph at redhat.com Thu Jul 31 12:44:20 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Jul 2008 13:44:20 +0100 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: <20080731124045.GB16851@redhat.com> References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> <20080731124045.GB16851@redhat.com> Message-ID: <4891B3A4.5080800@redhat.com> Andrew Overholt wrote: > * Andrew Haley [2008-07-31 05:20]: >> Caolan McNamara wrote: >>> Given that we've got openjdk on most platforms. Would it make sense to >>> package our java things so that the gcj ahead-of-time compiled stuff is >>> packaged into separate subrpms. e.g. taking hsqldb as a random example >>> the package takes 3696k but the aot /usr/lib/gcj/hsqldb contents takes >>> 2928k of that and it's unused except for the java-is-gij case right ? >>> >>> We typically end up with openjdk installed due to the web plugin and >>> then with java-1.5.0-gcj + dependencies installed due to >>> the /usr/bin/rebuild-gcj-db and .so requires of the java packaging >>> guidelines when installing any additional java package. >>> >>> I'd like to e.g. have the option of just having openjdk installed and >>> not have to haul around the 45Megs in my /usr/lib/gcj dir >> Sure, but it's potentially a lot of work to make the change, and how >> would the people who are running gcj know that they need to download >> the gcj ahead-of-time compiled stuff to get decent performance? > > Yeah, one of the reasons we didn't do this to begin with was because RPM > has no notion of Suggests or Recommends like dpkg does. Debian went > this route, but I've seen reports of people not realizing they needed to > install the associated -gcj package. Me too. "My Eclipse is godawful slow," etc... Andrew. From kanarip at kanarip.com Thu Jul 31 12:46:00 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 31 Jul 2008 14:46:00 +0200 Subject: Pungi as CD installer build tool In-Reply-To: <46a038f90807291532l2c062491h776c6a16a4d4d03a@mail.gmail.com> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> <488F8E96.1080404@nobugconsulting.ro> <46a038f90807291532l2c062491h776c6a16a4d4d03a@mail.gmail.com> Message-ID: <4891B408.3010903@kanarip.com> Martin Langhoff wrote: > On Wed, Jul 30, 2008 at 9:41 AM, Manuel Wolfshant > wrote: >> On 07/30/2008 12:30 AM, Jesse Keating wrote: >>> There is reviser, not sure if it landed in F7 timeframe. It puts a gui >>> on top of things, has some of it's own code for the things that pungi >>> does, although it does use bits and parts of pungi. >>> >> s/reviser/revisor/ :) > > I've looked at revisor on F9 but it seems to be geared to build a > livecd. Or can it build regular installer ISOs? > I can safely say that it builds regular installer ISOs, irregular installer ISOs, as well as installer ISOs that do not work if you change any random number the available settings involved without knowing what it is you're changing, as far as Fedora 9's Revisor (2.1.1) is concerned. The defaults, certainly on Fedora 7, *just build* a workable ISO. Same goes for Fedora 8. For the Revisor version in Fedora 7 (2.0.5 iirc); it just works. No extremely difficult settings for particular use-cases involved either. You might be better off composing Fedora 7 using Fedora 8 and the available Revisor package there though. And yes, Revisor does cross-compose between versions of distributions. Kind regards, Jeroen van Meeuwen -kanarip From promac at gmail.com Thu Jul 31 12:48:31 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 31 Jul 2008 09:48:31 -0300 Subject: Does your app use LIRC? In-Reply-To: <1217441497.5809.20.camel@cookie.hadess.net> References: <1217441497.5809.20.camel@cookie.hadess.net> Message-ID: <68720af30807310548q8854e0fhb8893875c750b7b9@mail.gmail.com> On Wed, Jul 30, 2008 at 3:11 PM, Bastien Nocera wrote: > If your app uses liblirc_client, it would be nice if you could follow > the instructions, and the two examples at: > https://fedoraproject.org/wiki/Features/BetterLIRCSupport#User_Experience > > to make your application work out-of-the-box in Fedora 10. > > Elisa, Totem and Rhythmbox are already fixed. > > I'd have had a nice list using repoquery, but it just seems to hang > there doing nothing (and then gives me useless answers, might just be > me...). > > Let me know if you have any questions about the setup. > > Hi, I tried it on F8. I had to upgrade PolicyKit-0.8-2.fc8.x86_64.rpm PolicyKit-devel-0.8-2.fc8.x86_64.rpm PolicyKit-docs-0.8-2.fc8.x86_64.rpm PolicyKit-gnome-0.8-4.fc8.x86_64.rpm PolicyKit-gnome-demo-0.8-4.fc8.x86_64.rpm PolicyKit-gnome-devel-0.8-4.fc8.x86_64.rpm PolicyKit-gnome-libs-0.8-4.fc8.x86_64.rpm before installing gnome-lirc-properties-0.2.5-1.fc8.noarch.rpm I also used lirc from CVS (the newest version I could get). When I rebooted and run /usr/bin/gnome-lirc-properties, I got: ............... WARNING:root:/usr/share/doc/lirc-0.8.4/remotes/: Remote DVICO_MCE listed twice in dvico/lircd.conf.fusionHDTV and dvico/lircd.conf.fusionHDTV. WARNING:root:/usr/share/doc/lirc-0.8.4/remotes/: Remote PVR2000 listed twice in leadtek/lircd.conf.PVR2000 and leadtek/lircd.conf.PVR2000. WARNING:root:/usr/share/doc/lirc-0.8.4/remotes/: Remote BESTBUY listed twice in bestbuy/lircd.conf.bestbuy2 and bestbuy/lircd.conf.bestbuy. Traceback (most recent call last): File "/usr/bin/gnome-lirc-properties", line 27, in gnome_lirc_properties.run(sys.argv[1:], datadir) File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/__init__.py", line 57, in run return ui.RemoteControlProperties(gtk.glade.XML(ui_filename)).run() File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/ui/RemoteControlProperties.py", line 55, in __init__ self.__restore_hardware_settings() File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/ui/RemoteControlProperties.py", line 218, in __restore_hardware_settings settings = lirc.HardwareConfParser(config.LIRC_HARDWARE_CONF) File "/usr/lib/python2.5/site-packages/gnome_lirc_properties/lirc.py", line 950, in __init__ key, value = tokens ValueError: too many values to unpack Any clue? -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Thu Jul 31 13:00:32 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 31 Jul 2008 15:00:32 +0200 Subject: Pungi as CD installer build tool In-Reply-To: <1217367010.3151.87.camel@localhost.localdomain> References: <46a038f90807290001t530eb92cnc2877b6962cd6f96@mail.gmail.com> <1217350744.3151.60.camel@localhost.localdomain> <46a038f90807291406q2699d713o1e1c1e3a9bc9f1ba@mail.gmail.com> <1217367010.3151.87.camel@localhost.localdomain> Message-ID: <4891B770.70603@kanarip.com> Jesse Keating wrote: > On Wed, 2008-07-30 at 09:06 +1200, Martin Langhoff wrote: >> Are there other good alternatives I should be considering? > > There is reviser, not sure if it landed in F7 timeframe. It puts a gui > on top of things, has some of it's own code for the things that pungi > does, although it does use bits and parts of pungi. > It landed on FUDCon Boston, February, 2007, ~1.5 months after pungi and livecd-tools were initially announced, and -at the time- still in full development. Just to set the record straight, Revisor had a CLI right from the beginning as well. Right now, that CLI is way more powerful then you'd want to get any users involved with. What you do with the Revisor GUI only gets you so far, what you *can* do with the Revisor CLI might very well confuse you initially. Not to mention the configuration options which are not exposed as CLI parameters. There's no limit to what it can do, and enabling use-cases like yours is Revisor's target. So, if you find anything in the compose process that just doesn't work for you, let me know. Most of the documentation is on http://fedorahosted.org/revisor/wiki -Jeroen From walters at verbum.org Thu Jul 31 13:29:19 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 31 Jul 2008 09:29:19 -0400 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: <20080731124045.GB16851@redhat.com> References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> <20080731124045.GB16851@redhat.com> Message-ID: On Thu, Jul 31, 2008 at 8:40 AM, Andrew Overholt wrote: > > > Yeah, one of the reasons we didn't do this to begin with was because RPM > has no notion of Suggests or Recommends like dpkg does. Debian went > this route, but I've seen reports of people not realizing they needed to > install the associated -gcj package. > I think the long term vision here should be that we actually need *both* AOT and JIT compilation. We need a JIT because many apps will continue to load code at runtime from sources that are not Fedora. Think unpackaged Eclipse plugins for just a start. But with OpenJDK, when I sit there at a Jython toplevel experimenting with code, it's pretty cool that it's actually getting JITted down to native code as it runs. There are also applications that actually generate bytecode at runtime for various purposes, and that continues to be a good idea. A JIT also has a lot more interesting information than a normal AOT model. Hotspot does a lot of cool things there. However, one approach is to take a set of runtime profiles from applications, and feed that back into the compiler: http://gcc.gnu.org/news/profiledriven.html As far as I know in Fedora right now we are not taking advantage of runtime profiles when we compile things in Koji. I heard though that Firefox can get up to a 10% speedup by being compiled with the right data; see: http://developer.mozilla.org/en/docs/Building_with_Profile-Guided_Optimization It does make sense to have AOT compilation, because having Hotspot re-profile and recompile the Eclipse core on everyone's computer is a bit of a waste. One approach here would be to modify Hotspot so that it can pick up "precompiled" code fragments shipped in a lookaside cache, based on its own runtime profiling data. I'm not sure if anyone has looked into that. But it's not as simple as saying that AOT is always fast and JIT is always slow - it really can be the opposite, and AOT compilation for everything can be a waste of space if the library is not in a performance critical path. -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Thu Jul 31 13:55:03 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 31 Jul 2008 09:55:03 -0400 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> <20080731124045.GB16851@redhat.com> Message-ID: Just to follow up on this because I think it's interesting =) One possible utopian future is thus: o Modify Koji to create profile-gathering versions of some targeted applications like Firefox; this would be a separate repository with packages of the same name o Have a yum plugin that allows you to replace your installed packages with the profiler-compiled packages o When you enable this plugin, Hotspot also goes into "dump profile information" mode o A new Fedora server where people can post the data from their profiled packages and Hotspot logs o Teach Koji to pull the data from this server and compile the software using it To do this it might help if we only had one code generation backend for both GCC and Hotspot that understood how to process the profiling data - a long term vision on that would be to move to GCC-LLVM and Hotspot's Shark work. This infrastructure would also help us make the decision which Java software makes sense to AOT compile versus not, rather than creating -precompiled versions of all packages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prieheck at iwu.edu Thu Jul 31 14:03:08 2008 From: prieheck at iwu.edu (Pat Riehecky) Date: Thu, 31 Jul 2008 09:03:08 -0500 Subject: Any chance for a tighter /etc/ structure? Message-ID: <1217512988.14884.95.camel@thales.iwu.edu> Please accept my apology for how long this is, in the end it is effectively a feature request (or perhaps a packing ''issue'')... it just takes a while to get there. After installing a typical RHEL/Fedora server a non privileged user has access to read all sorts of files that, while not terribly dangerous, they have no need to read and could, under some not at all extraordinary circumstances, disclose some more sensitive data. I know in a good part of the server world user's simply are not a valid concern. However, I would be surprised if any Unix based shop didn't have at least one server where users could ssh in and put files down. For example a standard user can read just about everything in /etc/samba, like the smbusers file which maps unix users to smb users. The big picture in this file is that it maps root to Administrator. This is something that we expect, but disclosing it seems in error. A security minded admin may change the mapping, but, since there is never a case where a non uid 0 process would need to read the file (samba runs as root), the permissions may never be tightened down. There is also the /etc/samba/smb.conf file which is world readable. A wealth of information that should never be given to users is in this file, as an admin I would expect this file to be not world readable by default. No one needs to read it but me, so I shouldn't share it with them. How about /etc/httpd/* I have a personal hosting account at a server farm where I can read everything in that directory. A quick check of the /etc/httpd/conf/httpd.conf tells me the name of every site hosted on this box. /home/37462614 doesn't tell me who this is, but a simple poke about in apache tells me all sorts of things. Like in this user's home they have a .ht_passwords file with customer access rights. A file that I can cat if I want and compromise their privacy. A file I must be able to cat because of the apache permissions. A file I would never have found if I hadn't been able to read the httpd.conf file. The httpd.conf file that as a non-root user, I never have a reason to read. The /etc/yum files are also world readable, knowing who is and is not a trusted software provider is just not something non-root users should need to know. The SNMP config file (/etc/snmp/snmpd.conf) is world readable by default. Disclosing this information to a non-administrative user is not a good idea. Supposing I enable SNMP writes. Giving any user access to this file after SNMP writes are enabled is rather bad. Chmoding it root only isn't listed in the documentation. Doesn't it seem a little strange that this is not automatically handled by the RPM on installation. Edits to the file will preserve the umask, and therefore retained. The 99% use case for snmpd is to only allow administrative users access to this file. The defaults apply to the 1% case where something else is at work. I wish to challenge this choice. Not just for SNMP but for every file and directory in /etc/. I would love for a secure configuration by default. seLinux is installed by default, the mandatory access control there is excellent, but there is no reason to have to rely on it when for 90% of the files in /etc/ a simple chmod will secure the files reasonably well. I realize one of the first reactions will be to let seLinux take care of it. SeLinux is great at this task, but it seems like pushing the burden entirely into seLinux is hiding the oddity I am pointing out. Suppose I had /etc/httpd/ recursively set to 2777 by default. This is obviously bad, but due to seLinux enforcement the apache process would not be able to modify /etc/httpd/ files, but wouldn't it make more sense to chmod things differently in the RPM? I realize that write access and random sticky bits are far greater than just a world read bit, but just because you can do something with seLinux doesn't mean it is the best way to do it. The list of random files in /etc/ could go on for a long while, but I would ask that a part of the packaging process going forward would be to evaluate the default permissions on all files packaged in /etc/ and decide if any of the world bits should be set. Allowing anything on the system to read files in /etc/ is not a good idea. I know seLinux, when it is enforcing, prevents a lot of this disclosure, but users are currently unconfined in the default RHEL5/Fedora9 and many admins (not myself, but it is still a sizable group) turn off seLinux. In security classes they stress having many lines of defense, setting good permissions by default seems a great place to start, just a serious outlay of work and a large bit of time. I know confined users is coming, but there are times I must put seLinux into Permissive mode. And confined users is not here yet. With the complexity of confining users I would not be the slightest bit shocked if it took a few more years to happen. Getting /etc/ locked down a bit tighter will help demonstrate that RHEL/Fedora is not only secure with seLinux running, but rather that seLinux is an extension of the security focus you expect to see from an Enterprise Linux provider. That even in non seLinux environments the system takes precautions about what data should and should not be given to non-root users. May I request that a step be added to the packaging process? A step where the world read bits are evaluated for validity. Obviously evaluating past packages is a ridiculous idea, but perhaps for the next release of Fedora any packages that start coming in could have this request attached to them. Pat From lsof at nodata.co.uk Thu Jul 31 14:59:57 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 31 Jul 2008 16:59:57 +0200 Subject: Any chance for a tighter /etc/ structure? In-Reply-To: <1217512988.14884.95.camel@thales.iwu.edu> References: <1217512988.14884.95.camel@thales.iwu.edu> Message-ID: <1217516397.12862.2.camel@sb-home> Am Donnerstag, den 31.07.2008, 09:03 -0500 schrieb Pat Riehecky: > Please accept my apology for how long this is, in the end it is > effectively a feature request (or perhaps a packing ''issue'')... it > just takes a while to get there. > > After installing a typical RHEL/Fedora server a non privileged user has > access to read all sorts of files that, while not terribly dangerous, > they have no need to read and could, under some not at all extraordinary > circumstances, disclose some more sensitive data. I know in a good part > of the server world user's simply are not a valid concern. However, I > would be surprised if any Unix based shop didn't have at least one > server where users could ssh in and put files down. > > For example a standard user can read just about everything > in /etc/samba, like the smbusers file which maps unix users to smb > users. The big picture in this file is that it maps root to > Administrator. This is something that we expect, but disclosing it > seems in error. A security minded admin may change the mapping, but, > since there is never a case where a non uid 0 process would need to read > the file (samba runs as root), the permissions may never be tightened > down. > There is also the /etc/samba/smb.conf file which is world readable. A > wealth of information that should never be given to users is in this > file, as an admin I would expect this file to be not world readable by > default. No one needs to read it but me, so I shouldn't share it with > them. > How about /etc/httpd/* I have a personal hosting account at a server > farm where I can read everything in that directory. A quick check of > the /etc/httpd/conf/httpd.conf tells me the name of every site hosted on > this box. /home/37462614 doesn't tell me who this is, but a simple poke > about in apache tells me all sorts of things. Like in this user's home > they have a .ht_passwords file with customer access rights. A file that > I can cat if I want and compromise their privacy. A file I must be able > to cat because of the apache permissions. A file I would never have > found if I hadn't been able to read the httpd.conf file. The httpd.conf > file that as a non-root user, I never have a reason to read. > The /etc/yum files are also world readable, knowing who is and is not a > trusted software provider is just not something non-root users should > need to know. > The SNMP config file (/etc/snmp/snmpd.conf) is world readable by > default. Disclosing this information to a non-administrative user is > not a good idea. Supposing I enable SNMP writes. Giving any user > access to this file after SNMP writes are enabled is rather bad. > Chmoding it root only isn't listed in the documentation. Doesn't it > seem a little strange that this is not automatically handled by the RPM > on installation. Edits to the file will preserve the umask, and > therefore retained. The 99% use case for snmpd is to only allow > administrative users access to this file. The defaults apply to the 1% > case where something else is at work. > I wish to challenge this choice. Not just for SNMP but for every file > and directory in /etc/. I would love for a secure configuration by > default. seLinux is installed by default, the mandatory access control > there is excellent, but there is no reason to have to rely on it when > for 90% of the files in /etc/ a simple chmod will secure the files > reasonably well. > > I realize one of the first reactions will be to let seLinux take care of > it. SeLinux is great at this task, but it seems like pushing the burden > entirely into seLinux is hiding the oddity I am pointing out. Suppose I > had /etc/httpd/ recursively set to 2777 by default. This is obviously > bad, but due to seLinux enforcement the apache process would not be able > to modify /etc/httpd/ files, but wouldn't it make more sense to chmod > things differently in the RPM? I realize that write access and random > sticky bits are far greater than just a world read bit, but just because > you can do something with seLinux doesn't mean it is the best way to do > it. > > The list of random files in /etc/ could go on for a long while, but I > would ask that a part of the packaging process going forward would be to > evaluate the default permissions on all files packaged in /etc/ and > decide if any of the world bits should be set. Allowing anything on the > system to read files in /etc/ is not a good idea. I know seLinux, when > it is enforcing, prevents a lot of this disclosure, but users are > currently unconfined in the default RHEL5/Fedora9 and many admins (not > myself, but it is still a sizable group) turn off seLinux. In security > classes they stress having many lines of defense, setting good > permissions by default seems a great place to start, just a serious > outlay of work and a large bit of time. > > I know confined users is coming, but there are times I must put seLinux > into Permissive mode. And confined users is not here yet. With the > complexity of confining users I would not be the slightest bit shocked > if it took a few more years to happen. Getting /etc/ locked down a bit > tighter will help demonstrate that RHEL/Fedora is not only secure with > seLinux running, but rather that seLinux is an extension of the security > focus you expect to see from an Enterprise Linux provider. That even in > non seLinux environments the system takes precautions about what data > should and should not be given to non-root users. > > May I request that a step be added to the packaging process? A step > where the world read bits are evaluated for validity. Obviously > evaluating past packages is a ridiculous idea, but perhaps for the next > release of Fedora any packages that start coming in could have this > request attached to them. > > Pat > Apart from the snmpd.conf permissions, which surely must be a bug, the rest of your long message seems like an argument for security by obscurity. Is it? From poelstra at redhat.com Thu Jul 31 14:56:47 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 31 Jul 2008 07:56:47 -0700 Subject: [Fwd: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 7:00 PM EST] Message-ID: <4891D2AF.90909@redhat.com> Reminder: This Weekend -------- Original Message -------- Subject: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 7:00 PM EST Date: Tue, 29 Jul 2008 00:05:42 -0400 From: Dave Lawrence O U T A G E R E Q U E S T F O R M ===================================== Severity: Severity Two (High) Scheduled Date: August 2nd, 2008 Scheduled Time: 9:00 AM EST - 7:00 PM EST Estimated Time Required: 10 hours Performed By: Red Hat Engineering Operations People/Groups Impacted: Users of bugzilla.redhat.com and any services that rely on bugzilla.redhat.com Site/Services Affected: bugzilla.redhat.com Web UI, Database, XMLRPC Impact: bugzilla.redhat.com will be unavailable during the posted time on August 2nd, 2008. Description: On August 2nd, bugzilla.redhat.com will go down for an update to the latest upstream code base. During this time the web servers will be reinstalled with the latest OS updates as well as the latest Bugzilla code. Also the database servers will undergo a data migration to be made compatible with the latest Bugzilla code. The web UI, database, and all XMLRPC services will be unavailable during the migration. Services that rely on bugzilla.redhat.com may not function properly during this time so please let your users know about the outage as well. Also please take time to point your services/scripts at our test server https://partner-bugzilla.redhat.com to make sure that they will still work with the new system once it goes live. Care has been taken to make the new system backwards compatible as much as possible with the old XMLRPC API but still confirm that they work properly. If you encounter any problems, please contact bugzilla-owner redhat com or file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.2 Signoff: kbaker redhat com _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mbarnes at redhat.com Thu Jul 31 15:03:56 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Thu, 31 Jul 2008 11:03:56 -0400 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? Message-ID: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> The OLPC guys are asking me to split the Python bindings for libgnome and libgnomeui into a new subpackage of gnome-python2 called gnome-python2-gnome (see [1]). The rationale being that libgnome drags in extra dependencies that some of the other gnome-python2 subpackages don't need. For example, gnome-python2-gnomevfs doesn't need libgnome but still requires its parent package, gnome-python2. This sounds like a reasonable idea to me but it will break other packages that require gnome-python2 expecting to get the libgnome[ui] bindings. Those packages would have to require gnome-python2-gnome instead. Possibly affected packages include: audit-viewer autobuild-applet awn-extras-applets blogtk decibel-audio-player deskbar-applet fwbackups gjots2 gnome-password-generator gnome-python2-desktop gnome-python2-extras gourmet gramps hamster-applet hwbrowser listen meld policycoreutils-gui qa-assistant rhythmbox setroubleshoot system-config-bind system-config-cluster system-config-httpd system-config-lvm system-config-netboot system-config-network system-config-printer wallpapoz Any objections or alternate suggestions? Thank, Matthew Barnes [1] http://bugzilla.redhat.com/show_bug.cgi?id=456122 From kevin.kofler at chello.at Thu Jul 31 15:04:40 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 31 Jul 2008 15:04:40 +0000 (UTC) Subject: Any chance for a tighter /etc/ structure? References: <1217512988.14884.95.camel@thales.iwu.edu> Message-ID: Pat Riehecky iwu.edu> writes: > about in apache tells me all sorts of things. Like in this user's home > they have a .ht_passwords file with customer access rights. A file that > I can cat if I want and compromise their privacy. A file I must be able > to cat because of the apache permissions. A file I would never have > found if I hadn't been able to read the httpd.conf file. The httpd.conf > file that as a non-root user, I never have a reason to read. Sure, the /etc permissions are more open than necessary, but here the .ht_passwords file's permissions are the actual problem. There are plenty of ways to make files readable to Apache without making them world-readable: * use groups: make a group for each hosted site containing only the user(s) allowed to modify the site and apache, then chown the file theuser:thegroup and make it 640. * use setfacl (requires filesystem support, ext3 supports it): chmod 600 .ht_passwords setfacl -m u:apache:r .ht_passwords Kevin Kofler From twaugh at redhat.com Thu Jul 31 15:09:28 2008 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 31 Jul 2008 16:09:28 +0100 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> Message-ID: <1217516968.25365.1.camel@cyberelk.elk> On Thu, 2008-07-31 at 11:03 -0400, Matthew Barnes wrote: > Possibly affected packages include: > > system-config-printer Not affected by these. It only uses gnome.url_show. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dsd at laptop.org Thu Jul 31 15:39:29 2008 From: dsd at laptop.org (Daniel Drake) Date: Thu, 31 Jul 2008 11:39:29 -0400 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217516968.25365.1.camel@cyberelk.elk> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <1217516968.25365.1.camel@cyberelk.elk> Message-ID: <1217518769.2688.3.camel@olpc-desktop01.laptop.org> On Thu, 2008-07-31 at 16:09 +0100, Tim Waugh wrote: > On Thu, 2008-07-31 at 11:03 -0400, Matthew Barnes wrote: > > Possibly affected packages include: > > > > system-config-printer > > Not affected by these. It only uses gnome.url_show. gnome.url show is a binding to libgnome's gnome_url_show. So the dependencies would have to be updated to depend on gnome-python2-gnome. Daniel From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 31 16:07:07 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 01 Aug 2008 01:07:07 +0900 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> Message-ID: <4891E32B.7060507@ioa.s.u-tokyo.ac.jp> Matthew Barnes wrote, at 08/01/2008 12:03 AM +9:00: > The OLPC guys are asking me to split the Python bindings for libgnome > and libgnomeui into a new subpackage of gnome-python2 called > gnome-python2-gnome (see [1]). The rationale being that libgnome drags > in extra dependencies that some of the other gnome-python2 subpackages > don't need. For example, gnome-python2-gnomevfs doesn't need libgnome > but still requires its parent package, gnome-python2. > > This sounds like a reasonable idea to me but it will break other > packages that require gnome-python2 expecting to get the libgnome[ui] > bindings. Those packages would have to require gnome-python2-gnome > instead. > > Possibly affected packages include: > wallpapoz > > Any objections or alternate suggestions? I maintain wallpapoz and as far as I am correct wallpapoz is also affected: wallpapoz uses gnome.PARAM_APP_DATADIR gnome.program_init gnome.help_display Instead, if OLPC members wants to use only non-binding part, would you consider to create gnome-python2-base (for example) and to make gnome-python2 depend on gnome-python2-base? Regards, Mamoru From lsof at nodata.co.uk Thu Jul 31 16:10:02 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 31 Jul 2008 18:10:02 +0200 Subject: Any chance for a tighter /etc/ structure? In-Reply-To: References: <1217512988.14884.95.camel@thales.iwu.edu> Message-ID: <1217520602.17911.0.camel@sb-home> Am Donnerstag, den 31.07.2008, 15:04 +0000 schrieb Kevin Kofler: > Pat Riehecky iwu.edu> writes: > > about in apache tells me all sorts of things. Like in this user's home > > they have a .ht_passwords file with customer access rights. A file that > > I can cat if I want and compromise their privacy. A file I must be able > > to cat because of the apache permissions. A file I would never have > > found if I hadn't been able to read the httpd.conf file. The httpd.conf > > file that as a non-root user, I never have a reason to read. > > Sure, the /etc permissions are more open than necessary, but here > the .ht_passwords file's permissions are the actual problem. There are plenty > of ways to make files readable to Apache without making them world-readable: > * use groups: make a group for each hosted site containing only the user(s) > allowed to modify the site and apache, then chown the file theuser:thegroup and > make it 640. > * use setfacl (requires filesystem support, ext3 supports it): > chmod 600 .ht_passwords > setfacl -m u:apache:r .ht_passwords > > Kevin Kofler But any user who can run scripts on the server as the apache user can still read the files.. unless you only use php, and you try to prevent it with safe mode or similar. From stlwrt at gmail.com Thu Jul 31 16:21:30 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 31 Jul 2008 19:21:30 +0300 Subject: Any chance for a tighter /etc/ structure? In-Reply-To: <1217520602.17911.0.camel@sb-home> References: <1217512988.14884.95.camel@thales.iwu.edu> <1217520602.17911.0.camel@sb-home> Message-ID: > But any user who can run scripts on the server as the apache user can > still read the files.. unless you only use php, and you try to prevent > it with safe mode or similar. Both php and apache cgi interface have tools to run scripts as unprivileged user -- http://scwlab.com From twaugh at redhat.com Thu Jul 31 16:28:30 2008 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 31 Jul 2008 17:28:30 +0100 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217518769.2688.3.camel@olpc-desktop01.laptop.org> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <1217516968.25365.1.camel@cyberelk.elk> <1217518769.2688.3.camel@olpc-desktop01.laptop.org> Message-ID: <1217521710.25365.10.camel@cyberelk.elk> On Thu, 2008-07-31 at 11:39 -0400, Daniel Drake wrote: > gnome.url show is a binding to libgnome's gnome_url_show. So the > dependencies would have to be updated to depend on gnome-python2-gnome. Ah, I misunderstood the original email. Thanks for correcting me. [Aside: I'm been wondering for a while about this GNOME dependency in system-config-printer, but don't know of a good replacement for gnome.url_show.] Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Thu Jul 31 16:31:03 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 31 Jul 2008 12:31:03 -0400 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217521710.25365.10.camel@cyberelk.elk> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <1217516968.25365.1.camel@cyberelk.elk> <1217518769.2688.3.camel@olpc-desktop01.laptop.org> <1217521710.25365.10.camel@cyberelk.elk> Message-ID: <1217521863.25656.1.camel@localhost.localdomain> On Thu, 2008-07-31 at 17:28 +0100, Tim Waugh wrote: > On Thu, 2008-07-31 at 11:39 -0400, Daniel Drake wrote: > > gnome.url show is a binding to libgnome's gnome_url_show. So the > > dependencies would have to be updated to depend on gnome-python2-gnome. > > Ah, I misunderstood the original email. Thanks for correcting me. > > [Aside: I'm been wondering for a while about this GNOME dependency in > system-config-printer, but don't know of a good replacement for > gnome.url_show.] The gtk in rawhide has gtk_show_uri, which is a good replacement. From rjones at redhat.com Thu Jul 31 16:44:42 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 31 Jul 2008 17:44:42 +0100 Subject: Anyone seeing serious network breakage in current Rawhide? Message-ID: <20080731164442.GA14056@amd.home.annexia.org> Just rebooted into a fully up to date Rawhide, and I'm experiencing really odd network-related problems. For example, ssh & scp work fine. HTTP is totally broken: most web pages time out (either in DNS or during page load), but occasionally I can get a whole webpage. Tested this in all of Firefox, Seamonkey and w3m, so I'm fairly sure it's not just a broken Firefox. I seem to have excluded local factors, such as the router and network connection itself, since other machines in my office work fine. ping is OK with small and large packet sizes. DNS lookups work fine from command line tools (eg. ping, ssh), but fail quite a lot in browsers. Linux thinkpad 2.6.27-0.186.rc0.git15.fc10.i686 #1 SMP Sun Jul 27 05:22:35 EDT 2008 i686 i686 i386 GNU/Linux The network is wireless, using iwl3945 driver, configured by NetworkManager. As far as I'm aware the kernel is untainted and there is no non-free software installed on the machine. Nothing very interesting in dmesg except some oopses in sched_mc_power_savings_store which appear to be unrelated. To be honest, I'm not even sure what to look at next ... 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 twaugh at redhat.com Thu Jul 31 16:50:36 2008 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 31 Jul 2008 17:50:36 +0100 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217521863.25656.1.camel@localhost.localdomain> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <1217516968.25365.1.camel@cyberelk.elk> <1217518769.2688.3.camel@olpc-desktop01.laptop.org> <1217521710.25365.10.camel@cyberelk.elk> <1217521863.25656.1.camel@localhost.localdomain> Message-ID: <1217523036.25365.16.camel@cyberelk.elk> On Thu, 2008-07-31 at 12:31 -0400, Matthias Clasen wrote: > The gtk in rawhide has gtk_show_uri, which is a good replacement. That's great news! Now I just need pygtk to pick it up... Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jul 31 16:58:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 31 Jul 2008 12:58:26 -0400 Subject: Anyone seeing serious network breakage in current Rawhide? In-Reply-To: <20080731164442.GA14056@amd.home.annexia.org> References: <20080731164442.GA14056@amd.home.annexia.org> Message-ID: <20080731165826.GA2614@nostromo.devel.redhat.com> Richard W.M. Jones (rjones at redhat.com) said: > Just rebooted into a fully up to date Rawhide, and I'm experiencing > really odd network-related problems. I noticed this, backed down to an earlier kernel, and everything was fine. Bill From pemboa at gmail.com Thu Jul 31 17:13:05 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 31 Jul 2008 12:13:05 -0500 Subject: What bz component does text-mode install fall under? Message-ID: <16de708d0807311013q1a2130bewba7f9a1b815897d3@mail.gmail.com> Does the text mode install fall under Anacoda as well in bugzilla? I would like to file an RFE to give a warning (or even better an option) that the machine will default to console (as opposed to graphical) mode when doing a text install with instructions on getting to /etc/inittab to fix this. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Thu Jul 31 17:17:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 31 Jul 2008 09:17:46 -0800 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> <20080731124045.GB16851@redhat.com> Message-ID: <604aa7910807311017j724a3c4cl9d089afb9a0311bf@mail.gmail.com> 2008/7/31 Colin Walters : > o Modify Koji to create profile-gathering versions of some targeted > applications like Firefox; this would be a separate repository with packages > of the same name > o Have a yum plugin that allows you to replace your installed packages with > the profiler-compiled packages Another repository.... included in fedora-release package? enabled/disabled by default? -jef From mike at miketc.net Thu Jul 31 17:28:34 2008 From: mike at miketc.net (Mike Chambers) Date: Thu, 31 Jul 2008 12:28:34 -0500 Subject: What bz component does text-mode install fall under? In-Reply-To: <16de708d0807311013q1a2130bewba7f9a1b815897d3@mail.gmail.com> References: <16de708d0807311013q1a2130bewba7f9a1b815897d3@mail.gmail.com> Message-ID: <1217525314.27456.3.camel@scrappy.miketc.net> On Thu, 2008-07-31 at 12:13 -0500, Arthur Pemberton wrote: > Does the text mode install fall under Anacoda as well in bugzilla? > > I would like to file an RFE to give a warning (or even better an > option) that the machine will default to console (as opposed to > graphical) mode when doing a text install with instructions on getting > to /etc/inittab to fix this. Correct, anaconda would be the component to file it against. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From dsd at laptop.org Thu Jul 31 17:33:29 2008 From: dsd at laptop.org (Daniel Drake) Date: Thu, 31 Jul 2008 13:33:29 -0400 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <4891E32B.7060507@ioa.s.u-tokyo.ac.jp> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <4891E32B.7060507@ioa.s.u-tokyo.ac.jp> Message-ID: <1217525609.2688.5.camel@olpc-desktop01.laptop.org> On Fri, 2008-08-01 at 01:07 +0900, Mamoru Tasaka wrote: > Instead, if OLPC members wants to use only non-binding part, would you consider > to create gnome-python2-base (for example) and to make gnome-python2 depend on > gnome-python2-base? That sounds like a good idea. Matthew? From a.badger at gmail.com Thu Jul 31 17:36:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 31 Jul 2008 10:36:33 -0700 Subject: java, possible to package the gcj aot stuff separately ? In-Reply-To: References: <1217495664.18789.144.camel@vain.rhgalway> <489183D5.3000304@redhat.com> <20080731124045.GB16851@redhat.com> Message-ID: <4891F821.20104@gmail.com> Colin Walters wrote: > Just to follow up on this because I think it's interesting =) > > One possible utopian future is thus: > > o Modify Koji to create profile-gathering versions of some targeted > applications like Firefox; this would be a separate repository with > packages of the same name > o Have a yum plugin that allows you to replace your installed packages > with the profiler-compiled packages > o When you enable this plugin, Hotspot also goes into "dump profile > information" mode > o A new Fedora server where people can post the data from their profiled > packages and Hotspot logs > o Teach Koji to pull the data from this server and compile the software > using it > Make sure you flag down some of the koji authors with this idea -- koji will need to grow a method of snapshoting the profiled data when it does a build otherwise it won't be able to satisfy its mission of creating a precisely auditable build. -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 pemboa at gmail.com Thu Jul 31 18:07:56 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 31 Jul 2008 13:07:56 -0500 Subject: What bz component does text-mode install fall under? In-Reply-To: <1217525314.27456.3.camel@scrappy.miketc.net> References: <16de708d0807311013q1a2130bewba7f9a1b815897d3@mail.gmail.com> <1217525314.27456.3.camel@scrappy.miketc.net> Message-ID: <16de708d0807311107r71131be5jc0fcfd7dcce34647@mail.gmail.com> On Thu, Jul 31, 2008 at 12:28 PM, Mike Chambers wrote: > On Thu, 2008-07-31 at 12:13 -0500, Arthur Pemberton wrote: >> Does the text mode install fall under Anacoda as well in bugzilla? >> >> I would like to file an RFE to give a warning (or even better an >> option) that the machine will default to console (as opposed to >> graphical) mode when doing a text install with instructions on getting >> to /etc/inittab to fix this. > > Correct, anaconda would be the component to file it against. > > -- > Mike Chambers > Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. > mikec302 at fedoraproject.org Thanks: https://bugzilla.redhat.com/show_bug.cgi?id=457449 -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From selinux at gmail.com Thu Jul 31 18:32:09 2008 From: selinux at gmail.com (Tom London) Date: Thu, 31 Jul 2008 11:32:09 -0700 Subject: Anyone seeing serious network breakage in current Rawhide? In-Reply-To: <20080731165826.GA2614@nostromo.devel.redhat.com> References: <20080731164442.GA14056@amd.home.annexia.org> <20080731165826.GA2614@nostromo.devel.redhat.com> Message-ID: <4c4ba1530807311132h359f369boef83dbcc293e0ed4@mail.gmail.com> On Thu, Jul 31, 2008 at 9:58 AM, Bill Nottingham wrote: > Richard W.M. Jones (rjones at redhat.com) said: >> Just rebooted into a fully up to date Rawhide, and I'm experiencing >> really odd network-related problems. > > I noticed this, backed down to an earlier kernel, and everything was > fine. > > Bill > I had a similar issue: "curl http://hostname" failing on my Rawhide system with DNS complaints, but "nslookup hostname" would work. Typically, "curl" would time out after 5 seconds, while "nslookup" would succed in less than a tenth of a second. [Alternatively, try "time getent ahosts hostname".] Long BZ report here: https://bugzilla.redhat.com/show_bug.cgi?id=454206 My issue appears to be my ISP's DNS servers not properly handling IPv6 type requests. [Actually, some would work, some wouldn't.] This sound like your issue? tom [Thanks to Ulrich Drepper for all his help on this....] -- Tom London From mbarnes at redhat.com Thu Jul 31 18:53:35 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Thu, 31 Jul 2008 14:53:35 -0400 Subject: Move libgnome[ui] Python bindings to gnome-python2-gnome? In-Reply-To: <1217525609.2688.5.camel@olpc-desktop01.laptop.org> References: <1217516636.3715.12.camel@dhcp-100-2-219.bos.redhat.com> <4891E32B.7060507@ioa.s.u-tokyo.ac.jp> <1217525609.2688.5.camel@olpc-desktop01.laptop.org> Message-ID: <1217530415.24534.15.camel@dhcp-100-2-195.bos.redhat.com> On Thu, 2008-07-31 at 13:33 -0400, Daniel Drake wrote: > On Fri, 2008-08-01 at 01:07 +0900, Mamoru Tasaka wrote: > > Instead, if OLPC members wants to use only non-binding part, would you consider > > to create gnome-python2-base (for example) and to make gnome-python2 depend on > > gnome-python2-base? > > That sounds like a good idea. Matthew? Seems kind of convoluted to me. I'd rather the libgnome[ui] bindings get their own subpackage, same as the other bindings in gnome-python2. I can deal with the one-time hassle of fixing requirements breakage. Matthew Barnes From overholt at redhat.com Thu Jul 31 19:07:30 2008 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 31 Jul 2008 15:07:30 -0400 Subject: Eclipse 3.4 Message-ID: <20080731190729.GB14841@redhat.com> Hi, I've finally got version 3.4 of the Eclipse SDK ready to go, targetting Fedora 10: http://koji.fedoraproject.org/koji/buildinfo?buildID=58121 (See [1] for an in-progress build with some minor fixes.) Action item for plugin package maintainers: ------------------------------------------- Please look at the relevant attached patches and apply them or something like them in the devel directory of your plugin(s). Feel free to commit and tag but note that you won't be able to build until I tag the build for rawhide. Email me personally if you have questions. Please also let me know when you're finished and I can do koji builds of everything in the right order (chain-build or otherwise). I'd like to do this very soon so please take a few minutes to apply the changes. Testing of the above build is greatly appreciated. ------------------------------------------- There are a few minor changes for packagers of plugins/features: - Bits are now installed to %{_libdir}/eclipse instead of %{_datadir}/eclipse. This brings us in line with upstream's file layout and avoids the crazy split-install osgi.sharedConfiguration.area hack. It's also what Debian does, FWIW. - p2 is the new provisioning platform in 3.4. Essentially it replaces the old update manager but does other things as well. It requires Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage them using its "director". In order to avoid fragile %post scriptlets, we're going to use the "dropins mechanism" for plugin installation. This means that all non-Eclipse platform plugins will be installed into their own directory under %{_libdir}/eclipse/dropins. There are a variety of layouts that are acceptable to p2, but we'll largely be going with dropins/eclipse//{plugins,features}. This has the nice side benefit of simplifying %files sections :) . See [2] for more information here. - I added a flag to the pdebuild script to allow for Orbit-style dependencies. If you don't know what this means, that's okay, but if a plugin you want to package uses Orbit dependencies, you'll want to use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but don't have a lib directory with JARs are probably using Orbit-style dependencies. They'll have Require-Bundle or Import-Package entries in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how to use pdebuild in this case. - I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I can't count the number of times people have been confused by this naming and since we're not going to ship swt2 or swt.motif any time soon, the naming is silly. I also folded pde-runtime into pde since PHPEclipse no longer needs the separate pde-runtime package. Outside of the CDT and the SELinux tools (both maintainers are working on the necessary changes themselves), I've got patches for all of the plugins we have as packages in Fedora. I've attached these patches and CC'd all of the maintainers. I will update the packaging guidelines very soon with the above information. Thanks, Andrew [1] Build with branding fixed and removing some unnecessary Requires(post) and the pde-runtime package which is now folded into pde: http://koji.fedoraproject.org/koji/taskinfo?taskID=750696 [2] There are some performance considerations here. Since it's generating the associated metadata and "provisioning" the bits on the fly based on files dropped into a directory, users may notice a slightly longer startup the first time they start the Eclipse IDE after installing a new plugin package. Subsequent startups won't be impacted. There is a lot of performance improvement work going on upstream and much of it will land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in Fedora 10. If not, we can ship it as an update. Should testing between now and Fedora 10 show unacceptably poor performance (I haven't noticed this in my own testing), we can look at back-porting some of the performance work. The other main way of speeding up dropins-installed plugins is by shipping pre-generated p2 metadata (like yum metadata). I've experimented with this and think I can make it so that we transparently generate it via pdebuild meaning it would only require a rebuild of Fedora plugin packages. Things will work without these generated content.xml files so in the interest of getting testing sooner rather than later, I'm going to push ahead without the metadata for dropins. -------------- next part -------------- ? .build-1.2.4-10.fc10.log ? eclipse-subclipse-1.2.4-10.fc10.src.rpm ? noarch ? subclipse-1.2.4 Index: eclipse-subclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-subclipse/devel/eclipse-subclipse.spec,v retrieving revision 1.20 diff -u -r1.20 eclipse-subclipse.spec --- eclipse-subclipse.spec 7 Apr 2008 13:50:59 -0000 1.20 +++ eclipse-subclipse.spec 30 Jul 2008 23:02:20 -0000 @@ -1,9 +1,15 @@ %define gcj_support 1 %define eclipse_name eclipse +%if 0%{?rhel} == 5 %define eclipse_base %{_datadir}/%{eclipse_name} %define core_plugin_jar %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_%{version}.jar %define core_plugin_dir %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_%{version} +%else +%define eclipse_base %{_libdir}/%{eclipse_name} +%define core_plugin_jar %{eclipse_base}/dropins/subclipse/eclipse/plugins/org.tigris.subversion.subclipse.core_%{version}.jar +%define core_plugin_dir %{eclipse_base}/dropins/subclipse/eclipse/plugins/org.tigris.subversion.subclipse.core_%{version} +%endif %define disable_javahl 0 %if 0%{?fedora} == 6 @@ -20,7 +26,7 @@ Name: eclipse-subclipse Version: 1.2.4 -Release: 9%{?dist} +Release: 10%{?dist} Summary: Subversion Eclipse plugin Group: Text Editors/Integrated Development Environments (IDE) @@ -116,13 +122,10 @@ # --------------------------------- # building subclipse pushd subclipse +%if 0%{?rhel} == 5 # See comments in the script to understand this. # RHEL eclipse has a different instalation root -%if 0%{?rhel} == 5 /bin/sh -x %{_libdir}/%{eclipse_name}/buildscripts/copy-platform SDK %{eclipse_base} -%else -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} -%endif SDK=$(cd SDK > /dev/null && pwd) # Eclipse may try to write to the home directory. @@ -171,6 +174,10 @@ # -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ # -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml +%else +%{eclipse_base}/buildscripts/pdebuild -f org.tigris.subversion.subclipse +%{eclipse_base}/buildscripts/pdebuild -f org.tigris.subversion.book +%endif # returning to base build directory popd @@ -185,12 +192,23 @@ %install rm -rf $RPM_BUILD_ROOT +%if 0%{?rhel} == 5 install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base} - pushd subclipse unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. build/rpmBuild/org.tigris.subversion.subclipse.zip unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. build/rpmBuild/org.tigris.subversion.book.zip +popd +%else +installDir=$RPM_BUILD_ROOT%{eclipse_base}/dropins/subclipse +install -d -m 755 $installDir +install -d -m 755 ${installDir}-book +pushd subclipse +unzip -q -d $installDir build/rpmBuild/org.tigris.subversion.subclipse.zip +unzip -q -d ${installDir}-book build/rpmBuild/org.tigris.subversion.book.zip +popd +%endif +pushd subclipse # repacking core plugin as a directory based plugin, needed in order to replace some jars with symlinks mkdir $RPM_BUILD_ROOT%{core_plugin_dir} unzip -q -d $RPM_BUILD_ROOT%{core_plugin_dir} $RPM_BUILD_ROOT%{core_plugin_jar} @@ -198,22 +216,23 @@ # packaging .class files as a jar file jar -cf $RPM_BUILD_ROOT%{core_plugin_dir}/lib/subclipse-core.jar -C $RPM_BUILD_ROOT%{core_plugin_dir} org rm -rf $RPM_BUILD_ROOT%{core_plugin_dir}/org +popd # removing core plugin internal jars rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnjavahl.jar rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnkit.jar rm -f $RPM_BUILD_ROOT%{core_plugin_dir}/lib/ganymed.jar -%if %{gcj_support} - aot-compile-rpm -%endif - # We need to setup the symlink because the ant copy task doesn't preserve symlinks # TODO file a bug about this ln -s %{javahl_dir}/svn-javahl.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnjavahl.jar ln -s %{_javadir}/svnkit.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/svnkit.jar ln -s %{_javadir}/ganymed-ssh2.jar $RPM_BUILD_ROOT%{core_plugin_dir}/lib/ganymed.jar +%if %{gcj_support} + aot-compile-rpm +%endif + %clean rm -rf $RPM_BUILD_ROOT @@ -225,10 +244,14 @@ %files %defattr(-,root,root) +%if 0%{?rhel} == 5 %{eclipse_base}/features/org.tigris.subversion.subclipse_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.core_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.ui_* %{eclipse_base}/plugins/org.tigris.subversion.subclipse.doc_* +%else +%{eclipse_base}/dropins/subclipse +%endif %doc svnClientAdapter/readme.txt svnClientAdapter/changelog.txt svnClientAdapter/license.txt %if %{gcj_support} @@ -237,10 +260,17 @@ %files book %defattr(-,root,root) +%if 0%{?rhel} == 5 %{eclipse_base}/features/org.tigris.subversion.book_* %{eclipse_base}/plugins/org.tigris.subversion.book_* +%else +%{eclipse_base}/dropins/subclipse-book +%endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1.2.4-10 +- Update for Eclipse SDK 3.4 + * Fri Apr 04 2008 Robert Marcano 1.2.4-9 - Fix Bug 440818: changed links to svn-javahl.jar -------------- next part -------------- ? .build-0.4.0-2.fc10.log ? specfile-editor-fetched-src-18653 Index: eclipse-rpm-editor.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-rpm-editor/devel/eclipse-rpm-editor.spec,v retrieving revision 1.17 diff -u -r1.17 eclipse-rpm-editor.spec --- eclipse-rpm-editor.spec 29 Jun 2008 14:12:39 -0000 1.17 +++ eclipse-rpm-editor.spec 30 Jul 2008 22:59:17 -0000 @@ -1,10 +1,10 @@ %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define svn_rev 18653 Name: eclipse-rpm-editor Version: 0.4.0 -Release: 1%{?dist} +Release: 2%{?dist} Summary: RPM Specfile editor for Eclipse Group: Development/Tools License: EPL @@ -23,9 +23,6 @@ %else BuildRequires: java-devel >= 1.5.0 %endif -%if ! %{gcj_support} -BuildArch: noarch -%endif BuildRequires: eclipse-pde >= 1:3.3.0 BuildRequires: eclipse-changelog >= 2.5.1 Requires: eclipse-platform >= 3.3.1 @@ -57,8 +54,9 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. \ +installDir=%{buildroot}%{eclipse_base}/dropins/rpm-editor +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/org.eclipse.linuxtools.rpm.ui.editor.zip %if %{gcj_support} @@ -84,18 +82,19 @@ %files %defattr(-,root,root,-) -%{eclipse_base}/plugins/org.eclipse.linuxtools.rpm.ui.editor_*.jar -%{eclipse_base}/plugins/org.eclipse.linuxtools.rpm.rpmlint_*.jar -%dir %{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/ -%doc %{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.html -%{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.xml -%{eclipse_base}/features/org.eclipse.linuxtools.rpm.ui.editor_*/*.properties +%doc org.eclipse.linuxtools.rpm.ui.editor-feature/*.html +%{eclipse_base}/dropins/rpm-editor %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/org.eclipse.linuxtools.rpm.* %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.4.0-2 +- Update for Eclipse SDK 3.4 +- Remove noarch potential since CDT is arch-specific and we + ExclusiveArch + * Wed Jun 29 2008 Alphonse Van Assche 0.4.0-1 - bump to 0.4.0 -------------- next part -------------- ? .build-1.2.0-0.3.svn1573.fc10.log ? eclipse-phpeclipse-1.2.0-0.3.svn1573.fc10.src.rpm ? noarch ? phpeclipse-1.2.0 Index: eclipse-phpeclipse.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-phpeclipse/devel/eclipse-phpeclipse.spec,v retrieving revision 1.6 diff -u -r1.6 eclipse-phpeclipse.spec --- eclipse-phpeclipse.spec 29 Jun 2008 18:30:45 -0000 1.6 +++ eclipse-phpeclipse.spec 30 Jul 2008 22:58:50 -0000 @@ -1,9 +1,9 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 Name: eclipse-phpeclipse Version: 1.2.0 -Release: 0.2.svn1573%{?dist} +Release: 0.3.svn1573%{?dist} Summary: PHP Eclipse plugin Group: Development/Tools License: CPL @@ -96,14 +96,15 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.feature.zip -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.debug.feature.zip -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/net.sourceforge.phpeclipse.xdebug.feature.zip +installDir=%{buildroot}%{eclipse_base}/dropins/phpeclipse +install -d -m 755 $installDir +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.feature.zip +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.debug.feature.zip +unzip -q -d $installDir build/rpmBuild/net.sourceforge.phpeclipse.xdebug.feature.zip # need to recreate the symlinks to libraries that were setup in "prep" # because for some reason the ant copy task doesn't preserve them -pushd %{buildroot}%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* +pushd $installDir/eclipse/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* rm *.jar build-jar-repository -s -p . xml-commons-apis popd @@ -122,37 +123,16 @@ %files %defattr(-,root,root,-) -%doc %{eclipse_base}/features/net.sourceforge.phpeclipse.feature_*/cpl-v10.html - -# main feature -%{eclipse_base}/features/net.sourceforge.phpeclipse.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.externaltools_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.help_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phphelp_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.phpmanual.htmlparser_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.smarty.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.webbrowser_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xml.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xml.ui_* - -# debug features -%{eclipse_base}/features/net.sourceforge.phpeclipse.debug.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.debug.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.debug.ui_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.launching_* -%{eclipse_base}/features/net.sourceforge.phpeclipse.xdebug.feature_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xdebug.core_* -%{eclipse_base}/plugins/net.sourceforge.phpeclipse.xdebug.ui_* - +%doc net.sourceforge.phpeclipse.feature/cpl-v10.html +%{eclipse_base}/dropins/phpeclipse %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1.2.0-0.3.svn1573 +- Update for building against Eclipse SDK 3.4. + * Sun Jun 29 2008 Mat Booth 1.2.0-0.2.svn1573 - Add patch for Show External Preview functionality. - Add patch for Use External PHP Parser functionality. -------------- next part -------------- ? .build-0.6.24-3.fc10.log ? eclipse-epic-0.6.24-3.fc10.src.rpm ? epic-0.6.24 ? noarch ? x86_64 Index: eclipse-epic.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-epic/devel/eclipse-epic.spec,v retrieving revision 1.4 diff -u -r1.4 eclipse-epic.spec --- eclipse-epic.spec 14 Jun 2008 12:37:41 -0000 1.4 +++ eclipse-epic.spec 30 Jul 2008 22:56:48 -0000 @@ -1,9 +1,9 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 Name: eclipse-epic Version: 0.6.24 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Perl Eclipse plugin Group: Development/Tools License: CPL @@ -99,18 +99,19 @@ %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. build/rpmBuild/org.epic.feature.main.zip +installDir=%{buildroot}%{eclipse_base}/dropins/epic +install -d -m 755 $installDir +unzip -q -d $installDir build/rpmBuild/org.epic.feature.main.zip # need to recreate the symlinks to libraries that were setup in "prep" # because for some reason the ant copy task doesn't preserve them -pushd %{buildroot}%{eclipse_base}/plugins/org.epic.lib_*/lib +pushd $installDir/eclipse/plugins/org.epic.lib_*/lib rm *.jar build-jar-repository -s -p . jdom antlr gnu-regexp brazil popd # ensure source packages are correctly verisoned -pushd %{buildroot}%{eclipse_base}/plugins +pushd $installDir/eclipse/plugins for p in org.epic.perleditor \ org.epic.regexp \ org.epic.debug; do @@ -133,19 +134,16 @@ %files %defattr(-,root,root,-) -%doc %{eclipse_base}/features/org.epic.feature.main_%{version}/license.html -%{eclipse_base}/features/org.epic.feature.main_* -%{eclipse_base}/plugins/org.epic.debug_* -%{eclipse_base}/plugins/org.epic.doc_* -%{eclipse_base}/plugins/org.epic.lib_* -%{eclipse_base}/plugins/org.epic.perleditor_* -%{eclipse_base}/plugins/org.epic.regexp_* -%{eclipse_base}/plugins/org.epic.source_* +%doc org.epic.feature.main/license.html +%{eclipse_base}/dropins/epic %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.6.24-3 +- Update for building with Eclipse SDK 3.4 + * Sat Jun 14 2008 Mat Booth 0.6.24-2 - Fixed package ownership of feature directory. -------------- next part -------------- ? .build-4.0.1-11.fc10.log ? eclipse-checkstyle-4.0.1 ? eclipse-checkstyle-4.0.1-11.fc10.src.rpm ? noarch Index: eclipse-checkstyle.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-checkstyle/devel/eclipse-checkstyle.spec,v retrieving revision 1.5 diff -u -r1.5 eclipse-checkstyle.spec --- eclipse-checkstyle.spec 19 Feb 2008 21:48:47 -0000 1.5 +++ eclipse-checkstyle.spec 30 Jul 2008 22:52:53 -0000 @@ -1,12 +1,12 @@ -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define cs_ver 4.1 -%define eclipse_ver 3.3 +%define eclipse_ver 3.4 %define gcj_support 1 Summary: Checkstyle plugin for Eclipse Name: eclipse-checkstyle Version: 4.0.1 -Release: 10%{?dist} +Release: 11%{?dist} License: LGPLv2+ Group: Development/Tools URL: http://eclipse-cs.sourceforge.net @@ -73,14 +73,14 @@ %{eclipse_base}/plugins/org.eclipse.core.filebuffers_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.core.resources_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.core.runtime_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.jdt.core_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.jdt.ui_%{eclipse_ver}.*.jar \ +%{eclipse_base}/dropins/jdt/plugins/org.eclipse.jdt.core_%{eclipse_ver}.*.jar \ +%{eclipse_base}/dropins/jdt/plugins/org.eclipse.jdt.ui_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.jface_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.jface.text_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.osgi_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.swt_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.team.core_%{eclipse_ver}.*.jar \ -%{eclipse_base}/plugins/org.eclipse.team.cvs.core_%{eclipse_ver}.*.jar \ +%{eclipse_base}/plugins/org.eclipse.team.cvs.core_*.jar \ %{eclipse_base}/plugins/org.eclipse.text_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.ui_%{eclipse_ver}.*.jar \ %{eclipse_base}/plugins/org.eclipse.ui.editors_%{eclipse_ver}.*.jar \ @@ -108,20 +108,21 @@ %install rm -rf %{buildroot} -install -d -m755 %{buildroot}/%{eclipse_base}/features/com.atlassw.tools.eclipse.checkstyle_%{version} +installDir=%{buildroot}/%{eclipse_base}/dropins/checkstyle +install -d -m755 $installDir/features/com.atlassw.tools.eclipse.checkstyle_%{version} BUILD_DIR=`pwd`/CheckstylePlugin # install feature -pushd %{buildroot}/%{eclipse_base}/features/com.atlassw.tools.eclipse.checkstyle_%{version} +pushd $installDir/features/com.atlassw.tools.eclipse.checkstyle_%{version} jar xvf ${BUILD_DIR}/dist/com.atlassw.tools.eclipse.checkstyle_%{version}-feature.jar popd # install plugin -pushd %{buildroot}/%{eclipse_base} +pushd $installDir jar xvf ${BUILD_DIR}/dist/com.atlassw.tools.eclipse.checkstyle_%{version}-bin.zip find . -type f -name '*src.zip' -print | xargs -t rm -f build-jar-repository \ - %{buildroot}/%{eclipse_base}/plugins/com.atlassw.tools.eclipse.checkstyle_%{version} \ + $installDir/plugins/com.atlassw.tools.eclipse.checkstyle_%{version} \ checkstyle-%{cs_ver} \ checkstyle-optional-%{cs_ver} \ commons-beanutils-core \ @@ -151,14 +152,16 @@ %files %defattr(-,root,root) %doc CheckstylePlugin/license/LICENSE.* -%{eclipse_base}/features/* -%{eclipse_base}/plugins/* +%{eclipse_base}/dropins/checkstyle %if %{gcj_support} %attr(-,root,root) %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 4.0.1-11 +- Update for Eclipse SDK 3.4 + * Tue Feb 19 2008 Fedora Release Engineering - 4.0.1-10 - Autorebuild for GCC 4.3 -------------- next part -------------- ? eclipse-changelog-2.6.2 Index: eclipse-changelog.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-changelog/devel/eclipse-changelog.spec,v retrieving revision 1.67 diff -u -r1.67 eclipse-changelog.spec --- eclipse-changelog.spec 24 Jul 2008 21:07:31 -0000 1.67 +++ eclipse-changelog.spec 30 Jul 2008 21:42:01 -0000 @@ -1,11 +1,11 @@ Epoch: 1 %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse Name: eclipse-changelog Version: 2.6.2 -Release: 1%{?dist} +Release: 2%{?dist} Summary: Eclipse ChangeLog plug-in Group: Development/Tools @@ -69,32 +69,13 @@ %setup -q -c -n eclipse-changelog-%{version} %build -# See comments in the script to understand this. -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{eclipse_base} cdt -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main ChangeLog feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Duser.home=$homedir \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.eclipse.linuxtools.changelog \ - -DsourceDirectory=$(pwd) \ - -DbaseLocation=$SDK \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml +%{eclipse_base}/buildscripts/pdebuild %install rm -rf $RPM_BUILD_ROOT -install -d -m 755 $RPM_BUILD_ROOT%{eclipse_base} -unzip -q -d $RPM_BUILD_ROOT%{eclipse_base}/.. \ +installDir=%{eclipse_base}/dropins/changelog +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/org.eclipse.linuxtools.changelog.zip %if %{gcj_support} @@ -111,12 +92,8 @@ %files %defattr(-,root,root) -%{eclipse_base}/features/org.eclipse.linuxtools.changelog_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.core_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.cparser_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.parsers.java_* -%{eclipse_base}/plugins/org.eclipse.linuxtools.changelog.doc_* -%doc %{eclipse_base}/features/org.eclipse.linuxtools.changelog_*/epl-v10.html +%doc org.eclipse.linuxtools.changelog-feature/epl-v10.html +%{eclipse_base}/dropins/changelog %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/org.eclipse.linuxtools.changelog.core_* @@ -125,6 +102,9 @@ %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1:2.6.2-2 +- Update for Eclipse SDK 3.4 + * Thu Jun 26 2008 Jeff Johnston 1:2.6.2-1 - Rebase to 2.6.2 - Resolves Bugzilla #452574 -------------- next part -------------- ? .build-3.5.0-8.fc10.log ? eclipse-quickrex-3.5.0-8.fc10.src.rpm ? noarch ? quickrex-fetched-src-QuickREx_3_5_0 Index: eclipse-quickrex.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-quickrex/devel/eclipse-quickrex.spec,v retrieving revision 1.6 diff -u -r1.6 eclipse-quickrex.spec --- eclipse-quickrex.spec 18 Feb 2008 19:08:46 -0000 1.6 +++ eclipse-quickrex.spec 30 Jul 2008 21:21:53 -0000 @@ -1,5 +1,5 @@ %define gcj_support 1 -%define eclipse_base %{_datadir}/eclipse +%define eclipse_base %{_libdir}/eclipse %define upstream_name QuickREx %define cvs_tag QuickREx_3_5_0 %define oro_jar jakarta-oro-2.0.8.jar @@ -7,7 +7,7 @@ Name: eclipse-quickrex Version: 3.5.0 -Release: 7%{?dist} +Release: 8%{?dist} Summary: %{upstream_name} is a regular-expression test Eclipse Plug-In Group: Development/Tools @@ -69,37 +69,18 @@ popd popd -# See comments in the script to understand this. -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} -mkdir home - %build -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -homedir=$(cd home > /dev/null && pwd) - -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=de.babe.eclipse.plugins.QuickREx \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild %install rm -rf %{buildroot} -install -d -m 755 %{buildroot}%{eclipse_base} -unzip -q -d %{buildroot}%{eclipse_base}/.. \ +installDir=%{buildroot}%{eclipse_base}/dropins/quickrex +install -d -m 755 $installDir +unzip -q -d $installDir \ build/rpmBuild/de.babe.eclipse.plugins.QuickREx.zip # Re-symlink -pushd %{buildroot}/%{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/lib +pushd $installDir/eclipse/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/lib rm %{oro_jar} rm %{regexp_jar} ln -s %{_javadir}/%{oro_jar} @@ -129,16 +110,17 @@ %files %defattr(-,root,root,-) -%dir %{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version} -%doc %{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/html -%{eclipse_base}/features/de.babe.eclipse.plugins.QuickREx_%{version} -%{eclipse_base}/plugins/de.babe.eclipse.plugins.QuickREx_%{version}/* +%doc Plug-In/html +%{eclipse_base}/dropins/quickrex %if %{gcj_support} %dir %{_libdir}/gcj/%{name} %{_libdir}/gcj/%{name}/%{upstream_name}.* %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 3.5.0-8 +- Update to build against Eclipse SDK 3.4 + * Mon Feb 18 2008 Fedora Release Engineering - 3.5.0-7 - Autorebuild for GCC 4.3 -------------- next part -------------- ? .build-1.3.14-3.fc10.log ? .build-1.3.18-1.fc10.log ? META-INF ? about.html ? about_files ? clog ? eclipse-pydev-1.3.14 ? eclipse-pydev-1.3.18 ? eclipse-pydev-1.3.18-1.fc10.src.rpm ? noarch ? org.python.pydev.feature-src-1_3_18.zip ? plugin.properties ? test Index: eclipse-pydev.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-pydev/devel/eclipse-pydev.spec,v retrieving revision 1.10 diff -u -r1.10 eclipse-pydev.spec --- eclipse-pydev.spec 17 Jul 2008 19:05:07 -0000 1.10 +++ eclipse-pydev.spec 30 Jul 2008 21:05:48 -0000 @@ -1,26 +1,24 @@ Epoch: 1 +%define eclipse_base %{_libdir}/eclipse %define gcj_support 1 -# All arches line up except i386 -> x86 -%ifarch %{ix86} -%define eclipse_arch x86 -%else -%define eclipse_arch %{_arch} -%endif - Summary: Eclipse Python development plug-in Name: eclipse-pydev -Version: 1.3.14 -Release: 2%{?dist} +Version: 1.3.18 +Release: 1%{?dist} License: EPL URL: http://pydev.sourceforge.net/ Group: Development/Tools -Source0: http://downloads.sourceforge.net/pydev/org.python.pydev.feature-src-1_3_14.zip +Source0: http://downloads.sourceforge.net/pydev/org.python.pydev.feature-src-1_3_18.zip Source1: org.python.pydev.mylyn.feature-fetched-src-pydev_1_3_7.tar.bz2 Source2: fetch-pydev-mylyn.sh +# Back-port from HEAD +# http://pydev.cvs.sourceforge.net/pydev/org.python.pydev/src/org/python/copiedfromeclipsesrc/CopiedWorkbenchLabelProvider.java?revision=1.3&view=markup +Patch0: %{name}-%{version}-compileerrors.patch + %if %{gcj_support} BuildRequires: gcc-java >= 4.1.2 BuildRequires: java-1.5.0-gcj-devel >= 1.5.0 @@ -59,6 +57,7 @@ %prep %setup -q -c +%patch0 tar jxf %{SOURCE1} @@ -108,66 +107,37 @@ rm -f plugins/org.python.pydev.refactoring/contrib/ch/hsr/ukistler/astgraph/jgraph.jar %build -# Copy the SDK for build -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{_datadir}/eclipse mylyn -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main pydev feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.python.pydev.feature \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" \ + -f org.python.pydev.feature # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 -# build the pydev mylyn feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.python.pydev.mylyn.feature \ - -DbaseLocation=$SDK \ - -DsourceDirectory=$(pwd) \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{eclipse_base}/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" \ + -d mylyn \ + -f org.python.pydev.mylyn.feature %endif %install rm -rf $RPM_BUILD_ROOT -install -d -m755 ${RPM_BUILD_ROOT}/%{_datadir}/eclipse +installDir=${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/pydev +install -d -m755 $installDir +install -d -m755 ${installDir}-mylyn # pydev main feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ - build/rpmBuild/org.python.pydev.feature.zip +unzip -q -d $installDir build/rpmBuild/org.python.pydev.feature.zip # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 # pydev mylyn feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ - build/rpmBuild/org.python.pydev.mylyn.feature.zip +unzip -q -d ${installDir}-mylyn build/rpmBuild/org.python.pydev.mylyn.feature.zip %endif # deal with linked deps -pushd $RPM_BUILD_ROOT%{_datadir}/eclipse/plugins +pushd $installDir/eclipse/plugins rm -rf org.python.pydev.core_%{version}/commons-codec.jar ln -sf %{_datadir}/java/jakarta-commons-codec.jar \ org.python.pydev.core_%{version}/commons-codec.jar @@ -196,20 +166,11 @@ %files %defattr(-,root,root,-) -%{_datadir}/eclipse/features/org.python.pydev* -%{_datadir}/eclipse/plugins/org.python.pydev_* -%{_datadir}/eclipse/plugins/org.python.pydev.ast* -%{_datadir}/eclipse/plugins/org.python.pydev.core* -%{_datadir}/eclipse/plugins/org.python.pydev.debug* -%{_datadir}/eclipse/plugins/org.python.pydev.help* -%{_datadir}/eclipse/plugins/org.python.pydev.parser* -%{_datadir}/eclipse/plugins/org.python.pydev.templates* -%{_datadir}/eclipse/plugins/org.python.pydev.jython* -%{_datadir}/eclipse/plugins/org.python.pydev.refactoring* +%{eclipse_base}/dropins/pydev # no xmlrpc3 -> no mylyn on ppc64 due to: # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 %ifnarch ppc64 -%{_datadir}/eclipse/plugins/org.python.pydev.mylyn* +%{eclipse_base}/dropins/pydev-mylyn %endif %if %{gcj_support} @@ -217,6 +178,11 @@ %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 1:1.3.18-1 +- 1.3.18 +- Update for building with Eclipse SDK 3.4 +- Back-port patch from HEAD for building against Eclipse SDK 3.4 + * Thu Jul 17 2008 Tom "spot" Callaway 1:1.3.14-2 - fix license tag -------------- next part -------------- ? .build-4.0-1.b3.fc10.2.log Index: eclipse-photran.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-photran/devel/eclipse-photran.spec,v retrieving revision 1.2 diff -u -r1.2 eclipse-photran.spec --- eclipse-photran.spec 19 Feb 2008 17:02:43 -0000 1.2 +++ eclipse-photran.spec 30 Jul 2008 16:19:18 -0000 @@ -2,20 +2,12 @@ %define major 4 %define minor 0 %define majmin %{major}.%{minor} -%define eclipse_base %{_datadir}/eclipse -%define eclipse_lib_base %{_libdir}/eclipse - -# All arches line up except i386 -> x86 -%ifarch %{ix86} -%define eclipse_arch x86 -%else -%define eclipse_arch %{_arch} -%endif +%define eclipse_base %{_libdir}/eclipse Summary: Eclipse Fortran Development Tools (Photran) plugin Name: eclipse-photran Version: %{majmin} -Release: 1.b3%{?dist}.1 +Release: 1.b3%{?dist}.2 License: EPL Group: Development/Tools URL: http://www.eclipse.org/photran @@ -66,43 +58,15 @@ export JAVA_HOME=%{java_home} export PATH=%{java_bin}:/usr/bin:$PATH -# See comments in the script to understand this. -/bin/sh -x %{eclipse_base}/buildscripts/copy-platform SDK %{eclipse_base} cdt -SDK=$(cd SDK >/dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{eclipse_lib_base}/configuration \ - -Duser.home=$homedir \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.eclipse.photran_feature \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -DbaseLocation=$SDK \ - -DjavacSource=1.5 \ - -DjavacTarget=1.5 \ - -Dbuilder=%{eclipse_base}/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{eclipse_base}/plugins/org.eclipse.pde.build/scripts/build.xml - +%{eclipse_base}/buildscripts/pdebuild -d cdt \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" %install rm -rf ${RPM_BUILD_ROOT} -install -d -m755 ${RPM_BUILD_ROOT}/%{eclipse_base} - -unzip -d ${RPM_BUILD_ROOT}/%{_datadir} build/rpmBuild/org.eclipse.photran_feature.zip +install -d -m755 ${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/photran -# We move arch-specific plugins to libdir. -mkdir -p ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins -for archplugin in $(find ${RPM_BUILD_ROOT}%{eclipse_base}/plugins -name \*%{eclipse_arch}_%{version}\*); do - mv $archplugin ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins - chmod -R 755 ${RPM_BUILD_ROOT}%{eclipse_lib_base}/plugins/$(basename $archplugin) -done +unzip -d ${RPM_BUILD_ROOT}/%{eclipse_base}/dropins/photran build/rpmBuild/org.eclipse.photran_feature.zip %if %{gcj_support} aot-compile-rpm @@ -123,13 +87,17 @@ %files %defattr(-,root,root) %doc org.eclipse.photran-feature/epl-v10.html -%{eclipse_base}/plugins/* +%{eclipse_base}/dropins/photran %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 4.0-1.b3 +- Update for building against Eclipse SDK 3.4 +- Move everything to %%{_libdir} + * Tue Feb 19 2008 Fedora Release Engineering - 4.0-1.b3.1 - Autorebuild for GCC 4.3 -------------- next part -------------- ? .build-0.3.1-2.fc10.log ? eclipse-egit-0.3.1 ? eclipse-egit-0.3.1-2.fc10.src.rpm ? noarch Index: eclipse-egit.spec =================================================================== RCS file: /cvs/pkgs/rpms/eclipse-egit/devel/eclipse-egit.spec,v retrieving revision 1.13 diff -u -r1.13 eclipse-egit.spec --- eclipse-egit.spec 17 Jul 2008 15:11:03 -0000 1.13 +++ eclipse-egit.spec 30 Jul 2008 16:14:12 -0000 @@ -4,7 +4,7 @@ Summary: Eclipse Git plug-in Name: eclipse-egit Version: 0.3.1 -Release: 1%{?dist} +Release: 2%{?dist} License: EPL and GPLv2 and LGPLv2 URL: http://repo.or.cz/w/egit.git Group: Development/Tools @@ -40,35 +40,16 @@ %setup -q -c %build -# Copy the SDK for build -/bin/sh -x %{_datadir}/eclipse/buildscripts/copy-platform SDK %{_datadir}/eclipse -SDK=$(cd SDK > /dev/null && pwd) - -# Eclipse may try to write to the home directory. -mkdir home -homedir=$(cd home > /dev/null && pwd) - -# build the main egit feature -java -cp $SDK/startup.jar \ - -Dosgi.sharedConfiguration.area=%{_libdir}/eclipse/configuration \ - org.eclipse.core.launcher.Main \ - -application org.eclipse.ant.core.antRunner \ - -Dtype=feature \ - -Did=org.spearce.egit \ - -DbaseLocation=$SDK \ - -DjavacSource=1.5 -DjavacTarget=1.5 \ - -DsourceDirectory=$(pwd) \ - -DbuildDirectory=$(pwd)/build \ - -Dbuilder=%{_datadir}/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ - -f %{_datadir}/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml \ - -vmargs -Duser.home=$homedir +%{_libdir}/eclipse/buildscripts/pdebuild \ + -a "-DjavacSource=1.5 -DjavacTarget=1.5" %install rm -rf $RPM_BUILD_ROOT -install -d -m755 $RPM_BUILD_ROOT/%{_datadir}/eclipse +installDir=$RPM_BUILD_ROOT/%{_libdir}/eclipse/dropins/egit +install -d -m755 $installDir # egit main feature -unzip -q -d $RPM_BUILD_ROOT%{_datadir}/eclipse/.. \ +unzip -q -d $installDir/ \ build/rpmBuild/org.spearce.egit.zip %if %{gcj_support} @@ -85,16 +66,16 @@ %files %defattr(-,root,root,-) -%{_datadir}/eclipse/features/org.spearce.egit* -%{_datadir}/eclipse/plugins/org.spearce.egit* -%{_datadir}/eclipse/plugins/org.spearce.egit.core* -%{_datadir}/eclipse/plugins/org.spearce.egit.ui* -%{_datadir}/eclipse/plugins/org.spearce.jgit* +%{_libdir}/eclipse/dropins/egit %if %{gcj_support} %{_libdir}/gcj/%{name} %endif %changelog +* Wed Jul 30 2008 Andrew Overholt 0.3.1-2 +- Move files and update build for Eclipse SDK 3.4 +- Use pdebuild + * Thu Jul 17 2008 Tom "spot" Callaway - 0.3.1-1 - fix license tag From poelstra at redhat.com Thu Jul 31 16:39:42 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 31 Jul 2008 09:39:42 -0700 Subject: Implementing new wiki categories names for feature process Message-ID: <4891EACE.3060201@redhat.com> Since there were no objections to the original proposal: https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00009.html I will be implementing the change in category names for the feature process starting today. John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dcbw at redhat.com Thu Jul 31 19:57:36 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 31 Jul 2008 15:57:36 -0400 Subject: Anyone seeing serious network breakage in current Rawhide? In-Reply-To: <20080731164442.GA14056@amd.home.annexia.org> References: <20080731164442.GA14056@amd.home.annexia.org> Message-ID: <1217534256.9377.10.camel@localhost.localdomain> On Thu, 2008-07-31 at 17:44 +0100, Richard W.M. Jones wrote: > Just rebooted into a fully up to date Rawhide, and I'm experiencing > really odd network-related problems. > > For example, ssh & scp work fine. > > HTTP is totally broken: most web pages time out (either in DNS or > during page load), but occasionally I can get a whole webpage. Tested > this in all of Firefox, Seamonkey and w3m, so I'm fairly sure it's not > just a broken Firefox. I seem to have excluded local factors, such as > the router and network connection itself, since other machines in my > office work fine. > > ping is OK with small and large packet sizes. > > DNS lookups work fine from command line tools (eg. ping, ssh), but > fail quite a lot in browsers. > > Linux thinkpad 2.6.27-0.186.rc0.git15.fc10.i686 #1 SMP Sun Jul 27 05:22:35 EDT 2008 i686 i686 i386 GNU/Linux > > The network is wireless, using iwl3945 driver, configured by > NetworkManager. As far as I'm aware the kernel is untainted and there > is no non-free software installed on the machine. > > Nothing very interesting in dmesg except some oopses in > sched_mc_power_savings_store which appear to be unrelated. There's breakage upstream in wireless-land for all mac80211-based drivers (b43, b43-legacy, iwl3945, iwl4965, ath5k, rt2x00, etc) while fallout from Dave Miller's multiqueue patches is fixed up. mac80211 was incorrectly using the skb->cb field that the multiqueue patches are now also using, and that conflict is causing a lot of random weirdness. Dan