From jburgess777 at googlemail.com Tue May 1 00:02:19 2007 From: jburgess777 at googlemail.com (Jon Burgess) Date: Tue, 01 May 2007 01:02:19 +0100 Subject: Blank screen and no xv video In-Reply-To: References: <20070430182742.671e6b24@lain.camperquake.de> Message-ID: <1177977739.7754.10.camel@localhost.localdomain> On Tue, 2007-05-01 at 00:07 +0100, Leo wrote: > ----- Ralf Ertzinger (2007-04-30) wrote:----- > > > Integrated Intel video chipset? > > That would be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237169 > > Thanks, I have joined the CC. > > -- > Leo (GPG Key: 9283AA3F) > Have you tried disabling DRI? Option "DRI" "off" A few years ago I found that Xv and DRI were mutually incompatible with the i810 driver, maybe the problem still exists. Jon From pekane52 at gmail.com Tue May 1 02:33:14 2007 From: pekane52 at gmail.com (Pat Kane) Date: Mon, 30 Apr 2007 21:33:14 -0500 Subject: F7T4: HD-5500 digital HDTV card Message-ID: > I just installed F7T4 on my DELL Dimension 1100 test box that has a HD-550 pcHDTV > card. The card is detected (see attached dmesg output), but the /dev/ entries are not > present. I dropped a zero, that should read HD-5500. Some interesting lines from the dmesg output are given below, what does " intel_rng: Firmware space is locked read-only...." mean? Pat --- ... Linux video capture interface: v2.00 cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded CORE cx88[0]: subsystem: 7063:5500, board: pcHDTV HD5500 HDTV [card=47,autodetected] TV tuner 64 at 0x1fe, Radio tuner -1 at 0x1fe iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007) iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt 0000:01:01.2[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/2: found at 0000:01:01.2, rev: 5, irq: 21, latency: 64, mmio: 0xfc000000 intel_rng: Firmware space is locked read-only. If you can't or intel_rng: don't want to disable this in firmware setup, and if intel_rng: you are certain that your system has a functional intel_rng: RNG, try using the 'no_fwh_detect' option. cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/0: found at 0000:01:01.0, rev: 5, irq: 21, latency: 64, mmio: 0xfa000000 e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation tuner 1-0043: chip found @ 0x86 (cx88[0]) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0061: chip found @ 0xc2 (cx88[0]) tuner 1-0061: type set to 64 (LG TDVS-H06xF) tuner 1-0061: type set to 64 (LG TDVS-H06xF) cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 22 e100: eth0: e100_probe: addr 0xfeaff000, irq 22, MAC addr 00:16:76:4E:0C:BB ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue May 1 03:03:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 03:03:09 +0000 (UTC) Subject: contributing a software through bugzilla References: <20070426184149.0E1487317F@hormel.redhat.com> <1177633134.3406.9.camel@localhost.localdomain> <20070427071045.GA2886@free.fr> <4631A3FC.9010302@fedoraproject.org> <1177662033.30803.732.camel@mccallum.corsepiu.local> <1177729268.30803.831.camel@mccallum.corsepiu.local> <20070430091952.GB2906@free.fr> <1177929029.3587.72.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > Are you seriously telling me you would accept a package which has 30 or > more patches applied? Why not? In fact, there are already such packages in Extras. For example, look at the ATLAS package. That one uses the "one big patch" approach, because there would be too many otherwise: there's a Debian gzipped patch applied which is 3.8 MB _compressed_ (!) and then there's a 972 byte Fedora patch on top of that to use gfortran instead of g77. Some packages have upstreams which are either defunct or (as is probably the case of ATLAS) don't care about packaging and packagers' requirements, so there's no other solution there. Sure, if the patches could go upstream, it would be better, but if not, I don't see why having many or big patches would be a reason not to approve the packages. Also, for a package like rtems-binutils, upstream is really RTEMS, not the FSF. So the big patch to get from FSF Binutils to RTEMS Binutils is not really a packager patch, it's just how upstream distributes its source code. Getting their local patches merged into the FSF source is something upstream would have to deal with, not the Fedora packager. TIGCC works similarly. (I currently have a 318 KB GCC patch and a 61 KB GNU as patch.) Kevin Kofler From kevin.kofler at chello.at Tue May 1 03:20:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 03:20:56 +0000 (UTC) Subject: contributing a software through bugzilla References: <20070426184149.0E1487317F@hormel.redhat.com> <1177633134.3406.9.camel@localhost.localdomain> <20070427071045.GA2886@free.fr> <4631A3FC.9010302@fedoraproject.org> <1177662033.30803.732.camel@mccallum.corsepiu.local> Message-ID: Replying to myself here, because I have to add something: Kevin Kofler chello.at> writes: > Are you referring to the rtems cross-compilers? I'm willing to get these > through review for you (I can review packages from people who don't need a > sponsor now that I own a package) if you do the same with my tigcc > cross-toolchain package once I submit it. However, I see these currently block FE-GUIDELINES, so this is not just a case of respecting existing guidelines as your original post sounded like, but the problem is that someone thinks specific guidelines for cross-compiling are needed. I've also noticed you regularly attend the Fedora Packaging Committee meetings, why didn't you bring this up there? Looking more closely at the situation, I now think the only way we can get these reviewed without violating policies is to either get a clear statement from FPC that no specific guidelines are needed (so the FE-GUIDELINES can be removed) or to get the specific guidelines voted. Kevin Kofler From peter at thecodergeek.com Tue May 1 03:34:45 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 30 Apr 2007 20:34:45 -0700 Subject: Blank screen and no xv video In-Reply-To: <1177977739.7754.10.camel@localhost.localdomain> References: <20070430182742.671e6b24@lain.camperquake.de> <1177977739.7754.10.camel@localhost.localdomain> Message-ID: <1177990485.3440.25.camel@tuxhugs> On Tue, 2007-05-01 at 01:02 +0100, Jon Burgess wrote: > Have you tried disabling DRI? > Option "DRI" "off" Not sure if this is still the case, but XVideo on Intel IGP, so far as I understand, uses OpenGL textures instead of drawing to the raw hardware; so without DRI, you don't get usable XVideo, either... (Though this is only from a brief Google; clarification from proper X/DRI ninjas would be greatly appreciated.) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lists at sapience.com Tue May 1 03:35:50 2007 From: lists at sapience.com (Mail List) Date: Mon, 30 Apr 2007 23:35:50 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <46361D99.5050604@fedoraproject.org> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <1177950551.3026.38.camel@zod.rchland.ibm.com> <46361D99.5050604@fedoraproject.org> Message-ID: <200704302335.51053.lists@sapience.com> On Monday 30 April 2007 12:47:21 pm Rahul Sundaram wrote: > ... Loads of discussion - what follows contains no petroleum products as far as we know ... As a lowly user - only 1.47 things are clear to me - I and many I know, will primarily need the 'everything install' - Is this a DVD or a series of CD ISO's? By the way - perhaps you could use Gnome-based KDE-based or perhaps Gnome-Centric to convey better the meaning of those installs. Or perhaps (tongue in cheek) the KDE one could simply be the Linus-Preferred install ;-) Not that Linus is always right ... or is he ;-) Thanks very much and I'm really looking forward to the All-Install now doesn't that sound nicer than everything-install???? Doesn't it? Thanks all for loads of hard work and for willingness to debate and make (positive) changes. g/ From kevin.kofler at chello.at Tue May 1 03:44:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 03:44:03 +0000 (UTC) Subject: Announcing Fedora 7 Test 4 (6.93) References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > KDE is a part of Fedora, however the overwhelming evidence is that Fedora > focuses on Gnome and GTK stacks. Almost all the Fedora upstream software > that is graphical is built on gnome/gtk. It is the most integrated > experience you can get. Using KDE is a less integrated less polished > experience, and thus it is not our best foot forward. It's because of statements like this that Fedora has a bad reputation with the KDE community (just look at some of the comments at dot.kde.org). I'm doing my best to improve Fedora's reputation there, but statements like this from official people like you as the Release Engineer really ruin things. How is KDE on Fedora less integrated? Why do you think people like Than Ngo, Rex Dieter, Sebastian Vahl or me work our behinds off to fix things like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 which is now finally fixed (thanks also to a developer from Pardus who made a one-line fix to my patch to get it to work instead of crashing)? (In fact, we have to specifically fix what your GNOME developers break, but that's another issue.) We're really doing what we can to provide a well-integrated KDE desktop to Fedora users, I think it's unfair to us to call this "a less integrated less polished experience" and "not our best foot forward", and I also think it's Fedora's reputation you're ruining there (again, look at some of the comments at dot.kde.org, I'd be surprised if nobody is going to quote your above paragraph the next time Fedora is mentioned anywhere), not just KDE's and ours. Kevin Kofler From kevin.kofler at chello.at Tue May 1 03:48:04 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 03:48:04 +0000 (UTC) Subject: Fedora 7 presentation (was Re: Announcing Fedora 7 Test 4 (6.93)) References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <4631B2E4.80006@fedoraproject.org> <4635FC2F.7090008@fedoraproject.org> <46360002.4020702@fedoraproject.org> <1177944365.3414.15.camel@dhcp83-33.boston.redhat.com> <463603C7.7020509@fedoraproject.org> Message-ID: Max Spevack redhat.com> writes: > I am a curious user, and I want to browse/download custom Fedora spins > that other people or groups have created. > --> We send them to a page, which includes the KDE Live CD, and > other custom spins that the Board has blessed. So you want to relegate the KDE Live CD, one of the official spins agreed on during the F7 feature planning, to unofficial ("custom") status? Kevin Kofler From jkeating at redhat.com Tue May 1 04:26:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Apr 2007 21:26:25 -0700 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> Message-ID: <200704302126.25636.jkeating@redhat.com> On Monday 30 April 2007 20:44:03 Kevin Kofler wrote: > How is KDE on Fedora less integrated? Why do you think people like Than > Ngo, Rex Dieter, Sebastian Vahl or me work our behinds off to fix things > like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 > which is now finally fixed (thanks also to a developer from Pardus who made > a one-line fix to my patch to get it to work instead of crashing)? (In > fact, we have to specifically fix what your GNOME developers break, but > that's another issue.) All our system config tools are GTK. The installer is GTK. Our applications like gnome-power-manager and NetworkManager and smolt and etc.. are all GTK. Our work went into GDM to improve login experience. Our Fast User Switching is designed for gnome. I can go on and on. These aren't bad things, they're just the way they are. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Tue May 1 04:50:49 2007 From: wart at kobold.org (Wart) Date: Mon, 30 Apr 2007 21:50:49 -0700 Subject: Tetris clones Message-ID: <4636C729.2000407@kobold.org> It was recently brought to my attention[1] that the bsd-games package contains 'tetris-bsd', a curses-based tetris clone. This was an oversight on my part, because if I had paid closer attention during the review I would have stripped the name 'tetris' and replaced it with something less objectionable. Now that I know, I'll do that anyway. But the bug report is claiming that all tetris clones are illegal and should be removed, not just the name 'tetris'. What is the legal status of tetris (and other game) clones? Can we get some "official" word from a legal department on what is and isn't allowed? --Wart [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238526 From lightsolphoenix at gmail.com Tue May 1 05:44:05 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Tue, 1 May 2007 01:44:05 -0400 Subject: Tetris clones In-Reply-To: <4636C729.2000407@kobold.org> References: <4636C729.2000407@kobold.org> Message-ID: <200705010144.06314.lightsolphoenix@gmail.com> On Tuesday, May 01, 2007 12:50 am Wart wrote: > It was recently brought to my attention[1] that the bsd-games package > contains 'tetris-bsd', a curses-based tetris clone. This was an > oversight on my part, because if I had paid closer attention during the > review I would have stripped the name 'tetris' and replaced it with > something less objectionable. Now that I know, I'll do that anyway. > > But the bug report is claiming that all tetris clones are illegal and > should be removed, not just the name 'tetris'. What is the legal status > of tetris (and other game) clones? Can we get some "official" word from > a legal department on what is and isn't allowed? > > --Wart > [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238526 IANAL, but it is generally not possible to claim copyright over a game, so only the title would be in a state of legal violation (as the term Tetris is a registered trademark). -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From rc040203 at freenet.de Tue May 1 05:58:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 May 2007 07:58:40 +0200 Subject: contributing a software through bugzilla In-Reply-To: References: <20070426184149.0E1487317F@hormel.redhat.com> <1177633134.3406.9.camel@localhost.localdomain> <20070427071045.GA2886@free.fr> <4631A3FC.9010302@fedoraproject.org> <1177662033.30803.732.camel@mccallum.corsepiu.local> Message-ID: <1177999120.4283.182.camel@mccallum.corsepiu.local> On Tue, 2007-05-01 at 03:20 +0000, Kevin Kofler wrote: > Replying to myself here, because I have to add something: > > Kevin Kofler chello.at> writes: > > Are you referring to the rtems cross-compilers? I'm willing to get these > > through review for you (I can review packages from people who don't need a > > sponsor now that I own a package) if you do the same with my tigcc > > cross-toolchain package once I submit it. > > However, I see these currently block FE-GUIDELINES, so this is not just a case > of respecting existing guidelines as your original post sounded like, but the > problem is that someone thinks specific guidelines for cross-compiling are > needed. I've also noticed you regularly attend the Fedora Packaging Committee > meetings, why didn't you bring this up there? I am a member of the FPC. The topic had been brought up there a very long time ago, but it was shot down. Other FPC members could not refrain from insisting on "change upstream". Anyway, this topic meanwhile had come up repeatedly on various Fedora lists, resulting into the "embedded SIG" http://fedoraproject.org/wiki//SIGs/Embedded, which collaborated into producing a precedence (avr-binutils), pragmatically focusing on the actual issues, to not further close out cross-toolchains from Fedora. Ralf From j.w.r.degoede at hhs.nl Tue May 1 06:01:31 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 01 May 2007 08:01:31 +0200 Subject: Tetris clones In-Reply-To: <200705010144.06314.lightsolphoenix@gmail.com> References: <4636C729.2000407@kobold.org> <200705010144.06314.lightsolphoenix@gmail.com> Message-ID: <4636D7BB.9040506@hhs.nl> Kelly wrote: > On Tuesday, May 01, 2007 12:50 am Wart wrote: >> It was recently brought to my attention[1] that the bsd-games package >> contains 'tetris-bsd', a curses-based tetris clone. This was an >> oversight on my part, because if I had paid closer attention during the >> review I would have stripped the name 'tetris' and replaced it with >> something less objectionable. Now that I know, I'll do that anyway. >> >> But the bug report is claiming that all tetris clones are illegal and >> should be removed, not just the name 'tetris'. What is the legal status >> of tetris (and other game) clones? Can we get some "official" word from >> a legal department on what is and isn't allowed? >> >> --Wart >> [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238526 > > IANAL, but it is generally not possible to claim copyright over a game, so > only the title would be in a state of legal violation (as the term Tetris is > a registered trademark). > Correct, otherwise for example the makers of unreal would be in great trouble with ID software, using the name and using copied / drawn over graphics is a problem. But as long as the graphics (and levels, sounds, etc). are original, and the name of the original game isn't used there isn't a problem Regards, Hans From kevin.kofler at chello.at Tue May 1 06:09:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 06:09:05 +0000 (UTC) Subject: contributing a software through bugzilla References: <20070426184149.0E1487317F@hormel.redhat.com> <1177633134.3406.9.camel@localhost.localdomain> <20070427071045.GA2886@free.fr> <4631A3FC.9010302@fedoraproject.org> <1177662033.30803.732.camel@mccallum.corsepiu.local> <1177999120.4283.182.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > The topic had been brought up there a very long time ago, but it was > shot down. Other FPC members could not refrain from insisting on "change > upstream". Anyway, this topic meanwhile had come up repeatedly on > various Fedora lists, resulting into the "embedded SIG" > http://fedoraproject.org/wiki//SIGs/Embedded, which collaborated into > producing a precedence (avr-binutils), pragmatically focusing on the > actual issues, to not further close out cross-toolchains from Fedora. So this means we can take your review requests out of FE-GUIDELINES? If so, I'll be glad to review them. I do need your latest SRPMs though. In particular, the GCC SRPM link is broken. Kevin Kofler From caolanm at redhat.com Tue May 1 06:45:06 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 01 May 2007 07:45:06 +0100 Subject: Weird tooltips for OOo with regard to bold/italic In-Reply-To: <1177975859.3777.10.camel@localhost.localdomain> References: <1177975859.3777.10.camel@localhost.localdomain> Message-ID: <1178001906.587.3.camel@localhost.localdomain> On Tue, 2007-05-01 at 09:30 +1000, Rodd Clarkson wrote: > If I put my mouse over the italic button in OOo and then move it over > the bold button, the tool tip for bold says italic. Move between the > two on the tool bar (and possibly other items) and both stay saying > italic. > > Move off the tool bar and then back on, this time moving over bold first > and then the italic icon says bold. > > Weird? Or just me being weird? None of this happens for me, bold says bold and italic italic regardless of the order hovered over. At least when under GNOME :-(. I assume your UI is in English ? Maybe a Istanbul video recording of the problem would show what this problem looks like. C. From mschwendt.tmp0701.nospam at arcor.de Tue May 1 08:47:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 1 May 2007 10:47:24 +0200 Subject: rpms/openvrml/devel .cvsignore, 1.4, 1.5 openvrml.spec, 1.12, 1.13 sources, 1.4, 1.5 In-Reply-To: <200705010121.l411Lmt3014949@cvs-int.fedora.redhat.com> References: <200705010121.l411Lmt3014949@cvs-int.fedora.redhat.com> Message-ID: <20070501104724.ecf2fe95.mschwendt.tmp0701.nospam@arcor.de> On Mon, 30 Apr 2007 21:21:48 -0400, Braden McDaniel (braden) wrote: > Author: braden > > Update of /cvs/extras/rpms/openvrml/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14903/devel > -%package gtkplug This breaks dependencies of previously released packages. When taking away a sub-package, don't forget proper "Obsoletes" (and "Provides" if the pkg content is still available in the renamed package). From fedora at leemhuis.info Tue May 1 09:10:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 01 May 2007 11:10:02 +0200 Subject: repotag in EPEL In-Reply-To: <1177967603.7337.66.camel@cmn3.stanford.edu> References: <1177541584.17572.3.camel@lincoln> <46304EFC.5000303@leemhuis.info> <1177690733.10685.15.camel@cmn3.stanford.edu> <20070428095815.GC18891@neu.nirvana> <1177851508.4390.16.camel@localhost.localdomain> <20070429152130.GB15091@neu.nirvana> <1177890118.3836.5.camel@localhost.localdomain> <20070430015053.GB25998@neu.nirvana> <1177939835.3836.47.camel@localhost.localdomain> <1177967603.7337.66.camel@cmn3.stanford.edu> Message-ID: <463703EA.4080108@leemhuis.info> Fernando Lopez-Lezcano schrieb: > [...] > AFAIK repotags have not caused technical > problems when used, they _have_ been useful, and they work now. repotags are part of the release and as such they influence the version-comparison when rpm determinates which rpm package is the newest. Some people call that a "technical problem". In other words: the repo with the "highest" repotag wins: [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at 0:1.1-5.at is newer [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel 0:1.1-5.epel is newer [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf 0:1.1-5.rf is newer [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz 0:1.1-5.zzzzzzzzzz is newer > [...] CU thl From pertusus at free.fr Tue May 1 09:32:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 1 May 2007 11:32:46 +0200 Subject: contributing a software through bugzilla In-Reply-To: <1177929029.3587.72.camel@mccallum.corsepiu.local> References: <20070426184149.0E1487317F@hormel.redhat.com> <1177633134.3406.9.camel@localhost.localdomain> <20070427071045.GA2886@free.fr> <4631A3FC.9010302@fedoraproject.org> <1177662033.30803.732.camel@mccallum.corsepiu.local> <1177729268.30803.831.camel@mccallum.corsepiu.local> <20070430091952.GB2906@free.fr> <1177929029.3587.72.camel@mccallum.corsepiu.local> Message-ID: <20070501093246.GB3047@free.fr> On Mon, Apr 30, 2007 at 12:30:29PM +0200, Ralf Corsepius wrote: > Are you seriously telling me you would accept a package which has 30 or > more patches applied? > > You would tell the maintainer to tell upstream to fix them. In the cernlib there are about 100 patches, most of them coming from debian, some I have submitted to the debian maintainer. Upstream still do some releases but don't care about shared libraries, FHS, distributing code violating the GPL, code already in other packages... -- Pat From buildsys at fedoraproject.org Tue May 1 09:48:05 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 1 May 2007 05:48:05 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-01 Message-ID: <20070501094805.C9F04152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 88 915resolution-0.5.3-1.fc6 NEW LabPlot-1.5.1.5-6.fc6 PyOpenGL-3.0.0-0.3.a6.fc6.1 R-2.5.0-2.fc6 R-mAr-1.1-10.fc6 R-waveslim-1.6-3.fc6 R-wavethresh-2.2-6.fc6 abook-0.6.0-0.1.pre2.fc6 aria2-0.10.2+1-1.fc6 bcfg2-0.9.3-1.fc6 cmake-2.4.6-3.fc6 cobbler-0.4.8-1.fc6 crystal-clear-20050622-4.fc6 dap-server-3.7.4-1.fc6 firmware-addon-dell-1.2.13-1.fc6 glchess-1.0.5-2.fc6 glibmm24-2.12.8-1.fc6 gmediaserver-0.12.0-8.fc6 gnome-applet-timer-1.3.3-1.fc6 gnome-vfsmm26-2.16.1-1 NEW google-perftools-0.91-3.fc6 gtkmm24-2.10.9-1.fc6 gtkwave-3.0.27-1.fc6 kazehakase-0.4.6-1.fc6 kdmtheme-1.1.3-1.fc6 kmenu-gnome-0.6.3-1.fc6 koan-0.3.1-2.fc6 NEW koverartist-0.5-7.fc6 krename-3.0.14-1.fc6 kshutdown-1.0-2.fc6 NEW marble-0.3.1-3.fc6 NEW migemo-0.40-9.fc6 nginx-0.5.19-1.fc6 pdfedit-0.3.1-1.fc6 pdns-2.9.21-1.fc6 NEW perl-CGI-Ex-2.10-2.fc6 NEW perl-Class-Prototyped-1.10-2.fc6 NEW perl-Config-IniHash-2.9.0-2.fc6 NEW perl-DBIx-POS-0.03-4.fc6 NEW perl-Data-Dump-1.08-2.fc6 perl-Devel-StackTrace-1.15-1.fc6 NEW perl-Email-Simple-Creator-1.420-2.fc6 NEW perl-GTop-0.16-3.fc6 perl-HTTP-Body-0.9-1.fc6 NEW perl-HTTP-Request-AsCGI-0.5-2.fc6 perl-MooseX-Params-Validate-0.02-1.fc6 perl-Net-LibIDN-0.09-2.fc6 perl-POE-Component-IRC-5.26-1.fc6 NEW perl-Test-use-ok-0.02-3.fc6 NEW perl-Tree-Simple-VisitorFactory-0.10-2.fc6 php-Smarty-2.6.18-1.fc6 php-pear-Structures-DataGrid-0.8.3-1.fc6 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.fc6 pylibacl-0.2.1-6.fc6 python-imaging-1.1.6-3.fc6 NEW python-meld3-0.6-2.fc6 python-mutagen-1.11-1.fc6 NEW ruby-zoom-0.2.2-2.fc6 NEW seahorse-adventures-1.0-1.fc6 soundconverter-0.9.6-1.fc6 NEW spambayes-1.0.4-4.fc6 NEW supervisor-2.1-3.fc6 toped-0.8.5-1.fc6 wine-0.9.36-1.fc6 wine-docs-0.9.36-1.fc6 xfce4-battery-plugin-0.5.0-2.fc6 xfce4-clipman-plugin-0.8.0-2.fc6 xfce4-cpugraph-plugin-0.3.0-5.fc6 xfce4-dict-plugin-0.2.1-2.fc6 xfce4-diskperf-plugin-2.1.0-3.fc6 xfce4-eyes-plugin-4.4.0-2.fc6 xfce4-fsguard-plugin-0.3.0-5.fc6 xfce4-genmon-plugin-3.1-2.fc6 xfce4-mailwatch-plugin-1.0.1-6.fc6 xfce4-minicmd-plugin-0.4-5.fc6 xfce4-mount-plugin-0.5.1-2.fc6 xfce4-netload-plugin-0.4.0-5.fc6 xfce4-notes-plugin-1.4.1-2.fc6 xfce4-quicklauncher-plugin-1.9.2-3.fc6 xfce4-screenshooter-plugin-1.0.0-5.fc6 xfce4-sensors-plugin-0.10.0-3.fc6 xfce4-smartbookmark-plugin-0.4.2-3.fc6 xfce4-systemload-plugin-0.4.2-2.fc6 xfce4-timer-plugin-0.5.1-2.fc6 xfce4-wavelan-plugin-0.5.4-2.fc6 xfce4-websearch-plugin-0.1.1-0.5.20070428svn2704.fc6 xfce4-xfapplet-plugin-0.1.0-3.fc6 xfce4-xkb-plugin-0.4.3-2.fc6 Packages built and released for Fedora Extras 5: 51 915resolution-0.5.3-1.fc5 R-2.5.0-2.fc5 R-mAr-1.1-10.fc5 R-waveslim-1.6-3.fc5 R-wavethresh-2.2-6.fc5 abook-0.6.0-0.1.pre2.fc5 aria2-0.10.2+1-1.fc5 cmake-2.4.6-3.fc5 cobbler-0.4.8-1.fc5 crystal-clear-20050622-4.fc5 dap-server-3.6.0-3.fc5.2 glibmm24-2.10.10-1 gnome-applet-timer-1.3.3-1.fc5 NEW google-perftools-0.91-3.fc5 gtkmm24-2.8.11-1.fc5 gtkwave-3.0.27-1.fc5 kazehakase-0.4.6-1.fc5 kdmtheme-1.1.3-1.fc5 kmenu-gnome-0.6.3-1.fc5 koan-0.3.1-1.fc5 NEW koverartist-0.5-7.fc5 krename-3.0.14-1.fc5 kshutdown-1.0-2.fc5 NEW migemo-0.40-9.fc5 nginx-0.5.19-1.fc5 NEW perl-CGI-Ex-2.10-2.fc5 NEW perl-Class-Prototyped-1.10-2.fc5 NEW perl-Config-IniHash-2.9.0-2.fc5 NEW perl-DBIx-POS-0.03-4.fc5 NEW perl-Data-Dump-1.08-2.fc5 perl-Devel-StackTrace-1.15-1.fc5 NEW perl-Email-Simple-Creator-1.420-2.fc5 NEW perl-GTop-0.16-3.fc5 perl-HTTP-Body-0.9-1.fc5 NEW perl-HTTP-Request-AsCGI-0.5-2.fc5 perl-MooseX-Params-Validate-0.02-1.fc5 perl-Net-LibIDN-0.09-2.fc5 perl-POE-Component-IRC-5.26-1.fc5 NEW perl-Test-use-ok-0.02-3.fc5 NEW perl-Tree-Simple-VisitorFactory-0.10-2.fc5 php-pear-Structures-DataGrid-0.8.3-1.fc5 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.fc5 pylibacl-0.2.1-6.fc5 NEW python-meld3-0.6-2.fc5 python-mutagen-1.11-1.fc5 NEW ruby-zoom-0.2.2-2.fc5 NEW spambayes-1.0.4-4.fc5 NEW supervisor-2.1-3.fc5 toped-0.8.5-1.fc5 wine-0.9.36-1.fc5 wine-docs-0.9.36-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at redhat.com Tue May 1 09:51:26 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 1 May 2007 05:51:26 -0400 Subject: rawhide report: 20070501 changes Message-ID: <200705010951.l419pQVc005646@hs20-bc2-6.build.redhat.com> Updated Packages: NetworkManager-1:0.6.5-2.fc7 ---------------------------- * Wed Apr 25 2007 Christopher Aillon 1:0.6.5-2 - Fix requires macro (237806) anaconda-11.2.0.57-1 -------------------- * Mon Apr 30 2007 Jeremy Katz - 11.2.0.57-1 - fix build * Mon Apr 30 2007 Jeremy Katz - 11.2.0.56-1 - Don't write out ipv6 disabling bits (dcantrell, #237642) - Load pata_pcmcia late (#237674) - Fix release notes to display nicely with the livecd running at 800x600 - Add support for spufs (pnasrat, #237725) - Add libidn for ping (#237745) - Fix selinux context of /root (clumens, #237834) - Fix for mirror errors (dlehman) - Fix splittree (Joel Andres Granados, #233384) - Fix ppc32 netboot (pnasrat, #237988) - Fix %packages for media installs (clumens, #231121, #235881) - Fix rescue mode networking (dcantrell, #238080) - Adjust for unbreaking the yum API - Fix rescue mode traceback (#238261) - Fix for iscsi not being present (#238424) - Fix for upgrades with LVM (clumens, #234938) - Give some feedback while erases are being processed (#238256) anthy-8706-2.fc7 ---------------- * Fri Apr 27 2007 Akira TAGOH - 8706-2 - Fix wrong Provides line. (#237987) libvirt-0.2.2-2.fc7 ------------------- * Sat Apr 21 2007 Daniel P. Berrange - 0.2.2-2.fc7 - Added Requires on dnsmasq for virtual networking pango-1.16.4-1.fc7 ------------------ * Tue Apr 10 2007 Behdad Esfahbod - 1.16.4-1 - Update to 1.16.4. - Enable doc rebuilding to get cross-references right. vim-2:7.0.235-1.fc7 ------------------- * Mon Apr 30 2007 Karsten Hopp 7.0.235-1 - update to patchlevel 235, fixes modeline issues vte-0.16.3-1.fc7 ---------------- * Fri Apr 27 2007 Behdad Esfahbod 0.16.3-1 - Update to 0.16.3 wireless-tools-1:28-2.fc7 ------------------------- * Mon Apr 30 2007 Christopher Aillon - 1:28-2 - Backport a few 64bit alignment fixes from the latest betas. xorg-x11-proto-devel-7.2-9.fc7 ------------------------------ * Thu Apr 26 2007 Adam Jackson 7.2-9 - inputproto 1.4.2 xorg-x11-server-1.3.0.0-3.fc7 ----------------------------- * Mon Apr 30 2007 Adam Jackson 1.3.0.0-3 - xserver-1.3.0-xkb-and-loathing.patch: Ignore (not just block) SIGALRM around calls to Popen()/Pclose(). Fixes a hang in openoffice when opening menus. - Modify BuildRequires to use the virtual protocol Provides. * Wed Apr 25 2007 Adam Jackson 1.3.0.0-2 - xserver-1.3.0-less-randr-fakerama.patch: Disable RANDR's fake Xinerama geometry when there's more than one protocol screen. (#231257) * Mon Apr 23 2007 Adam Jackson 1.3.0.0-1 - xserver 1.3.0. yum-3.1.7-2.fc7 --------------- * Mon Apr 30 2007 Jeremy Katz - 3.1.7-2 - add fix for fastestmirror (#238276) Broken deps for ia64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ia64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.ia64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ia64 requires mkisofs k3b - 1.0-1.fc7.ia64 requires cdrecord libvirt - 0.2.2-2.fc7.ia64 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.ia64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ia64 requires cdrecord xcdroast - 0.98a15-13.ia64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.ia64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ia64 requires mkisofs >= 0:2.0 Broken deps for ppc64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ppc64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.ppc64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ppc64 requires mkisofs k3b - 1.0-1.fc7.ppc64 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.ppc64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ppc64 requires cdrecord xcdroast - 0.98a15-13.ppc64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.ppc64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ppc64 requires mkisofs >= 0:2.0 Broken deps for i386 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.i386 requires mkisofs dvd+rw-tools - 7.0-3.fc7.i386 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.i386 requires cdrecord k3b - 1.0-1.fc7.i386 requires mkisofs libvirt - 0.2.2-2.fc7.i386 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.i386 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.i386 requires mkisofs xcdroast - 0.98a15-13.i386 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.i386 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.i386 requires mkisofs >= 0:2.0 Broken deps for x86_64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.x86_64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.x86_64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.i386 requires mkisofs k3b - 1.0-1.fc7.i386 requires cdrecord k3b - 1.0-1.fc7.x86_64 requires mkisofs k3b - 1.0-1.fc7.x86_64 requires cdrecord libvirt - 0.2.2-2.fc7.x86_64 requires dnsmasq libvirt - 0.2.2-2.fc7.i386 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.x86_64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.x86_64 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.i386 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.i386 requires cdrecord xcdroast - 0.98a15-13.x86_64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.x86_64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.x86_64 requires mkisofs >= 0:2.0 Broken deps for ppc ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ppc requires mkisofs dvd+rw-tools - 7.0-3.fc7.ppc requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ppc requires mkisofs k3b - 1.0-1.fc7.ppc requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.ppc requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ppc requires cdrecord xcdroast - 0.98a15-13.ppc requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ppc requires mkisofs >= 0:2.0 xcdroast - 0.98a15-13.ppc requires cdrecord >= 0:2.0 From lsof at nodata.co.uk Tue May 1 10:01:24 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 01 May 2007 12:01:24 +0200 Subject: F7T4 install problems on VMware... In-Reply-To: References: Message-ID: <1178013684.3299.9.camel@sb-home.lan> Am Montag, den 30.04.2007, 23:34 +0200 schrieb Thomas M Steenholdt: > Hi there... > > I've been trying to install F7T4 on VMware workstation 6 (RC) but haven > been successful yet. Have tried both i386 and x86_64 and the same thing > happens every time. When anaconda has built dependencies and is ready to > proceed, anaconda bails, leaving a python backtrace on the screen. I > have the option to save the debug info to a floppy, but that doesn't > work either. > > I just wanted to know if this is a known issue that I've missed. Perhaps > a problem with the not-yet-final VMware Workstation 6 or if I need to > file a bug. > > /Thomas > Works for me. Did you check the md5sum and use the non-default SCSI driver? From lsof at nodata.co.uk Tue May 1 10:03:42 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 01 May 2007 12:03:42 +0200 Subject: F7T4 install problems on VMware... In-Reply-To: <1178013684.3299.9.camel@sb-home.lan> References: <1178013684.3299.9.camel@sb-home.lan> Message-ID: <1178013822.3299.11.camel@sb-home.lan> Am Dienstag, den 01.05.2007, 12:01 +0200 schrieb nodata: > > Perhaps > > a problem with the not-yet-final VMware Workstation 6 or if I need to > > file a bug. > Works for me. Did you check the md5sum and use the non-default SCSI > driver? > Ah. Not tested with WS 6. But my questions are still valid. From n0dalus+redhat at gmail.com Tue May 1 10:20:30 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 1 May 2007 19:50:30 +0930 Subject: CD version gone? Message-ID: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> Hi, I noticed there is only a LiveCD and a DVD iso of the test version available on the mirrors. I need to be able to install Fedora without a dvd drive and essentially without an internet connection -- the lack of CD isos is a big problem for me. This is related to volunteer work I do for a organization out in the country with older computers. One consequence of this is that I am unable to test F7test4 on some of my computers (I will try the LiveCD though). Will there be a CD version available for F7? I'm sure I'm not the only person who would need a CD version. n0dalus. From sundaram at fedoraproject.org Tue May 1 10:23:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 15:53:56 +0530 Subject: CD version gone? In-Reply-To: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> Message-ID: <4637153C.8020302@fedoraproject.org> n0dalus wrote: > Hi, > > I noticed there is only a LiveCD and a DVD iso of the test version > available on the mirrors. I need to be able to install Fedora without > a dvd drive and essentially without an internet connection -- the lack > of CD isos is a big problem for me. This is related to volunteer work > I do for a organization out in the country with older computers. One > consequence of this is that I am unable to test F7test4 on some of my > computers (I will try the LiveCD though). > > Will there be a CD version available for F7? I'm sure I'm not the only > person who would need a CD version. The Live CD's are installable. Does that not serve your purpose? Rahul From drago01 at gmail.com Tue May 1 10:37:37 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 01 May 2007 12:37:37 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) (no x86_64 kde live cd ?) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> Message-ID: <46371871.5010900@gmail.com> Kevin, I am a gnome user so I have not noticed it until now... but whats the reason the kde live cd is i386 only? why no x86_64 one? (might be to late to change but just want to know the reason...) if its space the x86_64 livecd is already bigger than 700MB so that can't be the reason. From n0dalus+redhat at gmail.com Tue May 1 10:45:01 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 1 May 2007 20:15:01 +0930 Subject: CD version gone? In-Reply-To: <4637153C.8020302@fedoraproject.org> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> Message-ID: <6280325c0705010345v55e9c6cdk71e097abb1162832@mail.gmail.com> On 5/1/07, Rahul Sundaram wrote: > > The Live CD's are installable. Does that not serve your purpose? > That should be ok. Now all I need is a way to put all the other packages I need (the ones not on the LiveCD) on a CD, the problem being that in the past this is usually a trial-and-error process of finding out that x requires y requires z, downloading them all separately and putting them on disc (where hypothetically more than one disc could be required during a single transaction -- does yum handle this?) etc. n0dalus. From sundaram at fedoraproject.org Tue May 1 10:49:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 16:19:13 +0530 Subject: CD version gone? In-Reply-To: <6280325c0705010345v55e9c6cdk71e097abb1162832@mail.gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <6280325c0705010345v55e9c6cdk71e097abb1162832@mail.gmail.com> Message-ID: <46371B29.2070604@fedoraproject.org> n0dalus wrote: > On 5/1/07, Rahul Sundaram wrote: >> >> The Live CD's are installable. Does that not serve your purpose? >> > > That should be ok. Now all I need is a way to put all the other > packages I need (the ones not on the LiveCD) on a CD, the problem > being that in the past this is usually a trial-and-error process of > finding out that x requires y requires z, downloading them all > separately and putting them on disc (where hypothetically more than > one disc could be required during a single transaction -- does yum > handle this?) etc. Media handling? There is some amount of support for this. There was references in the Pirut changelog. I haven't had time to test this out yet. Rahul From drago01 at gmail.com Tue May 1 10:49:59 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 01 May 2007 12:49:59 +0200 Subject: CD version gone? In-Reply-To: <4637153C.8020302@fedoraproject.org> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> Message-ID: <46371B57.10302@gmail.com> Rahul Sundaram wrote: > > The Live CD's are installable. Does that not serve your purpose? > isn't it planned to have a cd version(multiple cds) of the fedora/prime/whatever it will be called spin? From sundaram at fedoraproject.org Tue May 1 10:54:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 16:24:41 +0530 Subject: CD version gone? In-Reply-To: <46371B57.10302@gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> Message-ID: <46371C71.9050703@fedoraproject.org> dragoran wrote: > Rahul Sundaram wrote: >> >> The Live CD's are installable. Does that not serve your purpose? >> > isn't it planned to have a cd version(multiple cds) of the > fedora/prime/whatever it will be called spin? AFAIK, No. Rahul From katzj at redhat.com Tue May 1 11:05:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 May 2007 07:05:56 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) (no x86_64 kde live cd ?) In-Reply-To: <46371871.5010900@gmail.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> <46371871.5010900@gmail.com> Message-ID: <1178017556.13694.6.camel@aglarond.local> On Tue, 2007-05-01 at 12:37 +0200, dragoran wrote: > Kevin, I am a gnome user so I have not noticed it until now... but whats > the reason the kde live cd is i386 only? why no x86_64 one? (might be to > late to change but just want to know the reason...) > if its space the x86_64 livecd is already bigger than 700MB so that > can't be the reason. Time mostly... to do an x86_64 one needed more time for more spinning and more testing. The hope was to be able to do so with test4 (and thus to be able to get more eyes on it prior to the final), but there just weren't enough hours in the day to get there. Jeremy From drago01 at gmail.com Tue May 1 11:19:33 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 01 May 2007 13:19:33 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) (no x86_64 kde live cd ?) In-Reply-To: <1178017556.13694.6.camel@aglarond.local> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> <46371871.5010900@gmail.com> <1178017556.13694.6.camel@aglarond.local> Message-ID: <46372245.4060602@gmail.com> Jeremy Katz wrote: > On Tue, 2007-05-01 at 12:37 +0200, dragoran wrote: > >> Kevin, I am a gnome user so I have not noticed it until now... but whats >> the reason the kde live cd is i386 only? why no x86_64 one? (might be to >> late to change but just want to know the reason...) >> if its space the x86_64 livecd is already bigger than 700MB so that >> can't be the reason. >> > > Time mostly... to do an x86_64 one needed more time for more spinning > and more testing. The hope was to be able to do so with test4 (and thus > to be able to get more eyes on it prior to the final), but there just > weren't enough hours in the day to get there. > > ok... sounds F8 stuff than ;) From rodd at clarkson.id.au Tue May 1 11:21:54 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 01 May 2007 21:21:54 +1000 Subject: Size does matter!!! Message-ID: <1178018514.3777.37.camel@localhost.localdomain> Why are the open and save file dialogs so small. I have a 1920x1200 screen, and yet I have to resize these dialogs each time they open so I can do complex (he he) tasks like find a file, or select a folder in which files might be. The damn dialog is so small I can't see more than 12 letters in a file name and I can see two places (one of which is Search). Surely something should be done about this, so who do I nag senseless? R. -- "It's a fine line between denial and faith. It's much better on my side" From limb at jcomserv.net Tue May 1 11:26:20 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 1 May 2007 06:26:20 -0500 (CDT) Subject: CD version gone? In-Reply-To: <46371C71.9050703@fedoraproject.org> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> Message-ID: <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> That could be a huge problem for me. I have no DVD drives, and several production fc6 machines with heavy reliance on things that would traditionally have been on CD 4 or 5, or in (the artist formerly known as) Extras. I suppose yum based upgrades are still offically unsupported? Is there a way users could spin their own CD set, with all packages, using only FC6 and yum? > dragoran wrote: >> Rahul Sundaram wrote: >>> >>> The Live CD's are installable. Does that not serve your purpose? >>> >> isn't it planned to have a cd version(multiple cds) of the >> fedora/prime/whatever it will be called spin? > > AFAIK, No. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From sundaram at fedoraproject.org Tue May 1 11:40:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 17:10:08 +0530 Subject: CD version gone? In-Reply-To: <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> Message-ID: <46372718.4020700@fedoraproject.org> Jon Ciesla wrote: > That could be a huge problem for me. I have no DVD drives, and several > production fc6 machines with heavy reliance on things that would > traditionally have been on CD 4 or 5, or in (the artist formerly known as) > Extras. I suppose yum based upgrades are still offically unsupported? > > Is there a way users could spin their own CD set, with all packages, using > only FC6 and yum? Both of these tools are in the repository. pungi - https://hosted.fedoraproject.org/projects/pungi livecd-tools - http://fedoraproject.org/wiki/FedoraLiveCD/ Rahul From n0dalus+redhat at gmail.com Tue May 1 11:53:41 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 1 May 2007 21:23:41 +0930 Subject: Size does matter!!! In-Reply-To: <1178018514.3777.37.camel@localhost.localdomain> References: <1178018514.3777.37.camel@localhost.localdomain> Message-ID: <6280325c0705010453s664f673cr1830165a83d74602@mail.gmail.com> On 5/1/07, Rodd Clarkson wrote: > Why are the open and save file dialogs so small. > > I have a 1920x1200 screen, and yet I have to resize these dialogs each > time they open so I can do complex (he he) tasks like find a file, or > select a folder in which files might be. > > The damn dialog is so small I can't see more than 12 letters in a file > name and I can see two places (one of which is Search). > > Surely something should be done about this, so who do I nag senseless? > See GNOME bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=325477 http://bugzilla.gnome.org/show_bug.cgi?id=418585 This may also be of interest: http://live.gnome.org/MathiasHasselmann/NewLayoutManager n0dalus. From limb at jcomserv.net Tue May 1 12:04:57 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 1 May 2007 07:04:57 -0500 (CDT) Subject: CD version gone? In-Reply-To: <46372718.4020700@fedoraproject.org> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> Message-ID: <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> Is it possible to use pungi to create fc7 cds using fc6 and a fc7 repo? The docs state that it isn't. A LiveCD would be too small for my purposes. What about yum upgrades? I've done them for all my machines from FC3 onwards with minor hiccups. Will the new PATA system cause me fstab headaches? > Jon Ciesla wrote: >> That could be a huge problem for me. I have no DVD drives, and several >> production fc6 machines with heavy reliance on things that would >> traditionally have been on CD 4 or 5, or in (the artist formerly known >> as) >> Extras. I suppose yum based upgrades are still offically unsupported? >> >> Is there a way users could spin their own CD set, with all packages, >> using >> only FC6 and yum? > > Both of these tools are in the repository. > > pungi - https://hosted.fedoraproject.org/projects/pungi > livecd-tools - http://fedoraproject.org/wiki/FedoraLiveCD/ > > Rahul > -- novus ordo absurdum From rdieter at math.unl.edu Tue May 1 12:29:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 01 May 2007 07:29:14 -0500 Subject: repotag in EPEL References: <1177541584.17572.3.camel@lincoln> <46304EFC.5000303@leemhuis.info> <1177690733.10685.15.camel@cmn3.stanford.edu> <20070428095815.GC18891@neu.nirvana> <1177851508.4390.16.camel@localhost.localdomain> <20070429152130.GB15091@neu.nirvana> <1177890118.3836.5.camel@localhost.localdomain> <20070430015053.GB25998@neu.nirvana> <1177939835.3836.47.camel@localhost.localdomain> <1177967603.7337.66.camel@cmn3.stanford.edu> <463703EA.4080108@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > Fernando Lopez-Lezcano schrieb: >> [...] >> AFAIK repotags have not caused technical >> problems when used, they _have_ been useful, and they work now. > > repotags are part of the release and as such they influence the > version-comparison when rpm determinates which rpm package is the > newest. Some people call that a "technical problem". > > In other words: the repo with the "highest" repotag wins: > > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at > 0:1.1-5.at is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel > 0:1.1-5.epel is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf > 0:1.1-5.rf is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz > 0:1.1-5.zzzzzzzzzz is newer That doesn't fly with me. Compare that with the repotag-less situation of each repo providing packages with *identical* EVR's. Which is worse? -- Rex From waustin at speakeasy.net Tue May 1 12:38:26 2007 From: waustin at speakeasy.net (William W. Austin) Date: Tue, 01 May 2007 08:38:26 -0400 Subject: acctcom for linux Message-ID: <1178023106l.10587l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> I recently made several updates to a Linux version of of acctcom (actually another accounting add-on package) which I've been using for several years, and one of the people testing it asked a question which I cannot answer. I'm hoping that someone on this list can give me some info. I have previously (over a year ago) asked on both this and a couple of kernel lists (several times there) about this issue, but nobody has ever answered. So if you have any info about this, I'd really appreciate it. As in many (all?) previous Linux kernels, the struct acct (defined in /usr/include/sys/acct.h) has members ac_io and ac_rw which are presumably counts of characters transferred and blocks read/written respectively. However, in the kernel code, the ac_io is set to 0 and the ac_rw gets set to (ac_io/512) or some such - it is set to 0 as well (and thus these are always reported as 0 in process accounting records. not good if you're trying to measure them...). Does anybody know why this is done that way? A long time ago (IIRC late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the kernel code but was not successful (I finally produced a bootable kernel, but it was unstable. Then I changed jobs, got swamped at work, and eventually gave up). As I said above, I have previously asked about this issue without success, and I have essentially given up changing or "fixing" it. But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's just too much work for too little added value), I'd really appreciate knowing the reason. Curiosity and the cat and all that ... Thanks - Bill -- william w. austin waustin at speakeasy.net "life is just another phase i'm going through. this time, anyway ..." From drago01 at gmail.com Tue May 1 12:41:08 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 01 May 2007 14:41:08 +0200 Subject: CD version gone? In-Reply-To: <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> Message-ID: <46373564.8030107@gmail.com> Jon Ciesla wrote: > Is it possible to use pungi to create fc7 cds using fc6 and a fc7 repo? > The docs state that it isn't. A LiveCD would be too small for my purposes. > > What about yum upgrades? I've done them for all my machines from FC3 > onwards with minor hiccups. Will the new PATA system cause me fstab > headaches? > only if you don't mount by label From paul at city-fan.org Tue May 1 12:59:10 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 01 May 2007 13:59:10 +0100 Subject: CD version gone? In-Reply-To: <46373564.8030107@gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> <46373564.8030107@gmail.com> Message-ID: <4637399E.4060907@city-fan.org> dragoran wrote: > Jon Ciesla wrote: >> Is it possible to use pungi to create fc7 cds using fc6 and a fc7 >> repo? The docs state that it isn't. A LiveCD would be too small for my >> purposes. >> >> What about yum upgrades? I've done them for all my machines from FC3 >> onwards with minor hiccups. Will the new PATA system cause me fstab >> headaches? >> > only if you don't mount by label I don't think that's right; the PATA drivers in FC7 are modules rather than being compiled into the kernel, and will hence need an appropriate entry in modprobe.conf making so that the initrd includes the necessary module(s). Anaconda will do this but I don't think anything in the yum upgrade process will take care of this. Paul. From katzj at redhat.com Tue May 1 12:58:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 May 2007 08:58:01 -0400 Subject: CD version gone? In-Reply-To: <4637399E.4060907@city-fan.org> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> <46373564.8030107@gmail.com> <4637399E.4060907@city-fan.org> Message-ID: <1178024281.13694.26.camel@aglarond.local> On Tue, 2007-05-01 at 13:59 +0100, Paul Howarth wrote: > dragoran wrote: > > Jon Ciesla wrote: > >> Is it possible to use pungi to create fc7 cds using fc6 and a fc7 > >> repo? The docs state that it isn't. A LiveCD would be too small for my > >> purposes. > >> > >> What about yum upgrades? I've done them for all my machines from FC3 > >> onwards with minor hiccups. Will the new PATA system cause me fstab > >> headaches? > >> > > only if you don't mount by label > > I don't think that's right; the PATA drivers in FC7 are modules rather > than being compiled into the kernel, and will hence need an appropriate > entry in modprobe.conf making so that the initrd includes the necessary > module(s). Anaconda will do this but I don't think anything in the yum > upgrade process will take care of this. mkinitrd is actually pretty smart about this these days; the entries in modprobe.conf are used as hints to ordering more than anything else Jeremy From ajackson at redhat.com Tue May 1 12:37:25 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 01 May 2007 08:37:25 -0400 Subject: Blank screen and no xv video In-Reply-To: <1177990485.3440.25.camel@tuxhugs> References: <20070430182742.671e6b24@lain.camperquake.de> <1177977739.7754.10.camel@localhost.localdomain> <1177990485.3440.25.camel@tuxhugs> Message-ID: <1178023045.19526.33.camel@localhost.localdomain> On Mon, 2007-04-30 at 20:34 -0700, Peter Gordon wrote: > On Tue, 2007-05-01 at 01:02 +0100, Jon Burgess wrote: > > Have you tried disabling DRI? > > Option "DRI" "off" > > Not sure if this is still the case, but XVideo on Intel IGP, so far as I > understand, uses OpenGL textures instead of drawing to the raw hardware; > so without DRI, you don't get usable XVideo, either... XV may or may not work at all on the intel driver without DRI enabled; I haven't checked, and tbh I can't imagine wanting to run without DRI, ever. It's entirely possible to use the texture engine without using OpenGL though, if you happen to be the driver itself. If Xv working requires DRI to be disabled, that's clearly a bug. - ajax From limb at jcomserv.net Tue May 1 13:02:09 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 1 May 2007 08:02:09 -0500 (CDT) Subject: CD version gone? In-Reply-To: <1178024281.13694.26.camel@aglarond.local> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> <46373564.8030107@gmail.com> <4637399E.4060907@city-fan.org> <1178024281.13694.26.camel@aglarond.local> Message-ID: <48139.65.192.24.190.1178024529.squirrel@mail.jcomserv.net> If I can be reasonably sure that I can upgrade fedora-release, run yum upgrade, reboot, and have all my drives show up, I'm happy. I;ve just really loved upgrading with yum, because it minimizes downtime. Add to that the flaky CD drives on some of my machines, and you see why this is important. To me, at least. Are there any precautions I should take? > On Tue, 2007-05-01 at 13:59 +0100, Paul Howarth wrote: >> dragoran wrote: >> > Jon Ciesla wrote: >> >> Is it possible to use pungi to create fc7 cds using fc6 and a fc7 >> >> repo? The docs state that it isn't. A LiveCD would be too small for >> my >> >> purposes. >> >> >> >> What about yum upgrades? I've done them for all my machines from FC3 >> >> onwards with minor hiccups. Will the new PATA system cause me fstab >> >> headaches? >> >> >> > only if you don't mount by label >> >> I don't think that's right; the PATA drivers in FC7 are modules rather >> than being compiled into the kernel, and will hence need an appropriate >> entry in modprobe.conf making so that the initrd includes the necessary >> module(s). Anaconda will do this but I don't think anything in the yum >> upgrade process will take care of this. > > mkinitrd is actually pretty smart about this these days; the entries in > modprobe.conf are used as hints to ordering more than anything else > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jwilson at redhat.com Tue May 1 13:17:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 01 May 2007 09:17:21 -0400 Subject: F7T4: HD-5500 digital HDTV card In-Reply-To: References: Message-ID: <46373DE1.6030103@redhat.com> Pat Kane wrote: > > I just installed F7T4 on my DELL Dimension 1100 test box that has a > HD-550 pcHDTV > > card. The card is detected (see attached dmesg output), but the > /dev/ entries are not > > present. > > I dropped a zero, that should read HD-5500. Figured as much... Basically, at some point in recent history, the addition of support for (iirc) the HVR-1300 broke cx88-dvb module auto-loading. This has been fixed in the upstream v4l/dvb tree. The most recent FC6 kernels have this patch backported, but may not have made its way into 2.6.21. > Some interesting lines > from the dmesg output are given below, > what does " intel_rng: Firmware space is locked read-only...." mean? Not sure exactly, but it shouldn't have anything to do with the HD-5500. I suspect all you need to do right now is 'modprobe cx88-dvb' and your HD-5500 should be fine. One way or another, the need to do that should be eliminated soonish, but in the interim, create a shell scrip /etc/sysconfig/modules/dvb.modules that does nothing more than modprobe cx88-dvb and you should be good to go. -- Jarod Wilson jwilson at redhat.com From tmus at tmus.dk Tue May 1 13:17:33 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 01 May 2007 15:17:33 +0200 Subject: F7T4 install problems on VMware... In-Reply-To: <1178013684.3299.9.camel@sb-home.lan> References: <1178013684.3299.9.camel@sb-home.lan> Message-ID: nodata wrote: > Am Montag, den 30.04.2007, 23:34 +0200 schrieb Thomas M Steenholdt: >> Hi there... >> >> I've been trying to install F7T4 on VMware workstation 6 (RC) but haven >> been successful yet. Have tried both i386 and x86_64 and the same thing >> happens every time. When anaconda has built dependencies and is ready to >> proceed, anaconda bails, leaving a python backtrace on the screen. I >> have the option to save the debug info to a floppy, but that doesn't >> work either. >> >> I just wanted to know if this is a known issue that I've missed. Perhaps >> a problem with the not-yet-final VMware Workstation 6 or if I need to >> file a bug. >> >> /Thomas >> > > Works for me. Did you check the md5sum and use the non-default SCSI > driver? > Tried buslogic/lsilogic and IDE, all with same results... However Wolfe was really close to my problem earlier in this thread - I'll get some info out soon... /Thomas From tcallawa at redhat.com Tue May 1 13:28:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 May 2007 08:28:17 -0500 Subject: Tetris clones In-Reply-To: <4636C729.2000407@kobold.org> References: <4636C729.2000407@kobold.org> Message-ID: <1178026097.3609.13.camel@localhost.localdomain> On Mon, 2007-04-30 at 21:50 -0700, Wart wrote: > It was recently brought to my attention[1] that the bsd-games package > contains 'tetris-bsd', a curses-based tetris clone. This was an > oversight on my part, because if I had paid closer attention during the > review I would have stripped the name 'tetris' and replaced it with > something less objectionable. Now that I know, I'll do that anyway. > > But the bug report is claiming that all tetris clones are illegal and > should be removed, not just the name 'tetris'. What is the legal status > of tetris (and other game) clones? Can we get some "official" word from > a legal department on what is and isn't allowed? As long as the game doesn't use the "Tetris" trademark to describe itself, the game is fine. ~spot From braden at endoframe.com Tue May 1 13:39:46 2007 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 01 May 2007 09:39:46 -0400 Subject: rpms/openvrml/devel .cvsignore, 1.4, 1.5 openvrml.spec, 1.12, 1.13 sources, 1.4, 1.5 In-Reply-To: <20070501104724.ecf2fe95.mschwendt.tmp0701.nospam@arcor.de> References: <200705010121.l411Lmt3014949@cvs-int.fedora.redhat.com> <20070501104724.ecf2fe95.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1178026786.3602.15.camel@hinge.endoframe.net> On Tue, 2007-05-01 at 10:47 +0200, Michael Schwendt wrote: > On Mon, 30 Apr 2007 21:21:48 -0400, Braden McDaniel (braden) wrote: > > > Author: braden > > > > Update of /cvs/extras/rpms/openvrml/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14903/devel > > > -%package gtkplug > > This breaks dependencies of previously released packages. > > When taking away a sub-package, don't forget proper "Obsoletes" > (and "Provides" if the pkg content is still available in the renamed > package). Done, thanks. (I had initially made this change, but then removed it when rpmlint complained about "Obsoletes without Provides". Since an executable name has changed, I'm fairly sure Provides is inappropriate.) -- Braden McDaniel e-mail: Jabber: From kevin.kofler at chello.at Tue May 1 13:37:00 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 13:37:00 +0000 (UTC) Subject: Tetris clones References: <4636C729.2000407@kobold.org> <1178026097.3609.13.camel@localhost.localdomain> Message-ID: Tom "spot" Callaway redhat.com> writes: > As long as the game doesn't use the "Tetris" trademark to describe > itself, the game is fine. So if someone were to submit Gnometris renamed to something without "tris" in it, it would be accepted? (Not that I'm going to do it, I have KSirtet already. ;-) ) Can't this be done in gnome-games then? Kevin Kofler From alan at redhat.com Tue May 1 13:54:08 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 1 May 2007 09:54:08 -0400 Subject: Tetris clones In-Reply-To: <1178026097.3609.13.camel@localhost.localdomain> References: <4636C729.2000407@kobold.org> <1178026097.3609.13.camel@localhost.localdomain> Message-ID: <20070501135408.GA6174@devserv.devel.redhat.com> On Tue, May 01, 2007 at 08:28:17AM -0500, Tom spot Callaway wrote: > > should be removed, not just the name 'tetris'. What is the legal status > > of tetris (and other game) clones? Can we get some "official" word from > > a legal department on what is and isn't allowed? > > As long as the game doesn't use the "Tetris" trademark to describe > itself, the game is fine. Tetris is one to be very careful about as the Tetris company have a reputation for causing legal trouble. From jonathan.underwood at gmail.com Tue May 1 14:07:04 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 1 May 2007 15:07:04 +0100 Subject: Tetris clones In-Reply-To: <20070501135408.GA6174@devserv.devel.redhat.com> References: <4636C729.2000407@kobold.org> <1178026097.3609.13.camel@localhost.localdomain> <20070501135408.GA6174@devserv.devel.redhat.com> Message-ID: <645d17210705010707k19f7263asfffbcf3ebbdf9261@mail.gmail.com> On 01/05/07, Alan Cox wrote: > On Tue, May 01, 2007 at 08:28:17AM -0500, Tom spot Callaway wrote: > > > should be removed, not just the name 'tetris'. What is the legal status > > > of tetris (and other game) clones? Can we get some "official" word from > > > a legal department on what is and isn't allowed? > > > > As long as the game doesn't use the "Tetris" trademark to describe > > itself, the game is fine. > > Tetris is one to be very careful about as the Tetris company have a reputation > for causing legal trouble. > A long discussion on precisely this issue can be found (without any real resolution) here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225726 [I just checked the emacs-devel mailing list archives, and as far as I can tell, noone has brought the whole matter to the attention of upstream.] Jonathan,. From sundaram at fedoraproject.org Tue May 1 15:44:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 21:14:24 +0530 Subject: CD version gone? In-Reply-To: <48139.65.192.24.190.1178024529.squirrel@mail.jcomserv.net> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <46371B57.10302@gmail.com> <46371C71.9050703@fedoraproject.org> <41841.65.192.24.190.1178018780.squirrel@mail.jcomserv.net> <46372718.4020700@fedoraproject.org> <43995.65.192.24.190.1178021097.squirrel@mail.jcomserv.net> <46373564.8030107@gmail.com> <4637399E.4060907@city-fan.org> <1178024281.13694.26.camel@aglarond.local> <48139.65.192.24.190.1178024529.squirrel@mail.jcomserv.net> Message-ID: <46376058.5000202@fedoraproject.org> Jon Ciesla wrote: > If I can be reasonably sure that I can upgrade fedora-release, run yum > upgrade, reboot, and have all my drives show up, I'm happy. I;ve just > really loved upgrading with yum, because it minimizes downtime. Add to > that the flaky CD drives on some of my machines, and you see why this is > important. To me, at least. > > Are there any precautions I should take? Take a backup and don't top post. Rahul From woodard at redhat.com Tue May 1 15:48:27 2007 From: woodard at redhat.com (Ben Woodard) Date: Tue, 01 May 2007 08:48:27 -0700 Subject: Size does matter!!! In-Reply-To: <1178018514.3777.37.camel@localhost.localdomain> References: <1178018514.3777.37.camel@localhost.localdomain> Message-ID: <4637614B.1040007@redhat.com> Rodd Clarkson wrote: > Why are the open and save file dialogs so small. > > I have a 1920x1200 screen, and yet I have to resize these dialogs each > time they open so I can do complex (he he) tasks like find a file, or > select a folder in which files might be. Remember some of us still do most of our work on laptops that only have a 1024x768 display. I know that a few years ago most of the main gnome-developers did most of their work off of laptops. > > The damn dialog is so small I can't see more than 12 letters in a file > name and I can see two places (one of which is Search). > > Surely something should be done about this, so who do I nag senseless? > > > R. > > -- -ben -=- From tromey at redhat.com Tue May 1 15:35:00 2007 From: tromey at redhat.com (Tom Tromey) Date: Tue, 01 May 2007 09:35:00 -0600 Subject: Tetris clones In-Reply-To: <645d17210705010707k19f7263asfffbcf3ebbdf9261@mail.gmail.com> (Jonathan Underwood's message of "Tue\, 1 May 2007 15\:07\:04 +0100") References: <4636C729.2000407@kobold.org> <1178026097.3609.13.camel@localhost.localdomain> <20070501135408.GA6174@devserv.devel.redhat.com> <645d17210705010707k19f7263asfffbcf3ebbdf9261@mail.gmail.com> Message-ID: >>>>> "Jonathan" == Jonathan Underwood writes: Jonathan> A long discussion on precisely this issue can be found (without any Jonathan> real resolution) here: Jonathan> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225726 Jonathan> [I just checked the emacs-devel mailing list archives, and as far as I Jonathan> can tell, noone has brought the whole matter to the attention of Jonathan> upstream.] Unfortunately it seems that RMS already said he doesn't think there is a problem: http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00916.html On the other hand the other discussion in that thread seems a bit inconclusive as well... as in, perhaps renaming the menu item and the buffer name "Tetris" to "Falling Blocks Wink Wink" might be sufficient. Tom From pemboa at gmail.com Tue May 1 16:09:51 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 1 May 2007 11:09:51 -0500 Subject: Size does matter!!! In-Reply-To: <1178018514.3777.37.camel@localhost.localdomain> References: <1178018514.3777.37.camel@localhost.localdomain> Message-ID: <16de708d0705010909i2e2b762bv6e8e2072fa79c734@mail.gmail.com> On 5/1/07, Rodd Clarkson wrote: > Why are the open and save file dialogs so small. > > I have a 1920x1200 screen, and yet I have to resize these dialogs each > time they open so I can do complex (he he) tasks like find a file, or > select a folder in which files might be. > > The damn dialog is so small I can't see more than 12 letters in a file > name and I can see two places (one of which is Search). > > Surely something should be done about this, so who do I nag senseless? > > > R. You could just increase your display (and/or desktop) resolution. -- Fedora Core 6 and proud From alan at clueserver.org Tue May 1 16:13:55 2007 From: alan at clueserver.org (alan) Date: Tue, 1 May 2007 09:13:55 -0700 (PDT) Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <200704302126.25636.jkeating@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: On Mon, 30 Apr 2007, Jesse Keating wrote: > On Monday 30 April 2007 20:44:03 Kevin Kofler wrote: >> How is KDE on Fedora less integrated? Why do you think people like Than >> Ngo, Rex Dieter, Sebastian Vahl or me work our behinds off to fix things >> like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 >> which is now finally fixed (thanks also to a developer from Pardus who made >> a one-line fix to my patch to get it to work instead of crashing)? (In >> fact, we have to specifically fix what your GNOME developers break, but >> that's another issue.) > > All our system config tools are GTK. The installer is GTK. Our applications > like gnome-power-manager and NetworkManager and smolt and etc.. are all GTK. > Our work went into GDM to improve login experience. Our Fast User Switching > is designed for gnome. I can go on and on. These aren't bad things, they're > just the way they are. The network config tools need some work. (Especially for Wireless.) I have been trying to get my bcm4306 chipset wireless to work. The network tools don't see it. (And I have the firmware that I used on FC6 with no problems.) The list of wireless cards in the drop down list seems very old. It needs to be updated to the currently supported list. (As much as wireless is at this point...) -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From jkeating at redhat.com Tue May 1 16:18:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 1 May 2007 12:18:40 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: <200705011218.40648.jkeating@redhat.com> On Tuesday 01 May 2007 12:13:55 alan wrote: > The network config tools need some work. ?(Especially for Wireless.) ?I > have been trying to get my bcm4306 chipset wireless to work. ?The network > tools don't see it. ?(And I have the firmware that I used on FC6 with no > problems.) ?The list of wireless cards in the drop down list seems very > old. ?It needs to be updated to the currently supported list. ?(As much as > wireless is at this point...) Modulo getting the firmware in place, try NetworkManager. Dead simple easy tool for using networks. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Tue May 1 16:21:47 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 16:21:47 +0000 (UTC) Subject: Announcing Fedora 7 Test 4 (6.93) References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > All our system config tools are GTK. The installer is GTK. Our applications > like gnome-power-manager and NetworkManager and smolt and etc.. are all GTK. That's undeniable fact, but from there to saying that KDE "is not our best foot forward", it's a big leap. Heck, Mandriva uses KDE as their default desktop and yet most of their admin tools at least used to be written in GTK+ (I'm not sure if they still are). Seamless integration is not simply a matter what toolkit the apps use. IMHO, the best way to achieve integration is to use a common theme for both GNOME and KDE. And in fact Fedora even ships one, too bad it's no longer the default. :-( But I may well be the only one still using Bluecurve... > Our work went into GDM to improve login experience. Our Fast User Switching > is designed for gnome. I can go on and on. Yes, upstream GNOME is getting new features, and yes, several Red Hat / Fedora developers are actively involved in that. But this doesn't mean nobody is working on adding features to KDE. (Just look at what's being done for KDE 4.0, for example.) Probably even some of the same features. (KDM already supports user images, for example, and has for some time already.) The fact that the work isn't done by Red Hat developers doesn't mean it isn't good software for Fedora to ship. Kevin Kofler From katzj at redhat.com Tue May 1 16:23:17 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 May 2007 12:23:17 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: <1178036597.12563.3.camel@erebor.boston.redhat.com> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > On Mon, 30 Apr 2007, Jesse Keating wrote: > > > On Monday 30 April 2007 20:44:03 Kevin Kofler wrote: > >> How is KDE on Fedora less integrated? Why do you think people like Than > >> Ngo, Rex Dieter, Sebastian Vahl or me work our behinds off to fix things > >> like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 > >> which is now finally fixed (thanks also to a developer from Pardus who made > >> a one-line fix to my patch to get it to work instead of crashing)? (In > >> fact, we have to specifically fix what your GNOME developers break, but > >> that's another issue.) > > > > All our system config tools are GTK. The installer is GTK. Our applications > > like gnome-power-manager and NetworkManager and smolt and etc.. are all GTK. > > Our work went into GDM to improve login experience. Our Fast User Switching > > is designed for gnome. I can go on and on. These aren't bad things, they're > > just the way they are. > > The network config tools need some work. (Especially for Wireless.) I > have been trying to get my bcm4306 chipset wireless to work. The network > tools don't see it. (And I have the firmware that I used on FC6 with no > problems.) For the new driver, I think you need newer firmware. Unfortunately, the firmware for the Broadcom isn't freely redistributable and thus we can't ship one so it can work out of the box. Jeremy From chasd at silveroaks.com Tue May 1 16:29:46 2007 From: chasd at silveroaks.com (chasd) Date: Tue, 1 May 2007 11:29:46 -0500 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <20070430144715.EB64A7332F@hormel.redhat.com> References: <20070430144715.EB64A7332F@hormel.redhat.com> Message-ID: <55FA31B6-2FD5-4C42-9CCE-63CA8E0904EC@silveroaks.com> I realize I am late on this thread, but I include my 2 US cents -- On Apr 30, 2007, Max Spevack wrote: > Most importantly: call something what it is, and *don't* give > something a > name that doesn't make it clear what it is. > > As such, several of our names made a lot of sense: > > Fedora 7 Gnome Live CD > Fedora 7 KDE Live CD > Fedora 7 Everything I think "Everything" isn't descriptive enough, and "Fedora" without any qualifiers isn't enough either. My recommendation : Fedora 7 Base Install ( CD or DVD ) Fedora 7 Base Live CD ( also installable ) Fedora 7 KDE Live CD ( also installable ) Fedora 7 Inclusive Repository ( network Installable ) The "Base" spin is what all other spins are based on, but it is not a "basic" installation. I think the old word "Core" had too many connotations about how small the installation was. The term "Base" in some ways is similar to the term "Core" , but does not seem to indicate "small." The word "Everything" is too nebulous for me. Maybe "Inclusive" is not the best term either, but it gets closer to what I think describes that repo. Sorry, the term "Prime" only makes me think of a specific member of the Transformers. Now back to your regularly scheduled programming . . . Charles Dostale From kevin.kofler at chello.at Tue May 1 16:24:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 1 May 2007 16:24:52 +0000 (UTC) Subject: Announcing Fedora 7 Test 4 (6.93) References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > All our system config tools are GTK. The installer is GTK. Our applications > like gnome-power-manager and NetworkManager and smolt and etc.. are all GTK. Oh, and NetworkManager is UI-independent and also has a KDE frontend, KNetworkManager, which is already in Extras. Kevin Kofler From jdieter at gmail.com Tue May 1 16:34:45 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 01 May 2007 19:34:45 +0300 Subject: Yum-presto 0.3.10 Message-ID: <1178037285.3855.82.camel@jndwidescreen.lesbg.loc> Just a quick note to say yum-presto 0.3.10 (which will be the last in the 0.3 series) is now in the presto repository with some fixes and a few new issues to deal with. For more information about yum-presto, check out http://hosted.fedoraproject.org/projects/presto. First off, the fixes: * A "*" is added to the repository of a deltarpm'd package in the package list. There used to be one by the name of the package, but that screwed up depsolving. It shouldn't cause any problems next to the repository. * Yum-presto is now able to validate two packages with the same name but different arches correctly. This was actually a bug in deltarpm, and upstream has provided a patch to fix the problem. I have pushed a new version of deltarpm with the upstream patch to the presto repository that goes with the new version of yum-presto. I have also reworked the presto repository so that it should work correctly for fc6 and devel for the i386 and x86_64 arches. Get the new repo file at http://www.lesbg.com/jdieter/presto/yum-presto.repo. The old repository file points to FC6 i386. I will *not* push the new version to either FC-6 or devel until the new version of deltarpm has been pushed. I'm also not sure whether the development freeze applies to presto (as it's *not* being included by default in F7). Just a heads up that there are many i386 packages in the x86_64 distribution that will *not* have deltarpms. This is because rpm uses file-colors to keep the the 32 bit binary from overwriting the 64 bit binary for any packages that store files in /bin, /usr/bin, /sbin, and /usr/sbin (and there may be other locations). Deltarpm can't build the new rpm when these files are missing. I'm not sure what the long-term solution is (though there seems to be some debate on that on fedora-maintainers). The next version of yum-presto will attempt to rebuild files from rpms kept in the cache, if they're available and may (if I can work out a good method) make deltas of the repository data. I will also remove the ability to set presto repositories in the presto.conf file. This information should be either built into the repomd.xml file or the repositories' .repo files. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Tue May 1 16:38:36 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 01 May 2007 12:38:36 -0400 Subject: OT: Re: Pidgin Icons gone In-Reply-To: <1177944840.19526.2.camel@localhost.localdomain> References: <6bb886180704191918l2d5262c9jed01b2d6ce9339ec@mail.gmail.com> <1177065405.25513.70.camel@vader.jdub.homelinux.org> <1177852886.4390.28.camel@localhost.localdomain> <1177944840.19526.2.camel@localhost.localdomain> Message-ID: <1178037516.19384.6.camel@localhost.localdomain> On Mon, 2007-04-30 at 10:54 -0400, Adam Jackson wrote: > On Sun, 2007-04-29 at 08:21 -0500, Tom "spot" Callaway wrote: > > On Fri, 2007-04-20 at 05:36 -0500, Josh Boyer wrote: > > > On Fri, 2007-04-20 at 12:18 +1000, David Hunter wrote: > > > > Since the demise of Gaim being replaced with pidgin, many of the old > > > > Icons from gaim have been changed. Any way to get them back? or is it > > > > a change for good? Is it a bug or known issue? > > > > > > As I understand it, the icons included with pidgin are _the_ icons for > > > the package now. I don't think it's a bug. > > > > Unfortunately they're hideous. Does anyone know of a slightly less > > horrible icon set for pidgin? > > There was a nice set in this other IM program. G-something, I think. In a fit of rage, I did a palette swap on the vomit-green bits of the pidgin icons to be more like fedora blue. RPMs here: http://people.redhat.com/ajackson/pidgin/ Much nicer, IMO. Might be something we actually want to ship. Unfortunately the only theming support I saw in gai^Wpidgin is for smilies, and nothing else, so it's not quite as simple as just making it inherit from Echo or whatever. Hooray for halfhearted Gnome integration. - ajax From jamatos at fc.up.pt Tue May 1 17:11:34 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 1 May 2007 18:11:34 +0100 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <200704302126.25636.jkeating@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: <200705011811.34507.jamatos@fc.up.pt> On Tuesday 01 May 2007 05:26:25 Jesse Keating wrote: > > All our system config tools are GTK. The installer is GTK. Our > applications like gnome-power-manager and NetworkManager and smolt and > etc.. are all GTK. If you referring to GTK in the sense of look and feel, this is is odd. I don't consider GTK to be Gnome the same way that I don't consider qt-based applications to be KDE. I reserve that classification to a closer integration with the desktop, AFAIK this is not the case of the system-tools. :-) We are not in the nineties anymore. ;-) > Our work went into GDM to improve login experience. Our > Fast User Switching is designed for gnome. I can go on and on. These > aren't bad things, they're just the way they are. OK. Nevertheless they are small comparative advantages of GNOME related with KDE in Fedora. :-) That is why there Fedora KDE users after all, we are not masochists, you know? ;-) Notice that the point that Kevin stressed remains, public relations are important and you words can be placed out of context quite easily. :-) Things have been improving a lot, and nowadays I can notice that I am using Fedora no matter what the DE I am using (even on XFCE FWIW) and that is more visible to me than the differences between the DE's. So even if I understand what you mean the communication is important and believe me KDE in Fedora feels like Fedora, and sometimes this seems a difficult message to pass, both inside and outside Fedora. :-) -- Jos? Ab?lio From lsof at nodata.co.uk Tue May 1 17:49:40 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 01 May 2007 19:49:40 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <55FA31B6-2FD5-4C42-9CCE-63CA8E0904EC@silveroaks.com> References: <20070430144715.EB64A7332F@hormel.redhat.com> <55FA31B6-2FD5-4C42-9CCE-63CA8E0904EC@silveroaks.com> Message-ID: <1178041780.3305.5.camel@sb-home.lan> Am Dienstag, den 01.05.2007, 11:29 -0500 schrieb chasd: > My recommendation : > > Fedora 7 Base Install ( CD or DVD ) > Fedora 7 Base Live CD ( also installable ) > Fedora 7 KDE Live CD ( also installable ) > Fedora 7 Inclusive Repository ( network Installable ) > Nobody but technical people will follow what "base" or "base install" means, let alone "Inclusive Repository". From michael.wiktowy at gmail.com Tue May 1 18:21:59 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 1 May 2007 14:21:59 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <200704300741.54753.jkeating@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <46360002.4020702@fedoraproject.org> <200704300741.54753.jkeating@redhat.com> Message-ID: <3e4ec4600705011121q135f3071k9587e1bdd607e2ea@mail.gmail.com> On 4/30/07, Jesse Keating wrote: > On Monday 30 April 2007 07:41:06 Rahul Sundaram wrote: > > > The answer, Rahul, is that "it depends". > > > > To make it clear, in the website and the announcement do you agree that > > we need to call it the "Fedora 7 GNOME live CD"? > > No. The Fedora Live is simple enough. It is different from the Fedora KDE > Live. Why not Fedora 7 "Standard" LiveCD/Install? "Standard" has good, clear, non-techie-comprehendable connotations and is something that other variants are compared to. It is not the best or the worst ... just the most "known" reference. Fedora 7 GNOME LiveCD can be reserved for someone who wants to put out a "pure" GNOME spin. Other variants can be named after how they vary from the standard. /Mike From michael.wiktowy at gmail.com Tue May 1 18:15:28 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 1 May 2007 14:15:28 -0400 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <1178041780.3305.5.camel@sb-home.lan> References: <20070430144715.EB64A7332F@hormel.redhat.com> <55FA31B6-2FD5-4C42-9CCE-63CA8E0904EC@silveroaks.com> <1178041780.3305.5.camel@sb-home.lan> Message-ID: <3e4ec4600705011115n19b8b112u6c0c3ebf89b16b44@mail.gmail.com> On 5/1/07, nodata wrote: > Am Dienstag, den 01.05.2007, 11:29 -0500 schrieb chasd: > > My recommendation : > > > > Fedora 7 Base Install ( CD or DVD ) > > Fedora 7 Base Live CD ( also installable ) > > Fedora 7 KDE Live CD ( also installable ) > > Fedora 7 Inclusive Repository ( network Installable ) > > > > Nobody but technical people will follow what "base" or "base install" > means, let alone "Inclusive Repository". I agree ... how about: Fedora 7 Standard Install/LiveCD (containing a well-integrated default selection suitable for the new Linux user ... GNOME desktop with tweaks) As "standard" has a well known, non-techie meaning of something default or some reference that you can compare other similar things to (i.e. the gold standard) Other spins can be named by their main feature that deviates from the standard: Fedora 7 GNOME Install/LiveCD (with "pure" GNOME desktop) Fedora 7 KDE Install/LiveCD (with "pure" KDE desktop) Fedora 7 XFCE Install/LiveCD (with "pure" XFCE desktop) Fedora 7 Rescue LiveCD (with all the tools needed to fix things) Fedora 7 World DVD (with everything you can cram on a DVD and more) Just a thought, /Mike From nando at ccrma.Stanford.EDU Tue May 1 18:25:41 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 01 May 2007 11:25:41 -0700 Subject: repotag in EPEL In-Reply-To: <463703EA.4080108@leemhuis.info> References: <1177541584.17572.3.camel@lincoln> <46304EFC.5000303@leemhuis.info> <1177690733.10685.15.camel@cmn3.stanford.edu> <20070428095815.GC18891@neu.nirvana> <1177851508.4390.16.camel@localhost.localdomain> <20070429152130.GB15091@neu.nirvana> <1177890118.3836.5.camel@localhost.localdomain> <20070430015053.GB25998@neu.nirvana> <1177939835.3836.47.camel@localhost.localdomain> <1177967603.7337.66.camel@cmn3.stanford.edu> <463703EA.4080108@leemhuis.info> Message-ID: <1178043941.10528.50.camel@cmn3.stanford.edu> On Tue, 2007-05-01 at 11:10 +0200, Thorsten Leemhuis wrote: > Fernando Lopez-Lezcano schrieb: > > [...] > > AFAIK repotags have not caused technical > > problems when used, they _have_ been useful, and they work now. > > repotags are part of the release and as such they influence the > version-comparison when rpm determinates which rpm package is the > newest. Some people call that a "technical problem". How is having a repotag in the "Release:" tag semantically _different_ from having only a number and an optional disttag? > In other words: the repo with the "highest" repotag wins: > > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5 0 1.1 5.at > 0:1.1-5.at is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.at 0 1.1 5.epel > 0:1.1-5.epel is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.epel 0 1.1 5.rf > 0:1.1-5.rf is newer > [thl at notebook ~]$ rpmdev-vercmp 0 1.1 5.rf 0 1.1 5.zzzzzzzzzz > 0:1.1-5.zzzzzzzzzz is newer > > > [...] If I may state the obvious, any component of the "Release:" tag influences the ordering. The numbers there do that, the distag there (if present) does that and the repotag there does that as well. None of the components have a magical meaning that makes it right[1]. Within a given repository the "extra" components (disttag, repotag) are irrelevant as they are a constant. The arbitrary number(s) at the beginning of the "Release:" tag will determine which package is newer, and hopefully packagers and the build system will keep them sane and nicely e-v-r ordered :-) So, I dare say there are no technical problems within a repository that could be caused by adding a repotag. Release tag comparison between repositories is meaningless. There is no "right way" of comparing between repositories. Having only a number there has the same _meaning_ in comparisons between repositories as having a number, an optional disttag and a repotag. To restate it differently, if an added repotag is a concern because of the fact that it can define the ordering of packages between repositories, then the already existing number there should raise exactly the same concern as it has _exactly_ the same effect. _All_ of the components of the "Release:" tag, when comparing between repositories, are meaningless. So, I dare say there are no technical problems in comparing packages between repositories that could be caused by adding a repotag. [furthermore and in case it was missed, when I wrote "AFAIK repotags have not caused technical problems when used, they _have_ been useful, and they work now." it means what it says, there have NOT been problems with them - there's nothing magical in EPEL that would suddenly cause problems now, I think] -- Fernando [1] you can also add letters, numbers, dates, etc that spill from the "Version:" tag to the "Release:" tag when packaging cvs, svn, beta or rc releases. From Eric.Tanguy at univ-nantes.fr Tue May 1 18:31:02 2007 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Tue, 1 May 2007 20:31:02 +0200 (CEST) Subject: live F7 test4 In-Reply-To: <4633EEA9.8060104@fedoraproject.org> References: <1177753244.3259.7.camel@bureau.maison> <4633EEA9.8060104@fedoraproject.org> Message-ID: <46848.86.195.204.66.1178044262.squirrel@webmail.univ-nantes.fr> > Tanguy Eric wrote: >> I just download the i386 gnome live version and it works fine. Mainly my >> wireless ralink card work out of the box with networkmanager. I just try >> it with broadcast and without security (wpa or wep) without broadcast it >> can't associate. There is a lot of error messages in dmesg but it works >> fine. > > Do file a bug report about this against network manager I will file a bug report against network manager but i have another problem : It seems my wireless card is known as an ethernet one so i can associate with network manager. As my system is a desktop and i don't need to switch network, i would like to disable network manager and use system-config-network but it can't work as my card is known as an ethernet one. My wireless card is a pci one : 02:08.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) Subsystem: SiteCom Europe BV Unknown device 9073 Flags: bus master, slow devsel, latency 64, IRQ 19 Memory at fe000000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 > >> My main question is about mp3 and fluendo codec. I believed that when >> you try to play a mp3 file something say to you some disclaimer and help >> you to install free fluendo mp3 plugin but i found nothing. When i >> installed this plugin i had to run a selinux command (chcon) to make it >> usuable by totem. It's a shame. > > This particular feature is not available in Fedora 7. Once installed it > should work properly. Bug report should be filed against selinux > targeted policy. I need to run : chcon -t textrel_shlib_t /usr/lib/gstreamer-0.10/libgstflump3dec.so as setroubleshoot says. > >> Apart this, it's a beautifull system which works very fine and with >> great improvements. > > Thanks for the feedback. > > Rahul > > Ps: Post to fedora-test list instead of here for test/development branch > issues. > > Rahul > > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > From ville.skytta at iki.fi Tue May 1 19:02:30 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 1 May 2007 22:02:30 +0300 Subject: repotag in EPEL In-Reply-To: References: <1177541584.17572.3.camel@lincoln> <463703EA.4080108@leemhuis.info> Message-ID: <200705012202.30692.ville.skytta@iki.fi> On Tuesday 01 May 2007, Rex Dieter wrote: > Compare that with the repotag-less situation of each repo providing > packages with *identical* EVR's. Which is worse? IMO having several repositories enabled which ship the same packages [0] is already bad enough to make the repotag discussion pretty much moot. [0] Same as in same software being packaged in packages that aren't *strictly equal*, no matter what the versions are, let alone release, repotag and friends. From tmus at tmus.dk Tue May 1 20:02:55 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 01 May 2007 22:02:55 +0200 Subject: F7T4 install problems on VMware... In-Reply-To: <20070430231735.GA1192@wolves.durham.nc.us> References: <20070430231735.GA1192@wolves.durham.nc.us> Message-ID: G.Wolfe Woodbury wrote: > On Mon, Apr 30, 2007 at 11:34:38PM +0200, Thomas M Steenholdt wrote: >> Hi there... >> >> I've been trying to install F7T4 on VMware workstation 6 (RC) but haven >> been successful yet. Have tried both i386 and x86_64 and the same thing >> happens every time. When anaconda has built dependencies and is ready to >> proceed, anaconda bails, leaving a python backtrace on the screen. I >> have the option to save the debug info to a floppy, but that doesn't >> work either. >> >> I just wanted to know if this is a known issue that I've missed. Perhaps >> a problem with the not-yet-final VMware Workstation 6 or if I need to >> file a bug. >> >> /Thomas > > Everything depends on what the backtrace and error being reported are. > Switch to text console VT2 (ctrl-alt-F2) to get a command window; > then cd to /tmp and cp the file anacdump.txt to a safe location (like > a floppy :-) > > There are a couple of open bugs on anaconda at that poin of the install > and you may want to add information to one of them. > > My question is if it is the LVM/vgchange activation bug. It's kind of > intermittent depending on the memory configuration of the machines. > It looks like you're right... --8<----- Traceback (most recent call first): File "/usr/lib/anaconda/lvm.py", line 63, in lvmExec raise LvmError, args[0] File "/usr/lib/anaconda/lvm.py", line 109, in vgactivate rc = lvmExec(*args) File "/usr/lib/anaconda/partitions.py", line 1323, in doMetaDeletes lvm.vgactivate() File "/usr/lib/anaconda/packages.py", line 143, in turnOnFilesystems anaconda.id.partitions.doMetaDeletes(anaconda.id.diskset) File "/usr/lib/anaconda/dispatch.py", line 203, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/text.py", line 605, in run anaconda.dispatch.gotoNext() File "/usr/bin/anaconda", line 954, in anaconda.intf.run(anaconda) LvmError: vgchange failed Log: Local variables in innermost frame: args: ('vgchange', '-ay', '-v') --8<----- Increasing virtual (VMware) memory to 512M (from 384) allows me to continue... I've added information to bug #236643, i guess that's the one you were thinking of? /Thomas From wwoods at redhat.com Tue May 1 21:09:11 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 01 May 2007 21:09:11 +0000 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> Message-ID: <1178053751.28491.24.camel@metroid.rdu.redhat.com> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > The network config tools need some work. (Especially for Wireless.) I > have been trying to get my bcm4306 chipset wireless to work. The network > tools don't see it. (And I have the firmware that I used on FC6 with no > problems.) The list of wireless cards in the drop down list seems very > old. It needs to be updated to the currently supported list. (As much as > wireless is at this point...) Yeah, you'll want to use NetworkManager to manage the device. First you will need firmware: 1) Install bcm43xx-fwcutter 2) Get a Broadcom-distributed driver to cut the firmware out of # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README # For the newer driver you'll need 4.x firmware. I recommend: http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 3) Unpack the driver and cut out the firmware # tar -jxvf broadcom-wl-*.tar.bz2 # bcm43xx-fwcutter -w /lib/firmware broadcom-wl-*/kmod/wl_apsta.o You might have to blacklist the old driver first if you're using the new one: # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist But at this point you should be able to reboot and have working wireless. Hooray! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwizart at gmail.com Tue May 1 21:21:45 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 1 May 2007 23:21:45 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <1178053751.28491.24.camel@metroid.rdu.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: 2007/5/1, Will Woods : > > On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > > > The network config tools need some work. (Especially for Wireless.) I > > have been trying to get my bcm4306 chipset wireless to work. The > network > > tools don't see it. (And I have the firmware that I used on FC6 with no > > > problems.) The list of wireless cards in the drop down list seems very > > old. It needs to be updated to the currently supported list. (As much > as > > wireless is at this point...) > > Yeah, you'll want to use NetworkManager to manage the device. First you > will need firmware: > > 1) Install bcm43xx-fwcutter > 2) Get a Broadcom-distributed driver to cut the firmware out of > # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > # For the newer driver you'll need 4.x firmware. I recommend: > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > 3) Unpack the driver and cut out the firmware > # tar -jxvf broadcom-wl-*.tar.bz2 > # bcm43xx-fwcutter -w /lib/firmware broadcom-wl-*/kmod/wl_apsta.o > > You might have to blacklist the old driver first if you're using the new > one: > > # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist > > But at this point you should be able to reboot and have working > wireless. Hooray! > > -w > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Thx for this feedback! i will document this on the french wiki for WiFi http://doc.fedora-fr.org/Wifi What do you call newer driver ? is it related to chipset version ? (provided by a lspci output) Nicolas (kwizart) -------------- next part -------------- An HTML attachment was scrubbed... URL: From miles.lane at gmail.com Tue May 1 21:25:26 2007 From: miles.lane at gmail.com (Miles Lane) Date: Tue, 1 May 2007 14:25:26 -0700 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <1178053751.28491.24.camel@metroid.rdu.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: On 5/1/07, Will Woods wrote: > On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > > > The network config tools need some work. (Especially for Wireless.) I > > have been trying to get my bcm4306 chipset wireless to work. The network > > tools don't see it. (And I have the firmware that I used on FC6 with no > > problems.) The list of wireless cards in the drop down list seems very > > old. It needs to be updated to the currently supported list. (As much as > > wireless is at this point...) > > Yeah, you'll want to use NetworkManager to manage the device. First you > will need firmware: > > 1) Install bcm43xx-fwcutter > 2) Get a Broadcom-distributed driver to cut the firmware out of > # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > # For the newer driver you'll need 4.x firmware. I recommend: > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 I'll try this, but I suspect it won't work, because I have a pretty old bcm4306 PCI card in my desktop machine. Last time I checked, my card isn't supported by the 4.x firmware. :-( From alan at clueserver.org Tue May 1 21:25:24 2007 From: alan at clueserver.org (alan) Date: Tue, 1 May 2007 14:25:24 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <1178053751.28491.24.camel@metroid.rdu.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: On Tue, 1 May 2007, Will Woods wrote: > On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > >> The network config tools need some work. (Especially for Wireless.) I >> have been trying to get my bcm4306 chipset wireless to work. The network >> tools don't see it. (And I have the firmware that I used on FC6 with no >> problems.) The list of wireless cards in the drop down list seems very >> old. It needs to be updated to the currently supported list. (As much as >> wireless is at this point...) > > Yeah, you'll want to use NetworkManager to manage the device. First you > will need firmware: > > 1) Install bcm43xx-fwcutter > 2) Get a Broadcom-distributed driver to cut the firmware out of > # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > # For the newer driver you'll need 4.x firmware. I recommend: > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > 3) Unpack the driver and cut out the firmware > # tar -jxvf broadcom-wl-*.tar.bz2 > # bcm43xx-fwcutter -w /lib/firmware broadcom-wl-*/kmod/wl_apsta.o I already have the firmware, but it is the older version. I will get the new one and see if that works. > You might have to blacklist the old driver first if you're using the new > one: > > # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist > > But at this point you should be able to reboot and have working > wireless. Hooray! What is the new driver name? -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From jwilson at redhat.com Tue May 1 21:29:12 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 01 May 2007 17:29:12 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: <4637B128.60206@redhat.com> Miles Lane wrote: > On 5/1/07, Will Woods wrote: >> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: >> >> > The network config tools need some work. (Especially for Wireless.) I >> > have been trying to get my bcm4306 chipset wireless to work. The >> network >> > tools don't see it. (And I have the firmware that I used on FC6 >> with no >> > problems.) The list of wireless cards in the drop down list seems very >> > old. It needs to be updated to the currently supported list. (As >> much as >> > wireless is at this point...) >> >> Yeah, you'll want to use NetworkManager to manage the device. First you >> will need firmware: >> >> 1) Install bcm43xx-fwcutter >> 2) Get a Broadcom-distributed driver to cut the firmware out of >> # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README >> # For the newer driver you'll need 4.x firmware. I recommend: >> http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > > I'll try this, but I suspect it won't work, because I have a pretty > old bcm4306 PCI card in my desktop machine. Last time I checked, my > card isn't supported by the 4.x firmware. :-( Works fine with the bcm4306 in my powerbook. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Tue May 1 21:29:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 01 May 2007 17:29:32 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: <4637B13C.2090403@redhat.com> alan wrote: > On Tue, 1 May 2007, Will Woods wrote: > >> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: >> >>> The network config tools need some work. (Especially for Wireless.) I >>> have been trying to get my bcm4306 chipset wireless to work. The >>> network >>> tools don't see it. (And I have the firmware that I used on FC6 with no >>> problems.) The list of wireless cards in the drop down list seems very >>> old. It needs to be updated to the currently supported list. (As >>> much as >>> wireless is at this point...) >> >> Yeah, you'll want to use NetworkManager to manage the device. First you >> will need firmware: >> >> 1) Install bcm43xx-fwcutter >> 2) Get a Broadcom-distributed driver to cut the firmware out of >> # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README >> # For the newer driver you'll need 4.x firmware. I recommend: >> http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 >> 3) Unpack the driver and cut out the firmware >> # tar -jxvf broadcom-wl-*.tar.bz2 >> # bcm43xx-fwcutter -w /lib/firmware broadcom-wl-*/kmod/wl_apsta.o > > I already have the firmware, but it is the older version. I will get the > new one and see if that works. > >> You might have to blacklist the old driver first if you're using the new >> one: >> >> # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist >> >> But at this point you should be able to reboot and have working >> wireless. Hooray! > > What is the new driver name? Its in the subject. :) (bcm43xx_mac80211) -- Jarod Wilson jwilson at redhat.com From miles.lane at gmail.com Tue May 1 21:35:57 2007 From: miles.lane at gmail.com (Miles Lane) Date: Tue, 1 May 2007 14:35:57 -0700 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <4637B128.60206@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <4637B128.60206@redhat.com> Message-ID: On 5/1/07, Jarod Wilson wrote: > Miles Lane wrote: > > On 5/1/07, Will Woods wrote: > >> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: > >> > >> > The network config tools need some work. (Especially for Wireless.) I > >> > have been trying to get my bcm4306 chipset wireless to work. The > >> network > >> > tools don't see it. (And I have the firmware that I used on FC6 > >> with no > >> > problems.) The list of wireless cards in the drop down list seems very > >> > old. It needs to be updated to the currently supported list. (As > >> much as > >> > wireless is at this point...) > >> > >> Yeah, you'll want to use NetworkManager to manage the device. First you > >> will need firmware: > >> > >> 1) Install bcm43xx-fwcutter > >> 2) Get a Broadcom-distributed driver to cut the firmware out of > >> # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > >> # For the newer driver you'll need 4.x firmware. I recommend: > >> http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > > > > I'll try this, but I suspect it won't work, because I have a pretty > > old bcm4306 PCI card in my desktop machine. Last time I checked, my > > card isn't supported by the 4.x firmware. :-( > > Works fine with the bcm4306 in my powerbook. It probably still won't work for my card. The card revision matters. I found this statement online: "> There is a revision number which is the key for v4 suppport. You'll need > at least revision number 0x4 there for d80211 support. The older > revisions 0x2 and 0x3 have to use the softmac stack." My PCI card is a Linksys card with bcm4306 revision 3. Gak! :-p From chasd at silveroaks.com Tue May 1 21:43:12 2007 From: chasd at silveroaks.com (chasd) Date: Tue, 1 May 2007 16:43:12 -0500 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <20070501183120.C7F3773894@hormel.redhat.com> References: <20070501183120.C7F3773894@hormel.redhat.com> Message-ID: <7BDBE62D-A8B2-479B-835F-F7E4C9C0668E@silveroaks.com> >>> My recommendation : >>> >>> Fedora 7 Base Install ( CD or DVD ) >>> Fedora 7 Base Live CD ( also installable ) >>> Fedora 7 KDE Live CD ( also installable ) >>> Fedora 7 Inclusive Repository ( network Installable ) I tried to answer certain questions with each part of my suggestion What is in it ? What does it do ? What media is it on ? >> Nobody but technical people will follow what "base" or "base install" >> means, let alone "Inclusive Repository". The word "base" is too technical ? I agree "Inclusive" is maybe not the best. I was attempting to indicate that all of the listed spins was included. > As "standard" has a well known, non-techie meaning of something > default or some reference that you can compare other similar things to > (i.e. the gold standard) Standard works for me, it is roughly synonymous with "base." It is better than " " which was the ongoing suggestion. " " doesn't answer anything. > Fedora 7 World DVD (with everything you can cram on a DVD and more) "World" makes me think that's what I need if I want extra language support. For me it doesn't say "All possible applications for Fedora" Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265 From lsof at nodata.co.uk Tue May 1 22:27:34 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 02 May 2007 00:27:34 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <3e4ec4600705011115n19b8b112u6c0c3ebf89b16b44@mail.gmail.com> References: <20070430144715.EB64A7332F@hormel.redhat.com> <55FA31B6-2FD5-4C42-9CCE-63CA8E0904EC@silveroaks.com> <1178041780.3305.5.camel@sb-home.lan> <3e4ec4600705011115n19b8b112u6c0c3ebf89b16b44@mail.gmail.com> Message-ID: <1178058454.3812.34.camel@sb-home.lan> Am Dienstag, den 01.05.2007, 14:15 -0400 schrieb Michael Wiktowy: > On 5/1/07, nodata wrote: > > Am Dienstag, den 01.05.2007, 11:29 -0500 schrieb chasd: > > > My recommendation : > > > > > > Fedora 7 Base Install ( CD or DVD ) > > > Fedora 7 Base Live CD ( also installable ) > > > Fedora 7 KDE Live CD ( also installable ) > > > Fedora 7 Inclusive Repository ( network Installable ) > > > > > > > Nobody but technical people will follow what "base" or "base install" > > means, let alone "Inclusive Repository". > > I agree ... how about: > > Fedora 7 Standard Install/LiveCD (containing a well-integrated default > selection suitable for the new Linux user ... GNOME desktop with > tweaks) > > As "standard" has a well known, non-techie meaning of something > default or some reference that you can compare other similar things to > (i.e. the gold standard) > > Other spins can be named by their main feature that deviates from the standard: > Fedora 7 GNOME Install/LiveCD (with "pure" GNOME desktop) > Fedora 7 KDE Install/LiveCD (with "pure" KDE desktop) > Fedora 7 XFCE Install/LiveCD (with "pure" XFCE desktop) > Fedora 7 Rescue LiveCD (with all the tools needed to fix things) > Fedora 7 World DVD (with everything you can cram on a DVD and more) > > Just a thought, > /Mike > This is all getting too complicated. Maybe that's a sign. Perhaps we should ditch the non-Live CD version of Fedora 7, and just have: * Fedora 7 Live! (with Gnome) * Fedora 7 Live! KDE edition. Plus a note saying the operating system can run from the media directly, or be installed to the hard disk, or used as a rescue disc. On a separate note, I really can't imagine Live discs being used extensively for day to day use- they get no security updates. But this is a separate, and different issue. From lsof at nodata.co.uk Tue May 1 22:33:50 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 02 May 2007 00:33:50 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <7BDBE62D-A8B2-479B-835F-F7E4C9C0668E@silveroaks.com> References: <20070501183120.C7F3773894@hormel.redhat.com> <7BDBE62D-A8B2-479B-835F-F7E4C9C0668E@silveroaks.com> Message-ID: <1178058830.3812.41.camel@sb-home.lan> Am Dienstag, den 01.05.2007, 16:43 -0500 schrieb chasd: > >>> My recommendation : > >>> > >>> Fedora 7 Base Install ( CD or DVD ) > >>> Fedora 7 Base Live CD ( also installable ) > >>> Fedora 7 KDE Live CD ( also installable ) > >>> Fedora 7 Inclusive Repository ( network Installable ) > > I tried to answer certain questions with each part of my suggestion > > What is in it ? > > What does it do ? > > What media is it on ? > > > >> Nobody but technical people will follow what "base" or "base install" > >> means, let alone "Inclusive Repository". > > The word "base" is too technical ? > I agree "Inclusive" is maybe not the best. > I was attempting to indicate that all of the listed spins was included. > > > As "standard" has a well known, non-techie meaning of something > > default or some reference that you can compare other similar things to > > (i.e. the gold standard) > > Standard works for me, it is roughly synonymous with "base." > It is better than " " which was the ongoing suggestion. > " " doesn't answer anything. > > > Fedora 7 World DVD (with everything you can cram on a DVD and more) > > "World" makes me think that's what I need if I want extra language > support. > For me it doesn't say "All possible applications for Fedora" > > > Charles Dostale > System Admin - Silver Oaks Communications > http://www.silveroaks.com/ > 824 17th Street, Moline IL 61265 > Too many options! "Don't make me think", for those that are fans of the book. This is like installing Suse. Suse has (had?) a dozen different text editors on the menu. Users do not want to have to choose which version they want, they want one default that works. Anyone that wants any different knows enough to do it themselves. Don't want firefox? yum install epiphany. At this rate, we are hurtling rapidly towards this mess: * Fedora 7 Starter * Fedora 7 Home Basic * Fedora 7 Home Premium * Fedora 7 Business * Fedora 7 Enterprise * Fedora 7 Ultimate Not the ease of use Fedora deserves. From alan at clueserver.org Tue May 1 22:39:52 2007 From: alan at clueserver.org (alan) Date: Tue, 1 May 2007 15:39:52 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <4637B128.60206@redhat.com> Message-ID: On Tue, 1 May 2007, Miles Lane wrote: > On 5/1/07, Jarod Wilson wrote: >> Miles Lane wrote: >> > On 5/1/07, Will Woods wrote: >> >> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: >> >> >> >> > The network config tools need some work. (Especially for Wireless.) >> I >> >> > have been trying to get my bcm4306 chipset wireless to work. The >> >> network >> >> > tools don't see it. (And I have the firmware that I used on FC6 >> >> with no >> >> > problems.) The list of wireless cards in the drop down list seems >> very >> >> > old. It needs to be updated to the currently supported list. (As >> >> much as >> >> > wireless is at this point...) >> >> >> >> Yeah, you'll want to use NetworkManager to manage the device. First you >> >> will need firmware: >> >> >> >> 1) Install bcm43xx-fwcutter >> >> 2) Get a Broadcom-distributed driver to cut the firmware out of >> >> # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README >> >> # For the newer driver you'll need 4.x firmware. I recommend: >> >> http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 >> > >> > I'll try this, but I suspect it won't work, because I have a pretty >> > old bcm4306 PCI card in my desktop machine. Last time I checked, my >> > card isn't supported by the 4.x firmware. :-( >> >> Works fine with the bcm4306 in my powerbook. > > It probably still won't work for my card. The card revision matters. > > I found this statement online: > "> There is a revision number which is the key for v4 suppport. You'll need >> at least revision number 0x4 there for d80211 support. The older >> revisions 0x2 and 0x3 have to use the softmac stack." > > My PCI card is a Linksys card with bcm4306 revision 3. > Gak! Gak is right. The laptop chipset I am trying to get working is a rev 3 as well. Is there going to be an option for people with the older hardware or are we just screwed? -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From lightsolphoenix at gmail.com Tue May 1 22:54:29 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Tue, 1 May 2007 18:54:29 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> Message-ID: <200705011854.30074.lightsolphoenix@gmail.com> On Tuesday, May 01, 2007 6:39 pm alan wrote: > Is there going to be an option for people with the older hardware or are > we just screwed? To be entirely frank (and having to say this sucks because of the large amount of work that has gone into making the native driver for Linux), I gave up even TRYING to get my laptop's wireless card (Broadcom bcm4320) and just used Ndiswrapper with the Windows driver. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From chris.stone at gmail.com Tue May 1 23:26:18 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 1 May 2007 16:26:18 -0700 Subject: ANNOUCEMENT: New Fedora-php-devel-list Message-ID: We now have a mailing list for PHP related discussion for Fedora. This list is for people in the PHP SIG group, or anyone who is interested in packaging or (co-)maintaining PHP packages in Fedora. We can also use this list for discussing Fedora PHP guidelines changes and additions. For more information, and to subscribe, see: https://www.redhat.com/mailman/listinfo/fedora-php-devel-list From linville at redhat.com Tue May 1 23:46:00 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 1 May 2007 19:46:00 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: <20070501234600.GA7545@redhat.com> On Tue, May 01, 2007 at 02:25:26PM -0700, Miles Lane wrote: > On 5/1/07, Will Woods wrote: > >Yeah, you'll want to use NetworkManager to manage the device. First you > >will need firmware: > > > >1) Install bcm43xx-fwcutter > >2) Get a Broadcom-distributed driver to cut the firmware out of > ># See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > ># For the newer driver you'll need 4.x firmware. I recommend: > >http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > > I'll try this, but I suspect it won't work, because I have a pretty > old bcm4306 PCI card in my desktop machine. Last time I checked, my > card isn't supported by the 4.x firmware. :-( If that is true, then you will need to stick with the older driver (bcm43xx). FWIW, the plan of record is for that driver (i.e. "bcm43xx") to be renamed (probably as "bcm4301") and ported to the same new mac80211 infrastructure as the newer driver (for now "bcm43xx-mac80211", eventually will be renamed to just "bcm43xx"). The PCI device table of bcm4301 will also be redacted to only refer to the older devices which require the version 3 firmware. But, that will not probably not happen upstream in time for F7. I would be open to making that change just for Fedora if there is something resembling consensus that such would be better than the current "two drivers" situation...? Probably not worth it...? John -- John W. Linville linville at redhat.com From alan at clueserver.org Tue May 1 23:45:55 2007 From: alan at clueserver.org (alan) Date: Tue, 1 May 2007 16:45:55 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <200705011854.30074.lightsolphoenix@gmail.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200705011854.30074.lightsolphoenix@gmail.com> Message-ID: On Tue, 1 May 2007, Kelly wrote: > On Tuesday, May 01, 2007 6:39 pm alan wrote: >> Is there going to be an option for people with the older hardware or are >> we just screwed? > > To be entirely frank (and having to say this sucks because of the large amount > of work that has gone into making the native driver for Linux), I gave up > even TRYING to get my laptop's wireless card (Broadcom bcm4320) and just used > Ndiswrapper with the Windows driver. The agrivating part of this is that it works fine in FC6 with the old firmware. This is a recient change that breaks anyone with the pre-4 chipset revision. -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From linville at redhat.com Tue May 1 23:47:21 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 1 May 2007 19:47:21 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200705011854.30074.lightsolphoenix@gmail.com> Message-ID: <20070501234721.GB7545@redhat.com> On Tue, May 01, 2007 at 04:45:55PM -0700, alan wrote: > On Tue, 1 May 2007, Kelly wrote: > > >On Tuesday, May 01, 2007 6:39 pm alan wrote: > >>Is there going to be an option for people with the older hardware or are > >>we just screwed? > > > >To be entirely frank (and having to say this sucks because of the large > >amount > >of work that has gone into making the native driver for Linux), I gave up > >even TRYING to get my laptop's wireless card (Broadcom bcm4320) and just > >used > >Ndiswrapper with the Windows driver. > > The agrivating part of this is that it works fine in FC6 with the old > firmware. This is a recient change that breaks anyone with the pre-4 > chipset revision. Did you try blacklisting the bcm43xx-mac80211 driver? -- John W. Linville linville at redhat.com From alan at clueserver.org Tue May 1 23:47:51 2007 From: alan at clueserver.org (alan) Date: Tue, 1 May 2007 16:47:51 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070501234721.GB7545@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200705011854.30074.lightsolphoenix@gmail.com> <20070501234721.GB7545@redhat.com> Message-ID: On Tue, 1 May 2007, John W. Linville wrote: > On Tue, May 01, 2007 at 04:45:55PM -0700, alan wrote: >> On Tue, 1 May 2007, Kelly wrote: >> >>> On Tuesday, May 01, 2007 6:39 pm alan wrote: >>>> Is there going to be an option for people with the older hardware or are >>>> we just screwed? >>> >>> To be entirely frank (and having to say this sucks because of the large >>> amount >>> of work that has gone into making the native driver for Linux), I gave up >>> even TRYING to get my laptop's wireless card (Broadcom bcm4320) and just >>> used >>> Ndiswrapper with the Windows driver. >> >> The agrivating part of this is that it works fine in FC6 with the old >> firmware. This is a recient change that breaks anyone with the pre-4 >> chipset revision. > > Did you try blacklisting the bcm43xx-mac80211 driver? I will be tonight. -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From jwilson at redhat.com Wed May 2 00:09:37 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 01 May 2007 20:09:37 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <4637B128.60206@redhat.com> Message-ID: <4637D6C1.6020708@redhat.com> Miles Lane wrote: > On 5/1/07, Jarod Wilson wrote: >> Miles Lane wrote: >> > On 5/1/07, Will Woods wrote: >> >> On Tue, 2007-05-01 at 09:13 -0700, alan wrote: >> >> >> >> > The network config tools need some work. (Especially for >> Wireless.) I >> >> > have been trying to get my bcm4306 chipset wireless to work. The >> >> network >> >> > tools don't see it. (And I have the firmware that I used on FC6 >> >> with no >> >> > problems.) The list of wireless cards in the drop down list >> seems very >> >> > old. It needs to be updated to the currently supported list. (As >> >> much as >> >> > wireless is at this point...) >> >> >> >> Yeah, you'll want to use NetworkManager to manage the device. First >> you >> >> will need firmware: >> >> >> >> 1) Install bcm43xx-fwcutter >> >> 2) Get a Broadcom-distributed driver to cut the firmware out of >> >> # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README >> >> # For the newer driver you'll need 4.x firmware. I recommend: >> >> http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 >> > >> > I'll try this, but I suspect it won't work, because I have a pretty >> > old bcm4306 PCI card in my desktop machine. Last time I checked, my >> > card isn't supported by the 4.x firmware. :-( >> >> Works fine with the bcm4306 in my powerbook. > > It probably still won't work for my card. The card revision matters. > > I found this statement online: > "> There is a revision number which is the key for v4 suppport. You'll need >> at least revision number 0x4 there for d80211 support. The older >> revisions 0x2 and 0x3 have to use the softmac stack." > > My PCI card is a Linksys card with bcm4306 revision 3. > Gak! I swear my card is a revision 2, and Will Woods has a revision 1, and both of them work with the new driver and firmware. Excerpt from bug 233011: Mar 19 16:04:55 albook kernel: bcm43xx_mac80211: Found PHY: Analog 1, Type 2, Revision 1 Perhaps you have a type 1, revision 3? That, or the revision level in this case is something entirely different and I have no clue what I'm talking about. (Always a possibility! :) -- Jarod Wilson jwilson at redhat.com From michel.salim at gmail.com Wed May 2 00:19:31 2007 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 1 May 2007 20:19:31 -0400 Subject: OT: Re: Pidgin Icons gone In-Reply-To: References: <6bb886180704191918l2d5262c9jed01b2d6ce9339ec@mail.gmail.com> <1177065405.25513.70.camel@vader.jdub.homelinux.org> <1177852886.4390.28.camel@localhost.localdomain> <1177944840.19526.2.camel@localhost.localdomain> <46360BCB.3080901@fedoraproject.org> <1177953143.3026.39.camel@zod.rchland.ibm.com> Message-ID: <883cfe6d0705011719k76a6a184wa217f255182d43bb@mail.gmail.com> 2007/4/30, dragoran dragoran : > > > > On 4/30/07, Josh Boyer wrote: > > > > On Mon, 2007-04-30 at 21:01 +0530, Rahul Sundaram wrote: > > > Adam Jackson wrote: > > > > On Sun, 2007-04-29 at 08:21 -0500, Tom "spot" Callaway wrote: > > > >> On Fri, 2007-04-20 at 05:36 -0500, Josh Boyer wrote: > > > >>> On Fri, 2007-04-20 at 12:18 +1000, David Hunter wrote: > > > >>>> Since the demise of Gaim being replaced with pidgin, many of the > > old > > > >>>> Icons from gaim have been changed. Any way to get them back? or > > is it > > > >>>> a change for good? Is it a bug or known issue? > > > >>> As I understand it, the icons included with pidgin are _the_ icons > > for > > > >>> the package now. I don't think it's a bug. > > > >> Unfortunately they're hideous. Does anyone know of a slightly less > > > >> horrible icon set for pidgin? > > > > > > > > There was a nice set in this other IM program. G-something, I > > think. > > > > > > Gossip? > > > > I believe Adam was making a tounge-in-cheek reference to Gaim... > > > I also don't like them... the gaim ones where much better imho... > Hmm, guess I'm one of the few that actually prefer them to the original icons? It's really nice that the icons are the same regardless of which protocol a contact is on. And the icon theme blends quite well with the Tango iconset (I made sure I have as little of OpenOffice installed as possible, since there are no Tango icons for them yet, and the upstream icons are .. uh. -- Michel Salim http://hircus.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpepple at fedoraproject.org Tue May 1 20:58:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 01 May 2007 16:58:20 -0400 Subject: FESCo Meeting Summary for 2007-04-26 Message-ID: <1178053100.5948.7.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Rex Dieter (rdieter) * Jesse Keating (f13) * Christian Iseli (c4chris) * Toshio Kuratomi (abadger1999) * Josh Boyer (jwb) * Jeremy Katz (jeremy) * Bill Nottingham (notting) * Warren Togami (warren) === Members Absent === * Dennis Gilmore (dgilmore) * Kevin Fenzi (nirik) * Tom Callaway (spot) === Summary === == FESCo Meeting Minutes == * warren will look at a bot to post irc logs from the meeting to a web directory, and then we will only be posting the summaries to the wiki. == Policies Updating == * c4chris, tibbs, and bpepple will start fixing policies that have inconsistencies due to the merging of Core & Extras. == Sub-Groups Reporting to FESCo == * Discussed how to be more efficient in handling of reporting from sub-groups. If a sub-groups provides a summary 24-hours prior to the FESCo meeting, the FESCo chair will just ask if there are "any objection to this week's report of at ". The consensus was that there was no need to go over items that people didn't object to. * Still needs to decide procedure for summaries from groups that can't get a summary to FESCo in time. bpepple sent an e-mail to the mailing list to get input on how folks would like to handle this. https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070426 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed May 2 04:55:05 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 May 2007 00:55:05 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070501234600.GA7545@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <20070501234600.GA7545@redhat.com> Message-ID: <20070502045505.GB30219@nostromo.devel.redhat.com> John W. Linville (linville at redhat.com) said: > But, that will not probably not happen upstream in time for F7. > I would be open to making that change just for Fedora if there is > something resembling consensus that such would be better than the > current "two drivers" situation...? Probably not worth it...? Two drivers claiming to support the same PCI ids == bad. If the fix is on its way upstream, I'm for shipping it slightly early. Bill From peter at thecodergeek.com Wed May 2 05:22:50 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 01 May 2007 22:22:50 -0700 Subject: rpms/pidgin/devel pidgin.spec,1.9,1.10 In-Reply-To: <200705020138.l421c0ZA027675@cvs-int.fedora.redhat.com> References: <200705020138.l421c0ZA027675@cvs-int.fedora.redhat.com> Message-ID: <1178083370.8360.4.camel@tuxhugs> On Tue, 2007-05-01 at 21:38 -0400, Stu Tomlinson wrote: > Index: pidgin.spec > =================================================================== > RCS file: /cvs/extras/rpms/pidgin/devel/pidgin.spec,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -u -r1.9 -r1.10 > --- pidgin.spec 1 May 2007 20:45:06 -0000 1.9 > +++ pidgin.spec 2 May 2007 01:37:24 -0000 1.10 > @@ -343,7 +343,7 @@ > %{_mandir}/man3/Pidgin* > %{_datadir}/applications/pidgin.desktop > %{_datadir}/pixmaps/pidgin/ > -%{_datadir}/icons/hicolor/ > +%{_datadir}/icons/hicolor/*/apps/pidgin.* > %{_datadir}/sounds/pidgin/ > %if %{perl_integration} > %{perl_vendorarch}/Pidgin.pm > @@ -405,6 +405,7 @@ > %changelog > * Tue May 1 2007 Stu Tomlinson > - Update Gtk icon cache when installing or uninstalling (#238621) > +- Don't own all directories we put icons in When you do this, please ensure that you add an explicit "Requires: hicolor-icon-theme" so that the %_datadir/icons/hicolor directory is properly owned. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From miles.lane at gmail.com Wed May 2 06:16:12 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 2 May 2007 02:16:12 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070502045505.GB30219@nostromo.devel.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <20070501234600.GA7545@redhat.com> <20070502045505.GB30219@nostromo.devel.redhat.com> Message-ID: On 5/2/07, Bill Nottingham wrote: > John W. Linville (linville at redhat.com) said: > > But, that will not probably not happen upstream in time for F7. > > I would be open to making that change just for Fedora if there is > > something resembling consensus that such would be better than the > > current "two drivers" situation...? Probably not worth it...? > > Two drivers claiming to support the same PCI ids == bad. If the fix > is on its way upstream, I'm for shipping it slightly early. Cool! The 4.0 firmware works! The dmesg output claims the bcm4306 PCI card is: "Manuf 0x17F, Version 0x2050, Revision 2" Bill, it does appear that the LiveCD is shipping with both bcm43xx and bcm43xx_mac80211 configured to handle this device. Okay, here's the scoop. I booted the F7t4 LiveCD on my nForce2-based desktop with the bcm4306. I then did the following steps: Downloaded the 4.0 firmware to ~fedora (Obviously, I needed an ethernet connection at this point). Then: yum install bcm43xx-fwcutter bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist modprobe -r bcm43xx modprobe -r ieee80211softmac modprobe -r ieee80211_crypt modprobe -r ieee80211 modprobe -r bcm43xx_mac80211 modprobe bcm43xx_mac80211 Then, configure my WIFI connection through NetworkManager and I'm golden. I am currently sending this note to you through resulting the connection. I'm not sure if WPA works. I have a WPA2-enabled Airport Extreme in the basement, and I am not seeing it in the NetworkManager AP list. I must say, it is really neat that I can get this working using the LiveCD and without even rebooting. Albeit, it would be better if I didn't have to jump through these hoops. Proprietary firmware... Grrr. Here is the corresponding section of dmesg: ssb: Sonics Silicon Backplane found on PCI device 0000:01:06.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI core, index 4 bcm43xx_mac80211: Broadcom 4306 WLAN found ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned off wmaster0: Selected rate control algorithm 'simple' fw_core: created new fw device fw0 (0 config rom retries) ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation bcm43xx driver ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [APCJ] -> GSI 22 (level, high) -> IRQ 16 PCI: Setting latency timer of device 0000:00:06.0 to 64 NET: Registered protocol family 10 lo: Disabled Privacy Extensions Mobile IPv6 bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 ssb: Switching to PCI core, index 4 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed. bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_mac80211: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed. eth2: setting half-duplex. ADDRCONF(NETDEV_UP): eth2: link is not ready ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 21 eth0: no IPv6 routers present bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_mac80211: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed. >>>>> At this point I: downloaded the 4.0 firmware to ~fedora yum install bcm43xx-fwcutter bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist modprobe -r bcm43xx modprobe -r ieee80211softmac modprobe -r ieee80211_crypt modprobe -r ieee80211 modprobe -r bcm43xx_mac80211 modprobe bcm43xx_mac80211 bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=30, tgt=62). Disabling TX power adjustment. bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 30-bit DMA initialized bcm43xx_mac80211: Wireless interface started wmaster0: Does not support passive scan, disabled ADDRCONF(NETDEV_UP): wlan0: link is not ready ieee80211_crypt: unregistered algorithm 'NULL' bcm43xx_mac80211: Removing Interface type 2 bcm43xx_mac80211: Wireless interface stopped bcm43xx_mac80211: DMA-32 0x0200 (RX) max used slots: 1/64 bcm43xx_mac80211: DMA-32 0x02A0 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0280 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0260 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0240 (TX) max used slots: 0/128 bcm43xx_mac80211: DMA-32 0x0220 (TX) max used slots: 22/128 bcm43xx_mac80211: DMA-32 0x0200 (TX) max used slots: 0/128 bcm43xx_mac80211: Radio turned off ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned off ACPI: PCI interrupt for device 0000:01:06.0 disabled ACPI: PCI Interrupt 0000:01:06.0[A] -> Link [APC1] -> GSI 16 (level, high) -> IRQ 20 ssb: Sonics Silicon Backplane found on PCI device 0000:01:06.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI core, index 4 bcm43xx_mac80211: Broadcom 4306 WLAN found ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned off wmaster0: Selected rate control algorithm 'simple' bcm43xx_mac80211: Adding Interface type 2 bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 ssb: Switching to PCI core, index 4 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Loading firmware version 351.126 (2006-07-29 05:54:02) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_mac80211: Radio turned on bcm43xx_mac80211: Radio enabled by hardware bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=30, tgt=62). Disabling TX power adjustment. bcm43xx_mac80211: Chip initialized bcm43xx_mac80211: 30-bit DMA initialized bcm43xx_mac80211: Wireless interface started wmaster0: Does not support passive scan, disabled ADDRCONF(NETDEV_UP): wlan0: link is not ready bcm43xx_mac80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:06:25:54:a2:0c wlan0: authenticate with AP 00:06:25:54:a2:0c wlan0: RX authentication from 00:06:25:54:a2:0c (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:06:25:54:a2:0c wlan0: RX AssocResp from 00:06:25:54:a2:0c (capab=0x11 status=0 aid=2) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: duplicate address detected! eth0: link down. wlan0: duplicate address detected! From miles.lane at gmail.com Wed May 2 06:53:46 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 2 May 2007 02:53:46 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems Message-ID: Hi, I have a NVidia NV31 (GeForce FX 5600). I booted the LiveCD, and it correctly configured the nv driver and set the monitor resolution to 1600x1200. Wanting to test Compiz, I opened System->Administration->Display. >From there, I selected Hardware->Configure and selected nouveau from the list. I was told I needed to log out to get the new driver running X. I logged out and then back in. The result was that the Gnome desktop never got displayed. Rather, I got reoccurring errors stating that something was wrong with the "greeter." I'll reproduce and file a bug with the exact wording. Then, when I tried to switch to a VT, I found it was busted. As far as I can tell, nothing was being rendered on the VT. Rather, the video image from GDM kept getting displayed. Each time I hit Enter, the whole image of GDM would rotate to the right and wrap around onto the left side of the screen. Miles From jspaleta at gmail.com Wed May 2 07:40:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 1 May 2007 23:40:20 -0800 Subject: repotag in EPEL In-Reply-To: References: <1177541584.17572.3.camel@lincoln> <20070428095815.GC18891@neu.nirvana> <1177851508.4390.16.camel@localhost.localdomain> <20070429152130.GB15091@neu.nirvana> <1177890118.3836.5.camel@localhost.localdomain> <20070430015053.GB25998@neu.nirvana> <1177939835.3836.47.camel@localhost.localdomain> <1177967603.7337.66.camel@cmn3.stanford.edu> <463703EA.4080108@leemhuis.info> Message-ID: <604aa7910705020040o7b42eb43kaa8eb02bd55ecde8@mail.gmail.com> On 5/1/07, Rex Dieter wrote: > That doesn't fly with me. > Compare that with the repotag-less situation of each repo providing packages > with *identical* EVR's. Which is worse? Once you have multiple vendors in the mix, each providing packages which may install over a package from another vendor there's no one-size fits all version comparison scheme which will hold. So to answer the question which is worse.. they are both significantly bad enough that your screwed either way. The only way to really solve the problem is to hold vendor as a separate metric by which to test against in a different way than version comparison. Vendor-ness simply doesn't translate to ordering in a programmatic way. Instead, you hold vendor-ness a parallel collection of namespaces in which you do version comparisons internally. So if I have package foo installed from the Vendor called babyeater, and updates for package foo are available from both the babyeater vendor and the lazybastard Vendors, regardless of how those versions compare, the management tool can be told to stay inside the babyeater namespace for package updates for foo (or be told to ignore vendor-ness completely and gobble the highest versioned packaged based on version comparison rules). If we had a way to authoritatively identify vendors ( hint gpg sigs ) then you could programmatically instruct a depsolver to always prefer updates from the vendor of the package for which you already have packages installed. If such functionality was possible, I bet it would be implemented in a yum plugin called protectvendor. -jef"I'm not a glass is half-empty of half-full sort of person. My glass is filled to the brim.. one part tequila, one part nerve gas"spaleta From jonathan.underwood at gmail.com Wed May 2 09:19:26 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 2 May 2007 10:19:26 +0100 Subject: Tetris clones In-Reply-To: References: <4636C729.2000407@kobold.org> <1178026097.3609.13.camel@localhost.localdomain> <20070501135408.GA6174@devserv.devel.redhat.com> <645d17210705010707k19f7263asfffbcf3ebbdf9261@mail.gmail.com> Message-ID: <645d17210705020219p5ab27382l42733e9a79e0a15@mail.gmail.com> On 01/05/07, Tom Tromey wrote: > Unfortunately it seems that RMS already said he doesn't think there is > a problem: > > http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00916.html > > On the other hand the other discussion in that thread seems a bit > inconclusive as well... as in, perhaps renaming the menu item and the > buffer name "Tetris" to "Falling Blocks Wink Wink" might be > sufficient. FWIW, I mentioned this on emacs-devel once more, pointing out the additional issues: http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00016.html and RMS is taking it back to the FSF legal people. Jonathan. From sundaram at fedoraproject.org Wed May 2 09:26:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 14:56:41 +0530 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: Message-ID: <46385951.3070506@fedoraproject.org> Miles Lane wrote: > Hi, > > I have a NVidia NV31 (GeForce FX 5600). > I booted the LiveCD, and it correctly configured the nv driver > and set the monitor resolution to 1600x1200. > Wanting to test Compiz, I opened System->Administration->Display. >> From there, I selected Hardware->Configure and selected nouveau from >> the list. Nouveau is nowhere near a state that it could run Compiz. More details at http://fedoraproject.org/wiki/Releases/FeatureNouveau Rahul From buildsys at redhat.com Wed May 2 09:31:32 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 2 May 2007 05:31:32 -0400 Subject: rawhide report: 20070502 changes Message-ID: <200705020931.l429VW1v024203@hs20-bc2-6.build.redhat.com> Updated Packages: audit-1.5.3-1.fc7 ----------------- * Tue May 01 2007 Steve Grubb 1.5.3-1 - Change buffer size to prevent truncation of DAEMON events with large labels - Fix memory leaks in auparse (John Dennis) - Update syscall tables for 2.6.21 kernel - Update capp & lspp rules - New python bindings for libauparse (John Dennis) kdebase-6:3.5.6-6.fc7 --------------------- * Mon Apr 23 2007 Than Ngo - 6:3.5.6-6.fc7 - apply patch KDM to support ConsoleKit, thanks to Kevin Kofler and S.??a??lar Onur, #228111 - ktip, kpersonlizer, kpager, kappfinder in kdebase-extras python-virtinst-0.103.0-3.fc7 ----------------------------- * Tue May 01 2007 Daniel P. Berrange - 0.103.0-3.fc7 - Fixed module import when using --accelerate - Fixed detection of RHEL5 client distro - Fixed default 'network's selection & default URI choice to not be Xen specific - Fixed features XML when using initrd for fullvirt rpm-4.4.2-46.fc7 ---------------- * Tue May 01 2007 Paul Nasrat - 4.4.2-46 - Configurable policy for prefered ELF (#235757) * Mon Apr 23 2007 Paul Nasrat - 4.4.2-45 - Fix debugedit for relative paths (#232222) * Mon Apr 16 2007 Paul Nasrat - 4.4.2-44 - Set default verify flags for %doc (#235353) - Revert to old configure line syslinux-3.36-3.fc7 ------------------- * Tue May 01 2007 Jeremy Katz - 3.36-3 - fix countdown on boot images (#229491) system-config-lvm-1.1.1-1.0.fc7 ------------------------------- * Tue May 01 2007 Stanko Kupcevic 1.1.1-1.0 - Update pam file - Update translation files * Mon Jan 22 2007 Stanko Kupcevic 1.0.22-1.0 - Fixed 223518 (s-c-lvm fails to probe CS5 properly) - Resolves: bz223518 * Mon Dec 18 2006 Stanko Kupcevic 1.0.21-1.0 - Fixed 216569 (some messages not localized) - Fixed 218126 (Can't resize ext3 fs online) - Resolves: bz216569, bz218126 xorg-x11-drv-i810-2.0.0-2.fc7 ----------------------------- * Tue May 01 2007 Adam Jackson 2.0.0-2 - Rebuild for final RANDR 1.2 ABI. Fixes segfault at startup. (#238575) * Mon Apr 23 2007 Adam Jackson 2.0.0-1 - xf86-video-intel 2.0.0. Change the version number to match, why not. - Add a Virtual provides for xorg-x11-drv-intel, since we should probably rename this at some point. Broken deps for ia64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ia64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.ia64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ia64 requires mkisofs k3b - 1.0-1.fc7.ia64 requires cdrecord libvirt - 0.2.2-2.fc7.ia64 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.ia64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ia64 requires cdrecord xcdroast - 0.98a15-13.ia64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.ia64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ia64 requires mkisofs >= 0:2.0 Broken deps for ppc64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ppc64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.ppc64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ppc64 requires mkisofs k3b - 1.0-1.fc7.ppc64 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.ppc64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ppc64 requires cdrecord xcdroast - 0.98a15-13.ppc64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.ppc64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ppc64 requires mkisofs >= 0:2.0 Broken deps for i386 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.i386 requires mkisofs dvd+rw-tools - 7.0-3.fc7.i386 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.i386 requires cdrecord k3b - 1.0-1.fc7.i386 requires mkisofs libvirt - 0.2.2-2.fc7.i386 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.i386 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.i386 requires mkisofs xcdroast - 0.98a15-13.i386 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.i386 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.i386 requires mkisofs >= 0:2.0 Broken deps for x86_64 ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.x86_64 requires mkisofs dvd+rw-tools - 7.0-3.fc7.x86_64 requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.x86_64 requires mkisofs k3b - 1.0-1.fc7.x86_64 requires cdrecord k3b - 1.0-1.fc7.i386 requires mkisofs k3b - 1.0-1.fc7.i386 requires cdrecord libvirt - 0.2.2-2.fc7.x86_64 requires dnsmasq libvirt - 0.2.2-2.fc7.i386 requires dnsmasq nautilus-cd-burner - 2.18.0-2.fc7.x86_64 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.x86_64 requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.i386 requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.i386 requires cdrecord xcdroast - 0.98a15-13.x86_64 requires cdrecord >= 0:2.0 xcdroast - 0.98a15-13.x86_64 requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.x86_64 requires mkisofs >= 0:2.0 Broken deps for ppc ---------------------------------------------------------- anaconda-runtime - 11.2.0.57-1.ppc requires mkisofs dvd+rw-tools - 7.0-3.fc7.ppc requires mkisofs >= 0:2.0 k3b - 1.0-1.fc7.ppc requires mkisofs k3b - 1.0-1.fc7.ppc requires cdrecord nautilus-cd-burner - 2.18.0-2.fc7.ppc requires mkisofs nautilus-cd-burner - 2.18.0-2.fc7.ppc requires cdrecord xcdroast - 0.98a15-13.ppc requires cdda2wav >= 0:2.0 xcdroast - 0.98a15-13.ppc requires mkisofs >= 0:2.0 xcdroast - 0.98a15-13.ppc requires cdrecord >= 0:2.0 From sundaram at fedoraproject.org Wed May 2 10:10:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 15:40:25 +0530 Subject: live F7 test4 In-Reply-To: <46848.86.195.204.66.1178044262.squirrel@webmail.univ-nantes.fr> References: <1177753244.3259.7.camel@bureau.maison> <4633EEA9.8060104@fedoraproject.org> <46848.86.195.204.66.1178044262.squirrel@webmail.univ-nantes.fr> Message-ID: <46386391.8070501@fedoraproject.org> Eric TANGUY wrote: > I will file a bug report against network manager but i have another problem : > It seems my wireless card is known as an ethernet one so i can associate > with network manager. As my system is a desktop and i don't need to switch > network, i would like to disable network manager and use > system-config-network but it can't work as my card is known as an ethernet > one. My wireless card is a pci one : > 02:08.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) > Subsystem: SiteCom Europe BV Unknown device 9073 > Flags: bus master, slow devsel, latency 64, IRQ 19 > Memory at fe000000 (32-bit, non-prefetchable) [size=8K] > Capabilities: [40] Power Management version 2 You can add these details in the bug report. > I need to run : > chcon -t textrel_shlib_t /usr/lib/gstreamer-0.10/libgstflump3dec.so > as setroubleshoot says. This one is a known issue with the plugin. More details at http://docs.fedoraproject.org/selinux-faq/. Please report this upstream instead. Rahul From laroche at redhat.com Wed May 2 10:13:21 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 May 2007 12:13:21 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> Message-ID: <20070502101321.GA4652@dudweiler.stuttgart.redhat.com> On Tue, May 01, 2007 at 03:44:03AM +0000, Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > KDE is a part of Fedora, however the overwhelming evidence is that Fedora > > focuses on Gnome and GTK stacks. Almost all the Fedora upstream software > > that is graphical is built on gnome/gtk. It is the most integrated > > experience you can get. Using KDE is a less integrated less polished > > experience, and thus it is not our best foot forward. > > It's because of statements like this that Fedora has a bad reputation with the > KDE community (just look at some of the comments at dot.kde.org). I'm doing my > best to improve Fedora's reputation there, but statements like this from > official people like you as the Release Engineer really ruin things. > > How is KDE on Fedora less integrated? Why do you think people like Than Ngo, > Rex Dieter, Sebastian Vahl or me work our behinds off to fix things like this: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 > which is now finally fixed (thanks also to a developer from Pardus who made a > one-line fix to my patch to get it to work instead of crashing)? (In fact, we > have to specifically fix what your GNOME developers break, but that's another > issue.) > > We're really doing what we can to provide a well-integrated KDE desktop to > Fedora users, I think it's unfair to us to call this "a less integrated less > polished experience" and "not our best foot forward", and I also think it's > Fedora's reputation you're ruining there (again, look at some of the comments > at dot.kde.org, I'd be surprised if nobody is going to quote your above > paragraph the next time Fedora is mentioned anywhere), not just KDE's and ours. Hello Kevin, as distributors we are responsible for integrating software and making sure the overall setup stays modular and supports as many as possible setups. Just look at the gnome live-cd which e.g. uses again smaller office apps and not only openoffice. So we do support more than one version of things and have always done so in the past. This is different from then selecting a "good enough subset" of Open Source apps we include at all. Also we ship sendmail/postfix/exim with sendmail as default and all of them receiving bug-fixes, updates and full integration. KDE is requested and used by lots of Fedora users and also by RHEL customers and partners, so there is no question about KDE support at Red Hat. That's for KDE itself as well as other components of the OS. I think the gnome/KDE split introduced in F7 is pretty unfortunate as it opens up the gnome/KDE discussion again, instead of supporting the integration and bug-fixing part. Fedora needs to be an open platform where Open Source projects get reviewed, tested, integrated and moved along. regards, Florian La Roche > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From sundaram at fedoraproject.org Wed May 2 10:35:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 16:05:27 +0530 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <20070502101321.GA4652@dudweiler.stuttgart.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> <20070502101321.GA4652@dudweiler.stuttgart.redhat.com> Message-ID: <4638696F.7030000@fedoraproject.org> Florian La Roche wrote: > > I think the gnome/KDE split introduced in F7 is pretty unfortunate as it > opens up the gnome/KDE discussion again, instead of supporting the integration > and bug-fixing part. Fedora needs to be an open platform where Open Source > projects get reviewed, tested, integrated and moved along. What the different spins give is the flexibility that benefits end users while providing integration at the repo level because of the upcoming merge. It also gives developers the freedom to do that that make sense for only one desktop environment instead of being the base common denominator just to be somewhat neutral. If you are a end user who wants just use a particular desktop environment then more focused spins is good. More importantly the tools are available in the repository which increasingly is making the process of creating a custom spin or derivative trivial. There is tremendous value in that. Describing the spins are just a DE split is missing out the big picture. Folks are experimenting with a lot more than that. Look at http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD. Rahul From dblistsub-fedora at yahoo.it Wed May 2 11:06:45 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Wed, 2 May 2007 13:06:45 +0200 Subject: Corrupted display with Fedora 7 test 4 live, Intel 965 chipset and wide monitor Message-ID: <200705021306.45895.dblistsub-fedora@yahoo.it> Greetings, I tried the Fedora 7 test 4 KDE live CD on a workstation with 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) and a (II) I810(0): Monitor name: BenQ FP202W resulting in a visually corrupted display. Taking a screenshot shows no corruption, so I guess the problem is with the display timings: the display is skewed to the right, with a large blank area on the left, and "ghosts" of the graphics appear overlapped a few pixels to the right and down of the original. The live CD was i386 and the CPU is x86_64, I am in the process of downloading the x86_64 live CD to see if it makes any difference. Under Fedora 6, the display shows no such corruption, although it works at 1024x768 instead of at aspect-correct resolutions. Which is the appropriate component in Bugzilla for this, the server or the i810 driver (which I guess includes the intel driver) ? Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From jfrieben at gmx.de Wed May 2 11:12:53 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 02 May 2007 13:12:53 +0200 Subject: Corrupted display with Fedora 7 test 4 live, Intel 965 chipset and wide monitor In-Reply-To: <200705021306.45895.dblistsub-fedora@yahoo.it> References: <200705021306.45895.dblistsub-fedora@yahoo.it> Message-ID: <20070502111253.181670@gmx.net> > Greetings, > I tried the Fedora 7 test 4 KDE live CD on a workstation with > > 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 > Integrated > Graphics Controller (rev 02) > > and a > > (II) I810(0): Monitor name: BenQ FP202W > > resulting in a visually corrupted display. Try to set the driver in "xorg.conf" from "i810" to "intel". The latter works very well now with the 965Q integrated graphics. Occasionally, I encounter a horizontally compressed image with black borders above and below the picture in conjunction with a 19" monitor having 1280x1024 pixels. Resetting the "X" server helps in this case. A 1920x1200 wide screen monitor gets detected and set up correctly in my case. -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From sundaram at fedoraproject.org Wed May 2 11:14:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 16:44:18 +0530 Subject: Corrupted display with Fedora 7 test 4 live, Intel 965 chipset and wide monitor In-Reply-To: <200705021306.45895.dblistsub-fedora@yahoo.it> References: <200705021306.45895.dblistsub-fedora@yahoo.it> Message-ID: <4638728A.3090402@fedoraproject.org> Davide Bolcioni wrote: > Greetings, > I tried the Fedora 7 test 4 KDE live CD on a workstation with > > 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated > Graphics Controller (rev 02) > > and a > > (II) I810(0): Monitor name: BenQ FP202W > > resulting in a visually corrupted display. Taking a screenshot shows no > corruption, so I guess the problem is with the display timings: the display > is skewed to the right, with a large blank area on the left, and "ghosts" of > the graphics appear overlapped a few pixels to the right and down of the > original. The live CD was i386 and the CPU is x86_64, I am in the process of > downloading the x86_64 live CD to see if it makes any difference. > > Under Fedora 6, the display shows no such corruption, although it works at > 1024x768 instead of at aspect-correct resolutions. Which is the appropriate > component in Bugzilla for this, the server or the i810 driver (which I guess > includes the intel driver) ? I would guess the driver. If it's not it can always be reassigned. So go ahead and file it with all the above information and logs. Thank you for testing and providing feedback. Rahul From laroche at redhat.com Wed May 2 11:19:45 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 2 May 2007 13:19:45 +0200 Subject: Announcing Fedora 7 Test 4 (6.93) In-Reply-To: <4638696F.7030000@fedoraproject.org> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300840.47087.jkeating@redhat.com> <46361183.1060206@fedoraproject.org> <200704300901.59753.jkeating@redhat.com> <20070502101321.GA4652@dudweiler.stuttgart.redhat.com> <4638696F.7030000@fedoraproject.org> Message-ID: <20070502111945.GA5860@dudweiler.stuttgart.redhat.com> > Describing the spins are just a DE split is missing out the big picture. > Folks are experimenting with a lot more than that. Look at > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD. Yes, this is a very good spin of Fedora. regards, Florian La Roche From selinux at gmail.com Wed May 2 13:22:17 2007 From: selinux at gmail.com (Tom London) Date: Wed, 2 May 2007 06:22:17 -0700 Subject: Corrupted display with Fedora 7 test 4 live, Intel 965 chipset and wide monitor In-Reply-To: <200705021306.45895.dblistsub-fedora@yahoo.it> References: <200705021306.45895.dblistsub-fedora@yahoo.it> Message-ID: <4c4ba1530705020622s3bd750a5sdd30bbe863625405@mail.gmail.com> On 5/2/07, Davide Bolcioni wrote: > Greetings, > I tried the Fedora 7 test 4 KDE live CD on a workstation with > > 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated > Graphics Controller (rev 02) > > and a > > (II) I810(0): Monitor name: BenQ FP202W > > resulting in a visually corrupted display. Taking a screenshot shows no > corruption, so I guess the problem is with the display timings: the display > is skewed to the right, with a large blank area on the left, and "ghosts" of > the graphics appear overlapped a few pixels to the right and down of the > original. The live CD was i386 and the CPU is x86_64, I am in the process of > downloading the x86_64 live CD to see if it makes any difference. > > Under Fedora 6, the display shows no such corruption, although it works at > 1024x768 instead of at aspect-correct resolutions. Which is the appropriate > component in Bugzilla for this, the server or the i810 driver (which I guess > includes the intel driver) ? > > Thank you for your consideration, > Davide Bolcioni > -- Try running 'xrandr --rate 60' and see if that fixes things. See BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236414 tom -- Tom London From dblistsub-fedora at yahoo.it Wed May 2 14:29:58 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Wed, 2 May 2007 16:29:58 +0200 Subject: Corrupted display with Fedora 7 test 4 live, Intel 965 chipset and wide monitor In-Reply-To: <4c4ba1530705020622s3bd750a5sdd30bbe863625405@mail.gmail.com> References: <200705021306.45895.dblistsub-fedora@yahoo.it> <4c4ba1530705020622s3bd750a5sdd30bbe863625405@mail.gmail.com> Message-ID: <200705021629.58686.dblistsub-fedora@yahoo.it> On Wednesday 02 May 2007 15:22:17 Tom London wrote: > On 5/2/07, Davide Bolcioni wrote: > > Greetings, > > I tried the Fedora 7 test 4 KDE live CD on a workstation with > > > > 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 > > Integrated Graphics Controller (rev 02) > > > > and a > > > > (II) I810(0): Monitor name: BenQ FP202W > > > > resulting in a visually corrupted display. Taking a screenshot shows no > > corruption, so I guess the problem is with the display timings: the > > display is skewed to the right, with a large blank area on the left, and > > "ghosts" of the graphics appear overlapped a few pixels to the right and > > down of the original. The live CD was i386 and the CPU is x86_64, I am in > > the process of downloading the x86_64 live CD to see if it makes any > > difference. > > > > Under Fedora 6, the display shows no such corruption, although it works > > at 1024x768 instead of at aspect-correct resolutions. Which is the > > appropriate component in Bugzilla for this, the server or the i810 driver > > (which I guess includes the intel driver) ? > > > > Thank you for your consideration, > > Davide Bolcioni > > -- > > Try running 'xrandr --rate 60' and see if that fixes things. To get things fixed, I had to (a) force the monitor to auto-adjust, which caused the large blank area to the left to go away, and (b) use xrandr to remove the ghosting effect. > See BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236414 I'll add further comments and logs there. Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From ajackson at redhat.com Wed May 2 14:20:41 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 02 May 2007 10:20:41 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: Message-ID: <1178115641.19384.14.camel@localhost.localdomain> On Wed, 2007-05-02 at 02:53 -0400, Miles Lane wrote: > Hi, > > I have a NVidia NV31 (GeForce FX 5600). > I booted the LiveCD, and it correctly configured the nv driver > and set the monitor resolution to 1600x1200. > Wanting to test Compiz, I opened System->Administration->Display. > >From there, I selected Hardware->Configure and selected nouveau from the list. > I was told I needed to log out to get the new driver running X. > I logged out and then back in. Compiz (and accelerated 3d in general) is not enabled in the nouveau driver in F7. Shouldn't have logged you out though, that's weird. I'll check, but please do file a bug so it doesn't get lost. - ajax From ajackson at redhat.com Wed May 2 14:26:00 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 02 May 2007 10:26:00 -0400 Subject: OT: Re: Pidgin Icons gone In-Reply-To: <1178037516.19384.6.camel@localhost.localdomain> References: <6bb886180704191918l2d5262c9jed01b2d6ce9339ec@mail.gmail.com> <1177065405.25513.70.camel@vader.jdub.homelinux.org> <1177852886.4390.28.camel@localhost.localdomain> <1177944840.19526.2.camel@localhost.localdomain> <1178037516.19384.6.camel@localhost.localdomain> Message-ID: <1178115960.19384.16.camel@localhost.localdomain> On Tue, 2007-05-01 at 12:38 -0400, Adam Jackson wrote: > In a fit of rage, I did a palette swap on the vomit-green bits of the > pidgin icons to be more like fedora blue. RPMs here: > > http://people.redhat.com/ajackson/pidgin/ ... now with SRPM. Whoops. - ajax From chris.stone at gmail.com Wed May 2 15:50:05 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 2 May 2007 08:50:05 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <46385951.3070506@fedoraproject.org> References: <46385951.3070506@fedoraproject.org> Message-ID: On 5/2/07, Rahul Sundaram wrote: > Nouveau is nowhere near a state that it could run Compiz. More details > at http://fedoraproject.org/wiki/Releases/FeatureNouveau Including Nouveau in the distro at this stage is probably a bad idea. I think whomever came up with the idea are just too much forward thinking. Perhaps we should put it on the shelf and revisit it for Fedora X. -Xul"Lets *not* package broken drivers to improve user experience"Chris From jspaleta at gmail.com Wed May 2 16:06:17 2007 From: jspaleta at gmail.com (jspaleta at gmail.com) Date: Wed, 2 May 2007 08:06:17 -0800 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> Message-ID: <604aa7910705020906n7c17ea76m159a1ecf44d0d522@mail.gmail.com> On 5/2/07, Christopher Stone wrote: > I think whomever came up with the idea are just too much forward > thinking. Perhaps we should put it on the shelf and revisit it for > Fedora X. > > -Xul"Lets *not* package broken drivers to improve user experience"Chris If the driver is never selected automatically, and a user has to choose it from the driver list.. I don't see the harm in including it on the basis of it not working completely. If you are selecting drivers through a list manually, there's no expectation that you'll make a decent choice regadless of what drivers are in the list. I'd be more inclined to see it dropped on the basis that its still going to be going through rather significant development which would result in frequent package updates.. updates everyone will need to install but very few people will be using because its not selected via automated hardware detection. -jef From alan at clueserver.org Wed May 2 16:11:44 2007 From: alan at clueserver.org (alan) Date: Wed, 2 May 2007 09:11:44 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070501234721.GB7545@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200705011854.30074.lightsolphoenix@gmail.com> <20070501234721.GB7545@redhat.com> Message-ID: On Tue, 1 May 2007, John W. Linville wrote: > On Tue, May 01, 2007 at 04:45:55PM -0700, alan wrote: >> On Tue, 1 May 2007, Kelly wrote: >> >>> On Tuesday, May 01, 2007 6:39 pm alan wrote: >>>> Is there going to be an option for people with the older hardware or are >>>> we just screwed? >>> >>> To be entirely frank (and having to say this sucks because of the large >>> amount >>> of work that has gone into making the native driver for Linux), I gave up >>> even TRYING to get my laptop's wireless card (Broadcom bcm4320) and just >>> used >>> Ndiswrapper with the Windows driver. >> >> The agrivating part of this is that it works fine in FC6 with the old >> firmware. This is a recient change that breaks anyone with the pre-4 >> chipset revision. > > Did you try blacklisting the bcm43xx-mac80211 driver? That finally worked. (After backreving the firmware and fixing the eth1 alias.) Also helps if you have a working wifi source to test off of. (The downtown free access is pretty worthless in Portland.) -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From fedora at leemhuis.info Wed May 2 16:26:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 May 2007 18:26:22 +0200 Subject: topics for todays EPEL meeting Message-ID: <4638BBAE.8030100@leemhuis.info> Hi all! Sorry, I was busy with other stuff and forgot to send the topics for todays meeting (17:00 UTC, #fedora-meeting) to the list in time. Nevertheless here they are: /topic EPEL Meeting -- chairmen /topic EPEL Meeting -- mass rebuild for RHEL5 /topic EPEL Meeting -- shortcut for branching -- dgilmore? /topic EPEL Meeting -- repotags/interaction with 3rd party repos /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid Anything else I forgot? CU thl From sundaram at fedoraproject.org Wed May 2 16:50:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 22:20:57 +0530 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> Message-ID: <4638C171.9050402@fedoraproject.org> Christopher Stone wrote: > On 5/2/07, Rahul Sundaram wrote: >> Nouveau is nowhere near a state that it could run Compiz. More details >> at http://fedoraproject.org/wiki/Releases/FeatureNouveau > > Including Nouveau in the distro at this stage is probably a bad idea. > I think whomever came up with the idea are just too much forward > thinking. Perhaps we should put it on the shelf and revisit it for > Fedora X. Why? It is turned off by default just like the new Intel xorg driver in FC6. That did help in users providing feedback when they turn it on manually. It fits our mission of progressing Free software. This is a important project. Anything that we can do to help is worth the effort. Rahul From sundaram at fedoraproject.org Wed May 2 16:54:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 22:24:26 +0530 Subject: topics for todays EPEL meeting In-Reply-To: <4638BBAE.8030100@leemhuis.info> References: <4638BBAE.8030100@leemhuis.info> Message-ID: <4638C242.5090904@fedoraproject.org> Thorsten Leemhuis wrote: > Hi all! > > Sorry, I was busy with other stuff and forgot to send the topics for > todays meeting (17:00 UTC, #fedora-meeting) to the list in time. > Nevertheless here they are: > > /topic EPEL Meeting -- chairmen > /topic EPEL Meeting -- mass rebuild for RHEL5 > /topic EPEL Meeting -- shortcut for branching -- dgilmore? > /topic EPEL Meeting -- repotags/interaction with 3rd party repos > /topic EPEL Meeting -- Communication plan for enterprise > customers/ISVs/IHVs -- stahnma, quaid > > Anything else I forgot? I think you should send it to epel-devel instead of here. Rahul From buildsys at fedoraproject.org Wed May 2 16:53:48 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 02 May 2007 16:53:48 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-05-02 Message-ID: <20070502165348.30934.91742@extras64.linux.duke.edu> Summary of broken packages (by owner): cbalint AT redhat.com gdal - 1.4.0-22.fc7.i386 gdal - 1.4.0-22.fc7.ppc gdal - 1.4.0-22.fc7.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-3.7.293svn.fc7.i386 (16 days) gaim-gaym - 0.96-3.7.293svn.fc7.ppc (16 days) gaim-gaym - 0.96-3.7.293svn.fc7.x86_64 (16 days) limb AT jcomserv.net freenx - 0.6.0-12.fc7.x86_64 (2 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 (5 days) kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 (5 days) kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc (5 days) kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 (5 days) kmod-em8300-PAE - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 (5 days) kmod-em8300-kdump - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 (5 days) kmod-em8300-smp - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc (5 days) ====================================================================== Broken packages in fedora-extras-development-i386: gaim-gaym-0.96-3.7.293svn.fc7.i386 requires libgaim.so.0 gaim-gaym-0.96-3.7.293svn.fc7.i386 requires gaim < 2:3.0.0 gdal-1.4.0-22.fc7.i386 requires libdapserver.so.2 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 requires kernel-i586 = 0:2.6.20-1.3104.fc7 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7 kmod-em8300-PAE-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7PAE ====================================================================== Broken packages in fedora-extras-development-ppc: gaim-gaym-0.96-3.7.293svn.fc7.ppc requires libgaim.so.0 gaim-gaym-0.96-3.7.293svn.fc7.ppc requires gaim < 2:3.0.0 gdal-1.4.0-22.fc7.ppc requires libdapserver.so.2 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7 kmod-em8300-smp-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7smp ====================================================================== Broken packages in fedora-extras-development-x86_64: freenx-0.6.0-12.fc7.x86_64 requires nx gaim-gaym-0.96-3.7.293svn.fc7.x86_64 requires libgaim.so.0()(64bit) gaim-gaym-0.96-3.7.293svn.fc7.x86_64 requires gaim < 2:3.0.0 gdal-1.4.0-22.fc7.x86_64 requires libdapserver.so.2()(64bit) kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7 kmod-em8300-kdump-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7kdump From fedora at leemhuis.info Wed May 2 17:06:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 May 2007 19:06:04 +0200 Subject: topics for todays EPEL meeting In-Reply-To: <4638C242.5090904@fedoraproject.org> References: <4638BBAE.8030100@leemhuis.info> <4638C242.5090904@fedoraproject.org> Message-ID: <4638C4FC.5050105@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> Hi all! >> >> Sorry, I was busy with other stuff and forgot to send the topics for >> todays meeting (17:00 UTC, #fedora-meeting) to the list in time. >> Nevertheless here they are: >> >> /topic EPEL Meeting -- chairmen >> /topic EPEL Meeting -- mass rebuild for RHEL5 >> /topic EPEL Meeting -- shortcut for branching -- dgilmore? >> /topic EPEL Meeting -- repotags/interaction with 3rd party repos >> /topic EPEL Meeting -- Communication plan for enterprise >> customers/ISVs/IHVs -- stahnma, quaid >> >> Anything else I forgot? > > I think you should send it to epel-devel instead of here. Good point. Sorry for the typo. CU thl From chris.stone at gmail.com Wed May 2 17:08:26 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 2 May 2007 10:08:26 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <4638C171.9050402@fedoraproject.org> References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> Message-ID: On 5/2/07, Rahul Sundaram wrote: > Christopher Stone wrote: > > On 5/2/07, Rahul Sundaram wrote: > >> Nouveau is nowhere near a state that it could run Compiz. More details > >> at http://fedoraproject.org/wiki/Releases/FeatureNouveau > > > > Including Nouveau in the distro at this stage is probably a bad idea. > > I think whomever came up with the idea are just too much forward > > thinking. Perhaps we should put it on the shelf and revisit it for > > Fedora X. > > Why? It is turned off by default just like the new Intel xorg driver in > FC6. That did help in users providing feedback when they turn it on > manually. It fits our mission of progressing Free software. This is a > important project. Anything that we can do to help is worth the effort. Because it's almost completely useless at this stage. It is only needed for developers, and I just don't think it should be iin a "stable" release of an OS for a handfull of people who use it for development purposes. Nouveau is a pretty high profile project and just about everyone with an nVidia card is going to want to try it, and I suspect most of them will be pretty disappointed after their system gets messed up. I think at a _minimum_ Nouveau should be atleast as good as the nv driver before including it, otherwise I see no point. -Xul"Tired of repeating the same thing over and over and over again to unfortunate n00bs on IRC asking how to fix their system after installing Nouveau"Chris From nicolas.mailhot at laposte.net Wed May 2 17:22:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 02 May 2007 19:22:52 +0200 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> Message-ID: <1178126572.29891.2.camel@rousalka.dyndns.org> Le mercredi 02 mai 2007 ? 10:08 -0700, Christopher Stone a ?crit : > I think at a _minimum_ Nouveau should be atleast as good as the nv > driver before including it, otherwise I see no point. That seems the case there (been running it for some time) You have a renouveau rpm and even more experimental stuff there if you want : http://people.freedesktop.org/~hughsient/fedora/7/ -- 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.tmp0701.nospam at arcor.de Wed May 2 17:32:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 2 May 2007 19:32:42 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-05-02 In-Reply-To: <20070502165348.30934.91742@extras64.linux.duke.edu> References: <20070502165348.30934.91742@extras64.linux.duke.edu> Message-ID: <20070502193242.31950e5c.mschwendt.tmp0701.nospam@arcor.de> On Wed, 02 May 2007 16:53:48 -0000, Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > > cbalint AT redhat.com > gdal - 1.4.0-22.fc7.i386 > gdal - 1.4.0-22.fc7.ppc > gdal - 1.4.0-22.fc7.x86_64 Not yet. But the "dap" updates in needsign will break it. From sundaram at fedoraproject.org Wed May 2 17:35:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 23:05:37 +0530 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> Message-ID: <4638CBE9.4050204@fedoraproject.org> Christopher Stone wrote: > I think at a _minimum_ Nouveau should be atleast as good as the nv > driver before including it, otherwise I see no point. > Yes it is. We can add a note on the release notes that explaining the status if the helps. Rahul From sdl.web at gmail.com Wed May 2 17:50:25 2007 From: sdl.web at gmail.com (Leo) Date: Wed, 02 May 2007 18:50:25 +0100 Subject: Blank screen and no xv video References: Message-ID: ----- Leo (2007-04-30) wrote:----- > 1. Blank screen > > When the screen enter screensaver mode, there is no way to activate > it again i.e. there is no dialogue for user to enter password to > unlock the screen. The whole screen stay black all the time > although it still respond to Ctrl+Alt+Backspace Anyone seeing this problem? -- Leo (GPG Key: 9283AA3F) From chris.stone at gmail.com Wed May 2 17:59:04 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 2 May 2007 10:59:04 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <4638CBE9.4050204@fedoraproject.org> References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <4638CBE9.4050204@fedoraproject.org> Message-ID: On 5/2/07, Rahul Sundaram wrote: > Christopher Stone wrote: > > > I think at a _minimum_ Nouveau should be atleast as good as the nv > > driver before including it, otherwise I see no point. > > > > Yes it is. We can add a note on the release notes that explaining the > status if the helps. According to the original post of this thread, it is not as stable as nv. Does the nv driver render your virtual terminals busted or kill your gnome session as stated in the original post? If so, then the nv driver is far more unstable than I had thought. Not only should you add a note to the release notes, you should probably also add a Conflicts with compiz to try and put a minimal amount of n00b protection in the package. -Xul"will just redirect IRC n00bs using Nouveau to bugzilla"Chris From ajackson at redhat.com Wed May 2 17:39:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 02 May 2007 13:39:39 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <4638CBE9.4050204@fedoraproject.org> Message-ID: <1178127579.19384.46.camel@localhost.localdomain> On Wed, 2007-05-02 at 10:59 -0700, Christopher Stone wrote: > According to the original post of this thread, it is not as stable as > nv. Does the nv driver render your virtual terminals busted or kill > your gnome session as stated in the original post? If so, then the nv > driver is far more unstable than I had thought. nv has known hang bugs. And sometimes doesn't VT switch right. And sometimes gets confused about picking which output to use if you have more than one connected. There are no good X drivers. > Not only should you add a note to the release notes, you should > probably also add a Conflicts with compiz to try and put a minimal > amount of n00b protection in the package. No, sorry, wrong. If compiz makes nouveau crash as shipped that's merely a bug that needs fixing. X should be smart enough to not crash when that happens and if it's not it's almost certainly easyfix. - ajax From sundaram at fedoraproject.org Wed May 2 18:06:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 23:36:12 +0530 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <4638CBE9.4050204@fedoraproject.org> Message-ID: <4638D314.2020602@fedoraproject.org> Christopher Stone wrote: > > According to the original post of this thread, it is not as stable as > nv. Does the nv driver render your virtual terminals busted or kill > your gnome session as stated in the original post? If so, then the nv > driver is far more unstable than I had thought. The spec is a bit outdated at this point. Things have moved ahead. > Not only should you add a note to the release notes, Feel free to add notes in http://fedoraproject.org/wiki/Docs/Beats/Xorg you should > probably also add a Conflicts with compiz to try and put a minimal > amount of n00b protection in the package. This is over the top, violates our packaging guidelines and is not very user friendly. Rahul From chris.stone at gmail.com Wed May 2 18:13:42 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 2 May 2007 11:13:42 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <4638D314.2020602@fedoraproject.org> References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <4638CBE9.4050204@fedoraproject.org> <4638D314.2020602@fedoraproject.org> Message-ID: On 5/2/07, Rahul Sundaram wrote: > Christopher Stone wrote: > > > > > According to the original post of this thread, it is not as stable as > > nv. Does the nv driver render your virtual terminals busted or kill > > your gnome session as stated in the original post? If so, then the nv > > driver is far more unstable than I had thought. > > The spec is a bit outdated at this point. Things have moved ahead. > > > Not only should you add a note to the release notes, > > Feel free to add notes in http://fedoraproject.org/wiki/Docs/Beats/Xorg You guys do whatever you want. I've already spent more time with this than I want. I just don't see any value with adding this package at this piont. -Xul"pre-emptive 'I told you so'"Chris From sundaram at fedoraproject.org Wed May 2 18:17:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 May 2007 23:47:28 +0530 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <4638CBE9.4050204@fedoraproject.org> <4638D314.2020602@fedoraproject.org> Message-ID: <4638D5B8.2010206@fedoraproject.org> Christopher Stone wrote: > You guys do whatever you want. I've already spent more time with this > than I want. I just don't see any value with adding this package at > this piont. I don't see any value in this discussion either. It's a done deal. Rahul From buildsys at fedoraproject.org Wed May 2 18:21:54 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 2 May 2007 14:21:54 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-02 Message-ID: <20070502182154.94980152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 34 915resolution-0.5.3-1.fc7 bcfg2-0.9.3-1.fc7 bsd-games-2.17-20.fc7 dstat-0.6.6-1.fc7 eclipse-mylar-2.0-0.1.M2a.1.fc7 NEW evolution-brutus-1.1.26.2-2.fc7 gtkwave-3.0.28-1.fc7 NEW kcemirror-0.1.5-1.fc7 kipi-plugins-0.1.3-4.fc7 kmenu-gnome-0.6.3-1.fc7 NEW libmimedir-0.4-3.fc7 NEW librapi-0.9.3-1.fc7 NEW librra-0.9.2-3.fc7 NEW libsynce-0.9.3-1.fc7 nautilus-python-0.4.3-4.fc7 openvrml-0.16.4-2.fc7 NEW perl-Email-Simple-Creator-1.420-2.fc7 NEW perl-GTop-0.16-3.fc7 perl-Imager-0.57-1.fc7 NEW perl-Test-use-ok-0.02-3.fc7 php-pear-Net-UserAgent-Detect-2.3.0-1.fc7 php-pear-Structures-DataGrid-0.8.3-1.fc7 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.fc7 NEW pidgin-rhythmbox-2.0-1.fc7 NEW pigment-0.1.5-1.fc7 smb4k-0.8.2-1.fc7 synce-0.9.1-10.fc7 NEW synce-kde-0.9.1-1.fc7 NEW synce-serial-0.9.1-2.fc7 NEW syncekonnector-0.3.2-1.fc7 sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7 NEW vdccm-0.9.3-1.fc7 vdr-1.4.6-3.fc7 yum-utils-1.1.3-1.fc7 Packages built and released for Fedora Extras 6: 12 dap-server-3.7.4-2.fc6 em8300-kmod-0.16.1-3.2.6.20_1.2948.fc6 gtkwave-3.0.28-1.fc6 nautilus-python-0.4.3-4.fc6 openvrml-0.16.4-2.fc6 perl-Imager-0.57-1.fc6 php-pear-Net-UserAgent-Detect-2.3.0-1.fc6 NEW pigment-0.1.5-1.fc6 smb4k-0.8.2-1.fc6 sysprof-kmod-1.0.8-1.2.6.20_1.2948.fc6 vdr-1.4.6-3.fc6 yumex-1.2.3-1.0.fc6 Packages built and released for Fedora Extras 5: 7 em8300-kmod-0.16.1-0.2.6.20_1.2316.fc5.2 gtkwave-3.0.28-1.fc5 pdns-2.9.21-1.fc5 perl-Imager-0.57-1.fc5 php-pear-Net-UserAgent-Detect-2.3.0-1.fc5 smb4k-0.8.2-1.fc5 sysprof-kmod-1.0.8-1.2.6.20_1.2316.fc5 915resolution-0.5.3-1.fc7 ------------------------- * Mon Apr 30 2007 Chris Weyl 0.5.3-1 - update to 0.5.3 bcfg2-0.9.3-1.fc7 ----------------- * Mon Apr 30 2007 Jeffrey C. Ollie - 0.9.3-1 - Update to 0.9.3 bsd-games-2.17-20.fc7 --------------------- * Mon Apr 30 2007 Wart 2.17-20 - Fix one more place where tetris must be renamed to bsd-fbg * Mon Apr 30 2007 Wart 2.17-19 - Rename tetris to avoid legal quandries dstat-0.6.6-1.fc7 ----------------- * Tue May 01 2007 Scott Baker - 0.6.6-1 - Bumped to latest release * Wed Apr 18 2007 Scott Baker - 0.6.5-1 - Bumped to latest release eclipse-mylar-2.0-0.1.M2a.1.fc7 ------------------------------- * Wed Apr 25 2007 Andrew Overholt 2.0-0.1.M2a.1 - 2.0M2a (a re-tag to fix some tagging issues). evolution-brutus-1.1.26.2-2.fc7 ------------------------------- * Wed May 02 2007 Brian Pepple - 1.1.26.2-2 - Add patch to fix eof ppc error. * Tue May 01 2007 Brian Pepple - 1.1.26.2-1 - Update to 1.1.26.2. - Drop patch to fix build on x86_64, fixed upstream. * Fri Apr 27 2007 Brian Pepple - 1.1.26.0-2 - add patch to build on x86_64. - Minor formatting changes. * Fri Apr 27 2007 Brian Pepple - 1.1.26.0-1 - Update to 1.1.26.0. - Drop BR on gpgme-devel, and add BR on libgcrypt-devel. * Wed Apr 25 2007 Brian Pepple - 1.1.25.9-3 - Remove unnecessary requires for devel subpackage. * Tue Apr 24 2007 Brian Pepple - 1.1.25.9-2 - Drop license in header, since it's not really necessary. - Minor formatting changes. - Remove unnecessary Requires, that are brought in by devel sonames. - Don't package unnecessary docs. - Use %doc macro. * Sat Apr 14 2007 Jules Colding 1.1.25-9 - Added brutus-keyring related files and directories to this spec * Thu Apr 12 2007 Jules Colding 1.1.25-4 - Fixed several Fedora review issues: a) Fixed duplicate CFLAGS due to an error in configure.in b) Removed redundant inclused from *.pc.in files c) Corrected Source0 to point at the right source tar-ball - Stopped using gnome-keyring. Integrated with the new brutus-keyring instead. gtkwave-3.0.28-1.fc7 -------------------- * Tue May 01 2007 Paul Howarth 3.0.28-1 - update to 3.0.28 - update source URL to master source kcemirror-0.1.5-1.fc7 --------------------- kipi-plugins-0.1.3-4.fc7 ------------------------ * Tue May 01 2007 Rex Dieter 0.1.3-4 - --with-libgpod (with patch) kmenu-gnome-0.6.3-1.fc7 ----------------------- * Tue May 01 2007 Chitlesh Goorah - 0.6.3-1 - New upstream release libmimedir-0.4-3.fc7 -------------------- * Tue May 01 2007 Aurelien Bompard 0.4-3 - Ease upgrade path * Mon Apr 02 2007 Aurelien Bompard 0.4-2 - make a -static package librapi-0.9.3-1.fc7 ------------------- librra-0.9.2-3.fc7 ------------------ * Tue May 01 2007 Aurelien Bompard 0.9.2-3 - next try at BRs * Tue May 01 2007 Aurelien Bompard 0.9.2-2 - add an explicit BuildRequires to help yum manage the split - the devel package now has a pkgconfig file, Require it * Tue May 01 2007 Aurelien Bompard 0.9.2-1 - version 0.9.2 - drop patch0 (it uses libsynce's cflags) - new python bindings libsynce-0.9.3-1.fc7 -------------------- nautilus-python-0.4.3-4.fc7 --------------------------- * Wed May 02 2007 Trond Danielsen - 0.4.3-4 - Added missing folder. Fixes bug #238591. * Sat Apr 21 2007 Trond Danielsen - 0.4.3-3 - Moved example code to devel package. openvrml-0.16.4-2.fc7 --------------------- * Tue May 01 2007 Braden McDaniel - 0.16.4-2 - Obsolete openvrml-gtkplug. * Mon Apr 30 2007 Braden McDaniel - 0.16.4-1 - Updated to 0.16.4. - Added BuildRequires for libgnomeui-devel >= 2.14 and curl-devel. - Changed name of gtkplug subpackage to xembed. - Removed -I flag for firefox headers. - Added player subpackage. perl-Email-Simple-Creator-1.420-2.fc7 ------------------------------------- * Sun Apr 29 2007 Tom "spot" Callaway - 1.420-2 - fix LICENSE Warning on build - add missing Test BR perl-GTop-0.16-3.fc7 -------------------- * Mon Apr 30 2007 Chris Weyl 0.16-3 - disable t/threads.t on ppc * Mon Apr 30 2007 Chris Weyl 0.16-2 - bump * Thu Apr 26 2007 Chris Weyl 0.16-1 - Specfile autogenerated by cpanspec 1.69.1. perl-Imager-0.57-1.fc7 ---------------------- * Tue May 01 2007 Steven Pritchard 0.57-1 - Update to 0.57. - BR gdbm-devel. perl-Test-use-ok-0.02-3.fc7 --------------------------- * Mon Apr 30 2007 Chris Weyl 0.02-3 - bump * Tue Apr 10 2007 Chris Weyl 0.02-2 - updated with core modules as BR's * Tue Apr 10 2007 Chris Weyl 0.02-1 - Specfile autogenerated by cpanspec 1.70. php-pear-Net-UserAgent-Detect-2.3.0-1.fc7 ----------------------------------------- * Tue May 01 2007 Christopher Stone 2.3.0-1 - Upstream sync - Update license to 3.01 php-pear-Structures-DataGrid-0.8.3-1.fc7 ---------------------------------------- * Mon Apr 30 2007 Christopher Stone 0.8.3-1 - Upstream sync php-pear-Structures-DataGrid-DataSource-MDB2-0.1.9-1.fc7 -------------------------------------------------------- * Mon Apr 30 2007 Christopher Stone 0.1.9-1 - Upstream sync pidgin-rhythmbox-2.0-1.fc7 -------------------------- * Sun Apr 29 2007 Michel Salim 2.0-1 - Update to 2.0 - Package renamed to pidgin-rhythmbox pigment-0.1.5-1.fc7 ------------------- * Mon Apr 16 2007 Matthias Saou 0.1.5-1 - Update to 0.1.5. - Get rid of the /usr/lib64 RPATH on 64bit. * Mon Apr 16 2007 Matthias Saou 0.1.4-2 - Update URLs. - Remove still included *.la files. - Have devel require gtk-doc for parent directory ownership. smb4k-0.8.2-1.fc7 ----------------- * Tue May 01 2007 Marcin Garski 0.8.2-1 - Updated to version 0.8.2 - Spec file cleanup synce-0.9.1-10.fc7 ------------------ * Tue May 01 2007 Aurelien Bompard 0.9.1-10 - split and create meta-package to provide an upgrade path synce-kde-0.9.1-1.fc7 --------------------- synce-serial-0.9.1-2.fc7 ------------------------ * Mon Apr 02 2007 Aurelien Bompard 0.9.1-2 - fix typo in description - make udev rules %config(noreplace) syncekonnector-0.3.2-1.fc7 -------------------------- sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7 -------------------------------------- vdccm-0.9.3-1.fc7 ----------------- vdr-1.4.6-3.fc7 --------------- * Tue May 01 2007 Ville Skytt? - 1.4.6-3 - Upstream 1.4.6-1, refresh other patches. yum-utils-1.1.3-1.fc7 --------------------- * Tue May 01 2007 Tim Lauridsen - mark as 1.1.3 * Tue May 01 2007 Seth Vidal - added debuginfo-install * Fri Apr 20 2007 Tim Lauridsen - Added security plugin written by James Antill For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Wed May 2 18:47:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 May 2007 13:47:20 -0500 Subject: Proposal: Repository Community Collaboration Statement References: <4634A1A8.7070903@timj.co.uk> Message-ID: Tim Jackson wrote: ... > Basically: > is this something that people feel could form the basis of something > they'd be willing to sign up to? Or should we all just go back to > arguing about repotags? > > --------------------------------------------------------------------- > Repository Community Collaboration Statement > --------------------------------------------------------------------- +1000000! Fantastically awesome, imho. Extracted and wiki-ized at: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration -- Rex From j.w.r.degoede at hhs.nl Wed May 2 19:03:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 02 May 2007 21:03:35 +0200 Subject: Proposal ocaml guidelines Message-ID: <4638E087.60102@hhs.nl> Hi all, I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 And I've come to the conclusion that we need some kinda ocaml packaging guidelines. Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt Which are PLD resp debian ocaml guidelines. And they seem to agree on most things. Notice that I've exactly 0 experience in packaging or writing caml software, this is all based on common sense and my observations with the 3 packages above. OCaml Guidelines ================ Naming ------ OCaml modules / libs should be named ocaml-foo. (This does not apply to applications written in caml). Rationale: this is how they are named in other distros (Debian, PLD) and this is consistent with perl / php / python. -devel sub-packages ------------------- OCaml software can either be byte compiled, in which case it will need the ocaml runtime and besides the runtime only the files installed by libs / modules under /usr/lib/ocaml/stublibs (the ocaml byte code from libs gets staticly linked into the bytecode-"executable"_. Or they can be compiled to native code in which case all caml specific libs / bindings get staticly linked into the executable (wrapped libraries themself will still be dynamicly linked, but the wrapper code is linked staticly into the executable, this can not be changed). Thus for ocaml modules / lib(wrapper)s, in the case of byte compiled ocaml programs only the files under /usr/lib/ocaml/stublibs from the module/lib are needed, and to run a compiled program nothing from the module/lib is needed. So only the files under /usr/lib/ocaml/stublibs should be in the mainpackage, and if there are no such files (in case of a pure caml module / lib) then the mainpackage should have an empty %files. All other files should go in a -devel package as they are only needed to compile and no to run ocaml programs. Unnecessary files ----------------- This is taken from: http://docs.pld-linux.org/ocaml.html Following files should NOT be distributed: - *.cmo object files. There is however one exception -- if file is needed for link (like gtkInit.cmo in lablgtk or std_exit.cmo in OCaml itself), then it should be of course included. - *.o for corresponding *.cmx. They are included in *.a anyway. Exception -- as above. - *.ml sources. - *.mli interface sources. However, if package lacks any documentation (which is unfortunately often the case), you can include *.mli, but it should be gziped and placed in package as %doc. Regards, Hans From miles.lane at gmail.com Wed May 2 19:32:38 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 2 May 2007 12:32:38 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178126572.29891.2.camel@rousalka.dyndns.org> References: <46385951.3070506@fedoraproject.org> <4638C171.9050402@fedoraproject.org> <1178126572.29891.2.camel@rousalka.dyndns.org> Message-ID: On 5/2/07, Nicolas Mailhot wrote: > Le mercredi 02 mai 2007 ? 10:08 -0700, Christopher Stone a ?crit : > > > I think at a _minimum_ Nouveau should be atleast as good as the nv > > driver before including it, otherwise I see no point. > > That seems the case there (been running it for some time) > You have a renouveau rpm and even more experimental stuff there if you > want : http://people.freedesktop.org/~hughsient/fedora/7/ Well, whatever got included in the F7T4 x86 LiveCD was busted. Maybe whatever it is that you are running should get included in the release, but it doesn't seem to be there now. Unfortunately, this is the last test before the release. Kinda late to get this right. Miles From jkeating at redhat.com Wed May 2 19:30:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 12:30:47 -0700 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <1178126572.29891.2.camel@rousalka.dyndns.org> Message-ID: <200705021230.47824.jkeating@redhat.com> On Wednesday 02 May 2007 12:32:38 Miles Lane wrote: > Well, whatever got included in the F7T4 x86 LiveCD was busted. > Maybe whatever it is that you are running should get included in the > release, but it doesn't seem to be there now. ?Unfortunately, this is > the last test before the release. ?Kinda late to get this right. Which is why the driver isn't used by default for anything. You have to _know_ about it and _knowningly_ enable it in your config. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jsacco at gnome.org Wed May 2 19:48:42 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Wed, 02 May 2007 15:48:42 -0400 Subject: FC6: Serial port kernel configuration problem for PowerMacs persists... Message-ID: <1178135322.3272.4.camel@rt.jesacco.com> The serial port configuration/contention problem for PowerMacs discussed in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155895 has been fixed in fedora/rawhide but not [yet as of 2May07] in FC6. Hopefully, a back-port is forthcoming. -Joseph -- jsacco [at] gnome [dot] org From drago01 at gmail.com Wed May 2 19:51:00 2007 From: drago01 at gmail.com (dragoran dragoran) Date: Wed, 2 May 2007 21:51:00 +0200 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <200705021230.47824.jkeating@redhat.com> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> Message-ID: On 5/2/07, Jesse Keating wrote: > > On Wednesday 02 May 2007 12:32:38 Miles Lane wrote: > > Well, whatever got included in the F7T4 x86 LiveCD was busted. > > Maybe whatever it is that you are running should get included in the > > release, but it doesn't seem to be there now. Unfortunately, this is > > the last test before the release. Kinda late to get this right. > > Which is why the driver isn't used by default for anything. You have to > _know_ about it and _knowningly_ enable it in your config. maybe adding a warning when turning it on in system-config-display might help? a popup like "if you are using this driver your computer might explode; you have been warned!" well not this but something similar (someone who doesn't know what he is doing wouldn't enable it in xorg.conf) -- > Jesse Keating > Release Engineer: Fedora > > -- > 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 Wed May 2 21:19:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 2 May 2007 13:19:05 -0800 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> Message-ID: <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> On 5/2/07, dragoran dragoran wrote: > maybe adding a warning when turning it on in system-config-display might > help? > a popup like "if you are using this driver your computer might explode; you > have been warned!" > well not this but something similar (someone who doesn't know what he is > doing wouldn't enable it in xorg.conf) And my answer to this.... if anyone is manually selecting a driver from the list..ever... then its that user's responsbility to know whether its going to work or not. If you are going through the trouble of picking your own driver, you sure as hell better have a solid idea as to what driver to pick instead of blithely scanning over the driver names and assuming a particular driver is the one you want. The auto-detection is doing the right thing, its setting up the nv driver. I see no reason to protect users from themselves when they are delibrately exploring non-recommended options. You might as well put a warning up for each and every driver that a user manually selects regardless of the hardware they are using. I'm still not too thrilled about the potential here to see this driver updated multiple times as f7 updates, that all users will need to consume even though its not a part of any hardware auto-detection scheme. Is there anyway we can make this driver optional, so that default install targets don't include it and only people who want to screw around with it get it installed? -jef"bets that if a xorg driver were named crackrock, some people would try to use it just cuz its there"spaleta From mclasen at redhat.com Wed May 2 21:25:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 May 2007 17:25:37 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> Message-ID: <1178141137.6784.1.camel@localhost.localdomain> On Wed, 2007-05-02 at 13:19 -0800, Jeff Spaleta wrote: > On 5/2/07, dragoran dragoran wrote: > > maybe adding a warning when turning it on in system-config-display might > > help? > > a popup like "if you are using this driver your computer might explode; you > > have been warned!" > > well not this but something similar (someone who doesn't know what he is > > doing wouldn't enable it in xorg.conf) > > And my answer to this.... if anyone is manually selecting a driver > from the list..ever... then its that user's responsbility to know > whether its going to work or not. If you are going through the > trouble of picking your own driver, you sure as hell better have a > solid idea as to what driver to pick instead of blithely scanning over > the driver names and assuming a particular driver is the one you want. > > The auto-detection is doing the right thing, its setting up the nv > driver. I see no reason to protect users from themselves when they are > delibrately exploring non-recommended options. You might as well put a > warning up for each and every driver that a user manually selects > regardless of the hardware they are using. > > I'm still not too thrilled about the potential here to see this driver > updated multiple times as f7 updates, that all users will need to > consume even though its not a part of any hardware auto-detection > scheme. Is there anyway we can make this driver optional, so that > default install targets don't include it and only people who want to > screw around with it get it installed? Why do you think the driver will have to be continuously revved in F7 ? I would assume that we keep tracking nouveau development in rawhide, and only push F7 updates when there is a major step forward in features or stability that makes it worthwhile. Matthias From jspaleta at gmail.com Wed May 2 21:43:03 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 2 May 2007 13:43:03 -0800 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178141137.6784.1.camel@localhost.localdomain> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178141137.6784.1.camel@localhost.localdomain> Message-ID: <604aa7910705021443l99a97b7s2f9946416acb87fb@mail.gmail.com> On 5/2/07, Matthias Clasen wrote: > Why do you think the driver will have to be continuously revved in F7 ? I'm hoping its not, but I can still be concerned, slightly. If its included, you'll be under pressure from users to rev updates as problems are solved. But if you can convince users to eat from development for incramental updates... more power to you. But however you absolutely scale the concern for the potential for egregious revving, my main thrust is I think that potential is more of a concern for the userbase at larger than any concern over system instability caused by allowing users to manually select the driver for use. -jef"Surely, the massive size of that driver package validates blocking the final release until there is a legal binding document in place that constrains the package maintainers from revving updates too frequently on pain of death"spaleta From nicolas.mailhot at laposte.net Wed May 2 22:43:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 03 May 2007 00:43:37 +0200 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <604aa7910705021443l99a97b7s2f9946416acb87fb@mail.gmail.com> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178141137.6784.1.camel@localhost.localdomain> <604aa7910705021443l99a97b7s2f9946416acb87fb@mail.gmail.com> Message-ID: <1178145817.5113.1.camel@rousalka.dyndns.org> Le mercredi 02 mai 2007 ? 13:43 -0800, Jeff Spaleta a ?crit : > On 5/2/07, Matthias Clasen wrote: > > Why do you think the driver will have to be continuously revved in F7 ? > > I'm hoping its not, but I can still be concerned, slightly. If its > included, you'll be under pressure from users to rev updates as > problems are solved. But if you can convince users to eat from > development for incramental updates... more power to you. The first thing post-F7 will be to split nouveau from the nv package so nouveau updates do not impact the vast majority of nv users -- 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 tibbs at math.uh.edu Thu May 3 02:17:23 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 May 2007 21:17:23 -0500 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178141137.6784.1.camel@localhost.localdomain> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178141137.6784.1.camel@localhost.localdomain> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> Why do you think the driver will have to be continuously revved in MC> F7 ? I would assume that we keep tracking nouveau development in MC> rawhide, and only push F7 updates when there is a major step MC> forward in features or stability that makes it worthwhile. Well, consider why it's being included in the first place. If it's there so that people can try it out, the last thing we want is them trying out a version that's months old and then annoying the developers with bug reports for an ancient version. Besides, with software this early in its lifetime, every bugfix is a major step forward. If it's going to languish, it would probably be better to not ship it at all, but I think having it and updating it often would be best. The package is only a third of a megabyte, after all. The whole thing is blocked on TTM in any case, so I don't really expect that things are going to progress very quickly for a while. - J< From jkeating at redhat.com Thu May 3 04:32:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 21:32:32 -0700 Subject: Core / Extras -> Fedora Message-ID: <200705022132.32870.jkeating@redhat.com> That's right, it's finally here. We are merging Core and Extras into just Fedora. The work started this morning, and some processes will continue through the night. Tomorrow we'll pick up where things left off and continue making it happen. As such, there will not be a new rawhide tonight, and there won't be any Extras pushes for devel either. See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge for further details. More news will follow as we get closer to finalizing the merger. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From miles.lane at gmail.com Thu May 3 06:03:54 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 2 May 2007 23:03:54 -0700 Subject: F7T4 -- pidgin-2.0.0-0.36.beta7.fc7 doesn't list jabber as a available protocol Message-ID: I am attempting to add my googletalk account to Pidgin, but jabber isn't shown in the list of protocols to select from in the Add Account dialog. From aalam at redhat.com Thu May 3 06:18:40 2007 From: aalam at redhat.com (A S Alam) Date: Thu, 03 May 2007 11:48:40 +0530 Subject: F7T4 -- pidgin-2.0.0-0.36.beta7.fc7 doesn't list jabber as a available protocol In-Reply-To: References: Message-ID: <46397EC0.5060603@redhat.com> Miles Lane ?? ?????: > I am attempting to add my googletalk account to Pidgin, but jabber > isn't shown in the list of protocols to select from in the Add Account > dialog. > please check the bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238666 regards -- A S Alam #fedora-l10n (freenode) tz GMT+5:30 "Either find a way or Make one" From dblistsub-fedora at yahoo.it Thu May 3 10:38:44 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Thu, 3 May 2007 12:38:44 +0200 Subject: Error messages with e1000 driver in Fedora 7 test 4 KDE live CD Message-ID: <200705031238.44646.dblistsub-fedora@yahoo.it> Greetings, I would like to report the following messages which I spotted on bootup and shutdown of the Live CD on an x86_64 host - fairly frequent but not 100% reproducible: On network shutdown e1000_reset: hardware error On network startup Unable to allocate NMI interrupt error -22 The card is reported as 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02) the network is however functional. I used to have similar errors on Fedora Core 6 until I disabled HAL, which sometimes died with a backtrace on boot. Thank you for your consideration, Davide Bolcioni -- Paranoia is a survival asset. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From fedora at camperquake.de Thu May 3 11:06:04 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 3 May 2007 13:06:04 +0200 Subject: Error messages with e1000 driver in Fedora 7 test 4 KDE live CD In-Reply-To: <200705031238.44646.dblistsub-fedora@yahoo.it> References: <200705031238.44646.dblistsub-fedora@yahoo.it> Message-ID: <20070503130604.7167e0a4@banea.int.addix.net> Hi. On Thu, 3 May 2007 12:38:44 +0200, Davide Bolcioni wrote: > On network startup > Unable to allocate NMI interrupt error -22 That is just a warning, and can be ignored. It should not appear on the console, though. From jos at mijnkamer.nl Thu May 3 12:32:17 2007 From: jos at mijnkamer.nl (Jos Poortvliet) Date: Thu, 3 May 2007 14:32:17 +0200 Subject: KDE alpha 1 packages for Fedora? Message-ID: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> Dear people, In a few days KDE 4 alpha 1 will be released, and we would like to give as many people as possible the opportunity to have a look at the next generation Linux Desktop. Thus an article is being prepared to explain to people how they can obtain KDE 4 Alpha 1 packages. A suse livecd already exists, and packages will be available for Suse, Ubuntu, Debian and OS X, but we haven't heard from the Fedora community yet. So, as to ensure the article will be reasonable complete, we'd like to inquire if Fedora will have Alpha 1 packages available to it's users. We thank you for any comments on this matter. Greetings, Jos Poortvliet (KDE-nl) ps please reply to me as well, as I'm not (yet) subscribed to the fedora-marketing list (and I hope this message gets through moderation) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Thu May 3 12:45:50 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 03 May 2007 13:45:50 +0100 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178145817.5113.1.camel@rousalka.dyndns.org> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178141137.6784.1.camel@localhost.localdomain> <604aa7910705021443l99a97b7s2f9946416acb87fb@mail.gmail.com> <1178145817.5113.1.camel@rousalka.dyndns.org> Message-ID: <1178196350.2733.10.camel@hughsie-laptop> On Thu, 2007-05-03 at 00:43 +0200, Nicolas Mailhot wrote: > > The first thing post-F7 will be to split nouveau from the nv package > so nouveau updates do not impact the vast majority of nv users Yes, this would be great. In my utopia repo that's exactly what I've done (but it's not handled well). In an ideal world nv and nouveau would be packaged separately in f7 and then I can just provide bleeeeding packages for xorg-driver-nouveau and leave the nv driver alone. Richard. From hughsient at gmail.com Thu May 3 12:48:27 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 03 May 2007 13:48:27 +0100 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178141137.6784.1.camel@localhost.localdomain> Message-ID: <1178196507.2733.14.camel@hughsie-laptop> On Wed, 2007-05-02 at 21:17 -0500, Jason L Tibbitts III wrote: > > The whole thing is blocked on TTM in any case, so I don't really > expect that things are going to progress very quickly for a while. Not quite. Textures are sortof stopped by TTM (as it's little point re-inventing the wheel) but other stuff like glxgears (and other trivial opengl stuff) should be working[1]. People are working on foundation stuff behind the scenes, so to speak. Put it this way: in a few months time I'm expecting to be playing Q3 on nouveau. Richard. [1] with updated mesa packages From kevin.kofler at chello.at Thu May 3 12:54:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 12:54:15 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> Message-ID: Jos Poortvliet mijnkamer.nl> writes: > Dear people,In a few days KDE 4 alpha 1 will be released, and we would like > to give as many people as possible the opportunity to have a look at the next > generation Linux Desktop. Thus an article is being prepared to explain to > people how they can obtain KDE 4 Alpha 1 packages. A suse livecd already > exists, and packages will be available for Suse, Ubuntu, Debian and OS X, but > we haven't heard from the Fedora community yet. So, as to ensure the article > will be reasonable complete, we'd like to inquire if Fedora will have Alpha 1 > packages available to it's users. I have parallel-installable kdelibs4, kdepimlibs4 and kdebase4 packages which are currently at 3.80.3 (with assorted backported bugfixes) and which I'm planning to upgrade to alpha 1 as soon as it's out. However, my packages are primarily targeted at developers, not as a sneak preview for users like the SuSE KDE 4 Live CD. So the focus so far has been safe parallel-installability with KDE 3 (so a developer can work on KDE 3 and target KDE 4), not full module coverage. I think that for Fedora 8, we will want KDE 4 packaged differently, with KDE 4 as default, all KDE 4 modules packaged and compat-kdelibs3 (and probably compat-kdebase3 with a subset of the current KDE 3 kdebase, e.g. the KControl modules which are needed by some applications) to run programs which haven't been ported yet. (Hopefully we won't need more compat-kde*3 stuff.) But we have all been busy with the TODO list for the Fedora 7 release, so we didn't have time to discuss this, and thus it's just my personal plan. Of course, packaging for Fedora 8 will not start before Fedora 7 is out, which is 3 weeks from now if things go well. So I don't know of anyone working on KDE 4 packages like this. I'm sorry, but I'm not personally going to work on any KDE-4-as-default packages nor on any KDE 4 modules beyond the basic development platform (kdebase4 + dependencies) before Rawhide opens for Fedora 8 at the earliest. I'm already way too busy. IMHO, alpha 1 is too early for use as a default desktop for end users anyway. If you want to run (or develop) individual KDE 4 apps on a KDE 3 desktop, my packages are enough (I haven't packaged any such app yet though, and I probably won't have the time to package any any time soon); for replacing KDE 3 altogether, it's IMHO too early, Fedora 8 is the target I suggest there (but I may even be overruled and the target set to Fedora 9 instead, we haven't had a chance to discuss this yet; it will also depend on the Fedora 8 schedule which AFAIK is not decided yet). Kevin Kofler From jos at mijnkamer.nl Thu May 3 13:00:21 2007 From: jos at mijnkamer.nl (Jos Poortvliet) Date: Thu, 3 May 2007 15:00:21 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> Message-ID: <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> On 5/3/07, Kevin Kofler wrote: > > Jos Poortvliet mijnkamer.nl> writes: > > Dear people,In a few days KDE 4 alpha 1 will be released, and we would > like > > to give as many people as possible the opportunity to have a look at the > next > > generation Linux Desktop. Thus an article is being prepared to explain > to > > people how they can obtain KDE 4 Alpha 1 packages. A suse livecd already > > exists, and packages will be available for Suse, Ubuntu, Debian and OS > X, but > > we haven't heard from the Fedora community yet. So, as to ensure the > article > > will be reasonable complete, we'd like to inquire if Fedora will have > Alpha 1 > > packages available to it's users. > > I have parallel-installable kdelibs4, kdepimlibs4 and kdebase4 packages > which > are currently at 3.80.3 (with assorted backported bugfixes) and which I'm > planning to upgrade to alpha 1 as soon as it's out. However, my packages > are > primarily targeted at developers, not as a sneak preview for users like > the > SuSE KDE 4 Live CD. So the focus so far has been safe > parallel-installability > with KDE 3 (so a developer can work on KDE 3 and target KDE 4), not full > module > coverage. > > I think that for Fedora 8, we will want KDE 4 packaged differently, with > KDE 4 > as default, all KDE 4 modules packaged and compat-kdelibs3 (and probably > compat-kdebase3 with a subset of the current KDE 3 kdebase, e.g. the > KControl > modules which are needed by some applications) to run programs which > haven't > been ported yet. (Hopefully we won't need more compat-kde*3 stuff.) But we > have > all been busy with the TODO list for the Fedora 7 release, so we didn't > have > time to discuss this, and thus it's just my personal plan. Of course, > packaging > for Fedora 8 will not start before Fedora 7 is out, which is 3 weeks from > now > if things go well. > > So I don't know of anyone working on KDE 4 packages like this. I'm sorry, > but > I'm not personally going to work on any KDE-4-as-default packages nor on > any > KDE 4 modules beyond the basic development platform (kdebase4 + > dependencies) > before Rawhide opens for Fedora 8 at the earliest. I'm already way too > busy. > IMHO, alpha 1 is too early for use as a default desktop for end users > anyway. > If you want to run (or develop) individual KDE 4 apps on a KDE 3 desktop, > my > packages are enough (I haven't packaged any such app yet though, and I > probably > won't have the time to package any any time soon); for replacing KDE 3 > altogether, it's IMHO too early, Fedora 8 is the target I suggest there > (but I > may even be overruled and the target set to Fedora 9 instead, we haven't > had a > chance to discuss this yet; it will also depend on the Fedora 8 schedule > which > AFAIK is not decided yet). It sounds like I can mention Fedora only has the base packages, mostly aimed at developers. Can you point me to a location I can link to where users can get these packages (or instructions how to get them)? thanx in advance Jos Kevin Kofler > > -- > 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 kevin.kofler at chello.at Thu May 3 13:02:46 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 13:02:46 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: Jos Poortvliet mijnkamer.nl> writes: > It sounds like I can mention Fedora only has the base packages, mostly aimed > at developers. Can you point me to a location I can link to where users can > get these packages (or instructions how to get them)? They are in the kde-redhat unstable repository. http://kde-redhat.sourceforge.net/ Kevin Kofler From jos at mijnkamer.nl Thu May 3 13:09:01 2007 From: jos at mijnkamer.nl (Jos Poortvliet) Date: Thu, 3 May 2007 15:09:01 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: <5c77e14b0705030609r1b04bcb0l1b88b38c77e2f3ea@mail.gmail.com> On 5/3/07, Kevin Kofler wrote: > > Jos Poortvliet mijnkamer.nl> writes: > > It sounds like I can mention Fedora only has the base packages, mostly > aimed > > at developers. Can you point me to a location I can link to where users > can > > get these packages (or instructions how to get them)? > > They are in the kde-redhat unstable repository. > http://kde-redhat.sourceforge.net/ > > Kevin Kofler Thank you. This is more or less what will be mentioned: Additionally, there are distro packages becoming available. Packages are (or will be very shortly) available for:
- Kubuntu
- OpenSuse
- OS X
- Debian
Some distributions only have some KDE 4 packages, like the KDE libraries and the basic desktop, but those are mainly intended for developers so they can easily work on KDE 4 applications:
- Fedora
-------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Thu May 3 13:09:03 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 May 2007 08:09:03 -0500 Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Jos Poortvliet mijnkamer.nl> writes: >> It sounds like I can mention Fedora only has the base packages, mostly >> aimed at developers. Can you point me to a location I can link to where >> users can get these packages (or instructions how to get them)? > > They are in the kde-redhat unstable repository. > http://kde-redhat.sourceforge.net/ When the hussle-bussle dies down (after F7 release?), we can work to submit these for review in Fedora proper. -- Rex From pekane52 at gmail.com Thu May 3 13:41:58 2007 From: pekane52 at gmail.com (Pat Kane) Date: Thu, 3 May 2007 08:41:58 -0500 Subject: F7T4 - sendmail & sm-client hang at boot Message-ID: Just installed F7T4 on my workstation, the sendmail and sm-client hangs (60 sec timeout?) are back. I think I worked around the problem on FC6 by hiding the /etc/rc.d/rc5.d/S80sendmail script, that works okay for me since I have no use for sendmail. Is there a better fix? Pat --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Thu May 3 13:48:22 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 13:48:22 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: Rex Dieter math.unl.edu> writes: > When the hussle-bussle dies down (after F7 release?), we can work to submit > these for review in Fedora proper. Do we really want KDE 4 packaged like that in Fedora 8? May 24 + 6 months = November 24, that's a month after the planned KDE 4.0 release (October 23). Thus I suggest upgrading all of KDE to the alphas in Rawhide as soon as possible after Rawhide opens for F8, with the target of shipping KDE 4.0 in the release (but if we have to ship an RC, so be it, it has been done more than once for the kernel, it has been done for OO.o 2 and parts of GNOME too) and letting KDE 3 be the compat libs, not KDE 4 as in my current packages. Yes, that will mean a lot of packages will initially have to build against compat-kdelibs3, but if we do things right, they'll just work on the shiny new KDE 4 desktop. This is Fedora, not Debian stable, we have to move forward. Consider that Qt 3 is going to be already EOL when Fedora 8 ships. Kevin Kofler From jima at beer.tclug.org Thu May 3 13:49:23 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 3 May 2007 08:49:23 -0500 (CDT) Subject: F7T4 - sendmail & sm-client hang at boot In-Reply-To: References: Message-ID: On Thu, 3 May 2007, Pat Kane wrote: > Just installed F7T4 on my workstation, the sendmail and sm-client hangs > (60 sec timeout?) are back. > I think I worked around the problem on FC6 by hiding the > /etc/rc.d/rc5.d/S80sendmail > script, that works okay for me since I have no use for sendmail. > Is there a better fix? That I've almost always seen, when sendmail does that, it's because there isn't a network interface up, and therefore it can't talk to a DNS server. (Or just the latter -- IIRC, it wants to get DNS replies and will pout for a while if it can't.) ISTR first encountering this while visiting an ISP back in '99. Somewhat worrying that the novice Linux user was the one to figure it out... ;-) Jima From pekane52 at gmail.com Thu May 3 14:02:10 2007 From: pekane52 at gmail.com (Pat Kane) Date: Thu, 3 May 2007 09:02:10 -0500 Subject: F7T4 - audio problem Message-ID: Sometimes after a reboot my audio does not work, when KDE has almost finished with my login, I get a dialog with a message like this: Informational - arts message Sound server informational message: Error while initalizing sound device: default can't be opened for playback (No such file or directory) The workaround is to go into the BIOS setup screen while booting and then back out to continue booting Linux. A simple reboot does not fix the problem. I also had this problem on FC6. I will attach two dmesg logs, one for the broken audio and a second for when the audio is okay. Any clues? Pat --- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # dmesg > audio_broken.txt Linux version 2.6.21-1.3116.fc7 (brewbuilder at hs20-bc1-7.build.redhat.com) (gcc version 4.1.2 20070424 (Red Hat 4.1.2-11)) #1 SMP Thu Apr 26 10:36:44 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: 0000000000000000 size: 00000000000a0000 end: 00000000000a0000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2 copy_e820_map() start: 0000000000100000 size: 000000003f670000 end: 000000003f770000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 000000003f770000 size: 0000000000002000 end: 000000003f772000 type: 4 copy_e820_map() start: 000000003f772000 size: 0000000000021000 end: 000000003f793000 type: 3 copy_e820_map() start: 000000003f793000 size: 000000000006d000 end: 000000003f800000 type: 2 copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end: 00000000fec10000 type: 2 copy_e820_map() start: 00000000fecf0000 size: 0000000000001000 end: 00000000fecf1000 type: 2 copy_e820_map() start: 00000000fed20000 size: 0000000000070000 end: 00000000fed90000 type: 2 copy_e820_map() start: 00000000fee00000 size: 0000000000010000 end: 00000000fee10000 type: 2 copy_e820_map() start: 00000000ffb00000 size: 0000000000500000 end: 0000000100000000 type: 2 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003f770000 (usable) BIOS-e820: 000000003f770000 - 000000003f772000 (ACPI NVS) BIOS-e820: 000000003f772000 - 000000003f793000 (ACPI data) BIOS-e820: 000000003f793000 - 000000003f800000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fecf0000 - 00000000fecf1000 (reserved) BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) 119MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 259952) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 259952 early_node_map[1] active PFN ranges 0: 0 -> 259952 On node 0 totalpages: 259952 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 2860 pages used for memmap Normal zone: 222420 pages, LIFO batch:31 HighMem zone: 388 pages used for memmap HighMem zone: 30188 pages, LIFO batch:7 DMI 2.3 present. Using APIC driver default ACPI: RSDP 000FEB90, 0014 (r0 DELL ) ACPI: RSDT 000FD283, 0034 (r1 DELL DE051 8 ASL 61) ACPI: FACP 000FD2B7, 0074 (r1 DELL DE051 8 ASL 61) ACPI: DSDT FFFCF83C, 24C9 (r1 DELL dt_ex 1000 MSFT 100000D) ACPI: FACS 3F770000, 0040 ACPI: SSDT FFFD1E42, 00BA (r1 DELL st_ex 1000 MSFT 100000D) ACPI: APIC 000FD32B, 006C (r1 DELL DE051 8 ASL 61) ACPI: BOOT 000FD397, 0028 (r1 DELL DE051 8 ASL 61) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 3f800000:bf400000) Built 1 zonelists. Total pages: 256652 Kernel command line: ro root=LABEL=/ rhgb quiet mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c079f000 soft=c077f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2527.277 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1096 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1015644k/1039808k available (2150k kernel code, 23428k reserved, 1140k data, 248k init, 122304k highmem) virtual kernel memory layout: fixmap : 0xffc56000 - 0xfffff000 (3748 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc073c000 - 0xc077a000 ( 248 kB) .data : 0xc0619955 - 0xc0736cb4 (1140 kB) .text : 0xc0400000 - 0xc0619955 (2150 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5057.66 BogoMIPS (lpj=2528830) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 256K CPU: Hyper-Threading is disabled CPU: After all inits, caps: bfebf3ff 00000000 00000000 00003180 0000441d 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 12k freed ACPI: Core revision 20070126 CPU0: Intel(R) Celeron(R) CPU 2.53GHz stepping 09 Total of 1 processors activated (5057.66 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Brought up 1 CPUs sizeof(vma)=84 bytes sizeof(page)=52 bytes sizeof(inode)=564 bytes sizeof(dentry)=156 bytes sizeof(ext3inode)=800 bytes sizeof(buffer_head)=56 bytes sizeof(skbuff)=176 bytes sizeof(task_struct)=2704 bytes Time: 7:12:49 Date: 04/03/107 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfbbf0, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) Boot video device is 0000:00:02.0 PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0880-08bf claimed by ICH4 GPIO PCI: Firmware left 0000:01:08.0 e100 interrupts enabled, disabling PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 9 devices usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved pnp: 00:00: iomem range 0x100000-0xffffff could not be reserved pnp: 00:00: iomem range 0x1000000-0x3f76ffff could not be reserved pnp: 00:00: iomem range 0xc0000-0xfffff could not be reserved pnp: 00:08: ioport range 0x800-0x85f has been reserved pnp: 00:08: ioport range 0xc00-0xc7f has been reserved Time: tsc clocksource has been installed. pnp: 00:08: ioport range 0x860-0x8ff could not be reserved PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 PCI: Bridge: 0000:00:1e.0 IO window: d000-dfff MEM window: fa000000-feafffff PREFETCH window: disabled. PCI: Setting latency timer of device 0000:00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 65536 (order: 9, 2359296 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 2793k freed Simple Boot Flag at 0x7a set to 0x1 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. audit: initializing netlink socket (disabled) audit(1178176369.414:1): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks ksign: Installing public key data Loading keyring - Added public key DEDF55B35CB8C48C - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] isapnp: Scanning for PnP cards... Switched to high resolution mode on CPU 0 isapnp: No Plug & Play device found Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux agpgart interface v0.102 (c) Dave Jones agpgart: Detected an Intel 865 Chipset. agpgart: Detected 8060K stolen memory. agpgart: AGP aperture is 128M @ 0xe8000000 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode Magic number: 7:126:217 Freeing unused kernel memory: 248k freed Write protecting the kernel read-only data: 846k USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000ff80 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000ff60 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1d.3 to 64 uhci_hcd 0000:00:1d.3: UHCI Host Controller uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000ff20 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected usb 1-1: new low speed USB device using uhci_hcd and address 2 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: irq 18, io mem 0xffa80800 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 8 ports detected SCSI subsystem initialized libata version 2.20 loaded. ata_piix 0000:00:1f.1: version 2.10ac1 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15 scsi0 : ata_piix ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000 ata1.00: ATA-7: Maxtor 6L160P0, BAJ41G10, max UDMA/133 ata1.00: 312500000 sectors, multi 8: LBA48 ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 ata2.01: ATA-6: WDC WD1200JB-00EVA0, 15.05R15, max UDMA/100 ata2.01: 234441648 sectors, multi 8: LBA48 ata2.00: configured for UDMA/33 ata2.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L160P0 BAJ4 PQ: 0 ANSI: 5 SCSI device sda: 312500000 512-byte hdwr sectors (160000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 312500000 512-byte hdwr sectors (160000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda:<6>usb 4-4: new high speed USB device using ehci_hcd and address 4 sda1 sda2 sda3 < sda5 sda6 > sda4 sd 0:0:0:0: Attached scsi disk sda scsi 1:0:0:0: CD-ROM PHILIPS DVD+-RW DVD8801 2D06 PQ: 0 ANSI: 5 scsi 1:0:1:0: Direct-Access ATA WDC WD1200JB-00E 15.0 PQ: 0 ANSI: 5 SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sd 1:0:1:0: Attached scsi disk sdb usb 4-4: configuration #1 chosen from 1 choice usb 1-1: new low speed USB device using uhci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: DELL DELL USB Keyboard as /class/input/input1 input: USB HID v1.10 Keyboard [DELL DELL USB Keyboard] on usb-0000:00:1d.0-1 usb 1-2: new low speed USB device using uhci_hcd and address 4 usb 1-2: configuration #1 chosen from 1 choice input: Logitech USB Optical Mouse as /class/input/input2 input: USB HID v1.10 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-2 usb 3-2: new full speed USB device using uhci_hcd and address 2 usb 3-2: configuration #1 chosen from 1 choice libusual: modprobe for usb-storage succeeded, but module is not present EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: sdb1: orphan cleanup on readonly fs ext3_orphan_cleanup: deleting unreferenced inode 1178697 EXT3-fs: sdb1: 1 orphan inode deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. security: 3 users, 6 roles, 1801 types, 76 bools, 1 sens, 1024 cats security: 60 classes, 65047 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev sdb1, type ext3), uses xattr SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev cpuset, type cpuset), uses genfs_contexts SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts audit(1178176383.912:2): policy loaded auid=4294967295 sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Attached scsi generic sg1 type 5 sd 1:0:1:0: Attached scsi generic sg2 type 0 sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 20 input: PC Speaker as /class/input/input3 Linux video capture interface: v2.00 cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 22 (level, low) -> IRQ 21 CORE cx88[0]: subsystem: 7063:5500, board: pcHDTV HD5500 HDTV [card=47,autodetected] TV tuner 64 at 0x1fe, Radio tuner -1 at 0x1fe cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded iTCO_vendor_support: vendor-support=0 cx88[0]/0: found at 0000:01:01.0, rev: 5, irq: 21, latency: 64, mmio: 0xfa000000 tuner 1-0043: chip found @ 0x86 (cx88[0]) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0061: chip found @ 0xc2 (cx88[0]) tuner 1-0061: type set to 64 (LG TDVS-H06xF) tuner 1-0061: type set to 64 (LG TDVS-H06xF) cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt 0000:01:01.2[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/2: found at 0000:01:01.2, rev: 5, irq: 21, latency: 64, mmio: 0xfc000000 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007) iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) intel_rng: Firmware space is locked read-only. If you can't or intel_rng: don't want to disable this in firmware setup, and if intel_rng: you are certain that your system has a functional intel_rng: RNG, try using the 'no_fwh_detect' option. rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of 00:05 failed with error -16 e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 22 e100: eth0: e100_probe: addr 0xfeaff000, irq 22, MAC addr 00:16:76:4E:0C:BB parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] parport0: Printer, Hewlett-Packard OfficeJet K80 snd_seq_midi_event: Unknown symbol snd_seq_expand_var_event snd_seq_oss: Unknown symbol snd_midi_event_free snd_seq_oss: Unknown symbol snd_midi_event_no_status snd_seq_oss: Unknown symbol snd_midi_event_new snd_seq_oss: Unknown symbol snd_midi_event_decode snd_seq_oss: Unknown symbol snd_midi_event_encode_byte cx2388x alsa driver version 0.0.6 loaded ACPI: PCI Interrupt 0000:01:01.1[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/1: CX88x/0: ALSA support for cx2388x boards cannot find the slot for index 0 (range 0-0), error: -16 Intel ICH: probe of 0000:00:1f.5 failed with error -12 audit(1178194395.727:3): avc: denied { search } for pid=1043 comm="salsa" name="root" dev=sdb1 ino=5368705 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir loop: loaded (max 8 devices) floppy0: no floppy controllers found lp0: using parport0 (interrupt-driven). lp0: console ready sonypi: Sony Programmable I/O Controller Driver v1.26. SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 audit(1178194405.226:4): avc: denied { search } for pid=1132 comm="rhgb" name="root" dev=sdb1 ino=5368705 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir No dock devices found. input: Power Button (FF) as /class/input/input4 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input5 ACPI: Power Button (CM) [VBTN] ibm_acpi: ec object not found device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com device-mapper: multipath: version 1.0.5 loaded EXT3 FS on sdb1, internal journal SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs kjournald starting. Commit interval 5 seconds EXT3 FS on sdb3, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev sdb3, type ext3), uses xattr Adding 1028120k swap on /dev/sda6. Priority:-1 extents:1 across:1028120k Adding 1807304k swap on /dev/sdb2. Priority:-2 extents:1 across:1807304k SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts IA-32 Microcode Update Driver: v1.14a ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (8123 buckets, 64984 max) e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex audit(1178194423.223:5): audit_pid=1716 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0 SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: HIDP (Human Interface Emulation) ver 1.2 SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 cx2388x dvb driver version 0.0.6 loaded cx8802_register_driver() ->registering driver type=dvb access=shared CORE cx88[0]: subsystem: 7063:5500, board: pcHDTV HD5500 HDTV [card=47] cx88[0]/2: cx2388x based dvb card DVB: registering new adapter (cx88[0]). DVB: registering frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... -------------- next part -------------- # dmesg > audio_ok.txt Linux version 2.6.21-1.3116.fc7 (brewbuilder at hs20-bc1-7.build.redhat.com) (gcc version 4.1.2 20070424 (Red Hat 4.1.2-11)) #1 SMP Thu Apr 26 10:36:44 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: 0000000000000000 size: 00000000000a0000 end: 00000000000a0000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2 copy_e820_map() start: 0000000000100000 size: 000000003f670000 end: 000000003f770000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 000000003f770000 size: 0000000000002000 end: 000000003f772000 type: 4 copy_e820_map() start: 000000003f772000 size: 0000000000021000 end: 000000003f793000 type: 3 copy_e820_map() start: 000000003f793000 size: 000000000006d000 end: 000000003f800000 type: 2 copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end: 00000000fec10000 type: 2 copy_e820_map() start: 00000000fecf0000 size: 0000000000001000 end: 00000000fecf1000 type: 2 copy_e820_map() start: 00000000fed20000 size: 0000000000070000 end: 00000000fed90000 type: 2 copy_e820_map() start: 00000000fee00000 size: 0000000000010000 end: 00000000fee10000 type: 2 copy_e820_map() start: 00000000ffb00000 size: 0000000000500000 end: 0000000100000000 type: 2 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003f770000 (usable) BIOS-e820: 000000003f770000 - 000000003f772000 (ACPI NVS) BIOS-e820: 000000003f772000 - 000000003f793000 (ACPI data) BIOS-e820: 000000003f793000 - 000000003f800000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fecf0000 - 00000000fecf1000 (reserved) BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) 119MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 259952) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 259952 early_node_map[1] active PFN ranges 0: 0 -> 259952 On node 0 totalpages: 259952 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 2860 pages used for memmap Normal zone: 222420 pages, LIFO batch:31 HighMem zone: 388 pages used for memmap HighMem zone: 30188 pages, LIFO batch:7 DMI 2.3 present. Using APIC driver default ACPI: RSDP 000FEB90, 0014 (r0 DELL ) ACPI: RSDT 000FD283, 0034 (r1 DELL DE051 8 ASL 61) ACPI: FACP 000FD2B7, 0074 (r1 DELL DE051 8 ASL 61) ACPI: DSDT FFFCF83C, 24C9 (r1 DELL dt_ex 1000 MSFT 100000D) ACPI: FACS 3F770000, 0040 ACPI: SSDT FFFD1E42, 00BA (r1 DELL st_ex 1000 MSFT 100000D) ACPI: APIC 000FD32B, 006C (r1 DELL DE051 8 ASL 61) ACPI: BOOT 000FD397, 0028 (r1 DELL DE051 8 ASL 61) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 3f800000:bf400000) Built 1 zonelists. Total pages: 256652 Kernel command line: ro root=LABEL=/ rhgb quiet mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c079f000 soft=c077f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2527.277 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1096 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1015644k/1039808k available (2150k kernel code, 23428k reserved, 1140k data, 248k init, 122304k highmem) virtual kernel memory layout: fixmap : 0xffc56000 - 0xfffff000 (3748 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc073c000 - 0xc077a000 ( 248 kB) .data : 0xc0619955 - 0xc0736cb4 (1140 kB) .text : 0xc0400000 - 0xc0619955 (2150 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5057.63 BogoMIPS (lpj=2528816) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 256K CPU: Hyper-Threading is disabled CPU: After all inits, caps: bfebf3ff 00000000 00000000 00003180 0000441d 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 12k freed ACPI: Core revision 20070126 CPU0: Intel(R) Celeron(R) CPU 2.53GHz stepping 09 Total of 1 processors activated (5057.63 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Brought up 1 CPUs sizeof(vma)=84 bytes sizeof(page)=52 bytes sizeof(inode)=564 bytes sizeof(dentry)=156 bytes sizeof(ext3inode)=800 bytes sizeof(buffer_head)=56 bytes sizeof(skbuff)=176 bytes sizeof(task_struct)=2704 bytes Time: 7:54:03 Date: 04/03/107 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfbbf0, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) Boot video device is 0000:00:02.0 PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0880-08bf claimed by ICH4 GPIO PCI: Firmware left 0000:01:08.0 e100 interrupts enabled, disabling PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 9 devices usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Time: tsc clocksource has been installed. pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved pnp: 00:00: iomem range 0x100000-0xffffff could not be reserved pnp: 00:00: iomem range 0x1000000-0x3f76ffff could not be reserved pnp: 00:00: iomem range 0xc0000-0xfffff could not be reserved pnp: 00:08: ioport range 0x800-0x85f has been reserved pnp: 00:08: ioport range 0xc00-0xc7f has been reserved pnp: 00:08: ioport range 0x860-0x8ff could not be reserved PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 PCI: Bridge: 0000:00:1e.0 IO window: d000-dfff MEM window: fa000000-feafffff PREFETCH window: disabled. PCI: Setting latency timer of device 0000:00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 65536 (order: 9, 2359296 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 2793k freed Simple Boot Flag at 0x7a set to 0x1 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. audit: initializing netlink socket (disabled) audit(1178178843.411:1): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks ksign: Installing public key data Loading keyring - Added public key DEDF55B35CB8C48C - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] isapnp: Scanning for PnP cards... Switched to high resolution mode on CPU 0 isapnp: No Plug & Play device found Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux agpgart interface v0.102 (c) Dave Jones agpgart: Detected an Intel 865 Chipset. agpgart: Detected 8060K stolen memory. agpgart: AGP aperture is 128M @ 0xe8000000 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode Magic number: 7:847:924 Freeing unused kernel memory: 248k freed Write protecting the kernel read-only data: 846k USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000ff80 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000ff60 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1d.3 to 64 uhci_hcd 0000:00:1d.3: UHCI Host Controller uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000ff20 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected usb 1-1: new low speed USB device using uhci_hcd and address 2 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: irq 18, io mem 0xffa80800 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 8 ports detected SCSI subsystem initialized libata version 2.20 loaded. ata_piix 0000:00:1f.1: version 2.10ac1 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15 scsi0 : ata_piix ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000 ata1.00: ATA-7: Maxtor 6L160P0, BAJ41G10, max UDMA/133 ata1.00: 312500000 sectors, multi 8: LBA48 ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 ata2.01: ATA-6: WDC WD1200JB-00EVA0, 15.05R15, max UDMA/100 ata2.01: 234441648 sectors, multi 8: LBA48 ata2.00: configured for UDMA/33 ata2.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L160P0 BAJ4 PQ: 0 ANSI: 5 SCSI device sda: 312500000 512-byte hdwr sectors (160000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 312500000 512-byte hdwr sectors (160000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda:<6>usb 4-4: new high speed USB device using ehci_hcd and address 4 sda1 sda2 sda3 < sda5 sda6 > sda4 sd 0:0:0:0: Attached scsi disk sda scsi 1:0:0:0: CD-ROM PHILIPS DVD+-RW DVD8801 2D06 PQ: 0 ANSI: 5 scsi 1:0:1:0: Direct-Access ATA WDC WD1200JB-00E 15.0 PQ: 0 ANSI: 5 SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sd 1:0:1:0: Attached scsi disk sdb usb 4-4: configuration #1 chosen from 1 choice usb 1-1: new low speed USB device using uhci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: DELL DELL USB Keyboard as /class/input/input1 input: USB HID v1.10 Keyboard [DELL DELL USB Keyboard] on usb-0000:00:1d.0-1 usb 1-2: new low speed USB device using uhci_hcd and address 4 usb 1-2: configuration #1 chosen from 1 choice input: Logitech USB Optical Mouse as /class/input/input2 input: USB HID v1.10 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-2 usb 3-2: new full speed USB device using uhci_hcd and address 2 usb 3-2: configuration #1 chosen from 1 choice libusual: modprobe for usb-storage succeeded, but module is not present kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. security: 3 users, 6 roles, 1801 types, 76 bools, 1 sens, 1024 cats security: 60 classes, 65047 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev sdb1, type ext3), uses xattr SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev cpuset, type cpuset), uses genfs_contexts SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts audit(1178178852.410:2): policy loaded auid=4294967295 sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Attached scsi generic sg1 type 5 sd 1:0:1:0: Attached scsi generic sg2 type 0 sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 Linux video capture interface: v2.00 ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 20 cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 22 (level, low) -> IRQ 21 CORE cx88[0]: subsystem: 7063:5500, board: pcHDTV HD5500 HDTV [card=47,autodetected] TV tuner 64 at 0x1fe, Radio tuner -1 at 0x1fe cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded iTCO_vendor_support: vendor-support=0 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (21-Jan-2007) iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) input: PC Speaker as /class/input/input3 intel_rng: Firmware space is locked read-only. If you can't or intel_rng: don't want to disable this in firmware setup, and if intel_rng: you are certain that your system has a functional intel_rng: RNG, try using the 'no_fwh_detect' option. cx88[0]/0: found at 0000:01:01.0, rev: 5, irq: 21, latency: 64, mmio: 0xfa000000 tuner 1-0043: chip found @ 0x86 (cx88[0]) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0061: chip found @ 0xc2 (cx88[0]) tuner 1-0061: type set to 64 (LG TDVS-H06xF) tuner 1-0061: type set to 64 (LG TDVS-H06xF) cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt 0000:01:01.2[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/2: found at 0000:01:01.2, rev: 5, irq: 21, latency: 64, mmio: 0xfc000000 parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 22 parport0: Printer, Hewlett-Packard OfficeJet K80 e100: eth0: e100_probe: addr 0xfeaff000, irq 22, MAC addr 00:16:76:4E:0C:BB ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.5 to 64 rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of 00:05 failed with error -16 AC'97 0 analog subsections not ready intel8x0_measure_ac97_clock: measured 50758 usecs intel8x0: clocking to 48000 cx2388x alsa driver version 0.0.6 loaded ACPI: PCI Interrupt 0000:01:01.1[A] -> GSI 22 (level, low) -> IRQ 21 cx88[0]/1: CX88x/0: ALSA support for cx2388x boards audit(1178196863.722:3): avc: denied { search } for pid=1073 comm="salsa" name="root" dev=sdb1 ino=5368705 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir loop: loaded (max 8 devices) floppy0: no floppy controllers found lp0: using parport0 (interrupt-driven). lp0: console ready sonypi: Sony Programmable I/O Controller Driver v1.26. SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 audit(1178196873.721:4): avc: denied { search } for pid=1153 comm="rhgb" name="root" dev=sdb1 ino=5368705 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir No dock devices found. input: Power Button (FF) as /class/input/input4 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input5 ACPI: Power Button (CM) [VBTN] ibm_acpi: ec object not found device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com device-mapper: multipath: version 1.0.5 loaded EXT3 FS on sdb1, internal journal SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs kjournald starting. Commit interval 5 seconds EXT3 FS on sdb3, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev sdb3, type ext3), uses xattr Adding 1028120k swap on /dev/sda6. Priority:-1 extents:1 across:1028120k Adding 1807304k swap on /dev/sdb2. Priority:-2 extents:1 across:1807304k SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts IA-32 Microcode Update Driver: v1.14a ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (8123 buckets, 64984 max) e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex audit(1178197200.671:5): audit_pid=1712 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0 SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: HIDP (Human Interface Emulation) ver 1.2 SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 cx2388x dvb driver version 0.0.6 loaded cx8802_register_driver() ->registering driver type=dvb access=shared CORE cx88[0]: subsystem: 7063:5500, board: pcHDTV HD5500 HDTV [card=47] cx88[0]/2: cx2388x based dvb card DVB: registering new adapter (cx88[0]). DVB: registering frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... From laurent.rineau__fedora_extras at normalesup.org Thu May 3 14:07:06 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 3 May 2007 16:07:06 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> Message-ID: <200705031607.06865@rineau.tsetse> On Thursday 03 May 2007 15:48:22 Kevin Kofler wrote: > Rex Dieter math.unl.edu> writes: > > When the hussle-bussle dies down (after F7 release?), we can work to > > submit these for review in Fedora proper. > > Do we really want KDE 4 packaged like that in Fedora 8? May 24 + 6 months = > November 24, that's a month after the planned KDE 4.0 release (October 23). > Thus I suggest upgrading all of KDE to the alphas in Rawhide as soon as > possible after Rawhide opens for F8 Let wait and see if the KDE project can release KDE-4.0 in time. I?would not like F8 ship a release candidate of KDE4. The KDE desktop is the central part of the KDE spin of Fedora. It has to be stable. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From kevin.kofler at chello.at Thu May 3 14:20:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 14:20:18 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> Message-ID: Laurent Rineau normalesup.org> writes: > > Do we really want KDE 4 packaged like that in Fedora 8? May 24 + 6 months = > > November 24, that's a month after the planned KDE 4.0 release (October 23). > > Thus I suggest upgrading all of KDE to the alphas in Rawhide as soon as > > possible after Rawhide opens for F8 > > Let wait and see if the KDE project can release KDE-4.0 in time. We can't afford to wait, we need to get the development versions into Rawhide ASAP to get it in shape, and then it will be way too late to revert everything without causing a gigantic mess. If we compare the risks, I think shipping a RC which has been tested for months in Rawhide is a much less scary prospect than deciding on importing a release at the last minute with no prior testing. And for the record, I think shipping 3.5 when 4.0 will be out with all the improvements (including standards-compliance, e.g. icon naming spec and shared-mime-info) and when Qt 3 will be completely discontinued by Trolltech (EOL is July 1st, 2007) and when the next opportunity means shipping 4.0 7 months late, when all the other normally slower-moving distros will already have it, is worse than both of these prospects. > I?would not like F8 ship a release candidate of KDE4. The KDE desktop is the > central part of the KDE spin of Fedora. It has to be stable. And the GNOME desktop is the central part of the GNOME spin, yet the GNOME people have already shipped a RC (with some packages which had few changes from RC to final upgraded to the final at the last minute) once. And the kernel is central to the entire distribution, yet it has shipped in RC state more than once. As long as it has been properly tested in Rawhide, it should not be a problem. And don't forget that that's just a worst-case analysis, if F8 is going to use the same 6-month schedule as the other versions, we have an entire month of slack time. Even more if it slips, which is likely to happen considering Fedora's release history. ;-) And besides, that's what updates are for. If the Fedora release ships an RC, that doesn't mean we won't have the final in updates. Kevin Kofler From caillon at redhat.com Thu May 3 14:26:29 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 03 May 2007 10:26:29 -0400 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <200705031607.06865@rineau.tsetse> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> Message-ID: <4639F115.4010403@redhat.com> Laurent Rineau wrote: > On Thursday 03 May 2007 15:48:22 Kevin Kofler wrote: >> Rex Dieter math.unl.edu> writes: >> > When the hussle-bussle dies down (after F7 release?), we can work to >> > submit these for review in Fedora proper. >> >> Do we really want KDE 4 packaged like that in Fedora 8? May 24 + 6 months = >> November 24, that's a month after the planned KDE 4.0 release (October 23). >> Thus I suggest upgrading all of KDE to the alphas in Rawhide as soon as >> possible after Rawhide opens for F8 > > Let wait and see if the KDE project can release KDE-4.0 in time. > > I would not like F8 ship a release candidate of KDE4. The KDE desktop is the > central part of the KDE spin of Fedora. It has to be stable. Release candidates are probably fine. We have shipped release candidates of GNOME, and other software at times. Basically, RCs are the releases that upstream thinks can be releases, but would rather get a wider amount of feedback before making it the actual release. In many cases, upstreams simply rebuild the RC and call it final. What we don't want are alphas or betas or random cvs snapshots in a final release. From ajackson at redhat.com Thu May 3 14:09:42 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 03 May 2007 10:09:42 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> Message-ID: <1178201382.16280.3.camel@localhost.localdomain> On Wed, 2007-05-02 at 13:19 -0800, Jeff Spaleta wrote: > I'm still not too thrilled about the potential here to see this driver > updated multiple times as f7 updates, that all users will need to > consume even though its not a part of any hardware auto-detection > scheme. Is there anyway we can make this driver optional, so that > default install targets don't include it and only people who want to > screw around with it get it installed? Could certainly deliver it as a different binary RPM. This is like five minutes of work, if we think it's worth doing. - ajax From markg85 at gmail.com Thu May 3 14:34:57 2007 From: markg85 at gmail.com (Mark) Date: Thu, 3 May 2007 16:34:57 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <4639F115.4010403@redhat.com> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> <4639F115.4010403@redhat.com> Message-ID: <6e24a8e80705030734y2c0910eaid53ecc20f1468f52@mail.gmail.com> so that means that aplha`s, beta`s en release candidates of KDE 4 will be in the next fedora rawhides? starting from now or FC8 development? i would like this alot ^_^ Thanx, Mark. 2007/5/3, Christopher Aillon : > > Laurent Rineau wrote: > > On Thursday 03 May 2007 15:48:22 Kevin Kofler wrote: > >> Rex Dieter math.unl.edu> writes: > >> > When the hussle-bussle dies down (after F7 release?), we can work to > >> > submit these for review in Fedora proper. > >> > >> Do we really want KDE 4 packaged like that in Fedora 8? May 24 + 6 > months = > >> November 24, that's a month after the planned KDE 4.0 release (October > 23). > >> Thus I suggest upgrading all of KDE to the alphas in Rawhide as soon as > >> possible after Rawhide opens for F8 > > > > Let wait and see if the KDE project can release KDE-4.0 in time. > > > > I would not like F8 ship a release candidate of KDE4. The KDE desktop is > the > > central part of the KDE spin of Fedora. It has to be stable. > > Release candidates are probably fine. We have shipped release > candidates of GNOME, and other software at times. Basically, RCs are > the releases that upstream thinks can be releases, but would rather get > a wider amount of feedback before making it the actual release. In many > cases, upstreams simply rebuild the RC and call it final. > > What we don't want are alphas or betas or random cvs snapshots in a > final release. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu May 3 14:35:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 May 2007 20:05:17 +0530 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <4639F115.4010403@redhat.com> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> <4639F115.4010403@redhat.com> Message-ID: <4639F325.2030806@fedoraproject.org> Christopher Aillon wrote: > > What we don't want are alphas or betas or random cvs snapshots in a > final release. What it is actually called is fairly meaningless. Linus always call the kernel pre stable releases as rc's. Fedora has included openoffice.org 2.0 "milestone" release, gaim 2.0 beta, dovecot beta etc in general releases of Fedora before. Not to mention the gcc release from Red Hat Linux days . What really matters is how much testing that particular software got externally and in a Fedora environment, upstream and developer coordination etc. Sometimes alphas or betas or random cvs snapshots are much more stable than the previously supposedly stable release and is even recommended by upstream in some instances. Rahul From jkeating at redhat.com Thu May 3 14:41:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 10:41:06 -0400 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <4639F325.2030806@fedoraproject.org> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <4639F115.4010403@redhat.com> <4639F325.2030806@fedoraproject.org> Message-ID: <200705031041.06379.jkeating@redhat.com> On Thursday 03 May 2007 10:35:17 Rahul Sundaram wrote: > What really matters is how much testing that particular software got > externally and in a Fedora environment, upstream and developer > coordination etc. Sometimes alphas or betas or random cvs snapshots are > much more stable than the previously supposedly stable release and is > even recommended by upstream in some instances. Well, what really matters is what upstream is planning on doing with the codebase. We ship "pre" releases of various types at various times, but always with a mind of what the upstream will do with them. Most often we ship it only if it goes into a bugfix mode only, and the final release falls somewhere in line with our final freeze date. We absolutely make sure that there aren't any feature enhancements planned for after our feature freeze. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Thu May 3 14:40:04 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 3 May 2007 10:40:04 -0400 (EDT) Subject: Fedora Core 5 end of life is 2007-06-29 Message-ID: All, Several months ago, the Fedora Board (in consultation with Red Hat Engineering) decided to increase the length of time that Fedora releases are supported, in terms of updates. This decision was retroactively applied to Fedora Core 5, allowing it to remain a fully maintained release for several months longer than it would have under our old policy. Fedora 7 will be released on Thursday May 24th, 2007. Fedora Core 5 will reach its End of Life for updates on Friday June 29th, 2007. In total, Fedora Core 5 will have had a lifespan of 15 months. For the sake of comparison, under the old policy, FC5 would have only had a lifespan of 11 months. === Zod insists that Fedora Core 6 receive updates until about one month after the release of Fedora 8. Fedora 7 will receive updates until about one month after the release of Fedora 9. And so on. "Fedora X will receive updates until about one month after the release of Fedora X+2." -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From kevin.kofler at chello.at Thu May 3 14:45:11 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 14:45:11 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> <4639F115.4010403@redhat.com> <6e24a8e80705030734y2c0910eaid53ecc20f1468f52@mail.gmail.com> Message-ID: Mark gmail.com> writes: > so that means that aplha`s, beta`s en release candidates of KDE 4 will be in > the next fedora rawhides? That's my plan. However, other people working on KDE on Fedora may have different plans. > starting from now or FC8 development? F8 development. (FYI, "Core" is no more.) There's no way KDE 4 will be usable as a default desktop by F7, not to mention that F7 is _well_ past feature freeze, so the current F7-targeted Rawhide is not going to get it. (Well, I might try to get my parallel-installable developer packages of kdelibs4, kdepimlibs4 and kdebase4 in once I upgrade them to alpha 1, but that's it for F7.) It's only about 3 weeks until Rawhide will open for F8 development anyway. Kevin Kofler From drago01 at gmail.com Thu May 3 14:48:02 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 03 May 2007 16:48:02 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <4639F325.2030806@fedoraproject.org> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031607.06865@rineau.tsetse> <4639F115.4010403@redhat.com> <4639F325.2030806@fedoraproject.org> Message-ID: <4639F622.9040506@gmail.com> Rahul Sundaram wrote: > Christopher Aillon wrote: > >> >> What we don't want are alphas or betas or random cvs snapshots in a >> final release. > > What it is actually called is fairly meaningless. Linus always call > the kernel pre stable releases as rc's. Fedora has included > openoffice.org 2.0 "milestone" release, gaim 2.0 beta, dovecot beta > etc in general releases of Fedora before. Not to mention the gcc > release from Red Hat Linux days . > don't forget the compiz gut snapshot that where shipped before compiz even had a first release. From hughsient at gmail.com Thu May 3 14:53:00 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 03 May 2007 15:53:00 +0100 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178201382.16280.3.camel@localhost.localdomain> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178201382.16280.3.camel@localhost.localdomain> Message-ID: <1178203980.2733.18.camel@hughsie-laptop> On Thu, 2007-05-03 at 10:09 -0400, Adam Jackson wrote: > Could certainly deliver it as a different binary RPM. This is like > five minutes of work, if we think it's worth doing. Yes, PLEASE PRETTY PLEASE. :-) I can then rebuild daily snapshots of nouveau ddx automatically without playing about with the nv RPM. Richard. From pekane52 at gmail.com Thu May 3 15:08:58 2007 From: pekane52 at gmail.com (Pat Kane) Date: Thu, 3 May 2007 10:08:58 -0500 Subject: F7T4 - audio problem Message-ID: > Sometimes after a reboot my audio does not work, I did a diff of the two dmesg logs and the following lines are the interesting differences: audio_broken ------------ snd_seq_midi_event: Unknown symbol snd_seq_expand_var_event snd_seq_oss: Unknown symbol snd_midi_event_free snd_seq_oss: Unknown symbol snd_midi_event_no_status snd_seq_oss: Unknown symbol snd_midi_event_new snd_seq_oss: Unknown symbol snd_midi_event_decode snd_seq_oss: Unknown symbol snd_midi_event_encode_byte cannot find the slot for index 0 (range 0-0), error: -16 Intel ICH: probe of 0000:00:1f.5 failed with error -12 audio_ok -------- ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:1f.5 to 64 AC'97 0 analog subsections not ready intel8x0_measure_ac97_clock: measured 50758 usecs intel8x0: clocking to 48000 Pat --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Thu May 3 16:00:40 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 03 May 2007 17:00:40 +0100 Subject: F7T4 - audio problem In-Reply-To: References: Message-ID: <1178208040.11120.185.camel@pmac.infradead.org> On Thu, 2007-05-03 at 10:08 -0500, Pat Kane wrote: > > Sometimes after a reboot my audio does not work, > > I did a diff of the two dmesg logs and the following lines > are the interesting differences: Please, read http://david.woodhou.se/email.html -- dwmw2 From gemi at bluewin.ch Thu May 3 16:02:20 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 03 May 2007 18:02:20 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <4638E087.60102@hhs.nl> References: <4638E087.60102@hhs.nl> Message-ID: <1178208140.5401.3.camel@localhost.localdomain> On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: > I got looking into this because of these review requests: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 > > And I've come to the conclusion that we need some kinda ocaml > packaging guidelines. > > Interesting with regards to this are: > http://docs.pld-linux.org/ocaml.html > http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones . -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From rjones at redhat.com Thu May 3 16:30:01 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 03 May 2007 17:30:01 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <1178208140.5401.3.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> Message-ID: <463A0E09.2080305@redhat.com> G?rard Milmeister wrote: > On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: >> I got looking into this because of these review requests: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 >> >> And I've come to the conclusion that we need some kinda ocaml >> packaging guidelines. >> >> Interesting with regards to this are: >> http://docs.pld-linux.org/ocaml.html >> http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt > > Maybe you could start an add something to the fedoraproject wiki, for > example a Ocaml SIG. There has also been some interest in this by > Richard Jones . Thanks for alerting me to this Gerard. I did post to caml-list a while back about the lack of a comprehensive range of OCaml packages in Fedora (versus the case with Debian, for example, where the supported packages are both comprehensive and of very high quality). I didn't get much response, but I'd really like to help out. At my previous company I wrote and maintained a great deal of OCaml software: http://merjis.com/developers Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rdieter at math.unl.edu Thu May 3 16:42:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 May 2007 11:42:21 -0500 Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Rex Dieter math.unl.edu> writes: >> When the hussle-bussle dies down (after F7 release?), we can work to >> submit these for review in Fedora proper. > > Do we really want KDE 4 packaged like that in Fedora 8? If I had to say *right now*, yes. There will still be a whole lot of kde3/legacy libraries/apps, so we'll want to keep co-installability. -- Rex From jos at mijnkamer.nl Thu May 3 15:57:01 2007 From: jos at mijnkamer.nl (jos poortvliet) Date: Thu, 03 May 2007 17:57:01 +0200 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: <200705031041.06379.jkeating@redhat.com> References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <4639F325.2030806@fedoraproject.org> <200705031041.06379.jkeating@redhat.com> Message-ID: <200705031757.01498.jos@mijnkamer.nl> Op Thursday 03 May 2007, schreef Jesse Keating: > On Thursday 03 May 2007 10:35:17 Rahul Sundaram wrote: > > What really matters is how much testing that particular software got > > externally and in a Fedora environment, upstream and developer > > coordination etc. Sometimes alphas or betas or random cvs snapshots are > > much more stable than the previously supposedly stable release and is > > even recommended by upstream in some instances. > > Well, what really matters is what upstream is planning on doing with the > codebase. We ship "pre" releases of various types at various times, but > always with a mind of what the upstream will do with them. Most often we > ship it only if it goes into a bugfix mode only, and the final release > falls somewhere in line with our final freeze date. We absolutely make > sure that there aren't any feature enhancements planned for after our > feature freeze. It's of course not my call at all, but I can tell you the KDE release schedule is quite clear in terms of what is allowed - you can check techbase [1] and see that september 23, KDE will go in a total freeze (only bugfixes) until the final release on oktober 23th. [1] http://techbase.kde.org/Schedules/KDE4/4.0_Release_Schedule -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ? ?A: Because it destroys the flow of the conversation ? ?Q: Why is top-posting bad? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu May 3 17:08:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 17:08:41 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <4639F325.2030806@fedoraproject.org> <200705031041.06379.jkeating@redhat.com> <200705031757.01498.jos@mijnkamer.nl> Message-ID: jos poortvliet mijnkamer.nl> writes: > It's of course not my call at all, but I can tell you the KDE release schedule > is quite clear in terms of what is allowed - you can check techbase [1] and > see that september 23, KDE will go in a total freeze (only bugfixes) until > the final release on oktober 23th. And the feature freeze is even earlier, June 1st, that will be _well_ before F8's feature freeze. Kevin Kofler From jkeating at redhat.com Thu May 3 17:15:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 13:15:45 -0400 Subject: KDE alpha 1 packages for Fedora? In-Reply-To: References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <200705031757.01498.jos@mijnkamer.nl> Message-ID: <200705031315.46054.jkeating@redhat.com> On Thursday 03 May 2007 13:08:41 Kevin Kofler wrote: > And the feature freeze is even earlier, June 1st, that will be _well_ > before F8's feature freeze. So it sounds like the schedule fits up. Be sure to bring this feature up when we start talking about F8 features and timelines and such. The KDE sig will be on the hook for delivering it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu May 3 17:25:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 May 2007 17:25:52 +0000 (UTC) Subject: KDE alpha 1 packages for Fedora? References: <5c77e14b0705030532o1215d62t1e884738c4b480d6@mail.gmail.com> <5c77e14b0705030600o7837099eg6df503517a9d7899@mail.gmail.com> Message-ID: Rex Dieter math.unl.edu> writes: > If I had to say *right now*, yes. There will still be a whole lot of > kde3/legacy libraries/apps, so we'll want to keep co-installability. No doubt we'll still want to be able to run KDE 3 apps! But I'm not sure this will necessarily mean relegating all of KDE 4 to some directory like the /opt/kde4 I'm currently using. If we do that even when KDE 4.0 is supposedly packaged as the default KDE, I'm worried that we're going to be stuck with it forever, like SuSE was with /opt/kde3. (They're now moving back to /usr with KDE 4, they do have the advantage of not having KDE 3 in there.) Hasn't upstream eliminated most of the conflicts in /usr? I could envision packaging both KDE 4 and compat KDE 3 stuff into /usr, and where there are conflicts, just zapping the KDE 3 one. (For example, if it only affects binaries like konqueror which we don't want or need in compat-kdebase3 anyway, we can easily do that.) Of course, I still have to look at the alpha to see how many conflicts there really are left. One definite problem will be the -devel packages, the symlinks will unavoidably conflict. That's a problem most compat-lib packages have, the most common solution is a Conflicts, but I don't really like it. I hope we can think of an acceptable solution which is neither a completely separate prefix nor a -devel conflict. Maybe putting the symlinks into the already existing /usr/lib/kde3 or something similar (/usr/lib/kdelibs3 or whatever)? But that will probably need configure patching in some packages which build against kdelibs3. That was the KDE4DIR part. For what to do about KDE4HOME, that appears still to be an open topic upstream. Speculations are that as long as we don't need to run the KDE 3 and KDE 4 version of the _same_ apps, sharing the directory should just work, but maybe some system services which are always there in both versions can cause trouble. What I know for sure is that as long as there's apps like Konqueror etc. in both kdebase 3 and kdebase 4, sharing KDEHOME won't work. But as I said above, we probably don't want to install the KDE 3 Konqueror at all in F8. The only parts from kdebase 3 which would be useful/needed in a compat-kdebase3 package are the loadable modules (KControl config pages and such). Kevin Kofler From j.w.r.degoede at hhs.nl Thu May 3 18:17:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 May 2007 20:17:16 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <1178208140.5401.3.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> Message-ID: <463A272C.8000201@hhs.nl> G?rard Milmeister wrote: > On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: >> I got looking into this because of these review requests: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 >> >> And I've come to the conclusion that we need some kinda ocaml >> packaging guidelines. >> >> Interesting with regards to this are: >> http://docs.pld-linux.org/ocaml.html >> http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt > > Maybe you could start an add something to the fedoraproject wiki, for > example a Ocaml SIG. There has also been some interest in this by > Richard Jones . Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer here, so to those interested, go ahead create a sig. Maybe Nigel Jones will want to join you too, as he is the submitter of the package review requests linked to above. Either way we need to put down some guidelines, since the current ocaml packages aren't packaged properly (when judging them by the debian / PLD guidelines). Regards, Hans From jkeating at redhat.com Thu May 3 18:21:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 14:21:06 -0400 Subject: Core / Extras -> Fedora In-Reply-To: <200705022132.32870.jkeating@redhat.com> References: <200705022132.32870.jkeating@redhat.com> Message-ID: <200705031421.06357.jkeating@redhat.com> On Thursday 03 May 2007 00:32:32 Jesse Keating wrote: > That's right, it's finally here. We are merging Core and Extras into just > Fedora. The work started this morning, and some processes will continue > through the night. Tomorrow we'll pick up where things left off and > continue making it happen. As such, there will not be a new rawhide > tonight, and there won't be any Extras pushes for devel either. > > See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge for > further details. > > More news will follow as we get closer to finalizing the merger. A status report. CVS contents have been merged for the devel/ branch. A new cvs root, cvs/pkgs is used (cvs/extras is a symlink to this). Latest Extras builds for development have been imported into koji, our new build system. CVS make files have been adjusted to direct builds to koji if done from devel/ Koji is now accepting builds. Whats left? We're going to be working on making rawhide show up. Most likely it will be tomorrow at some point. This includes adjusting the mirror layouts, and providing new fedora-release packages that no longer list both core and extras as separate repositories. Once again, thanks for all your patience. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu May 3 18:40:08 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 May 2007 20:40:08 +0200 Subject: Core / Extras -> Fedora In-Reply-To: <200705031421.06357.jkeating@redhat.com> References: <200705022132.32870.jkeating@redhat.com> <200705031421.06357.jkeating@redhat.com> Message-ID: <463A2C88.9030001@hhs.nl> Jesse Keating wrote: > Whats left? > > We're going to be working on making rawhide show up. Most likely it will be > tomorrow at some point. This includes adjusting the mirror layouts, and > providing new fedora-release packages that no longer list both core and > extras as separate repositories. > > Once again, thanks for all your patience. > > Very very cool, Thank you (and all the other) for your hard work to make this happen! Regards, Hans From a.badger at gmail.com Thu May 3 18:34:40 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 03 May 2007 11:34:40 -0700 Subject: Proposal ocaml guidelines In-Reply-To: <463A272C.8000201@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> Message-ID: <1178217280.12451.31.camel@localhost.localdomain> On Thu, 2007-05-03 at 20:17 +0200, Hans de Goede wrote: > G?rard Milmeister wrote: > > On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: > >> I got looking into this because of these review requests: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 > >> > >> And I've come to the conclusion that we need some kinda ocaml > >> packaging guidelines. > >> > >> Interesting with regards to this are: > >> http://docs.pld-linux.org/ocaml.html > >> http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt > > > > Maybe you could start an add something to the fedoraproject wiki, for > > example a Ocaml SIG. There has also been some interest in this by > > Richard Jones . > > Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer > here, so to those interested, go ahead create a sig. Maybe Nigel Jones will > want to join you too, as he is the submitter of the package review requests > linked to above. > > Either way we need to put down some guidelines, since the current ocaml > packages aren't packaged properly (when judging them by the debian / PLD > guidelines). I can help get the guidelines approved but I'm not an OCaml packager so most of the work will be up to you guys. Discuss the guidelines, either put something under /wiki/PackagingDrafts/ or ping me with a copy that you want to propose and I'll do it. Then it would be tremendously helpful if one of you could make it to a Packaging Meeting where the Guideline gets discussed by the Packaging Committee. That way you can field questions immediately instead of me being a go-between. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wwoods at redhat.com Thu May 3 18:51:38 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 03 May 2007 18:51:38 +0000 Subject: F7T4 - sendmail & sm-client hang at boot In-Reply-To: References: Message-ID: <1178218298.28491.106.camel@metroid.rdu.redhat.com> On Thu, 2007-05-03 at 08:49 -0500, Jima wrote: > On Thu, 3 May 2007, Pat Kane wrote: > > Just installed F7T4 on my workstation, the sendmail and sm-client hangs > > (60 sec timeout?) are back. > > I think I worked around the problem on FC6 by hiding the > > /etc/rc.d/rc5.d/S80sendmail > > script, that works okay for me since I have no use for sendmail. > > Is there a better fix? In my experience this happens when sendmail can't look up your hostname. The usual way to is to make sure your hostname is listed in /etc/hosts on the "localhost" line. For example, on my machine "metroid", /etc/hosts has: 127.0.0.1 localhost.localdomain localhost metroid hope that helps. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jamatos at fc.up.pt Thu May 3 19:03:27 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 3 May 2007 20:03:27 +0100 Subject: Core / Extras -> Fedora In-Reply-To: <463A2C88.9030001@hhs.nl> References: <200705022132.32870.jkeating@redhat.com> <200705031421.06357.jkeating@redhat.com> <463A2C88.9030001@hhs.nl> Message-ID: <200705032003.27205.jamatos@fc.up.pt> On Thursday 03 May 2007 19:40:08 Hans de Goede wrote: > Very very cool, > > Thank you (and all the other) for your hard work to make this happen! Usually I refrain myself from saying "me too" but this occasion really deserves. Thanks to all, > Regards, > > Hans -- Jos? Ab?lio From j.w.r.degoede at hhs.nl Thu May 3 19:23:50 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 May 2007 21:23:50 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <1178217280.12451.31.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> Message-ID: <463A36C6.5000108@hhs.nl> Toshio Kuratomi wrote: > On Thu, 2007-05-03 at 20:17 +0200, Hans de Goede wrote: >> G?rard Milmeister wrote: >>> On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: >>>> I got looking into this because of these review requests: >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 >>>> >>>> And I've come to the conclusion that we need some kinda ocaml >>>> packaging guidelines. >>>> >>>> Interesting with regards to this are: >>>> http://docs.pld-linux.org/ocaml.html >>>> http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt >>> Maybe you could start an add something to the fedoraproject wiki, for >>> example a Ocaml SIG. There has also been some interest in this by >>> Richard Jones . >> Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer >> here, so to those interested, go ahead create a sig. Maybe Nigel Jones will >> want to join you too, as he is the submitter of the package review requests >> linked to above. >> >> Either way we need to put down some guidelines, since the current ocaml >> packages aren't packaged properly (when judging them by the debian / PLD >> guidelines). > > I can help get the guidelines approved but I'm not an OCaml packager so > most of the work will be up to you guys. Discuss the guidelines, either > put something under /wiki/PackagingDrafts/ or ping me with a copy that > you want to propose and I'll do it. Then it would be tremendously > helpful if one of you could make it to a Packaging Meeting where the > Guideline gets discussed by the Packaging Committee. That way you can > field questions immediately instead of me being a go-between. > Okay, The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml If you can let me know where and when the FPC meeting happens, then I can see if I can attend (times in CET please, as a european I'm not used to doing timezone calculations) Regards, Hans From cweyl at alumni.drew.edu Thu May 3 19:24:35 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 3 May 2007 12:24:35 -0700 Subject: Core / Extras -> Fedora In-Reply-To: <200705031421.06357.jkeating@redhat.com> References: <200705022132.32870.jkeating@redhat.com> <200705031421.06357.jkeating@redhat.com> Message-ID: <7dd7ab490705031224j6d1b68bdq1d974c11dd2b44bf@mail.gmail.com> On 5/3/07, Jesse Keating wrote: > A status report. > > CVS contents have been merged for the devel/ branch. A new cvs root, cvs/pkgs > is used (cvs/extras is a symlink to this). Sanity checking here: do we need to use fresh checked out copies from CVS, or can we keep on using our existing sandboxes? -Chris -- Chris Weyl Ex astris, scientia From roland at redhat.com Thu May 3 19:28:52 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 3 May 2007 12:28:52 -0700 (PDT) Subject: Core / Extras -> Fedora In-Reply-To: Chris Weyl's message of Thursday, 3 May 2007 12:24:35 -0700 <7dd7ab490705031224j6d1b68bdq1d974c11dd2b44bf@mail.gmail.com> Message-ID: <20070503192852.A676F1801A3@magilla.sf.frob.com> Existing extras checkouts work fine. If you want to "upgrade" them: echo :ext:user at cvs.fedora.redhat.com:/cvs/pkgs > root find extras -maxdepth 4 -wholename '*/CVS/Root' -exec cp -f root {} \; For old core checkouts life is more complicated, because only devel/ moved. I used: find dist -maxdepth 4 -wholename '*/devel/CVS/Root' -exec cp root {} \; But now my dist/foo checkouts are somewhat confusing. Probably I'll rename those dirs under extras, but noone did anything like a helpful migration plan for developers *beforehand*. From jwilson at redhat.com Thu May 3 19:36:45 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 03 May 2007 15:36:45 -0400 Subject: Core / Extras -> Fedora In-Reply-To: <7dd7ab490705031224j6d1b68bdq1d974c11dd2b44bf@mail.gmail.com> References: <200705022132.32870.jkeating@redhat.com> <200705031421.06357.jkeating@redhat.com> <7dd7ab490705031224j6d1b68bdq1d974c11dd2b44bf@mail.gmail.com> Message-ID: <463A39CD.3050508@redhat.com> Chris Weyl wrote: > On 5/3/07, Jesse Keating wrote: >> A status report. >> >> CVS contents have been merged for the devel/ branch. A new cvs root, >> cvs/pkgs >> is used (cvs/extras is a symlink to this). > > Sanity checking here: do we need to use fresh checked out copies from > CVS, or can we keep on using our existing sandboxes? For what were Extras packages, your existing stuff should continue to Just Work. For what were Core packages, some fiddling is needed (alter your cvs root within existing checkout, or just do a clean checkout). -- Jarod Wilson jwilson at redhat.com From bpepple at fedoraproject.org Thu May 3 21:10:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 03 May 2007 17:10:30 -0400 Subject: FESCo Meeting Summary for 2007-05-03 Message-ID: <1178226630.5828.12.camel@lincoln> = 2007 May 03 FESCo Meeting = === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Rex Dieter (rdieter) * Jesse Keating (f13) * Christian Iseli (c4chris) * Toshio Kuratomi (abadger1999) * Jeremy Katz (jeremy) * Bill Nottingham (notting) * Warren Togami (warren) * Kevin Fenzi (nirik) * Tom Callaway (spot) === Absent === * Josh Boyer (jwb) * Dennis Gilmore (dgilmore) == Summary == === CVS Branching === * CVS will be branched next week (2007-05-10). * After F7 is released, FESCo will address when future branchings should occur. === Test release after merge? === * FESCo discussed whether to have a test release after the merge is finished. It was decided that the daily spins being currently generated is sufficient. === Bugzilla changes due to merge === * Plan is to add all Extras components to Fedora Core, and then rename that component 'Fedora'. Then all Extras bugs will be moved to 'Fedora' in the database. === Meeting Minutes IRC bot === * Since this is a fairly low priority item, we'll look into this after F7 has been released. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070503 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Thu May 3 21:19:21 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 03 May 2007 23:19:21 +0200 Subject: Core / Extras -> Fedora In-Reply-To: <20070503192852.A676F1801A3@magilla.sf.frob.com> References: <20070503192852.A676F1801A3@magilla.sf.frob.com> Message-ID: <463A51D9.6000807@poolshark.org> Roland McGrath wrote: > Existing extras checkouts work fine. If you want to "upgrade" them: > > echo :ext:user at cvs.fedora.redhat.com:/cvs/pkgs > root > find extras -maxdepth 4 -wholename '*/CVS/Root' -exec cp -f root {} \; or use regexxer :-) From poelstra at redhat.com Thu May 3 21:55:14 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 03 May 2007 14:55:14 -0700 Subject: 2007-apr-30 Release Meeting Recap Message-ID: <463A5A42.7030300@redhat.com> http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-apr-30 == Reports on F7-Test 4 == * wwoods * rawhide is currently uninstallable * concerned about mkinitrd issues - there's a lot of "can't find /dev/root" reports out there * we're gonna need some docs on device labeling, since that's a very common install failure--cc jeremy on bugs * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234938 is a failed upgrade * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236743 those are anaconda, not mkinitrd * warren * resume regressed on my thinkpad :/ but that's something I'll track down and report in a bit * qemu is not working; jeremy believes he has a fix == Merge == * Decisions * Buildsys freeze on 01-MAY-07 * Start merge on 02-MAY-07 at 12:00 EDT until completed * move final devel freeze out one week * hold current GA date of 24-MAY-07 * http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge * http://fedoraproject.org/wiki/Infrastructure/CoreExtrasCVSMerge should be pretty detailed for the cvs side of the merge * f13 * I'm continuing to keep koji updated with the Core builds * dgilmore had something cooking to import Extras builds, we should probably start doing that regularly ASAP * the question marks are, a owners.list <-> koji sync tool * need the creation of a needsign type que for up to the hour build access and a way to do package signing. * how did we wind up with a 1~ week window between Test4 release and Final freeze? * moving ahead with hardware we have; new hardware is on the way * it could take a while to import the Extras stuff becasue I'll have to write something up to do the imports since Extras isn't in a koji like builddb right now * we will let people do post-merge rebuilds to pick up new builddeps * there is also a ton of dist-fc7 builds that haven't been requested for f7-final tagging. * we will disable the build system by removing the dist-fc7 build target from brew. * koji will first be used for f7 only and after the dust settles we'll bring over fc6-updates * will document the freeze process * will send mail on freeze * jeremy * people will still have to request their post-merge rebuilds be tagged for final * mmcgrath * will try to clean up the filesystem on cvs too before next wed. It's kind of a mess on that box right now. * new PPC arriving late this week or beginning of next * notting * when can we reasonably have a deadline? * will create the hook for the owners.list <-> koji sync * poelcat * suggested detailed schedule with completion dates for merge * others thought a list of tasks is fine because everything has to be done on Wednesday From tibbs at math.uh.edu Thu May 3 23:29:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 May 2007 18:29:38 -0500 Subject: Proposal ocaml guidelines In-Reply-To: <463A36C6.5000108@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> If you can let me know where and when the FPC meeting happens, HdG> then I can see if I can attend (times in CET please, as a HdG> european I'm not used to doing timezone calculations) #fedora-meeting, 1700UTC. I believe that's 1900CET, according to timezoneconverter.com. - J< From tibbs at math.uh.edu Fri May 4 00:05:44 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 May 2007 19:05:44 -0500 Subject: Proposal ocaml guidelines In-Reply-To: References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> #fedora-meeting, 1700UTC. I believe that's 1900CET, according to JLT> timezoneconverter.com. Doh, it's on Tuesdays. - J< From a.badger at gmail.com Fri May 4 00:40:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 03 May 2007 17:40:37 -0700 Subject: Proposal ocaml guidelines In-Reply-To: <463A36C6.5000108@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> Message-ID: <1178239237.31937.7.camel@localhost.localdomain> On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote: > Okay, > > The proposal I mailed to the list yesterday is now available here: > http://fedoraproject.org/wiki/PackagingDrafts/OCaml > Thanks Hans! I have a question about bytecode/native code. Should the guidelines specify that module packages build both bytecode and native code? As a precedent, a java library will install a native code version to %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar. I also wonder if we want to specify that ocaml programs should be compiled to native code. > If you can let me know where and when the FPC meeting happens, then I can see > if I can attend (times in CET please, as a european I'm not used to doing > timezone calculations) > I believe that tibbs answered this. Thanks, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Fri May 4 05:14:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 May 2007 07:14:14 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <1178239237.31937.7.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <1178239237.31937.7.camel@localhost.localdomain> Message-ID: <463AC126.2040603@hhs.nl> Toshio Kuratomi wrote: > On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote: >> Okay, >> >> The proposal I mailed to the list yesterday is now available here: >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >> > Thanks Hans! Please keep in mind I'm not an ocaml expert, I just did some reading on it as I needed to know something about it todo reviews. > I have a question about bytecode/native code. Should the guidelines > specify that module packages build both bytecode and native code? As a > precedent, a java library will install a native code version to > %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar. > Thats not how ocaml handles things. Ocaml code gets compiled to bytecode objects, native<->ocaml glue code gets compiled to native objects. Then when compiling an application / program, you can compile it in 2 ways: 1) to a bytecode program which will require the ocaml runtime and the .so versions of any native code from used modules/libs. All bytecode objects from used modules will get staticly liked in. This reminds me, since ocaml will dlopen the .so files with native code of used modules, an application compiled this way should have Requires: for all used modules of which native parts are used. 2) To native code, in this case the bytecode parts of used modules get converted to native code and any native objects which are part of modules get staticly linked in, resulting in a native binary which is independent of any ocaml modules (but which will still depend upon any be dynamicly linked against any normal native libraries used by modules, like libjpeg) > I also wonder if we want to specify that ocaml programs should be > compiled to native code. > According to Debian's guidelines this has both advantages and disadvantages, so its probably best to use upstream's default behaviour. Also worth noticing is that native compilation is not available on all platforms. Luckily it is available for all platforms which are part of Fedora. Regards, Hans p.s. What do you think about the Naming part of the proposal? I'm currently doing an ocaml related review which mainly needs a "decision" on the naming part of the proposal. I think this is not very controversial, so if atleast an agreement could be reached on this, then said review can move forward. From dev at nigelj.com Fri May 4 05:31:11 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 4 May 2007 17:31:11 +1200 (NZST) Subject: Proposal ocaml guidelines In-Reply-To: <463AC126.2040603@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <1178239237.31937.7.camel@localhost.localdomain> <463AC126.2040603@hhs.nl> Message-ID: <50393.202.154.145.104.1178256671.squirrel@webmail.nigelj.com> > Toshio Kuratomi wrote: >> On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote: >>> Okay, >>> >>> The proposal I mailed to the list yesterday is now available here: >>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >>> >> Thanks Hans! > > Please keep in mind I'm not an ocaml expert, I just did some reading on it > as I needed to know something about it todo reviews. > >> I have a question about bytecode/native code. Should the guidelines >> specify that module packages build both bytecode and native code? As a >> precedent, a java library will install a native code version to >> %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar. >> > > Thats not how ocaml handles things. Ocaml code gets compiled to bytecode > objects, native<->ocaml glue code gets compiled to native objects. > > Then when compiling an application / program, you can compile it in 2 > ways: > 1) to a bytecode program which will require the ocaml runtime and the .so > versions of any native code from used modules/libs. All bytecode > objects > from used modules will get staticly liked in. > > This reminds me, since ocaml will dlopen the .so files with native > code of > used modules, an application compiled this way should have Requires: > for all used modules of which native parts are used. > > 2) To native code, in this case the bytecode parts of used modules get > converted to native code and any native objects which are part of > modules > get staticly linked in, resulting in a native binary which is > independent of > any ocaml modules (but which will still depend upon any be dynamicly > linked > against any normal native libraries used by modules, like libjpeg) > > >> I also wonder if we want to specify that ocaml programs should be >> compiled to native code. >> > > According to Debian's guidelines this has both advantages and > disadvantages, so > its probably best to use upstream's default behaviour. > > Also worth noticing is that native compilation is not available on all > platforms. Luckily it is available for all platforms which are part of > Fedora. > > Regards, > > Hans > > > p.s. > > What do you think about the Naming part of the proposal? I'm currently > doing an > ocaml related review which mainly needs a "decision" on the naming part of > the > proposal. I think this is not very controversial, so if atleast an > agreement > could be reached on this, then said review can move forward. I'm actually happy with it, I'm going to change the name in the review shortly. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dwmw2 at infradead.org Fri May 4 09:08:28 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 May 2007 10:08:28 +0100 Subject: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8 In-Reply-To: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> Message-ID: <1178269708.11120.259.camel@pmac.infradead.org> On Mon, 2007-04-09 at 01:34 -0400, Remi Collet wrote: > +# This requires dmidecode (at run time) which is only available on x86. > +ExcludeArch: ppc ppc64 s390 s390x ia64 To use ExcludeArch, you MUST have a bug filed an on the FE-ExcludeArch-ppc tracker (and FE-ExcludeArch-ppc64 now too, I suppose). But the correct fix in this case is to make the use of dmidecode optional, and perhaps to look elsewhere for the information you wanted from it. Just disabling an architecture is the packagemonkey approach. Fedora needs _maintainers_ not packagemonkeys. Once the bug is filed, include the information about what you were looking for in the dmidecode output. I'll see the bug when it's added to the tracker and I'll tell you where to find information in /proc/device-tree, if possible. -- dwmw2 From rjones at redhat.com Fri May 4 09:44:09 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 04 May 2007 10:44:09 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <463A36C6.5000108@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> Message-ID: <463B0069.5090100@redhat.com> Hans de Goede wrote: > The proposal I mailed to the list yesterday is now available here: > http://fedoraproject.org/wiki/PackagingDrafts/OCaml What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage. Debian even include *.ml files in certain situations: $ dpkg -S /usr/lib/ocaml/3.08.3/list.ml ocaml-nox: /usr/lib/ocaml/3.08.3/list.ml Along the same lines I notice that there is no version information in the path. Early on Debian used the major.minor format (eg. /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & *.cmx format can change incompatibly on every release (even bugfixes) so they now put the full version number in the path. See: http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Fri May 4 09:52:03 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 04 May 2007 10:52:03 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <463B0069.5090100@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> Message-ID: <463B0243.5020102@redhat.com> Richard W.M. Jones wrote: > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html Reading further into that thread reminds me of how Fedora OCaml _shouldn't_ emulate Debian, w.r.t. the build process: http://lists.debian.org/debian-ocaml-maint/2005/01/msg00061.html (I know zero about the Fedora build process) Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From dev at nigelj.com Fri May 4 09:48:42 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 04 May 2007 21:48:42 +1200 Subject: Proposal ocaml guidelines In-Reply-To: <463B0069.5090100@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> Message-ID: <463B017A.8020604@nigelj.com> Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote: > Hans de Goede wrote: >> The proposal I mailed to the list yesterday is now available here: >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > > What's the thinking behind removing *.mli by default? Even in packages > which are well documented, the *.mli files are the definitive reference > for programmers. I think they should always be in the -devel subpackage. I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files. > > Debian even include *.ml files in certain situations: > > $ dpkg -S /usr/lib/ocaml/3.08.3/list.ml > ocaml-nox: /usr/lib/ocaml/3.08.3/list.ml It seems to be a case of when they are provided in make install, include them. > > Along the same lines I notice that there is no version information in > the path. Early on Debian used the major.minor format (eg. > /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & > *.cmx format can change incompatibly on every release (even bugfixes) so > they now put the full version number in the path. See: Good point, this needs to be looked at by the ocaml maintainer (CC'd) > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html > > Rich. > N.J. From rjones at redhat.com Fri May 4 09:58:02 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 04 May 2007 10:58:02 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <463B017A.8020604@nigelj.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B017A.8020604@nigelj.com> Message-ID: <463B03AA.30809@redhat.com> Nigel Jones wrote: > Sorry to come into the discussion a bit later than expected. > Richard W.M. Jones wrote: >> Hans de Goede wrote: >>> The proposal I mailed to the list yesterday is now available here: >>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >> What's the thinking behind removing *.mli by default? Even in packages >> which are well documented, the *.mli files are the definitive reference >> for programmers. I think they should always be in the -devel subpackage. > I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated > html references, which seems to be pretty much the same as the > individual mli files. But I wanna use 'less'! Seriously, I don't want to fire up a browser just to check an interface. Even the text mode browsers have serious UI problems compared to 'less /usr/lib/ocaml/3.08.3/list.mli'. Is there any reason why *.mli files can't be included in a -devel package? I'm not talking about the main library package where it would add bloat, but in a package which would only need to be installed by developers. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From j.w.r.degoede at hhs.nl Fri May 4 10:03:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 May 2007 12:03:51 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <463B0069.5090100@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> Message-ID: <463B0507.3010408@hhs.nl> Richard W.M. Jones wrote: > Hans de Goede wrote: >> The proposal I mailed to the list yesterday is now available here: >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > > What's the thinking behind removing *.mli by default? Even in packages > which are well documented, the *.mli files are the definitive reference > for programmers. I think they should always be in the -devel subpackage. > This is taken from then PLD guidelines, I'm open to changing this. They advice to put the mli files (gzipped) in %doc when necessary, but to not ship them when there are other docs. > Along the same lines I notice that there is no version information in > the path. Early on Debian used the major.minor format (eg. > /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & > *.cmx format can change incompatibly on every release (even bugfixes) so > they now put the full version number in the path. See: > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html > Yes, I think that adding version info to the ocaml lib path would be a good idea, however the already existing packages don't do this, hence I didn't put it in my proposal. This would be something todo at the beginning of the F8 cycle, if we agree that we want to change this. Regards, Hans From tmraz at redhat.com Fri May 4 10:09:02 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 04 May 2007 12:09:02 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <463B03AA.30809@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B017A.8020604@nigelj.com> <463B03AA.30809@redhat.com> Message-ID: <1178273342.3151.2.camel@perun.kabelta.loc> On Fri, 2007-05-04 at 10:58 +0100, Richard W.M. Jones wrote: > Nigel Jones wrote: > > Sorry to come into the discussion a bit later than expected. > > Richard W.M. Jones wrote: > >> Hans de Goede wrote: > >>> The proposal I mailed to the list yesterday is now available here: > >>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > >> What's the thinking behind removing *.mli by default? Even in packages > >> which are well documented, the *.mli files are the definitive reference > >> for programmers. I think they should always be in the -devel subpackage. > > I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated > > html references, which seems to be pretty much the same as the > > individual mli files. > > But I wanna use 'less'! > > Seriously, I don't want to fire up a browser just to check an interface. > Even the text mode browsers have serious UI problems compared to > 'less /usr/lib/ocaml/3.08.3/list.mli'. > > Is there any reason why *.mli files can't be included in a -devel > package? I'm not talking about the main library package where it would > add bloat, but in a package which would only need to be installed by > developers. +1 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From j.w.r.degoede at hhs.nl Fri May 4 10:06:43 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 May 2007 12:06:43 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <463B03AA.30809@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B017A.8020604@nigelj.com> <463B03AA.30809@redhat.com> Message-ID: <463B05B3.5090506@hhs.nl> Richard W.M. Jones wrote: > Nigel Jones wrote: >> Sorry to come into the discussion a bit later than expected. >> Richard W.M. Jones wrote: >>> Hans de Goede wrote: >>>> The proposal I mailed to the list yesterday is now available here: >>>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >>> What's the thinking behind removing *.mli by default? Even in packages >>> which are well documented, the *.mli files are the definitive reference >>> for programmers. I think they should always be in the -devel >>> subpackage. >> I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated >> html references, which seems to be pretty much the same as the >> individual mli files. > > But I wanna use 'less'! > > Seriously, I don't want to fire up a browser just to check an interface. > Even the text mode browsers have serious UI problems compared to > 'less /usr/lib/ocaml/3.08.3/list.mli'. > > Is there any reason why *.mli files can't be included in a -devel > package? I'm not talking about the main library package where it would > add bloat, but in a package which would only need to be installed by > developers. > Other then size, no. So if there is a use for them, and appearantly there is, I guess the not shipping of them should be removed from the guidelines (thats why they are a draft :) Regards, Hans From fedora at leemhuis.info Fri May 4 10:24:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 12:24:19 +0200 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: <1178269708.11120.259.camel@pmac.infradead.org> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> Message-ID: <463B09D3.7000604@leemhuis.info> On 04.05.2007 11:08, David Woodhouse wrote: > On Mon, 2007-04-09 at 01:34 -0400, Remi Collet wrote: >> +# This requires dmidecode (at run time) which is only available on x86. >> +ExcludeArch: ppc ppc64 s390 s390x ia64 > To use ExcludeArch, you MUST have a bug filed an on the > FE-ExcludeArch-ppc tracker (and FE-ExcludeArch-ppc64 now too, I > suppose). +1 > But the correct fix in this case is to make the use of dmidecode > optional, and perhaps to look elsewhere for the information you wanted > from it. Just disabling an architecture is the packagemonkey approach. > Fedora needs _maintainers_ not packagemonkeys. My 2 cent: Fedora needs both maintainers and packagemonkeys (as you call them). Packagemonkeys (and in my interpretation of the term) can do lots of good work IMHO: - package apps - update them now and then - making sure they work well - look at bugs - fix the trivial bugs - forward bugs upstream E.g. they can do relative easy kind of maintenance work without even know a programming language. Thus they are helpful for the project as a whole and can do some "easy tasks" while real "maintainers" with more skills can concentrate on the stuff that harder to fix or realize. In the end we might have an overall better distro with lots of packages. And with a bit of luck a lot of packagemonkeys become real maintainers over time. CU thl P.S.:Packagemonkey sounds bad and we should not use the term IMHO. Anyway, just in case anyone wonders: I consider myself as a package monkey, as I never found time to learn programming properly :-/ From jonathan.underwood at gmail.com Fri May 4 10:40:34 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 May 2007 11:40:34 +0100 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: <463B09D3.7000604@leemhuis.info> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> Message-ID: <645d17210705040340u316ad541raa15ee35300bd62b@mail.gmail.com> > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. Totally agreed, everything about that term is negative, and it does nothing but convey contempt for people's valued contributions. If I were just looking through the mailing lists archives and considering contributing to Fedora in some way, and saw contributers referred to as "package monkeys", I wouldn't hang around long. I find the word, and the attitude it conveys quite offensive. From dwmw2 at infradead.org Fri May 4 10:52:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 May 2007 11:52:20 +0100 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: <463B09D3.7000604@leemhuis.info> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> Message-ID: <1178275940.11120.264.camel@pmac.infradead.org> On Fri, 2007-05-04 at 12:24 +0200, Thorsten Leemhuis wrote: > My 2 cent: Fedora needs both maintainers and packagemonkeys (as you call > them). > > Packagemonkeys (and in my interpretation of the term) can do lots of > good work IMHO: > > - package apps > - update them now and then > - making sure they work well > - look at bugs > - fix the trivial bugs > - forward bugs upstream > > E.g. they can do relative easy kind of maintenance work without even > know a programming language. Thus they are helpful for the project as a > whole and can do some "easy tasks" while real "maintainers" with more > skills can concentrate on the stuff that harder to fix or realize. > > In the end we might have an overall better distro with lots of packages. > And with a bit of luck a lot of packagemonkeys become real maintainers > over time. You could be right. But they _MUST_ file the bugs seeking assistance where required. > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. It's a term which is precisely suited to the task. Nobody seemed to offer a better one last time I asked. I like monkeys. > Anyway, just in case anyone wonders: I consider myself as a package > monkey, as I never found time to learn programming properly :-/ I also consider myself a package monkey, for certain packages. I'd like to get rid of bluez-*, for example, since they seem to be more and more based on dbus, about which I am entirely clueless. -- dwmw2 From dev at nigelj.com Fri May 4 11:07:12 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 04 May 2007 23:07:12 +1200 Subject: Proposal ocaml guidelines In-Reply-To: <463B03AA.30809@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B017A.8020604@nigelj.com> <463B03AA.30809@redhat.com> Message-ID: <463B13E0.5080402@nigelj.com> Richard W.M. Jones wrote: > Nigel Jones wrote: >> Sorry to come into the discussion a bit later than expected. >> Richard W.M. Jones wrote: >>> Hans de Goede wrote: >>>> The proposal I mailed to the list yesterday is now available here: >>>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml >>> What's the thinking behind removing *.mli by default? Even in packages >>> which are well documented, the *.mli files are the definitive reference >>> for programmers. I think they should always be in the -devel >>> subpackage. >> I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated >> html references, which seems to be pretty much the same as the >> individual mli files. > > But I wanna use 'less'! > > Seriously, I don't want to fire up a browser just to check an interface. > Even the text mode browsers have serious UI problems compared to > 'less /usr/lib/ocaml/3.08.3/list.mli'. > > Is there any reason why *.mli files can't be included in a -devel > package? I'm not talking about the main library package where it would > add bloat, but in a package which would only need to be installed by > developers. Technically, if we are going to package developer documentation, they should be in a noarch -doc package (i.e. ocaml-camlimages-doc). What I'd suggest is: Packager splits out .mli files from build, compresses and gunzips them, and creates a spec file, something to the tune of: ---- [njones at ip-96 SPECS]$ cat ocaml-camlimages-doc.spec Name: ocaml-camlimages-doc Version: 2.2.0 Release: 1%{?dist} Summary: Developer Documentation for ocaml-camlimages Group: Documentation License: LGPL URL: - Source0: ocaml-camlimages-doc-2.2.0.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch BuildRequires: texinfo ocaml ocaml-ocamldoc ocaml-camlimages-devel %description Dev Docu.... %prep %setup -q %build ocamldoc.opt -texi -I /usr/lib/ocaml/lablgtk2/ \ -I /usr/lib/ocaml/camlimages/ -t "camlimages" \ -info-section "Ocaml Libraries" -intf *.* makeinfo ocamldoc.texi gzip camlimages.info %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/lib/ocaml/camlimages mkdir -p $RPM_BUILD_ROOT/usr/share/info cp -p *.mli $RPM_BUILD_ROOT/usr/lib/ocaml/camlimages/ cp -p *.info.gz $RPM_BUILD_ROOT/usr/share/info %clean rm -rf $RPM_BUILD_ROOT %post /sbin/install-info \ --entry "* camlimages: (camlimages). OCaml image processing library" \ --section "Ocaml Libraries" \ %{_infodir}/camlimages.info \ %{_infodir}/dir 2>/dev/null || : %preun if [ $1 -eq 0 ]; then /sbin/install-info --delete %{_infodir}/camlimages.info %{_infodir}/dir 2>/dev/null || : fi %files %defattr(-,root,root,-) /usr/lib/ocaml/camlimages/*.mli %{_infodir}/* %changelog ---- This satisfies the answer of "I want my mli files" and "I want something a bit more meaty". I agree that html documentation wasn't the best choice, but this could work. N.J. From dev at nigelj.com Fri May 4 11:08:14 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 04 May 2007 23:08:14 +1200 Subject: Proposal ocaml guidelines In-Reply-To: <1178208140.5401.3.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> Message-ID: <463B141E.8030007@nigelj.com> G?rard Milmeister wrote: > On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote: >> I got looking into this because of these review requests: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 >> >> And I've come to the conclusion that we need some kinda ocaml >> packaging guidelines. >> >> Interesting with regards to this are: >> http://docs.pld-linux.org/ocaml.html >> http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt > > Maybe you could start an add something to the fedoraproject wiki, for > example a Ocaml SIG. There has also been some interest in this by > Richard Jones . I think an SIG would be useful, not only to develop standards, but also to improve the general quality of ocaml based packages in Fedora. It'd also be useful to coordinate changes like emulating w.r.t policy if needed (as Richard points out), and deciding on items like how documentation should be presented. N.J. From gemi at bluewin.ch Fri May 4 11:24:18 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 04 May 2007 13:24:18 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <463B0507.3010408@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B0507.3010408@hhs.nl> Message-ID: <1178277858.14509.1.camel@localhost.localdomain> On Fri, 2007-05-04 at 12:03 +0200, Hans de Goede wrote: > Richard W.M. Jones wrote: > > Hans de Goede wrote: > >> The proposal I mailed to the list yesterday is now available here: > >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > > > > What's the thinking behind removing *.mli by default? Even in packages > > which are well documented, the *.mli files are the definitive reference > > for programmers. I think they should always be in the -devel subpackage. > > > > This is taken from then PLD guidelines, I'm open to changing this. They advice > to put the mli files (gzipped) in %doc when necessary, but to not ship them > when there are other docs. > > > Along the same lines I notice that there is no version information in > > the path. Early on Debian used the major.minor format (eg. > > /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & > > *.cmx format can change incompatibly on every release (even bugfixes) so > > they now put the full version number in the path. See: > > > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html > > > > Yes, I think that adding version info to the ocaml lib path would be a good > idea, however the already existing packages don't do this, hence I didn't put > it in my proposal. This would be something todo at the beginning of the F8 > cycle, if we agree that we want to change this. Maybe we should open a bug report against ocaml, so we can take the discussion off this list. Some changes have to be done to that package anyways. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From j.w.r.degoede at hhs.nl Fri May 4 11:36:17 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Fri, 04 May 2007 13:36:17 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <1178277858.14509.1.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B0507.3010408@hhs.nl> <1178277858.14509.1.camel@localhost.localdomain> Message-ID: On Fri, 04 May 2007 13:24:18 +0200 G?rard Milmeister wrote: > On Fri, 2007-05-04 at 12:03 +0200, Hans de Goede wrote: > > Richard W.M. Jones wrote: > > > Hans de Goede wrote: > > >> The proposal I mailed to the list yesterday is now > available here: > > >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > > > > > > What's the thinking behind removing *.mli by default? > Even in packages > > > which are well documented, the *.mli files are the > definitive reference > > > for programmers. I think they should always be in > the -devel subpackage. > > > > > > > This is taken from then PLD guidelines, I'm open to > changing this. They advice > > to put the mli files (gzipped) in %doc when necessary, > but to not ship them > > when there are other docs. > > > > > Along the same lines I notice that there is no > version information in > > > the path. Early on Debian used the major.minor > format (eg. > > > /usr/lib/ocaml/3.06/) but they found out the hard way > that the *.cmo & > > > *.cmx format can change incompatibly on every release > (even bugfixes) so > > > they now put the full version number in the path. > See: > > > > > > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html > > > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html > > > > http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html > > > > > > > Yes, I think that adding version info to the ocaml lib > path would be a good > > idea, however the already existing packages don't do > this, hence I didn't put > > it in my proposal. This would be something todo at the > beginning of the F8 > > cycle, if we agree that we want to change this. > Maybe we should open a bug report against ocaml, so we > can take the > discussion off this list. Some changes have to be done to > that package > anyways. Thats sounds like a good plan, when you do, please send a link as reply in this thread, so that interested people can add themselves to the CC, Regards, Hans From j.w.r.degoede at hhs.nl Fri May 4 11:40:17 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Fri, 04 May 2007 13:40:17 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <463B13E0.5080402@nigelj.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <463B0069.5090100@redhat.com> <463B017A.8020604@nigelj.com> <463B03AA.30809@redhat.com> <463B13E0.5080402@nigelj.com> Message-ID: On Fri, 04 May 2007 23:07:12 +1200 Nigel Jones wrote: > Richard W.M. Jones wrote: > > Nigel Jones wrote: > >> Sorry to come into the discussion a bit later than > expected. > >> Richard W.M. Jones wrote: > >>> Hans de Goede wrote: > >>>> The proposal I mailed to the list yesterday is now > available here: > >>>> http://fedoraproject.org/wiki/PackagingDrafts/OCaml > >>> What's the thinking behind removing *.mli by default? > Even in packages > >>> which are well documented, the *.mli files are the > definitive reference > >>> for programmers. I think they should always be in > the -devel > >>> subpackage. > >> I replaced it in ocaml-SDL and ocaml-camlimages with > ocamldoc generated > >> html references, which seems to be pretty much the > same as the > >> individual mli files. > > > > But I wanna use 'less'! > > > > Seriously, I don't want to fire up a browser just to > check an interface. > > Even the text mode browsers have serious UI problems > compared to > > 'less /usr/lib/ocaml/3.08.3/list.mli'. > > > > Is there any reason why *.mli files can't be included > in a -devel > > package? I'm not talking about the main library > package where it would > > add bloat, but in a package which would only need to be > installed by > > developers. > Technically, if we are going to package developer > documentation, they > should be in a noarch -doc package (i.e. > ocaml-camlimages-doc). > > What I'd suggest is: > Packager splits out .mli files from build, compresses and > gunzips them, > and creates a spec file, something to the tune of: > No please, I don't know what the size of the htmldocs is, but assuming there small lets just have the htmldocs and the *.mli files in the main package, maybe in a seperate subpackage. If the size of the htmldocs is so large that the additional mirror churn for updates to the main package are woth seperating, then only the htmldocs should be packaged seperately. Using parts of the build output from one package and manually copying them that as source for another is just plain wrong. And since we are not talking 100Mb data files here, lets not do this! Regards, Hans From dennis at ausil.us Fri May 4 12:05:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 4 May 2007 07:05:00 -0500 Subject: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8 In-Reply-To: <1178269708.11120.259.camel@pmac.infradead.org> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> Message-ID: <200705040705.00587.dennis@ausil.us> Once upon a time Friday 04 May 2007, David Woodhouse wrote: > On Mon, 2007-04-09 at 01:34 -0400, Remi Collet wrote: > > +# This requires dmidecode (at run time) which is only available on x86. > > +ExcludeArch: ppc ppc64 s390 s390x ia64 a better solution for the case where someting is x86 only is to use ExclusiveArch %{ix86} x86_64 This then will work for people that build extras for non supported archs like sparc :) > To use ExcludeArch, you MUST have a bug filed an on the > FE-ExcludeArch-ppc tracker (and FE-ExcludeArch-ppc64 now too, I > suppose). > > But the correct fix in this case is to make the use of dmidecode > optional, and perhaps to look elsewhere for the information you wanted > from it. Just disabling an architecture is the packagemonkey approach. > Fedora needs _maintainers_ not packagemonkeys. support should be added for getting the info from OF. there is a osx version of the client written in php Dennis From atkac at redhat.com Fri May 4 12:20:10 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 04 May 2007 14:20:10 +0200 Subject: Latest nash/kernel problems Message-ID: <463B24FA.4000808@redhat.com> Hi, I've updated from fedora 6 to rawhide right now. During update glibc uninstall script fails with %trigger(redhat-lsb-3.1-13) scriptlet failed, signal 2 so I must terminate update process. When I try reboot rawhide's kernel can't start because nash can't find libm.so.6 but fc6 kernel boots correctly. I've tried reinstall nash, mkinitrd and kernel but problem still exists. Any hints? Regards, Adam From rjones at redhat.com Fri May 4 12:50:41 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 04 May 2007 13:50:41 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <1178239237.31937.7.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463A272C.8000201@hhs.nl> <1178217280.12451.31.camel@localhost.localdomain> <463A36C6.5000108@hhs.nl> <1178239237.31937.7.camel@localhost.localdomain> Message-ID: <463B2C21.8060800@redhat.com> Toshio Kuratomi wrote: > I also wonder if we want to specify that ocaml programs should be > compiled to native code. David Allsopp reminded me (in a private email) that byte code and native code programs also differ in functionality. For example, Dynlink is not available to native code - which is the reason why mod_caml is always compiled to bytecode, even though in theory it could be compiled to native code on platforms which support that. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From gemi at bluewin.ch Fri May 4 13:12:50 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 04 May 2007 15:12:50 +0200 Subject: Proposal ocaml guidelines (bugzilla) In-Reply-To: <463B141E.8030007@nigelj.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463B141E.8030007@nigelj.com> Message-ID: <1178284370.14509.4.camel@localhost.localdomain> I opened a bugzilla entry at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 So we can move the discussion there. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From rjones at redhat.com Fri May 4 13:25:41 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 04 May 2007 14:25:41 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <463B141E.8030007@nigelj.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <463B141E.8030007@nigelj.com> Message-ID: <463B3455.1080703@redhat.com> I created a SIG. I've no idea if I did it right. Nevertheless: http://fedoraproject.org/wiki/SIGs/OCaml Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mclasen at redhat.com Fri May 4 13:28:24 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 04 May 2007 09:28:24 -0400 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: <1178275940.11120.264.camel@pmac.infradead.org> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> Message-ID: <1178285304.3722.6.camel@localhost.localdomain> On Fri, 2007-05-04 at 11:52 +0100, David Woodhouse wrote: > > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. > > It's a term which is precisely suited to the task. Nobody seemed to > offer a better one last time I asked. > > I like monkeys. Well, this is not so much about what _you_ find offensive or not, it is about how others perceive your mutterings... From giallu at gmail.com Fri May 4 14:21:13 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 4 May 2007 16:21:13 +0200 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: <1178275940.11120.264.camel@pmac.infradead.org> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> Message-ID: On 5/4/07, David Woodhouse wrote: > > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. > > It's a term which is precisely suited to the task. Nobody seemed to > offer a better one last time I asked. I don't mind if you call me packagemonkey :) However I think "Packager" would be quite enough to convey the same meaning. From ssorce at redhat.com Fri May 4 14:44:06 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 May 2007 10:44:06 -0400 Subject: about maintainers and packagemonkeys (was: Re: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8) In-Reply-To: References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> Message-ID: <1178289846.10301.7.camel@willson> On Fri, 2007-05-04 at 16:21 +0200, Gianluca Sforna wrote: > On 5/4/07, David Woodhouse wrote: > > > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. > > > > It's a term which is precisely suited to the task. Nobody seemed to > > offer a better one last time I asked. > > I don't mind if you call me packagemonkey :) > However I think "Packager" would be quite enough to convey the same meaning. Maybe JuniorPackager :-) From andy at warmcat.com Fri May 4 14:50:04 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 04 May 2007 15:50:04 +0100 Subject: about maintainers and packagemonkeys In-Reply-To: References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> Message-ID: <463B481C.8060202@warmcat.com> Gianluca Sforna wrote: > On 5/4/07, David Woodhouse wrote: >> > P.S.:Packagemonkey sounds bad and we should not use the term IMHO. >> >> It's a term which is precisely suited to the task. Nobody seemed to >> offer a better one last time I asked. > > I don't mind if you call me packagemonkey :) > However I think "Packager" would be quite enough to convey the same > meaning. You know how they all point and go HUSSS!!! in the film "Invasion of the Bodysnatchers" http://imdb.com/title/tt0077745/ Well it's sort of like that except they turn you into Jeff Johnson. But let's face it: "packager" is more neutral. Or at least packagehuman. -Andy From jwboyer at jdub.homelinux.org Fri May 4 14:50:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 May 2007 09:50:07 -0500 Subject: about maintainers and packagemonkeys In-Reply-To: <463B481C.8060202@warmcat.com> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> <463B481C.8060202@warmcat.com> Message-ID: <1178290207.3026.170.camel@zod.rchland.ibm.com> On Fri, 2007-05-04 at 15:50 +0100, Andy Green wrote: > > Well it's sort of like that except they turn you into Jeff Johnson. It's not nice to flame people that aren't involved in the discussion in any way. Please don't do this anymore. There's no reason for it. josh From andy at warmcat.com Fri May 4 15:08:05 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 04 May 2007 16:08:05 +0100 Subject: about maintainers and packagemonkeys In-Reply-To: <1178290207.3026.170.camel@zod.rchland.ibm.com> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> <463B09D3.7000604@leemhuis.info> <1178275940.11120.264.camel@pmac.infradead.org> <463B481C.8060202@warmcat.com> <1178290207.3026.170.camel@zod.rchland.ibm.com> Message-ID: <463B4C55.90301@warmcat.com> Josh Boyer wrote: > On Fri, 2007-05-04 at 15:50 +0100, Andy Green wrote: >> Well it's sort of like that except they turn you into Jeff Johnson. > > It's not nice to flame people that aren't involved in the discussion in > any way. Please don't do this anymore. There's no reason for it. Well thanks for that Josh. Actually I quite approve of Jeff Johnson. However like Being John Malkovich http://imdb.com/title/tt0120601/ Being "Jeff Johnson" is in some part an honour bestowed by others. -Andy From wwoods at redhat.com Fri May 4 15:38:46 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 04 May 2007 11:38:46 -0400 Subject: Latest nash/kernel problems In-Reply-To: <463B24FA.4000808@redhat.com> References: <463B24FA.4000808@redhat.com> Message-ID: <1178293126.28491.127.camel@metroid.rdu.redhat.com> On Fri, 2007-05-04 at 14:20 +0200, Adam Tkac wrote: > Hi, > > I've updated from fedora 6 to rawhide right now. During update glibc > uninstall script fails with %trigger(redhat-lsb-3.1-13) scriptlet > failed, signal 2 so I must terminate update process. When I try reboot > rawhide's kernel can't start because nash can't find libm.so.6 but fc6 > kernel boots correctly. I've tried reinstall nash, mkinitrd and kernel > but problem still exists. Any hints? Were you doing a yum upgrade? You know those are unsupported, right? A quick bugzilla search for "libm" turns up: Bug 230874: kernel panic caused by a missing libm https://bugzilla.redhat.com/230874 Is it possible you were running a xen kernel when you tried the yum upgrade? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From atkac at redhat.com Fri May 4 15:52:36 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 04 May 2007 17:52:36 +0200 Subject: Latest nash/kernel problems In-Reply-To: <1178293126.28491.127.camel@metroid.rdu.redhat.com> References: <463B24FA.4000808@redhat.com> <1178293126.28491.127.camel@metroid.rdu.redhat.com> Message-ID: <463B56C4.5080702@redhat.com> Will Woods napsal(a): > > Were you doing a yum upgrade? You know those are unsupported, right? > > A quick bugzilla search for "libm" turns up: > Bug 230874: kernel panic caused by a missing libm > https://bugzilla.redhat.com/230874 > > Is it possible you were running a xen kernel when you tried the yum > upgrade? > > -w > Yeah, my problem looks like that bug. I've install packages fedora-release & fedora-release-notes from rawhide to my fc6 xen system and simple did yum update. Non-xen kernel isn't able to boot. Thanks -A- From mcepl at redhat.com Fri May 4 15:23:11 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 04 May 2007 17:23:11 +0200 Subject: 2007-apr-30 Release Meeting Recap References: <463A5A42.7030300@redhat.com> Message-ID: On 2007-05-03, 21:55 GMT, John Poelstra wrote: > * rawhide is currently uninstallable And now you are telling me! :-( ;-) Mat?j From mcepl at redhat.com Fri May 4 16:49:38 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 04 May 2007 18:49:38 +0200 Subject: Latest nash/kernel problems References: <463B24FA.4000808@redhat.com> <1178293126.28491.127.camel@metroid.rdu.redhat.com> Message-ID: On 2007-05-04, 15:38 GMT, Will Woods wrote: > Were you doing a yum upgrade? You know those are unsupported, Sorry for being bother, but could you point me to The Way how to install Rawhide into xen guest (full-virt)? Both Rawhide and FC7t4 freeze on Uncompressing Linux... and the only way I made it work was to install FC6 and do yum upgrade. However, now I have screwed up Rawhide and now way how to fix it. Any thoughts? Note, that I am not kernel developer, just bugmaster on desktop team, and I would like to use rawhide for reproducing bugs, so there is no way how Rawhide could get into dom0 for me. Thanks for any reply, Matej From alex at tvtransilvania.ro Fri May 4 16:00:31 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Fri, 04 May 2007 19:00:31 +0300 Subject: kernel 2.6.21-1.3116.fc7 possible circular locking dependency Message-ID: <463B589F.7060900@tvtransilvania.ro> Upon booting 2.6.21 kernel on my HP500 notebook I get a kind of weid info message which I've pasted below. I'm using a custom 2.6.21-1.3116 kernel [I've included a small patch in drivers/input/serio/i8042.c to get my touchpad going (BZ #230595)] and reiserfs for filesystem. I'm not experiencing any problems with my system and I definitely have no ideea what this error(?) is about. Any ideas? ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.21-1.3116ics.fc7 #1 ------------------------------------------------------- chgrp/1221 is trying to acquire lock: (&REISERFS_SB(s)->xattr_dir_sem){..--}, at: [] reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] but task is already holding lock: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&inode->i_mutex){--..}: [] __lock_acquire+0xa19/0xba4 [] lock_acquire+0x56/0x6f [] __mutex_lock_slowpath+0xf7/0x26e [] mutex_lock+0x21/0x24 [] get_xa_root+0x4a/0x10b [reiserfs] [] open_xa_dir+0x19/0xde [reiserfs] [] reiserfs_delete_xattrs+0x58/0x160 [reiserfs] [] reiserfs_delete_inode+0x5d/0xe8 [reiserfs] [] generic_delete_inode+0xa6/0x110 [] generic_drop_inode+0x12/0x130 [] iput+0x63/0x66 [] do_unlinkat+0xb6/0x123 [] sys_unlink+0x10/0x12 [] syscall_call+0x7/0xb [] 0xffffffff -> #0 (&REISERFS_SB(s)->xattr_dir_sem){..--}: [] __lock_acquire+0x8fd/0xba4 [] lock_acquire+0x56/0x6f [] down_read+0x3f/0x51 [] reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] [] reiserfs_setattr+0x115/0x258 [reiserfs] [] notify_change+0x127/0x2c8 [] chown_common+0x93/0xa6 [] sys_chown+0x34/0x46 [] syscall_call+0x7/0xb [] 0xffffffff other info that might help us debug this: 1 lock held by chgrp/1221: #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 stack backtrace: [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] print_circular_bug_tail+0x5f/0x68 [] __lock_acquire+0x8fd/0xba4 [] lock_acquire+0x56/0x6f [] down_read+0x3f/0x51 [] reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] [] reiserfs_setattr+0x115/0x258 [reiserfs] [] notify_change+0x127/0x2c8 [] chown_common+0x93/0xa6 [] sys_chown+0x34/0x46 [] syscall_call+0x7/0xb ======================= From mackay_d at bellsouth.net Fri May 4 15:16:27 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Fri, 04 May 2007 10:16:27 -0500 Subject: F7 Zope package Message-ID: <1178291788.2702.10.camel@vorpal.macdev.com> It was nice to see that zope is one of the packages available for installation in F7. Unfortunately, the package won't work on F7 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The maintainer that received the bug report suggested that I make some noise on the devel list, so here I am. The problem is that the zope version packaged for F7 won't run with python 2.5.x (nor, to my knowledge will other zope versions). The Zope corporation used to supply "binary" rpms where the python interpreter that was appropriate for the zope version was installed in the zope directory tree. They have discontinued this, but it seems like a good solution for this particular problem. Zope is an excellent platform for serving web-based apps, and is well worth having available as part of the fedora installation. Hopefully, it will be packaged properly. Dave From katzj at redhat.com Fri May 4 17:13:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 13:13:45 -0400 Subject: F7 Zope package In-Reply-To: <1178291788.2702.10.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> Message-ID: <1178298825.2785.9.camel@aglarond.local> On Fri, 2007-05-04 at 10:16 -0500, David G. Mackay wrote: > It was nice to see that zope is one of the packages available for > installation in F7. Unfortunately, the package won't work on F7 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The > maintainer that received the bug report suggested that I make some noise > on the devel list, so here I am. The problem is that the zope version > packaged for F7 won't run with python 2.5.x The right place to make noise is to the upstream Zope developers. The first python 2.5 release candidate was released nine months ago with the final release coming just after that. Shipping older versions of python ends up entailing shipping huge swaths of a runtime for more than one version causing huge amounts of overhead for developers and users. Jeremy From Fedora at FamilleCollet.com Fri May 4 17:36:46 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 04 May 2007 19:36:46 +0200 Subject: rpms/ocsinventory-client/devel ocsinventory-client.spec, 1.7, 1.8 In-Reply-To: <1178269708.11120.259.camel@pmac.infradead.org> References: <200704090534.l395YoC4002585@cvs-int.fedora.redhat.com> <1178269708.11120.259.camel@pmac.infradead.org> Message-ID: <463B6F2E.4060404@FamilleCollet.com> David Woodhouse a ?crit : > On Mon, 2007-04-09 at 01:34 -0400, Remi Collet wrote: >> +# This requires dmidecode (at run time) which is only available on x86. >> +ExcludeArch: ppc ppc64 s390 s390x ia64 > > To use ExcludeArch, you MUST have a bug filed an on the > FE-ExcludeArch-ppc tracker (and FE-ExcludeArch-ppc64 now too, I > suppose). I must apologize, i missed that. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239049 > But the correct fix in this case is to make the use of dmidecode > optional, and perhaps to look elsewhere for the information you wanted > from it. Yes, i work on this issue. I use this packages for my company and we know there is a lot work to improve it. Our need is to have a running inventory agent for all our OS, i mean Linux, Windows, Aix, Solaris, ... We are actualy working on the new "OCS Inventory NG Unix Unified Agent", fully written in perl, which should/must works on all arch. http://www.ocsinventory-ng.org/index.php?page=beta-test We are aleady using it on RHEL 2-4, Fedora 3-6, AIX 5.x, Solaris 9. Working on this new agent, i have split, from ocsinventory-agent (which will become obsolete), a sub-package ocsinventory-ipdiscover (which is still needed). That's why ocsinventory became "noarch". I waiting for the "beta" test before posting a review for this new agent, but it's already available for testing : http://remi.collet.free.fr/index.php?2007/04/11/340-ocs-inventory-ng-unix-unified-agent > Just disabling an architecture is the packagemonkey approach. Probably, if you don't know which works are in progress. > Fedora needs _maintainers_ not packagemonkeys. I'm really sad if you think i'm one. > > Once the bug is filed, include the information about what you were > looking for in the dmidecode output. I'll see the bug when it's added to > the tracker and I'll tell you where to find information > in /proc/device-tree, if possible. > Help/Test on new ocsinventory-agent is probably more useful. Regards From mschwendt.tmp0701.nospam at arcor.de Fri May 4 17:40:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 4 May 2007 19:40:15 +0200 Subject: F7 Zope package In-Reply-To: <1178291788.2702.10.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> Message-ID: <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> On Fri, 04 May 2007 10:16:27 -0500, David G. Mackay wrote: > It was nice to see that zope is one of the packages available for > installation in F7. Unfortunately, the package won't work on F7 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The > maintainer that received the bug report suggested that I make some noise > on the devel list, so here I am. The problem is that the zope version > packaged for F7 won't run with python 2.5.x (nor, to my knowledge will > other zope versions). There is no zope and no plone for Fedora 7. We've removed the rpms from the development repository some time ago on the package owner's request. You refer to the old builds for Fedora 6, which have continued to live in the development repo for some time. From fedora at leemhuis.info Fri May 4 17:48:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 19:48:33 +0200 Subject: F7 Zope package In-Reply-To: <1178298825.2785.9.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> Message-ID: <463B71F1.4040300@leemhuis.info> Jeremy Katz schrieb: > On Fri, 2007-05-04 at 10:16 -0500, David G. Mackay wrote: >> It was nice to see that zope is one of the packages available for >> installation in F7. Unfortunately, the package won't work on F7 >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The >> maintainer that received the bug report suggested that I make some noise >> on the devel list, so here I am. The problem is that the zope version >> packaged for F7 won't run with python 2.5.x > > The right place to make noise is to the upstream Zope developers. The > first python 2.5 release candidate was released nine months ago with the > final release coming just after that. > > Shipping older versions of python ends up entailing shipping huge swaths > of a runtime for more than one version causing huge amounts of overhead > for developers and users. I agree. Nevertheless: We ship compatibility packages for other packages/corner cases as well. Why not for Zope, too? Yeah, other packages might want to try to get around upgrading do python 2.5 then as well, but we could create some kind of "Fedora packages only are allowed to depend on this compat package if they it was permitted by FESCo". Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 just looks so bad to out the outside and created problems for out users. I'd really would like to avoid that. Further: Our beahaviour IMHO will only result in finger pointing like "Fedora should just ship python 2.4 for zope; that's technically possible and no big deal" from one side and "zope should make sure their stuff works on latest python" from the other side. That doesn't help to get the problem solved and users are left out in the cold. CU thl From hughsient at gmail.com Fri May 4 17:57:46 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 04 May 2007 18:57:46 +0100 Subject: F7 Zope package In-Reply-To: <463B71F1.4040300@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> Message-ID: <1178301466.7630.22.camel@hughsie-laptop> On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: > Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 > just looks so bad to out the outside and created problems for out > users. I'd really would like to avoid that. If a vendor kept patching a driver for kernel 2.4 but refused to port it to kernel 2.6, would we ship a 2.4 kernel just for that one driver? Technically possible but a really bad plan. Just my 2p. Richard. From fedora at leemhuis.info Fri May 4 18:06:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 20:06:00 +0200 Subject: F7 Zope package In-Reply-To: <1178301466.7630.22.camel@hughsie-laptop> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> Message-ID: <463B7608.60508@leemhuis.info> Richard Hughes schrieb: > On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: >> Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 >> just looks so bad to out the outside and created problems for out >> users. I'd really would like to avoid that. > If a vendor kept patching a driver for kernel 2.4 but refused to port it > to kernel 2.6, would we ship a 2.4 kernel just for that one driver? > Technically possible but a really bad plan. Sure, we have to draw the line somewhere. But why do we have these, too: > $ yum list compat-* > Loading "installonlyn" plugin > Excluding Packages in global exclude list > Finished > Installed Packages > compat-db.i386 4.3.29-2.fc7 installed > compat-libstdc++-296.i386 2.96-138 installed > compat-libstdc++-33.i386 3.2.3-61 installed > compat-readline43.i386 4.3-3 installed > compat-wxGTK26.i386 2.6.3-2 installed > Available Packages > compat-erlang.i386 R10B-10.7.fc7 extras-developme > compat-flex.i386 2.5.4a-1.fc7 extras-developme > compat-gcc-34.i386 3.4.6-7 development > compat-gcc-34-c++.i386 3.4.6-7 development > compat-gcc-34-g77.i386 3.4.6-7 development > compat-gda-ldap.i386 1.2.4-1.fc7 extras-developme > compat-gda-mysql.i386 1.2.4-1.fc7 extras-developme > compat-gda-odbc.i386 1.2.4-1.fc7 extras-developme > compat-gda-postgres.i386 1.2.4-1.fc7 extras-developme > compat-gda-sqlite.i386 1.2.4-1.fc7 extras-developme > compat-gda-xbase.i386 1.2.4-1.fc7 extras-developme > compat-guichan05.i386 0.5.0-5.fc7 extras-developme > compat-guichan05-devel.i386 0.5.0-5.fc7 extras-developme > compat-guile-16.i386 1.6.7-6.fc7 extras-developme > compat-guile-16-devel.i386 1.6.7-6.fc7 extras-developme > compat-libf2c-34.i386 3.4.6-7 development > compat-libgcc-296.i386 2.96-138 development > compat-libgda.i386 1.2.4-1.fc7 extras-developme > compat-libgda-devel.i386 1.2.4-1.fc7 extras-developme > compat-libosip2.i386 2.2.2-12.fc7 extras-developme > compat-libosip2-devel.i386 2.2.2-12.fc7 extras-developme > compat-openldap.i386 2.3.34_2.2.29-0.fc7 development > compat-wxGTK.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-common.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-common-devel.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-devel.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-gl.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-stc.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK-xrc.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK2.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK2-devel.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK2-gl.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK2-stc.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK2-xrc.i386 2.4.2-21.fc6 extras-developme > compat-wxGTK26-devel.i386 2.6.3-2 extras-developme > compat-wxPythonGTK2.i386 2.4.2.4-15.fc7 extras-developme So why not a compat-python24 for a limited timeframe, too -- say one or two releases? CU thl From sundaram at fedoraproject.org Fri May 4 18:12:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 May 2007 23:42:28 +0530 Subject: F7 Zope package In-Reply-To: <463B7608.60508@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> Message-ID: <463B778C.5050904@fedoraproject.org> Thorsten Leemhuis wrote: > Richard Hughes schrieb: >> On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: >>> Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 >>> just looks so bad to out the outside and created problems for out >>> users. I'd really would like to avoid that. >> If a vendor kept patching a driver for kernel 2.4 but refused to port it >> to kernel 2.6, would we ship a 2.4 kernel just for that one driver? >> Technically possible but a really bad plan. > > Sure, we have to draw the line somewhere. I agree with this. Zope is a pretty important python application. Dropping it off the repository just because it does not work with python 2.5 doesn't seem very reasonable. If a maintainer is willing to take care of the compatibility package we should let Zope use that or just use a local copy. Rahul From rdieter at math.unl.edu Fri May 4 18:25:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 May 2007 13:25:07 -0500 Subject: F7 Zope package References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > ... Zope is a pretty important python application. > Dropping it off the repository just because it does not work with python > 2.5 doesn't seem very reasonable. If a maintainer is willing to take > care of the compatibility package we should let Zope use that or just > use a local copy. FESCo discussed this awhile back (not sure when), and (pretty much) veto'd the compat-python option. -- Rex From kevin.kofler at chello.at Fri May 4 18:30:06 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 4 May 2007 18:30:06 +0000 (UTC) Subject: F7 Zope package References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> Message-ID: Rex Dieter math.unl.edu> writes: > FESCo discussed this awhile back (not sure when), and (pretty much) veto'd > the compat-python option. I find it pretty sad that FESCo is vetoing packages which don't have licensing (including copyright/patent/trademark) or serious security issues. If someone is willing to maintain such a package, why not let them? Kevin Kofler From skvidal at linux.duke.edu Fri May 4 18:34:36 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 04 May 2007 14:34:36 -0400 Subject: F7 Zope package In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> Message-ID: <1178303676.18256.140.camel@cutter> On Fri, 2007-05-04 at 18:30 +0000, Kevin Kofler wrote: > Rex Dieter math.unl.edu> writes: > > FESCo discussed this awhile back (not sure when), and (pretty much) veto'd > > the compat-python option. > > I find it pretty sad that FESCo is vetoing packages which don't have licensing > (including copyright/patent/trademark) or serious security issues. If someone > is willing to maintain such a package, why not let them? > b/c of the maintenance headache it adds to the entire distribution and all of the misfiled bugs and confusing reports it will create. -sv From kevin.kofler at chello.at Fri May 4 18:35:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 4 May 2007 18:35:44 +0000 (UTC) Subject: F7 Zope package References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> Message-ID: seth vidal linux.duke.edu> writes: > b/c of the maintenance headache it adds to the entire distribution and > all of the misfiled bugs and confusing reports it will create. But what if Zope just forked Python, renamed their version to "Snake" and then "Snake" would be a new requirement for Zope. Then I'm sure "Snake" would be allowed to get packaged. So the prohibition on a compat-python-24 doesn't make much sense to me. Kevin Kofler From skvidal at linux.duke.edu Fri May 4 18:42:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 04 May 2007 14:42:21 -0400 Subject: F7 Zope package In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> Message-ID: <1178304141.18256.142.camel@cutter> On Fri, 2007-05-04 at 18:35 +0000, Kevin Kofler wrote: > seth vidal linux.duke.edu> writes: > > b/c of the maintenance headache it adds to the entire distribution and > > all of the misfiled bugs and confusing reports it will create. > > But what if Zope just forked Python, renamed their version to "Snake" and > then "Snake" would be a new requirement for Zope. Then I'm sure "Snake" would > be allowed to get packaged. So the prohibition on a compat-python-24 doesn't > make much sense to me. if zope, the upstream, decided to do that as their answer, then yes, we probably would. we're just not going to take on the same load, just for fun. upstream needs to fix it to work with python 2.5. -sv From kevin.kofler at chello.at Fri May 4 18:39:29 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 4 May 2007 18:39:29 +0000 (UTC) Subject: F7 Zope package References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> Message-ID: seth vidal linux.duke.edu> writes: > b/c of the maintenance headache it adds to the entire distribution and > all of the misfiled bugs and confusing reports it will create. Also, from the maintenance and misfiled bugs POV, what do you prefer? An official compat-python-24 in Fedora which everyone uses or 5 different packages in as many different third-party repositories which are all incompatible with each other (e.g. zope in repo A doesn't work with compat-python-24 in repo B) and all have different bugs? Because I think that's exactly what's going to happen with that policy. Kevin Kofler From tibbs at math.uh.edu Fri May 4 19:08:57 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 May 2007 14:08:57 -0500 Subject: F7 Zope package In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> I find it pretty sad that FESCo is vetoing packages which don't KK> have licensing (including copyright/patent/trademark) or serious KK> security issues. The python maintainer insisted that this not happen, and FESCo (as a body) agreed. There is plenty of discussion at http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 Search for " Sorry, we also need to consider the zope/plone problem." KK> If someone is willing to maintain such a package, why not let KK> them? Note that the Zope maintainer considered doing so and decided against it. And to respond to your later message: KK> But what if Zope just forked Python, renamed their version to KK> "Snake" and then "Snake" would be a new requirement for Zope. Note that the zope maintainer considered doing just that but decided against it. - J, From fedora at leemhuis.info Fri May 4 19:09:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 21:09:48 +0200 Subject: F7 Zope package In-Reply-To: <1178303676.18256.140.camel@cutter> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> Message-ID: <463B84FC.4080808@leemhuis.info> seth vidal schrieb: > On Fri, 2007-05-04 at 18:30 +0000, Kevin Kofler wrote: >> Rex Dieter math.unl.edu> writes: >>> FESCo discussed this awhile back (not sure when), and (pretty much) veto'd >>> the compat-python option. >> I find it pretty sad that FESCo is vetoing packages which don't have licensing >> (including copyright/patent/trademark) or serious security issues. If someone >> is willing to maintain such a package, why not let them? > b/c of the maintenance headache it adds to the entire distribution Can't be worse then Xen afaics. Or will we throw that out, too, as upstream doesn't make sure it runs on latest kernels? Ohh wait, I suppose Xen is special? > and > all of the misfiled bugs and confusing reports it will create. I'd prefer some misfiled bugs and confusing reports (*if* they happen) over lots of users that get confused and disappointed if zope is vanishing suddenly. /me wonders how many confusing reports we'll get like this: "I tried to yum update my system but yum boils out due to missing deps. Seems python 2.5 is missing for zope. What did I wrong or how do I fix this?" CU thl From katzj at redhat.com Fri May 4 20:33:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 16:33:25 -0400 Subject: F7 Zope package In-Reply-To: <463B7608.60508@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> Message-ID: <1178310805.2785.18.camel@aglarond.local> On Fri, 2007-05-04 at 20:06 +0200, Thorsten Leemhuis wrote: > Richard Hughes schrieb: > > On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: > >> Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 > >> just looks so bad to out the outside and created problems for out > >> users. I'd really would like to avoid that. > > If a vendor kept patching a driver for kernel 2.4 but refused to port it > > to kernel 2.6, would we ship a 2.4 kernel just for that one driver? > > Technically possible but a really bad plan. > > Sure, we have to draw the line somewhere. But why do we have these, too: [snip] > So why not a compat-python24 for a limited timeframe, too -- say one or > two releases? The difference is that one is libraries linked into an application. The other is a framework with sets of modules, etc. As the python maintainer, I am *STRONGLY* opposed to a compat-python24 package. Because at the end of the day, bug reports will get filed against the wrong python package (because end-users aren't going to know or case). Security problems are still going to end up having to be dealt with and likely through me because the CVE will originally get filed against python and no one will think about compat-python. And the _main_ package owner is still going to have to be somewhat responsible. I'd actually like to see formally in the guidelines that the introduction of a compat package needs to have the assent of the primary package owner. Jeremy From katzj at redhat.com Fri May 4 20:35:12 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 16:35:12 -0400 Subject: F7 Zope package In-Reply-To: <463B84FC.4080808@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> <463B84FC.4080808@leemhuis.info> Message-ID: <1178310912.2785.21.camel@aglarond.local> On Fri, 2007-05-04 at 21:09 +0200, Thorsten Leemhuis wrote: > seth vidal schrieb: > > On Fri, 2007-05-04 at 18:30 +0000, Kevin Kofler wrote: > >> Rex Dieter math.unl.edu> writes: > >>> FESCo discussed this awhile back (not sure when), and (pretty much) veto'd > >>> the compat-python option. > >> I find it pretty sad that FESCo is vetoing packages which don't have licensing > >> (including copyright/patent/trademark) or serious security issues. If someone > >> is willing to maintain such a package, why not let them? > > b/c of the maintenance headache it adds to the entire distribution > > Can't be worse then Xen afaics. Or will we throw that out, too, as > upstream doesn't make sure it runs on latest kernels? Ohh wait, I > suppose Xen is special? Realistically? Xen as it stands was a mistake. Just because we've made them in the past doesn't mean that we should continue to do so. Jeremy From debarshi.ray at gmail.com Fri May 4 20:44:05 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 02:14:05 +0530 Subject: F7 Zope package In-Reply-To: <1178310912.2785.21.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> <463B84FC.4080808@leemhuis.info> <1178310912.2785.21.camel@aglarond.local> Message-ID: <3170f42f0705041344h3189ac98sa83fd95428a8ca58@mail.gmail.com> > > Can't be worse then Xen afaics. Or will we throw that out, too, as > > upstream doesn't make sure it runs on latest kernels? Ohh wait, I > > suppose Xen is special? > Realistically? Xen as it stands was a mistake. Just because we've made > them in the past doesn't mean that we should continue to do so. I recall Fedora had gcc32 in the early days of gcc-4.x. The fact is that if Zope suddenly disappears it will cause a world of inconvenience for a large number of users. I for one, will never be able to use Fedora 7 if this is the case. :-( Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jkeating at redhat.com Fri May 4 20:44:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 13:44:27 -0700 Subject: F7 Zope package In-Reply-To: <3170f42f0705041344h3189ac98sa83fd95428a8ca58@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178310912.2785.21.camel@aglarond.local> <3170f42f0705041344h3189ac98sa83fd95428a8ca58@mail.gmail.com> Message-ID: <200705041344.27660.jkeating@redhat.com> On Friday 04 May 2007 13:44:05 Debarshi 'Rishi' Ray wrote: > I recall Fedora had gcc32 in the early days of gcc-4.x. The fact is > that if Zope suddenly disappears it will cause a world of > inconvenience for a large number of users. I for one, will never be > able to use Fedora 7 if this is the case. Seriously. You can populate a chroot with FC6 content to run plone, or any number of other workarounds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri May 4 21:06:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 23:06:59 +0200 Subject: F7 Zope package In-Reply-To: <1178310912.2785.21.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> <463B84FC.4080808@leemhuis.info> <1178310912.2785.21.camel@aglarond.local> Message-ID: <463BA073.5080802@leemhuis.info> Jeremy Katz schrieb: > On Fri, 2007-05-04 at 21:09 +0200, Thorsten Leemhuis wrote: >> seth vidal schrieb: >>> On Fri, 2007-05-04 at 18:30 +0000, Kevin Kofler wrote: >>>> Rex Dieter math.unl.edu> writes: >>>>> FESCo discussed this awhile back (not sure when), and (pretty much) veto'd >>>>> the compat-python option. >>>> I find it pretty sad that FESCo is vetoing packages which don't have licensing >>>> (including copyright/patent/trademark) or serious security issues. If someone >>>> is willing to maintain such a package, why not let them? >>> b/c of the maintenance headache it adds to the entire distribution >> Can't be worse then Xen afaics. Or will we throw that out, too, as >> upstream doesn't make sure it runs on latest kernels? Ohh wait, I >> suppose Xen is special? > Realistically? Xen as it stands was a mistake. Just because we've made > them in the past doesn't mean that we should continue to do so. Hehe :) Well, I strongly dislike this decision we did for zope, as it creates much hassle for users. But users is what we do this distribution for. But whatever: I assume somebody made sure this annoyance got documented properly in the release notes to avoid users misfile bugs and send confusing reports? As FESCo is indirectly responsible for zope missing now I assume FESCo itself also directly or indirectly took care of documenting this properly? CU thl From katzj at redhat.com Fri May 4 21:04:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 17:04:06 -0400 Subject: F7 Zope package In-Reply-To: <200705041344.27660.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178310912.2785.21.camel@aglarond.local> <3170f42f0705041344h3189ac98sa83fd95428a8ca58@mail.gmail.com> <200705041344.27660.jkeating@redhat.com> Message-ID: <1178312646.2785.27.camel@aglarond.local> On Fri, 2007-05-04 at 13:44 -0700, Jesse Keating wrote: > On Friday 04 May 2007 13:44:05 Debarshi 'Rishi' Ray wrote: > > I recall Fedora had gcc32 in the early days of gcc-4.x. The fact is > > that if Zope suddenly disappears it will cause a world of > > inconvenience for a large number of users. I for one, will never be > > able to use Fedora 7 if this is the case. > > Seriously. You can populate a chroot with FC6 content to run plone, or any > number of other workarounds. Or use virtualization or maybe, just maybe, even help the zope developers get things working with python 2.5 Jeremy From tmus at tmus.dk Fri May 4 21:20:47 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 04 May 2007 23:20:47 +0200 Subject: kernel 2.6.21-1.3116.fc7 possible circular locking dependency In-Reply-To: <463B589F.7060900@tvtransilvania.ro> References: <463B589F.7060900@tvtransilvania.ro> Message-ID: Alexandru Ciobanu wrote: > Upon booting 2.6.21 kernel on my HP500 notebook I get a kind of weid > info message which I've pasted below. > I'm using a custom 2.6.21-1.3116 kernel [I've included a small patch in > drivers/input/serio/i8042.c to get my touchpad going (BZ #230595)] and > reiserfs for filesystem. I'm not experiencing any problems with my > system and I definitely have no ideea what this error(?) is about. > Any ideas? > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.21-1.3116ics.fc7 #1 > ------------------------------------------------------- > chgrp/1221 is trying to acquire lock: > (&REISERFS_SB(s)->xattr_dir_sem){..--}, at: [] > reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] > > but task is already holding lock: > (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > -> #1 (&inode->i_mutex){--..}: > [] __lock_acquire+0xa19/0xba4 > [] lock_acquire+0x56/0x6f > [] __mutex_lock_slowpath+0xf7/0x26e > [] mutex_lock+0x21/0x24 > [] get_xa_root+0x4a/0x10b [reiserfs] > [] open_xa_dir+0x19/0xde [reiserfs] > [] reiserfs_delete_xattrs+0x58/0x160 [reiserfs] > [] reiserfs_delete_inode+0x5d/0xe8 [reiserfs] > [] generic_delete_inode+0xa6/0x110 > [] generic_drop_inode+0x12/0x130 > [] iput+0x63/0x66 > [] do_unlinkat+0xb6/0x123 > [] sys_unlink+0x10/0x12 > [] syscall_call+0x7/0xb > [] 0xffffffff > > -> #0 (&REISERFS_SB(s)->xattr_dir_sem){..--}: > [] __lock_acquire+0x8fd/0xba4 > [] lock_acquire+0x56/0x6f > [] down_read+0x3f/0x51 > [] reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] > [] reiserfs_setattr+0x115/0x258 [reiserfs] > [] notify_change+0x127/0x2c8 > [] chown_common+0x93/0xa6 > [] sys_chown+0x34/0x46 > [] syscall_call+0x7/0xb > [] 0xffffffff > > other info that might help us debug this: > > 1 lock held by chgrp/1221: > #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 > > stack backtrace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_trace+0x12/0x14 > [] dump_stack+0x16/0x18 > [] print_circular_bug_tail+0x5f/0x68 > [] __lock_acquire+0x8fd/0xba4 > [] lock_acquire+0x56/0x6f > [] down_read+0x3f/0x51 > [] reiserfs_chown_xattrs+0x4e/0x106 [reiserfs] > [] reiserfs_setattr+0x115/0x258 [reiserfs] > [] notify_change+0x127/0x2c8 > [] chown_common+0x93/0xa6 > [] sys_chown+0x34/0x46 > [] syscall_call+0x7/0xb > ======================= > AFAICT, this problem has reiserfs written all over it. You should take this to kernel.org, since reiserfs is not supported in fedora... Hope this helps. /Thomas From wilmer at fedoraproject.org Fri May 4 21:24:35 2007 From: wilmer at fedoraproject.org (Wilmer Jaramillo M.) Date: Fri, 4 May 2007 17:24:35 -0400 Subject: Some Candidate Packages for Extras Message-ID: <2b26c4260705041424m38c3b8aai36f77f32aca07e3a@mail.gmail.com> Hi, I finished to package "emesene" and "mybashburn", is there somebody is interested a review in bugzilla? Bugzilla ID: # 217197 and # 238379 Both have full review, i have Sponsorship pending. -- Wilmer Jaramillo M. GPG Key Fingerprint = 0666 D0D3 24CE 8935 9C24 BBF1 87DD BEA2 A4B2 1E8A From kevin.kofler at chello.at Fri May 4 21:34:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 4 May 2007 21:34:56 +0000 (UTC) Subject: Some Candidate Packages for Extras References: <2b26c4260705041424m38c3b8aai36f77f32aca07e3a@mail.gmail.com> Message-ID: Wilmer Jaramillo M. fedoraproject.org> writes: > Hi, I finished to package "emesene" and "mybashburn", is there > somebody is interested a review in bugzilla? > Bugzilla ID: # 217197 and # 238379 > > Both have full review, i have Sponsorship pending. Extras? What Extras? ;-) http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge Unfortunately, I can't help here as I'm not a sponsor. Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Fri May 4 21:37:12 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 4 May 2007 23:37:12 +0200 Subject: F7 Zope package In-Reply-To: <1178310805.2785.18.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <1178310805.2785.18.camel@aglarond.local> Message-ID: <20070504233712.59751f33.mschwendt.tmp0701.nospam@arcor.de> On Fri, 04 May 2007 16:33:25 -0400, Jeremy Katz wrote: > I'd actually like to see formally in the guidelines that the > introduction of a compat package needs to have the assent of the primary > package owner. ... the primary package owner and upstream and any competent testers (whether involved in the packaging or not). And as soon as this becomes part of the guidelines, don't forget adding another guideline for the primary package owner not to break dependencies. From debarshi.ray at gmail.com Fri May 4 21:39:14 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 03:09:14 +0530 Subject: F7 Zope package In-Reply-To: <1178312646.2785.27.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178310912.2785.21.camel@aglarond.local> <3170f42f0705041344h3189ac98sa83fd95428a8ca58@mail.gmail.com> <200705041344.27660.jkeating@redhat.com> <1178312646.2785.27.camel@aglarond.local> Message-ID: <3170f42f0705041439t325c87b7wc88b9101dd5eec4f@mail.gmail.com> > Or use virtualization or maybe, just maybe, even help the zope > developers get things working with python 2.5 It is already on the way: http://code.google.com/soc/zope/appinfo.html?csaid=D1F8274F927002A3 Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From stickster at gmail.com Fri May 4 23:23:10 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 04 May 2007 19:23:10 -0400 Subject: F7 Zope package In-Reply-To: <463BA073.5080802@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> <463B84FC.4080808@leemhuis.info> <1178310912.2785.21.camel@aglarond.local> <463BA073.5080802@leemhuis.info> Message-ID: <1178320990.4542.2.camel@localhost.localdomain> On Fri, 2007-05-04 at 23:06 +0200, Thorsten Leemhuis wrote: > Jeremy Katz schrieb: > > On Fri, 2007-05-04 at 21:09 +0200, Thorsten Leemhuis wrote: > >> seth vidal schrieb: > >>> On Fri, 2007-05-04 at 18:30 +0000, Kevin Kofler wrote: > >>>> Rex Dieter math.unl.edu> writes: > >>>>> FESCo discussed this awhile back (not sure when), and (pretty much) veto'd > >>>>> the compat-python option. > >>>> I find it pretty sad that FESCo is vetoing packages which don't have licensing > >>>> (including copyright/patent/trademark) or serious security issues. If someone > >>>> is willing to maintain such a package, why not let them? > >>> b/c of the maintenance headache it adds to the entire distribution > >> Can't be worse then Xen afaics. Or will we throw that out, too, as > >> upstream doesn't make sure it runs on latest kernels? Ohh wait, I > >> suppose Xen is special? > > Realistically? Xen as it stands was a mistake. Just because we've made > > them in the past doesn't mean that we should continue to do so. > > Hehe :) > > Well, I strongly dislike this decision we did for zope, as it creates > much hassle for users. But users is what we do this distribution for. > > But whatever: I assume somebody made sure this annoyance got documented > properly in the release notes to avoid users misfile bugs and send > confusing reports? As FESCo is indirectly responsible for zope missing > now I assume FESCo itself also directly or indirectly took care of > documenting this properly? Bwahahaha... I mean, um, no. But I did just add a release note for it that will make it to the Web only release notes. (Our release notes always state at the top that the latest version should be consulted on the Web, so people with discs aren't stuck with only what made it to the spins.) Events like this are why we freed up the Beats weeks ago so anyone could edit them, though. Hopefully that will get more people proactively involved, even if only for F8 and beyond. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields 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 email.ahmedkamal at googlemail.com Fri May 4 23:42:25 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 5 May 2007 02:42:25 +0300 Subject: KDE user stats Message-ID: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openSuse has posted the results of a survey spanning 27,462 users. An interesting piece of info, was that the number of KDE users was over 71%, with Gnome around 22%. I'm not trying to start any kind of flame wars, and I know most opensuse users are on that distro for KDE. Still I think we should use a mechanism to gather desktop environement popularity information for Fedora. If that survey is any indication, the KDE "spin" or whatever they call it today, could perhaps use more love. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGO8OFh7vk/g+PRfcRAuKhAJ9G4o6k3N4BSJpR0c26IU2gFze8GACcDp4n 7y+KBC2xmDn3DSNzb4wpsQU= =AxuB -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Fri May 4 23:49:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 May 2007 18:49:14 -0500 Subject: KDE user stats In-Reply-To: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> Message-ID: <1178322554.22813.10.camel@vader.jdub.homelinux.org> On Sat, 2007-05-05 at 02:42 +0300, Ahmed Kamal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > openSuse has posted the results of a survey spanning 27,462 users. An > interesting piece of info, was that the number of KDE users was over > 71%, with Gnome around 22%. I'm not trying to start any kind of flame > wars, and I know most opensuse users are on that distro for KDE. Still > I think we should use a mechanism to gather desktop environement > popularity information for Fedora. If that survey is any indication, > the KDE "spin" or whatever they call it today, could perhaps use more > love. You're welcome to setup a survey of some sorts and ask people to take it. If you do, please share the results. They could be quite interesting indeed. josh From mike at miketc.com Sat May 5 01:21:17 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 04 May 2007 20:21:17 -0500 Subject: Merge update Message-ID: <1178328077.2227.2.camel@scrappy.miketc.com> How's the merge seem to be going and/or working out? Can we expect the finale to happen in the next couple hours or in the wee morning hours? Or dare I ask, do we have a problem or anything? Hope all is going well. Jesse you hangin in there and remembering to eat? haha -- Mike Chambers Madisonville, KY From jkeating at redhat.com Sat May 5 02:00:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 19:00:16 -0700 Subject: Merge update In-Reply-To: <1178328077.2227.2.camel@scrappy.miketc.com> References: <1178328077.2227.2.camel@scrappy.miketc.com> Message-ID: <200705041900.19801.jkeating@redhat.com> On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > How's the merge seem to be going and/or working out? ?Can we expect the > finale to happen in the next couple hours or in the wee morning hours? > > Or dare I ask, do we have a problem or anything? ?Hope all is going > well. > > Jesse you hangin in there and remembering to eat? haha Most is going well. We're scrambling to create ppc64 builds of all the Extras packages, as those didn't exist before, but now they will be built for ppc64. Also we need to hook up some software to make rawhide appear. It may just be in package repo form (not installable) to begin with, we'll see. I wouldn't expect anything this weekend. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at miketc.com Sat May 5 02:29:50 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 04 May 2007 21:29:50 -0500 Subject: Merge update In-Reply-To: <200705041900.19801.jkeating@redhat.com> References: <1178328077.2227.2.camel@scrappy.miketc.com> <200705041900.19801.jkeating@redhat.com> Message-ID: <1178332190.2232.2.camel@scrappy.miketc.com> On Fri, 2007-05-04 at 19:00 -0700, Jesse Keating wrote: > On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > > How's the merge seem to be going and/or working out? Can we expect the > > finale to happen in the next couple hours or in the wee morning hours? > > > > Or dare I ask, do we have a problem or anything? Hope all is going > > well. > > > > Jesse you hangin in there and remembering to eat? haha > > Most is going well. We're scrambling to create ppc64 builds of all the Extras > packages, as those didn't exist before, but now they will be built for ppc64. > Also we need to hook up some software to make rawhide appear. It may just be > in package repo form (not installable) to begin with, we'll see. I wouldn't > expect anything this weekend. That's cool, glad it's coming along. Hopefully anyone that has a package that needs to help fix theirs is standing by or on notify if they are needed to fix their packaging. Anyways, thanks for the update and keep up the good work. -- Mike Chambers Madisonville, KY From debarshi.ray at gmail.com Sat May 5 06:04:11 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 11:34:11 +0530 Subject: KDE user stats In-Reply-To: <1178322554.22813.10.camel@vader.jdub.homelinux.org> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <1178322554.22813.10.camel@vader.jdub.homelinux.org> Message-ID: <3170f42f0705042304q7d4ddd7fu918abf0ae764e0b4@mail.gmail.com> Does not Mugshot do something similar? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From frank-buettner at gmx.net Sat May 5 07:29:17 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 05 May 2007 09:29:17 +0200 Subject: buildNotification fail on koji Message-ID: <463C324D.3030009@gmx.net> When I build one of my packages, the build self will work, but the notification of it will fail. On the web site of the build system I see: Traceback (most recent call last): File "/usr/sbin/kojid", line 1109, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1185, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2128, in handler server.sendmail(from_addr, recipients, message) File "/usr/lib64/python2.4/smtplib.py", line 696, in sendmail (code,resp) = self.data(msg) File "/usr/lib64/python2.4/smtplib.py", line 493, in data self.send(q) File "/usr/lib64/python2.4/smtplib.py", line 320, in send self.sock.sendall(str) File "", line 1, in sendall UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 609: ordinal not in range(128) Example: http://koji.fedoraproject.org/koji/taskinfo?taskID=2607 -------------- 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 jon at fedoraunity.org Sat May 5 08:07:41 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sat, 05 May 2007 02:07:41 -0600 Subject: F7 Zope package In-Reply-To: <1178291788.2702.10.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> Message-ID: <463C3B4D.2070200@fedoraunity.org> David G. Mackay wrote: > It was nice to see that zope is one of the packages available for > installation in F7. Unfortunately, the package won't work on F7 > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The > maintainer that received the bug report suggested that I make some noise > on the devel list, so here I am. I would also make noise, but think it was fully discussed via IRC. I am just checking into the discussion. > The problem is that the zope version > packaged for F7 won't run with python 2.5.x (nor, to my knowledge will > other zope versions). There is no 2.5 support as of yet and it looks like only Zope 3 will eventually support 2.5. > The Zope corporation used to supply "binary" rpms > where the python interpreter that was appropriate for the zope version > was installed in the zope directory tree. They have discontinued this, > but it seems like a good solution for this particular problem. > This was discussed. Anyone care to add the details as to why we are not going to ship a "runzope" 2.4 binary? I understand a compat-python24 package to be more proper but a middle ground might be to ship a 2.4 binary for exclusive use with zope. I know this has been discussed, I just wanted to point out the options have been run through for the sake of a full reply to David M. > Zope is an excellent platform for serving web-based apps, and is well > worth having available as part of the fedora installation. Yes, it is. > Hopefully, > it will be packaged properly. > Please don't point your finger at me. As the packager, it is not fair to me. This is not a packaging issue. This is an issue of including python 2.4 support or not. Jonathan Steffan From jon at fedoraunity.org Sat May 5 08:11:49 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sat, 05 May 2007 02:11:49 -0600 Subject: F7 Zope package In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> Message-ID: <463C3C45.9050900@fedoraunity.org> Jason L Tibbitts III wrote: >>>>>> "KK" == Kevin Kofler writes: >>>>>> > > KK> I find it pretty sad that FESCo is vetoing packages which don't > KK> have licensing (including copyright/patent/trademark) or serious > KK> security issues. > > The python maintainer insisted that this not happen, and FESCo (as a > body) agreed. > > There is plenty of discussion at > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 > Search for " Sorry, we also need to consider the zope/plone > problem." > > KK> If someone is willing to maintain such a package, why not let > KK> them? > > Note that the Zope maintainer considered doing so and decided against > it. > I would consider it and have actually offered, but this was also discussed and requested to not happen. > And to respond to your later message: > > KK> But what if Zope just forked Python, renamed their version to > KK> "Snake" and then "Snake" would be a new requirement for Zope. > > Note that the zope maintainer considered doing just that but decided > against it. > I would also look at doing this, but was this was discussed and requested to not happen. Jonathan Steffan From jon at fedoraunity.org Sat May 5 08:25:45 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sat, 05 May 2007 02:25:45 -0600 Subject: F7 Zope package In-Reply-To: <463C3C45.9050900@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> Message-ID: <463C3F89.1000701@fedoraunity.org> Thread, I want to make it perfectly clear I was involved with trying to progress Zope (and thus python 2.4) support in Fedora 7. For reasons outside of my control, I requested the packages be removed after what I would call lengthy discussion with people more knowledgeable then myself. In no way did I not try or not offer potential solutions. I get the feeling from reading this thread there is a sense I didn't do everything in my power to get Zope supported. Please know I did try. The issue is not a packaging issue, nor (IMHO) an issue with Zope itself. The issue is including python 2.4 support under the Fedora name or not. There are plenty of workarounds we could discuss but I find it more meta-discussion then not. If a "workaround" is eventually needed for current Zope users, each user will end up doing their own solution and I have no idea where that is going to leave things. The point is that there is no planned support for python 2.4 in Fedora 7 and thus I needed to remove the packages from the build system. I invite Zope/Plone users to express their desire to have support but I think I have already fought the battle to the best of my abilities and feel any further action on my part is futile. Jonathan Steffan From opensource at till.name Sat May 5 09:32:20 2007 From: opensource at till.name (Till Maas) Date: Sat, 05 May 2007 11:32:20 +0200 Subject: F7 Zope package In-Reply-To: <1178298825.2785.9.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> Message-ID: <200705051132.21629.opensource@till.name> On Fr Mai 4 2007, Jeremy Katz wrote: > The right place to make noise is to the upstream Zope developers. The > first python 2.5 release candidate was released nine months ago with the > final release coming just after that. According to http://www.python.org/download/releases/ python 2.4.4 and 2.3.6 were released after 2.5, so the older versions of python seem to be still supported. Why should the zope developers change to a newer python release, when even an older release than the one they depend on is still supported? Regards, Till From debarshi.ray at gmail.com Sat May 5 09:32:49 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 15:02:49 +0530 Subject: F7 Zope package In-Reply-To: <463C3F89.1000701@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> Message-ID: <3170f42f0705050232p5be2b6bfnec6b75482e038926@mail.gmail.com> > There are > plenty of workarounds we could discuss but I find it more > meta-discussion then not. If a "workaround" is eventually needed for > current Zope users, each user will end up doing their own solution and I > have no idea where that is going to leave things. Very true. Many who have come to expect Zope to work 'out-of-the-box' after a 'yum install zope' will now be frustrated enough to shift to some another distribution and never use Fedora again. Telling everybody that "you should have read the release notes" is not a good excuse too. :-( Please note that the number of Zope/Plone users affected by this is not going to be negligible enough to consider this as a corner case. > I invite Zope/Plone users to express their desire to have support +1 Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From pertusus at free.fr Sat May 5 10:19:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 May 2007 12:19:50 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-05-02 In-Reply-To: <20070502193242.31950e5c.mschwendt.tmp0701.nospam@arcor.de> References: <20070502165348.30934.91742@extras64.linux.duke.edu> <20070502193242.31950e5c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070505101950.GC2892@free.fr> On Wed, May 02, 2007 at 07:32:42PM +0200, Michael Schwendt wrote: > On Wed, 02 May 2007 16:53:48 -0000, Fedora Extras repoclosure wrote: > > > Summary of broken packages (by owner): > > > > cbalint AT redhat.com > > gdal - 1.4.0-22.fc7.i386 > > gdal - 1.4.0-22.fc7.ppc > > gdal - 1.4.0-22.fc7.x86_64 > > Not yet. But the "dap" updates in needsign will break it. I know it is pretty bad to break sonames that late in the release cycle, but I updated the whole dap stack while fixing a security issue. I also notified Cristian by mail. -- Pat From mschwendt.tmp0701.nospam at arcor.de Sat May 5 10:42:34 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 5 May 2007 12:42:34 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-05-02 In-Reply-To: <20070505101950.GC2892@free.fr> References: <20070502165348.30934.91742@extras64.linux.duke.edu> <20070502193242.31950e5c.mschwendt.tmp0701.nospam@arcor.de> <20070505101950.GC2892@free.fr> Message-ID: <20070505124234.a38fe7f7.mschwendt.tmp0701.nospam@arcor.de> On Sat, 5 May 2007 12:19:50 +0200, Patrice Dumas wrote: > On Wed, May 02, 2007 at 07:32:42PM +0200, Michael Schwendt wrote: > > On Wed, 02 May 2007 16:53:48 -0000, Fedora Extras repoclosure wrote: > > > > > Summary of broken packages (by owner): > > > > > > cbalint AT redhat.com > > > gdal - 1.4.0-22.fc7.i386 > > > gdal - 1.4.0-22.fc7.ppc > > > gdal - 1.4.0-22.fc7.x86_64 > > > > Not yet. But the "dap" updates in needsign will break it. > > I know it is pretty bad to break sonames that late in the release > cycle, but I updated the whole dap stack while fixing a security > issue. I also notified Cristian by mail. Which apparently was possible to fix for FC-6 without an upgrade of libdap: http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/libdap.html http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/dap-server.html Does gdal rebuild without problems? Has that been tried? Library package owners really need to negotiate with owners of dependencies about the possibility to submit simple rebuilds themeselves. From pertusus at free.fr Sat May 5 10:53:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 May 2007 12:53:36 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-05-02 In-Reply-To: <20070505124234.a38fe7f7.mschwendt.tmp0701.nospam@arcor.de> References: <20070502165348.30934.91742@extras64.linux.duke.edu> <20070502193242.31950e5c.mschwendt.tmp0701.nospam@arcor.de> <20070505101950.GC2892@free.fr> <20070505124234.a38fe7f7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070505105336.GF2892@free.fr> On Sat, May 05, 2007 at 12:42:34PM +0200, Michael Schwendt wrote: > > > > I know it is pretty bad to break sonames that late in the release > > cycle, but I updated the whole dap stack while fixing a security > > issue. I also notified Cristian by mail. > > Which apparently was possible to fix for FC-6 without an upgrade of libdap: > > http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/libdap.html > > http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/dap-server.html Indeed, but I wanted to avoid having an old version of libdap through F7, and since I updated dap-server I took the opportunity to update the whole stack. > Does gdal rebuild without problems? > Has that been tried? No. Indeed I should have tried. I'll try now. > Library package owners really need to negotiate with owners of dependencies > about the possibility to submit simple rebuilds themeselves. I proposed that to Cristian. -- Pat From pasik at iki.fi Sat May 5 11:18:21 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sat, 5 May 2007 14:18:21 +0300 Subject: FC7 going to be released with broken/crashing/freezing kernel-xen ? Message-ID: <20070505111821.GZ4933@edu.joroinen.fi> Hi list! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234008 This same bug happens with FC7 kernel-xen packages.. Any plans to fix that? Usually the answer for this has been "but xen is not tracking upstream kernel like we are so we can't fix this".. but is that a reason to ship broken kernel? Maybe revert to older (=working) version then? kernel-xen-2.6.19 works fine.. Thanks! -- Pasi From buildsys at fedoraproject.org Sat May 5 11:51:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 5 May 2007 07:51:45 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-05 Message-ID: <20070505115145.BAF36152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 27 NEW autodownloader-0.2.0-1.fc6 dstat-0.6.6-1.fc6 gscan2pdf-0.9.9-3.fc6 gtk+extra-2.1.1-4.fc6 koji-1.1-2.fc6 NEW ocaml-SDL-0.7.2-6.fc6 NEW perl-Config-Any-0.07-4.fc6 perl-Data-Alias-1.04-1.fc6 NEW perl-Data-Visitor-0.05-2.fc6 NEW perl-Declare-Constraints-Simple-0.03-2.fc6 NEW perl-Email-MIME-Creator-1.453-1.fc6 NEW perl-File-Modified-0.07-4.fc6 perl-Moose-0.21-1.fc6 NEW perl-MooseX-Getopt-0.03-2.fc6 NEW perl-PDF-API2-0.60-3.fc6 NEW perl-Text-SimpleTable-0.03-2.fc6 NEW perl-YAML-Syck-0.82-2.fc6 puppet-0.22.4-1.fc6 NEW python-BeautifulSoup-3.0.4-1.fc6 NEW python-mecab-0.95-3.fc6 NEW qsf-1.2.6-2.fc6 rrdtool-1.2.23-3.fc6 NEW ruby-mecab-0.95-4.fc6 scanbuttond-0.2.3-10.fc6 smb4k-0.8.3-1.fc6 transmission-0.72-1.fc6 wine-0.9.36-2.fc6 Packages built and released for Fedora Extras 5: 21 dstat-0.6.6-1.fc5 gscan2pdf-0.9.9-3.fc5 gtk+extra-2.1.1-3.fc5 NEW perl-Config-Any-0.07-4.fc5 perl-Data-Alias-1.04-1.fc5 NEW perl-Data-Visitor-0.05-2.fc5 NEW perl-Declare-Constraints-Simple-0.03-2.fc5 NEW perl-Email-MIME-Creator-1.453-1.fc5 NEW perl-File-Modified-0.07-4.fc5 perl-Moose-0.21-1.fc5 NEW perl-MooseX-Getopt-0.03-2.fc5 NEW perl-PDF-API2-0.60-3.fc5 NEW perl-Text-SimpleTable-0.03-2.fc5 NEW perl-YAML-Syck-0.82-2.fc5 puppet-0.22.4-1.fc5 NEW python-mecab-0.95-3.fc5 NEW qsf-1.2.6-2.fc5 rrdtool-1.2.23-3.fc5 NEW ruby-mecab-0.95-4.fc5 smb4k-0.8.3-1.fc5 wine-0.9.36-2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From alan at redhat.com Sat May 5 11:52:16 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 5 May 2007 07:52:16 -0400 Subject: F7 Zope package In-Reply-To: <1178310912.2785.21.camel@aglarond.local> References: <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> <463B84FC.4080808@leemhuis.info> <1178310912.2785.21.camel@aglarond.local> Message-ID: <20070505115216.GA28835@devserv.devel.redhat.com> On Fri, May 04, 2007 at 04:35:12PM -0400, Jeremy Katz wrote: > Realistically? Xen as it stands was a mistake. Just because we've made > them in the past doesn't mean that we should continue to do so. Its a bit early to throw out Xen just get - at least until lguest has some more features (eg migration) From jkeating at redhat.com Sat May 5 13:07:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 5 May 2007 06:07:49 -0700 Subject: F7 Zope package In-Reply-To: <3170f42f0705050232p5be2b6bfnec6b75482e038926@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463C3F89.1000701@fedoraunity.org> <3170f42f0705050232p5be2b6bfnec6b75482e038926@mail.gmail.com> Message-ID: <200705050607.50226.jkeating@redhat.com> On Saturday 05 May 2007 02:32:49 Debarshi 'Rishi' Ray wrote: > Very true. Many who have come to expect Zope to work 'out-of-the-box' > after a 'yum install zope' will now be frustrated enough to shift to > some another distribution and never use Fedora again. Telling > everybody that "you should have read the release notes" is not a good > excuse too. :-( > > Please note that the number of Zope/Plone users affected by this is > not going to be negligible enough to consider this as a corner case. > > > I invite Zope/Plone users to express their desire to have support > > +1 Please express it also upstream. Fedora isn't going to be the only distro using Python2.5. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat May 5 13:08:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 5 May 2007 06:08:51 -0700 Subject: F7 Zope package In-Reply-To: <200705051132.21629.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <200705051132.21629.opensource@till.name> Message-ID: <200705050608.51673.jkeating@redhat.com> On Saturday 05 May 2007 02:32:20 Till Maas wrote: > According to http://www.python.org/download/releases/ python 2.4.4 and > 2.3.6 were released after 2.5, so the older versions of python seem to be > still supported. Why should the zope developers change to a newer python > release, when even an older release than the one they depend on is still > supported? How many kenrel 2.4 releases has there been since kernel 2.6 came out? Why should anybody support kernel 2.6 if kernel 2.4 releases are still happening? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat May 5 13:54:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 May 2007 15:54:39 +0200 Subject: F7 Zope package In-Reply-To: <200705050607.50226.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463C3F89.1000701@fedoraunity.org> <3170f42f0705050232p5be2b6bfnec6b75482e038926@mail.gmail.com> <200705050607.50226.jkeating@redhat.com> Message-ID: <463C8C9F.6010008@leemhuis.info> Jesse Keating schrieb: > On Saturday 05 May 2007 02:32:49 Debarshi 'Rishi' Ray wrote: >> Very true. Many who have come to expect Zope to work 'out-of-the-box' >> after a 'yum install zope' will now be frustrated enough to shift to >> some another distribution and never use Fedora again. Telling >> everybody that "you should have read the release notes" is not a good >> excuse too. :-( >> Please note that the number of Zope/Plone users affected by this is >> not going to be negligible enough to consider this as a corner case. >>> I invite Zope/Plone users to express their desire to have support >> +1 > Please express it also upstream. +1 > Fedora isn't going to be the only distro > using Python2.5. But one of the first. Well, Ubuntu 7.04 has python 2.4 already; but they afaics ship a 2.4 package for those that want/need one. CU thl From opensource at till.name Sat May 5 14:00:58 2007 From: opensource at till.name (Till Maas) Date: Sat, 05 May 2007 16:00:58 +0200 Subject: F7 Zope package In-Reply-To: <200705050608.51673.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> Message-ID: <200705051600.59640.opensource@till.name> On Sa Mai 5 2007, Jesse Keating wrote: > How many kenrel 2.4 releases has there been since kernel 2.6 came out? Why > should anybody support kernel 2.6 if kernel 2.4 releases are still > happening? Afaik it is not possible to use 2.4 and 2.6 kernels at the same time, but with python there seem to be no technical problems, so these two issues are not really comparable. Regards, Till From mastahnke at gmail.com Sat May 5 15:01:10 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 5 May 2007 10:01:10 -0500 Subject: F7 Zope package In-Reply-To: <200705051600.59640.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> Message-ID: <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> On 5/5/07, Till Maas wrote: > On Sa Mai 5 2007, Jesse Keating wrote: > > > How many kenrel 2.4 releases has there been since kernel 2.6 came out? Why > > should anybody support kernel 2.6 if kernel 2.4 releases are still > > happening? > > Afaik it is not possible to use 2.4 and 2.6 kernels at the same time, but with > python there seem to be no technical problems, so these two issues are not > really comparable. Doens't slackware ship a 2.4 kernel and a 2.6 kernel in their release? Also, I think this only cements the feeling that Fedora is for developers, not users. When I talk to other Linux users, they say "Fedora was great, until I found something that listened to the end-users much more." As a developer, I love Fedora. As a user, I feel like many items that are pointed out are ignored because it means developers have to do something. I am not trying to start a flame-war, but please remember, we develop to serve users, and they are very important. If they want/require zope python 2.4, we should try to accommodate them; otherwise it's a 3rd party repo job and will show that Fedora is also incomplete. stahnma > > Regards, > Till > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From tibbs at math.uh.edu Sat May 5 16:28:49 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2007 11:28:49 -0500 Subject: F7 Zope package In-Reply-To: <463C3C45.9050900@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> Message-ID: >>>>> "JS" == Jonathan Steffan writes: JS> I would also look at doing this, but was this was discussed and JS> requested to not happen. I apologize for any inaccuracies; we chatted on IRC a bit after that FESCO meeting ("tibbs, thanks for throwing down :-P") but I was speaking from memory instead of my logs and my memory isn't all that great these days. - J< From tonynelson at georgeanelson.com Sat May 5 16:30:56 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sat, 5 May 2007 12:30:56 -0400 Subject: F7 Zope package In-Reply-To: <200705051132.21629.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <200705051132.21629.opensource@till.name> Message-ID: At 11:32 AM +0200 5/5/07, Till Maas wrote: >On Fr Mai 4 2007, Jeremy Katz wrote: > >> The right place to make noise is to the upstream Zope developers. The >> first python 2.5 release candidate was released nine months ago with the >> final release coming just after that. > >According to http://www.python.org/download/releases/ python 2.4.4 and 2.3.6 >were released after 2.5, so the older versions of python seem to be still >supported. Why should the zope developers change to a newer python release, >when even an older release than the one they depend on is still supported? Those are intended to be final bug-fix releases. The 2.3.6 release was special, and there may or may not be any such corresponding release for 2.4 when 2.6 is out. If a serious security vulnerability is found, then there may well be another release. So, most likely, they have received thier final maintenance. -- ____________________________________________________________________ TonyN.:' ' From denis at poolshark.org Sat May 5 16:55:12 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 05 May 2007 18:55:12 +0200 Subject: F7 Zope package In-Reply-To: <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> Message-ID: <463CB6F0.6000302@poolshark.org> Michael Stahnke wrote: > On 5/5/07, Till Maas wrote: >> On Sa Mai 5 2007, Jesse Keating wrote: >> >> > How many kenrel 2.4 releases has there been since kernel 2.6 came >> out? Why >> > should anybody support kernel 2.6 if kernel 2.4 releases are still >> > happening? >> >> Afaik it is not possible to use 2.4 and 2.6 kernels at the same time, >> but with >> python there seem to be no technical problems, so these two issues are >> not >> really comparable. > Doens't slackware ship a 2.4 kernel and a 2.6 kernel in their release? > > Also, I think this only cements the feeling that Fedora is for > developers, not users. When I talk to other Linux users, they say > "Fedora was great, until I found something that listened to the > end-users much more." As a developer, I love Fedora. As a user, I > feel like many items that are pointed out are ignored because it means > developers have to do something. > I am not trying to start a flame-war, but please remember, we develop > to serve users, and they are very important. If they want/require > zope python 2.4, we should try to accommodate them; otherwise it's a > 3rd party repo job and will show that Fedora is also incomplete. My feelings also. I mean if it's technically possible to package clean compat python 2.4 packages, and we have competent community members willing to do it, i don't understand why we shouldn't let them... From debarshi.ray at gmail.com Sat May 5 17:28:18 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 22:58:18 +0530 Subject: F7 Zope package In-Reply-To: <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> Message-ID: <3170f42f0705051028m1d5ec94aqd52baa42ef727c0e@mail.gmail.com> > Also, I think this only cements the feeling that Fedora is for > developers, not users. When I talk to other Linux users, they say > "Fedora was great, until I found something that listened to the > end-users much more." As a developer, I love Fedora. As a user, I > feel like many items that are pointed out are ignored because it means > developers have to do something. > I am not trying to start a flame-war, but please remember, we develop > to serve users, and they are very important. If they want/require > zope python 2.4, we should try to accommodate them; otherwise it's a > 3rd party repo job and will show that Fedora is also incomplete. I entirely agree with you here. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Sat May 5 17:32:05 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 5 May 2007 23:02:05 +0530 Subject: F7 Zope package In-Reply-To: <200705050607.50226.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463C3F89.1000701@fedoraunity.org> <3170f42f0705050232p5be2b6bfnec6b75482e038926@mail.gmail.com> <200705050607.50226.jkeating@redhat.com> Message-ID: <3170f42f0705051032pb5ea677i484d15adf24ff9cc@mail.gmail.com> > Please express it also upstream. Fedora isn't going to be the only distro > using Python2.5. They already working on it. http://code.google.com/soc/zope/appinfo.html?csaid=D1F8274F927002A3 I just hope that Fedora gives them some more time. :-) Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mike at miketc.com Sat May 5 17:36:42 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 05 May 2007 12:36:42 -0500 Subject: Merge update In-Reply-To: <1178332190.2232.2.camel@scrappy.miketc.com> References: <1178328077.2227.2.camel@scrappy.miketc.com> <200705041900.19801.jkeating@redhat.com> <1178332190.2232.2.camel@scrappy.miketc.com> Message-ID: <1178386603.2232.15.camel@scrappy.miketc.com> On Fri, 2007-05-04 at 21:29 -0500, Mike Chambers wrote: > On Fri, 2007-05-04 at 19:00 -0700, Jesse Keating wrote: > > On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > > > How's the merge seem to be going and/or working out? Can we expect the > > > finale to happen in the next couple hours or in the wee morning hours? > > > > > > Or dare I ask, do we have a problem or anything? Hope all is going > > > well. > > > > > > Jesse you hangin in there and remembering to eat? haha > > > > Most is going well. We're scrambling to create ppc64 builds of all the Extras > > packages, as those didn't exist before, but now they will be built for ppc64. > > Also we need to hook up some software to make rawhide appear. It may just be > > in package repo form (not installable) to begin with, we'll see. I wouldn't > > expect anything this weekend. > > That's cool, glad it's coming along. Hopefully anyone that has a package > that needs to help fix theirs is standing by or on notify if they are > needed to fix their packaging. > > Anyways, thanks for the update and keep up the good work. I know extras for FC6/FC5 are still being built while the merge is going on, but figured extras-devel could be deleted since there will be changes/downloads to sync up again once it's all said and done? Hrm, this might sound confusing, as in I mirror another mirror, so guess I am asking about stopping sync'ing and to go ahead and delete the extras-devel dir if I wanted to? -- Mike Chambers Madisonville, KY From fedora at leemhuis.info Sat May 5 17:45:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 05 May 2007 19:45:07 +0200 Subject: F7 Zope package In-Reply-To: <463CB6F0.6000302@poolshark.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> Message-ID: <463CC2A3.9090600@leemhuis.info> Denis Leroy schrieb: > Michael Stahnke wrote: >> On 5/5/07, Till Maas wrote: >>> On Sa Mai 5 2007, Jesse Keating wrote: >>>> How many kenrel 2.4 releases has there been since kernel 2.6 came >>> out? Why >>>> should anybody support kernel 2.6 if kernel 2.4 releases are still >>>> happening? >>> Afaik it is not possible to use 2.4 and 2.6 kernels at the same time, >>> but with >>> python there seem to be no technical problems, so these two issues are >>> not >>> really comparable. >> Doens't slackware ship a 2.4 kernel and a 2.6 kernel in their release? >> Also, I think this only cements the feeling that Fedora is for >> developers, not users. When I talk to other Linux users, they say >> "Fedora was great, until I found something that listened to the >> end-users much more." As a developer, I love Fedora. As a user, I >> feel like many items that are pointed out are ignored because it means >> developers have to do something. >> I am not trying to start a flame-war, but please remember, we develop >> to serve users, and they are very important. If they want/require >> zope python 2.4, we should try to accommodate them; otherwise it's a >> 3rd party repo job and will show that Fedora is also incomplete. > My feelings also. +1 from here, too > I mean if it's technically possible to package clean > compat python 2.4 packages, and we have competent community members > willing to do it, i don't understand why we shouldn't let them... Well, we need a clean break now and then, as we end with a big and unmaintainable mess with lots of compat packages otherwise. So I can understand the intention to not ship something like compat-python -- but I think it's to early for that. So my vote is to ship a compat-python24 for F7, but tell everyone that we won't do that for F8 and later. That gives developers like those from zope half a year time to prepare. I think that's only fair. Cu thl From dwmw2 at infradead.org Sat May 5 17:50:52 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 May 2007 18:50:52 +0100 Subject: F7 Zope package In-Reply-To: <463B71F1.4040300@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> Message-ID: <1178387453.17680.38.camel@shinybook.infradead.org> On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: > Jeremy Katz schrieb: > > On Fri, 2007-05-04 at 10:16 -0500, David G. Mackay wrote: > >> It was nice to see that zope is one of the packages available for > >> installation in F7. Unfortunately, the package won't work on F7 > >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The > >> maintainer that received the bug report suggested that I make some noise > >> on the devel list, so here I am. The problem is that the zope version > >> packaged for F7 won't run with python 2.5.x So? Surely it's the r?le of the Fedora package maintainer to _make_ it work with Fedora? Is the package maintainer AWOL? > Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 just > looks so bad to out the outside and created problems for out users. I'd > really would like to avoid that. Yes, we should avoid getting into a situation where that can happen. We need to make sure we have active and capable package maintainers for the packages we ship. -- dwmw2 From dwmw2 at infradead.org Sat May 5 18:02:21 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 May 2007 19:02:21 +0100 Subject: F7 Zope package In-Reply-To: <200705051132.21629.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <200705051132.21629.opensource@till.name> Message-ID: <1178388141.17680.42.camel@shinybook.infradead.org> On Sat, 2007-05-05 at 11:32 +0200, Till Maas wrote: > On Fr Mai 4 2007, Jeremy Katz wrote: > > > The right place to make noise is to the upstream Zope developers. The > > first python 2.5 release candidate was released nine months ago with the > > final release coming just after that. > > According to http://www.python.org/download/releases/ python 2.4.4 and 2.3.6 > were released after 2.5, so the older versions of python seem to be still > supported. Why should the zope developers change to a newer python release, > when even an older release than the one they depend on is still supported? They shouldn't, necessarily. It's up to Fedora folks to make Fedora work a coherent whole with the choices that Fedora makes (like python 2.5). That's what makes it a distribution and not just a random collection of packages on a DVD. -- dwmw2 From caillon at redhat.com Sat May 5 19:43:50 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 05 May 2007 15:43:50 -0400 Subject: KDE user stats In-Reply-To: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> Message-ID: <463CDE76.2090005@redhat.com> Ahmed Kamal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > openSuse has posted the results of a survey spanning 27,462 users. An > interesting piece of info, was that the number of KDE users was over 71%, > with Gnome around 22%. I'm not trying to start any kind of flame wars, > and I > know most opensuse users are on that distro for KDE. Still I think we > should > use a mechanism to gather desktop environement popularity information for > Fedora. If that survey is any indication, the KDE "spin" or whatever they > call it today, could perhaps use more love. The KDE spin should get more love regardless. But we should treat these statistics with a bag of salt. If all I cared about was working on the popular stuff, I'd be working for Microsoft. From tibbs at math.uh.edu Sat May 5 20:17:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2007 15:17:18 -0500 Subject: F7 Zope package In-Reply-To: <1178387453.17680.38.camel@shinybook.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> So? Surely it's the r?le of the Fedora package maintainer to DW> _make_ it work with Fedora? Is the package maintainer AWOL? I think you drastically underestimate the amount of work required there. This isn't just fixing up a couple of bits of code. The package maintainer has posted in this very thread and is active in the maintenance of the package. - J< From email.ahmedkamal at googlemail.com Sat May 5 20:24:39 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 5 May 2007 23:24:39 +0300 Subject: KDE user stats In-Reply-To: <463CDE76.2090005@redhat.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> Message-ID: <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> > The KDE spin should get more love regardless. But we should treat these > statistics with a bag of salt. If all I cared about was working on the > popular stuff, I'd be working for Microsoft. IMHO that logic is flawed. Most of us don't use MS products, because of their poor technological implementation and because we care about using open-source standards-based software. I know MS makes the most used software in the world, but I don't care and will not use it! However, in the world of open-source software, we should care if users do prefer one of the alternatives strongly over the other! Just hypothetically if we do discover that over 70% of Fedora users use and choose KDE over other desktop environments, like the opensuse user base did. Then perhaps KDE should be treated as a first class DE as much as gnome if not more! I understand redhat likes Gnome on its Enterprise products, but nothing should be stopping fedora from choosing KDE, or at least putting both on equal footing. It's hard to argue, but I always get the feeling KDE is treated as a second class DE. Anyway, the most important message in this thread, should be that it's important to start gathering information about what DE our user base prefers! Perhaps, a checkbox "I prefer KDE"/"I prefer Gnome" besides the F7 download links, should provide enough clicks for a statistical meaning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Sat May 5 20:25:08 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 05 May 2007 21:25:08 +0100 Subject: F7 Zope package In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> Message-ID: <1178396708.11851.78.camel@pmac.infradead.org> On Sat, 2007-05-05 at 15:17 -0500, Jason L Tibbitts III wrote: > I think you drastically underestimate the amount of work required > there. This isn't just fixing up a couple of bits of code. That's entirely feasible. I tend to hide under the sofa when python enters the equation. Nevertheless, the changelog on the python package seems to indicate that we first imported python 2.5b1 almost a year ago -- in June 2006 (although that seems strange since it predates FC6). That's quite a long time. -- dwmw2 From mschwendt.tmp0701.nospam at arcor.de Sat May 5 18:06:06 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 5 May 2007 20:06:06 +0200 Subject: Merge update In-Reply-To: <1178386603.2232.15.camel@scrappy.miketc.com> References: <1178328077.2227.2.camel@scrappy.miketc.com> <200705041900.19801.jkeating@redhat.com> <1178332190.2232.2.camel@scrappy.miketc.com> <1178386603.2232.15.camel@scrappy.miketc.com> Message-ID: <20070505200606.0780c006.mschwendt.tmp0701.nospam@arcor.de> On Sat, 05 May 2007 12:36:42 -0500, Mike Chambers wrote: > On Fri, 2007-05-04 at 21:29 -0500, Mike Chambers wrote: > > On Fri, 2007-05-04 at 19:00 -0700, Jesse Keating wrote: > > > On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > > > > How's the merge seem to be going and/or working out? Can we expect the > > > > finale to happen in the next couple hours or in the wee morning hours? > > > > > > > > Or dare I ask, do we have a problem or anything? Hope all is going > > > > well. > > > > > > > > Jesse you hangin in there and remembering to eat? haha > > > > > > Most is going well. We're scrambling to create ppc64 builds of all the Extras > > > packages, as those didn't exist before, but now they will be built for ppc64. > > > Also we need to hook up some software to make rawhide appear. It may just be > > > in package repo form (not installable) to begin with, we'll see. I wouldn't > > > expect anything this weekend. > > > > That's cool, glad it's coming along. Hopefully anyone that has a package > > that needs to help fix theirs is standing by or on notify if they are > > needed to fix their packaging. > > > > Anyways, thanks for the update and keep up the good work. Please stop cross-posting. fedora-devel is the right list for the merge. There is way too much cross-posting on fedora related lists. > I know extras for FC6/FC5 are still being built while the merge is going > on, but figured extras-devel could be deleted since there will be > changes/downloads to sync up again once it's all said and done? The Wiki page about the merge covers the new repo layout. If I were you, I would not delete extras-devel, but merge it with rawhide when the repo merge is done. Since that is what has happened in koji already [*], you will save yourself downloading/rsyncing lots of old packages again. [*] koji keeps a copy of every built package, and kojira constructs full repositories from all packages based on tags. In koji, core and extras are merged already. It's the public repository that's missing. > Hrm, this might sound confusing, as in I mirror another mirror, so guess > I am asking about stopping sync'ing and to go ahead and delete the > extras-devel dir if I wanted to? extras devel won't see any updates. From rdieter at math.unl.edu Sat May 5 21:17:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 05 May 2007 16:17:20 -0500 Subject: KDE SIG can use your help In-Reply-To: <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> Message-ID: <463CF460.5040702@math.unl.edu> Ahmed Kamal wrote: > Just hypothetically if we do discover that over 70% of Fedora users use > and choose KDE over other desktop environments, like the opensuse user > base did. Then perhaps KDE should be treated as a first class DE as much > as gnome if not more! I understand redhat likes Gnome on its Enterprise > products, but nothing should be stopping fedora from choosing KDE, or at > least putting both on equal footing. It's hard to argue, but I always > get the feeling KDE is treated as a second class DE. The only thing unequal about DE footings in Fedora is the # of folks working on each. Just so happens, a lot of Red Hat employees are paid to work on gnome, and I'd venture it outnumbers those @redhat working on KDE. NOTE: Red Hat != Fedora. Nothing wrong with that. Having been focusing most of my attention on Fedora's kde packaging, I haven't had all that much spare cycles to work on the task of soliciting help/contributors to the KDE cause on Fedora. My roundabout point is... If you want Fedora/KDE to be better, then *do* something to make that happen, like joining the KDE SIG, contributing/maintaining kde packages, providing feedback, etc... We certainly could use all the help we can get. Free punch and pie for all who attend the next KDE SIG irc meeting! http://fedoraproject.org/wiki/SIGs/KDE (not that you have to wait till then to contribute anything...) :) -- Rex From stickster at gmail.com Sat May 5 22:03:40 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 05 May 2007 18:03:40 -0400 Subject: F7 Zope package In-Reply-To: <1178396708.11851.78.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <1178396708.11851.78.camel@pmac.infradead.org> Message-ID: <1178402620.6112.6.camel@localhost.localdomain> On Sat, 2007-05-05 at 21:25 +0100, David Woodhouse wrote: > On Sat, 2007-05-05 at 15:17 -0500, Jason L Tibbitts III wrote: > > I think you drastically underestimate the amount of work required > > there. This isn't just fixing up a couple of bits of code. > > That's entirely feasible. I tend to hide under the sofa when python > enters the equation. Nevertheless, the changelog on the python package > seems to indicate that we first imported python 2.5b1 almost a year ago > -- in June 2006 (although that seems strange since it predates FC6). > That's quite a long time. No no, he *really* means "drastically underestimate." The maintainer is pretty knowledgeable in the ways of the package, and Python. This is just a REALLY big job. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields 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 caillon at redhat.com Sat May 5 22:25:43 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 05 May 2007 18:25:43 -0400 Subject: KDE user stats In-Reply-To: <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> Message-ID: <463D0467.4030301@redhat.com> Ahmed Kamal wrote: > Just hypothetically if we do discover that over 70% of Fedora users use and > choose KDE over other desktop environments, like the opensuse user base > did. > Then perhaps KDE should be treated as a first class DE as much as gnome The point you're missing is that it should be treated like a first class citizen regardless. We don't need stats to do this, just people. From jon at fedoraunity.org Sun May 6 00:09:38 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sat, 05 May 2007 18:09:38 -0600 Subject: F7 Zope package In-Reply-To: <1178387453.17680.38.camel@shinybook.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> Message-ID: <463D1CC2.8000204@fedoraunity.org> David Woodhouse wrote: > On Fri, 2007-05-04 at 19:48 +0200, Thorsten Leemhuis wrote: > >> Jeremy Katz schrieb: >> >>> On Fri, 2007-05-04 at 10:16 -0500, David G. Mackay wrote: >>> >>>> It was nice to see that zope is one of the packages available for >>>> installation in F7. Unfortunately, the package won't work on F7 >>>> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238809). The >>>> maintainer that received the bug report suggested that I make some noise >>>> on the devel list, so here I am. The problem is that the zope version >>>> packaged for F7 won't run with python 2.5.x >>>> > > So? Surely it's the r?le of the Fedora package maintainer to _make_ it > work with Fedora? Is the package maintainer AWOL? > I'm not AWOL and I don't think it is my job to fix upstream code. Ok, I will state yet again; This is not a packaging issue. This is an issue of including python 2.4 support in Fedora 7 or not. Just because I am maintaining the packages, does this mean it is a requirement I work upstream to fix the many things that need to be done to even *begin* to support python 2.5? No, I am just the packager. There are *technical* reasons Zope will not run on python 2.5 and it is a lot more then it seems you think. To try to make this more a complete discussion (even though I have already seen this posted): http://wiki.zope.org/zope3/Zope3UsingPython25 Please, I request that anyone that feels this is my fault and I am not a capable package maintain read the above... and I mean all of it. To the best of my knowledge this also shows there will never be any support for python 2.5 in the Zope 2 branch; at least not any time soon. I don't know when Plone is going to target Zope 3 but I get the feeling it is no time soon. This means that even if we get Zope 3 support in Fedora 7 using python 2.5 all the plone users will be out of luck. > >> Shipping Zope in Fedora 5 and Fedora 6 and excluding it in Fedora 7 just >> looks so bad to out the outside and created problems for out users. I'd >> really would like to avoid that. >> As would I. > > Yes, we should avoid getting into a situation where that can happen. > We need to make sure we have active and capable package maintainers for > the packages we ship. > I am active. Please note the current pacakges are Zope 2.9.7 and Plone 2.5.2, the most current stable/recommended versions that run on python 2.4. I promptly push out updates. Please check these things before you smear active members of the community. Jonathan Steffan From tibbs at math.uh.edu Sun May 6 00:10:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2007 19:10:09 -0500 Subject: F7 Zope package In-Reply-To: <1178396708.11851.78.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <1178396708.11851.78.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Nevertheless, the changelog on the python package seems to DW> indicate that we first imported python 2.5b1 almost a year ago in DW> June 2006 (although that seems strange since it predates DW> FC6). That's quite a long time. Sometimes upstream sucks. Is this really news to anyone? And of course people should be questioning why the Python developers would go out and break one of their flagship applications so badly that it's not fixed even a year later. Sometimes upstream sucks, and we're left trying to beat a usable distro out of the resulting occasional suckitude. - J< From lightsolphoenix at gmail.com Sun May 6 00:52:59 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 5 May 2007 20:52:59 -0400 Subject: Kernel compliation errors Message-ID: <200705052053.00032.lightsolphoenix@gmail.com> Recently I've been trying to compile KQemu so I can get decent speed running Qemu (for those who want to know why, my stupid college requires Visual Studio and I don't really want to waste a whole partition keeping Windows around). However, when I compile it, I get an error stating that the format of the kernel module is not compatible with the kernel. WTF? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From warren at togami.com Sun May 6 01:08:12 2007 From: warren at togami.com (Warren Togami) Date: Sat, 05 May 2007 21:08:12 -0400 Subject: Kernel compliation errors In-Reply-To: <200705052053.00032.lightsolphoenix@gmail.com> References: <200705052053.00032.lightsolphoenix@gmail.com> Message-ID: <463D2A7C.7020700@togami.com> Kelly wrote: > Recently I've been trying to compile KQemu so I can get decent speed running > Qemu (for those who want to know why, my stupid college requires Visual > Studio and I don't really want to waste a whole partition keeping Windows > around). However, when I compile it, I get an error stating that the format > of the kernel module is not compatible with the kernel. WTF? I don't know anything about your build problem, but is your hardware capable of HVM? You could use qemu-kvm instead of kqemu. Warren Togami wtogami at redhat.com From lightsolphoenix at gmail.com Sun May 6 02:01:05 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 5 May 2007 22:01:05 -0400 Subject: Kernel compliation errors In-Reply-To: <463D2A7C.7020700@togami.com> References: <200705052053.00032.lightsolphoenix@gmail.com> <463D2A7C.7020700@togami.com> Message-ID: <200705052201.05984.lightsolphoenix@gmail.com> On Saturday, May 05, 2007 9:08 pm Warren Togami wrote: > Kelly wrote: > > Recently I've been trying to compile KQemu so I can get decent speed > > running Qemu (for those who want to know why, my stupid college requires > > Visual Studio and I don't really want to waste a whole partition keeping > > Windows around). However, when I compile it, I get an error stating that > > the format of the kernel module is not compatible with the kernel. WTF? > > I don't know anything about your build problem, but is your hardware > capable of HVM? You could use qemu-kvm instead of kqemu. > > Warren Togami > wtogami at redhat.com Probably not; it's an AMD Mobile Sempron. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From lightsolphoenix at gmail.com Sun May 6 03:16:14 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 5 May 2007 23:16:14 -0400 Subject: Kernel compliation errors In-Reply-To: <463D2A7C.7020700@togami.com> References: <200705052053.00032.lightsolphoenix@gmail.com> <463D2A7C.7020700@togami.com> Message-ID: <200705052316.15218.lightsolphoenix@gmail.com> Kelly wrote: > > Recently I've been trying to compile KQemu so I can get decent speed > > running Qemu (for those who want to know why, my stupid college requires > > Visual Studio and I don't really want to waste a whole partition keeping > > Windows around). However, when I compile it, I get an error stating that > > the format of the kernel module is not compatible with the kernel. WTF? BTW, I noticed that I'm also getting these errors from ndiswrapper, most of the ALSA sound drivers, and just about every driver that doesn't come with the Fedora default setup. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sean.stangl at gmail.com Sun May 6 04:07:34 2007 From: sean.stangl at gmail.com (Sean Stangl) Date: Sun, 06 May 2007 00:07:34 -0400 Subject: Kernel compliation errors In-Reply-To: <200705052316.15218.lightsolphoenix@gmail.com> References: <200705052053.00032.lightsolphoenix@gmail.com> <463D2A7C.7020700@togami.com> <200705052316.15218.lightsolphoenix@gmail.com> Message-ID: <1178424454.13686.5.camel@localhost.localdomain> On Sat, 2007-05-05 at 23:16 -0400, Kelly wrote: > Kelly wrote: > BTW, I noticed that I'm also getting these errors from ndiswrapper, most of > the ALSA sound drivers, and just about every driver that doesn't come with > the Fedora default setup. Have you verified that the modules are building against the sources for the kernel that you're running, and not against something else (Check the terminal output of make)? I'm betting that this isn't some error within Fedora, namely since I've never heard of this issue previously, but if it turns out that kernel-devel has been updated incorrectly for your architecture, that would be good to check. -Sean Stangl From lightsolphoenix at gmail.com Sun May 6 05:22:14 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 6 May 2007 01:22:14 -0400 Subject: Kernel compliation errors In-Reply-To: <1178424454.13686.5.camel@localhost.localdomain> References: <200705052053.00032.lightsolphoenix@gmail.com> <200705052316.15218.lightsolphoenix@gmail.com> <1178424454.13686.5.camel@localhost.localdomain> Message-ID: <200705060122.15508.lightsolphoenix@gmail.com> On Sunday, May 06, 2007 12:07 am Sean Stangl wrote: > On Sat, 2007-05-05 at 23:16 -0400, Kelly wrote: > > Kelly wrote: > > BTW, I noticed that I'm also getting these errors from ndiswrapper, most > > of the ALSA sound drivers, and just about every driver that doesn't come > > with the Fedora default setup. > > Have you verified that the modules are building against the sources for > the kernel that you're running, and not against something else (Check > the terminal output of make)? I'm betting that this isn't some error > within Fedora, namely since I've never heard of this issue previously, > but if it turns out that kernel-devel has been updated incorrectly for > your architecture, that would be good to check. > > -Sean Stangl In this case, not only am I getting the errors from modules I built, but also modules I've downloaded through ATRPMS and modules automated through DKMS. When I first started getting the errors, I went and double-checked that the version & arch numbers were the same, so that's not the problem. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sundaram at fedoraproject.org Sun May 6 06:48:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 06 May 2007 12:18:00 +0530 Subject: KDE user stats In-Reply-To: <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> Message-ID: <463D7A20.600@fedoraproject.org> Ahmed Kamal wrote: > Anyway, the most important message in this thread, should be that it's > important to start gathering information about what DE our user base > prefers! Perhaps, a checkbox "I prefer KDE"/"I prefer Gnome" besides the > F7 download links, should provide enough clicks for a statistical meaning. Perhaps you can use the energy for evangelism into contributing? Lots of packages are waiting for review. We need a desktop guide for KDE users and no one has stepped up to do it. Rahul From ville.skytta at iki.fi Sun May 6 07:01:31 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 6 May 2007 10:01:31 +0300 Subject: buildNotification fail on koji In-Reply-To: <463C324D.3030009@gmx.net> References: <463C324D.3030009@gmx.net> Message-ID: <200705061001.31540.ville.skytta@iki.fi> On Saturday 05 May 2007, Frank B?ttner wrote: > When I build one of my packages, the build self will work, but the > notification of it will fail. Ditto. Looks like koji's build notification sender doesn't deal with non-ASCII properly. In these cases our non-ASCII surnames are probably the things triggering the bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239182 From frank-buettner at gmx.net Sun May 6 07:06:13 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 06 May 2007 09:06:13 +0200 Subject: buildNotification fail on koji In-Reply-To: <200705061001.31540.ville.skytta@iki.fi> References: <463C324D.3030009@gmx.net> <200705061001.31540.ville.skytta@iki.fi> Message-ID: <463D7E65.6040804@gmx.net> Ville Skytt? schrieb: > On Saturday 05 May 2007, Frank B?ttner wrote: >> When I build one of my packages, the build self will work, but the >> notification of it will fail. > > Ditto. Looks like koji's build notification sender doesn't deal with > non-ASCII properly. In these cases our non-ASCII surnames are probably the > things triggering the bug. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239182 > Yes, I have add me to the bug. -------------- 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 sundaram at fedoraproject.org Sun May 6 08:10:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 06 May 2007 13:40:41 +0530 Subject: Fedora Extras Package Build Report 2007-05-05 In-Reply-To: <20070505115145.BAF36152131@buildsys.fedoraproject.org> References: <20070505115145.BAF36152131@buildsys.fedoraproject.org> Message-ID: <463D8D81.40300@fedoraproject.org> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 6: 27 > > NEW autodownloader-0.2.0-1.fc6 > dstat-0.6.6-1.fc6 > gscan2pdf-0.9.9-3.fc6 > gtk+extra-2.1.1-4.fc6 > koji-1.1-2.fc6 > NEW ocaml-SDL-0.7.2-6.fc6 > NEW perl-Config-Any-0.07-4.fc6 > perl-Data-Alias-1.04-1.fc6 > NEW perl-Data-Visitor-0.05-2.fc6 > NEW perl-Declare-Constraints-Simple-0.03-2.fc6 > NEW perl-Email-MIME-Creator-1.453-1.fc6 > NEW perl-File-Modified-0.07-4.fc6 > perl-Moose-0.21-1.fc6 > NEW perl-MooseX-Getopt-0.03-2.fc6 > NEW perl-PDF-API2-0.60-3.fc6 > NEW perl-Text-SimpleTable-0.03-2.fc6 > NEW perl-YAML-Syck-0.82-2.fc6 > puppet-0.22.4-1.fc6 > NEW python-BeautifulSoup-3.0.4-1.fc6 > NEW python-mecab-0.95-3.fc6 > NEW qsf-1.2.6-2.fc6 > rrdtool-1.2.23-3.fc6 > NEW ruby-mecab-0.95-4.fc6 > scanbuttond-0.2.3-10.fc6 > smb4k-0.8.3-1.fc6 > transmission-0.72-1.fc6 > wine-0.9.36-2.fc6 Can the short description from the spec file be added to the NEW packages in this report? It would be useful to know what some of these packages do in a quick glance. Rahul From dwmw2 at infradead.org Sun May 6 08:24:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 May 2007 09:24:33 +0100 Subject: What does package 'maintenance' mean? In-Reply-To: <463D1CC2.8000204@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> Message-ID: <1178439873.17680.104.camel@shinybook.infradead.org> On Sat, 2007-05-05 at 18:09 -0600, Jonathan Steffan wrote: > David Woodhouse wrote: > > So? Surely it's the r?le of the Fedora package maintainer to _make_ it > > work with Fedora? Is the package maintainer AWOL? > > I'm not AWOL and I don't think it is my job to fix upstream code. > Ok, I will state yet again; This is not a packaging issue. I appreciate, having looked at the references you provided, that fixing this would require a 'fair bit of work' and that you're a volunteer; it's not unreasonable that you haven't done it all by yourself within the last year -- I'm not suggesting otherwise. But let's address the _general_ case (and I've changed the subject accordingly to avoid that specific topic behind). I believe very strongly that it _is_ the package maintainer's job to work with upstream code to make it work with Fedora, and this kind of thing _is_ a packaging issue. There's a reason we have Fedora package maintainers instead of just automatically pulling in upstream tarballs and building them with rpmbuild -ta. It's because the r?le of the package maintainer is to make the package a _part_ of Fedora -- that's what makes Fedora a coherent distribution and not just a semi-random collection of packages. That means both local modifications and working with upstream where necessary -- not just to ensure that the package is configured properly for Fedora, but also that it _works_ properly as a Fedora package -- that IPv6 support works, that it works with exec-shield and SElinux, that it builds and works on all supported architectures, and most importantly that it builds and works with the other versions of software which are included in Fedora. In many of the examples there, there are resources available to assist package maintainers -- people with experience of particular languages or architectures, SElinux, IPv6, etc. But it _is_ the job of the package maintainer to ensure that the package actually works as part of Fedora -- asking for help where it's needed, by all means, but taking charge of the process and working with upstream to make it happen. I really don't like to think what would happen if our kernel, gcc, glibc and other package maintainers all suddenly declared that their job was just to package what's upstream and not guide its development. -- dwmw2 From drago01 at gmail.com Sun May 6 09:09:31 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 06 May 2007 11:09:31 +0200 Subject: Selinux and package guidelines In-Reply-To: <1178439873.17680.104.camel@shinybook.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> Message-ID: <463D9B4B.2080407@gmail.com> David Woodhouse wrote: > [...] > *SElinux*, > [..] thx for mentioning this I suggest that any package that create avcs should not pass a review. We have suchs packages in extras and nothing in the review process takes care of selinux integration which is wrong. From dwmw2 at infradead.org Sun May 6 10:06:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 May 2007 11:06:34 +0100 Subject: Selinux and package guidelines In-Reply-To: <463D9B4B.2080407@gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> Message-ID: <1178445996.17680.139.camel@shinybook.infradead.org> On Sun, 2007-05-06 at 11:09 +0200, dragoran wrote: > thx for mentioning this I suggest that any package that create avcs > should not pass a review. We have suchs packages in extras and nothing > in the review process takes care of selinux integration which is wrong. Yes, that makes sense. Although the SElinux experts do a great job of cleaning up after us, we should strive to ensure that package maintainers take responsibility for their own packages rather than _just_ dumping the load onto others. -- dwmw2 From drago01 at gmail.com Sun May 6 10:18:00 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 06 May 2007 12:18:00 +0200 Subject: Selinux and package guidelines In-Reply-To: <1178445996.17680.139.camel@shinybook.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> Message-ID: <463DAB58.6060205@gmail.com> David Woodhouse wrote: > On Sun, 2007-05-06 at 11:09 +0200, dragoran wrote: > >> thx for mentioning this I suggest that any package that create avcs >> should not pass a review. We have suchs packages in extras and nothing >> in the review process takes care of selinux integration which is wrong. >> > > Yes, that makes sense. Although the SElinux experts do a great job of > cleaning up after us, we should strive to ensure that package > maintainers take responsibility for their own packages rather than > _just_ dumping the load onto others. > > +1 but it would be better to clean up before aproving a package (if a selinux expert is needed cc one in the review request) we should do something like "works with selinux enforcing ->no please fix first" during the review From dwmw2 at infradead.org Sun May 6 10:20:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 May 2007 11:20:17 +0100 Subject: Selinux and package guidelines In-Reply-To: <463DAB58.6060205@gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463DAB58.6060205@gmail.com> Message-ID: <1178446817.11851.80.camel@pmac.infradead.org> On Sun, 2007-05-06 at 12:18 +0200, dragoran wrote: > but it would be better to clean up before aproving a package (if a > selinux expert is needed cc one in the review request) > we should do something like "works with selinux enforcing ->no please > fix first" during the review Absolutely. -- dwmw2 From wolfy at nobugconsulting.ro Sun May 6 11:25:37 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 06 May 2007 14:25:37 +0300 Subject: Selinux and package guidelines In-Reply-To: <1178446817.11851.80.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463DAB58.6060205@gmail.com> <1178446817.11851.80.camel@pmac.infradead.org> Message-ID: <463DBB31.9040200@nobugconsulting.ro> On 05/06/2007 01:20 PM, David Woodhouse wrote: > On Sun, 2007-05-06 at 12:18 +0200, dragoran wrote: > >> but it would be better to clean up before aproving a package (if a >> selinux expert is needed cc one in the review request) >> we should do something like "works with selinux enforcing ->no please >> fix first" during the review >> > > Absolutely. > > +1. I suggest adding this to packaging and review guidelines lonely "struggling to have OpenVPN from EPEL5 functional in selinux enforcing mode" wolf From Axel.Thimm at ATrpms.net Sun May 6 11:33:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 6 May 2007 13:33:35 +0200 Subject: Kernel compliation errors In-Reply-To: <200705060122.15508.lightsolphoenix@gmail.com> References: <200705052053.00032.lightsolphoenix@gmail.com> <200705052316.15218.lightsolphoenix@gmail.com> <1178424454.13686.5.camel@localhost.localdomain> <200705060122.15508.lightsolphoenix@gmail.com> Message-ID: <20070506113335.GD481@neu.nirvana> On Sun, May 06, 2007 at 01:22:14AM -0400, Kelly wrote: > On Sunday, May 06, 2007 12:07 am Sean Stangl wrote: > > On Sat, 2007-05-05 at 23:16 -0400, Kelly wrote: > > > Kelly wrote: > > > BTW, I noticed that I'm also getting these errors from ndiswrapper, most > > > of the ALSA sound drivers, and just about every driver that doesn't come > > > with the Fedora default setup. > > > > Have you verified that the modules are building against the sources for > > the kernel that you're running, and not against something else (Check > > the terminal output of make)? I'm betting that this isn't some error > > within Fedora, namely since I've never heard of this issue previously, > > but if it turns out that kernel-devel has been updated incorrectly for > > your architecture, that would be good to check. > > > > -Sean Stangl > > In this case, not only am I getting the errors from modules I built, but also > modules I've downloaded through ATRPMS and modules automated through DKMS. How do these errors look like? Maybe i586 vs i686 mismatches? Please post the exact output of the errors. > When I first started getting the errors, I went and double-checked that the > version & arch numbers were the same, so that's not the problem. The only case known to me when ATrpms' modules are involved is the i586/i686 mismatch explained here: http://fedoraproject.org/wiki/Bugs/FC6Common#head-e0676100ebd965b92fbaa7111097983a3822f143 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From naheemzaffar at gmail.com Sun May 6 16:28:43 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 6 May 2007 17:28:43 +0100 Subject: Networking regression? Message-ID: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> Before I file a bug for this I just want to confirm it is a real bug. I am an NTL/VirginMedia internet user. Since FC2 I have been able to connect to the network via dhcp. Since atleast FC6 (I think also FC5) Network Manager hasdetected the network automatically. It is an ethernet connection. Under Test 4 it is not working. The network settings do have an adaptor is detected, but it gives some sort of error message. DHCP does not find the internet. nor does NetworkManager. I used the default Live CD to test. Also installed it to the HDD with no change, Is there anything I am missing? What info will I need to give for a useful bug report? From mschwendt.tmp0701.nospam at arcor.de Sun May 6 16:43:22 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 May 2007 18:43:22 +0200 Subject: Fedora Extras Package Build Report 2007-05-05 In-Reply-To: <463D8D81.40300@fedoraproject.org> References: <20070505115145.BAF36152131@buildsys.fedoraproject.org> <463D8D81.40300@fedoraproject.org> Message-ID: <20070506184322.53bbeab9.mschwendt.tmp0701.nospam@arcor.de> On Sun, 06 May 2007 13:40:41 +0530, Rahul Sundaram wrote: > Can the short description from the spec file be added to the NEW > packages in this report? It would be useful to know what some of these > packages do in a quick glance. Code to do that is there now. But the entire report could need some reformatting to look more pretty. From buildsys at fedoraproject.org Sun May 6 17:10:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 6 May 2007 13:10:18 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-06 Message-ID: <20070506171018.600B8152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 23 asymptote-1.27-1.fc6 bsd-games-2.17-17.fc6 cacti-0.8.6j-1.fc6 cups-pdf-2.4.6-1.fc6 NEW freetennis-0.4.8-5.fc6 : Tennis simulation game NEW goocanvas-0.6-2.fc6 : A new canvas widget for GTK+ that uses cairo for drawing NEW libopenraw-0.0.2-5.fc6 : Decode camera RAW files NEW ocaml-camlimages-2.2.0-7.fc6 : OCaml image processing library pan-0.128-1.fc6 NEW perl-Email-Reply-1.201-3.fc6 : Reply to an email message perl-JSON-1.12-1.fc6 NEW perl-Math-Vec-0.04-2.fc6 : Perl Math::Vec module perl-Module-ScanDeps-0.74-1.fc6 NEW perl-Net-IPv4Addr-0.10-2.fc6 : Perl extension for manipulating IPv4 addresses perl-POE-Component-IRC-5.29-1.fc6 perl-Test-Warn-0.10-1.fc6 php-pear-MDB2-2.4.1-1.fc6 php-pear-MDB2-Driver-mysql-1.4.1-1.fc6 NEW pipepanic-0.1.3-2.fc6 : A pipe connecting game NEW postr-0.5-3.fc6 : Flickr uploader python-kaa-metadata-0.6.1-4.fc6 NEW scratchpad-0.3.0-3.fc6 : Spatial text editor for the GNOME desktop vdr-femon-1.1.2-1.fc6 Packages built and released for Fedora Extras 5: 12 cacti-0.8.6j-1.fc5 cups-pdf-2.4.6-1.fc5 NEW perl-Email-Reply-1.201-3.fc5 : Reply to an email message perl-JSON-1.12-1.fc5 NEW perl-Math-Vec-0.04-2.fc5 : Perl Math::Vec module perl-Module-ScanDeps-0.74-1.fc5 NEW perl-Net-IPv4Addr-0.10-2.fc5 : Perl extension for manipulating IPv4 addresses perl-POE-Component-IRC-5.29-1.fc5 perl-Test-Warn-0.10-1.fc5 php-pear-MDB2-2.4.1-1.fc5 php-pear-MDB2-Driver-mysql-1.4.1-1.fc5 NEW pipepanic-0.1.3-2.fc5 : A pipe connecting game Changes in Fedora Extras 6: asymptote-1.27-1.fc6 -------------------- * Sat May 05 2007 Jose Pedro Oliveira - 1.27-1 - Update to 1.27. * Wed Apr 25 2007 Jose Pedro Oliveira - 1.26-1 - Update to 1.26. * Tue Apr 10 2007 Jose Pedro Oliveira - 1.25-1 - Update to 1.25. bsd-games-2.17-17.fc6 --------------------- * Tue May 01 2007 Wart 2.17-17 - Rename tetris to avoid legal quandries - Patch to add extern "C" block to prevent c++ compiler error. cacti-0.8.6j-1.fc6 ------------------ * Sat May 05 2007 Mike McGrath - 0.8.6j-5 - Upstream released new version cups-pdf-2.4.6-1.fc6 -------------------- * Sun May 06 2007 Remi Collet 2.4.6-1 - update to 2.4.6 * Sun Apr 08 2007 Remi Collet 2.4.5-1 - update to 2.4.5 freetennis-0.4.8-5.fc6 ---------------------- * Sun May 06 2007 Nigel Jones 0.4.8-5 - Add missing BuildRequires (SDL_ttf-devel) * Fri May 04 2007 Nigel Jones 0.4.8-4 - Add SportsGame to .desktop file - Correct source URL * Fri May 04 2007 Nigel Jones 0.4.8-3 - Change builddep to ocaml-camlimages * Thu May 03 2007 Nigel Jones 0.4.8-2 - Add freetennis.png and alter freetennis.desktop to show icon - Change builddep to ocaml-SDL-devel * Tue Apr 10 2007 Nigel Jones 0.4.8-1 - Initial spec file goocanvas-0.6-2.fc6 ------------------- * Sat May 05 2007 Bernard Johnson - 0.6-2 - bump for incorrect tag in buildsys libopenraw-0.0.2-5.fc6 ---------------------- * Thu May 03 2007 Trond Danielsen - 0.0.2-5 - Added unowned directory to list of files. - Changed license from GPL to LGPL. * Wed May 02 2007 Trond Danielsen - 0.0.2-4 - Moved gui components to a separate package. * Tue May 01 2007 Trond Danielsen - 0.0.2-3 - Added missing BuildRequirement. * Mon Apr 30 2007 Trond Danielsen - 0.0.2-2 - Added missing BuildRequirement. * Sun Apr 29 2007 Trond Danielsen - 0.0.2-1 - Inital version. ocaml-camlimages-2.2.0-7.fc6 ---------------------------- * Fri May 04 2007 Nigel Jones 2.2.0-7 - Change to Makefile patch to move .so files to stublibs - Rename to ocaml-camlimages - Other changes per review * Thu May 03 2007 Nigel Jones 2.2.0-6 - Include .*a files just to make sure * Thu May 03 2007 Nigel Jones 2.2.0-5 - Revert -4 changes - Remove excludedirs patch, replace with a sed - Provide html documentation generated from running ocaml-ocamldoc * Thu Apr 26 2007 Nigel Jones 2.2.0-4 - Add Provides: camlimages-static, and LICENSE to -devel docs * Thu Apr 12 2007 Nigel Jones 2.2.0-3 - Remove .a & .o files * Wed Apr 11 2007 Nigel Jones 2.2.0-2 - Add missing dependencies * Tue Apr 10 2007 Nigel Jones 2.2.0-1 - Initial spec file pan-0.128-1.fc6 --------------- * Sun May 06 2007 Alexander Dalloz - 1:0.128-1 - Update to 0.128 * Sat Apr 14 2007 Alexander Dalloz - 1:0.127-1 - Update to 0.127 perl-Email-Reply-1.201-3.fc6 ---------------------------- * Fri May 04 2007 Tom "spot" Callaway - 1.201-3 - fix missing BR * Sun Apr 29 2007 Tom "spot" Callaway - 1.201-2 - fix LICENSE Warning on build - add missing Test BR perl-JSON-1.12-1.fc6 -------------------- * Fri May 04 2007 Chris Weyl 1.12-1 - update to 1.12 - add t/ to %doc * Wed Apr 25 2007 Chris Weyl 1.11-2 - bump * Tue Apr 24 2007 Chris Weyl 1.11-1 - update to 1.11 * Wed Apr 18 2007 Chris Weyl 1.10-1 - Specfile autogenerated by cpanspec 1.69.1. perl-Math-Vec-0.04-2.fc6 ------------------------ * Fri May 04 2007 Roozbeh Pournader - 0.04-2 - Packaging improvements (use more proper license tag, use tarball with preserved timestamp, remove direct BuildRequires on perl, expand description, enable pod tests) by Bernard Johnson * Mon Apr 16 2007 Roozbeh Pournader - 0.04-1 - First package perl-Module-ScanDeps-0.74-1.fc6 ------------------------------- * Sat May 05 2007 Jose Pedro Oliveira - 0.74-1 - Update to 0.74. * Sat Mar 31 2007 Jose Pedro Oliveira - 0.73-1 - Update to 0.73. perl-Net-IPv4Addr-0.10-2.fc6 ---------------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 - Add missing build dependencies - Fix License * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 - Initial build perl-POE-Component-IRC-5.29-1.fc6 --------------------------------- * Sat May 05 2007 Chris Weyl 5.29-1 - update to 5.29 * Wed May 02 2007 Chris Weyl 5.28-1 - update to 5.28 * Mon Apr 30 2007 Chris Weyl 5.26-1 - update to 5.26 - include t/ in %doc * Sat Apr 21 2007 Chris Weyl 5.24-1 - update to 5.24 - additional splittage BR's - Additional BR's to handle new tests, ipv6 functionality, etc perl-Test-Warn-0.10-1.fc6 ------------------------- * Sat May 05 2007 Jose Pedro Oliveira - 0.10-1 - Update to 0.10. * Sun Mar 18 2007 Jose Pedro Oliveira - 0.09-1 - Update to 0.09. - New upstream maintainer. - New BR: perl(Test::Pod). php-pear-MDB2-2.4.1-1.fc6 ------------------------- * Sat May 05 2007 Christopher Stone 2.4.1-1 - Upstream sync * Tue Mar 13 2007 Christopher Stone 2.4.0-1 - Upstream sync php-pear-MDB2-Driver-mysql-1.4.1-1.fc6 -------------------------------------- * Sat May 05 2007 Christopher Stone 1.4.1-1 - Upstream sync * Tue Mar 13 2007 Christopher Stone 1.4.0-1 - Upstream sync pipepanic-0.1.3-2.fc6 --------------------- * Wed May 02 2007 Andrea Musuruane 0.1.3-2.fc6 - Fixed package ownership of its datadir - Changed description - Added a patch by Hans de Goede to set a window title and icon * Tue Apr 10 2007 Andrea Musuruane 0.1.3-1.fc6 - Initial release postr-0.5-3.fc6 --------------- * Thu May 03 2007 Trond Danielsen - 0.5-3 - Added missing hicolor-icon-theme requirement. * Wed May 02 2007 Trond Danielsen - 0.5-2 - Backported icons from development branch of Postr. python-kaa-metadata-0.6.1-4.fc6 ------------------------------- * Tue May 01 2007 kwizart < kwizart at gmail.com > - 0.6.1-4 - Fix Obsolete also for mmpython 0.4.10 * Sat Apr 21 2007 kwizart < kwizart at gmail.com > - 0.6.1-3 - Add missing Requires for python packages * Fri Apr 20 2007 kwizart < kwizart at gmail.com > - 0.6.1-2 - Obsolete/provides mmpython version 0.4.10 * Wed Apr 18 2007 kwizart < kwizart at gmail.com > - 0.6.1-1 - Update to 0.6.1 scratchpad-0.3.0-3.fc6 ---------------------- * Thu May 03 2007 Sindre Pedersen Bj?rdal - 0.3.0-3 - Add patch for Hidden=true on .desktop-file * Tue May 01 2007 Sindre Pedersen Bj?rdal - 0.3.0-2 - Add NEWS file - Fix broken url in Source vdr-femon-1.1.2-1.fc6 --------------------- * Thu May 03 2007 Ville Skytt? - 1.1.2-1 - 1.1.2. * Tue Jan 09 2007 Ville Skytt? - 1.1.1-1 - 1.1.1. Changes in Fedora Extras 5: cacti-0.8.6j-1.fc5 ------------------ * Sat May 05 2007 Mike McGrath - 0.8.6j-5 - Upstream released new version cups-pdf-2.4.6-1.fc5 -------------------- * Sun May 06 2007 Remi Collet 2.4.6-1 - update to 2.4.6 * Sun Apr 08 2007 Remi Collet 2.4.5-1 - update to 2.4.5 perl-Email-Reply-1.201-3.fc5 ---------------------------- * Fri May 04 2007 Tom "spot" Callaway - 1.201-3 - fix missing BR * Sun Apr 29 2007 Tom "spot" Callaway - 1.201-2 - fix LICENSE Warning on build - add missing Test BR perl-JSON-1.12-1.fc5 -------------------- * Fri May 04 2007 Chris Weyl 1.12-1 - update to 1.12 - add t/ to %doc * Wed Apr 25 2007 Chris Weyl 1.11-2 - bump * Tue Apr 24 2007 Chris Weyl 1.11-1 - update to 1.11 * Wed Apr 18 2007 Chris Weyl 1.10-1 - Specfile autogenerated by cpanspec 1.69.1. perl-Math-Vec-0.04-2.fc5 ------------------------ * Fri May 04 2007 Roozbeh Pournader - 0.04-2 - Packaging improvements (use more proper license tag, use tarball with preserved timestamp, remove direct BuildRequires on perl, expand description, enable pod tests) by Bernard Johnson * Mon Apr 16 2007 Roozbeh Pournader - 0.04-1 - First package perl-Module-ScanDeps-0.74-1.fc5 ------------------------------- * Sat May 05 2007 Jose Pedro Oliveira - 0.74-1 - Update to 0.74. * Sat Mar 31 2007 Jose Pedro Oliveira - 0.73-1 - Update to 0.73. perl-Net-IPv4Addr-0.10-2.fc5 ---------------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 - Add missing build dependencies - Fix License * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 - Initial build perl-POE-Component-IRC-5.29-1.fc5 --------------------------------- * Sat May 05 2007 Chris Weyl 5.29-1 - update to 5.29 * Wed May 02 2007 Chris Weyl 5.28-1 - update to 5.28 * Mon Apr 30 2007 Chris Weyl 5.26-1 - update to 5.26 - include t/ in %doc * Sat Apr 21 2007 Chris Weyl 5.24-1 - update to 5.24 - additional splittage BR's - Additional BR's to handle new tests, ipv6 functionality, etc perl-Test-Warn-0.10-1.fc5 ------------------------- * Sat May 05 2007 Jose Pedro Oliveira - 0.10-1 - Update to 0.10. * Sun Mar 18 2007 Jose Pedro Oliveira - 0.09-1 - Update to 0.09. - New upstream maintainer. - New BR: perl(Test::Pod). * Sun Sep 10 2006 Jose Pedro Oliveira - 0.08-4 - Rebuild for FC6. php-pear-MDB2-2.4.1-1.fc5 ------------------------- * Sat May 05 2007 Christopher Stone 2.4.1-1 - Upstream sync * Tue Mar 13 2007 Christopher Stone 2.4.0-1 - Upstream sync php-pear-MDB2-Driver-mysql-1.4.1-1.fc5 -------------------------------------- * Sat May 05 2007 Christopher Stone 1.4.1-1 - Upstream sync * Tue Mar 13 2007 Christopher Stone 1.4.0-1 - Upstream sync pipepanic-0.1.3-2.fc5 --------------------- * Wed May 02 2007 Andrea Musuruane 0.1.3-2.fc5 - Fixed package ownership of its datadir - Changed description - Added a patch by Hans de Goede to set a window title and icon * Tue Apr 10 2007 Andrea Musuruane 0.1.3-1.fc5 - Initial release For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lamont at gurulabs.com Sun May 6 18:33:20 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 6 May 2007 12:33:20 -0600 Subject: KDE user stats In-Reply-To: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> Message-ID: <200705061233.25384.lamont@gurulabs.com> On Friday 04 May 2007 05:42pm, Ahmed Kamal wrote: > openSuse has posted the results of a survey spanning 27,462 users. An > interesting piece of info, was that the number of KDE users was over 71%, > with Gnome around 22%. I'm not trying to start any kind of flame wars, and > I know most opensuse users are on that distro for KDE. Still I think we > should use a mechanism to gather desktop environement popularity > information for Fedora. If that survey is any indication, the KDE "spin" or > whatever they call it today, could perhaps use more love. I'm would almost be willing to bet (except that I never gamble with my money:) ) that such a survey of Red Hat/Redora users would show numbers the other way around. In my experience, the vast majority of users seem to prefer one desktop environment over the others simply because that's what they became used to, They became used to GNOME on Red Hat because that's what Red Hat (and Fedora) default to. For SUSE users, KDE is not surprising. In other words, most users usually have zero technical reason for choosing one desktop environment over the others. The exception to that has been the real or imaginary perception that KDE on Red Hat isn't built the way KDE could be because Red Hat "doesn't like KDE" or whatever. Personally, I've experienced that myself and have had to rebuild packages to turn on the building of apps that the Red Hat/Fedora packages have disabled for no apparently good reason (though, most of that is worked out now and I haven't had the need to do this for those reasons in a long time). In almost all cases, I simply re-enabled the building of an app and everything worked without any further changes to the spec, or I simple removed some "rm" command(s) that deleted apps before %files could get hold of them, but still wasted time compiling them (and they worked just fine). I'm not suggesting that any of this was done to intentionally "cripple KDE on Red Hat to make GNOME look better" or anything like that. I'm sure that all of these kinds of incidents were because there were too many things for the very few people who dealt with KDE packages at Red Hat to have time to do things "right". Anyway, I'm glad to see more love going into KDE on Fedora. Open source is about choice and by that I mean my choice (as an end user), not Red Hat's choice, not SUSE's, not Fedora's, etc. This is what makes users love a distro; when they can choose to do things the way they want to. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun May 6 18:55:45 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 May 2007 20:55:45 +0200 Subject: Selinux and package guidelines In-Reply-To: <1178445996.17680.139.camel@shinybook.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> Message-ID: <463E24B1.6040407@hhs.nl> David Woodhouse wrote: > On Sun, 2007-05-06 at 11:09 +0200, dragoran wrote: >> thx for mentioning this I suggest that any package that create avcs >> should not pass a review. We have suchs packages in extras and nothing >> in the review process takes care of selinux integration which is wrong. > > Yes, that makes sense. Although the SElinux experts do a great job of > cleaning up after us, we should strive to ensure that package > maintainers take responsibility for their own packages rather than > _just_ dumping the load onto others. > David, I'm getting very tired of these generalism's of you. Most of us are not just volunteers, but even hard working volunteers. Terms like packaging monkeys, and dumping, are not nice descriptions of, and show no respect for, all the hard working people behind Fedora. I for one have made sure all my packages work well with selinux targeted policy in enforcing mode, and I've written patches for other peoples packages too. I've even written for example textrel patches for SDL, but the @redhat.com maintainer doesn't want to apply them. So in the future please refrain from such generalisms, an show some respect, or even better show others the respect you expect them to show for you. Regards, Hans From rubin at xs4all.nl Sun May 6 18:43:08 2007 From: rubin at xs4all.nl (Rubin) Date: Sun, 06 May 2007 20:43:08 +0200 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <20070506171018.600B8152131@buildsys.fedoraproject.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> Message-ID: <463E21BC.9090409@xs4all.nl> Hi people, I have searched the mailinglist back to 25-01-2007 using the keywords "public folder", "templates folder", "downloads folder" "creating directories", "creating folders", "nautilus directories" and a few other combinations and I am a little surprised I didn't find any previous posting about the following (ie. I tried to avoid getting a re-discussion about this): Why does gnome/nautilus/vfs(?) create three directories in my home directory by default (using F7t4)? I _really_ dislike this behaviour. I can't find any knobs that would allow me to turn this off or _at least_ allow me to change the folders they point to (Downloads, Public and Templates). I don't know about anyone else but I find it hard to imagine that anyone actually likes this behaviour; after all, who is not annoyed like hell about directories like "My eBooks", "My Pictures", "My Music", etc that incessantly re-create themselves in your home directory on some other operating system whose name I shall not mention? It is _my_ home directory, not some scratchpad for badly designed software, excuse the venom. So, long story short: If it has been discussed before, my humble apologies. If it has to be in there due to upstream changes, then where are the knobs? Can I turn it off? Grtz, Rubin. buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras 6: 23 > > asymptote-1.27-1.fc6 > bsd-games-2.17-17.fc6 > cacti-0.8.6j-1.fc6 > cups-pdf-2.4.6-1.fc6 > NEW freetennis-0.4.8-5.fc6 : Tennis simulation game > NEW goocanvas-0.6-2.fc6 : A new canvas widget for GTK+ that uses cairo for drawing > NEW libopenraw-0.0.2-5.fc6 : Decode camera RAW files > NEW ocaml-camlimages-2.2.0-7.fc6 : OCaml image processing library > pan-0.128-1.fc6 > NEW perl-Email-Reply-1.201-3.fc6 : Reply to an email message > perl-JSON-1.12-1.fc6 > NEW perl-Math-Vec-0.04-2.fc6 : Perl Math::Vec module > perl-Module-ScanDeps-0.74-1.fc6 > NEW perl-Net-IPv4Addr-0.10-2.fc6 : Perl extension for manipulating IPv4 addresses > perl-POE-Component-IRC-5.29-1.fc6 > perl-Test-Warn-0.10-1.fc6 > php-pear-MDB2-2.4.1-1.fc6 > php-pear-MDB2-Driver-mysql-1.4.1-1.fc6 > NEW pipepanic-0.1.3-2.fc6 : A pipe connecting game > NEW postr-0.5-3.fc6 : Flickr uploader > python-kaa-metadata-0.6.1-4.fc6 > NEW scratchpad-0.3.0-3.fc6 : Spatial text editor for the GNOME desktop > vdr-femon-1.1.2-1.fc6 > > > Packages built and released for Fedora Extras 5: 12 > > cacti-0.8.6j-1.fc5 > cups-pdf-2.4.6-1.fc5 > NEW perl-Email-Reply-1.201-3.fc5 : Reply to an email message > perl-JSON-1.12-1.fc5 > NEW perl-Math-Vec-0.04-2.fc5 : Perl Math::Vec module > perl-Module-ScanDeps-0.74-1.fc5 > NEW perl-Net-IPv4Addr-0.10-2.fc5 : Perl extension for manipulating IPv4 addresses > perl-POE-Component-IRC-5.29-1.fc5 > perl-Test-Warn-0.10-1.fc5 > php-pear-MDB2-2.4.1-1.fc5 > php-pear-MDB2-Driver-mysql-1.4.1-1.fc5 > NEW pipepanic-0.1.3-2.fc5 : A pipe connecting game > > > Changes in Fedora Extras 6: > > > asymptote-1.27-1.fc6 > -------------------- > * Sat May 05 2007 Jose Pedro Oliveira - 1.27-1 > - Update to 1.27. > > * Wed Apr 25 2007 Jose Pedro Oliveira - 1.26-1 > - Update to 1.26. > > * Tue Apr 10 2007 Jose Pedro Oliveira - 1.25-1 > - Update to 1.25. > > bsd-games-2.17-17.fc6 > --------------------- > * Tue May 01 2007 Wart 2.17-17 > - Rename tetris to avoid legal quandries > - Patch to add extern "C" block to prevent c++ compiler error. > > cacti-0.8.6j-1.fc6 > ------------------ > * Sat May 05 2007 Mike McGrath - 0.8.6j-5 > - Upstream released new version > > cups-pdf-2.4.6-1.fc6 > -------------------- > * Sun May 06 2007 Remi Collet 2.4.6-1 > - update to 2.4.6 > > * Sun Apr 08 2007 Remi Collet 2.4.5-1 > - update to 2.4.5 > > freetennis-0.4.8-5.fc6 > ---------------------- > * Sun May 06 2007 Nigel Jones 0.4.8-5 > - Add missing BuildRequires (SDL_ttf-devel) > > * Fri May 04 2007 Nigel Jones 0.4.8-4 > - Add SportsGame to .desktop file > - Correct source URL > > * Fri May 04 2007 Nigel Jones 0.4.8-3 > - Change builddep to ocaml-camlimages > > * Thu May 03 2007 Nigel Jones 0.4.8-2 > - Add freetennis.png and alter freetennis.desktop to show icon > - Change builddep to ocaml-SDL-devel > > * Tue Apr 10 2007 Nigel Jones 0.4.8-1 > - Initial spec file > > goocanvas-0.6-2.fc6 > ------------------- > * Sat May 05 2007 Bernard Johnson - 0.6-2 > - bump for incorrect tag in buildsys > > libopenraw-0.0.2-5.fc6 > ---------------------- > * Thu May 03 2007 Trond Danielsen - 0.0.2-5 > - Added unowned directory to list of files. > - Changed license from GPL to LGPL. > > * Wed May 02 2007 Trond Danielsen - 0.0.2-4 > - Moved gui components to a separate package. > > * Tue May 01 2007 Trond Danielsen - 0.0.2-3 > - Added missing BuildRequirement. > > * Mon Apr 30 2007 Trond Danielsen - 0.0.2-2 > - Added missing BuildRequirement. > > * Sun Apr 29 2007 Trond Danielsen - 0.0.2-1 > - Inital version. > > ocaml-camlimages-2.2.0-7.fc6 > ---------------------------- > * Fri May 04 2007 Nigel Jones 2.2.0-7 > - Change to Makefile patch to move .so files to stublibs > - Rename to ocaml-camlimages > - Other changes per review > > * Thu May 03 2007 Nigel Jones 2.2.0-6 > - Include .*a files just to make sure > > * Thu May 03 2007 Nigel Jones 2.2.0-5 > - Revert -4 changes > - Remove excludedirs patch, replace with a sed > - Provide html documentation generated from running ocaml-ocamldoc > > * Thu Apr 26 2007 Nigel Jones 2.2.0-4 > - Add Provides: camlimages-static, and LICENSE to -devel docs > > * Thu Apr 12 2007 Nigel Jones 2.2.0-3 > - Remove .a & .o files > > * Wed Apr 11 2007 Nigel Jones 2.2.0-2 > - Add missing dependencies > > * Tue Apr 10 2007 Nigel Jones 2.2.0-1 > - Initial spec file > > pan-0.128-1.fc6 > --------------- > * Sun May 06 2007 Alexander Dalloz - 1:0.128-1 > - Update to 0.128 > > * Sat Apr 14 2007 Alexander Dalloz - 1:0.127-1 > - Update to 0.127 > > perl-Email-Reply-1.201-3.fc6 > ---------------------------- > * Fri May 04 2007 Tom "spot" Callaway - 1.201-3 > - fix missing BR > > * Sun Apr 29 2007 Tom "spot" Callaway - 1.201-2 > - fix LICENSE Warning on build > - add missing Test BR > > perl-JSON-1.12-1.fc6 > -------------------- > * Fri May 04 2007 Chris Weyl 1.12-1 > - update to 1.12 > - add t/ to %doc > > * Wed Apr 25 2007 Chris Weyl 1.11-2 > - bump > > * Tue Apr 24 2007 Chris Weyl 1.11-1 > - update to 1.11 > > * Wed Apr 18 2007 Chris Weyl 1.10-1 > - Specfile autogenerated by cpanspec 1.69.1. > > perl-Math-Vec-0.04-2.fc6 > ------------------------ > * Fri May 04 2007 Roozbeh Pournader - 0.04-2 > - Packaging improvements (use more proper license tag, use tarball > with preserved timestamp, remove direct BuildRequires on perl, expand > description, enable pod tests) by Bernard Johnson > > * Mon Apr 16 2007 Roozbeh Pournader - 0.04-1 > - First package > > perl-Module-ScanDeps-0.74-1.fc6 > ------------------------------- > * Sat May 05 2007 Jose Pedro Oliveira - 0.74-1 > - Update to 0.74. > > * Sat Mar 31 2007 Jose Pedro Oliveira - 0.73-1 > - Update to 0.73. > > perl-Net-IPv4Addr-0.10-2.fc6 > ---------------------------- > * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 > - Add missing build dependencies > - Fix License > > * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 > - Initial build > > perl-POE-Component-IRC-5.29-1.fc6 > --------------------------------- > * Sat May 05 2007 Chris Weyl 5.29-1 > - update to 5.29 > > * Wed May 02 2007 Chris Weyl 5.28-1 > - update to 5.28 > > * Mon Apr 30 2007 Chris Weyl 5.26-1 > - update to 5.26 > - include t/ in %doc > > * Sat Apr 21 2007 Chris Weyl 5.24-1 > - update to 5.24 > - additional splittage BR's > - Additional BR's to handle new tests, ipv6 functionality, etc > > perl-Test-Warn-0.10-1.fc6 > ------------------------- > * Sat May 05 2007 Jose Pedro Oliveira - 0.10-1 > - Update to 0.10. > > * Sun Mar 18 2007 Jose Pedro Oliveira - 0.09-1 > - Update to 0.09. > - New upstream maintainer. > - New BR: perl(Test::Pod). > > php-pear-MDB2-2.4.1-1.fc6 > ------------------------- > * Sat May 05 2007 Christopher Stone 2.4.1-1 > - Upstream sync > > * Tue Mar 13 2007 Christopher Stone 2.4.0-1 > - Upstream sync > > php-pear-MDB2-Driver-mysql-1.4.1-1.fc6 > -------------------------------------- > * Sat May 05 2007 Christopher Stone 1.4.1-1 > - Upstream sync > > * Tue Mar 13 2007 Christopher Stone 1.4.0-1 > - Upstream sync > > pipepanic-0.1.3-2.fc6 > --------------------- > * Wed May 02 2007 Andrea Musuruane 0.1.3-2.fc6 > - Fixed package ownership of its datadir > - Changed description > - Added a patch by Hans de Goede to set a window title and icon > > * Tue Apr 10 2007 Andrea Musuruane 0.1.3-1.fc6 > - Initial release > > postr-0.5-3.fc6 > --------------- > * Thu May 03 2007 Trond Danielsen - 0.5-3 > - Added missing hicolor-icon-theme requirement. > > * Wed May 02 2007 Trond Danielsen - 0.5-2 > - Backported icons from development branch of Postr. > > python-kaa-metadata-0.6.1-4.fc6 > ------------------------------- > * Tue May 01 2007 kwizart < kwizart at gmail.com > - 0.6.1-4 > - Fix Obsolete also for mmpython 0.4.10 > > * Sat Apr 21 2007 kwizart < kwizart at gmail.com > - 0.6.1-3 > - Add missing Requires for python packages > > * Fri Apr 20 2007 kwizart < kwizart at gmail.com > - 0.6.1-2 > - Obsolete/provides mmpython version 0.4.10 > > * Wed Apr 18 2007 kwizart < kwizart at gmail.com > - 0.6.1-1 > - Update to 0.6.1 > > scratchpad-0.3.0-3.fc6 > ---------------------- > * Thu May 03 2007 Sindre Pedersen Bj?rdal - 0.3.0-3 > - Add patch for Hidden=true on .desktop-file > > * Tue May 01 2007 Sindre Pedersen Bj?rdal - 0.3.0-2 > - Add NEWS file > - Fix broken url in Source > > vdr-femon-1.1.2-1.fc6 > --------------------- > * Thu May 03 2007 Ville Skytt? - 1.1.2-1 > - 1.1.2. > > * Tue Jan 09 2007 Ville Skytt? - 1.1.1-1 > - 1.1.1. > > > Changes in Fedora Extras 5: > > > cacti-0.8.6j-1.fc5 > ------------------ > * Sat May 05 2007 Mike McGrath - 0.8.6j-5 > - Upstream released new version > > cups-pdf-2.4.6-1.fc5 > -------------------- > * Sun May 06 2007 Remi Collet 2.4.6-1 > - update to 2.4.6 > > * Sun Apr 08 2007 Remi Collet 2.4.5-1 > - update to 2.4.5 > > perl-Email-Reply-1.201-3.fc5 > ---------------------------- > * Fri May 04 2007 Tom "spot" Callaway - 1.201-3 > - fix missing BR > > * Sun Apr 29 2007 Tom "spot" Callaway - 1.201-2 > - fix LICENSE Warning on build > - add missing Test BR > > perl-JSON-1.12-1.fc5 > -------------------- > * Fri May 04 2007 Chris Weyl 1.12-1 > - update to 1.12 > - add t/ to %doc > > * Wed Apr 25 2007 Chris Weyl 1.11-2 > - bump > > * Tue Apr 24 2007 Chris Weyl 1.11-1 > - update to 1.11 > > * Wed Apr 18 2007 Chris Weyl 1.10-1 > - Specfile autogenerated by cpanspec 1.69.1. > > perl-Math-Vec-0.04-2.fc5 > ------------------------ > * Fri May 04 2007 Roozbeh Pournader - 0.04-2 > - Packaging improvements (use more proper license tag, use tarball > with preserved timestamp, remove direct BuildRequires on perl, expand > description, enable pod tests) by Bernard Johnson > > * Mon Apr 16 2007 Roozbeh Pournader - 0.04-1 > - First package > > perl-Module-ScanDeps-0.74-1.fc5 > ------------------------------- > * Sat May 05 2007 Jose Pedro Oliveira - 0.74-1 > - Update to 0.74. > > * Sat Mar 31 2007 Jose Pedro Oliveira - 0.73-1 > - Update to 0.73. > > perl-Net-IPv4Addr-0.10-2.fc5 > ---------------------------- > * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-2 > - Add missing build dependencies > - Fix License > > * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.10-1 > - Initial build > > perl-POE-Component-IRC-5.29-1.fc5 > --------------------------------- > * Sat May 05 2007 Chris Weyl 5.29-1 > - update to 5.29 > > * Wed May 02 2007 Chris Weyl 5.28-1 > - update to 5.28 > > * Mon Apr 30 2007 Chris Weyl 5.26-1 > - update to 5.26 > - include t/ in %doc > > * Sat Apr 21 2007 Chris Weyl 5.24-1 > - update to 5.24 > - additional splittage BR's > - Additional BR's to handle new tests, ipv6 functionality, etc > > perl-Test-Warn-0.10-1.fc5 > ------------------------- > * Sat May 05 2007 Jose Pedro Oliveira - 0.10-1 > - Update to 0.10. > > * Sun Mar 18 2007 Jose Pedro Oliveira - 0.09-1 > - Update to 0.09. > - New upstream maintainer. > - New BR: perl(Test::Pod). > > * Sun Sep 10 2006 Jose Pedro Oliveira - 0.08-4 > - Rebuild for FC6. > > php-pear-MDB2-2.4.1-1.fc5 > ------------------------- > * Sat May 05 2007 Christopher Stone 2.4.1-1 > - Upstream sync > > * Tue Mar 13 2007 Christopher Stone 2.4.0-1 > - Upstream sync > > php-pear-MDB2-Driver-mysql-1.4.1-1.fc5 > -------------------------------------- > * Sat May 05 2007 Christopher Stone 1.4.1-1 > - Upstream sync > > * Tue Mar 13 2007 Christopher Stone 1.4.0-1 > - Upstream sync > > pipepanic-0.1.3-2.fc5 > --------------------- > * Wed May 02 2007 Andrea Musuruane 0.1.3-2.fc5 > - Fixed package ownership of its datadir > - Changed description > - Added a patch by Hans de Goede to set a window title and icon > > * Tue Apr 10 2007 Andrea Musuruane 0.1.3-1.fc5 > - Initial release > > > > For more information about the built packages please see the repository > or the Fedora Info Feed: http://fedoraproject.org/infofeed/ > > From jkeating at redhat.com Sun May 6 18:42:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 May 2007 11:42:43 -0700 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <200705061142.44161.jkeating@redhat.com> On Sunday 06 May 2007 11:43:08 Rubin wrote: > So, long story short: If it has been discussed before, my humble > apologies. If it has to be in there due to upstream changes, then where > are the knobs? Can I turn it off? I do believe there was some discussion on the fedora-desktop-list. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From neugens at limasoftware.net Sun May 6 18:53:10 2007 From: neugens at limasoftware.net (Mario Torre) Date: Sun, 06 May 2007 20:53:10 +0200 Subject: Kernel compliation errors In-Reply-To: <20070506113335.GD481@neu.nirvana> References: <200705052053.00032.lightsolphoenix@gmail.com> <200705052316.15218.lightsolphoenix@gmail.com> <1178424454.13686.5.camel@localhost.localdomain> <200705060122.15508.lightsolphoenix@gmail.com> <20070506113335.GD481@neu.nirvana> Message-ID: <1178477590.3420.28.camel@nirvana.limasoftware.net> Il giorno dom, 06/05/2007 alle 13.33 +0200, Axel Thimm ha scritto: > How do these errors look like? Maybe i586 vs i686 mismatches? Please > post the exact output of the errors. Hello, I don't know if it helps, but I had problems with few drivers as well, for example compiling the alsa drivers and the vmware modules with the first 2.6.20 kernel update on FC6. The error for the alsa drivers was something like this: error: implicit declaration of function 'is_power_of_2' I've solved patching the drivers. In the case of vmware, I installed new vmware-any-any. The alsa drivers were downloaded by the personal page of Martin Stransky, so I think they are at least a bit tested and should work, but in my case I was not able to compile them. Maybe you have this same problem (but other than try to patch the single packages I don't know what else to tell, because I don't know if they were caused by some version mismatches or what)? Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From bpepple at fedoraproject.org Sun May 6 19:01:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 06 May 2007 15:01:24 -0400 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <200705061142.44161.jkeating@redhat.com> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <200705061142.44161.jkeating@redhat.com> Message-ID: <1178478084.5790.3.camel@lincoln> On Sun, 2007-05-06 at 11:42 -0700, Jesse Keating wrote: > On Sunday 06 May 2007 11:43:08 Rubin wrote: > > So, long story short: If it has been discussed before, my humble > > apologies. If it has to be in there due to upstream changes, then where > > are the knobs? Can I turn it off? > > I do believe there was some discussion on the fedora-desktop-list. Also, I remember a few blog entries at Fedora People & Planet GNOME about it. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Sun May 6 19:14:41 2007 From: opensource at till.name (Till Maas) Date: Sun, 06 May 2007 21:14:41 +0200 Subject: Selinux and package guidelines In-Reply-To: <463DAB58.6060205@gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463DAB58.6060205@gmail.com> Message-ID: <200705062114.42830.opensource@till.name> On So Mai 6 2007, dragoran wrote: > but it would be better to clean up before aproving a package (if a > selinux expert is needed cc one in the review request) > we should do something like "works with selinux enforcing ->no please > fix first" during the review Please update the documentation about selinux and packaging[1] first, currently, there is not much help to allow e.g. execmod for a file in a package. Without proper documentation, your demand seems not to be very wise to me. Also does rpm not support a packager very much to use selinux afaik. When one needs two extra files and more than 15 lines of scriptlets for only making some files "textrel_shlib_t", it is not much helpful. Imho something like %textrel_shlib_t /path/to/libpackage.so in %files should be enough, because it contains all the information that is needed (the lib should have textrel_shlib_t) and everything else can be automatically. Regards, Till [1] http://fedoraproject.org/wiki/PackagingDrafts/SELinux From lsof at nodata.co.uk Sun May 6 19:23:07 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 06 May 2007 21:23:07 +0200 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <1178479387.3549.11.camel@sb-home> Am Sonntag, den 06.05.2007, 20:43 +0200 schrieb Rubin: > So, long story short: If it has been discussed before, my humble > apologies. If it has to be in there due to upstream changes, then where > are the knobs? Can I turn it off? I agree. No app should create non dot files or folders in my home directory. It's my home directory, it doesn't belong to a program, it belongs to me. See here for the discussion: http://www.redhat.com/archives/fedora-devel-list/2007-March/msg00858.html From lsof at nodata.co.uk Sun May 6 19:23:49 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 06 May 2007 21:23:49 +0200 Subject: Networking regression? In-Reply-To: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> Message-ID: <1178479429.3549.13.camel@sb-home> Am Sonntag, den 06.05.2007, 17:28 +0100 schrieb Naheem Zaffar: > but it gives some sort of error message You need to give the error message. Also post the output from ifconfig -a From lightsolphoenix at gmail.com Sun May 6 19:41:47 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 6 May 2007 15:41:47 -0400 Subject: Kernel compliation errors In-Reply-To: <20070506113335.GD481@neu.nirvana> References: <200705052053.00032.lightsolphoenix@gmail.com> <200705060122.15508.lightsolphoenix@gmail.com> <20070506113335.GD481@neu.nirvana> Message-ID: <200705061541.48103.lightsolphoenix@gmail.com> On Sunday, May 06, 2007 7:33 am Axel Thimm wrote: > How do these errors look like? Maybe i586 vs i686 mismatches? Please > post the exact output of the errors. As I said, that's pretty much the first thing I checked. I've switched from the latest kernel (*48) to the previous kernel (*44) and now everything appears to be working. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From david at lovesunix.net Sun May 6 19:44:40 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 06 May 2007 21:44:40 +0200 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> On s?n, 2007-05-06 at 20:43 +0200, Rubin wrote: > Hi people, > > I have searched the mailinglist back to 25-01-2007 using the keywords > "public folder", "templates folder", "downloads folder" "creating > directories", "creating folders", "nautilus directories" and a few other > combinations and I am a little surprised I didn't find any previous > posting about the following (ie. I tried to avoid getting a > re-discussion about this): > > Why does gnome/nautilus/vfs(?) create three directories in my home > directory by default (using F7t4)? I _really_ dislike this behaviour. I > can't find any knobs that would allow me to turn this off or _at least_ > allow me to change the folders they point to (Downloads, Public and > Templates). > > I don't know about anyone else but I find it hard to imagine that anyone > actually likes this behaviour; after all, who is not annoyed like hell > about directories like "My eBooks", "My Pictures", "My Music", etc that > incessantly re-create themselves in your home directory on some other > operating system whose name I shall not mention? It is _my_ home > directory, not some scratchpad for badly designed software, excuse the > venom. > > So, long story short: If it has been discussed before, my humble > apologies. If it has to be in there due to upstream changes, then where > are the knobs? Can I turn it off? sounds like the xdg-user-dirs freedesktop.org spec implementation, one of the great new features in F7 - it provides per session translated directories. Great stuff, will likely be a blessed part of GNOME 2.20 at least a lot of the applications now have support for it. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun May 6 19:47:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 07 May 2007 01:17:30 +0530 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <1178479387.3549.11.camel@sb-home> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178479387.3549.11.camel@sb-home> Message-ID: <463E30D2.2060606@fedoraproject.org> nodata wrote: > Am Sonntag, den 06.05.2007, 20:43 +0200 schrieb Rubin: >> So, long story short: If it has been discussed before, my humble >> apologies. If it has to be in there due to upstream changes, then where >> are the knobs? Can I turn it off? > > I agree. No app should create non dot files or folders in my home directory. > > It's my home directory, it doesn't belong to a program, it belongs to me. You lost that capability long back when Desktop folder was created. It is configurable in ~.config/ Rahul From mclasen at redhat.com Sun May 6 20:32:10 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 06 May 2007 16:32:10 -0400 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <1178483530.3040.3.camel@localhost.localdomain> On Sun, 2007-05-06 at 20:43 +0200, Rubin wrote: > So, long story short: If it has been discussed before, my humble > apologies. If it has to be in there due to upstream changes, then where > are the knobs? Can I turn it off? Nautilus has nothing to do with creating the folders (unless you count the fact that the nautilus maintainer also wrote xdg-user-dirs, which is responsible for the creation of the directories). If you don't like the directories, simply remove them. They won't come back. If you want to change their names, look in ~/.config/user-dirs.dirs. Matthias From naheemzaffar at gmail.com Mon May 7 02:40:40 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 7 May 2007 03:40:40 +0100 Subject: Networking regression? In-Reply-To: <1178479429.3549.13.camel@sb-home> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> Message-ID: <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> I have filed the bug under NetworkManager (Probably wrong component...): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239254 The report contains the output of ifconfig -a (Both from FC6 and FC7Test4) My first post here was incorrect - the live cd did not detect an adapter. I thought it did. Either way FC6 detects the device during install. Just tested by re-installing FC6. Naheem On 06/05/07, nodata wrote: > Am Sonntag, den 06.05.2007, 17:28 +0100 schrieb Naheem Zaffar: > > but it gives some sort of error message > > You need to give the error message. > > Also post the output from > ifconfig -a > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rubin at xs4all.nl Mon May 7 07:37:32 2007 From: rubin at xs4all.nl (Rubin) Date: Mon, 7 May 2007 09:37:32 +0200 (CEST) Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <1178483530.3040.3.camel@localhost.localdomain> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178483530.3040.3.camel@localhost.localdomain> Message-ID: <10529.145.7.182.188.1178523452.squirrel@webmail.xs4all.nl> > On Sun, 2007-05-06 at 20:43 +0200, Rubin wrote: > >> So, long story short: If it has been discussed before, my humble >> apologies. If it has to be in there due to upstream changes, then where >> are the knobs? Can I turn it off? > > Nautilus has nothing to do with creating the folders (unless you count > the fact that the nautilus maintainer also wrote xdg-user-dirs, which is > responsible for the creation of the directories). > > If you don't like the directories, simply remove them. They won't come > back. If you want to change their names, look in > ~/.config/user-dirs.dirs. Actually, they are re-created. I've deleted them a couple of times already. However as I now know of a knob (~/.config/user-dirs.dirs) to twist, I'm sure I can tweak it to my liking. I still think this will upset people even though it may be something good/cool/handy/smart. People should at least be presented with something that tells them about it and ideally allows them to set the directories in question when creating a useraccount through the gui for example. Kind regards, Rubin. > > > Matthias > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kwade at redhat.com Mon May 7 08:29:56 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 07 May 2007 01:29:56 -0700 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <1178526596.4218.200.camel@erato.phig.org> On Sun, 2007-05-06 at 20:43 +0200, Rubin wrote: > Hi people, > > I have searched the mailinglist back to 25-01-2007 using the keywords > "public folder", "templates folder", "downloads folder" "creating > directories", "creating folders", "nautilus directories" and a few other > combinations and I am a little surprised I didn't find any previous > posting about the following (ie. I tried to avoid getting a > re-discussion about this): The reason is in the release notes for (at least) test4 http://fedoraproject.org/wiki/Docs/Beats/Desktop Sorry, only release notes source available (the Wiki), no direct link to the test4 notes, but you can find it locally at: file:///usr/share/doc/HTML/RELEASE-NOTES-en_US.html#sn-Desktop - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmy at tigress.co.uk Mon May 7 09:36:50 2007 From: rmy at tigress.co.uk (Ron Yorston) Date: Mon, 07 May 2007 10:36:50 +0100 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> Message-ID: <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> David Nielsen wrote: >sounds like the xdg-user-dirs freedesktop.org spec implementation, one >of the great new features in F7 - it provides per session translated >directories. Great stuff, will likely be a blessed part of GNOME 2.20 at >least a lot of the applications now have support for it. Only for values of great <= crap. One of the first things I did after installing f7t4 was spend some time finding out how to turn off this 'great' new feature. Just deleting the directories isn't enough, they come back later. There is a setting in /etc/xdg/user-dirs.conf or ~/.config/user-dirs.conf to disable them. I have to agree with a previous poster: the system has no business cluttering up my home directory with these intrusive and unnecesary subdirectories. Ron From lightsolphoenix at gmail.com Mon May 7 10:01:46 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Mon, 7 May 2007 06:01:46 -0400 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> Message-ID: <200705070601.47268.lightsolphoenix@gmail.com> On Monday, May 07, 2007 5:36 am Ron Yorston wrote: > I have to agree with a previous poster: the system has no business > cluttering up my home directory with these intrusive and unnecesary > subdirectories. > > Ron Looking at it from another point of view; why is it every time I set up a new Linux system I have to recreate certain common folders (Music, Pictures, Downloads, Documents, etc.)? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From nicolas.mailhot at laposte.net Mon May 7 10:17:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 12:17:29 +0200 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <200705070601.47268.lightsolphoenix@gmail.com> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> <200705070601.47268.lightsolphoenix@gmail.com> Message-ID: <1178533049.10526.4.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 06:01 -0400, Kelly a ?crit : > On Monday, May 07, 2007 5:36 am Ron Yorston wrote: > > I have to agree with a previous poster: the system has no business > > cluttering up my home directory with these intrusive and unnecesary > > subdirectories. > Looking at it from another point of view; why is it every time I set up a new > Linux system I have to recreate certain common folders (Music, Pictures, > Downloads, Documents, etc.)? That's a setting replication problem, and having to undo stupid in-your-face defaults is much more annoying than adding a few customizations. The whole default dir stuff seems quite at odds with GNOME's unobstrusive charm -- 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 dwmw2 at infradead.org Mon May 7 10:24:22 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 11:24:22 +0100 Subject: Selinux and package guidelines In-Reply-To: <463E24B1.6040407@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> Message-ID: <1178533462.11851.127.camel@pmac.infradead.org> On Sun, 2007-05-06 at 20:55 +0200, Hans de Goede wrote: > I for one have made sure all my packages work well with selinux targeted policy > in enforcing mode, and I've written patches for other peoples packages too. > I've even written for example textrel patches for SDL, but the @redhat.com > maintainer doesn't want to apply them. That's very commendable. Are you suggesting that _everyone_ does this, and that there's no _need_ for us to say anything about SElinux in the review guidelines because _everyone_ is already as conscientious as you? If so, I think you're wrong -- many people, including myself, _do_ just leave SElinux-related issues to the SElinux experts. Since you've gone all Californian on us, I'm not going to presume to hypothesise about why anyone else does that -- but personally I tend to dump that particular load onto others because I lack the wit to deal with such things myself. Alternatively, if you're just pointing out that you _personally_ are a lot more conscientious than many others, then I'm not sure I see the relevance. Would you suggest that we abandon the guidelines and the review process altogether, just because _some_ people like yourself get everything right first time anyway? So I'm confused -- what _is_ the point you're trying to make, and how does it relate to "dragoran"'s suggestion that we add something about SElinux to the review guidelines? > So in the future please refrain from such generalisms, an show some respect, or > even better show others the respect you expect them to show for you. You seem to be picking holes in terminology and making invalid assumptions about my feelings, instead of talking about the issue at hand. Please don't. -- dwmw2 From dev at nigelj.com Mon May 7 10:50:49 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 07 May 2007 22:50:49 +1200 Subject: Syncing of Bugzilla Components Message-ID: <463F0489.9090000@nigelj.com> I'm just wondering if there is any indication of when new packages php-magpierss, netgen, widelands, ocaml-SDL etc etc etc will be synced up to Bugzilla? I've been told that previously the syncs were based on the owners.list changes (which is fair enough), and have had to be disabled to avoid duplication of packages such as binutils. So basically, I'm just wondering where this sits on the timeline (no entry for Bugzilla changes is listed on http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge). Thanks, N.J. From j.w.r.degoede at hhs.nl Mon May 7 11:12:09 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 07 May 2007 13:12:09 +0200 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <1178533462.11851.127.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> Message-ID: <463F0989.4030403@hhs.nl> David Woodhouse wrote: > On Sun, 2007-05-06 at 20:55 +0200, Hans de Goede wrote: >> I for one have made sure all my packages work well with selinux targeted policy >> in enforcing mode, and I've written patches for other peoples packages too. >> I've even written for example textrel patches for SDL, but the @redhat.com >> maintainer doesn't want to apply them. > > That's very commendable. > > Are you suggesting that _everyone_ does this, and that there's no _need_ > for us to say anything about SElinux in the review guidelines because > _everyone_ is already as conscientious as you? > Quoting the first paragraph of my mail, which contains the real message: "I'm getting very tired of these generalism's of you. Most of us are not just volunteers, but even hard working volunteers. Terms like packaging monkeys, and dumping, are not nice descriptions of, and show no respect for, all the hard working people behind Fedora." I've no problems with writing something about SELinux in the guidelines, although you should realise, that handling selinux requires a certain amount of knowledge I'm pretty sure not everyone has, so making this a hard requirement will exclude about 99% of our current packagers. But as I tried to already make clear by quoting the first paragraph of my previous mail. The SELinux guidelines is not why I responded, the reason I responded was the tone of the mail, and more general the tone of your mails in general. Please quit calling valuable volunteer contributers as "package monkeys", and stop accusing them of "dumping stuff onto other people". >> So in the future please refrain from such generalisms, an show some respect, or >> even better show others the respect you expect them to show for you. > > You seem to be picking holes in terminology and making invalid > assumptions about my feelings, instead of talking about the issue at > hand. Please don't. > I wasn't talking about the issue at hand (Selinux guidelines), I was talking about an entirely other issue, the selinux thread just happened to trigger me to say something of the unpleasant tone of many of your mails and the lack of respect this shows for Fedora contributers (like me). I've changed the subject to reflect this. Regards, Hans From buc at odusz.so-cdu.ru Mon May 7 11:22:18 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 07 May 2007 15:22:18 +0400 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <1178479387.3549.11.camel@sb-home> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178479387.3549.11.camel@sb-home> Message-ID: <463F0BEA.30003@odu.neva.ru> nodata wrote: > It's my home directory, it doesn't belong to a program, it belongs to me. > > See here for the discussion: > http://www.redhat.com/archives/fedora-devel-list/2007-March/msg00858.html > Perhaps it is a time to create some wiki page for "traditional UN*X-style users" -- i.e. how to customise modern desktops (GNOME) for their habits. BTW, it could save their nerves from search of other distros... Regards, Dmitry Butskoy From dwmw2 at infradead.org Mon May 7 11:27:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 12:27:34 +0100 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <463F0989.4030403@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> Message-ID: <1178537254.11851.155.camel@pmac.infradead.org> (Ignoring the political correctness gone mad and the bogus and incorrect assumptions about my own feelings of respect or otherwise.) On Mon, 2007-05-07 at 13:12 +0200, Hans de Goede wrote: > I've no problems with writing something about SELinux in the guidelines, > although you should realise, that handling selinux requires a certain amount of > knowledge I'm pretty sure not everyone has, so making this a hard requirement > will exclude about 99% of our current packagers. I don't think anyone suggested that the package owner should required to do it all _personally_ -- just that the package should have no AVC denials in order to pass review. So the only people who would be excluded would be those who are unwilling or unable to seek help from others when the task before them exceeds their abilities. Which would probably be a good thing. -- dwmw2 From dwmw2 at infradead.org Mon May 7 11:43:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 12:43:07 +0100 Subject: [OFFTOPIC] bedwetting. In-Reply-To: <463F0989.4030403@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> Message-ID: <1178538187.11851.170.camel@pmac.infradead.org> On Mon, 2007-05-07 at 13:12 +0200, Hans de Goede wrote: > Quoting the first paragraph of my mail, which contains the real message: > "I'm getting very tired of these generalism's of you. Most of us are not just > volunteers, but even hard working volunteers. Terms like packaging monkeys, and > dumping, are not nice descriptions of, and show no respect for, all the hard > working people behind Fedora." Please don't make assumptions about whom I respect. The inference you have drawn is simply wrong. > But as I tried to already make clear by quoting the first paragraph of my > previous mail. The SELinux guidelines is not why I responded, the reason I > responded was the tone of the mail, and more general the tone of your mails in > general. Please quit calling valuable volunteer contributers as "package > monkeys", and stop accusing them of "dumping stuff onto other people". I can just about deal with the fact that some people are thin-skinned enough that they choose to take offence at the term 'packagemonkey' even though I've never used it (to my knowledge) to refer to any _specific_ person other than myself. I think those people should grow up and stop being so quick to take offence, and I think they're part of the diseased and evil culture of political correctness which blights our society -- but I try not to be too harsh when they whine about it. As I said, I'll use a different term if someone can think of anything as succinct. It's certainly not a term which implies disrespect. It's a term I apply to myself, and it's a term I would apply to others I respect too -- but only if I respect them _enough_ that I trust them not to take gratuitous offence at it. :) Over the years, I have been _massively_ impressed by some people who meet the 'packagemonkey' description -- with their willingness and ability to embrace tasks which are beyond their (initial) capabilities, and the speed at which they learn. Or with their knowledge and skill in areas _other_ than the package in question. You are utterly wrong to assume that it's a term of disrespect. It isn't. That's bad enough -- but to object _also_ to the phrase 'dumping the work onto others' when that's a _precise_ description of what often happens with SElinux issues is beyond the pale. I am extremely disappointed to find that a sensible technical discussion can be hijacked by such political correctness gone mad. Please desist -- or at least take it off-list; either with me if you must, or preferably with your therapist. -- dwmw2 From martin.sourada at seznam.cz Mon May 7 11:48:53 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 13:48:53 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <1178053751.28491.24.camel@metroid.rdu.redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> Message-ID: <463F1225.6010502@seznam.cz> Will Woods wrote: > > Yeah, you'll want to use NetworkManager to manage the device. First you > will need firmware: > > 1) Install bcm43xx-fwcutter > 2) Get a Broadcom-distributed driver to cut the firmware out of > # See the list in /usr/share/doc/bcm43xx-fwcutter-006/README > # For the newer driver you'll need 4.x firmware. I recommend: > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > 3) Unpack the driver and cut out the firmware > # tar -jxvf broadcom-wl-*.tar.bz2 > # bcm43xx-fwcutter -w /lib/firmware broadcom-wl-*/kmod/wl_apsta.o > > You might have to blacklist the old driver first if you're using the new > one: > > # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist > > But at this point you should be able to reboot and have working > wireless. Hooray! > > -w > It should but it doesn't for me. Neither anaconda nor installed system created a device for the wireless card, while on FC6 and F7T1 LiveCD it worked without problems. These steps only lead to initializing the card by the driver (or what does it do), but device (even after reboot) isn't still there (i.e. for me that the eth1 device does not exist). I attach dmesg and lspci output. Any clues? Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.log Type: text/x-log Size: 24686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lspci.log Type: text/x-log Size: 2272 bytes Desc: not available URL: From dev at nigelj.com Mon May 7 11:52:21 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 07 May 2007 23:52:21 +1200 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <463F0989.4030403@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> Message-ID: <463F12F5.7070807@nigelj.com> Hans de Goede wrote: > David Woodhouse wrote: >> On Sun, 2007-05-06 at 20:55 +0200, Hans de Goede wrote: >>> I for one have made sure all my packages work well with selinux >>> targeted policy in enforcing mode, and I've written patches for other >>> peoples packages too. I've even written for example textrel patches >>> for SDL, but the @redhat.com maintainer doesn't want to apply them. >> >> That's very commendable. >> >> Are you suggesting that _everyone_ does this, and that there's no _need_ >> for us to say anything about SElinux in the review guidelines because >> _everyone_ is already as conscientious as you? >> > > Quoting the first paragraph of my mail, which contains the real message: > "I'm getting very tired of these generalism's of you. Most of us are not > just volunteers, but even hard working volunteers. Terms like packaging > monkeys, and dumping, are not nice descriptions of, and show no respect > for, all the hard working people behind Fedora." How about the impressions of a new maintainer? Personally, I think the environment as it is, is perfect, everyone is allowed to have a view, and people have the right to say "I don't like it". David when making the comment "Don't be a Package Monkey" was expressing his own views, yes I was a bit taken aback at first, but I think it's a better term to use than saying 'lazy'... bringing his original comment in context: > But the correct fix in this case is to make the use of dmidecode > optional, and perhaps to look elsewhere for the information you wanted > from it. Just disabling an architecture is the packagemonkey approach. > Fedora needs _maintainers_ not packagemonkeys. Far better in my opinion saying that than "Just disabling an architecture is the lazy approach. Fedora needs _maintainers_ not lazy people.". My only guess was David was refering to the a-typical "Monkey see, Monkey do" approach that we see increasingly in society. The alternative to the laid back style that encourages discussion, we have the style where the Fedora community is so 'PC' that nobody wants to communicate. I think I'd perfer to be part of a community that will communicate, I may get insulted a couple of times along the way, but at least nobody is too scared to communicate. > I've no problems with writing something about SELinux in the guidelines, > although you should realise, that handling selinux requires a certain > amount of knowledge I'm pretty sure not everyone has, so making this a > hard requirement will exclude about 99% of our current packagers. As David pointed out, we have people that know what they are doing when it comes to SELinux that can help. I can see issues with Package Reviews, the obvious solution here, is a break from tradition where during package review SELinux is not taken into consideration, (i.e. the package is taken for it's compliance with general packaging rules, but it's then the job of the packager to work with someone experienced in SELinux to make the correct adjustments to the package, between fedora-review and fedora-cvs. > But as I tried to already make clear by quoting the first paragraph of > my previous mail. The SELinux guidelines is not why I responded, the > reason I responded was the tone of the mail, and more general the tone > of your mails in general. Please quit calling valuable volunteer > contributers as "package monkeys", and stop accusing them of "dumping > stuff onto other people". Back to the original context of the package monkey quote... David was pointing out to the volunteer that there was no bug filed against the package saying why it can't be built on ppc64, *not* doing this, is the package monkey approach, David was not accusing the volunteer of been a package monkey, he was just pointing out that a bug needed to be filed, so other people could see what was going on, and to provide progress information on what needs to happen to get the package up to scratch... this is the maintainer approach! While it's even better to go out your way to fix the problem, it's hard for some maintainers to have resources to cater for every arch that Fedora supports, (do you want to have to have i386, x86_64, ppc and ppc64 boxes before you can contribute?) but the filing of the bug shows your not lazy, your taking the time to acknowledge there is a problem, thats what counts in communication. [SNIP] N.J. From j.w.r.degoede at hhs.nl Mon May 7 12:10:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 07 May 2007 14:10:52 +0200 Subject: [OFFTOPIC] bedwetting. In-Reply-To: <1178538187.11851.170.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> <1178538187.11851.170.camel@pmac.infradead.org> Message-ID: <463F174C.9030209@hhs.nl> David Woodhouse wrote: > On Mon, 2007-05-07 at 13:12 +0200, Hans de Goede wrote: >> Quoting the first paragraph of my mail, which contains the real message: >> "I'm getting very tired of these generalism's of you. Most of us are not just >> volunteers, but even hard working volunteers. Terms like packaging monkeys, and >> dumping, are not nice descriptions of, and show no respect for, all the hard >> working people behind Fedora." > > Please don't make assumptions about whom I respect. The inference you > have drawn is simply wrong. > And how does changing the topic of my serious post, about the sometimes hostile mails seen on this list (not only by you), to "[OFFTOPIC] bedwetting" show any respect whatsoever ???? Regards, Hans From mclasen at redhat.com Mon May 7 12:15:42 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 07 May 2007 08:15:42 -0400 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178480680.23177.12.camel@dawkins.stavtrup-st.dk> <200705070936.l479aoeB007963@tiffany.internal.tigress.co.uk> Message-ID: <1178540142.3185.4.camel@dhcp83-33.boston.redhat.com> On Mon, 2007-05-07 at 10:36 +0100, Ron Yorston wrote: > Just deleting > the directories isn't enough, they come back later. There is a setting > in /etc/xdg/user-dirs.conf or ~/.config/user-dirs.conf to disable them. > [mclasen at dhcp83-33 ~]$ grep Videos .config/user-dirs.dirs XDG_VIDEOS_DIR="$HOME/Videos" [mclasen at dhcp83-33 ~]$ rmdir Videos [mclasen at dhcp83-33 ~]$ xdg-user-dirs-update /home/mclasen/Videos was removed, reassigning VIDEOS to homedir [mclasen at dhcp83-33 ~]$ grep VIDEOS .config/user-dirs.dirs XDG_VIDEOS_DIR="$HOME/" Seems to work here. From alexl at redhat.com Mon May 7 12:18:28 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 07 May 2007 14:18:28 +0200 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <463E21BC.9090409@xs4all.nl> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> Message-ID: <1178540308.28070.13.camel@localhost.localdomain> On Sun, 2007-05-06 at 20:43 +0200, Rubin wrote: > I don't know about anyone else but I find it hard to imagine that anyone > actually likes this behaviour; after all, who is not annoyed like hell > about directories like "My eBooks", "My Pictures", "My Music", etc that > incessantly re-create themselves in your home directory on some other > operating system whose name I shall not mention? It is _my_ home > directory, not some scratchpad for badly designed software, excuse the > venom. This is weird. Once you've removed the directory, when xdg-user-dirs-update is run a second time (i.e. on next login) we should notice that its not there and remap the setting for that directory type to $home. Can you try something like grep VIDEOS ~/.config/user-dirs.dirs which should print: XDG_VIDEOS_DIR="$HOME/Videos" (or something) Then remove ~/Videos and run xdg-user-dirs-update. What happens to the user-dirs.dir file? Does it not now have: XDG_VIDEOS_DIR="$HOME/" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an unconventional bohemian boxer from a doomed world. She's a time-travelling nymphomaniac barmaid who can talk to animals. They fight crime! From dwmw2 at infradead.org Mon May 7 12:26:50 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 13:26:50 +0100 Subject: [OFFTOPIC] bedwetting. In-Reply-To: <463F174C.9030209@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> <1178538187.11851.170.camel@pmac.infradead.org> <463F174C.9030209@hhs.nl> Message-ID: <1178540810.11851.182.camel@pmac.infradead.org> On Mon, 2007-05-07 at 14:10 +0200, Hans de Goede wrote: > And how does changing the topic of my serious post, about the sometimes hostile > mails seen on this list (not only by you), to "[OFFTOPIC] bedwetting" show any > respect whatsoever ???? It doesn't. What's your point? I have absolutely no respect for the PC nonsense you insist on dragging us back to despite my attempt to stay with the sensible topic. So what? I _sincerely_ hope you're not trying to imply that observation is at all relevant to your earlier, incorrect, assumptions about my respect (or otherwise) for something/someone entirely _different_? -- dwmw2 From linville at redhat.com Mon May 7 12:46:06 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 7 May 2007 08:46:06 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F1225.6010502@seznam.cz> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> Message-ID: <20070507124606.GA4761@redhat.com> On Mon, May 07, 2007 at 01:48:53PM +0200, Martin Sourada wrote: > Will Woods wrote: > >You might have to blacklist the old driver first if you're using the new > >one: > > > ># echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist > > > >But at this point you should be able to reboot and have working > >wireless. Hooray! > It should but it doesn't for me. Neither anaconda nor installed system > created a device for the wireless card, while on FC6 and F7T1 LiveCD it > worked without problems. These steps only lead to initializing the card by > the driver (or what does it do), but device (even after reboot) isn't still > there (i.e. for me that the eth1 device does not exist). I attach dmesg and > lspci output. Any clues? You have a bcm4318 device. This is probably the most problematic of the bcm43xx devices. FWIW, the ones I have work fine. But, others have problems. Does your work better if you get physically close to the AP (2-3 meters or less)? You may wish to continue using the bcm43xx driver, and blacklist the bcm43xx-mac80211 driver instead. If so then you will also need to go back to v3.x firmware. Hth! John -- John W. Linville linville at redhat.com From martin.sourada at seznam.cz Mon May 7 12:55:34 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 14:55:34 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507124606.GA4761@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> Message-ID: <463F21C6.3010608@seznam.cz> John W. Linville wrote: > You have a bcm4318 device. This is probably the most problematic of > the bcm43xx devices. FWIW, the ones I have work fine. But, others > have problems. Does your work better if you get physically close to > the AP (2-3 meters or less)? > In FC6 it did, at least with older kernels. About two or so months ago it started to work without problems... But on rawhide I don't even have an eth1 device... > You may wish to continue using the bcm43xx driver, and blacklist the > bcm43xx-mac80211 driver instead. If so then you will also need to > go back to v3.x firmware. > > Hth! > > John Thanks I'll try the old one... I have the firmware I used in FC6 backuped. I'll see what it'll do. Thanks, Martin From ncorrare at fedoraproject.org Mon May 7 13:40:01 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Mon, 07 May 2007 10:40:01 -0300 Subject: spca5xx In-Reply-To: <1178540308.28070.13.camel@localhost.localdomain> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> Message-ID: <463F2C31.7070708@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone maintaining the gspca package for modules for webcams based on spca5xx? Want me to help? Y.S.-- - - -- Nicolas A. Corrarello p: +54 (11) 4341-6233 Global Support Services LATAM c: +54 (911) 6398-5974 Red Hat Inc. e: ncorrare at redhat.com GPG Key: DFC893EE h: www.latam.redhat.com GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 5182-2245 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGPywx4UWy+d/Ik+4RAjp8AJwK6ih+ASmXGOp9f/0fjRVfAdllHQCfdPEL jSyUdWGZ0iAq4j3HAQSfktE= =Bxz9 -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon May 7 13:43:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 15:43:01 +0200 Subject: spca5xx In-Reply-To: <463F2C31.7070708@fedoraproject.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> Message-ID: <1178545381.23513.0.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 10:40 -0300, Nicolas Antonio Corrarello a ?crit : > Anyone maintaining the gspca package for modules for webcams based on > spca5xx? > > Want me to help? I'm sure people would like it but to be honest convincing the author to submit his stuff for inclusion in mainline would help more. -- 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 sundaram at fedoraproject.org Mon May 7 13:44:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 07 May 2007 19:14:35 +0530 Subject: spca5xx In-Reply-To: <463F2C31.7070708@fedoraproject.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> Message-ID: <463F2D43.5050304@fedoraproject.org> Nicolas Antonio Corrarello wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anyone maintaining the gspca package for modules for webcams based on > spca5xx? > > Want me to help? You hijacked the thread. Don't do that. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209113. This package review request was closed as no one was reviewing it for a while. Rahul From dcantrell at redhat.com Mon May 7 13:41:34 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 07 May 2007 09:41:34 -0400 Subject: Networking regression? In-Reply-To: <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> Message-ID: <1178545294.2813.3.camel@mortise.boston.redhat.com> Is dhcdbd running? If you have a wireless device, are you one of the lucky few to sometimes get a device name on boot called __tmp2349873264983274932 or something similar? The dhcdbd script had some work done recently and for a few days there were issues with it cleaning up on exit, so it wouldn't start on reboot. NM needs dhcdbd. On Mon, 2007-05-07 at 03:40 +0100, Naheem Zaffar wrote: > I have filed the bug under NetworkManager (Probably wrong component...): > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239254 > > The report contains the output of ifconfig -a (Both from FC6 and FC7Test4) > > My first post here was incorrect - the live cd did not detect an > adapter. I thought it did. Either way FC6 detects the device during > install. Just tested by re-installing FC6. > > Naheem > > On 06/05/07, nodata wrote: > > Am Sonntag, den 06.05.2007, 17:28 +0100 schrieb Naheem Zaffar: > > > but it gives some sort of error message > > > > You need to give the error message. > > > > Also post the output from > > ifconfig -a > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mschwendt.tmp0701.nospam at arcor.de Mon May 7 13:45:11 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 7 May 2007 15:45:11 +0200 Subject: [OFFTOPIC] bedwetting. In-Reply-To: <1178540810.11851.182.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> <1178538187.11851.170.camel@pmac.infradead.org> <463F174C.9030209@hhs.nl> <1178540810.11851.182.camel@pmac.infradead.org> Message-ID: <20070507154511.55adf1c7.mschwendt.tmp0701.nospam@arcor.de> On Mon, 07 May 2007 13:26:50 +0100, David Woodhouse wrote: > On Mon, 2007-05-07 at 14:10 +0200, Hans de Goede wrote: > > And how does changing the topic of my serious post, about the sometimes hostile > > mails seen on this list (not only by you), to "[OFFTOPIC] bedwetting" show any > > respect whatsoever ???? > > It doesn't. What's your point? > > I have absolutely no respect for the PC nonsense you insist on dragging > us back to despite my attempt to stay with the sensible topic. > > So what? I _sincerely_ hope you're not trying to imply that observation > is at all relevant to your earlier, incorrect, assumptions about my > respect (or otherwise) for something/someone entirely _different_? I'm so sick of threads like this one, which do damage to the Fedora community of packagers and which hurt the Fedora community in general. Threads like this create a hostile environment. The context in which fellow packagers are called "package-monkeys" seems to be the same always. https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00223.html https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00224.html https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00225.html From dcbw at redhat.com Mon May 7 14:13:54 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 07 May 2007 10:13:54 -0400 Subject: Networking regression? In-Reply-To: <1178545294.2813.3.camel@mortise.boston.redhat.com> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> <1178545294.2813.3.camel@mortise.boston.redhat.com> Message-ID: <1178547234.3910.4.camel@localhost.localdomain> On Mon, 2007-05-07 at 09:41 -0400, David Cantrell wrote: > Is dhcdbd running? > > If you have a wireless device, are you one of the lucky few to sometimes > get a device name on boot called __tmp2349873264983274932 or something > similar? > > The dhcdbd script had some work done recently and for a few days there > were issues with it cleaning up on exit, so it wouldn't start on reboot. > NM needs dhcdbd. Hopefully not for too much longer :) Dan > On Mon, 2007-05-07 at 03:40 +0100, Naheem Zaffar wrote: > > I have filed the bug under NetworkManager (Probably wrong component...): > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239254 > > > > The report contains the output of ifconfig -a (Both from FC6 and FC7Test4) > > > > My first post here was incorrect - the live cd did not detect an > > adapter. I thought it did. Either way FC6 detects the device during > > install. Just tested by re-installing FC6. > > > > Naheem > > > > On 06/05/07, nodata wrote: > > > Am Sonntag, den 06.05.2007, 17:28 +0100 schrieb Naheem Zaffar: > > > > but it gives some sort of error message > > > > > > You need to give the error message. > > > > > > Also post the output from > > > ifconfig -a > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From tcallawa at redhat.com Mon May 7 14:20:45 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 09:20:45 -0500 Subject: [Guidelines Change] Conflicts Message-ID: <1178547645.3661.19.camel@localhost.localdomain> A new document was added to the Packaging/ hierarchy: Conflicts. This document is also linked from the Packaging/Guidelines. For convenience, the contents of the current Packaging/Conflicts policy is presented below: ================ Conflicts Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the Conflicts: field. Acceptable Uses of Conflicts: As a general rule, Fedora packages must NOT contain any usage of the Conflicts: field. This field is commonly misused, when a Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the Conflicts: field is appropriate and acceptable. Implicit Conflicts Keep in mind that implicit conflicts are NEVER acceptable. If your package conflicts with another package, then you must either resolve the conflict, or mark it with Conflicts:. Optional Functionality Some software can utilize other optional software applications if present, but do not require them to be installed. If they are not installed, the software will still function properly. However, if those other "optional applications" are too old, then the software won't work. This is an acceptable use of the Conflicts: field. The packager must document the reason in a comment above the Conflicts: field: Example: # If the unrar utility is present, super-unpacker can open rar files. However, it only works with unrar >= 2.0. Unrar is not required for this app to function. Conflicts: unrar < 2.0 If the software links to the libraries of another package, it must use Requires: instead of Conflicts: to mark that dependency. Also, if the software does not function properly without another package being installed, it must use Requires: instead of Conflicts:. The packager should ask: If the package (at the correct version) in Conflicts: is not present, will my package be functional? If the answer is yes, then it is probably a valid use of Conflicts:. If the answer is no, then it is almost certainly a better case for Requires:. For example, if foo-game needs libbar to run, but will not work with libbar that is older than 1.2.3: WRONG: Conflicts: libbar < 1.2.3 RIGHT: Requires: libbar >= 1.2.3 Packagers should keep usage of Conflicts: to a bare minimum. Only upgrading from two previous release of Fedora is supported, so Conflicts against older packages than that, while technically correct, are unnecessary, and should not be included. Compat Package Conflicts It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided. Conflicting Files There are many types of files which can conflict between multiple packages. Fedora strongly discourages using Conflicts: to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions): Man Page Name Conflicts * Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz) * Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz) Library Name Conflicts * Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/. Header Name Conflicts * Put the headers in a subdirectory of /usr/include. Binary Name Conflicts * Convince upstream to rename the binaries to something less generic (or just less conflicting). * In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case. Other Uses of Conflicts: If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the Fedora Packaging Committee. If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist. ~spot From dcantrell at redhat.com Mon May 7 14:38:29 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 07 May 2007 10:38:29 -0400 Subject: Networking regression? In-Reply-To: <1178547234.3910.4.camel@localhost.localdomain> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> <1178545294.2813.3.camel@mortise.boston.redhat.com> <1178547234.3910.4.camel@localhost.localdomain> Message-ID: <1178548709.2813.35.camel@mortise.boston.redhat.com> On Mon, 2007-05-07 at 10:13 -0400, Dan Williams wrote: > On Mon, 2007-05-07 at 09:41 -0400, David Cantrell wrote: > > Is dhcdbd running? > > > > If you have a wireless device, are you one of the lucky few to sometimes > > get a device name on boot called __tmp2349873264983274932 or something > > similar? > > > > The dhcdbd script had some work done recently and for a few days there > > were issues with it cleaning up on exit, so it wouldn't start on reboot. > > NM needs dhcdbd. > > Hopefully not for too much longer :) No, it was about a day that I had a borken script in rawhide. Can't remember the actual time period though. Test 4 is now ancient anyway. Rawhide has the right goods. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon May 7 15:00:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 07 May 2007 11:00:45 -0400 Subject: F7 Zope package In-Reply-To: <463CC2A3.9090600@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> Message-ID: <1178550045.2558.5.camel@aglarond.local> On Sat, 2007-05-05 at 19:45 +0200, Thorsten Leemhuis wrote: > So my vote is to ship a compat-python24 for F7, but tell everyone that > we won't do that for F8 and later. That gives developers like those from > zope half a year time to prepare. I think that's only fair. The zope developers have *HAD* half a year to prepare and they've still made zero serious progress. And even in this thread, people are saying that once Zope supports it that's not enough and that there is still plone and who knows how long that will be. And what about when we move to python 2.6? We've then dug the hole that "well, we'll do compat shims so that you don't have to keep up" and someone has to do it again. Compat packages are a crutch that massively magnify the amount of effort required to support a distribution and that never goes away. Jeremy From katzj at redhat.com Mon May 7 15:04:19 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 07 May 2007 11:04:19 -0400 Subject: Syncing of Bugzilla Components In-Reply-To: <463F0489.9090000@nigelj.com> References: <463F0489.9090000@nigelj.com> Message-ID: <1178550259.2558.7.camel@aglarond.local> On Mon, 2007-05-07 at 22:50 +1200, Nigel Jones wrote: > I'm just wondering if there is any indication of when new packages > php-magpierss, netgen, widelands, ocaml-SDL etc etc etc will be synced > up to Bugzilla? I'm going to be turning on the script and hoping things don't blow up shortly... was going to on Friday, but had some Real Life (tm) stuff get in the way of doing so. Jeremy From fedora at leemhuis.info Mon May 7 15:12:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 17:12:30 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <463F41DE.6060508@leemhuis.info> (sending this again; this time with proper cross-posting) Tom "spot" Callaway schrieb: > A new document was added to the Packaging/ hierarchy: Conflicts. > This document is also linked from the Packaging/Guidelines. I'd like to thank all members of the packaging committee for their work and this policy. > [...] > Implicit Conflicts > Keep in mind that implicit conflicts are NEVER acceptable. If your > package conflicts with another package, then you must either resolve the > conflict, or mark it with Conflicts:. /me hopes we sooner or later have a script running somewhere on a server regularly that checks for implicit conflicts and bugs people if it finds any > [...] > Other Uses of Conflicts: > If you find yourself in a situation where you feel that your package has > to conflict with another package (either explicitly or implicitly), but > does not fit the documented accepted cases above, then you need to make > your case to the Fedora Packaging Committee. If they agree, then, and > only then can you use Conflicts: in a Fedora package. [...] Just wondering (and *not* meant as a critique!): Wasn't the "unwritten rule" that the Packaging Committee handles theoretical packaging while FESCo handles practical packaging? Or did I get something wrong? *If* the Packaging Committee handles practical packaging like "Approve Conflicts" I'd suggest we should consider moving "Request for packages with static libs" and maybe "Appoval requests for kmod packages" from FESCo's duty's over to the Packaging Committee. CU thl From dwmw2 at infradead.org Mon May 7 15:22:56 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 16:22:56 +0100 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <1178551376.11851.201.camel@pmac.infradead.org> On Mon, 2007-05-07 at 09:20 -0500, Tom "spot" Callaway wrote: > A new document was added to the Packaging/ hierarchy: Conflicts. > This document is also linked from the Packaging/Guidelines. > > For convenience, the contents of the current Packaging/Conflicts policy > is presented below: Might be appropriate to have some mention of multilib -- that it's _acceptable_ to have the same package for two different architectures both providing the same file in /usr/bin -- which strictly speaking is a conflict. And then, of course, I'd like to recommend the guideline set out in bug #235757 -- that any binary package which is _expected_ to be installed in both flavours in order to get both sets of libraries in their respective %_libdir should _not_ also have conflicts in /usr/bin -- the binaries should be in a separate binary package. (Like we did for hal + hal-libs recently). -- dwmw2 From dwmw2 at infradead.org Mon May 7 15:23:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 16:23:17 +0100 Subject: [OFFTOPIC] bedwetting. In-Reply-To: <20070507154511.55adf1c7.mschwendt.tmp0701.nospam@arcor.de> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> <463F0989.4030403@hhs.nl> <1178538187.11851.170.camel@pmac.infradead.org> <463F174C.9030209@hhs.nl> <1178540810.11851.182.camel@pmac.infradead.org> <20070507154511.55adf1c7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1178551397.11851.202.camel@pmac.infradead.org> On Mon, 2007-05-07 at 15:45 +0200, Michael Schwendt wrote: > I'm so sick of threads like this one, which do damage to the Fedora > community of packagers and which hurt the Fedora community in > general. As am I. I don't know why Hans hijacked a perfectly civil discussion about SElinux in packaging guidelines, but I wish he hadn't. -- dwmw2 From panemade at gmail.com Mon May 7 15:39:33 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 7 May 2007 21:09:33 +0530 Subject: spca5xx In-Reply-To: <463F2C31.7070708@fedoraproject.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> Message-ID: hi, On 5/7/07, Nicolas Antonio Corrarello wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Anyone maintaining the gspca package for modules for webcams based on > spca5xx? > > Want me to help? Thanks for at least showing your interest in spca5xx package. spca5xx is kernel module based on v4l1 standard and gspca is kernel module based on v4l2 standard. I tried both kernel module packages to include in Fedora one by one using all kernel module packaging guidelines but nobody showed interest in reviwing gspca even I got FE-KMOD-APPROVED on it. For gspca you can see how review got progressed at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112 If you are more interested in spca5xx as gspca development got stopped for time being then I even tried to include spca5xx-kmod package but there also no response and same time I saw gspca is gaining momentum so I CLOSED https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198331 and submitted review request for gspca kernel module. Unfortunately nobody showed interest in reviewing either of the package so I closed review requests. If you are willing to maintain it I can share SRPMs of both packages to you. But you need to go again with long reviewing process of kernel packages. Regards, Parag. From martin.sourada at seznam.cz Mon May 7 16:07:48 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 18:07:48 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F21C6.3010608@seznam.cz> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> Message-ID: <463F4ED4.4080307@seznam.cz> Some new info... Still playing with the new driver (bcm43xx_mac80211) I discovered 1. ifconfig -a lists among other devices wlan0, however ifup cannot use it (complains about missing configuration) 2. after I tried creating new wireless network with NetworkManager it stayed connected to wired network, however it detected some wireless networks here. So it seems the wifi is working, the wifi driver as well, only configuration for ifup is missing. Why? Is it some new "feature" or is it just a bug? Thanks, Martin From naheemzaffar at gmail.com Mon May 7 16:12:13 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 7 May 2007 17:12:13 +0100 Subject: Networking regression? In-Reply-To: <1178548709.2813.35.camel@mortise.boston.redhat.com> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> <1178545294.2813.3.camel@mortise.boston.redhat.com> <1178547234.3910.4.camel@localhost.localdomain> <1178548709.2813.35.camel@mortise.boston.redhat.com> Message-ID: <3adc77210705070912u148bf5bag545895039ba5694b@mail.gmail.com> It is a wired ethernet connection. On the livecd from System >> Admin>> Services dhcdbd is active, network is not. In FC6 dhcdbd is not active, network is. Can't update without the network, so no idea how to test a newer rawhide. From dwmw2 at infradead.org Mon May 7 16:12:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 07 May 2007 17:12:31 +0100 Subject: spca5xx In-Reply-To: References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> Message-ID: <1178554351.11851.213.camel@pmac.infradead.org> On Mon, 2007-05-07 at 21:09 +0530, Parag N(????) wrote: > I tried both kernel module packages to include in Fedora one by one > using all kernel module packaging guidelines but nobody showed > interest in reviwing gspca I'm completely uninterested in reviewing it as a Fedora package, but the merge window for the 2.6.22 kernel is open, and if you want to do the _right_ thing by submitting it upstream, I'll take a look over it, and give you an account on git.infradead.org where you can publish a git tree with it, etc. -- dwmw2 From nicolas.mailhot at laposte.net Mon May 7 16:29:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 18:29:19 +0200 Subject: spca5xx In-Reply-To: <1178554351.11851.213.camel@pmac.infradead.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> <1178554351.11851.213.camel@pmac.infradead.org> Message-ID: <1178555359.24533.0.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 17:12 +0100, David Woodhouse a ?crit : > On Mon, 2007-05-07 at 21:09 +0530, Parag N(????) wrote: > > I tried both kernel module packages to include in Fedora one by one > > using all kernel module packaging guidelines but nobody showed > > interest in reviwing gspca > > I'm completely uninterested in reviewing it as a Fedora package, but the > merge window for the 2.6.22 kernel is open, and if you want to do the > _right_ thing by submitting it upstream, I'll take a look over it, and > give you an account on git.infradead.org where you can publish a git > tree with it, etc. That would close http://bugzilla.kernel.org/show_bug.cgi?id=8413 BTW 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 panemade at gmail.com Mon May 7 16:30:02 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 7 May 2007 22:00:02 +0530 Subject: spca5xx In-Reply-To: <1178554351.11851.213.camel@pmac.infradead.org> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> <1178554351.11851.213.camel@pmac.infradead.org> Message-ID: Hi, On 5/7/07, David Woodhouse wrote: > On Mon, 2007-05-07 at 21:09 +0530, Parag N(????) wrote: > > I tried both kernel module packages to include in Fedora one by one > > using all kernel module packaging guidelines but nobody showed > > interest in reviwing gspca > > I'm completely uninterested in reviewing it as a Fedora package, but the > merge window for the 2.6.22 kernel is open, and if you want to do the > _right_ thing by submitting it upstream, I'll take a look over it, and > give you an account on git.infradead.org where you can publish a git > tree with it, etc. I don't mind as you are not the first who said that ("completely uninterested in reviewing it as a Fedora package"). As I am not the author and developer of spca5xx or gspca, I can't help with upstream submission. I think that can be only done by its author Michel Xhaard. Regards, Parag. From mackay_d at bellsouth.net Mon May 7 16:41:27 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 11:41:27 -0500 Subject: F7 Zope package In-Reply-To: <463C3B4D.2070200@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463C3B4D.2070200@fedoraunity.org> Message-ID: <1178556087.12774.25.camel@vorpal.macdev.com> On Sat, 2007-05-05 at 02:07 -0600, Jonathan Steffan wrote: > There is no 2.5 support as of yet and it looks like only Zope 3 will > eventually support 2.5. That's a horse of a different color, one I'll pursue on the zope mailing list. > > The Zope corporation used to supply "binary" rpms > > where the python interpreter that was appropriate for the zope version > > was installed in the zope directory tree. They have discontinued this, > > but it seems like a good solution for this particular problem. > Please don't point your finger at me. As the packager, it is not fair to > me. This is not a packaging issue. This is an issue of including python > 2.4 support or not. I'm not pointing a finger at you, specifically, Jonathan. It sounds like your hands are tied. But, at the end of the day, if the package won't run, it's broken. I'd like to convince the good folks at Red Hat to supply a functioning package. Dave From linville at redhat.com Mon May 7 16:49:13 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 7 May 2007 12:49:13 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F4ED4.4080307@seznam.cz> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> Message-ID: <20070507164913.GB4761@redhat.com> On Mon, May 07, 2007 at 06:07:48PM +0200, Martin Sourada wrote: > Some new info... > > Still playing with the new driver (bcm43xx_mac80211) I discovered > 1. ifconfig -a lists among other devices wlan0, however ifup cannot use it > (complains about missing configuration) OK, I missed the point of you complaining about "eth1" missing... :-) > 2. after I tried creating new wireless network with NetworkManager it > stayed connected to wired network, however it detected some wireless > networks here. So it seems the wifi is working, the wifi driver as well, > only configuration for ifup is missing. Why? Is it some new "feature" or is > it just a bug? Did you setup wlan0 w/ system-config-network? If not, ifup'ing it won't help. John -- John W. Linville linville at redhat.com From mackay_d at bellsouth.net Mon May 7 16:53:43 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 11:53:43 -0500 Subject: F7 Zope package In-Reply-To: <463C3F89.1000701@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> Message-ID: <1178556823.12774.34.camel@vorpal.macdev.com> On Sat, 2007-05-05 at 02:25 -0600, Jonathan Steffan wrote: > The point is that > there is no planned support for python 2.4 in Fedora 7 and thus I needed > to remove the packages from the build system. I invite Zope/Plone users > to express their desire to have support but I think I have already > fought the battle to the best of my abilities and feel any further > action on my part is futile. Thanks for trying. This is all starting to sound more like a moral crusade than a technical discussion. As a user of both fedora and zope, I'd like for them to both "just work" together. The fact that the parties involved have managed to rationalize the exclusion of several perfectly viable solutions doesn't speak well for their attention to the end users. As you stated in a (deleted for brevity) portion of your message, if the solution is not supplied by the distro, I'll find or do something myself. If so, I might feel compelled to strike Matthew Szulik's name from my Christmas card list. Dave From martin.sourada at seznam.cz Mon May 7 16:55:11 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 18:55:11 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507164913.GB4761@redhat.com> References: <1177609031.22781.47.camel@metroid.rdu.redhat.com> <200704300901.59753.jkeating@redhat.com> <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> Message-ID: <463F59EF.2000101@seznam.cz> John W. Linville wrote: > On Mon, May 07, 2007 at 06:07:48PM +0200, Martin Sourada wrote: >> Some new info... >> >> Still playing with the new driver (bcm43xx_mac80211) I discovered >> 1. ifconfig -a lists among other devices wlan0, however ifup cannot use it >> (complains about missing configuration) > > OK, I missed the point of you complaining about "eth1" missing... :-) > >> 2. after I tried creating new wireless network with NetworkManager it >> stayed connected to wired network, however it detected some wireless >> networks here. So it seems the wifi is working, the wifi driver as well, >> only configuration for ifup is missing. Why? Is it some new "feature" or is >> it just a bug? > > Did you setup wlan0 w/ system-config-network? If not, ifup'ing it > won't help. > > John Hm... when I try to add new device in system-config-network I can choose only eth* (though I can write there wlan0 manually), but I don't know which adapter to choose, because mine does not seems to be listed there... I think it should be detected and set automatically like in previous versions of fedora. Thanks, Martin From jwboyer at jdub.homelinux.org Mon May 7 17:02:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 12:02:01 -0500 Subject: F7 Zope package In-Reply-To: <1178556823.12774.34.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> <1178556823.12774.34.camel@vorpal.macdev.com> Message-ID: <1178557321.2990.89.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 11:53 -0500, David G. Mackay wrote: > myself. If so, I might feel compelled to strike Matthew Szulik's name > from my Christmas card list. That would be a bit silly. Matthew has nothing to do with this. If you meant to imply that Red Hat isn't going to support a compat-python24 package and therefore deserves some sort of thwapping, that still isn't the case. Jeremy, as the _Fedora_ python owner, doesn't want to provide that package. FESCo, which is comprised from the _community_, backed him thus far. If you, or anyone else, would like to create a compat-python24 package and escalate back up to FESCo to be heard, then go for it. This has nothing to do with Red Hat. josh From linville at redhat.com Mon May 7 17:22:05 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 7 May 2007 13:22:05 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F59EF.2000101@seznam.cz> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> Message-ID: <20070507172205.GC4761@redhat.com> On Mon, May 07, 2007 at 06:55:11PM +0200, Martin Sourada wrote: > John W. Linville wrote: > >On Mon, May 07, 2007 at 06:07:48PM +0200, Martin Sourada wrote: > >>Some new info... > >> > >>Still playing with the new driver (bcm43xx_mac80211) I discovered > >>1. ifconfig -a lists among other devices wlan0, however ifup cannot use > >>it (complains about missing configuration) > > > >OK, I missed the point of you complaining about "eth1" missing... :-) > > > >>2. after I tried creating new wireless network with NetworkManager it > >>stayed connected to wired network, however it detected some wireless > >>networks here. So it seems the wifi is working, the wifi driver as well, > >>only configuration for ifup is missing. Why? Is it some new "feature" or > >>is it just a bug? > > > >Did you setup wlan0 w/ system-config-network? If not, ifup'ing it > >won't help. > > > >John > > Hm... when I try to add new device in system-config-network I can choose > only eth* (though I can write there wlan0 manually), but I don't know which > adapter to choose, because mine does not seems to be listed there... I > think it should be detected and set automatically like in previous versions > of fedora. Hmmm...my wlan0 shows-up there automatically...Bill? John -- John W. Linville linville at redhat.com From nicolas.mailhot at laposte.net Mon May 7 17:22:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 19:22:50 +0200 Subject: spca5xx In-Reply-To: References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> <463F2C31.7070708@fedoraproject.org> <1178554351.11851.213.camel@pmac.infradead.org> Message-ID: <1178558570.24941.2.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 22:00 +0530, Parag N(????) a ?crit : > Hi, > On 5/7/07, David Woodhouse wrote: > > On Mon, 2007-05-07 at 21:09 +0530, Parag N(????) wrote: > > > I tried both kernel module packages to include in Fedora one by one > > > using all kernel module packaging guidelines but nobody showed > > > interest in reviwing gspca > > > > I'm completely uninterested in reviewing it as a Fedora package, but the > > merge window for the 2.6.22 kernel is open, and if you want to do the > > _right_ thing by submitting it upstream, I'll take a look over it, and > > give you an account on git.infradead.org where you can publish a git > > tree with it, etc. > I don't mind as you are not the first who said that ("completely > uninterested in reviewing it as a Fedora package"). As I am not the > author and developer of spca5xx or gspca, I can't help with upstream > submission. I think that can be only done by its author Michel Xhaard. It can be done by anyone with the technical abilities, working as proxy for the original project. Of course the best person to do it is always the original author, but if he lacks the will someone else can do 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 nicolas.mailhot at laposte.net Mon May 7 17:33:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 19:33:51 +0200 Subject: F7 Zope package In-Reply-To: <1178556823.12774.34.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> <1178556823.12774.34.camel@vorpal.macdev.com> Message-ID: <1178559231.24941.11.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 11:53 -0500, David G. Mackay a ?crit : > On Sat, 2007-05-05 at 02:25 -0600, Jonathan Steffan wrote: > > > The point is that > > there is no planned support for python 2.4 in Fedora 7 and thus I needed > > to remove the packages from the build system. I invite Zope/Plone users > > to express their desire to have support but I think I have already > > fought the battle to the best of my abilities and feel any further > > action on my part is futile. > > Thanks for trying. This is all starting to sound more like a moral > crusade than a technical discussion. Don't be mistaken. This is everything but a moral crusade. compat packages are a big distro pain, compat packages for something as complex as python would be a major F7 pain, and you're all a little quick to decide it's the obvious easy solution. It's not an easy solution and it's not an obvious one, especially lacking some form of commitment zope-side not to repeat the mess for the next (F8) release. -- 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 naheemzaffar at gmail.com Mon May 7 17:37:36 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 7 May 2007 18:37:36 +0100 Subject: Networking regression? In-Reply-To: <3adc77210705070912u148bf5bag545895039ba5694b@mail.gmail.com> References: <3adc77210705060928k55fccbeepac639e9fe6047aa4@mail.gmail.com> <1178479429.3549.13.camel@sb-home> <3adc77210705061940k2ab3a23jf5fd40bc029dae8d@mail.gmail.com> <1178545294.2813.3.camel@mortise.boston.redhat.com> <1178547234.3910.4.camel@localhost.localdomain> <1178548709.2813.35.camel@mortise.boston.redhat.com> <3adc77210705070912u148bf5bag545895039ba5694b@mail.gmail.com> Message-ID: <3adc77210705071037h39a2621fgac897ff9a046927d@mail.gmail.com> I have now tested in the rawhide-20070502-live CD with no change. From drago01 at gmail.com Mon May 7 17:38:24 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 07 May 2007 19:38:24 +0200 Subject: Selinux and package guidelines In-Reply-To: <200705062114.42830.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463DAB58.6060205@gmail.com> <200705062114.42830.opensource@till.name> Message-ID: <463F6410.2090208@gmail.com> Till Maas wrote: > > Please update the documentation about selinux and packaging[1] first, > currently, there is not much help to allow e.g. execmod for a file in a > package. Without proper documentation, your demand seems not to be very wise > to me. yes we probably need more/better docs but this is a important issue that can't be simply ignored... how can a package that does not work with something that is enabled by default in fedora get into fedora? "I've no problems with writing something about SELinux in the guidelines, although you should realise, that handling selinux requires a certain amount of knowledge I'm pretty sure not everyone has, so making this a hard requirement will exclude about 99% of our current packagers." no it wouldn't because 95% of the packages do not require any changes... and the other 5% should read the docs (has to be improved) or aks people that has better knowlege (thats why its a community distro not everybody should know about everything) p.s: I am ignoring the "packagemonkey issue" because I think its pointless and does not help making fedora better (its the opposite) so please stop it...thx From mackay_d at bellsouth.net Mon May 7 17:40:46 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 12:40:46 -0500 Subject: F7 Zope package In-Reply-To: <1178550045.2558.5.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> Message-ID: <1178559646.12774.43.camel@vorpal.macdev.com> On Mon, 2007-05-07 at 11:00 -0400, Jeremy Katz wrote: > The zope developers have *HAD* half a year to prepare and they've still > made zero serious progress. And even in this thread, people are saying > that once Zope supports it that's not enough and that there is still > plone and who knows how long that will be. And what about when we move > to python 2.6? We've then dug the hole that "well, we'll do compat > shims so that you don't have to keep up" and someone has to do it again. So Zope Corp is obligated to drive their development efforts based upon what Red Hat finds to be esthetically pleasing? > Compat packages are a crutch that massively magnify the amount of effort > required to support a distribution and that never goes away. You keep saying that it's a massive effort. Would you point us to some documentation outlining the work required? Also, how much work is required of Red Hat employees? As a casual observer, I just don't see it, and I might be a lot more sympathetic if I had a better idea. The "never goes away" portion of the statement is patently untrue. Dave From notting at redhat.com Mon May 7 17:57:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 May 2007 13:57:19 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507172205.GC4761@redhat.com> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> Message-ID: <20070507175719.GA3505@nostromo.devel.redhat.com> John W. Linville (linville at redhat.com) said: > > Hm... when I try to add new device in system-config-network I can choose > > only eth* (though I can write there wlan0 manually), but I don't know which > > adapter to choose, because mine does not seems to be listed there... I > > think it should be detected and set automatically like in previous versions > > of fedora. > > Hmmm...my wlan0 shows-up there automatically...Bill? kudzu -p -c network? (Or does s-c-network use HAL these days?) Bill From nicolas.mailhot at laposte.net Mon May 7 18:06:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 07 May 2007 20:06:20 +0200 Subject: F7 Zope package In-Reply-To: <1178559646.12774.43.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> Message-ID: <1178561180.24941.21.camel@rousalka.dyndns.org> Le lundi 07 mai 2007 ? 12:40 -0500, David G. Mackay a ?crit : > On Mon, 2007-05-07 at 11:00 -0400, Jeremy Katz wrote: > > > The zope developers have *HAD* half a year to prepare and they've still > > made zero serious progress. And even in this thread, people are saying > > that once Zope supports it that's not enough and that there is still > > plone and who knows how long that will be. And what about when we move > > to python 2.6? We've then dug the hole that "well, we'll do compat > > shims so that you don't have to keep up" and someone has to do it again. > > So Zope Corp is obligated to drive their development efforts based upon > what Red Hat finds to be esthetically pleasing? So the Fedora Project is obligated to drive its development efforts based upon what Zope Corp finds to be esthetically pleasing? Fedora is not a single-app distro, it targets an optimum composed of all the apps it ships, and if Zope Corp is unable to fit in this target, that's too bad for Zope. The writing was on the wall when the F7 release cycle started, if you want to go in panic mode now, do it on Zope forums. > > Compat packages are a crutch that massively magnify the amount of effort > > required to support a distribution and that never goes away. > > You keep saying that it's a massive effort. Would you point us to some > documentation outlining the work required? Also, how much work is > required of Red Hat employees? As a casual observer, I just don't see > it, and I might be a lot more sympathetic if I had a better idea. You obviously never have been involved in a big packaging effort. Workarounds and crutches do not integrate, they just accumulate and call for other workarounds till the whole project crumbles. Particularly if the upstream calling for workarounds considers they're no problem as history tends to repeat itself. -- 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 martin.sourada at seznam.cz Mon May 7 18:09:22 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 20:09:22 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507175719.GA3505@nostromo.devel.redhat.com> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> Message-ID: <463F6B52.7080709@seznam.cz> Bill Nottingham wrote: > John W. Linville (linville at redhat.com) said: >>> Hm... when I try to add new device in system-config-network I can choose >>> only eth* (though I can write there wlan0 manually), but I don't know which >>> adapter to choose, because mine does not seems to be listed there... I >>> think it should be detected and set automatically like in previous versions >>> of fedora. >> Hmmm...my wlan0 shows-up there automatically...Bill? > > kudzu -p -c network? (Or does s-c-network use HAL these days?) > > Bill > # kudzu -p -c network - class: NETWORK bus: PCI detached: 0 device: eth1 driver: bcm43xx desc: "Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller" vendorId: 14e4 deviceId: 4318 subVendorId: 1468 subDeviceId: 0312 pciType: 1 pcidom: 0 pcibus: 6 pcidev: 2 pcifn: 0 - class: NETWORK bus: PCI detached: 0 device: eth0 driver: b44 desc: "Broadcom Corporation BCM4401-B0 100Base-TX" network.hwaddr: 00:16:d4:1a:34:78 vendorId: 14e4 deviceId: 170c subVendorId: 1025 subDeviceId: 0090 pciType: 1 pcidom: 0 pcibus: 6 pcidev: 1 pcifn: 0 But still nothing in system-config-network. Also, I think under driver there should be bmc43xx_mac80211 since I have bcm43xx blacklisted and the NetworkManager indeed uses the bmc43xx_mac80211 driver. This behaviour seems quite weird to me. Thanks, Martin From mschwendt.tmp0701.nospam at arcor.de Mon May 7 18:11:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 7 May 2007 20:11:54 +0200 Subject: F7 Zope package In-Reply-To: <1178559231.24941.11.camel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> <1178556823.12774.34.camel@vorpal.macdev.com> <1178559231.24941.11.camel@rousalka.dyndns.org> Message-ID: <20070507201154.76ef8380.mschwendt.tmp0701.nospam@arcor.de> On Mon, 07 May 2007 19:33:51 +0200, Nicolas Mailhot wrote: > Don't be mistaken. This is everything but a moral crusade. compat > packages are a big distro pain, compat packages for something as complex > as python would be a major F7 pain, and you're all a little quick to > decide it's the obvious easy solution. Don't forget the opposite direction: multiple packages for multiple APIs of some framework. Compat-packages in disguise. For example, Qt 3 and Qt 4. Both are stable major releases. Now, if a big application, that was developed for Qt 3 by several dozen upstream developers, is not available for Qt 4 yet, the single packager cannot be expected to take over the porting from one API to another. From mmcgrath at redhat.com Mon May 7 18:21:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 07 May 2007 13:21:39 -0500 Subject: Buildsystem Outage Message-ID: <463F6E33.1040304@redhat.com> We're upgrading some hardware (filers) on Wed, 10:30-12:30 EST. Sorry for any inconvenience. -Mike From jdieter at gmail.com Mon May 7 18:27:04 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 07 May 2007 21:27:04 +0300 Subject: Yum-presto utilities Message-ID: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> I've finally got a copy of createprestorepo that I'm (mostly) happy with, along with a couple of other small utilites: * createprestorepo - Creates a Presto repository from rpms and drpms. http://www.lesbg.com/jdieter/presto/createprestorepo-0.1.0.tar.bz2 * prunerepo - This is actually FI's RepoPrune with a few small modifications to make it useful for local mirrors. http://www.lesbg.com/jdieter/presto/prunerepo-0.1.0.tar.bz2 * prunedrpms - A small utility to remove all drpms that point to rpms that are no longer in the local repository (probably because they've been removed by prunerepo above). http://www.lesbg.com/jdieter/presto/prunedrpms-0.1.0.tar.bz2 This should be all you need to create presto repositories for your own repositories. If you need more information about Presto, there's http://hosted.fedoraproject.org/projects/presto. Jonathan -------------- 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 drago01 at gmail.com Mon May 7 18:30:51 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 07 May 2007 20:30:51 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F6B52.7080709@seznam.cz> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> Message-ID: <463F705B.7040500@gmail.com> Martin Sourada wrote: > Bill Nottingham wrote: >> John W. Linville (linville at redhat.com) said: >>>> Hm... when I try to add new device in system-config-network I can >>>> choose only eth* (though I can write there wlan0 manually), but I >>>> don't know which adapter to choose, because mine does not seems to >>>> be listed there... I think it should be detected and set >>>> automatically like in previous versions of fedora. >>> Hmmm...my wlan0 shows-up there automatically...Bill? >> >> kudzu -p -c network? (Or does s-c-network use HAL these days?) >> >> Bill >> what about adding alias wlan0 bmc43xx_mac80211 to modprobe.conf ? does system-config network detect it than? From mackay_d at bellsouth.net Mon May 7 16:00:20 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 11:00:20 -0500 Subject: F7 Zope package In-Reply-To: <1178301466.7630.22.camel@hughsie-laptop> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> Message-ID: <1178553620.12774.14.camel@vorpal.macdev.com> On Fri, 2007-05-04 at 18:57 +0100, Richard Hughes wrote: > If a vendor kept patching a driver for kernel 2.4 but refused to port it > to kernel 2.6, would we ship a 2.4 kernel just for that one driver? > Technically possible but a really bad plan. I don't believe that anyone's refusing to update zope to operate with 2.5, but the effort isn't trivial. Zope has normally lagged behind the python releases because of the c bindings to python present in zope. And, running two different python interpreters is nothing like trying to run two different kernels. Dave From mackay_d at bellsouth.net Mon May 7 15:55:08 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 10:55:08 -0500 Subject: F7 Zope package In-Reply-To: <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1178553308.12774.9.camel@vorpal.macdev.com> On Fri, 2007-05-04 at 19:40 +0200, Michael Schwendt wrote: > There is no zope and no plone for Fedora 7. We've removed the rpms from > the development repository some time ago on the package owner's request. Sorry to hear that they were removed. If you need the functionality provided by Zope, then I don't know of any other open source product that comes close. > You refer to the old builds for Fedora 6, which have continued to > live in the development repo for some time. I refer to the rpms that were on the F7-t3 dvd. Dave From mackay_d at bellsouth.net Mon May 7 16:05:34 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 11:05:34 -0500 Subject: F7 Zope package In-Reply-To: <1178303676.18256.140.camel@cutter> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <1178303676.18256.140.camel@cutter> Message-ID: <1178553934.12774.18.camel@vorpal.macdev.com> On Fri, 2007-05-04 at 14:34 -0400, seth vidal wrote: > > I find it pretty sad that FESCo is vetoing packages which don't have licensing > > (including copyright/patent/trademark) or serious security issues. If someone > > is willing to maintain such a package, why not let them? > > > > b/c of the maintenance headache it adds to the entire distribution and > all of the misfiled bugs and confusing reports it will create. Why do you assume that will happen? I would guess that most bug reports would be directed to zope.org. The presence of the 2.4 python wouldn't even be visible unless someone dug into the package startup scripts. Dave From mackay_d at bellsouth.net Mon May 7 18:41:54 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 13:41:54 -0500 Subject: F7 Zope package In-Reply-To: <1178561559.24941.25.camel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178301466.7630.22.camel@hughsie-laptop> <463B7608.60508@leemhuis.info> <463B778C.5050904@fedoraproject.org> <463C3C45.9050900@fedoraunity.org> <463C3F89.1000701@fedoraunity.org> <1178556823.12774.34.camel@vorpal.macdev.com> <1178559231.24941.11.camel@rousalka.dyndns.org> <1178560911.12774.58.camel@vorpal.macdev.com> <1178561559.24941.25.camel@rousalka.dyndns.org> Message-ID: <1178563314.12774.84.camel@vorpal.macdev.com> On Mon, 2007-05-07 at 20:12 +0200, Nicolas Mailhot wrote: > Le lundi 07 mai 2007 ? 13:01 -0500, David G. Mackay a ?crit : > > > Well, I'd note that Fedora needs good packages a LOT more than the good > > packages need Fedora. If Fedora wants to keep and/or build mind share, > > then they might want to evaluate the effort to user satisfaction ratio > > again. > > Bad engineering does not make good packages. > Bad packages do not make satisfied users. > > The train wreck is 100% due to Zope people losing touch with the > evolution of their technical environment and hoping it would stop just > for them. Out of curiosity, why are the Zope developers responsible for the fact that python breaks compatibility with their (python's) APIs from release to release? > Fedora inclusion process is fast, zope will be back as soon as the zope > devs get their stuff in shape again. So, being on the bleeding edge is more important than functionality to Fedora? The only problem with Zope's engineering decisions here is that they're tightly integrated to python, and the python folks don't seem to worry overly much about backward compatibility at that level of integration. Dave From jkeating at redhat.com Mon May 7 18:45:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 14:45:17 -0400 Subject: F7 Zope package In-Reply-To: <1178553308.12774.9.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> Message-ID: <200705071445.17637.jkeating@redhat.com> On Monday 07 May 2007 11:55:08 David G. Mackay wrote: > I refer to the rpms that were on the F7-t3 dvd. Which don't actually work, and shouldn't be there, I don't think they were there for t4. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 7 18:46:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 14:46:09 -0400 Subject: F7 Zope package In-Reply-To: <1178563314.12774.84.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178561559.24941.25.camel@rousalka.dyndns.org> <1178563314.12774.84.camel@vorpal.macdev.com> Message-ID: <200705071446.09585.jkeating@redhat.com> On Monday 07 May 2007 14:41:54 David G. Mackay wrote: > Out of curiosity, why are the Zope developers responsible for the fact > that python breaks compatibility with their (python's) APIs from release > to release? Er, 2.4 -> 2.5 was listed as a _major_ api change. Surprise, api changes break... apis. If it weren't an API change, it would have been yet another 2.4.something release most likely. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From emmanuel.seyman at club-internet.fr Mon May 7 18:50:22 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 7 May 2007 20:50:22 +0200 Subject: F7 Zope package In-Reply-To: <1178559646.12774.43.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> Message-ID: <20070507185022.GA22316@orient.maison.lan> * David G. Mackay [07/05/2007 20:33] : > > You keep saying that it's a massive effort. Would you point us to some > documentation outlining the work required? Also, how much work is > required of Red Hat employees? As a casual observer, I just don't see > it, and I might be a lot more sympathetic if I had a better idea. This goes both ways. If the work needed to package compat-python24 + zope + plone + any and all packages needed to make the whole stack work is trivial, then anybody can do it and make a third party repo with all the rpms and maintain it until Zope 3 is included in Fedora. Users will just go to a website, click on a rpm, click twice on "OK" and then run "yum install zope" (or whatever the equivalent for their favourite backend is). Problem solved. Emmanuel From mschwendt.tmp0701.nospam at arcor.de Mon May 7 19:03:36 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 7 May 2007 21:03:36 +0200 Subject: F7 Zope package In-Reply-To: <1178553308.12774.9.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> Message-ID: <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> On Mon, 07 May 2007 10:55:08 -0500, David G. Mackay wrote: > On Fri, 2007-05-04 at 19:40 +0200, Michael Schwendt wrote: > > > There is no zope and no plone for Fedora 7. We've removed the rpms from > > the development repository some time ago on the package owner's request. > > Sorry to hear that they were removed. If you need the functionality > provided by Zope, then I don't know of any other open source product > that comes close. > > > You refer to the old builds for Fedora 6, which have continued to > > live in the development repo for some time. > > I refer to the rpms that were on the F7-t3 dvd. Yes, an old FC-6 zope from Aug 30th, 2006, and older than the current FC-6 package. The spec in Fedora Extras CVS has not been touched since then. From sundaram at fedoraproject.org Mon May 7 19:08:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 May 2007 00:38:39 +0530 Subject: Why does nautilus create folders in my home directory by default? In-Reply-To: <1178540308.28070.13.camel@localhost.localdomain> References: <20070506171018.600B8152131@buildsys.fedoraproject.org> <463E21BC.9090409@xs4all.nl> <1178540308.28070.13.camel@localhost.localdomain> Message-ID: <463F7937.6010409@fedoraproject.org> Alexander Larsson wrote: > On Sun, 2007-05-06 at 20:43 +0200, Rubin wrote: >> I don't know about anyone else but I find it hard to imagine that anyone >> actually likes this behaviour; after all, who is not annoyed like hell >> about directories like "My eBooks", "My Pictures", "My Music", etc that >> incessantly re-create themselves in your home directory on some other >> operating system whose name I shall not mention? It is _my_ home >> directory, not some scratchpad for badly designed software, excuse the >> venom. > > This is weird. Once you've removed the directory, when > xdg-user-dirs-update is run a second time (i.e. on next login) we should > notice that its not there and remap the setting for that directory type > to $home. > > Can you try something like > grep VIDEOS ~/.config/user-dirs.dirs > which should print: > XDG_VIDEOS_DIR="$HOME/Videos" > (or something) > > Then remove ~/Videos and run xdg-user-dirs-update. What happens to the > user-dirs.dir file? Does it not now have: > XDG_VIDEOS_DIR="$HOME/" Yes. This works as expected. Remove folders and relogin and it does not create the folders. However rebooting and logging into the system I find the folders are created automatically again. Rahul From martin.sourada at seznam.cz Mon May 7 19:14:51 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 21:14:51 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F705B.7040500@gmail.com> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <463F705B.7040500@gmail.com> Message-ID: <463F7AAB.6060200@seznam.cz> dragoran wrote: > Martin Sourada wrote: >> Bill Nottingham wrote: >>> John W. Linville (linville at redhat.com) said: >>>>> Hm... when I try to add new device in system-config-network I can >>>>> choose only eth* (though I can write there wlan0 manually), but I >>>>> don't know which adapter to choose, because mine does not seems to >>>>> be listed there... I think it should be detected and set >>>>> automatically like in previous versions of fedora. >>>> Hmmm...my wlan0 shows-up there automatically...Bill? >>> >>> kudzu -p -c network? (Or does s-c-network use HAL these days?) >>> >>> Bill >>> > what about adding > alias wlan0 bmc43xx_mac80211 to modprobe.conf ? > does system-config network detect it than? > Hm... the system-config-network then shows it in the hardware list and allows me to create a device. If I run ifup wlan0 however, I get this error: Error for wireless request "Set Bit Rate" (8B20) : SET failed on device wlan0 ; Operation not supported. And it fails to connect - but that is OK, since I don't have there any wireless network I have access to... Maybe I should try eth1, as kudzu find it as eth1? Or is wireless supposed to be handled by NetworkManager completely? Thanks, Martin From notting at redhat.com Mon May 7 19:13:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 May 2007 15:13:38 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F6B52.7080709@seznam.cz> References: <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> Message-ID: <20070507191338.GB4803@nostromo.devel.redhat.com> Martin Sourada (martin.sourada at seznam.cz) said: > # kudzu -p -c network > - > class: NETWORK > bus: PCI > detached: 0 > device: eth1 > driver: bcm43xx > desc: "Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN > Controller" > vendorId: 14e4 > deviceId: 4318 > subVendorId: 1468 > subDeviceId: 0312 > pciType: 1 > pcidom: 0 > pcibus: 6 > pcidev: 2 > pcifn: 0 > - > class: NETWORK > bus: PCI > detached: 0 > device: eth0 > driver: b44 > desc: "Broadcom Corporation BCM4401-B0 100Base-TX" > network.hwaddr: 00:16:d4:1a:34:78 > vendorId: 14e4 > deviceId: 170c > subVendorId: 1025 > subDeviceId: 0090 > pciType: 1 > pcidom: 0 > pcibus: 6 > pcidev: 1 > pcifn: 0 > > But still nothing in system-config-network. Is the device you're looking for eth1 or something else? > Also, I think under driver > there should be bmc43xx_mac80211 since I have bcm43xx blacklisted and the > NetworkManager indeed uses the bmc43xx_mac80211 driver. This behaviour > seems quite weird to me. Shouldn't matter. Bill From mschwendt.tmp0701.nospam at arcor.de Mon May 7 19:16:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 7 May 2007 21:16:15 +0200 Subject: Yum-presto utilities In-Reply-To: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> References: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> Message-ID: <20070507211615.60f9d581.mschwendt.tmp0701.nospam@arcor.de> On Mon, 07 May 2007 21:27:04 +0300, Jonathan Dieter wrote: > I've finally got a copy of createprestorepo that I'm (mostly) happy > with, along with a couple of other small utilites: > * prunerepo - This is actually FI's RepoPrune with a few small > modifications to make it useful for local mirrors. > http://www.lesbg.com/jdieter/presto/prunerepo-0.1.0.tar.bz2 The way you've modified it, you could also have used "repomanage" from yum-utils instead. Essentially, you've removed the feature that distinguishes RepoPrune from repomanage and which makes it ~4x faster. In short: RepoPrune only compares src.rpm EVRs and kills all orphaned binary rpms, which refer to a non-existant src.rpm. This only works with a repository, where every binary rpm must have a "mother" src.rpm. I was afraid of releasing it as an executable script, since without modifications it is destructive whenever a repository does not match the Fedora Extras repository layout. ;-) The three "assert" calls are one of the few safety measures in RepoPrune. They are better executed always and without "assert", because I think optimised Python code might drop them. From martin.sourada at seznam.cz Mon May 7 19:22:51 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 07 May 2007 21:22:51 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507191338.GB4803@nostromo.devel.redhat.com> References: <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <20070507191338.GB4803@nostromo.devel.redhat.com> Message-ID: <463F7C8B.1040303@seznam.cz> Bill Nottingham wrote: > Is the device you're looking for eth1 or something else? Yes, that's it. I should have mention it... Martin >> Also, I think under driver >> there should be bmc43xx_mac80211 since I have bcm43xx blacklisted and the >> NetworkManager indeed uses the bmc43xx_mac80211 driver. This behaviour >> seems quite weird to me. > > Shouldn't matter. > > Bill > From linville at redhat.com Mon May 7 19:30:14 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 7 May 2007 15:30:14 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F7C8B.1040303@seznam.cz> References: <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <20070507191338.GB4803@nostromo.devel.redhat.com> <463F7C8B.1040303@seznam.cz> Message-ID: <20070507193014.GE4761@redhat.com> On Mon, May 07, 2007 at 09:22:51PM +0200, Martin Sourada wrote: > Bill Nottingham wrote: > >Is the device you're looking for eth1 or something else? > Yes, that's it. I should have mention it... Well, the answer depends on which driver claims the device. The bcm43xx driver will call it "eth1" but the bcm43xx-mac80211 driver will call it "wlan0". I mentioned this situation earlier (maybe in this same thread). Unfortunately, upstream isn't ready to move "bcm43xx" to "bcm4301" (and make the accomanying PCI ID changes) yet. I'll have to noodle on this. John -- John W. Linville linville at redhat.com From jon at fedoraunity.org Mon May 7 19:53:26 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 07 May 2007 13:53:26 -0600 Subject: F7 Zope package In-Reply-To: <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <463F83B6.3010809@fedoraunity.org> Michael Schwendt wrote: > On Mon, 07 May 2007 10:55:08 -0500, David G. Mackay wrote: > > >> On Fri, 2007-05-04 at 19:40 +0200, Michael Schwendt wrote: >> >> >>> There is no zope and no plone for Fedora 7. We've removed the rpms from >>> the development repository some time ago on the package owner's request. >>> >> Sorry to hear that they were removed. If you need the functionality >> provided by Zope, then I don't know of any other open source product >> that comes close. >> >> >>> You refer to the old builds for Fedora 6, which have continued to >>> live in the development repo for some time. >>> >> I refer to the rpms that were on the F7-t3 dvd. >> > > Yes, an old FC-6 zope from Aug 30th, 2006, and older than the current FC-6 > package. The spec in Fedora Extras CVS has not been touched since then. > It wouldn't build. Why should I update it? (I actually asked and was told it was a waste of my time) Jonathan From jon at fedoraunity.org Mon May 7 19:56:52 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 07 May 2007 13:56:52 -0600 Subject: F7 Zope package In-Reply-To: <20070507185022.GA22316@orient.maison.lan> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> Message-ID: <463F8484.2070506@fedoraunity.org> Emmanuel Seyman wrote: > * David G. Mackay [07/05/2007 20:33] : > >> You keep saying that it's a massive effort. Would you point us to some >> documentation outlining the work required? Also, how much work is >> required of Red Hat employees? As a casual observer, I just don't see >> it, and I might be a lot more sympathetic if I had a better idea. >> > > This goes both ways. > If the work needed to package compat-python24 + zope + plone + any and > all packages needed to make the whole stack work is trivial, then > anybody can do it and make a third party repo with all the rpms and > maintain it until Zope 3 is included in Fedora. > Even when Zope 3 is available in F7, Plone will not be supported. I would expect this to be the case with other Zope projects/products too. In response to your "use a 3rd party" direction.. that is most likely what will happen. We all know where that leads, just look at the current state of all the addon repos for Fedora currently. (Yes, I know there is work to make it better and I've tried to be involved in this.) I'm all for having things well documented as to why it's *not* there and also want to be clear as to what I (the maintainer) have done to get the packages supported in Fedora 7. Jonathan From mackay_d at bellsouth.net Mon May 7 19:58:31 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 14:58:31 -0500 Subject: F7 Zope package In-Reply-To: <200705071445.17637.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> <200705071445.17637.jkeating@redhat.com> Message-ID: <1178567911.12774.104.camel@vorpal.macdev.com> On Mon, 2007-05-07 at 14:45 -0400, Jesse Keating wrote: > On Monday 07 May 2007 11:55:08 David G. Mackay wrote: > > I refer to the rpms that were on the F7-t3 dvd. > > Which don't actually work, and shouldn't be there, I don't think they were > there for t4. Well, I'm going to set up a qemu sandbox to check on a couple other issues, so I'll see. Dave From jdieter at gmail.com Mon May 7 20:07:20 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 07 May 2007 23:07:20 +0300 Subject: Yum-presto utilities In-Reply-To: <20070507211615.60f9d581.mschwendt.tmp0701.nospam@arcor.de> References: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> <20070507211615.60f9d581.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1178568440.9345.48.camel@jndwidescreen.lesbg.loc> On Mon, 2007-05-07 at 21:16 +0200, Michael Schwendt wrote: > On Mon, 07 May 2007 21:27:04 +0300, Jonathan Dieter wrote: > > > I've finally got a copy of createprestorepo that I'm (mostly) happy > > with, along with a couple of other small utilites: > > > * prunerepo - This is actually FI's RepoPrune with a few small > > modifications to make it useful for local mirrors. > > http://www.lesbg.com/jdieter/presto/prunerepo-0.1.0.tar.bz2 > > The way you've modified it, you could also have used "repomanage" from > yum-utils instead. Essentially, you've removed the feature that > distinguishes RepoPrune from repomanage and which makes it ~4x faster. In > short: RepoPrune only compares src.rpm EVRs and kills all orphaned binary > rpms, which refer to a non-existant src.rpm. This only works with > a repository, where every binary rpm must have a "mother" src.rpm. > Yeah, don't mind me. I seem to enjoy re-inventing the wheel. :) Ah, well, it didn't take that long as I mostly just pulled out the code that matches the "mother" src.rpm to the binary rpms. The only reason I posted it was for completeness; it's what I'm using for the test presto server. Prunedrpms needs some form of repository management before it can recognize the old drpms, and prunerepo (as well as repomanage) fits the bill. > I was afraid of releasing it as an executable script, since without > modifications it is destructive whenever a repository does not match the > Fedora Extras repository layout. ;-) > > The three "assert" calls are one of the few safety measures in RepoPrune. > They are better executed always and without "assert", because I think > optimised Python code might drop them. > They're just there to test and make sure that compareEVR is working the way it's supposed to? Better safe than sorry, though I wouldn't expect compareEVR to suddenly reverse how it works...right? Jonathan -------------- 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 mackay_d at bellsouth.net Mon May 7 20:08:52 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 15:08:52 -0500 Subject: F7 Zope package In-Reply-To: <20070507185022.GA22316@orient.maison.lan> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> Message-ID: <1178568532.12774.115.camel@vorpal.macdev.com> On Mon, 2007-05-07 at 20:50 +0200, Emmanuel Seyman wrote: > Users will just go to a website, click on a rpm, click twice on "OK" > and then run "yum install zope" (or whatever the equivalent for their > favourite backend is). > > Problem solved. Which is pretty much what I expect will happen. I'm more concerned with what I perceive the Fedora leadership's response to the situation. We have a package that's been available in extras that won't be available directly from Fedora for F7. I wonder how large the Zope-Fedora cross-section of users would have to be to make it worth the effort. For that matter, does anyone have an idea how large it is? Dave From rdieter at math.unl.edu Mon May 7 20:10:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 07 May 2007 15:10:47 -0500 Subject: KDE SIG can use your help References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> <463CF460.5040702@math.unl.edu> Message-ID: Rex Dieter wrote: > Free punch and pie for all who attend the next KDE SIG irc meeting! > http://fedoraproject.org/wiki/SIGs/KDE > (not that you have to wait till then to contribute anything...) :) Arg, opened my big mouth, turns out I'll be on a plane to the RH Summit much of tomorrow, so will unlikely be able to attend any KDE SIG meetings myself. -- Rex, sad to miss the punch'n pie. From emmanuel.seyman at club-internet.fr Mon May 7 20:11:18 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 7 May 2007 22:11:18 +0200 Subject: F7 Zope package In-Reply-To: <463F8484.2070506@fedoraunity.org> References: <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <463F8484.2070506@fedoraunity.org> Message-ID: <20070507201118.GA22999@orient.maison.lan> * Jonathan Steffan [07/05/2007 22:07] : > > In response to your "use a 3rd party" direction.. that is most likely > what will happen. We all know where that leads, just look at the current > state of all the addon repos for Fedora currently. Actually, I have no idea where that leads and I'ld be very surprised if I were the only one. Could you fill in the blanks ? Emmanuel From jon at fedoraunity.org Mon May 7 20:25:59 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 07 May 2007 14:25:59 -0600 Subject: F7 Zope package In-Reply-To: <20070507201118.GA22999@orient.maison.lan> References: <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <463F8484.2070506@fedoraunity.org> <20070507201118.GA22999@orient.maison.lan> Message-ID: <463F8B57.5000308@fedoraunity.org> Emmanuel Seyman wrote: > * Jonathan Steffan [07/05/2007 22:07] : > >> In response to your "use a 3rd party" direction.. that is most likely >> what will happen. We all know where that leads, just look at the current >> state of all the addon repos for Fedora currently. >> We are going to end up with N number of 3rd party repos providing Zope/Plone and thus python 2.4. Currently, 3rd party Fedora repos have a track record of not working together (this is changing! and I in no way want to put down the current efforts) and all that does is lead to lot more issues then some extra overhead managing an "official" python 2.4 package(s). Basically, this is going to take the headache/overhead from the Fedora devs and put in on the Community based support structure. > > Actually, I have no idea where that leads and I'ld be very surprised > if I were the only one. Could you fill in the blanks ? > > Emmanuel > > From emmanuel.seyman at club-internet.fr Mon May 7 20:36:34 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 7 May 2007 22:36:34 +0200 Subject: F7 Zope package In-Reply-To: <1178568532.12774.115.camel@vorpal.macdev.com> References: <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <1178568532.12774.115.camel@vorpal.macdev.com> Message-ID: <20070507203634.GA23167@orient.maison.lan> * David G. Mackay [07/05/2007 22:11] : > > We > have a package that's been available in extras that won't be available > directly from Fedora for F7. Retired packages have been around since day one (well, day two really but you know what I mean...) and "Depends on a legacy library that no longer ships in Fedora" is just one of a long list of reasons (*cough* xmms *cough*). The cleanest thing to do is document it ASAP so that people using said packages can have as much time as possible to find alternate solutions (whether that be moving to another distribution, joining forces to maintain a third party repo or anything else), IMHO. Emmanuel From mschwendt.tmp0701.nospam at arcor.de Mon May 7 20:37:55 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 7 May 2007 22:37:55 +0200 Subject: F7 Zope package In-Reply-To: <463F83B6.3010809@fedoraunity.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> <463F83B6.3010809@fedoraunity.org> Message-ID: <20070507223755.7c151a9e.mschwendt.tmp0701.nospam@arcor.de> On Mon, 07 May 2007 13:53:26 -0600, Jonathan Steffan wrote: > Michael Schwendt wrote: > > On Mon, 07 May 2007 10:55:08 -0500, David G. Mackay wrote: > > > > > >> On Fri, 2007-05-04 at 19:40 +0200, Michael Schwendt wrote: > >> > >> > >>> There is no zope and no plone for Fedora 7. We've removed the rpms from > >>> the development repository some time ago on the package owner's request. > >>> > >> Sorry to hear that they were removed. If you need the functionality > >> provided by Zope, then I don't know of any other open source product > >> that comes close. > >> > >> > >>> You refer to the old builds for Fedora 6, which have continued to > >>> live in the development repo for some time. > >>> > >> I refer to the rpms that were on the F7-t3 dvd. > >> > > > > Yes, an old FC-6 zope from Aug 30th, 2006, and older than the current FC-6 > > package. The spec in Fedora Extras CVS has not been touched since then. > > > It wouldn't build. Why should I update it? (I actually asked and was > told it was a waste of my time) Why would you keep and offer old builds which don't work? My initial reply was about this: | It was nice to see that zope is one of the packages available for | installation in F7. The old builds ought to have been removed before the release of F7T1. Both zope and plone have been in the broken upgrade paths report for a long time without that FESCo has been made aware of the problem with Python 2.5. Further, do the release notes cover the removal yet? (searching the Wiki I don't think they do) From bpepple at fedoraproject.org Mon May 7 20:55:28 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 07 May 2007 16:55:28 -0400 Subject: F7 Zope package In-Reply-To: <20070507223755.7c151a9e.mschwendt.tmp0701.nospam@arcor.de> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> <463F83B6.3010809@fedoraunity.org> <20070507223755.7c151a9e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1178571328.11094.3.camel@lincoln> On Mon, 2007-05-07 at 22:37 +0200, Michael Schwendt wrote: > > Further, do the release notes cover the removal yet? > (searching the Wiki I don't think they do) http://fedoraproject.org/wiki/Docs/Beats/PackageNotes /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jon at fedoraunity.org Mon May 7 21:00:07 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 07 May 2007 15:00:07 -0600 Subject: F7 Zope package In-Reply-To: <20070507223755.7c151a9e.mschwendt.tmp0701.nospam@arcor.de> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070504194015.7e68a82d.mschwendt.tmp0701.nospam@arcor.de> <1178553308.12774.9.camel@vorpal.macdev.com> <20070507210336.b5015239.mschwendt.tmp0701.nospam@arcor.de> <463F83B6.3010809@fedoraunity.org> <20070507223755.7c151a9e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <463F9357.6090509@fedoraunity.org> Michael Schwendt wrote: > On Mon, 07 May 2007 13:53:26 -0600, Jonathan Steffan wrote: > > >> Michael Schwendt wrote: >> >>> On Mon, 07 May 2007 10:55:08 -0500, David G. Mackay wrote: >>> >>> >>> >>>> On Fri, 2007-05-04 at 19:40 +0200, Michael Schwendt wrote: >>>> >>>> >>>> >>>>> There is no zope and no plone for Fedora 7. We've removed the rpms from >>>>> the development repository some time ago on the package owner's request. >>>>> >>>>> >>>> Sorry to hear that they were removed. If you need the functionality >>>> provided by Zope, then I don't know of any other open source product >>>> that comes close. >>>> >>>> >>>> >>>>> You refer to the old builds for Fedora 6, which have continued to >>>>> live in the development repo for some time. >>>>> >>>>> >>>> I refer to the rpms that were on the F7-t3 dvd. >>>> >>>> >>> Yes, an old FC-6 zope from Aug 30th, 2006, and older than the current FC-6 >>> package. The spec in Fedora Extras CVS has not been touched since then. >>> >>> >> It wouldn't build. Why should I update it? (I actually asked and was >> told it was a waste of my time) >> > > Why would you keep and offer old builds which don't work? > I'm sorry. I am new to the Fedora infrastructure. I didn't know what to do right away. I requested the remove when it was addressed to me. I half hoped there would be a solution that would not require me to remove the builds. Anyways, they are removed. > My initial reply was about this: > > | It was nice to see that zope is one of the packages available for > | installation in F7. > > The old builds ought to have been removed before the release of F7T1. > Yes, I'm sorry I didn't promptly give up on things. > Both zope and plone have been in the broken upgrade paths report for a > long time without that FESCo has been made aware of the problem with > Python 2.5. > FESCo would have been notified at the same time I was... At lest I had expected. This might be a flawed assumption on my part. Extras Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:41:25 CST 2007 is the first I was aware of the possible issue, other then my devel branch not building. It was directly requested I removed the packages on April 10th. After trying to get compat packages included I gave up and finally requested the removal. > Further, do the release notes cover the removal yet? > (searching the Wiki I don't think they do) > I don't personally know. I don't think it will make it into the on-image release notes but I would expect something to be added to the wiki? Jonathan Steffan From miles.lane at gmail.com Mon May 7 21:01:45 2007 From: miles.lane at gmail.com (Miles Lane) Date: Mon, 7 May 2007 14:01:45 -0700 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507193014.GE4761@redhat.com> References: <20070507124606.GA4761@redhat.com> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <20070507191338.GB4803@nostromo.devel.redhat.com> <463F7C8B.1040303@seznam.cz> <20070507193014.GE4761@redhat.com> Message-ID: On 5/7/07, John W. Linville wrote: > On Mon, May 07, 2007 at 09:22:51PM +0200, Martin Sourada wrote: > > Bill Nottingham wrote: > > >Is the device you're looking for eth1 or something else? > > Yes, that's it. I should have mention it... > > Well, the answer depends on which driver claims the device. The > bcm43xx driver will call it "eth1" but the bcm43xx-mac80211 driver > will call it "wlan0". > > I mentioned this situation earlier (maybe in this same thread). > Unfortunately, upstream isn't ready to move "bcm43xx" to "bcm4301" (and > make the accomanying PCI ID changes) yet. I'll have to noodle on this. I am not sure that there is still a reason to keep the older driver around. It works on my old bmc4306 rev. 2. Do we know there are still bcm43xx devices that the new driver won't work for? Also, the issue of having both drivers looking to handle the same device IDs hasn't been resolved. That is, I've heard that raised as an issue. Miles From mackay_d at bellsouth.net Mon May 7 21:10:20 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Mon, 07 May 2007 16:10:20 -0500 Subject: F7 Zope package In-Reply-To: <20070507203634.GA23167@orient.maison.lan> References: <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <1178568532.12774.115.camel@vorpal.macdev.com> <20070507203634.GA23167@orient.maison.lan> Message-ID: <1178572220.12774.146.camel@vorpal.macdev.com> On Mon, 2007-05-07 at 22:36 +0200, Emmanuel Seyman wrote: > Retired packages have been around since day one (well, day two really > but you know what I mean...) and "Depends on a legacy library that no > longer ships in Fedora" is just one of a long list of reasons (*cough* > xmms *cough*). Yeah, next time I'm at the watering hole, I'll have to hoist one in memory of Fedora Legacy. And not shipping multimedia components that are illegal in the US is a lot more palatable than not shipping a product because it's inconvenient to package a dependency. > The cleanest thing to do is document it ASAP so that people using said > packages can have as much time as possible to find alternate solutions > (whether that be moving to another distribution, joining forces to > maintain a third party repo or anything else), IMHO. I doubt that there'll be a problem finding a repo that will host Zope. And, I think that we're getting the word out now. Dave From linville at redhat.com Mon May 7 22:47:04 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 7 May 2007 18:47:04 -0400 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: References: <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <20070507191338.GB4803@nostromo.devel.redhat.com> <463F7C8B.1040303@seznam.cz> <20070507193014.GE4761@redhat.com> Message-ID: <20070507224704.GA17998@redhat.com> On Mon, May 07, 2007 at 02:01:45PM -0700, Miles Lane wrote: > On 5/7/07, John W. Linville wrote: > >On Mon, May 07, 2007 at 09:22:51PM +0200, Martin Sourada wrote: > >I mentioned this situation earlier (maybe in this same thread). > >Unfortunately, upstream isn't ready to move "bcm43xx" to "bcm4301" (and > >make the accomanying PCI ID changes) yet. I'll have to noodle on this. > > I am not sure that there is still a reason to keep the older driver around. > It works on my old bmc4306 rev. 2. Do we know there are still bcm43xx > devices that the new driver won't work for? Yes. BCM4301 and BCM4303 don't work with the new driver. This is because they don't have the memory resources required to load the v4.x firmware required by the new driver. John -- John W. Linville linville at redhat.com From poelstra at redhat.com Mon May 7 22:54:12 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 07 May 2007 15:54:12 -0700 Subject: Release Eng Meeting Recap 2007-May-07 Message-ID: <463FAE14.9040102@redhat.com> http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-may-07 == Status of the Merge == * f13 * I'm poking at some software bill wrote a while ago to build package repos out of Koji. * I'm somewhat close to having a repo of packages created in a test environment. * expected to be at this point on Thursday, but well, we all forgot about ppc64 * some of the extras importing didn't go as quickly as I 'd hoped. * plan for now I _think_ it will be koji -> repo of packages as rawhide * people can use pungi to make installable trees, I'll probably make one somewhere. * I need to work on the multilib stuff to make sure it's multilibbing like distill did. * no plan yet around needsign/package signing * ppc64 things are still uploading/importing; build status is unknown * found a few things that didn't have matching NVRs did not build--libupnp-1.4.3-1.fc7 for example * warren * volunteers to be "bit mover" while f13 is at the Red Hat Summit * jwb * need a document explaining how to get your package into the release... something like "If you did FOO before the merge, here is how to do FOO now" * will take a crack at the before/after document * lengthy technical discussion around using auto-add script and building packages with koji * all builds must be performed manually * no specific decisions were made * notting will work on getting automated builds working over the next three days * notting * there's some stuff that won't build due to various errors - i've filed some bugs, but still have more to file * ocaml and maven are being worked on * things that BR mono will need ifarched * i'll try and attack maven again later *ugh* * everything on the missing dep tracker should be OK now * 1224 SRPMS built so far, give or take a few * using ibiblio--mmcgrath and f13 will discuss at Summit == mirror layout and getting bits to said mirror == * f13 * Since we're still doing Extras for 6/5, perhaps we just tie into that rsync process to get development synced as well? Compse rawhide to the place that is servied by buildsys: rsync? * symlinks or hardlinks are the plan. * nirik: proposed mirror layout changes look sane * No formal decisions made == Building Rawhide == * not going to have a post-fc7 rawhide until fc7 goes gold * important to be able to use rawhide to tackle F7 blocker BZs * rawhide push will be good for checking EVR and broken deps issues. * can't make rawhide automated today; will try to enable eventually. No date set. * nirik: should we eventually revisit signing rawhide? * would possibly make it so yum could detect what repo a package was from and help with all the repotag nightmares? * f13: * I'd like rawhide to be signed, with the buildsystem throwaway key but that'll involve an automated signing system. * we have a signing system; manual or automated * discussion of getting a "real" rawhide working before we branch and also how/when to branch * no decision reached == F7 Blocker List == * https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150226&hide_resolved=1 * 104 open bugs * 17 Days until release * wwoods * will do some blocker bug triage * will loudly announce * some bugs might not be getting addressed because developers are waiting for builds of rawhide == Schedule Slip == * f13 * not entirely convinced we'll be ready for deep freeze by Thursday, though probably 'frozen enough to branch cvs' * okay with more slipping because what we just did (merge) was _huge_ and we're not coming back online as fast as I hoped we would. * can't feel good about deep freezing only a couple days after a merged repo shows up. * decision reached: * slip 1 week on the freeze and re-evaluate blockers next week * no explicit decision made on GA date * state that merger took longer/more effort than panned for * need more time for rawhide to settle down a bit and maintianers to get their builds in. == Build System Outage == * outage on Wed for about an hour and a half. We're getting some new filers installed. * Time: TBD From spng.yang at gmail.com Tue May 8 02:20:02 2007 From: spng.yang at gmail.com (Ken YANG) Date: Tue, 08 May 2007 10:20:02 +0800 Subject: yumdownloader do nothing Message-ID: <463FDE52.1070901@gmail.com> hi all: i am in FC7 Rawhide, and the yum-utils is: yum-utils-1.1.3-1.fc7 when i use: yumdownloader --enablerepo development-source --source selinux-policy the output is: Loading "installonlyn" plugin Loading "skip-broken" plugin development-source 100% |=========================| 951 B 00:00 primary.xml.gz 100% |=========================| 304 kB 00:03 developmen: ################################################## 1150/1150 Excluding Packages in global exclude list Finished there is nothing download, i also try: yumdownloader --enablerepo development-source --source selinux-policy-2.6.1-1.fc7.src.rpm but obviously, the argument is wrong. so why yumdownloader can not download correspoding SRPM? thank in advance From davehoz at gmail.com Tue May 8 04:49:05 2007 From: davehoz at gmail.com (David Hunter) Date: Tue, 8 May 2007 14:49:05 +1000 Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. Message-ID: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> When I try to load the page at http://www.zooweekly.com.au/zootube/, epiphany-2.18.1-2.fc7 crashes. Also occurs on Firefox firefox-2.0.0.3-4.fc7. Could it be a website issue or an issue with the software in Fedora. The gnome crash buddy is not activated with the crash of either program. -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at scrye.com Tue May 8 04:53:01 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 7 May 2007 22:53:01 -0600 Subject: Yum-presto utilities In-Reply-To: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> References: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> Message-ID: <20070507225301.06c1eb03@ghistelwchlohm.scrye.com> On Mon, 07 May 2007 21:27:04 +0300 jdieter at gmail.com (Jonathan Dieter) wrote: > I've finally got a copy of createprestorepo that I'm (mostly) happy > with, along with a couple of other small utilites: > > * createprestorepo - Creates a Presto repository from rpms and drpms. > http://www.lesbg.com/jdieter/presto/createprestorepo-0.1.0.tar.bz2 > > * prunerepo - This is actually FI's RepoPrune with a few small > modifications to make it useful for local mirrors. > http://www.lesbg.com/jdieter/presto/prunerepo-0.1.0.tar.bz2 > > * prunedrpms - A small utility to remove all drpms that point to rpms > that are no longer in the local repository (probably because > they've been removed by prunerepo above). > http://www.lesbg.com/jdieter/presto/prunedrpms-0.1.0.tar.bz2 > > This should be all you need to create presto repositories for your own > repositories. If you need more information about Presto, there's > http://hosted.fedoraproject.org/projects/presto. Are you planning on adding these to the yum-presto package? Or adding a new 'presto-utils'? Or each one? I think it would be good if these could be available via yum... > Jonathan kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Tue May 8 05:03:30 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 8 May 2007 05:03:30 +0000 (UTC) Subject: Selinux and package guidelines References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> Message-ID: dragoran gmail.com> writes: > David Woodhouse wrote: > > [...] > > *SElinux*, > > [..] > thx for mentioning this I suggest that any package that create avcs > should not pass a review. We have suchs packages in extras and nothing > in the review process takes care of selinux integration which is wrong. So you want to force reviewers to run with SELinux enabled? That's going to reduce the number of reviewers significantly and increase the load on the review queue even more. I for one have SELinux disabled (completely, so I don't get even permissive AVCs) and I'm surely not the only one. Reviewing is already tedious enough as it stands (it took me over an hour to review Strigi, and it already had some quick pre-review comments by Rex Dieter and me). (It does work though, for example I caught some plugin .so files being mistaken for symlinks and thus accidentally shipped in strigi-devel rather than in the main strigi package, that would definitely have broken things for the end user. So I'm not complaining about the current process, just about your suggestion to add that SELinux requirement.) Kevin Kofler From bojan at rexursive.com Tue May 8 05:08:18 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 8 May 2007 05:08:18 +0000 (UTC) Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> Message-ID: David Hunter gmail.com> writes: > When I try to load the page at http://www.zooweekly.com.au/zootube/, epiphany-2.18.1-2.fc7 crashes. Also occurs on Firefox firefox-2.0.0.3-4.fc7. Could it be a website issue or an issue with the software in Fedora. The gnome crash buddy is not activated with the crash of either program. The best thing to do would be to open a bug report in Bugzilla. You can try running "firefox -g" after installing firefox-debuginfo RPM and then give the backtrace output. In any event, the theory is that applications (i.e. FF/Epi) should be able to handle bad data (i.e. web site content) gracefully and not crash. -- Bojan From fedora at leemhuis.info Tue May 8 05:31:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 May 2007 07:31:37 +0200 Subject: Selinux and package guidelines In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> Message-ID: <46400B39.1090307@leemhuis.info> On 08.05.2007 07:03, Kevin Kofler wrote: > dragoran gmail.com> writes: >> David Woodhouse wrote: >>> [...] >>> *SElinux*, >>> [..] >> thx for mentioning this I suggest that any package that create avcs >> should not pass a review. We have suchs packages in extras and nothing >> in the review process takes care of selinux integration which is wrong. > So you want to force reviewers to run with SELinux enabled? That's going to > reduce the number of reviewers significantly and increase the load on the > review queue even more. I for one have SELinux disabled (completely, so I don't > get even permissive AVCs) and I'm surely not the only one. Reviewing is already > tedious enough as it stands (it took me over an hour to review Strigi, and it > already had some quick pre-review comments by Rex Dieter and me). (It does work > though, for example I caught some plugin .so files being mistaken for symlinks > and thus accidentally shipped in strigi-devel rather than in the main strigi > package, that would definitely have broken things for the end user. So I'm not > complaining about the current process, just about your suggestion to add that > SELinux requirement.) Kevin and David both have good points IMHO. A solution afaics might behave some kind of (semi-)automatic SELinux testsuite running on a testmachine somewhere where users can submit packages for testing. And a SIG that users can ask in case of problem -- but we have a selinux mailing list, which should be enough probably. And maybe we should suggest somehow to packagers and reviewers to look out for SELinux trouble (but not as MUST or SHOULD; more as a kine of "best practices" document). CU thl From debarshi.ray at gmail.com Tue May 8 06:39:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 May 2007 12:09:55 +0530 Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. In-Reply-To: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> Message-ID: <3170f42f0705072339x22df271eu4bcdca38308a0ba5@mail.gmail.com> > When I try to load the page at > http://www.zooweekly.com.au/zootube/, epiphany-2.18.1-2.fc7 > crashes. Also occurs on Firefox firefox-2.0.0.3-4.fc7. It works for me on i386. I have firefox-2.0.0.3-4.fc7 installed, but not Epiphany. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jdieter at gmail.com Tue May 8 07:58:45 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 08 May 2007 10:58:45 +0300 Subject: Yum-presto utilities In-Reply-To: <20070507225301.06c1eb03@ghistelwchlohm.scrye.com> References: <1178562424.9345.38.camel@jndwidescreen.lesbg.loc> <20070507225301.06c1eb03@ghistelwchlohm.scrye.com> Message-ID: <1178611125.9345.62.camel@jndwidescreen.lesbg.loc> On Mon, 2007-05-07 at 22:53 -0600, Kevin Fenzi wrote: > Are you planning on adding these to the yum-presto package? > Or adding a new 'presto-utils'? Or each one? > > I think it would be good if these could be available via yum... > > kevin I am planning on packaging up createprestorepo and prunedrpms (as mentioned elsewhere, prunerepo does the same thing as repomanage) and putting them into extras, but that could be a while. I'll let you know when I need someone to review them, though. ;) I just wanted to make sure I got them out there so people can look at them, use them, tear them apart, etc. Jonathan -------------- 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 mighty.klingon at gmail.com Tue May 8 08:56:54 2007 From: mighty.klingon at gmail.com (Shashank Sharma) Date: Tue, 8 May 2007 14:26:54 +0530 Subject: Possible changes between F7T4 and the final Fedora release Message-ID: <3f15e6450705080156n20a8796fic3fd75c5d24d3324@mail.gmail.com> Hi list, I have a question about the final Fedora release on May 24. The thing is, I downloaded F7T1 and noticed that it had no terminal under the Applications -> Accessories menu. Same with F7T2. This was probably a bug or whatever and I saw several people complaining about this. Now in test 4, the Terminal is available under Applications -> System Tools. Have me made up our minds? Is the position now final or could it change still when the final is released on May 24th? Also, I was wondering what kind of work is being done on Fedora currently? I mean, I know there won't be any new features apart from what was in F7T4. So my question is: are you working on things like fonts, graphics, wallpapers, and such, or just fixing bugs and everything else like layout of the tools (see analogy about the terminal) final? Another thing that bothered me about the layout is the System -> Preferences menu. It was different in Test1, test2 and test4. Have we finally settled on what I see in Test 4 (categorized preferences menu). In summary, my question is whether or not Fedora 7 will look the same as F7T4 with bug fixes or will Fedora 7 have a different look and feel? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at deadbabylon.de Tue May 8 09:07:03 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 8 May 2007 11:07:03 +0200 Subject: KDE SIG can use your help In-Reply-To: References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> <463CF460.5040702@math.unl.edu> Message-ID: <20070508110703.41107fd7@localhost.localdomain> Am Mon, 07 May 2007 15:10:47 -0500 schrieb Rex Dieter : > Rex Dieter wrote: > > > Free punch and pie for all who attend the next KDE SIG irc meeting! > > http://fedoraproject.org/wiki/SIGs/KDE > > (not that you have to wait till then to contribute anything...) :) > > Arg, opened my big mouth, turns out I'll be on a plane to the RH > Summit much of tomorrow, so will unlikely be able to attend any KDE > SIG meetings myself. Uh. I hope there still will be enough people to actually have a meeting. Or we should meet at another time this week. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Tue May 8 09:52:02 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 8 May 2007 05:52:02 -0400 Subject: F7 Zope package In-Reply-To: <1178550045.2558.5.camel@aglarond.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> Message-ID: <20070508095202.GA11993@devserv.devel.redhat.com> On Mon, May 07, 2007 at 11:00:45AM -0400, Jeremy Katz wrote: > that once Zope supports it that's not enough and that there is still > plone and who knows how long that will be. And what about when we move > to python 2.6? We've then dug the hole that "well, we'll do compat > shims so that you don't have to keep up" and someone has to do it again. > > Compat packages are a crutch that massively magnify the amount of effort > required to support a distribution and that never goes away. How about putting a copy of ancient-python into the Zope package itself so that the mess only affects those who use/maintain it ? From opensource at till.name Tue May 8 10:19:43 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 12:19:43 +0200 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <1178537254.11851.155.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463F0989.4030403@hhs.nl> <1178537254.11851.155.camel@pmac.infradead.org> Message-ID: <200705081219.44853.opensource@till.name> On Mo Mai 7 2007, David Woodhouse wrote: > So the only people who would be excluded would be those who are > unwilling or unable to seek help from others when the task before them > exceeds their abilities. Which would probably be a good thing. And the people that do not get enough help. I once asked how to get something to work because of denied execmod. I got a response that it needs text_rel_shlib_t or something similiar, but there was no help how to do this correctly in a spec. http://fedoraproject.org/wiki/PackagingDrafts/SELinux helped a little but was/is not up to date and also the work needed for something this simple is way to much imho. One needs to create at least 2 not empty files and have a bunch of scriptlets and some other selinux code. This whole complexity only leads to more packaging errors. What should be there is help, procedures and helpful tools for a maintainer to be able to easily package software. Regards, Till From dev at nigelj.com Tue May 8 10:40:10 2007 From: dev at nigelj.com (Nigel Jones) Date: Tue, 08 May 2007 22:40:10 +1200 Subject: KDE SIG can use your help In-Reply-To: <20070508110703.41107fd7@localhost.localdomain> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> <463CF460.5040702@math.unl.edu> <20070508110703.41107fd7@localhost.localdomain> Message-ID: <4640538A.2060401@nigelj.com> Sebastian Vahl wrote: > Am Mon, 07 May 2007 15:10:47 -0500 > schrieb Rex Dieter : > >> Rex Dieter wrote: >> >>> Free punch and pie for all who attend the next KDE SIG irc meeting! >>> http://fedoraproject.org/wiki/SIGs/KDE >>> (not that you have to wait till then to contribute anything...) :) >> Arg, opened my big mouth, turns out I'll be on a plane to the RH >> Summit much of tomorrow, so will unlikely be able to attend any KDE >> SIG meetings myself. > > Uh. I hope there still will be enough people to actually have a > meeting. Or we should meet at another time this week. Personally, the problem I have is none of the meeting times really suit me. 1600UTC is 4am on a Wednesday, and 2000UTC is 8am on a Wednesday (which I could attend easily as typically I don't need to go into town on Wednesdays). I'll try and attend 2000UTC though. N.J. From j.w.r.degoede at hhs.nl Tue May 8 10:58:54 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 12:58:54 +0200 Subject: F7 Zope package In-Reply-To: <20070508095202.GA11993@devserv.devel.redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> Message-ID: <464057EE.1000201@hhs.nl> Alan Cox wrote: > On Mon, May 07, 2007 at 11:00:45AM -0400, Jeremy Katz wrote: >> that once Zope supports it that's not enough and that there is still >> plone and who knows how long that will be. And what about when we move >> to python 2.6? We've then dug the hole that "well, we'll do compat >> shims so that you don't have to keep up" and someone has to do it again. >> >> Compat packages are a crutch that massively magnify the amount of effort >> required to support a distribution and that never goes away. > > How about putting a copy of ancient-python into the Zope package itself so that > the mess only affects those who use/maintain it ? > Yes that would be an excellent solution but the main python maintainer is against this (as he still fears extra BZ traffic because of this). And for some reason beyond my comprehension FESco has decided to vote with the python maintainer and blacklist py2.4 in any way. This is completely un-understandable, as this will serious hurt end users for little good reasons?? Could FESco please explain itself with regard to this in detail? What ever happend to a package is ok, as long as it is free software, not legally encumbered and someone is willing to maintain it? Note I'm not a zope user, but I just don't like to see (some of) our end users getting burned this way. Regards, Hans From rdieter at math.unl.edu Tue May 8 11:19:33 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 08 May 2007 06:19:33 -0500 Subject: KDE SIG can use your help In-Reply-To: <4640538A.2060401@nigelj.com> References: <3da3b5b40705041642h5150eb56mffb475c3719c0bf9@mail.gmail.com> <463CDE76.2090005@redhat.com> <3da3b5b40705051324j1ebdb23an5d1f5d6d88de1c38@mail.gmail.com> <463CF460.5040702@math.unl.edu> <20070508110703.41107fd7@localhost.localdomain> <4640538A.2060401@nigelj.com> Message-ID: <46405CC5.2020100@math.unl.edu> Nigel Jones wrote: > Sebastian Vahl wrote: >> Uh. I hope there still will be enough people to actually have a >> meeting. Or we should meet at another time this week. Let's see about meeting Thurs sometime. > Personally, the problem I have is none of the meeting times really suit > me. 1600UTC is 4am on a Wednesday, and 2000UTC is 8am on a Wednesday > (which I could attend easily as typically I don't need to go into town > on Wednesdays). Good point, feel free add/create different meeting times. I've updated http://fedoraproject.org/wiki/SIGs/KDE accordingly to say: "Add your name to which times you are available and/or work best or even create a new meeting time, but remember whoever is listed first needs to commit to lead the meeting at that time slot." -- Rex From buildsys at fedoraproject.org Tue May 8 11:04:26 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 8 May 2007 07:04:26 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-08 Message-ID: <20070508110426.61BF0152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 35 bitlbee-1.0.3-6.fc6 cyphesis-0.5.12-1.fc6 duplicity-0.4.2-7.fc6 eggdrop-1.6.18-8.fc6 em8300-0.16.2-1.fc6 em8300-kmod-0.16.2-1.2.6.20_1.2948.fc6 fortune-firefly-2.1.2-2.fc6 gallery2-2.2-0.2.svn20070506.fc6 gnome-chemistry-utils-0.6.5-2.fc6 htmldoc-1.8.27-2.fc6 initng-0.6.10-2.fc6 initng-ifiles-0.1.2-1.fc6 libopm-0.1-4.20050731cvs.fc6 librsync-0.9.7-10.fc6 libupnp-1.4.6-1.fc6 mimedefang-2.62-2.fc6 moin-1.5.7-2.fc6 moodle-1.6.5-4.fc6 opensc-0.11.2-2.fc6 perl-File-Next-0.40-1.fc6 perl-Module-Refresh-0.13-1.fc6 perl-Net-LibIDN-0.09-3.fc6 perl-Pod-Strip-1.02-2.fc6 perl-POE-Component-SSLify-0.07-1.fc6 perl-Text-Glob-0.08-1.fc6 perl-Want-0.14-1.fc6 php-idn-1.2-2.fc6 php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc6 NEW php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.fc6 : Meta-element which holds any other element in a grid php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc6 NEW ruby-amazon-0.9.2-3.fc6 : Ruby interface to Amazon Web Services NEW schismtracker-0.5-0.4.rc1.fc6 : Sound module composer/player tcpick-0.2.1-12.fc6 NEW tdom-0.8.0-2.fc6 : DOM parser for Tcl NEW widelands-0-0.3.build10.fc6 : Open source realtime-strategy game Packages built and released for Fedora Extras 5: 26 bitlbee-1.0.3-6.fc5 duplicity-0.4.2-7.fc5 eggdrop-1.6.18-8.fc5 fortune-firefly-2.1.2-2.fc5 gallery2-2.2-0.2.svn20070506.fc5 gnome-chemistry-utils-0.6.5-2.fc5 htmldoc-1.8.27-2.fc5 libopm-0.1-4.20050731cvs.fc5 librsync-0.9.7-10.fc5 libupnp-1.4.6-1.fc5 mimedefang-2.62-2.fc5 moin-1.5.7-2.fc5 moodle-1.6.5-4.fc5 perl-File-Next-0.40-1.fc5 perl-Module-Refresh-0.13-1.fc5 perl-Net-LibIDN-0.09-3.fc5 perl-Pod-Strip-1.02-2.fc5 perl-Text-Glob-0.08-1.fc5 perl-Want-0.14-1.fc5 php-idn-1.2-2.fc5 php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc5 NEW php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.fc5 : Meta-element which holds any other element in a grid php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc5 NEW ruby-amazon-0.9.2-3.fc5 : Ruby interface to Amazon Web Services NEW schismtracker-0.5-0.4.rc1.fc5 : Sound module composer/player tcpick-0.2.1-12.fc5 Changes in Fedora Extras 6: bitlbee-1.0.3-6.fc6 ------------------- * Mon May 07 2007 Robert Scheck 1.0.3-6 - Rebuilt cyphesis-0.5.12-1.fc6 --------------------- * Mon May 07 2007 Wart 0.5.12-1 - Update to 0.5.12 duplicity-0.4.2-7.fc6 --------------------- * Mon May 07 2007 Robert Scheck 0.4.2-7 - Rebuild eggdrop-1.6.18-8.fc6 -------------------- * Mon May 07 2007 Robert Scheck 1.6.18-8 - Rebuild * Tue Mar 13 2007 Robert Scheck 1.6.18-7 - Rebuild for bind 9.4.0 * Wed Feb 14 2007 Robert Scheck 1.6.18-6 - Rebuild for tcl 8.4 em8300-0.16.2-1.fc6 ------------------- * Mon May 07 2007 Ville Skytt? - 0.16.2-1 - 0.16.2. * Wed Apr 04 2007 Ville Skytt? - 0.16.2-0.1.rc1 - 0.16.2-rc1. - Update examples in README-modprobe.conf. em8300-kmod-0.16.2-1.2.6.20_1.2948.fc6 -------------------------------------- * Mon May 07 2007 Ville Skytt? - 0.16.2-1 - 0.16.2. * Tue May 01 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2948.fc6. * Fri Apr 13 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2944.fc6. * Fri Mar 23 2007 Ville Skytt? - 0.16.1-3 - Re-enable xen, build for kernel 2.6.20-1.2933.fc6. * Thu Mar 15 2007 Ville Skytt? - 0.16.1-2 - Build for kernel 2.6.20-1.2925.fc6 and adjust variants for it (add PAE-debug for i686, debug for i686 and x86_64, disable xen). - Update kmodtool to 0.10.13. fortune-firefly-2.1.2-2.fc6 --------------------------- * Mon May 07 2007 Karen Pease - 2.1.2.2 - Upping tag to sync builds. * Mon May 07 2007 Karen Pease - 2.1.2 - Spelling fixes * Fri Sep 15 2006 Karen Pease - 2.1.1.2 - Rebuild gallery2-2.2-0.2.svn20070506.fc6 -------------------------------- * Mon May 07 2007 John Berninger - 2.2-0.2.svn20070506 - Requires PHP 4.3.0, not 4.1.0 - Add statement of support for DB2, MS SQL server - Don't hardcode /srv/gallery2 in install section, use the g2datadir variable - Up PHP memory chunk to 24M - Known issue - downloading modules and themes from within Gallery will not work with G2 being in /usr/share - esp if /usr is read-only. Would need exception to Fedora packaging guidelines to enable this feature * Sun May 06 2007 John Berninger - 2.2-0.1.svn20070506 - Switch to upstream ver 2.2 base - Add digibug, dynamicalbum, ecard, flashvideo, httpauth, itemadd, keyalbum, mp3audio, multiroot, replica, webdav modules - Add ajaxian, carbon themes - Refactor login.txt and config.php references, update readme for same gnome-chemistry-utils-0.6.5-2.fc6 --------------------------------- * Mon May 07 2007 Julian Sikorski - 0.6.5-2 - Fixed gchemtable crash (RH #239056, Savannah #19808) * Mon Apr 09 2007 Julian Sikorski - 0.6.5-1 - Updated to 0.6.5 - Switched to bzip2 sources - Added rpath killer htmldoc-1.8.27-2.fc6 -------------------- * Sat May 05 2007 Adam Goode - 1.8.27-2 - Remove X-Fedora initng-0.6.10-2.fc6 ------------------- * Thu Mar 29 2007 Daniel Malmgren 0.6.10-2 - Include patch from che to sole console font issue * Tue Mar 27 2007 Daniel Malmgren 0.6.10-1 - New upstreams version initng-ifiles-0.1.2-1.fc6 ------------------------- * Tue Mar 27 2007 Daniel Malmgren 0.1.2-1 - New upstreams version - Fixed up genrunlevel calls in post - Patch to disable broken virtcheck stuff libopm-0.1-4.20050731cvs.fc6 ---------------------------- * Mon May 07 2007 Robert Scheck 0.1-4.20050731cvs - Rebuild librsync-0.9.7-10.fc6 --------------------- * Mon May 07 2007 Robert Scheck 0.9.7-10 - rebuilt libupnp-1.4.6-1.fc6 ------------------- * Tue May 01 2007 Eric Tanguy - 1.4.6-1 - Update to version 1.4.6 * Sat Apr 21 2007 Eric Tanguy - 1.4.4-1 - Update to version 1.4.4 mimedefang-2.62-2.fc6 --------------------- * Mon May 07 2007 Robert Scheck 2.62-2 - Changed sendmail build requirement slightly (#237157) * Mon Apr 16 2007 Robert Scheck 2.62-1 - Upgrade to 2.62 moin-1.5.7-2.fc6 ---------------- * Mon May 07 2007 Matthias Saou 1.5.7-2 - Include security fixes from the Debian package (Jonas Smedegaard). - FIX_use_ACL_in_include_directive (Alexander Schremmer). - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). - CVE-2007-0857. moodle-1.6.5-4.fc6 ------------------ * Mon May 07 2007 Jerry James - 1.6.5-4 - Mark a bunch of config.php files as configuration files. - Update language packs to the 07 May 2007 versions. * Fri Apr 20 2007 Jerry James - 1.6.5-3 - perl-Text-Aspell is now available, so use it. Don't make the spellchecker a separate package, however, since it is an htmlarea plugin, not a moodle plugin. Somebody we will provide htmlarea as a separate package. - Update language packs to the 20 Apr 2007 versions. * Tue Apr 17 2007 Jerry James - 1.6.5-2 - Fix a CVS gaffe. - Obsolete language packs with old names. - Update language packs to the 17 Apr 2007 versions. * Thu Apr 12 2007 Jerry James - 1.6.5-1 - Update to 1.6.5 (fixes BZ 220041 and 232103) - Own /var/www/moodle/web (BZ 233882) - Drop unused mimetex patches - Add executable bits to 3 scripts that should have them - Remove the installation language files from the main package (twice) - Package the moodle language files, not just the installation files - Rename/add several language files to match the upstream list - Minor typo fixes in the scripts opensc-0.11.2-2.fc6 ------------------- * Sun May 06 2007 Ville Skytt? - 0.11.2-2 - Add explicit build dependency on ncurses-devel. * Sat May 05 2007 Ville Skytt? - 0.11.2-1 - 0.11.2. * Tue Apr 24 2007 Ville Skytt? - 0.11.2-0.3.rc2 - 0.11.2-rc2. * Fri Mar 23 2007 Ville Skytt? - 0.11.2-0.3.rc1 - 0.11.2-rc1. * Thu Mar 15 2007 Ville Skytt? - 0.11.2-0.2.pre6 - 0.11.2-pre6. * Tue Mar 06 2007 Ville Skytt? - 0.11.2-0.2.pre4 - 0.11.2-pre4. - Require pinentry-gui instead of the pinentry executable in signer. * Sun Dec 03 2006 Ville Skytt? - 0.11.2-0.1.pre3 - 0.11.2-pre3. - Build with new libassuan. - Don't run autotools during build. - Adjust to readline/termcap/ncurses changes. perl-File-Next-0.40-1.fc6 ------------------------- * Sun May 06 2007 Ian Burrell - 0.40-1 - Update to 0.40 perl-Module-Refresh-0.13-1.fc6 ------------------------------ * Tue May 08 2007 Ralf Cors?pius < - 0.13-1 - Upstream update. * Wed Apr 25 2007 Ralf Cors?pius < - 0.11-1 - Upstream update. perl-Net-LibIDN-0.09-3.fc6 -------------------------- * Mon May 07 2007 Robert Scheck 0.09-3 - Rebuild * Thu Apr 26 2007 Robert Scheck 0.09-2 - Added build requirement to perl(ExtUtils::MakeMaker) perl-Pod-Strip-1.02-2.fc6 ------------------------- * Sun May 06 2007 Jose Pedro Oliveira - 1.02-2 - Added missing requirement: perl(Pod::Simple) (see bug #239241). perl-POE-Component-SSLify-0.07-1.fc6 ------------------------------------ * Sun May 06 2007 Chris Weyl 0.07-1 - update to 0.07 - add t/ to %doc - some spec rework due to perl splittage perl-Text-Glob-0.08-1.fc6 ------------------------- * Tue May 08 2007 Ralf Cors?pius - 0.08-1 - Upstream update. perl-Want-0.14-1.fc6 -------------------- * Mon May 07 2007 Ralf Cors?pius - 0.14-1 - Upstream update. * Thu Apr 19 2007 Ralf Cors?pius - 0.12-2 - Reflect perl package split. php-idn-1.2-2.fc6 ----------------- * Mon May 07 2007 Robert Scheck 1.2-2 - Rebuild php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc6 ---------------------------------------------------- * Sun May 06 2007 Christopher Stone 1.0.0-0.5.RC7 - Require new HTML_QuickForm_ElementGrid package * Mon Apr 02 2007 Christopher Stone 1.0.0-0.4.RC7 - Upstream sync php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.fc6 ----------------------------------------------- * Sun Jan 14 2007 Christopher Stone 0.1.0-1 - Initial Fedora release php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc6 -------------------------------------------------------------- * Mon May 07 2007 Christopher Stone 0.1.2-1 - Upstream sync ruby-amazon-0.9.2-3.fc6 ----------------------- * Wed May 02 2007 Mamoru Tasaka - 0.9.2-3 - Split documentation * Sun Apr 22 2007 Mamoru Tasaka - 0.9.2-2 - Don't provide rdoc files to aboid unwanted conflict with ri * Sat Apr 21 2007 Mamoru Tasaka - 0.9.2-1 - Initial packaging, based on the spec file by developer schismtracker-0.5-0.4.rc1.fc6 ----------------------------- * Mon May 07 2007 Jindrich Novy 0.5-0.4.rc1 - bump release to avoid EVR problems with FC-5 * Fri May 04 2007 Jindrich Novy 0.5-0.3.rc1 - add X dependencies (#238824), thanks to Ville Skytt? - tune the .desktop file yet more * Fri May 04 2007 Jindrich Novy 0.5-0.2.rc1 - update GTK icon caches in %post, %postun - remove unneeded dependencies - update .desktop file * Wed May 02 2007 Jindrich Novy 0.5-0.1rc1 - package schismtracker tcpick-0.2.1-12.fc6 ------------------- * Mon May 07 2007 Robert Scheck 0.2.1-12 - Rebuilt tdom-0.8.0-2.fc6 ---------------- * Tue May 01 2007 Wart - 0.8.0-2 - Updated patch 1 to add $RPM_OPT_FLAGS to the compiler flags - Add --enable-threads to match the configuration of the core Tcl package widelands-0-0.3.build10.fc6 --------------------------- * Sun May 06 2007 Karol Trzcionka - 0-0.3.build10 - Changes in .desktop and icon-dir - Changes in %postun and %post sections - Merge -data subpackage with core package * Tue May 01 2007 Karol Trzcionka - 0-0.2.build10 - Return to first method of versioning - Some changes in summary and GenericName - Make spec-file more clear * Mon Apr 30 2007 Karol Trzcionka - 0-0.10.1.build10 - Flagfix - Change versions numerating * Sat Apr 28 2007 Karol Trzcionka - 0-0.1.build10 - Initial Release Changes in Fedora Extras 5: bitlbee-1.0.3-6.fc5 ------------------- * Mon May 07 2007 Robert Scheck 1.0.3-6 - Rebuilt duplicity-0.4.2-7.fc5 --------------------- * Mon May 07 2007 Robert Scheck 0.4.2-7 - Rebuild eggdrop-1.6.18-8.fc5 -------------------- * Mon May 07 2007 Robert Scheck 1.6.18-8 - Rebuild * Tue Mar 13 2007 Robert Scheck 1.6.18-7 - Rebuild for bind 9.4.0 * Wed Feb 14 2007 Robert Scheck 1.6.18-6 - Rebuild for tcl 8.4 fortune-firefly-2.1.2-2.fc5 --------------------------- * Mon May 07 2007 Karen Pease - 2.1.2.2 - Upping tag to sync builds. * Mon May 07 2007 Karen Pease - 2.1.2 - Spelling fixes gallery2-2.2-0.2.svn20070506.fc5 -------------------------------- * Mon May 07 2007 John Berninger - 2.2-0.2.svn20070506 - Requires PHP 4.3.0, not 4.1.0 - Add statement of support for DB2, MS SQL server - Don't hardcode /srv/gallery2 in install section, use the g2datadir variable - Up PHP memory chunk to 24M - Known issue - downloading modules and themes from within Gallery will not work with G2 being in /usr/share - esp if /usr is read-only. Would need exception to Fedora packaging guidelines to enable this feature * Sun May 06 2007 John Berninger - 2.2-0.1.svn20070506 - Switch to upstream ver 2.2 base - Add digibug, dynamicalbum, ecard, flashvideo, httpauth, itemadd, keyalbum, mp3audio, multiroot, replica, webdav modules - Add ajaxian, carbon themes - Refactor login.txt and config.php references, update readme for same gnome-chemistry-utils-0.6.5-2.fc5 --------------------------------- * Mon May 07 2007 Julian Sikorski - 0.6.5-2 - Fixed gchemtable crash (RH #239056, Savannah #19808) * Mon Apr 09 2007 Julian Sikorski - 0.6.5-1 - Updated to 0.6.5 - Switched to bzip2 sources - Added rpath killer htmldoc-1.8.27-2.fc5 -------------------- * Sat May 05 2007 Adam Goode - 1.8.27-2 - Remove X-Fedora libopm-0.1-4.20050731cvs.fc5 ---------------------------- * Mon May 07 2007 Robert Scheck 0.1-4.20050731cvs - Rebuild librsync-0.9.7-10.fc5 --------------------- * Mon May 07 2007 Robert Scheck 0.9.7-10 - rebuilt libupnp-1.4.6-1.fc5 ------------------- * Tue May 01 2007 Eric Tanguy - 1.4.6-1 - Update to version 1.4.6 * Sat Apr 21 2007 Eric Tanguy - 1.4.4-1 - Update to version 1.4.4 mimedefang-2.62-2.fc5 --------------------- * Mon May 07 2007 Robert Scheck 2.62-2 - Changed sendmail build requirement slightly (#237157) * Mon Apr 16 2007 Robert Scheck 2.62-1 - Upgrade to 2.62 moin-1.5.7-2.fc5 ---------------- * Mon May 07 2007 Matthias Saou 1.5.7-2 - Include security fixes from the Debian package (Jonas Smedegaard). - FIX_use_ACL_in_include_directive (Alexander Schremmer). - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). - CVE-2007-0857. moodle-1.6.5-4.fc5 ------------------ * Mon May 07 2007 Jerry James - 1.6.5-4 - Mark a bunch of config.php files as configuration files. - Update language packs to the 07 May 2007 versions. * Fri Apr 20 2007 Jerry James - 1.6.5-3 - perl-Text-Aspell is now available, so use it. Don't make the spellchecker a separate package, however, since it is an htmlarea plugin, not a moodle plugin. Somebody we will provide htmlarea as a separate package. - Update language packs to the 20 Apr 2007 versions. * Tue Apr 17 2007 Jerry James - 1.6.5-2 - Fix a CVS gaffe. - Obsolete language packs with old names. - Update language packs to the 17 Apr 2007 versions. * Thu Apr 12 2007 Jerry James - 1.6.5-1 - Update to 1.6.5 (fixes BZ 220041 and 232103) - Own /var/www/moodle/web (BZ 233882) - Drop unused mimetex patches - Add executable bits to 3 scripts that should have them - Remove the installation language files from the main package (twice) - Package the moodle language files, not just the installation files - Rename/add several language files to match the upstream list - Minor typo fixes in the scripts perl-File-Next-0.40-1.fc5 ------------------------- * Sun May 06 2007 Ian Burrell - 0.40-1 - Update to 0.40 perl-Module-Refresh-0.13-1.fc5 ------------------------------ * Tue May 08 2007 Ralf Cors?pius < - 0.13-1 - Upstream update. * Wed Apr 25 2007 Ralf Cors?pius < - 0.11-1 - Upstream update. * Tue Sep 05 2006 Ralf Cors?pius - 0.09-3 - Mass rebuild. perl-Net-LibIDN-0.09-3.fc5 -------------------------- * Mon May 07 2007 Robert Scheck 0.09-3 - Rebuild * Thu Apr 26 2007 Robert Scheck 0.09-2 - Added build requirement to perl(ExtUtils::MakeMaker) perl-Pod-Strip-1.02-2.fc5 ------------------------- * Sun May 06 2007 Jose Pedro Oliveira - 1.02-2 - Added missing requirement: perl(Pod::Simple) (see bug #239241). perl-Text-Glob-0.08-1.fc5 ------------------------- * Tue May 08 2007 Ralf Cors?pius - 0.08-1 - Upstream update. * Tue Sep 05 2006 Ralf Cors?pius - 0.07-2 - Mass rebuild. perl-Want-0.14-1.fc5 -------------------- * Mon May 07 2007 Ralf Cors?pius - 0.14-1 - Upstream update. * Thu Apr 19 2007 Ralf Cors?pius - 0.12-2 - Reflect perl package split. php-idn-1.2-2.fc5 ----------------- * Mon May 07 2007 Robert Scheck 1.2-2 - Rebuild php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc5 ---------------------------------------------------- * Sun May 06 2007 Christopher Stone 1.0.0-0.5.RC7 - Require new HTML_QuickForm_ElementGrid package * Mon Apr 02 2007 Christopher Stone 1.0.0-0.4.RC7 - Upstream sync php-pear-HTML-QuickForm-ElementGrid-0.1.0-1.fc5 ----------------------------------------------- * Sun Jan 14 2007 Christopher Stone 0.1.0-1 - Initial Fedora release php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc5 -------------------------------------------------------------- * Mon May 07 2007 Christopher Stone 0.1.2-1 - Upstream sync ruby-amazon-0.9.2-3.fc5 ----------------------- * Wed May 02 2007 Mamoru Tasaka - 0.9.2-3 - Split documentation * Sun Apr 22 2007 Mamoru Tasaka - 0.9.2-2 - Don't provide rdoc files to aboid unwanted conflict with ri * Sat Apr 21 2007 Mamoru Tasaka - 0.9.2-1 - Initial packaging, based on the spec file by developer schismtracker-0.5-0.4.rc1.fc5 ----------------------------- * Mon May 07 2007 Jindrich Novy 0.5-0.4.rc1 - add mesa-libGLU-devel BR which is missing from the FC-5 SDL-devel which is needed for successful build * Fri May 04 2007 Jindrich Novy 0.5-0.3.rc1 - add X dependencies (#238824), thanks to Ville Skytt? - tune the .desktop file yet more * Fri May 04 2007 Jindrich Novy 0.5-0.2.rc1 - update GTK icon caches in %post, %postun - remove unneeded dependencies - update .desktop file * Wed May 02 2007 Jindrich Novy 0.5-0.1rc1 - package schismtracker tcpick-0.2.1-12.fc5 ------------------- * Mon May 07 2007 Robert Scheck 0.2.1-12 - Rebuilt For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From davehoz at gmail.com Tue May 8 11:05:01 2007 From: davehoz at gmail.com (David Hunter) Date: Tue, 8 May 2007 21:05:01 +1000 Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. In-Reply-To: References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> Message-ID: <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> firefox -g GTK Accessibility Module initialized argn=src, argv=/images/zootube/videos/262.mov argn=autoplay, argv=false argn=type, argv=video/quicktime argn=pluginspage, argv=http://www.apple.com/quicktime/download/ argn=bgcolor, argv=#000000 argn=height, argv=300 argn=width, argv=320 [00000001] main private debug: checking builtin modules [00000001] main private debug: checking plugin modules [00000001] main private debug: loading plugins cache file /home/dhunter/.vlc/cache/plugins-04041e.dat [00000001] main private warning: could not open plugins cache file /home/dhunter/.vlc/cache/plugins-04041e.dat for reading [00000001] main private debug: recursively browsing `modules' [00000001] main private debug: recursively browsing `/usr/lib/vlc' [00000001] main private warning: cannot load module `/usr/lib/vlc/control/libcorba_plugin.so' (/usr/lib/vlc/control/libcorba_plugin.so: undefined symbol: mediacontrol_new_from_object) [00000001] main private warning: cannot load module `/usr/lib/vlc/codec/libquicktime_plugin.so' (/usr/lib/vlc/codec/libquicktime_plugin.so: undefined symbol: NewHandleClear) [00000001] main private debug: recursively browsing `plugins' [00000001] main private debug: module bank initialized, found 239 modules [00000001] main private debug: opening config file /home/dhunter/.vlc/vlcrc [00000001] main private warning: config file /home/dhunter/.vlc/vlcrc does not exist yet [00000001] main private debug: CPU has capabilities 486 586 MMX FPU [00000001] main private debug: looking for memcpy module: 2 candidates [00000001] main private debug: using memcpy module "memcpymmx" [00000302] main playlist debug: waiting for thread completion [00000302] main playlist debug: thread 156957584 (playlist) created at priority 0 (playlist/playlist.c:184) [00000303] main private debug: waiting for thread completion [00000303] main private debug: thread 2948090768 (preparser) created at priority 0 (playlist/playlist.c:210) [00000304] main interface debug: looking for interface module: 1 candidate [00000304] main interface debug: using interface module "hotkeys" [00000304] main interface debug: thread 2937600912 (interface) created at priority 0 (interface/interface.c:231) [00000305] main interface debug: looking for interface module: 1 candidate [00000305] main interface debug: using interface module "screensaver" [00000305] main interface debug: thread 2927111056 (interface) created at priority 0 (interface/interface.c:231) /usr/lib/firefox-2.0.0.3/firefox-bin: symbol lookup error: /usr/lib/mozilla/plugins/libvlcplugin.so: undefined symbol: XtWindowToWidget What to do now? Looks like its trying to use quicktime. :( On 08/05/07, Bojan Smojver wrote: > > David Hunter gmail.com> writes: > > > > When I try to load the page at http://www.zooweekly.com.au/zootube/, > epiphany-2.18.1-2.fc7 crashes. Also occurs on Firefox > firefox-2.0.0.3-4.fc7. > Could it be a website issue or an issue with the software in Fedora. The > gnome > crash buddy is not activated with the crash of either program. > > The best thing to do would be to open a bug report in Bugzilla. You can > try > running "firefox -g" after installing firefox-debuginfo RPM and then give > the > backtrace output. > > In any event, the theory is that applications (i.e. FF/Epi) should be able > to > handle bad data (i.e. web site content) gracefully and not crash. > > -- > Bojan > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 8 11:09:03 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 May 2007 13:09:03 +0200 Subject: Fedora Extras Package Build Report 2007-05-08 In-Reply-To: <20070508110426.61BF0152131@buildsys.fedoraproject.org> References: <20070508110426.61BF0152131@buildsys.fedoraproject.org> Message-ID: <20070508130903.53d32917@python3.es.egwn.lan> buildsys at fedoraproject.org wrote : > moin-1.5.7-2.fc5 > ---------------- > * Mon May 07 2007 Matthias Saou 1.5.7-2 > - Include security fixes from the Debian package (Jonas Smedegaard). > - FIX_use_ACL_in_include_directive (Alexander Schremmer). > - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). > - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). > - CVE-2007-0857. This one has been rebuilt on all branches. Can someone make sure it'll be available for Fedora 7? It contains only security fixes and is not a major component of the distribution. Thanks in advance ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 1.93 2.53 2.13 From jwboyer at jdub.homelinux.org Tue May 8 11:55:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 06:55:49 -0500 Subject: Fedora Extras Package Build Report 2007-05-08 In-Reply-To: <20070508130903.53d32917@python3.es.egwn.lan> References: <20070508110426.61BF0152131@buildsys.fedoraproject.org> <20070508130903.53d32917@python3.es.egwn.lan> Message-ID: <1178625349.25550.25.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 13:09 +0200, Matthias Saou wrote: > buildsys at fedoraproject.org wrote : > > > moin-1.5.7-2.fc5 > > ---------------- > > * Mon May 07 2007 Matthias Saou 1.5.7-2 > > - Include security fixes from the Debian package (Jonas Smedegaard). > > - FIX_use_ACL_in_include_directive (Alexander Schremmer). > > - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). > > - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). > > - CVE-2007-0857. > > This one has been rebuilt on all branches. Can someone make sure it'll > be available for Fedora 7? It contains only security fixes and is not a > major component of the distribution. > > Thanks in advance ;-) You (or someone) needs to email rel-eng per http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy josh From skvidal at linux.duke.edu Tue May 8 12:12:46 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 08 May 2007 08:12:46 -0400 Subject: F7 Zope package In-Reply-To: <464057EE.1000201@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> Message-ID: <1178626366.3862.3.camel@rivendell> On Tue, 2007-05-08 at 12:58 +0200, Hans de Goede wrote: > What ever happend to a package is ok, as long as it is free software, not > legally encumbered and someone is willing to maintain it? > It's not that simple of a rule. There's also: "Don't create agonizing pain for others by the addition of a package." -sv From mclasen at redhat.com Tue May 8 12:15:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 08 May 2007 08:15:16 -0400 Subject: Possible changes between F7T4 and the final Fedora release In-Reply-To: <3f15e6450705080156n20a8796fic3fd75c5d24d3324@mail.gmail.com> References: <3f15e6450705080156n20a8796fic3fd75c5d24d3324@mail.gmail.com> Message-ID: <1178626516.3490.14.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-05-08 at 14:26 +0530, Shashank Sharma wrote: > Hi list, > > I have a question about the final Fedora release on May 24. The thing > is, I downloaded F7T1 and noticed that it had no terminal under the > Applications -> Accessories menu. Same with F7T2. This was probably a > bug or whatever and I saw several people complaining about this. > > Now in test 4, the Terminal is available under Applications -> System > Tools. Have me made up our minds? Is the position now final or could > it change still when the final is released on May 24th? It will not change. > Also, I was wondering what kind of work is being done on Fedora > currently? I mean, I know there won't be any new features apart from > what was in F7T4. So my question is: are you working on things like > fonts, graphics, wallpapers, and such, or just fixing bugs and > everything else like layout of the tools (see analogy about the > terminal) final? Critical bugfixes. > Another thing that bothered me about the layout is the System -> > Preferences menu. It was different in Test1, test2 and test4. Have we > finally settled on what I see in Test 4 (categorized preferences > menu). For better or worse, we'll have the same layout we have right now in preferences. From j.w.r.degoede at hhs.nl Tue May 8 12:36:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 14:36:52 +0200 Subject: F7 Zope package In-Reply-To: <1178626366.3862.3.camel@rivendell> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> Message-ID: <46406EE4.8050503@hhs.nl> seth vidal wrote: > On Tue, 2007-05-08 at 12:58 +0200, Hans de Goede wrote: > > >> What ever happend to a package is ok, as long as it is free software, not >> legally encumbered and someone is willing to maintain it? >> > > It's not that simple of a rule. There's also: > "Don't create agonizing pain for others by the addition of a package." > There has been presented exactly 0 proof that providing python2.4 packages (espicially under a different name) cause "agonizing pain for others" Regards, Hans From jwboyer at jdub.homelinux.org Tue May 8 12:16:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 07:16:57 -0500 Subject: F7 Zope package In-Reply-To: <46406EE4.8050503@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> Message-ID: <1178626617.25550.27.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 14:36 +0200, Hans de Goede wrote: > seth vidal wrote: > > On Tue, 2007-05-08 at 12:58 +0200, Hans de Goede wrote: > > > > > >> What ever happend to a package is ok, as long as it is free software, not > >> legally encumbered and someone is willing to maintain it? > >> > > > > It's not that simple of a rule. There's also: > > "Don't create agonizing pain for others by the addition of a package." > > > > There has been presented exactly 0 proof that providing python2.4 packages > (espicially under a different name) cause "agonizing pain for others" And there's been 0 proof that it won't. Proof, one way or another,only comes after the fact. josh From j.w.r.degoede at hhs.nl Tue May 8 12:53:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 14:53:29 +0200 Subject: F7 Zope package In-Reply-To: <1178626617.25550.27.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> Message-ID: <464072C9.1040301@hhs.nl> Josh Boyer wrote: > On Tue, 2007-05-08 at 14:36 +0200, Hans de Goede wrote: >> seth vidal wrote: >>> On Tue, 2007-05-08 at 12:58 +0200, Hans de Goede wrote: >>> >>> >>>> What ever happend to a package is ok, as long as it is free software, not >>>> legally encumbered and someone is willing to maintain it? >>>> >>> It's not that simple of a rule. There's also: >>> "Don't create agonizing pain for others by the addition of a package." >>> >> There has been presented exactly 0 proof that providing python2.4 packages >> (espicially under a different name) cause "agonizing pain for others" > > And there's been 0 proof that it won't. Proof, one way or another,only > comes after the fact. > okay, so maybe proof is the wrong word, but there have been little to no arguments presented for this, and 0 arguments with proper explanation / reasoning added. As long as there is no proper motivation (which sofar has not been shown IMHO) and someone is willing to maintain a python2.4 (under a different name even), then I see noe reason to inflict pain upon our users. Proven pain even, not potentially maybe pain like the arguments against shipping a python-compat for zope. Again I have no use for zope whatsoever myself. But I see a serious lack of respect for our end users here. If there are good reasons not to include python2.4, then its perhaps unfortunate but ok to leave zope out. But first give good reasons then, with proper explanation. not just: "that could cause potential problems" mumbo jumbo. I guess in the end it boils down to are we doing a distro for developers only, or for normal (not minding to be on the cutting edge) users too? Regards, Hans From jwboyer at jdub.homelinux.org Tue May 8 12:46:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 07:46:55 -0500 Subject: F7 Zope package In-Reply-To: <464072C9.1040301@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> Message-ID: <1178628415.3175.2.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 14:53 +0200, Hans de Goede wrote: > > As long as there is no proper motivation (which sofar has not been shown IMHO) > and someone is willing to maintain a python2.4 (under a different name even), > then I see noe reason to inflict pain upon our users. Proven pain even, not > potentially maybe pain like the arguments against shipping a python-compat for > zope. I'm a little rusty here, but is there someone willing to maintain python 2.4 inside of Zope itself? I thought it was discussed, with Jeremy not liking it, but I'm not aware of an actual person that wants to maintain that. I'm not advocating for that, but unless we have a physical person that wants to do it all further discussion is pointless. josh From linville at redhat.com Tue May 8 13:03:36 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 8 May 2007 09:03:36 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels Message-ID: <20070508130336.GB23247@redhat.com> If you are a rawhide user/tester and have ipw3945 hardware, please try the latest kernels here: http://people.redhat.com/davej/kernels/Fedora/fc7/ I am having mixed results with the latest iwl3945 updates, but I'm not sure if it is this particular laptop having problems or the driver in general. Please give the latest kernels a try and let me know how it is working for you. Please also let me know what was the last kernel that worked any better for ipw3945 hardware than the current ones. At this point, I am quite uneasy about this driver. It seems to work fine at times, then crash or simply refuse to associate at others. I am considering backing it out to the 0.0.16 tag or possibly even removing it (since the driver has _still_ not been posted upstream). Thoughts? Thanks, John -- John W. Linville linville at redhat.com From debarshi.ray at gmail.com Tue May 8 13:12:16 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 May 2007 18:42:16 +0530 Subject: F7 Zope package In-Reply-To: <1178628415.3175.2.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> Message-ID: <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> > I'm a little rusty here, but is there someone willing to maintain python > 2.4 inside of Zope itself? I thought it was discussed, with Jeremy not > liking it, but I'm not aware of an actual person that wants to maintain > that. > > I'm not advocating for that, but unless we have a physical person that > wants to do it all further discussion is pointless. What about the Zope maintainer? Would he like to have Python 2.4.x inside his Zope package? What is happening here is that no matter who wants to maintain Python 2.4.x in whatever form for Fedora 7, the idea is being shot down since Jeremy (the main Python maintainer) does not like it. That is what needs a little explaining. All that I have seen is that it will cause "agonizing pain", "it is too difficult", etc.. During the days of Fedora Core 5, we used to have gcc32 (ie., GCC 3.2.x) alongwith GCC (ie., GCC 4.x). Did that cause enough pain too? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From nicolas.mailhot at laposte.net Tue May 8 13:18:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 08 May 2007 15:18:15 +0200 Subject: F7 Zope package In-Reply-To: <464072C9.1040301@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> Message-ID: <1178630295.342.22.camel@rousalka.dyndns.org> Le mardi 08 mai 2007 ? 14:53 +0200, Hans de Goede a ?crit : > But I see a serious lack of respect for our end users here. I see a serious lack of respect for the release process and all the packagers that followed it if a single user causing enough noise on the lists can force the fork of a major distro component against the wishes of its maintainer on the eve of a release for a single app without the upstream of said app being involved and expressing any form of commitment to help clear the mess. May as well trumpet "our release process is a joke" and "people who follow it are morons afraid of a little flaming". Think we're not creating a precedent now? Read the thread. Every past compat package is used as an argument to ignore test releases and the fact python 2.5 hit rawhide 10 months ago. Do we want to be flamed every time there is a roadmap clash because people feel it's easier to change ours than fix the problem upstream (upstream, upstream, usptream, remember ?) > I guess in the end it boils down to are we doing a distro for developers only, > or for normal (not minding to be on the cutting edge) users too? It boils down to are we trying to do a distro or are we just publishing a package magma with no lifecycle or internal consistency. -- 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 rmo at sunnmore.net Tue May 8 13:19:53 2007 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Tue, 08 May 2007 15:19:53 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <464078F9.5080007@sunnmore.net> John W. Linville skreiv: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? I am experiencing kernel oops when trying to unload the driver with kernel-2.6.21-1.3141.fc7. I will try kernel-2.6.21-1.3142.fc7 later today and see if this is still a problem. From nicolas.mailhot at laposte.net Tue May 8 13:24:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 08 May 2007 15:24:49 +0200 Subject: F7 Zope package In-Reply-To: <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> Message-ID: <1178630689.342.29.camel@rousalka.dyndns.org> Le mardi 08 mai 2007 ? 18:42 +0530, Debarshi 'Rishi' Ray a ?crit : > During the days of Fedora Core 5, we used to have gcc32 (ie., GCC > 3.2.x) alongwith GCC (ie., GCC 4.x). Did that cause enough pain too? All this stuff is largely developed as Red Hat, was done with the blessing and support of the upstream project, and was anticipated early enough to be in before Freezing and Testing. Here not only Fedora is less involved in the upstream projects but : 1. the person in charge of python Fedora-side is opposed to the whole thing. 2. no upstream speaker stepped in to commit to sharing the burden 3. it's way too late now There is absolutely no comparison possible. -- 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 bbbush.yuan at gmail.com Tue May 8 13:26:09 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 8 May 2007 21:26:09 +0800 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <76e72f800705080626ie6c6944rb537d62475ed89f2@mail.gmail.com> 2007/5/8, John W. Linville : > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? > Cannot unload the driver and sometimes cannot power down completely (have to press the button several seconds). But I like this driver because it makes things so easy. -- bbbush ^_^ From tonynelson at georgeanelson.com Tue May 8 13:54:00 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 8 May 2007 09:54:00 -0400 Subject: F7 Zope package In-Reply-To: <1178626617.25550.27.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> Message-ID: At 7:16 AM -0500 5/8/07, Josh Boyer wrote: >On Tue, 2007-05-08 at 14:36 +0200, Hans de Goede wrote: >> seth vidal wrote: >> > On Tue, 2007-05-08 at 12:58 +0200, Hans de Goede wrote: >> > >> > >> >> What ever happend to a package is ok, as long as it is free software, not >> >> legally encumbered and someone is willing to maintain it? >> >> >> > >> > It's not that simple of a rule. There's also: >> > "Don't create agonizing pain for others by the addition of a package." >> > >> >> There has been presented exactly 0 proof that providing python2.4 packages >> (espicially under a different name) cause "agonizing pain for others" > >And there's been 0 proof that it won't. Proof, one way or another,only >comes after the fact. Python 2.5 is in maintenance mode. Python 2.4 is past that, though it may receive critical security fixes during the life of Python 2.5. Last October, after the release of Python 2.5 and the "final" maintenance release of Python 2.4, to cover a security flaw Python 2.3.6 was released with that flaw and a couple of other minor bug-fixes. Somthing like this could happen for Python 2.4 after the release of Python 2.6 and after the release of Fedora 8, but very little will be fixed in such a release. Thus, nearly every bug report against a Python-compat 2.4 would be marked "won't fix". -- ____________________________________________________________________ TonyN.:' ' From mackay_d at bellsouth.net Tue May 8 13:57:03 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 08:57:03 -0500 Subject: F7 Zope package In-Reply-To: <1178626617.25550.27.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> Message-ID: <1178632623.18160.3.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 07:16 -0500, Josh Boyer wrote: > > There has been presented exactly 0 proof that providing python2.4 packages > > (espicially under a different name) cause "agonizing pain for others" > > And there's been 0 proof that it won't. Proof, one way or another,only > comes after the fact. I just checked bugzilla, and found a total of twelve bugs for python under fc6, most of which didn't really pertain to python itself. If it is packaged so that it doesn't conflict with python 2.5.x, why would you expect that it would suddenly become unstable? Dave From tjb at unh.edu Tue May 8 14:03:39 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 08 May 2007 10:03:39 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <1178633019.20754.11.camel@raptor.sr.unh.edu> On Tue, 2007-05-08 at 09:03 -0400, John W. Linville wrote: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? > > Thanks, > > John > -- > John W. Linville > linville at redhat.com > The 3142 kernel seems to work better than any iwlwifi enabled kernel I've tried so far. I've had it running for 15 minutes cruising the web and it hasn't reassociated or spewed any errors to the log yet. It even connected to my preferred AP when I logged in. It previously always seemed to fail the first time. I still get a hang at reboot or shutdown if I've logged in but I don't know if that's related to iwlwifi or intel graphics drm being employed by compiz. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From andy at warmcat.com Tue May 8 14:06:45 2007 From: andy at warmcat.com (Andy Green) Date: Tue, 08 May 2007 15:06:45 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <464083F5.9000401@warmcat.com> John W. Linville wrote: > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). 2.6.21-1.3142.fc7 First the name has changed, iwlwifi -> iwl3945, confused me anyway. The device associates okay automatically to my WPA network using wext on bootup now but I am not using Network Manager. I just mean that it happens on my setup, I don't know what will happen on an FC7 install without meddling. They fixed the b rates issue on a g network, so it now understands it is a G adapter on a G network. They seem to have improved the robustness problem where for example a git pull would kill the driver. However I can still kill the driver from userspace by bringing up a management interface and injecting packets down it. When it is trashed, it drops association, will not associate, may or may not stall on a modprobe -r, and issues this when trying to scan: iwl3945: check mac addr 1 | 1 iwl3945: check basic rate 2 | 1 iwl3945: check assoc id 3 | 1 iwl3945: check CCK and short slot 4 | 1 iwl3945: check CCK & auto detect 5 | 1 iwl3945: check TGG 6 | 1 iwl3945: check antenna 7 1 iwl3945: Tuning to channel 2 iwl3945: Error not a valid ipw_rxon_assoc_cmd field values iwl3945: Invalid RXON configuration. Not committing. If you can remove it and re-insert it, then it will work okay. On my brief experience with it I would keep it in, since it is better than no support at all and more stable than, eg, bcm43xx has been in the past Fedora kernels. -Andy From jsacco at gnome.org Tue May 8 14:12:33 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 08 May 2007 10:12:33 -0400 Subject: FC6: Request for sqlite3 version update Message-ID: <1178633553.3221.35.camel@rt.jesacco.com> The version of sqlite3 currently available for FC6 is 3.3.6, which was released my sqlite.org on 6June2006: http://www.sqlite.org/changes.html The current version of sqlite3, 3.3.17, was released in April of 2007. -Joseph -- jsacco [at] gnome [dot] org From bpepple at fedoraproject.org Tue May 8 14:22:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 08 May 2007 10:22:21 -0400 Subject: F7 Zope package In-Reply-To: <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> Message-ID: <1178634141.5880.10.camel@lincoln> On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: > What is happening here is that no matter who wants to maintain Python > 2.4.x in whatever form for Fedora 7, the idea is being shot down since > Jeremy (the main Python maintainer) does not like it. That is what > needs a little explaining. All that I have seen is that it will cause > "agonizing pain", "it is too difficult", etc.. No, the reason the idea is being shot down is because the majority of FESCo does not like the idea. You are seriously mis-characterizing FESCo's decision by implying that Jeremy is the sole reason that Python 2.4 is not being maintained in F7. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Tue May 8 15:00:50 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 May 2007 20:30:50 +0530 Subject: F7 Zope package In-Reply-To: <1178630295.342.22.camel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> Message-ID: <3170f42f0705080800x578e6fc6xaf9ac447b2f50185@mail.gmail.com> > > But I see a serious lack of respect for our end users here. > I see a serious lack of respect for the release process and all the > packagers that followed it if a single user causing enough noise on the > lists can force the fork of a major distro component against the wishes > of its maintainer on the eve of a release for a single app without the > upstream of said app being involved and expressing any form of > commitment to help clear the mess. Wait a second! I do not see any "single user" here. Do you seriously believe that there is only one person using Zope on Fedora? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From michael.wiktowy at gmail.com Tue May 8 15:01:33 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 8 May 2007 11:01:33 -0400 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <3e4ec4600705080801o3cd6db0ra002c21608b89fdf@mail.gmail.com> On 5/7/07, Tom spot Callaway wrote: > Packagers should keep usage of Conflicts: to a bare minimum. Only > upgrading from two previous release of Fedora is supported, so Conflicts > against older packages than that, while technically correct, are > unnecessary, and should not be included. Phrases like "technically correct but don't do this anyways", too me, scream for justification why it is otherwise correct. I can see justification for pruning stupidly complicated Conflicts for clarity. I can also see the encouraging the reverse perspective where Conflicts of a certain age are not *required*. But to discourage a correct Conflicts because it is more than a year old is questionable as it is creating more work for the packager and is throwing up artificial roadblocks for large update leaps. As witnessed by the number of inquiries on the fedora-list labeled "Can I yum/anaconda update FC1->FC7?" ... this is going to bite a lot of people someday. Just seeking some clarity why not doing the right thing is the right thing to do. /Mike From alan at clueserver.org Tue May 8 15:51:07 2007 From: alan at clueserver.org (alan) Date: Tue, 8 May 2007 08:51:07 -0700 (PDT) Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <20070507224704.GA17998@redhat.com> References: <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <20070507191338.GB4803@nostromo.devel.redhat.com> <463F7C8B.1040303@seznam.cz> <20070507193014.GE4761@redhat.com> <20070507224704.GA17998@redhat.com> Message-ID: On Mon, 7 May 2007, John W. Linville wrote: > On Mon, May 07, 2007 at 02:01:45PM -0700, Miles Lane wrote: >> On 5/7/07, John W. Linville wrote: >>> On Mon, May 07, 2007 at 09:22:51PM +0200, Martin Sourada wrote: >>> I mentioned this situation earlier (maybe in this same thread). >>> Unfortunately, upstream isn't ready to move "bcm43xx" to "bcm4301" (and >>> make the accomanying PCI ID changes) yet. I'll have to noodle on this. >> >> I am not sure that there is still a reason to keep the older driver around. >> It works on my old bmc4306 rev. 2. Do we know there are still bcm43xx >> devices that the new driver won't work for? > > Yes. BCM4301 and BCM4303 don't work with the new driver. This is > because they don't have the memory resources required to load the > v4.x firmware required by the new driver. My HP laptop has one of these chipsets. Please do not remove the old driver. I can provide PCI id of my chipset if needed. -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From hughsient at gmail.com Tue May 8 15:57:02 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 May 2007 16:57:02 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <1178639822.2662.0.camel@hughsie-laptop> On Tue, 2007-05-08 at 09:03 -0400, John W. Linville wrote: > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? I've been using the git iwlwifi tree and a linus kernel for a few days now, without one crash, even under heavy load. DaveJ's kernels seem to perform well for me as well. Richard. From mackay_d at bellsouth.net Tue May 8 14:10:33 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 09:10:33 -0500 Subject: F7 Zope package In-Reply-To: <464072C9.1040301@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> Message-ID: <1178633433.18160.6.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 14:53 +0200, Hans de Goede wrote: > I guess in the end it boils down to are we doing a distro for developers only, > or for normal (not minding to be on the cutting edge) users too? I'd like to point out that zope IS a development platform, a very good one. And, there's a lot of interesting work being done on it. See PrimaGIS, for example. Dave From hughsient at gmail.com Tue May 8 16:12:47 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 08 May 2007 17:12:47 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178639822.2662.0.camel@hughsie-laptop> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> Message-ID: <1178640767.3606.3.camel@hughsie-laptop> On Tue, 2007-05-08 at 16:57 +0100, Richard Hughes wrote: > DaveJ's kernels seem to perform well for me as well. Nope, scrub that, I'm getting about a bazillion: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: issuing reconnect request psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. psmouse.c: Failed to reset mouse on isa0060/serio1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 and my mouse pointer keeps jumping around every few minutes - most irritating. I didn't get this with iwlwifi from git and a linus kernel. Richard. From mackay_d at bellsouth.net Tue May 8 16:13:36 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 11:13:36 -0500 Subject: F7 Zope package In-Reply-To: <1178630295.342.22.camel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> Message-ID: <1178640816.18982.11.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 15:18 +0200, Nicolas Mailhot wrote: > May as well trumpet "our release process is a joke" and "people who > follow it are morons afraid of a little flaming". > > Think we're not creating a precedent now? Read the thread. Every past > compat package is used as an argument to ignore test releases and the > fact python 2.5 hit rawhide 10 months ago. > > Do we want to be flamed every time there is a roadmap clash because > people feel it's easier to change ours than fix the problem upstream > (upstream, upstream, usptream, remember ?) You seem to believe that the failure of Zope Corp to expend a major effort that yields NO improvement to their product so that you can be bothered to give their product away somehow makes a very useful package undesirable. The only upstream problem that I see here is that the python developers keep breaking compatibility with previous versions. Quite frankly, if python weren't such a great development tool in other respects, that would probably be enough to get most developers to tell them to bugger off. > > I guess in the end it boils down to are we doing a distro for developers only, > > or for normal (not minding to be on the cutting edge) users too? > > It boils down to are we trying to do a distro or are we just publishing > a package magma with no lifecycle or internal consistency. Are you so inflexible that you can't reverse a flawed decision? Dave From sundaram at fedoraproject.org Tue May 8 16:17:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 May 2007 21:47:42 +0530 Subject: F7 Zope package In-Reply-To: <1178640816.18982.11.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> Message-ID: <4640A2A6.7050303@fedoraproject.org> David G. Mackay wrote: > On Tue, 2007-05-08 at 15:18 +0200, Nicolas Mailhot wrote: > >> May as well trumpet "our release process is a joke" and "people who >> follow it are morons afraid of a little flaming". >> >> Think we're not creating a precedent now? Read the thread. Every past >> compat package is used as an argument to ignore test releases and the >> fact python 2.5 hit rawhide 10 months ago. >> >> Do we want to be flamed every time there is a roadmap clash because >> people feel it's easier to change ours than fix the problem upstream >> (upstream, upstream, usptream, remember ?) > > You seem to believe that the failure of Zope Corp to expend a major > effort that yields NO improvement to their product so that you can be > bothered to give their product away somehow makes a very useful package > undesirable. Are you intimate enough with Python 2.5 and Zope to see that a port wouldn't yield any improvement at all? I think you are sidelining the discussions. Rahul From denis at poolshark.org Tue May 8 16:17:48 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 08 May 2007 18:17:48 +0200 Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. In-Reply-To: <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> Message-ID: <4640A2AC.9070705@poolshark.org> David Hunter wrote: > firefox -g terface) created > at priority 0 (interface/interface.c:231) > /usr/lib/firefox-2.0.0.3/firefox-bin : > symbol lookup error: /usr/lib/mozilla/plugins/libvlcplugin.so: undefined > symbol: XtWindowToWidget > > What to do now? Looks like its trying to use quicktime. :( Looks like a vlc plugin bug, or a vlc packaging bug. What does this say: ? rpm -qf /usr/lib/mozilla/plugins/libvlcplugin.so From selinux at gmail.com Tue May 8 16:26:03 2007 From: selinux at gmail.com (Tom London) Date: Tue, 8 May 2007 09:26:03 -0700 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> On 5/8/07, John W. Linville wrote: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? > > Thanks, > > John .3142 seems to be solid in my simpler, 'at home' setup; basically only one strong access point. [Running with NetworkManager.....] Testing in a more complex, multi-network, multi-access point 'at work' setup provides less joy. Here is the setup: eth0 Scan completed : Cell 01 - Address: 00:14:6A:5B:3A:80 ESSID:"INSIDE" Mode:Master Channel:2 Frequency:2.417 GHz Quality=0/100 Signal level=-66 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000000d95bcbd9e7 Extra:bcn_int=100 Extra:capab=0x0431 Cell 02 - Address: 00:14:69:3B:AF:60 ESSID:"INSIDE" Mode:Master Channel:3 Frequency:2.422 GHz Quality=0/100 Signal level=-76 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000000d95c0020da Extra:bcn_int=100 Extra:capab=0x0431 Cell 03 - Address: 00:12:17:BB:4B:4A ESSID:"OUTSIDE" Mode:Master Channel:10 Frequency:2.457 GHz Quality=0/100 Signal level=-69 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s 12 Mb/s; 48 Mb/s Extra:tsf=0000000c6cd0ec69 Extra:bcn_int=100 Extra:capab=0x0411 Cell 04 - Address: 00:18:4D:95:EC:1E ESSID:"InnoLan" Mode:Master Channel:11 Frequency:2.462 GHz Quality=0/100 Signal level=-78 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000000007cad43f9 Extra:bcn_int=100 Extra:capab=0x0431 Here is log info: May 8 09:18:19 localhost wpa_supplicant[3777]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys May 8 09:18:19 localhost kernel: eth0: No ProbeResp from current AP 00:14:6a:5b:3a:80 - assume out of range May 8 09:18:19 localhost kernel: hwcrypto disabled! May 8 09:18:20 localhost kernel: eth0: no IPv6 routers present May 8 09:18:22 localhost kernel: eth0: No STA entry for own AP 00:14:6a:5b:3a:80 May 8 09:18:22 localhost wpa_supplicant[3777]: Trying to associate with 00:14:6a:5b:3a:80 (SSID='INSIDE' freq=2417 MHz) May 8 09:18:22 localhost kernel: eth0: Initial auth_alg=0 May 8 09:18:22 localhost kernel: eth0: authenticate with AP 00:14:6a:5b:3a:80 May 8 09:18:22 localhost kernel: eth0: RX authentication from 00:14:6a:5b:3a:80 (alg=0 transaction=2 status=0) May 8 09:18:22 localhost kernel: eth0: authenticated May 8 09:18:22 localhost kernel: eth0: associate with AP 00:14:6a:5b:3a:80 May 8 09:18:22 localhost kernel: eth0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored May 8 09:18:22 localhost last message repeated 2 times May 8 09:18:22 localhost kernel: eth0: Initial auth_alg=0 May 8 09:18:22 localhost kernel: eth0: authenticate with AP 00:14:6a:5b:3a:80 May 8 09:18:22 localhost kernel: eth0: Initial auth_alg=0 May 8 09:18:22 localhost kernel: eth0: authenticate with AP 00:14:6a:5b:3a:80 May 8 09:18:22 localhost wpa_supplicant[3777]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys May 8 09:18:22 localhost kernel: eth0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) May 8 09:18:22 localhost kernel: eth0: deauthenticated May 8 09:18:22 localhost kernel: eth0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) Would it be useful to try this without NetworkManager? tom -- Tom London From tibbs at math.uh.edu Tue May 8 16:26:20 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 May 2007 11:26:20 -0500 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: >>>>> "JWL" == John W Linville writes: JWL> I am having mixed results with the latest iwl3945 updates, but JWL> I'm not sure if it is this particular laptop having problems or JWL> the driver in general. The last kernel I tried was 3138, and the iwl(whatever) driver actually killed the system there. (It oopsed and seemingly left interrupts disabled.) I posted a backtrace and system info on fedora-kernel a few days ago. I see 3143 in koji; I'll try it out as soon as I'm in the office. - J< From linville at redhat.com Tue May 8 16:29:49 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 8 May 2007 12:29:49 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178640767.3606.3.camel@hughsie-laptop> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> Message-ID: <20070508162949.GA24490@redhat.com> On Tue, May 08, 2007 at 05:12:47PM +0100, Richard Hughes wrote: > On Tue, 2007-05-08 at 16:57 +0100, Richard Hughes wrote: > > DaveJ's kernels seem to perform well for me as well. > > Nope, scrub that, I'm getting about a bazillion: > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > psmouse.c: issuing reconnect request > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > psmouse.c: Failed to reset mouse on isa0060/serio1 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > and my mouse pointer keeps jumping around every few minutes - most > irritating. I didn't get this with iwlwifi from git and a linus kernel. Well, that seems like a problem -- but I don't see a connection to iwl3945. John -- John W. Linville linville at redhat.com From linville at redhat.com Tue May 8 16:32:04 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 8 May 2007 12:32:04 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> References: <20070508130336.GB23247@redhat.com> <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> Message-ID: <20070508163204.GB24490@redhat.com> On Tue, May 08, 2007 at 09:26:03AM -0700, Tom London wrote: > CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > May 8 09:18:22 localhost kernel: eth0: RX deauthentication from > 00:14:6a:5b:3a:80 (reason=2) > May 8 09:18:22 localhost kernel: eth0: deauthenticated > May 8 09:18:22 localhost kernel: eth0: RX deauthentication from > 00:14:6a:5b:3a:80 (reason=2) > > Would it be useful to try this without NetworkManager? Maybe, but... I see a lot of "eth0" -- did you rename the interface? By default iwl3945 should have a name like "wlan0". John -- John W. Linville linville at redhat.com From selinux at gmail.com Tue May 8 16:46:12 2007 From: selinux at gmail.com (Tom London) Date: Tue, 8 May 2007 09:46:12 -0700 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508163204.GB24490@redhat.com> References: <20070508130336.GB23247@redhat.com> <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> <20070508163204.GB24490@redhat.com> Message-ID: <4c4ba1530705080946w45f53518tadaa5cadc6e92761@mail.gmail.com> On 5/8/07, John W. Linville wrote: > On Tue, May 08, 2007 at 09:26:03AM -0700, Tom London wrote: > > > CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys > > May 8 09:18:22 localhost kernel: eth0: RX deauthentication from > > 00:14:6a:5b:3a:80 (reason=2) > > May 8 09:18:22 localhost kernel: eth0: deauthenticated > > May 8 09:18:22 localhost kernel: eth0: RX deauthentication from > > 00:14:6a:5b:3a:80 (reason=2) > > > > Would it be useful to try this without NetworkManager? > > Maybe, but... > > I see a lot of "eth0" -- did you rename the interface? By default > iwl3945 should have a name like "wlan0". > > John > -- Don't know how that happened, but that seems to be the way it is...: lo no wireless extensions. irda0 no wireless extensions. wmaster0 no wireless extensions. Warning: Driver for device eth0 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken... eth0 IEEE 802.11a ESSID:"" Mode:Managed Frequency:5.18 GHz Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth1 no wireless extensions. vmnet8 no wireless extensions. vmnet1 no wireless extensions. I was running both iwlwifi and ipw3945 on the same kernel. Perhaps that got it 'renamed'. Not sure it matters, but I can probably try renaming it back..... tom -- Tom London From hughsient at gmail.com Tue May 8 16:48:41 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 8 May 2007 17:48:41 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508162949.GA24490@redhat.com> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> <20070508162949.GA24490@redhat.com> Message-ID: <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> On 08/05/07, John W. Linville wrote: > On Tue, May 08, 2007 at 05:12:47PM +0100, Richard Hughes wrote: > > On Tue, 2007-05-08 at 16:57 +0100, Richard Hughes wrote: > > > DaveJ's kernels seem to perform well for me as well. > > > > Nope, scrub that, I'm getting about a bazillion: > > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > psmouse.c: issuing reconnect request > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > > psmouse.c: Failed to reset mouse on isa0060/serio1 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > > and my mouse pointer keeps jumping around every few minutes - most > > irritating. I didn't get this with iwlwifi from git and a linus kernel. > > Well, that seems like a problem -- but I don't see a connection > to iwl3945. It stops (and returns to normal) when I rmmod the driver... Richard. From austinf at cetoncorp.com Tue May 8 17:17:18 2007 From: austinf at cetoncorp.com (Austin Foxley) Date: Tue, 08 May 2007 10:17:18 -0700 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <4640B09E.9070103@cetoncorp.com> John W. Linville wrote: > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. The 3142 kernel is the first one to work with the new driver for me, and it is working very well. I'm able to associate with my open network, and it stays up and working (so far). -Austin From dwmw2 at infradead.org Tue May 8 17:26:28 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 08 May 2007 18:26:28 +0100 Subject: F7 Zope package In-Reply-To: <1178640816.18982.11.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> Message-ID: <1178645188.2824.44.camel@pmac.infradead.org> On Tue, 2007-05-08 at 11:13 -0500, David G. Mackay wrote: > You seem to believe that the failure of Zope Corp to expend a major > effort that yields NO improvement to their product so that you can be > bothered to give their product away somehow makes a very useful package > undesirable. The only upstream problem that I see here is that the > python developers keep breaking compatibility with previous versions. It's got very little to do with upstream. The problem is that there is no _Fedora_ maintainer with enough time and energy to make the package work as part of _Fedora_. -- dwmw2 From tjb at unh.edu Tue May 8 17:44:58 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 08 May 2007 13:44:58 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178633019.20754.11.camel@raptor.sr.unh.edu> References: <20070508130336.GB23247@redhat.com> <1178633019.20754.11.camel@raptor.sr.unh.edu> Message-ID: <1178646298.20754.21.camel@raptor.sr.unh.edu> On Tue, 2007-05-08 at 10:03 -0400, Thomas J. Baker wrote: > On Tue, 2007-05-08 at 09:03 -0400, John W. Linville wrote: > > If you are a rawhide user/tester and have ipw3945 hardware, please > > try the latest kernels here: > > > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > > > I am having mixed results with the latest iwl3945 updates, but I'm > > not sure if it is this particular laptop having problems or the driver > > in general. > > > > Please give the latest kernels a try and let me know how it is working > > for you. Please also let me know what was the last kernel that worked > > any better for ipw3945 hardware than the current ones. > > > > At this point, I am quite uneasy about this driver. It seems to work > > fine at times, then crash or simply refuse to associate at others. > > I am considering backing it out to the 0.0.16 tag or possibly even > > removing it (since the driver has _still_ not been posted upstream). > > Thoughts? > > > > Thanks, > > > > John > > -- > > John W. Linville > > linville at redhat.com > > > > The 3142 kernel seems to work better than any iwlwifi enabled kernel > I've tried so far. I've had it running for 15 minutes cruising the web > and it hasn't reassociated or spewed any errors to the log yet. It even > connected to my preferred AP when I logged in. It previously always > seemed to fail the first time. > > I still get a hang at reboot or shutdown if I've logged in but I don't > know if that's related to iwlwifi or intel graphics drm being employed > by compiz. I got back from lunch and the wireless was down and out. I can't reconnect either. I can post the logs. What is the current relevant bugzilla bug? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From j.w.r.degoede at hhs.nl Tue May 8 18:02:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 20:02:23 +0200 Subject: F7 Zope package In-Reply-To: <1178634141.5880.10.camel@lincoln> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> Message-ID: <4640BB2F.1060602@hhs.nl> Brian Pepple wrote: > On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: >> What is happening here is that no matter who wants to maintain Python >> 2.4.x in whatever form for Fedora 7, the idea is being shot down since >> Jeremy (the main Python maintainer) does not like it. That is what >> needs a little explaining. All that I have seen is that it will cause >> "agonizing pain", "it is too difficult", etc.. > > No, the reason the idea is being shot down is because the majority of > FESCo does not like the idea. Why? If FESco cannot properly explain itself, I vote that we put this to a vote instead of letting FESco take a decision on their gut feeling. Fedora is supposed to be a democracy (ish) I'm now asking my representatives to explain their decision's / voting. Regards, Hans From j.w.r.degoede at hhs.nl Tue May 8 18:05:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 20:05:38 +0200 Subject: F7 Zope package In-Reply-To: <1178630295.342.22.camel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> Message-ID: <4640BBF2.4030502@hhs.nl> Nicolas Mailhot wrote: > Le mardi 08 mai 2007 ? 14:53 +0200, Hans de Goede a ?crit : > >> But I see a serious lack of respect for our end users here. > > I see a serious lack of respect for the release process and all the > packagers that followed it if a single user causing enough noise on the > lists can force the fork of a major distro component against the wishes > of its maintainer on the eve of a release for a single app without the > upstream of said app being involved and expressing any form of > commitment to help clear the mess. > > May as well trumpet "our release process is a joke" and "people who > follow it are morons afraid of a little flaming". > > Think we're not creating a precedent now? Read the thread. Every past > compat package is used as an argument to ignore test releases and the > fact python 2.5 hit rawhide 10 months ago. > > Do we want to be flamed every time there is a roadmap clash because > people feel it's easier to change ours than fix the problem upstream > (upstream, upstream, usptream, remember ?) > You're getting me wrong, I'm not advocating a last minute rush to fix this. I mearly want to know why FESco decided as it did. Sofar no-one has been able to explain that properly to me. Also I almost always read the FESco meeting minutes, and I cannot remember seeing this there. But thats probably my fault, can someone point me to the minutes of the meeting where this was decided? Regards, Hans From tjb at unh.edu Tue May 8 17:51:38 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 08 May 2007 13:51:38 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178646298.20754.21.camel@raptor.sr.unh.edu> References: <20070508130336.GB23247@redhat.com> <1178633019.20754.11.camel@raptor.sr.unh.edu> <1178646298.20754.21.camel@raptor.sr.unh.edu> Message-ID: <1178646698.20754.24.camel@raptor.sr.unh.edu> On Tue, 2007-05-08 at 13:44 -0400, Thomas J. Baker wrote: > On Tue, 2007-05-08 at 10:03 -0400, Thomas J. Baker wrote: > > On Tue, 2007-05-08 at 09:03 -0400, John W. Linville wrote: > > > If you are a rawhide user/tester and have ipw3945 hardware, please > > > try the latest kernels here: > > > > > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > > > > > I am having mixed results with the latest iwl3945 updates, but I'm > > > not sure if it is this particular laptop having problems or the driver > > > in general. > > > > > > Please give the latest kernels a try and let me know how it is working > > > for you. Please also let me know what was the last kernel that worked > > > any better for ipw3945 hardware than the current ones. > > > > > > At this point, I am quite uneasy about this driver. It seems to work > > > fine at times, then crash or simply refuse to associate at others. > > > I am considering backing it out to the 0.0.16 tag or possibly even > > > removing it (since the driver has _still_ not been posted upstream). > > > Thoughts? > > > > > > Thanks, > > > > > > John > > > -- > > > John W. Linville > > > linville at redhat.com > > > > > > > The 3142 kernel seems to work better than any iwlwifi enabled kernel > > I've tried so far. I've had it running for 15 minutes cruising the web > > and it hasn't reassociated or spewed any errors to the log yet. It even > > connected to my preferred AP when I logged in. It previously always > > seemed to fail the first time. > > > > I still get a hang at reboot or shutdown if I've logged in but I don't > > know if that's related to iwlwifi or intel graphics drm being employed > > by compiz. > > I got back from lunch and the wireless was down and out. I can't > reconnect either. I can post the logs. What is the current relevant > bugzilla bug? > I guess I should add that the important log lines seem to be: iwl3945: Error not a valid ipw_rxon_assoc_cmd field values iwl3945: Invalid RXON configuration. Not committing. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From linville at redhat.com Tue May 8 17:54:01 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 8 May 2007 13:54:01 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178646298.20754.21.camel@raptor.sr.unh.edu> References: <20070508130336.GB23247@redhat.com> <1178633019.20754.11.camel@raptor.sr.unh.edu> <1178646298.20754.21.camel@raptor.sr.unh.edu> Message-ID: <20070508175401.GB25284@redhat.com> On Tue, May 08, 2007 at 01:44:58PM -0400, Thomas J. Baker wrote: > On Tue, 2007-05-08 at 10:03 -0400, Thomas J. Baker wrote: > > The 3142 kernel seems to work better than any iwlwifi enabled kernel > > I've tried so far. I've had it running for 15 minutes cruising the web > > and it hasn't reassociated or spewed any errors to the log yet. It even > > connected to my preferred AP when I logged in. It previously always > > seemed to fail the first time. > > > > I still get a hang at reboot or shutdown if I've logged in but I don't > > know if that's related to iwlwifi or intel graphics drm being employed > > by compiz. > > I got back from lunch and the wireless was down and out. I can't > reconnect either. I can post the logs. What is the current relevant > bugzilla bug? Hmmm...maybe this one? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235247 John -- John W. Linville linville at redhat.com From linville at redhat.com Tue May 8 17:55:37 2007 From: linville at redhat.com (John W. Linville) Date: Tue, 8 May 2007 13:55:37 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4c4ba1530705080946w45f53518tadaa5cadc6e92761@mail.gmail.com> References: <20070508130336.GB23247@redhat.com> <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> <20070508163204.GB24490@redhat.com> <4c4ba1530705080946w45f53518tadaa5cadc6e92761@mail.gmail.com> Message-ID: <20070508175537.GC25284@redhat.com> On Tue, May 08, 2007 at 09:46:12AM -0700, Tom London wrote: > On 5/8/07, John W. Linville wrote: > >I see a lot of "eth0" -- did you rename the interface? By default > >iwl3945 should have a name like "wlan0". > Not sure it matters, but I can probably try renaming it back..... No, fine. Just wanted to make sure we were on the same page. :-) -- John W. Linville linville at redhat.com From bpepple at fedoraproject.org Tue May 8 17:59:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 08 May 2007 13:59:45 -0400 Subject: F7 Zope package In-Reply-To: <4640BBF2.4030502@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <4640BBF2.4030502@hhs.nl> Message-ID: <1178647185.14795.0.camel@lincoln> On Tue, 2007-05-08 at 20:05 +0200, Hans de Goede wrote: > > You're getting me wrong, I'm not advocating a last minute rush to fix this. I > mearly want to know why FESco decided as it did. Sofar no-one has been able to > explain that properly to me. Also I almost always read the FESco meeting > minutes, and I cannot remember seeing this there. But thats probably my fault, > can someone point me to the minutes of the meeting where this was decided? > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue May 8 18:01:12 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 08 May 2007 14:01:12 -0400 Subject: F7 Zope package In-Reply-To: <4640BB2F.1060602@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640BB2F.1060602@hhs.nl> Message-ID: <1178647272.14795.2.camel@lincoln> On Tue, 2007-05-08 at 20:02 +0200, Hans de Goede wrote: > Brian Pepple wrote: > > On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: > >> What is happening here is that no matter who wants to maintain Python > >> 2.4.x in whatever form for Fedora 7, the idea is being shot down since > >> Jeremy (the main Python maintainer) does not like it. That is what > >> needs a little explaining. All that I have seen is that it will cause > >> "agonizing pain", "it is too difficult", etc.. > > > > No, the reason the idea is being shot down is because the majority of > > FESCo does not like the idea. > > Why? If FESco cannot properly explain itself, I vote that we put this to a vote > instead of letting FESco take a decision on their gut feeling. > > Fedora is supposed to be a democracy (ish) I'm now asking my representatives to > explain their decision's / voting. You can see the discussion in the IRC log for that meeting: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From emmanuel.seyman at club-internet.fr Tue May 8 18:08:31 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 8 May 2007 20:08:31 +0200 Subject: F7 Zope package In-Reply-To: <4640BBF2.4030502@hhs.nl> References: <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <4640BBF2.4030502@hhs.nl> Message-ID: <20070508180831.GA605@orient.maison.lan> * Hans de Goede [08/05/2007 19:50] : > > I mearly want to know why FESco decided as it did. Sofar no-one has been > able to explain that properly to me. Also I almost always read the FESco > meeting minutes, and I cannot remember seeing this there. But thats > probably my fault, can someone point me to the minutes of the meeting where > this was decided? http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 Emmanuel From j.w.r.degoede at hhs.nl Tue May 8 18:28:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 20:28:06 +0200 Subject: F7 Zope package In-Reply-To: <1178647272.14795.2.camel@lincoln> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640BB2F.1060602@hhs.nl> <1178647272.14795.2.camel@lincoln> Message-ID: <4640C136.3080001@hhs.nl> Brian Pepple wrote: > On Tue, 2007-05-08 at 20:02 +0200, Hans de Goede wrote: >> Brian Pepple wrote: >>> On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: >>>> What is happening here is that no matter who wants to maintain Python >>>> 2.4.x in whatever form for Fedora 7, the idea is being shot down since >>>> Jeremy (the main Python maintainer) does not like it. That is what >>>> needs a little explaining. All that I have seen is that it will cause >>>> "agonizing pain", "it is too difficult", etc.. >>> No, the reason the idea is being shot down is because the majority of >>> FESCo does not like the idea. >> Why? If FESco cannot properly explain itself, I vote that we put this to a vote >> instead of letting FESco take a decision on their gut feeling. >> >> Fedora is supposed to be a democracy (ish) I'm now asking my representatives to >> explain their decision's / voting. > > You can see the discussion in the IRC log for that meeting: > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 > Yes I just read it, and it is very sloppy decision making, I see 2 against (one verbal, abstained from voting, one vote) and 3 in favor's. And also lots of unexplored options, for example Jeremy never said what he found of having a /usr/bin/runzope, the zope maintainer never got asked if he would be willing to maintain a runzope package, etc. I urge FESco to bring this back to the table again, and this time do their "homework". Ask Jeremy if the private copy of python 2.4 inside the zope package is acceptable, ask the zope maintainer if the is willing todo that. I know that no matter which way the decision is made, this won't get us a working zope with the the release. But if a solution is found, then maybe we can have a working zope as an update, that would look way better in the release notes, then what boils down to: "If you use zope, go looking for another distro" Also although I understand Jeremy concerns this FESco decision draws close to censorship and I don't think thats something which we want. Regards, Hans From emmanuel.seyman at club-internet.fr Tue May 8 18:27:41 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 8 May 2007 20:27:41 +0200 Subject: F7 Zope package In-Reply-To: <4640C136.3080001@hhs.nl> References: <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640BB2F.1060602@hhs.nl> <1178647272.14795.2.camel@lincoln> <4640C136.3080001@hhs.nl> Message-ID: <20070508182740.GA996@orient.maison.lan> * Hans de Goede [08/05/2007 20:13] : > > I know that no matter which way the decision is made, this won't get us a > working zope with the the release. But if a solution is found, then maybe > we can have a working zope as an update, that would look way better in the > release notes, then what boils down to: "If you use zope, go looking for > another distro" There's a simpler solution : Make a third party repo that delivers zope-runtime (the-language-formerly-known-as-python-2.4 ?) + zope + anything else you see fit and maintain it until Zope 3 is included in Fedora. Users will just go to a website, click on a rpm, click twice on "OK" and then run "yum install zope" (or whatever the equivalent for their favourite backend is). Emmanuel From valent.turkovic at gmail.com Tue May 8 18:29:19 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 8 May 2007 20:29:19 +0200 Subject: yum-presto and $basearch In-Reply-To: <1176040743.28372.1.camel@jndwidescreen.lesbg.loc> References: <1176036885.3909.4.camel@eagle.danny.cz> <1176040743.28372.1.camel@jndwidescreen.lesbg.loc> Message-ID: <64b14b300705081129l1300a0e5p3638ad34686cc621@mail.gmail.com> I'm testing presto at the moment... and can you expain how previous versions of presto worked without the need to edit fedora-updates.repo file? presto worked the first time I installed it, and it stoped now untill I added "deltaurl= http://www.lesbg.com/jdieter/updates/fc$releasever/$basearch" line in fedora-updates.repo can you make it so it works by default without that line? On 4/8/07, Jonathan Dieter wrote: > > On Sun, 2007-04-08 at 14:54 +0200, Dan Hor?k wrote: > > Hello Jonathan,fedora-updates.repo > > > > is it possible for yum-presto to interpret $basearch and $releasever > > variables in its URLs in the config file? > > > > > > Dan > > > > > I probably could get it to work in the presto.conf file, but it works > automatically if you add > deltaurl=http://www.lesbg.com/jdieter/updates/fc$releasever/$basearch to > fedora-updates.repo. > > Jonathan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Tue May 8 18:40:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 13:40:18 -0500 Subject: F7 Zope package In-Reply-To: <4640C136.3080001@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640BB2F.1060602@hhs.nl> <1178647272.14795.2.camel@lincoln> <4640C136.3080001@hhs.nl> Message-ID: <1178649619.3175.9.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 20:28 +0200, Hans de Goede wrote: > > You can see the discussion in the IRC log for that meeting: > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 > > > > Yes I just read it, and it is very sloppy decision making, I see 2 against (one > verbal, abstained from voting, one vote) and 3 in favor's. And also lots of > unexplored options, for example Jeremy never said what he found of having a > /usr/bin/runzope, the zope maintainer never got asked if he would be willing to > maintain a runzope package, etc. > > I urge FESco to bring this back to the table again, and this time do their > "homework". Ask Jeremy if the private copy of python 2.4 inside the zope > package is acceptable, ask the zope maintainer if the is willing todo that. Both of them have been active in this thread. You just essentially asked them. And according to the logs you supposedly read, Jeremy and the zope maintainer _did_ have a conversation about it already. He _was_ asked. > I know that no matter which way the decision is made, this won't get us a > working zope with the the release. But if a solution is found, then maybe we > can have a working zope as an update, that would look way better in the release > notes, then what boils down to: "If you use zope, go looking for another distro" The release notes are frozen (at least the ones that make it on the media). > Also although I understand Jeremy concerns this FESco decision draws close to > censorship and I don't think thats something which we want. This is not censorship. Not even close. Censorship would be banning any further discussion on this topic, which nobody is going to do. josh From valent.turkovic at gmail.com Tue May 8 18:49:33 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 8 May 2007 20:49:33 +0200 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <200704121437.58088.jkeating@redhat.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> Message-ID: <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> On 4/12/07, Jesse Keating wrote: > > On Thursday 12 April 2007 14:27:45 Jonathan Dieter wrote: > > Jesse, I totally understand where you're coming from on the "it should > > have been started in Rawhide". I'm afraid that's my fault, though I'll > > beg extenuating circumstances. I live and work in Beirut where > > broadband means anything but (thus my interest in the problem in the > > first place). > > Well, even if development started in fc6, that's fine. I think DEPLOYMENT > should begin with rawhide, and work its way down. > > > Finally, when we do get to the point of "do we put deltarpms in the > > master mirror", *if* we decide *not* to (for the many reasons mentioned > > by those against the idea), is it possible for yum-presto in Extras to > > point to the test server in the default .conf file? > > Typically we don't allow packages other than fedora-release to add repo > files. > Maybe we could grant an exception for this package for a temporary time > being, but once a repo file is on, it is difficult to get it off, so > wherever > you point you might want to be willing to at least maintain a redirect to > somewhere where content lives. > > -- > Jesse Keating > Release Engineer: Fedora Hi, can you please update us with the status of yum-presto and Fedora 7? I installed Fedora 7 test 4 and I don't see yum-prest and deltarpm installed by default. Will this change in the mean time so it is installed by default when Fedora 7 ships? I can only say that deltarpm is a great idea, and works great in practice (on Fedora Core 6 - I still haven't tested it on Fedora 7). It is maybe little less needed when people install new pacgakes but for updates it is a godsend... You should think how to enable more and more people to use linux, and great features like fast updates with small bandwidth cost is a really big benefit to linux users. There are millions of people with dialup and other slow connections on our planet and updates for them are almost impossible. Or students with laptops who can do some big installs when they are at their university but at home have also slow connection. For all of them bandwidth is scarce and deltarpms is a great solution to that problem so please do all you can with implementing it. Thank you in advance. Valent from Croatia. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Tue May 8 18:43:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 13:43:39 -0500 Subject: F7 Zope package In-Reply-To: <4640BB2F.1060602@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640BB2F.1060602@hhs.nl> Message-ID: <1178649819.3175.12.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 20:02 +0200, Hans de Goede wrote: > Brian Pepple wrote: > > On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: > >> What is happening here is that no matter who wants to maintain Python > >> 2.4.x in whatever form for Fedora 7, the idea is being shot down since > >> Jeremy (the main Python maintainer) does not like it. That is what > >> needs a little explaining. All that I have seen is that it will cause > >> "agonizing pain", "it is too difficult", etc.. > > > > No, the reason the idea is being shot down is because the majority of > > FESCo does not like the idea. > > Why? If FESco cannot properly explain itself, I vote that we put this to a vote > instead of letting FESco take a decision on their gut feeling. Are you suggesting an escalation to the Fedora Board? There is no authority higher than FESCo other than the Board. josh From jwboyer at jdub.homelinux.org Tue May 8 18:46:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 13:46:21 -0500 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> Message-ID: <1178649981.3175.16.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 20:49 +0200, Valent Turkovic wrote: > > Hi, can you please update us with the status of yum-presto and Fedora > 7? > > I installed Fedora 7 test 4 and I don't see yum-prest and deltarpm > installed by default. It won't be. > Will this change in the mean time so it is installed by default when > Fedora 7 ships? No. > I can only say that deltarpm is a great idea, and works great in > practice (on Fedora Core 6 - I still haven't tested it on Fedora 7). > > It is maybe little less needed when people install new pacgakes but > for updates it is a godsend... > > You should think how to enable more and more people to use linux, and > great features like fast updates with small bandwidth cost is a really > big benefit to linux users. > > There are millions of people with dialup and other slow connections on > our planet and updates for them are almost impossible. Or students > with laptops who can do some big installs when they are at their > university but at home have also slow connection. > > For all of them bandwidth is scarce and deltarpms is a great solution > to that problem so please do all you can with implementing it. These are all perfectly valid reasons. However, it is entirely too late to enable this by default for Fedora 7. And, realistically, it should be tested throughout a development cycle in rawhide before being enabled by default for a released distro. josh From valent.turkovic at gmail.com Tue May 8 18:53:16 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 8 May 2007 20:53:16 +0200 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> Message-ID: <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> Please look at this: Size of all updates downloaded from Presto-enabled repositories: 14M Size of updates that would have been downloaded if Presto wasn't enabled: 32M This is a savings of 56 percent Updated: gimp.i386 2:2.2.14-5.fc6 gimp-libs.i386 2:2.2.14-5.fc6 gnome-media.i386 0:2.16.1-4.fc6 gstreamer.i386 0:0.10.11-1.fc6 gstreamer-plugins-base.i386 0:0.10.11-1.fc6 gstreamer-tools.i386 0: 0.10.11-1.fc6 gtk2.i386 0:2.10.8-3.fc6 hpijs.i386 1:1.7.2-3.fc6 hplip.i3860: 1.7.2-3.fc6 httpd.i386 0:2.2.4-2.fc6 httpd-manual.i386 0:2.2.4-2.fc6 Dependency Updated: mod_ssl.i386 1:2.2.4-2.fc6 Complete! -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Tue May 8 19:06:21 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 8 May 2007 21:06:21 +0200 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> Message-ID: <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> Full update gave me even better results!!! 75% savings !!! Size of all updates downloaded from Presto-enabled repositories: 10M Size of updates that would have been downloaded if Presto wasn't enabled: 41M This is a savings of 75 percent Dependency Installed: freeglut.i386 0:2.4.0-11.fc6 libcaca.i386 0: 0.99-0.1.beta11.fc6 libfame.i386 0:0.9.1-12.fc6 xine-lib-moles.i386 0: 1.1.6-1.fc6 Updated: coreutils.i386 0:5.97-12.5.fc6 dbus.i386 0:1.0.1-12.fc6 dbus-devel.i386 0:1.0.1-12.fc6 dbus-x11.i386 0:1.0.1-12.fc6 elfutils.i386 0: 0.127-1.fc6 elfutils-libelf.i386 0:0.127-1.fc6 elfutils-libelf-devel.i386 0: 0.127-1.fc6 elfutils-libelf-devel-static.i386 0:0.127-1.fc6 elfutils-libs.i386 0:0.127-1.fc6 evolution-data-server.i386 0:1.8.3-6.fc6 iputils.i386 0:20070202-3.fc6 kernel-headers.i386 0:2.6.20-1.2948.fc6 krename.i386 0:3.0.14-1.fc6 lftp.i386 0:3.5.9-0.fc6 libsane-hpaio.i386 0: 1.7.2-3.fc6 libupnp.i386 0:1.4.6-1.fc6 libxml2.i386 0:2.6.28-1.fc6 libxml2-devel.i386 0:2.6.28-1.fc6 libxml2-python.i386 0:2.6.28-1.fc6 m4.i3860: 1.4.8-2 php.i386 0:5.1.6-3.5.fc6 php-cli.i386 0:5.1.6-3.5.fc6 php-common.i386 0:5.1.6-3.5.fc6 php-ldap.i386 0:5.1.6-3.5.fc6 php-mysql.i3860: 5.1.6-3.5.fc6 php-pdo.i386 0:5.1.6-3.5.fc6 policycoreutils.i386 0: 1.34.1-9.fc6 popt.i386 0:1.10.2-33.fc6 pygobject2.i386 0:2.12.3-2.fc6 python-mutagen.noarch 0:1.11-1.fc6 rpm.i386 0:4.4.2-33.fc6 rpm-build.i386 0: 4.4.2-33.fc6 rpm-devel.i386 0:4.4.2-33.fc6 rpm-libs.i386 0:4.4.2-33.fc6 rpm-python.i386 0:4.4.2-33.fc6 selinux-policy.noarch 0:2.4.6-62.fc6 selinux-policy-targeted.noarch 0:2.4.6-62.fc6 smartmontools.i386 1: 5.37-1.1.fc6 subversion.i386 0:1.4.3-2.fc6 system-config-date.noarch 0: 1.8.12-2.fc6 tar.i386 2:1.15.1-25.fc6 tcp_wrappers.i386 0:7.6-40.3.fc6 vim-common.i386 2:7.0.235-1.fc6 vim-enhanced.i386 2:7.0.235-1.fc6 vim-minimal.i386 2:7.0.235-1.fc6 xine.i386 0:0.99.5-1.fc6 xine-lib.i386 0: 1.1.6-2.fc6 xsane.i386 0:0.994-2.fc6 xsane-gimp.i386 0:0.994-2.fc6 xterm.i386 0:225-1.fc6 Complete! -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Tue May 8 19:34:28 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 08 May 2007 21:34:28 +0200 Subject: F7 Zope package In-Reply-To: <1178634141.5880.10.camel@lincoln> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> Message-ID: <4640D0C4.8060408@poolshark.org> Brian Pepple wrote: > On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: >> What is happening here is that no matter who wants to maintain Python >> 2.4.x in whatever form for Fedora 7, the idea is being shot down since >> Jeremy (the main Python maintainer) does not like it. That is what >> needs a little explaining. All that I have seen is that it will cause >> "agonizing pain", "it is too difficult", etc.. > > No, the reason the idea is being shot down is because the majority of > FESCo does not like the idea. You are seriously mis-characterizing > FESCo's decision by implying that Jeremy is the sole reason that Python > 2.4 is not being maintained in F7. Why does this even have to go to FESCO in the first place ? We should just make a Call For Submissions for packagers to try Alan's idea and package python 2.4 with zope, and it should just go through the regular review process... If it's really too difficult to do, we'll either have noone willing to do the work, or the submitted packages will have too many problems to go through review. Just follow the process... From opensource at till.name Tue May 8 19:40:23 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 21:40:23 +0200 Subject: F7 Zope package In-Reply-To: <1178649619.3175.9.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> Message-ID: <200705082140.25186.opensource@till.name> On Di Mai 8 2007, Josh Boyer wrote: > The release notes are frozen (at least the ones that make it on the > media). Is there no procedure to add important forgotten release notes additions there? It is kind of sad that in this thread it is critized that Zope upstream is unable to port Zope to python 2.5 within 9 months but Fedora is not able to mention this in the release notes on the media. Regards, Till From jwboyer at jdub.homelinux.org Tue May 8 19:58:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 14:58:24 -0500 Subject: F7 Zope package In-Reply-To: <200705082140.25186.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> Message-ID: <1178654305.3175.28.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 21:40 +0200, Till Maas wrote: > On Di Mai 8 2007, Josh Boyer wrote: > > > The release notes are frozen (at least the ones that make it on the > > media). > > Is there no procedure to add important forgotten release notes additions > there? It is kind of sad that in this thread it is critized that Zope > upstream is unable to port Zope to python 2.5 within 9 months but Fedora is > not able to mention this in the release notes on the media. Not that I'm aware of. They're frozen for translations, and adding stuff after the fact makes it impossible to fully translate things. However, the media release notes always say "the most recent copy of the release notes are on the wiki", which do get updated. josh From j.w.r.degoede at hhs.nl Tue May 8 20:22:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 22:22:53 +0200 Subject: F7 Zope package In-Reply-To: <4640D0C4.8060408@poolshark.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640D0C4.8060408@poolshark.org> Message-ID: <4640DC1D.3010202@hhs.nl> Denis Leroy wrote: > Brian Pepple wrote: >> On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: >>> What is happening here is that no matter who wants to maintain Python >>> 2.4.x in whatever form for Fedora 7, the idea is being shot down since >>> Jeremy (the main Python maintainer) does not like it. That is what >>> needs a little explaining. All that I have seen is that it will cause >>> "agonizing pain", "it is too difficult", etc.. >> >> No, the reason the idea is being shot down is because the majority of >> FESCo does not like the idea. You are seriously mis-characterizing >> FESCo's decision by implying that Jeremy is the sole reason that Python >> 2.4 is not being maintained in F7. > > Why does this even have to go to FESCO in the first place ? We should > just make a Call For Submissions for packagers to try Alan's idea and > package python 2.4 with zope, and it should just go through the regular > review process... If it's really too difficult to do, we'll either have > noone willing to do the work, or the submitted packages will have too > many problems to go through review. Just follow the process... > +1. but for some reason FESco has decided to veto this before its even tried, hence my comparison to censorship. Regards, Hans From sundaram at fedoraproject.org Tue May 8 20:11:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 01:41:38 +0530 Subject: F7 Zope package In-Reply-To: <200705082140.25186.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> Message-ID: <4640D97A.6090702@fedoraproject.org> Till Maas wrote: > On Di Mai 8 2007, Josh Boyer wrote: > >> The release notes are frozen (at least the ones that make it on the >> media). > > Is there no procedure to add important forgotten release notes additions > there? It is kind of sad that in this thread it is critized that Zope > upstream is unable to port Zope to python 2.5 within 9 months but Fedora is > not able to mention this in the release notes on the media. You are too late for the release notes in the media. There has been several announcements here explaining the process. What is really sad is very few people have bothered to read it or contribute to the release notes. FC5 and FC6 both had post release errata for the release notes. Even when the translation freeze is there you can continue to make changes in the wiki. Notes on Zope has already been added to http://fedoraproject.org/wiki/Docs/Beats/PackageNotes. A web update at http://docs.fedoraproject.org will be published in sync with the Fedora 7 release. Release notes has been separated from the fedora-release package from FC6 onwards and updated content can be pushed out easily. Rahul From jwboyer at jdub.homelinux.org Tue May 8 20:05:52 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:05:52 -0500 Subject: F7 Zope package In-Reply-To: <4640D0C4.8060408@poolshark.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640D0C4.8060408@poolshark.org> Message-ID: <1178654753.3175.31.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 21:34 +0200, Denis Leroy wrote: > Brian Pepple wrote: > > On Tue, 2007-05-08 at 18:42 +0530, Debarshi 'Rishi' Ray wrote: > >> What is happening here is that no matter who wants to maintain Python > >> 2.4.x in whatever form for Fedora 7, the idea is being shot down since > >> Jeremy (the main Python maintainer) does not like it. That is what > >> needs a little explaining. All that I have seen is that it will cause > >> "agonizing pain", "it is too difficult", etc.. > > > > No, the reason the idea is being shot down is because the majority of > > FESCo does not like the idea. You are seriously mis-characterizing > > FESCo's decision by implying that Jeremy is the sole reason that Python > > 2.4 is not being maintained in F7. > > Why does this even have to go to FESCO in the first place ? We should > just make a Call For Submissions for packagers to try Alan's idea and > package python 2.4 with zope, and it should just go through the regular > review process... If it's really too difficult to do, we'll either have > noone willing to do the work, or the submitted packages will have too > many problems to go through review. Just follow the process... Except it already went to FESCo. Trying to undo the decision by just submitting a package and hoping it passes review likely isn't the best way to go about things. josh From emmanuel.seyman at club-internet.fr Tue May 8 20:15:54 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 8 May 2007 22:15:54 +0200 Subject: F7 Zope package In-Reply-To: <1178572220.12774.146.camel@vorpal.macdev.com> References: <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <1178568532.12774.115.camel@vorpal.macdev.com> <20070507203634.GA23167@orient.maison.lan> <1178572220.12774.146.camel@vorpal.macdev.com> Message-ID: <20070508201554.GA1609@orient.maison.lan> * David G. Mackay [08/05/2007 07:17] : > > And not shipping multimedia components that > are illegal in the US is a lot more palatable than not shipping a > product because it's inconvenient to package a dependency. Xmms was removed from Fedora Core because it depended on gtk-1.x (which was retired because it was a legacy library), not because of its legal status (mp3 support had been removed by this point). Emmanuel From debarshi.ray at gmail.com Tue May 8 20:17:18 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 9 May 2007 01:47:18 +0530 Subject: F7 Zope package In-Reply-To: <1178654305.3175.28.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> Message-ID: <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> >> It is kind of sad that in this thread it is critized that Zope >> upstream is unable to port Zope to python 2.5 within 9 months but Fedora is >> not able to mention this in the release notes on the media. > Not that I'm aware of. They're frozen for translations, and adding > stuff after the fact makes it impossible to fully translate things. You do not get the point. What Till was trying to indicate is that while we are criticising Zope for not migrating to Python 2.5 over the last 9 months, Fedora has not been able to mention their dropping of Zope in the release notes. Now, the question that arises is whether porting Zope to Python 2.5 is easier, or mentioning Zope's inability to do so and the consequences thereof in the release notes is easier? Or was the decision to drop Zope was taken too late to be included in the release notes? > However, the media release notes always say "the most recent copy of the > release notes are on the wiki", which do get updated. This is only applicable for last minute decisions. As far as I understand, the decision to drop Zope, Plone and Python 2.4 was a strategic decision. If it was a last minute one too, then it is indeed very sad. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mackay_d at bellsouth.net Tue May 8 18:44:39 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 13:44:39 -0500 Subject: F7 Zope package In-Reply-To: <1178645188.2824.44.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> <1178645188.2824.44.camel@pmac.infradead.org> Message-ID: <1178649879.19523.17.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 18:26 +0100, David Woodhouse wrote: > It's got very little to do with upstream. The problem is that there is > no _Fedora_ maintainer with enough time and energy to make the package > work as part of _Fedora_. I have asked several times what leads to the expectation that a package that has been the primary package for FC6 and generated only 12 bugzilla entries during that time would suddenly become a massive problem. I can understand that care would need to be taken to prevent unintended interactions between 2.4 and 2.5, but that's doable. More specifically, we've discussed the option of putting it under the zope directory hierarchy. Someone would have to actively dig to find it and use it out of context if that were the case. Dave From j.w.r.degoede at hhs.nl Tue May 8 20:42:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 22:42:00 +0200 Subject: Sun just released the JDK under the GPL implications for F8 / F9? Message-ID: <4640E098.6@hhs.nl> Hi all, Sun has just released (most of) the JDK under the GPL, hurray! Looking forward to the next devel cycle what will this mean? I haven't looked yet at which parts are missing, as some parts are missing since they are not Sun's to open. But I think we need a new java strategy for F8, or otherwise surely F9, taking the GPL JDK into account. In my limited experience gcj, although a great achievement, fails to run many java programs, including many opensource java programs, out of the box. I've been tempted sometimes to try and fix either the app or gcj, but after Sun's promise I've opted to invest my time elsewhere. Although I'm a java noob, I'm also a quick learner, and I'm thinking about sinking some serious time into this, but we first need a strategy I think. Well thats really all I've to say about this, not much really, but I'm kind hoping this will be the start of a very interesting thread :) Regards, Hans From debarshi.ray at gmail.com Tue May 8 20:30:09 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 9 May 2007 02:00:09 +0530 Subject: F7 Zope package In-Reply-To: <1178654753.3175.31.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640D0C4.8060408@poolshark.org> <1178654753.3175.31.camel@vader.jdub.homelinux.org> Message-ID: <3170f42f0705081330k50cdcdf9y1bb088fba6a9446b@mail.gmail.com> > Except it already went to FESCo. Trying to undo the decision by just > submitting a package and hoping it passes review likely isn't the best > way to go about things. Arguments like this will neither solve the problem, nor take this decision any further. All that people (not some 'single user') are asking is FESCo explain why they took this decision, not keep repeating things like "it is too difficult and painful", "read the release notes on the Wiki", etc.. Those are neither reasons nor explanations. Given the fact that Python 2.4 has been around for so long and that it had generated only 12 bug reports for FC6, I do not see how providing a compat-python package is so big a problem. I do not see how a /usr/bin/python2.4 will cause such a huge number of confusing bug reports, since a newbie (who does not know about python & compat-python) will simply use 'python' and not hunt for 'python24' in the distribution in the first place. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From emmanuel.seyman at club-internet.fr Tue May 8 20:29:25 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 8 May 2007 22:29:25 +0200 Subject: F7 Zope package In-Reply-To: <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> Message-ID: <20070508202925.GA1768@orient.maison.lan> * Debarshi 'Rishi' Ray [08/05/2007 22:21] : > > >However, the media release notes always say "the most recent copy of the > >release notes are on the wiki", which do get updated. > > This is only applicable for last minute decisions. Is this true? I've always been under the impression that anything that the rel-notes writers had missed pre-release could be included in the updates. Emmanuel From sundaram at fedoraproject.org Tue May 8 20:33:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 02:03:43 +0530 Subject: F7 Zope package In-Reply-To: <20070508202925.GA1768@orient.maison.lan> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> Message-ID: <4640DEA7.4050403@fedoraproject.org> Emmanuel Seyman wrote: > * Debarshi 'Rishi' Ray [08/05/2007 22:21] : >>> However, the media release notes always say "the most recent copy of the >>> release notes are on the wiki", which do get updated. >> This is only applicable for last minute decisions. > > Is this true? I've always been under the impression that anything that the > rel-notes writers had missed pre-release could be included in the updates. That's correct. The process is not just for last minute decisions. The number of people who work on the release notes is very few and we do miss things that gets pointed out and added later. Rahul From debarshi.ray at gmail.com Tue May 8 20:40:09 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 9 May 2007 02:10:09 +0530 Subject: F7 Zope package In-Reply-To: <4640DEA7.4050403@fedoraproject.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> Message-ID: <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> >>>> However, the media release notes always say "the most recent copy of the >>>> release notes are on the wiki", which do get updated. >>> This is only applicable for last minute decisions. >> Is this true? I've always been under the impression that anything that the >> rel-notes writers had missed pre-release could be included in the updates. > That's correct. The process is not just for last minute decisions. The > number of people who work on the release notes is very few and we do > miss things that gets pointed out and added later. I am not talking about what the rule book says. I can not help noticing how we are being really rigid while saying, "If Zope can not migrate to a later release of Python in one year its their headache, God help them.", but keep giving excuses why such a big development does not make it to the on-media release notes. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From overholt at redhat.com Tue May 8 20:37:30 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 08 May 2007 16:37:30 -0400 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <4640E098.6@hhs.nl> References: <4640E098.6@hhs.nl> Message-ID: <1178656650.9601.73.camel@localhost.localdomain> On Tue, 2007-08-05 at 22:42 +0200, Hans de Goede wrote: > Well thats really all I've to say about this, not much really, but I'm kind > hoping this will be the start of a very interesting thread :) Just FYI: a few of the leaders Fedora's java stuff are at JavaOne this week so I doubt they'll have time to respond that quickly. I speak with no authority but I'm sure we'll have OpenJDK in Fedora 8 if not some time in the Fedora 7 cycle. There are still the encumbered bits to work out in the short term. In the longer term, we need to think about platform coverage. I'm confident, though, that we'll have an openjdk alternative (as in alternatives) soon. fedora-devel-java-list is where most of the discussion will take place, I imagine. HTH, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Tue May 8 20:45:10 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 8 May 2007 22:45:10 +0200 Subject: Installation of Flash plugin on Fedora 7 test 4 in Firefox Message-ID: <64b14b300705081345l72a1f550me7a30c357b1e9468@mail.gmail.com> I tried installing adobe flash plugin on clean install of Fedora 7 test 4. It failed 2-3 times then I recorded my first video of it failing for bug submission. And here is the video: http://www.youtube.com/watch?v=g9zI9vpLdgM Should this be reported as a bug? And if yes - where? Is this a Firefox bug? After that I tied once more and it failed again. Then I started recording it again, and then it seceded! Here is the video of it: http://www.youtube.com/watch?v=666z1sGfEv8 What are other people's experience with installing flash under Fedora 7? It is great that it works as it does in Windows in order to make it easier for new users. Great job Fedora team! Keep it up and just polish these small quirks. Thanks! -- 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 emmanuel.seyman at club-internet.fr Tue May 8 20:45:17 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 8 May 2007 22:45:17 +0200 Subject: F7 Zope package In-Reply-To: <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> Message-ID: <20070508204517.GA1959@orient.maison.lan> * Debarshi 'Rishi' Ray [08/05/2007 22:39] : > > but keep giving excuses why such a big development > does not make it to the on-media release notes. People expecting perfection from the Release Notes writers should really wake up and smell the coffee. They do a brilliant job and receive little to no praise for it. If you feel you can do a better job, then go give them a hand. Emmanuel From sundaram at fedoraproject.org Tue May 8 20:49:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 02:19:09 +0530 Subject: F7 Zope package In-Reply-To: <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> Message-ID: <4640E245.8060509@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >>>>> However, the media release notes always say "the most recent copy >>>>> of the >>>>> release notes are on the wiki", which do get updated. >>>> This is only applicable for last minute decisions. > >>> Is this true? I've always been under the impression that anything >>> that the >>> rel-notes writers had missed pre-release could be included in the >>> updates. > >> That's correct. The process is not just for last minute decisions. The >> number of people who work on the release notes is very few and we do >> miss things that gets pointed out and added later. > > I am not talking about what the rule book says. I just clarified the description of the release notes process being actively involved in that effort. Regardless of what you were talking about it might help others to understand the process better and hopefully participate in it. I can not help > noticing how we are being really rigid while saying, "If Zope can not > migrate to a later release of Python in one year its their headache, > God help them.", but keep giving excuses why such a big development > does not make it to the on-media release notes. It didn't make it into the on media release notes because there are more people willing to talk in length about how bad it is but not willing to contribute. Rahul From jwboyer at jdub.homelinux.org Tue May 8 20:44:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:44:07 -0500 Subject: F7 Zope package In-Reply-To: <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> Message-ID: <1178657048.3175.43.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 01:47 +0530, Debarshi 'Rishi' Ray wrote: > >> It is kind of sad that in this thread it is critized that Zope > >> upstream is unable to port Zope to python 2.5 within 9 months but Fedora is > >> not able to mention this in the release notes on the media. > > > Not that I'm aware of. They're frozen for translations, and adding > > stuff after the fact makes it impossible to fully translate things. > > You do not get the point. What Till was trying to indicate is that > while we are criticising Zope for not migrating to Python 2.5 over the > last 9 months, Fedora has not been able to mention their dropping of > Zope in the release notes. The decision was made a month ago. I have no idea when the release notes freeze was. I do know, however, that it is very easy to add a note to the release notes on the wiki through the Beats page. Why this was not done, I have no clue. If the intention of including it in the release notes was to inform users of it's exclusion from Fedora 7, then yes that is indeed unfortunate. We can still direct them to the wiki pages though. josh From debarshi.ray at gmail.com Tue May 8 20:55:51 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 9 May 2007 02:25:51 +0530 Subject: F7 Zope package In-Reply-To: <20070508204517.GA1959@orient.maison.lan> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> Message-ID: <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> > People expecting perfection from the Release Notes writers should really > wake up and smell the coffee. They do a brilliant job and receive little > to no praise for it. > > If you feel you can do a better job, then go give them a hand. If FESCo had indeed taken this decision sufficiently beforehand, they could have given a reminder to the release notes writers regarding this. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Tue May 8 20:57:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 02:27:25 +0530 Subject: F7 Zope package In-Reply-To: <1178657048.3175.43.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <1178657048.3175.43.camel@vader.jdub.homelinux.org> Message-ID: <4640E435.7050008@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-05-09 at 01:47 +0530, Debarshi 'Rishi' Ray wrote: >>>> It is kind of sad that in this thread it is critized that Zope >>>> upstream is unable to port Zope to python 2.5 within 9 months but Fedora is >>>> not able to mention this in the release notes on the media. >>> Not that I'm aware of. They're frozen for translations, and adding >>> stuff after the fact makes it impossible to fully translate things. >> You do not get the point. What Till was trying to indicate is that >> while we are criticising Zope for not migrating to Python 2.5 over the >> last 9 months, Fedora has not been able to mention their dropping of >> Zope in the release notes. > > The decision was made a month ago. I have no idea when the release > notes freeze was. 20th April http://fedoraproject.org/wiki/DocsProject/Schedule Rahul From jwboyer at jdub.homelinux.org Tue May 8 20:52:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:52:40 -0500 Subject: F7 Zope package In-Reply-To: <1178649879.19523.17.camel@vorpal.macdev.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> <1178645188.2824.44.camel@pmac.infradead.org> <1178649879.19523.17.camel@vorpal.macdev.com> Message-ID: <1178657560.3175.53.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 13:44 -0500, David G. Mackay wrote: > On Tue, 2007-05-08 at 18:26 +0100, David Woodhouse wrote: > > > It's got very little to do with upstream. The problem is that there is > > no _Fedora_ maintainer with enough time and energy to make the package > > work as part of _Fedora_. > > I have asked several times what leads to the expectation that a package > that has been the primary package for FC6 and generated only 12 bugzilla > entries during that time would suddenly become a massive problem. I can > understand that care would need to be taken to prevent unintended > interactions between 2.4 and 2.5, but that's doable. More specifically, > we've discussed the option of putting it under the zope directory > hierarchy. Someone would have to actively dig to find it and use it out > of context if that were the case. Yes. Again, someone would have to do the work. Who's volunteering to start? josh From jwboyer at jdub.homelinux.org Tue May 8 20:54:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:54:17 -0500 Subject: F7 Zope package In-Reply-To: <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> Message-ID: <1178657658.3175.57.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 02:25 +0530, Debarshi 'Rishi' Ray wrote: > > People expecting perfection from the Release Notes writers should really > > wake up and smell the coffee. They do a brilliant job and receive little > > to no praise for it. > > > > If you feel you can do a better job, then go give them a hand. > > If FESCo had indeed taken this decision sufficiently beforehand, they > could have given a reminder to the release notes writers regarding > this. You don't get it. _Anyone_ can contribute to the release notes directly through the wiki. It should not be the burden of the release notes writers to have to update them for this. Nor should it have to rely on FESCo doing it. The zope maintainer could have done it as well. josh From jwboyer at jdub.homelinux.org Tue May 8 20:54:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:54:48 -0500 Subject: F7 Zope package In-Reply-To: <4640E435.7050008@fedoraproject.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <1178657048.3175.43.camel@vader.jdub.homelinux.org> <4640E435.7050008@fedoraproject.org> Message-ID: <1178657689.3175.59.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 02:27 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Wed, 2007-05-09 at 01:47 +0530, Debarshi 'Rishi' Ray wrote: > >>>> It is kind of sad that in this thread it is critized that Zope > >>>> upstream is unable to port Zope to python 2.5 within 9 months but Fedora is > >>>> not able to mention this in the release notes on the media. > >>> Not that I'm aware of. They're frozen for translations, and adding > >>> stuff after the fact makes it impossible to fully translate things. > >> You do not get the point. What Till was trying to indicate is that > >> while we are criticising Zope for not migrating to Python 2.5 over the > >> last 9 months, Fedora has not been able to mention their dropping of > >> Zope in the release notes. > > > > The decision was made a month ago. I have no idea when the release > > notes freeze was. > > 20th April > > http://fedoraproject.org/wiki/DocsProject/Schedule Time enough indeed. That is very unfortunate. josh From j.w.r.degoede at hhs.nl Tue May 8 21:18:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 23:18:55 +0200 Subject: F7 Zope package In-Reply-To: <1178657560.3175.53.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> <1178645188.2824.44.camel@pmac.infradead.org> <1178649879.19523.17.camel@vorpal.macdev.com> <1178657560.3175.53.camel@vader.jdub.homelinux.org> Message-ID: <4640E93F.8010706@hhs.nl> Josh Boyer wrote: > On Tue, 2007-05-08 at 13:44 -0500, David G. Mackay wrote: >> On Tue, 2007-05-08 at 18:26 +0100, David Woodhouse wrote: >> >>> It's got very little to do with upstream. The problem is that there is >>> no _Fedora_ maintainer with enough time and energy to make the package >>> work as part of _Fedora_. >> I have asked several times what leads to the expectation that a package >> that has been the primary package for FC6 and generated only 12 bugzilla >> entries during that time would suddenly become a massive problem. I can >> understand that care would need to be taken to prevent unintended >> interactions between 2.4 and 2.5, but that's doable. More specifically, >> we've discussed the option of putting it under the zope directory >> hierarchy. Someone would have to actively dig to find it and use it out >> of context if that were the case. > > Yes. Again, someone would have to do the work. Who's volunteering to > start? > The zope maintainer? AFAIK no one has asked him if he would be willing to try this, instead it he has been forbidden to even try. Bad leadership if you ask me. Regards, Hans From jwboyer at jdub.homelinux.org Tue May 8 20:58:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 15:58:07 -0500 Subject: F7 Zope package In-Reply-To: <3170f42f0705081330k50cdcdf9y1bb088fba6a9446b@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178628415.3175.2.camel@vader.jdub.homelinux.org> <3170f42f0705080612w7e2eb04fo281c7f0221d9c628@mail.gmail.com> <1178634141.5880.10.camel@lincoln> <4640D0C4.8060408@poolshark.org> <1178654753.3175.31.camel@vader.jdub.homelinux.org> <3170f42f0705081330k50cdcdf9y1bb088fba6a9446b@mail.gmail.com> Message-ID: <1178657887.3175.65.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 02:00 +0530, Debarshi 'Rishi' Ray wrote: > > Except it already went to FESCo. Trying to undo the decision by just > > submitting a package and hoping it passes review likely isn't the best > > way to go about things. > > Arguments like this will neither solve the problem, nor take this > decision any further. All that people (not some 'single user') are > asking is FESCo explain why they took this decision, not keep > repeating things like "it is too difficult and painful", "read the > release notes on the Wiki", etc.. Those are neither reasons nor > explanations. The decision making process, in it's entirety, is in the meeting minutes on the wiki. At that time, there did not seem to be a willing maintainer for it. > Given the fact that Python 2.4 has been around for so long and that it > had generated only 12 bug reports for FC6, I do not see how providing > a compat-python package is so big a problem. I do not see how a > /usr/bin/python2.4 will cause such a huge number of confusing bug > reports, since a newbie (who does not know about python & > compat-python) will simply use 'python' and not hunt for 'python24' in > the distribution in the first place. Then why don't you package up a compat-python24 and volunteer to maintain it? Email FESCo saying you'd like to be the maintainer of this package. Having an _active_ and _willing_ maintainer may influence FESCo to revisit the issue. There is absolutely nothing that says a decision is carved in stone for all eternity. If it's not important enough for anyone to step up and do the work, then further discussion is pointless. Now personally, all I've seen so far is a bunch of people who really like Zope and are really vocal about it but haven't actually done anything other than whine about a decision what was made a month ago. If Zope is so damn important, why hasn't someone created the needed package already and posted a link to it? The collective amount of time that has been wasted on this thread could have resulted in about 4 different solutions being implemented for FESCo to actually look at. josh From mackay_d at bellsouth.net Tue May 8 21:14:42 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 16:14:42 -0500 Subject: F7 Zope package In-Reply-To: <20070508201554.GA1609@orient.maison.lan> References: <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <1178559646.12774.43.camel@vorpal.macdev.com> <20070507185022.GA22316@orient.maison.lan> <1178568532.12774.115.camel@vorpal.macdev.com> <20070507203634.GA23167@orient.maison.lan> <1178572220.12774.146.camel@vorpal.macdev.com> <20070508201554.GA1609@orient.maison.lan> Message-ID: <1178658882.3791.1.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 22:15 +0200, Emmanuel Seyman wrote: > Xmms was removed from Fedora Core because it depended on gtk-1.x (which > was retired because it was a legacy library), not because of its legal > status (mp3 support had been removed by this point). Sorry, I missed that. It does happen to be one of the apps that I add from the repo, but I just didn't pay attention. Dave From jwboyer at jdub.homelinux.org Tue May 8 21:11:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 16:11:00 -0500 Subject: F7 Zope package In-Reply-To: <4640E93F.8010706@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> <1178645188.2824.44.camel@pmac.infradead.org> <1178649879.19523.17.camel@vorpal.macdev.com> <1178657560.3175.53.camel@vader.jdub.homelinux.org> <4640E93F.8010706@hhs.nl> Message-ID: <1178658661.3175.75.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 23:18 +0200, Hans de Goede wrote: > Josh Boyer wrote: > > On Tue, 2007-05-08 at 13:44 -0500, David G. Mackay wrote: > >> On Tue, 2007-05-08 at 18:26 +0100, David Woodhouse wrote: > >> > >>> It's got very little to do with upstream. The problem is that there is > >>> no _Fedora_ maintainer with enough time and energy to make the package > >>> work as part of _Fedora_. > >> I have asked several times what leads to the expectation that a package > >> that has been the primary package for FC6 and generated only 12 bugzilla > >> entries during that time would suddenly become a massive problem. I can > >> understand that care would need to be taken to prevent unintended > >> interactions between 2.4 and 2.5, but that's doable. More specifically, > >> we've discussed the option of putting it under the zope directory > >> hierarchy. Someone would have to actively dig to find it and use it out > >> of context if that were the case. > > > > Yes. Again, someone would have to do the work. Who's volunteering to > > start? > > > > The zope maintainer? AFAIK no one has asked him if he would be willing to try > this, instead it he has been forbidden to even try. Bad leadership if you ask me. Jonathan has been sent an email asking what his ideal outcome is and has been requested to forward that to FESCo. We've now officially asked. If he wants to attempt something, that would be great. Otherwise someone else will have to step up. josh From mackay_d at bellsouth.net Tue May 8 21:21:49 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Tue, 08 May 2007 16:21:49 -0500 Subject: F7 Zope package In-Reply-To: <1178657560.3175.53.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705051132.21629.opensource@till.name> <200705050608.51673.jkeating@redhat.com> <200705051600.59640.opensource@till.name> <7874d9dd0705050801m41c939c8jf56ec4bf3b333269@mail.gmail.com> <463CB6F0.6000302@poolshark.org> <463CC2A3.9090600@leemhuis.info> <1178550045.2558.5.camel@aglarond.local> <20070508095202.GA11993@devserv.devel.redhat.com> <464057EE.1000201@hhs.nl> <1178626366.3862.3.camel@rivendell> <46406EE4.8050503@hhs.nl> <1178626617.25550.27.camel@vader.jdub.homelinux.org> <464072C9.1040301@hhs.nl> <1178630295.342.22.camel@rousalka.dyndns.org> <1178640816.18982.11.camel@vorpal.macdev.com> <1178645188.2824.44.camel@pmac.infradead.org> <1178649879.19523.17.camel@vorpal.macdev.com> <1178657560.3175.53.camel@vader.jdub.homelinux.org> Message-ID: <1178659309.3791.4.camel@vorpal.macdev.com> On Tue, 2007-05-08 at 15:52 -0500, Josh Boyer wrote: > > I have asked several times what leads to the expectation that a package > > that has been the primary package for FC6 and generated only 12 bugzilla > > entries during that time would suddenly become a massive problem. I can > > understand that care would need to be taken to prevent unintended > > interactions between 2.4 and 2.5, but that's doable. More specifically, > > we've discussed the option of putting it under the zope directory > > hierarchy. Someone would have to actively dig to find it and use it out > > of context if that were the case. > > Yes. Again, someone would have to do the work. Who's volunteering to > start? Jonathan Steffan has already sent several messages stating that he already had. Which still leaves my question unanswered. Dave From orion at cora.nwra.com Tue May 8 22:08:22 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 08 May 2007 16:08:22 -0600 Subject: Reliable rpm database corruption with rawhide Message-ID: <4640F4D6.1080809@cora.nwra.com> I'm pretty reliably getting rpm database corruption when installing new packages on a freshly installed system: Running Transaction Installing: python-krbV ######################### [1/8] Installing: redhat-rpm-config ######################### [2/8] Installing: pyOpenSSL ######################### [3/8] Installing: elfutils-libs ######################### [4/8] Installing: elfutils ######################### [5/8] Installing: rpm-build ######################### [6/8] Installing: rpmdevtools ######################### [7/8] rpmdb: page 50: illegal page type or format rpmdb: PANIC: Invalid argument error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery error: error(-30977) getting "/usr/bin/python" records from Requirename index rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery error: error(-30977) getting "bzip2" records from Requirename index rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery ..... This has happened for at least three installs over the last couple of months. As anyone else seen this? I'm off to run some memory tests, but I haven't seen any other messages in the logs and my disk looks pretty good. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From davehoz at gmail.com Tue May 8 22:13:13 2007 From: davehoz at gmail.com (David Hunter) Date: Wed, 9 May 2007 08:13:13 +1000 Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. In-Reply-To: <4640A2AC.9070705@poolshark.org> References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> <4640A2AC.9070705@poolshark.org> Message-ID: <6bb886180705081513g19eace80h8f46f67dd8efcbd3@mail.gmail.com> mozilla-vlc-0.8.6b-0.2.lvn7 On 09/05/07, Denis Leroy wrote: > > David Hunter wrote: > > firefox -g > terface) created > > at priority 0 (interface/interface.c:231) > > /usr/lib/firefox-2.0.0.3/firefox-bin : > > symbol lookup error: /usr/lib/mozilla/plugins/libvlcplugin.so: undefined > > symbol: XtWindowToWidget > > > > What to do now? Looks like its trying to use quicktime. :( > > Looks like a vlc plugin bug, or a vlc packaging bug. What does this > say: ? > > rpm -qf /usr/lib/mozilla/plugins/libvlcplugin.so > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From bojan at rexursive.com Tue May 8 22:16:02 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 8 May 2007 22:16:02 +0000 (UTC) Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> Message-ID: David Hunter gmail.com> writes: > What to do now? Looks like its trying to use quicktime. :( Maybe a VLC plugin bug: http://forum.videolan.org/viewtopic.php?p=107934&sid=ee6406e52e10b0ee93c02e4a75e88135 -- Bojan From bojan at rexursive.com Tue May 8 22:21:31 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 8 May 2007 22:21:31 +0000 (UTC) Subject: Epiphany and Firefox crash on a certain website. Warning - link may offend some readers. References: <6bb886180705072149jcb24fc9u6c4817be8eab129a@mail.gmail.com> <6bb886180705080405g4b39d536j3e12e14bdfd29fc1@mail.gmail.com> <4640A2AC.9070705@poolshark.org> <6bb886180705081513g19eace80h8f46f67dd8efcbd3@mail.gmail.com> Message-ID: David Hunter gmail.com> writes: > mozilla-vlc-0.8.6b-0.2.lvn7 You should report it to Livna. -- Bojan From wolfy at nobugconsulting.ro Tue May 8 23:09:58 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 09 May 2007 02:09:58 +0300 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> Message-ID: <46410346.3060302@nobugconsulting.ro> On 05/08/2007 10:06 PM, Valent Turkovic wrote: > Full update gave me even better results!!! 75% savings !!! > > > Size of all updates downloaded from Presto-enabled repositories: 10M > Size of updates that would have been downloaded if Presto wasn't > enabled: 41M > This is a savings of 75 percent No one said that it would not be great to have this tool. Unfortunately it a) is still in beta stage and more important b)it arrived too late to be included in the release. Even the tools to generated the deltarpm enabled repos have just been released. It will be included in rawhide and after proper testing might be pushed as an update to FC6/FC7 too. Or at least that's the picture I got. From bojan at rexursive.com Wed May 9 00:17:18 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 9 May 2007 00:17:18 +0000 (UTC) Subject: FC6: Request for sqlite3 version update References: <1178633553.3221.35.camel@rt.jesacco.com> Message-ID: Joseph Sacco gnome.org> writes: > > The version of sqlite3 currently available for FC6 is 3.3.6, which was > released my sqlite.org on 6June2006: > > http://www.sqlite.org/changes.html > > The current version of sqlite3, 3.3.17, was released in April of 2007. You should open a bug in Bugzilla for this. If you also supply a patch to the spec file, it may get done faster :-) -- Bojan From sundaram at fedoraproject.org Wed May 9 00:31:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 06:01:37 +0530 Subject: yumdownloader do nothing In-Reply-To: <463FDE52.1070901@gmail.com> References: <463FDE52.1070901@gmail.com> Message-ID: <46411669.6000905@fedoraproject.org> Ken YANG wrote: > > hi all: > > i am in FC7 Rawhide, and the yum-utils is: > > yum-utils-1.1.3-1.fc7 > > when i use: > > yumdownloader --enablerepo development-source --source selinux-policy > > the output is: > > Loading "installonlyn" plugin > Loading "skip-broken" plugin > development-source 100% |=========================| 951 B 00:00 > primary.xml.gz 100% |=========================| 304 kB 00:03 > developmen: ################################################## 1150/1150 > Excluding Packages in global exclude list > Finished > > there is nothing download, i also try: > > yumdownloader --enablerepo development-source --source > selinux-policy-2.6.1-1.fc7.src.rpm > > but obviously, the argument is wrong. > > so why yumdownloader can not download correspoding SRPM? Seems like a bug. File a report in http://bugzilla.redhat.com Rahul From jwboyer at jdub.homelinux.org Wed May 9 00:58:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 19:58:22 -0500 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <46410346.3060302@nobugconsulting.ro> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> <46410346.3060302@nobugconsulting.ro> Message-ID: <1178672302.3175.86.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 02:09 +0300, Manuel Wolfshant wrote: > It will be included in rawhide and after proper testing might be > pushed as an update to FC6/FC7 too. Or at least that's the picture I got. The packages for yum-presto and deltarpm certainly can be. Whether the official Fedora repositories have deltarpms enabled is a different matter. It would be good to do this for rawhide, however that is something we'll have to evaluate post-F7. Just too much stuff to look at for the time being. josh From jwboyer at jdub.homelinux.org Wed May 9 01:27:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 20:27:14 -0500 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change Message-ID: <1178673883.3175.109.camel@vader.jdub.homelinux.org> The bulk of the Core/Extras merge has now been finished, and the Release Engineering team has been working hard to get things back in shape for the final F7 release. However, due to the massive nature of this undertaking, we are not coming back online as fast as we had hoped. We do not have a rawhide repository available as of yet, and the release and QA teams are not comfortable going into deep freeze at this point. During the Release team meeting yesterday, it was decided to slip the deep freeze date by a week at least. This will also slip the final release of Fedora 7 by at least a week. Slipping a week will allow more time for the merge tree to materialize and stabilize. Maintainers will also have more time to adjust to the new processes involved as a result of the merge. We will also have more time to evaluate the blocking bugs that are currently open in Bugzilla. While this slip is unfortunate, it is also in the best interest for the quality of the release. Please bear with us as we strive to make this the best release of Fedora to date! josh From wwoods at redhat.com Wed May 9 01:59:36 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 8 May 2007 21:59:36 -0400 Subject: yumdownloader do nothing In-Reply-To: <463FDE52.1070901@gmail.com> References: <463FDE52.1070901@gmail.com> Message-ID: <73066563-A318-4C22-A2D7-D3A46068D2FF@redhat.com> On May 7, 2007, at 10:20 PM, Ken YANG wrote: > > hi all: > > i am in FC7 Rawhide, and the yum-utils is: > > yum-utils-1.1.3-1.fc7 > > when i use: > > yumdownloader --enablerepo development-source --source selinux-policy > > the output is: > > Loading "installonlyn" plugin > Loading "skip-broken" plugin > development-source 100% |=========================| 951 B > 00:00 > primary.xml.gz 100% |=========================| 304 kB > 00:03 > developmen: ################################################## > 1150/1150 > Excluding Packages in global exclude list > Finished > > there is nothing download, i also try: > > yumdownloader --enablerepo development-source --source selinux- > policy-2.6.1-1.fc7.src.rpm > > but obviously, the argument is wrong. > > so why yumdownloader can not download correspoding SRPM? I think --enablerepo was fixed in yum recently, but --source still doesn't work yet. There've been a lot of changes in yum recently. Please do file a bug about this: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora% 20Extras&version=devel&component=yum-utils Or, for a nice short (unbroken) URL: http://rdr.to/YJ Thanks! -w From wwoods at redhat.com Wed May 9 02:12:58 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 8 May 2007 22:12:58 -0400 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178672302.3175.86.camel@vader.jdub.homelinux.org> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> <46410346.3060302@nobugconsulting.ro> <1178672302.3175.86.camel@vader.jdub.homelinux.org> Message-ID: <6C913713-D171-4ED9-AD42-66777815E34E@redhat.com> On May 8, 2007, at 8:58 PM, Josh Boyer wrote: > On Wed, 2007-05-09 at 02:09 +0300, Manuel Wolfshant wrote: >> It will be included in rawhide and after proper testing might be >> pushed as an update to FC6/FC7 too. Or at least that's the picture >> I got. > > The packages for yum-presto and deltarpm certainly can be. Whether > the > official Fedora repositories have deltarpms enabled is a different > matter. > > It would be good to do this for rawhide, however that is something > we'll > have to evaluate post-F7. Just too much stuff to look at for the time > being. Don't forget - F8 is only 6 or 7 months away. If enough people put time and effort into developing, maintaining, and testing Presto, there's no reason[1] it can't be installed by default for F8.. -w [1] well, assuming the mirror maintainers are OK with carrying it.. From tromey at redhat.com Wed May 9 02:29:20 2007 From: tromey at redhat.com (Tom Tromey) Date: Tue, 8 May 2007 19:29:20 -0700 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <1178656650.9601.73.camel@localhost.localdomain> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> Message-ID: <17985.12800.58208.812026@localhost.localdomain> >>>>> "Andrew" == Andrew Overholt writes: Andrew> I speak with no authority but I'm sure we'll have OpenJDK in Andrew> Fedora 8 if not some time in the Fedora 7 cycle. There are Andrew> still the encumbered bits to work out in the short term. In Andrew> the longer term, we need to think about platform coverage. Andrew> I'm confident, though, that we'll have an openjdk alternative Andrew> (as in alternatives) soon. Which Fedora release this ships in depends on how quickly the encumbrances can be lifted. Also my current understanding is that the standard names ("Java", "OpenJDK") can't be used unless the TCK is passed, and I don't know when this will all be set up. "Ice tea" has been proposed as an interim name :-) Platform coverage is also important but perhaps a bit less so; though I suppose setting the standard here is up to the Fedora governing board. The problem is that there is no PPC port and the best guess today is that there won't be one before F8. Anyway, yes, assuming various minor remaining hurdles can be jumped, OpenJDK is the future. We have always said that it is better to have a single good implementation. Tom From sundaram at fedoraproject.org Wed May 9 02:52:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 08:22:18 +0530 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <17985.12800.58208.812026@localhost.localdomain> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> Message-ID: <46413762.6040108@fedoraproject.org> Tom Tromey wrote: > Platform coverage is also important but perhaps a bit less so; though > I suppose setting the standard here is up to the Fedora governing > board. The problem is that there is no PPC port and the best guess > today is that there won't be one before F8. Assuming you can get the encumbrances removed and get a 100% Free software solution soon then including OpenJDK in x86 and x86_64 which covers about 80% of our users[1] while putting in GCJ for PPC in Fedora 8 and continuing to push for a PPC port would be a good approach. Rahul [1] http://smolt.fedoraproject.org/stats From lightsolphoenix at gmail.com Wed May 9 02:57:45 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Tue, 8 May 2007 22:57:45 -0400 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <46413762.6040108@fedoraproject.org> References: <4640E098.6@hhs.nl> <17985.12800.58208.812026@localhost.localdomain> <46413762.6040108@fedoraproject.org> Message-ID: <200705082257.45998.lightsolphoenix@gmail.com> Actually, I'm kinda interested; what is the difference between i386, i586 and i686? On Tuesday, May 08, 2007 10:52 pm Rahul Sundaram wrote: > Tom Tromey wrote: > > Platform coverage is also important but perhaps a bit less so; though > > I suppose setting the standard here is up to the Fedora governing > > board. The problem is that there is no PPC port and the best guess > > today is that there won't be one before F8. > > Assuming you can get the encumbrances removed and get a 100% Free > software solution soon then including OpenJDK in x86 and x86_64 which > covers about 80% of our users[1] while putting in GCJ for PPC in Fedora > 8 and continuing to push for a PPC port would be a good approach. > > Rahul > > [1] http://smolt.fedoraproject.org/stats -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dimi at lattica.com Wed May 9 03:22:31 2007 From: dimi at lattica.com (Dimi Paun) Date: Tue, 08 May 2007 23:22:31 -0400 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <46413762.6040108@fedoraproject.org> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> <46413762.6040108@fedoraproject.org> Message-ID: <1178680951.7901.33.camel@dimi.lattica.com> On Wed, 2007-05-09 at 08:22 +0530, Rahul Sundaram wrote: > including OpenJDK in x86 and x86_64 which > covers about 80% of our users[1] Well, according to that link it's more like 98%. PPC is less than 1.5%, hardly a reason to hold back on deploying OpenJDK in F8... -- Dimi Paun Lattica, Inc. From dennis at ausil.us Wed May 9 04:01:21 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 8 May 2007 23:01:21 -0500 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <200705082301.27510.dennis@ausil.us> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? ive never had the iwlwifi driver work for me and the newest version is no different. the first versions of the drivers would associate but quickly drop off. the last half dozen or so kernels ive tested fail to associate at all. in fact they don't even see any networks. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed May 9 05:05:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 May 2007 07:05:26 +0200 Subject: F7 Zope package In-Reply-To: <1178657658.3175.57.camel@vader.jdub.homelinux.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> Message-ID: <46415696.6050804@leemhuis.info> On 08.05.2007 22:54, Josh Boyer wrote: > On Wed, 2007-05-09 at 02:25 +0530, Debarshi 'Rishi' Ray wrote: >>> People expecting perfection from the Release Notes writers should really >>> wake up and smell the coffee. They do a brilliant job and receive little >>> to no praise for it. >>> If you feel you can do a better job, then go give them a hand. >> If FESCo had indeed taken this decision sufficiently beforehand, they >> could have given a reminder to the release notes writers regarding >> this. > You don't get it. _Anyone_ can contribute to the release notes directly > through the wiki. It should not be the burden of the release notes > writers to have to update them for this. Nor should it have to rely on > FESCo doing it. The zope maintainer could have done it as well. Sorry, but if FESCo decides to kick a package from the repo against the will of the packager then it's IMHO FESCos responsibility to make sure that fact gets documented properly. CU thl From jdieter at gmail.com Wed May 9 05:21:24 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 09 May 2007 08:21:24 +0300 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178672302.3175.86.camel@vader.jdub.homelinux.org> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <64b14b300705081149m235c5d4dv735c75cc7bedba6d@mail.gmail.com> <64b14b300705081153r21322836q851797a031edf4ff@mail.gmail.com> <64b14b300705081206p51b0728m5d5cfda2dd8725cf@mail.gmail.com> <46410346.3060302@nobugconsulting.ro> <1178672302.3175.86.camel@vader.jdub.homelinux.org> Message-ID: <1178688084.9345.144.camel@jndwidescreen.lesbg.loc> On Tue, 2007-05-08 at 19:58 -0500, Josh Boyer wrote: > On Wed, 2007-05-09 at 02:09 +0300, Manuel Wolfshant wrote: > > It will be included in rawhide and after proper testing might be > > pushed as an update to FC6/FC7 too. Or at least that's the picture I got. > > The packages for yum-presto and deltarpm certainly can be. Whether the > official Fedora repositories have deltarpms enabled is a different > matter. > > It would be good to do this for rawhide, however that is something we'll > have to evaluate post-F7. Just too much stuff to look at for the time > being. > > josh > +1 Just want to note that both yum-presto and deltarpm are already in extras for FC6 and in F7, though I don't think yum-presto will be in any spins. Jonathan -------------- 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 Wed May 9 05:27:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 May 2007 01:27:47 -0400 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <17985.12800.58208.812026@localhost.localdomain> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> Message-ID: <20070509052747.GA28866@nostromo.devel.redhat.com> Tom Tromey (tromey at redhat.com) said: > Which Fedora release this ships in depends on how quickly the > encumbrances can be lifted. Is it a matter of lifting the encumberances, or just re-implementing said parts (and what are those parts?) Bill From abartlet at samba.org Wed May 9 05:46:18 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 09 May 2007 15:46:18 +1000 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <200705082301.27510.dennis@ausil.us> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> Message-ID: <1178689578.13537.25.camel@localhost.localdomain> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: > Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > > If you are a rawhide user/tester and have ipw3945 hardware, please > > try the latest kernels here: > > > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > > > I am having mixed results with the latest iwl3945 updates, but I'm > > not sure if it is this particular laptop having problems or the driver > > in general. > > > > Please give the latest kernels a try and let me know how it is working > > for you. Please also let me know what was the last kernel that worked > > any better for ipw3945 hardware than the current ones. > > > > At this point, I am quite uneasy about this driver. It seems to work > > fine at times, then crash or simply refuse to associate at others. > > I am considering backing it out to the 0.0.16 tag or possibly even > > removing it (since the driver has _still_ not been posted upstream). > > Thoughts? > ive never had the iwlwifi driver work for me and the newest version is no > different. the first versions of the drivers would associate but quickly > drop off. the last half dozen or so kernels ive tested fail to associate at > all. in fact they don't even see any networks. For me, I see networks, and in all previous versions I would get 'tx buffer full', messages (after working for a very short moment), but now I get nothing other than NetworkManger telling me to 'get a better one' :-) 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 tcallawa at redhat.com Wed May 9 06:27:55 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 May 2007 01:27:55 -0500 Subject: Selinux and package guidelines In-Reply-To: <1178533462.11851.127.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> <1178445996.17680.139.camel@shinybook.infradead.org> <463E24B1.6040407@hhs.nl> <1178533462.11851.127.camel@pmac.infradead.org> Message-ID: <1178692075.3733.12.camel@localhost.localdomain> On Mon, 2007-05-07 at 11:24 +0100, David Woodhouse wrote: > So I'm confused -- what _is_ the point you're trying to make, and how > does it relate to "dragoran"'s suggestion that we add something about > SElinux to the review guidelines? I don't really want to be in this thread, but I do want to make it clear how you can suggest changes for the review guidelines: http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure This is the one and only way to get changes considered: Write a draft, and let us know it exists. Thanks, ~spot From spng.yang at gmail.com Wed May 9 06:58:18 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 09 May 2007 14:58:18 +0800 Subject: yumdownloader do nothing In-Reply-To: <73066563-A318-4C22-A2D7-D3A46068D2FF@redhat.com> References: <463FDE52.1070901@gmail.com> <73066563-A318-4C22-A2D7-D3A46068D2FF@redhat.com> Message-ID: <4641710A.4070507@gmail.com> Will Woods wrote: > > On May 7, 2007, at 10:20 PM, Ken YANG wrote: > >> >> hi all: >> >> i am in FC7 Rawhide, and the yum-utils is: >> >> yum-utils-1.1.3-1.fc7 >> >> when i use: >> >> yumdownloader --enablerepo development-source --source selinux-policy >> >> the output is: >> >> Loading "installonlyn" plugin >> Loading "skip-broken" plugin >> development-source 100% |=========================| 951 B 00:00 >> primary.xml.gz 100% |=========================| 304 kB 00:03 >> developmen: ################################################## 1150/1150 >> Excluding Packages in global exclude list >> Finished >> >> there is nothing download, i also try: >> >> yumdownloader --enablerepo development-source --source >> selinux-policy-2.6.1-1.fc7.src.rpm >> >> but obviously, the argument is wrong. >> >> so why yumdownloader can not download correspoding SRPM? > > I think --enablerepo was fixed in yum recently, but --source still > doesn't work yet. There've been a lot of changes in yum recently. Please > do file a bug about this: > > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&version=devel&component=yum-utils > > > Or, for a nice short (unbroken) URL: http://rdr.to/YJ ok, i have summit the bug: 239528 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239528 thank you > > Thanks! > > -w > From nicolas.mailhot at laposte.net Wed May 9 07:06:39 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 May 2007 09:06:39 +0200 (CEST) Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <20070509052747.GA28866@nostromo.devel.redhat.com> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> <20070509052747.GA28866@nostromo.devel.redhat.com> Message-ID: <14724.192.54.193.51.1178694399.squirrel@rousalka.dyndns.org> Le Mer 9 mai 2007 07:27, Bill Nottingham a ?crit : > Tom Tromey (tromey at redhat.com) said: >> Which Fedora release this ships in depends on how quickly the >> encumbrances can be lifted. > > Is it a matter of lifting the encumberances, or just re-implementing > said parts (and what are those parts?) One of the parts publicly pointed out was the font rendering, which is fine since java should have switched to fontconfig years ago (die font.properties die die die). Hope the old code is replaced soonish. -- Nicolas Mailhot From jdieter at gmail.com Wed May 9 07:41:53 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 09 May 2007 10:41:53 +0300 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <200704121437.58088.jkeating@redhat.com> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> Message-ID: <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> On Thu, 2007-04-12 at 14:37 -0400, Jesse Keating wrote: > > Finally, when we do get to the point of "do we put deltarpms in the > > master mirror", *if* we decide *not* to (for the many reasons mentioned > > by those against the idea), is it possible for yum-presto in Extras to > > point to the test server in the default .conf file? > > Typically we don't allow packages other than fedora-release to add repo files. > Maybe we could grant an exception for this package for a temporary time > being, but once a repo file is on, it is difficult to get it off, so wherever > you point you might want to be willing to at least maintain a redirect to > somewhere where content lives. I have a proposal that I would like to run by all interested parties. As has been covered elsewhere, FI isn't ready to start generating deltarpms for . At the moment yum-presto in Extras (for FC6 and F7) doesn't point to any Presto-enabled repositories. It does have some commented out deltaurls in presto.conf that, when uncommented, point to the test server at http://www.lesbg.com. The "right" way to set a deltaurl for a repository in yum-presto is to put it in the repository's .repo file. ATM, you can also put the deltaurl in presto.conf, though I keep on saying that that method will be removed soon. So, my proposal is this: I would like to be able to uncomment the deltaurls in presto.conf, even though they point to a non-Fedora Project url (yes, I know this is against policy). When (or if) FI starts generating deltarpms, I would then remove the ability to set deltaurls in presto.conf from the next version of yum-presto. All people who upgrade to the new version of yum-presto would no longer be pointed to the test server and would instead grab the deltarpms directly from the official repositories. I would maintain a redirect on the test server pointing to the official repositories for a long period of time after the transition has been made. I would appreciate any comments, flames, or large rocks aimed at my head. Jonathan -------------- 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 Wed May 9 09:01:12 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 10:01:12 +0100 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <20070509052747.GA28866@nostromo.devel.redhat.com> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> <20070509052747.GA28866@nostromo.devel.redhat.com> Message-ID: <17985.36312.705731.791166@zebedee.pink> Bill Nottingham writes: > Tom Tromey (tromey at redhat.com) said: > > Which Fedora release this ships in depends on how quickly the > > encumbrances can be lifted. > > Is it a matter of lifting the encumberances, or just re-implementing > said parts (and what are those parts?) I'm going to spend the next couple of days figuring that out. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From zboszor at freemail.hu Wed May 9 09:40:00 2007 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Wed, 09 May 2007 11:40:00 +0200 Subject: Merge update In-Reply-To: <200705041900.19801.jkeating@redhat.com> References: <1178328077.2227.2.camel@scrappy.miketc.com> <200705041900.19801.jkeating@redhat.com> Message-ID: <464196F0.7090906@freemail.hu> Hi, Jesse Keating ?rta: > On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > >> How's the merge seem to be going and/or working out? Can we expect the >> finale to happen in the next couple hours or in the wee morning hours? >> >> Or dare I ask, do we have a problem or anything? Hope all is going >> well. >> >> Jesse you hangin in there and remembering to eat? haha >> > > Most is going well. We're scrambling to create ppc64 builds of all the Extras > packages, as those didn't exist before, but now they will be built for ppc64. > Also we need to hook up some software to make rawhide appear. It may just be > in package repo form (not installable) to begin with, we'll see. I wouldn't > expect anything this weekend. > May I expect that the merge causes Glade to finally have GnomeDB widgets enabled? Best regards, Zolt?n B?sz?rm?nyi From abartlet at samba.org Wed May 9 10:13:07 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 09 May 2007 20:13:07 +1000 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> <20070508162949.GA24490@redhat.com> <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> Message-ID: <1178705587.13537.31.camel@localhost.localdomain> On Tue, 2007-05-08 at 17:48 +0100, Richard Hughes wrote: > On 08/05/07, John W. Linville wrote: > > On Tue, May 08, 2007 at 05:12:47PM +0100, Richard Hughes wrote: > > > On Tue, 2007-05-08 at 16:57 +0100, Richard Hughes wrote: > > > > DaveJ's kernels seem to perform well for me as well. > > > > > > Nope, scrub that, I'm getting about a bazillion: > > > > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > psmouse.c: issuing reconnect request > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. > > > psmouse.c: Failed to reset mouse on isa0060/serio1 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4 > > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > > > > > and my mouse pointer keeps jumping around every few minutes - most > > > irritating. I didn't get this with iwlwifi from git and a linus kernel. > > > > Well, that seems like a problem -- but I don't see a connection > > to iwl3945. > > It stops (and returns to normal) when I rmmod the driver... Doing things around this driver (in older versions) had the keyboard playing up for me. I wondered if it was playing games with interrupts? Likewise odd suspend/resume issues that similarly looked like a system without some interrupts. 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 jwboyer at jdub.homelinux.org Wed May 9 10:36:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 05:36:23 -0500 Subject: Merge update In-Reply-To: <464196F0.7090906@freemail.hu> References: <1178328077.2227.2.camel@scrappy.miketc.com> <200705041900.19801.jkeating@redhat.com> <464196F0.7090906@freemail.hu> Message-ID: <1178706983.3175.115.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 11:40 +0200, Zoltan Boszormenyi wrote: > Hi, > > Jesse Keating ?rta: > > On Friday 04 May 2007 18:21:17 Mike Chambers wrote: > > > >> How's the merge seem to be going and/or working out? Can we expect the > >> finale to happen in the next couple hours or in the wee morning hours? > >> > >> Or dare I ask, do we have a problem or anything? Hope all is going > >> well. > >> > >> Jesse you hangin in there and remembering to eat? haha > >> > > > > Most is going well. We're scrambling to create ppc64 builds of all the Extras > > packages, as those didn't exist before, but now they will be built for ppc64. > > Also we need to hook up some software to make rawhide appear. It may just be > > in package repo form (not installable) to begin with, we'll see. I wouldn't > > expect anything this weekend. > > > > May I expect that the merge causes Glade to finally have GnomeDB widgets > enabled? You'll need to start with asking the Glade maintainer. josh From hughsient at gmail.com Wed May 9 12:30:29 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 09 May 2007 13:30:29 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178705587.13537.31.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> <20070508162949.GA24490@redhat.com> <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> <1178705587.13537.31.camel@localhost.localdomain> Message-ID: <1178713829.32477.5.camel@hughsie-laptop> On Wed, 2007-05-09 at 20:13 +1000, Andrew Bartlett wrote: > > Doing things around this driver (in older versions) had the keyboard > playing up for me. I wondered if it was playing games with > interrupts? Yes, I believe that's the case, although a self-compiled git version of iwlwifi on a custom kernel doesn't do this, which is odd. As an aside when the redhat kernel is loaded and the iwl3945 driver is loaded then I'm also unable to shutdown, the kernel just prints out "shutting down" and never actually does anything, although a warning about interrupts on the touchpad appears just before the shutdown warning. Sorry about the overly vague symptoms, after my exams in a few days I can debug this properly. Richard. From dcbw at redhat.com Wed May 9 11:40:51 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 09 May 2007 07:40:51 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178689578.13537.25.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> Message-ID: <1178710852.17189.0.camel@localhost.localdomain> On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: > On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: > > Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > > > If you are a rawhide user/tester and have ipw3945 hardware, please > > > try the latest kernels here: > > > > > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > > > > > I am having mixed results with the latest iwl3945 updates, but I'm > > > not sure if it is this particular laptop having problems or the driver > > > in general. > > > > > > Please give the latest kernels a try and let me know how it is working > > > for you. Please also let me know what was the last kernel that worked > > > any better for ipw3945 hardware than the current ones. > > > > > > At this point, I am quite uneasy about this driver. It seems to work > > > fine at times, then crash or simply refuse to associate at others. > > > I am considering backing it out to the 0.0.16 tag or possibly even > > > removing it (since the driver has _still_ not been posted upstream). > > > Thoughts? > > ive never had the iwlwifi driver work for me and the newest version is no > > different. the first versions of the drivers would associate but quickly > > drop off. the last half dozen or so kernels ive tested fail to associate at > > all. in fact they don't even see any networks. > > For me, I see networks, and in all previous versions I would get 'tx > buffer full', messages (after working for a very short moment), but now > I get nothing other than NetworkManger telling me to 'get a better > one' :-) Hmm, can you run 'lshal' and find the bit for the wireless device? There may be both wmaster0 and wifi0. Dan From rc040203 at freenet.de Wed May 9 11:44:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 May 2007 13:44:15 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178710852.17189.0.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> Message-ID: <1178711055.3504.213.camel@mccallum.corsepiu.local> On Wed, 2007-05-09 at 07:40 -0400, Dan Williams wrote: > Hmm, can you run 'lshal' and find the bit for the wireless device? While we're at it (I've never heart about lshal before :): # lshal ... process 25754: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application. Ralf From dwmw2 at infradead.org Wed May 9 12:12:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 13:12:23 +0100 Subject: Packaging quality, assistance. In-Reply-To: <46415696.6050804@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> Message-ID: <1178712743.2824.152.camel@pmac.infradead.org> On Wed, 2007-05-09 at 07:05 +0200, Thorsten Leemhuis wrote: > Sorry, but if FESCo decides to kick a package from the repo against the > will of the packager then it's IMHO FESCos responsibility to make sure > that fact gets documented properly. I hate to bring it up again, because I'm sure it'll make someone cry... but I feel sure that if Zope had been an actively maintained Core package, we wouldn't be having this discussion. It's been almost a year since python 2.5b1 was first committed to CVS, and the maintainer _would_ have made it work with python 2.5 in that time. I am increasingly concerned by the discrepancy between 'Core' and 'Extras' in such matters -- and now that they're merged, we don't seem to have the convenient distinction which has always before told me 'this package should be taken with a pinch of salt'. I filed bugs only a few days ago for another Extras package which just dumps its files on the filesystem and doesn't bother to set up its own d?mon with an xinet.d file, set up its web interface with files in /etc/httpd/conf.d, etc. It's just a dump of the upstream package without proper _Fedora_ maintenance. We need some way to help out with this kind of thing. Obviously I do it for anything related to ppc (and now ppc64)?, and I'll poke at other things I care about or that people ask me to help with. If think we need much more of that?. Perhaps we just need a way to encourage and help packagers in need of assistance to get in touch with others who can help them? A kind of 'packaging SWAT team'? :) I'm not sure how it would work best -- perhaps an 'assistance required' tracker bug which the 'hard' bug can be made to block? Or just a mailing list where assistance can be solicited? We need to strike a balance between quality and quantity -- I appreciate it's nice if every man and his dog can submit any package for they can manage to cobble together a specfile, but what if they can't actually understand any of the code, can't deal with any of the bugs, and can't make it work as a coherent part of the Fedora distribution? As well as making it easier to find help, perhaps there's something to be said for expecting the sponsors to co-own packages and help keep track of bugs in the cases where the owner needs a little extra assistance? I've seen basic 32/64-bit compatibility bugs closed with a comment about not understanding the code and just waiting for upstream -- that _really_ needs to be avoided. -- dwmw2 ? Actually that's only necessarily true for bugs which end up on the FE-ExcludeArch-ppc{64,} tracker. If a package just has certain functionality disabled, it might not come to my attention unless the packager is conscientious enough to seek assistance. ? To make sure I don't accidentally make anyone cry, I should point out the blindingly obvious fact that I'm not the only one -- there are plenty of other people who _are_ very capable and willing to help with packages belonging to others, and who also help out when problems come to their attention. From dwmw2 at infradead.org Wed May 9 12:17:56 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 13:17:56 +0100 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <200705081219.44853.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463F0989.4030403@hhs.nl> <1178537254.11851.155.camel@pmac.infradead.org> <200705081219.44853.opensource@till.name> Message-ID: <1178713076.2824.158.camel@pmac.infradead.org> On Tue, 2007-05-08 at 12:19 +0200, Till Maas wrote: > And the people that do not get enough help. I once asked how to get something > to work because of denied execmod. I got a response that it needs > text_rel_shlib_t or something similiar, but there was no help how to do this > correctly in a spec. You're right; I think we need some better procedure for people to ask for help -- and we need to _encourage_ them to ask for help. For the specific case of SElinux problems, what I'd probably do myself would be file a bug against my package and then assign (or at least Cc) it to dwalsh. I wouldn't just ask on the fedora-devel mailing list -- is that what you did? I appreciate that my approach might not scale though, and he might not thank me if I advocate it as a general solution :) It would be very good to have a document addressing the things a package maintainer might need to know when packaging software. It might already exist. -- dwmw2 From opensource at till.name Wed May 9 12:32:57 2007 From: opensource at till.name (Till Maas) Date: Wed, 09 May 2007 14:32:57 +0200 Subject: Making Fedora a contributer friendly environment In-Reply-To: <1178713076.2824.158.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705081219.44853.opensource@till.name> <1178713076.2824.158.camel@pmac.infradead.org> Message-ID: <200705091433.05257.opensource@till.name> On Mi Mai 9 2007, David Woodhouse wrote: > For the specific case of SElinux problems, what I'd probably do myself > would be file a bug against my package and then assign (or at least Cc) > it to dwalsh. I wouldn't just ask on the fedora-devel mailing list -- is > that what you did? I asked on the selinux list. The problem with filing first a bug is, that this cannot be done before a package is included in Fedora. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed May 9 12:34:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 May 2007 14:34:14 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178712743.2824.152.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> Message-ID: <4641BFC6.7080105@leemhuis.info> On 09.05.2007 14:12, David Woodhouse wrote: > On Wed, 2007-05-09 at 07:05 +0200, Thorsten Leemhuis wrote: > > I hate to bring it up again, because I'm sure it'll make someone cry... :-) > [...] > Perhaps we just need a way to encourage and help packagers in need of > assistance to get in touch with others who can help them? A kind of > 'packaging SWAT team'? :) That's what we *IMHO* have "Packaging SIGs" for - see http://fedoraproject.org/wiki/SIGs/ Quoting: ---- === General === Comps Games GNOME KDE Laptop Mono Music and Media Production Objective CAML (OCaml) Perl PHP Python QA Ruby Scientific and Technical Server Tools VoIP Embedded Systems Development === Arch specific === x86-64 (sometimes also named x64, AMD64, EM64T, x86_64, ia32e) PPC/PPC64 ---- But as you are not aware of it and not part of the ppc/ppc64 SIG ;-) it seems to me we need to document the working areas of those SIGs better and encourage packagers to ask those SIGs for help when they need them (if the SIGs do such work). > I'm not sure how it would work best -- perhaps an 'assistance required' > tracker bug which the 'hard' bug can be made to block? Or just a mailing > list where assistance can be solicited? Not ever more mailing lists please. We have to much of them IMHO already. > [...] CU thl From dwmw2 at infradead.org Wed May 9 12:34:27 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 13:34:27 +0100 Subject: Making Fedora a contributer friendly environment In-Reply-To: <200705091433.05257.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705081219.44853.opensource@till.name> <1178713076.2824.158.camel@pmac.infradead.org> <200705091433.05257.opensource@till.name> Message-ID: <1178714067.2824.166.camel@pmac.infradead.org> On Wed, 2007-05-09 at 14:32 +0200, Till Maas wrote: > I asked on the selinux list. The problem with filing first a bug is, that this > cannot be done before a package is included in Fedora. Well, there's a package review bug at that point, isn't there? -- dwmw2 From dwmw2 at infradead.org Wed May 9 12:45:32 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 13:45:32 +0100 Subject: Packaging quality, assistance. In-Reply-To: <4641BFC6.7080105@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> Message-ID: <1178714732.2824.173.camel@pmac.infradead.org> On Wed, 2007-05-09 at 14:34 +0200, Thorsten Leemhuis wrote: > But as you are not aware of it and not part of the ppc/ppc64 SIG ;-) There's a lot of stuff on the wiki I don't know about -- I wasn't aware of the PlayStation page either -- at least not until after Rawhide was running on it. I haven't yet formed an opinion on why that is -- either I'm just crap, or wikis aren't a very good method of communication for some tasks. Or both. > it seems to me we need to document the working areas of those SIGs > better and encourage packagers to ask those SIGs for help when they > need them (if the SIGs do such work). What mechanism would you suggest I use if I need help from one of those SIGs? Please tell me you don't want me to add something to a wiki page and wait for someone to notice? :) How about a tracker bug for each SIG? -- dwmw2 From jakub at redhat.com Wed May 9 12:46:02 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 9 May 2007 08:46:02 -0400 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <200705081219.44853.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463F0989.4030403@hhs.nl> <1178537254.11851.155.camel@pmac.infradead.org> <200705081219.44853.opensource@till.name> Message-ID: <20070509124602.GP355@devserv.devel.redhat.com> On Tue, May 08, 2007 at 12:19:43PM +0200, Till Maas wrote: > On Mo Mai 7 2007, David Woodhouse wrote: > > > So the only people who would be excluded would be those who are > > unwilling or unable to seek help from others when the task before them > > exceeds their abilities. Which would probably be a good thing. > > And the people that do not get enough help. I once asked how to get something > to work because of denied execmod. I got a response that it needs > text_rel_shlib_t or something similiar, but there was no help how to do this > correctly in a spec. http://fedoraproject.org/wiki/PackagingDrafts/SELinux > helped a little but was/is not up to date and also the work needed for > something this simple is way to much imho. One needs to create at least 2 not > empty files and have a bunch of scriptlets and some other selinux code. This > whole complexity only leads to more packaging errors. What should be there is > help, procedures and helpful tools for a maintainer to be able to easily > package software. DT_TEXTREL shared libraries are (almost always) a packaging bug which should be fixed, not worked around by setting SELinux contexts. In most cases that just means compiling all the objects that are linked into the shared library with -fpic resp. -fPIC (for very large shared libraries). Jakub From opensource at till.name Wed May 9 12:53:16 2007 From: opensource at till.name (Till Maas) Date: Wed, 09 May 2007 14:53:16 +0200 Subject: Making Fedora a contributer friendly environment In-Reply-To: <1178714067.2824.166.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091433.05257.opensource@till.name> <1178714067.2824.166.camel@pmac.infradead.org> Message-ID: <200705091453.38009.opensource@till.name> On Mi Mai 9 2007, David Woodhouse wrote: > Well, there's a package review bug at that point, isn't there? Ok, one could use this, but in my case the selinux stuff was only one issue of a long list, so the package was not ready for review at this point. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Wed May 9 12:56:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 14:56:32 +0200 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <20070509124602.GP355@devserv.devel.redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463F0989.4030403@hhs.nl> <1178537254.11851.155.camel@pmac.infradead.org> <200705081219.44853.opensource@till.name> <20070509124602.GP355@devserv.devel.redhat.com> Message-ID: <4641C500.9030704@hhs.nl> Jakub Jelinek wrote: > > DT_TEXTREL shared libraries are (almost always) a packaging bug which > should be fixed, not worked around by setting SELinux contexts. > In most cases that just means compiling all the objects that are linked > into the shared library with -fpic resp. -fPIC (for very large shared > libraries). > Sorry for going offtopic, but I've always wondered what the difference was between -fpic resp. -fPIC, any good docs on this? Regards, Hans From cra at WPI.EDU Wed May 9 13:13:03 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 9 May 2007 09:13:03 -0400 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> Message-ID: <20070509131303.GE9763@angus.ind.WPI.EDU> On Wed, May 09, 2007 at 10:41:53AM +0300, Jonathan Dieter wrote: > So, my proposal is this: I would like to be able to uncomment the > deltaurls in presto.conf, even though they point to a non-Fedora Project > url (yes, I know this is against policy). I think it is a bad idea to continue supporting deltaurls in presto.conf, even now. It is also a bad idea to have any default configuration point to non-Fedora repos. The documentation should instruct the users to add the deltaurls to the main *.repo files themselves. This avoids the situation where non-Fedora URLs are being added automatically--the user has to do it themselves. > When (or if) FI starts generating deltarpms, I would then remove > the ability to set deltaurls in presto.conf from the next version of > yum-presto. Deltaurls-in-presto.conf support should be removed ASAP. > All people who upgrade to the new version of yum-presto would no longer > be pointed to the test server and would instead grab the deltarpms > directly from the official repositories. I would maintain a redirect on > the test server pointing to the official repositories for a long period > of time after the transition has been made. A redirect would still be fine if you would like to do that. From fedora at leemhuis.info Wed May 9 13:25:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 May 2007 15:25:12 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178714732.2824.173.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> Message-ID: <4641CBB8.1010501@leemhuis.info> On 09.05.2007 14:45, David Woodhouse wrote: > On Wed, 2007-05-09 at 14:34 +0200, Thorsten Leemhuis wrote: >> But as you are not aware of it and not part of the ppc/ppc64 SIG ;-) > There's a lot of stuff on the wiki I don't know about -- I wasn't aware > of the PlayStation page either -- at least not until after Rawhide was > running on it. I haven't yet formed an opinion on why that is -- either > I'm just crap, or wikis aren't a very good method of communication for > some tasks. Or both. Well, it works quite well, *if* you are subscribed to the pages of interest. But you don't get aware of new pages that way. That's why I actually took the hard way and simply subscribed to the whole wiki and route the mail to a specific folder on my IMAP server. I skim over that folder now and then, so it's just like yet another mailing list for me. And if I care about some pages more then about other I can simply use procmail and route the mail differently. >> it seems to me we need to document the working areas of those SIGs >> better and encourage packagers to ask those SIGs for help when they >> need them (if the SIGs do such work). > > What mechanism would you suggest I use if I need help from one of those > SIGs? Please tell me you don't want me to add something to a wiki page > and wait for someone to notice? :) > > How about a tracker bug for each SIG? Well, we never defined in more detail how Packaging SIGs should work. Maybe we should create a small set of guidelines that all SIGs follow, to get such questions answered once and for all and a common "look and feel". I think we should do that, but don't care enough to do it myself ATM. And we'll get the usual yelling "to much bureaucracy" or "that's should be the decision of the SIG itself" of course... ;-) CU thl From jwboyer at jdub.homelinux.org Wed May 9 13:20:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 08:20:27 -0500 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change In-Reply-To: <1178673883.3175.109.camel@vader.jdub.homelinux.org> References: <1178673883.3175.109.camel@vader.jdub.homelinux.org> Message-ID: <1178716827.3086.14.camel@zod.rchland.ibm.com> On Tue, 2007-05-08 at 20:24 -0500, Josh Boyer wrote: > The bulk of the Core/Extras merge has now been finished, and the Release > Engineering team has been working hard to get things back in shape for > the final F7 release. However, due to the massive nature of this > undertaking, we are not coming back online as fast as we had hoped. > > We do not have a rawhide repository available as of yet, and the release > and QA teams are not comfortable going into deep freeze at this point. > During the Release team meeting yesterday, it was decided to slip the > deep freeze date by a week at least. This will also slip the final > release of Fedora 7 by at least a week. > > Slipping a week will allow more time for the merge tree to materialize > and stabilize. Maintainers will also have more time to adjust to the > new processes involved as a result of the merge. We will also have more > time to evaluate the blocking bugs that are currently open in Bugzilla. > > While this slip is unfortunate, it is also in the best interest for the > quality of the release. Please bear with us as we strive to make this > the best release of Fedora to date! Also, given that release cycles for older Fedora releases are dependent upon the release dates of future releases, Fedora Core 5 will have it's EOL date extended the same amount of time as the Fedora 7 release slips. FYI. josh From jwilson at redhat.com Wed May 9 13:30:40 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 09 May 2007 09:30:40 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178710852.17189.0.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> Message-ID: <4641CD00.3060604@redhat.com> Dan Williams wrote: > On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: >> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: >>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: >>>> If you are a rawhide user/tester and have ipw3945 hardware, please >>>> try the latest kernels here: >>>> >>>> http://people.redhat.com/davej/kernels/Fedora/fc7/ >>>> >>>> I am having mixed results with the latest iwl3945 updates, but I'm >>>> not sure if it is this particular laptop having problems or the driver >>>> in general. [...] >>> ive never had the iwlwifi driver work for me and the newest version is no >>> different. the first versions of the drivers would associate but quickly >>> drop off. the last half dozen or so kernels ive tested fail to associate at >>> all. in fact they don't even see any networks. >> For me, I see networks, and in all previous versions I would get 'tx >> buffer full', messages (after working for a very short moment), but now >> I get nothing other than NetworkManger telling me to 'get a better >> one' :-) > > Hmm, can you run 'lshal' and find the bit for the wireless device? > There may be both wmaster0 and wifi0. There's this Toshiba laptop in front of me with an iwl3945-driven card that for some reason, NetworkManager never notices is there -- never gives any evidence in its menu that a wireless card exists. I've got a wmaster0 and a wlan0, but no wifi0, if its relevant. lshal output here: http://people.redhat.com/jwilson/misc/lshal-toshiba-tecra-a8-s8513.txt -- Jarod Wilson jwilson at redhat.com From jakub at redhat.com Wed May 9 13:40:10 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 9 May 2007 09:40:10 -0400 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <4641C500.9030704@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <463F0989.4030403@hhs.nl> <1178537254.11851.155.camel@pmac.infradead.org> <200705081219.44853.opensource@till.name> <20070509124602.GP355@devserv.devel.redhat.com> <4641C500.9030704@hhs.nl> Message-ID: <20070509134009.GQ355@devserv.devel.redhat.com> On Wed, May 09, 2007 at 02:56:32PM +0200, Hans de Goede wrote: > Jakub Jelinek wrote: > > > >DT_TEXTREL shared libraries are (almost always) a packaging bug which > >should be fixed, not worked around by setting SELinux contexts. > >In most cases that just means compiling all the objects that are linked > >into the shared library with -fpic resp. -fPIC (for very large shared > >libraries). > > > > Sorry for going offtopic, but I've always wondered what the difference was > between -fpic resp. -fPIC, any good docs on this? It differs from arch to arch. On some architectures it is identical (e.g. i386 or x86_64), elsewhere -fpic creates faster code that is usable only in smaller shared libraries while -fPIC creates somewhat slower code that can be used even in bigger shared libraries. What actually means small and large here is arch dependent. E.g. on SPARC most load instructions have signed 13-bit immediate offsets. So, -fpic shared libraries can load GOT entries with ld[%l7 + offset], %reg (one instruction), but only if .got size is at most 8KB (if _GLOBAL_OFFSET_TABLE_ points in the middle of .got, otherwise 4KB), i.e. 2048(1024) pointers for 32-bit and 1024(512) pointers for 64-bit. -fPIC generates slower code, as load from GOT needs to be done with 3 instructions: sethi %hi(offset), %regX ! load high 22 bits of offset or %regX, %lo(offset), %regX ! low 10 bits ored into it ld[%l7 + %regX], %reg ! load the GOT entry On other arches the exact details are different, but in essence the problem is the same. So, the rules for using -f{pic,pie,PIC,PIE,no-pic} are: 1) use -fno-pic (the default) only for code that is linked into normal executables (not PIEs, not shared libraries) 2) use -f{pie,PIE} for code that is only linked into executables (normal ones and PIEs) 3) use -f{pic,PIC} otherwise 4) use -f{PIC,PIE} for code you put into .a libraries and you expect some other package will link things from that .a library into their shared libraries (or PIEs) 5) otherwise use -f{pic,pie}, if the shared library (PIE) links successfully 6) if linking fails on some architecture due to relocation overflows, retry with -f{PIC,PIE} (ideally only on that architecture) Jakub From opensource at till.name Wed May 9 13:55:56 2007 From: opensource at till.name (Till Maas) Date: Wed, 09 May 2007 15:55:56 +0200 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <20070509124602.GP355@devserv.devel.redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705081219.44853.opensource@till.name> <20070509124602.GP355@devserv.devel.redhat.com> Message-ID: <200705091555.57932.opensource@till.name> On Mi Mai 9 2007, Jakub Jelinek wrote: > DT_TEXTREL shared libraries are (almost always) a packaging bug which > should be fixed, not worked around by setting SELinux contexts. > In most cases that just means compiling all the objects that are linked > into the shared library with -fpic resp. -fPIC (for very large shared > libraries). In my case it is virtualbox, a x86 emulator. It uses code like it is described in http://people.redhat.com/~drepper/selinux-mem.html so I guess it is not (only) the -fpic stuff. Btw. what are very larged shared libraries? And should "-fpic" only be used when one encounters selinux problems? Regards, Till From abartlet at samba.org Wed May 9 14:05:33 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 10 May 2007 00:05:33 +1000 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178713829.32477.5.camel@hughsie-laptop> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> <20070508162949.GA24490@redhat.com> <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> <1178705587.13537.31.camel@localhost.localdomain> <1178713829.32477.5.camel@hughsie-laptop> Message-ID: <1178719533.13537.50.camel@localhost.localdomain> On Wed, 2007-05-09 at 13:30 +0100, Richard Hughes wrote: > On Wed, 2007-05-09 at 20:13 +1000, Andrew Bartlett wrote: > > > > Doing things around this driver (in older versions) had the keyboard > > playing up for me. I wondered if it was playing games with > > interrupts? > > Yes, I believe that's the case, although a self-compiled git version of > iwlwifi on a custom kernel doesn't do this, which is odd. > > As an aside when the redhat kernel is loaded and the iwl3945 driver is > loaded then I'm also unable to shutdown, the kernel just prints out > "shutting down" and never actually does anything, although a warning > about interrupts on the touchpad appears just before the shutdown > warning. > > Sorry about the overly vague symptoms, after my exams in a few days I > can debug this properly. With the latest kernel (I think 2.6.12-1.3144), I've got the system locked up from the keyboard (and I suspect disk). I can't type, nor SSH in (makes a connection, then hangs). But the mouse works... I got into this spot by leaving it on (broken, not working) wireless connection to my AP, then selecting wired. In the time it took to type in the URL for to RH's bugzilla, but before I filed the bug, it cut the keyboard. 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 dcbw at redhat.com Wed May 9 14:20:36 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 09 May 2007 10:20:36 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4641CD00.3060604@redhat.com> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> <4641CD00.3060604@redhat.com> Message-ID: <1178720436.18370.0.camel@localhost.localdomain> On Wed, 2007-05-09 at 09:30 -0400, Jarod Wilson wrote: > Dan Williams wrote: > > On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: > >> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: > >>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > >>>> If you are a rawhide user/tester and have ipw3945 hardware, please > >>>> try the latest kernels here: > >>>> > >>>> http://people.redhat.com/davej/kernels/Fedora/fc7/ > >>>> > >>>> I am having mixed results with the latest iwl3945 updates, but I'm > >>>> not sure if it is this particular laptop having problems or the driver > >>>> in general. > [...] > >>> ive never had the iwlwifi driver work for me and the newest version is no > >>> different. the first versions of the drivers would associate but quickly > >>> drop off. the last half dozen or so kernels ive tested fail to associate at > >>> all. in fact they don't even see any networks. > >> For me, I see networks, and in all previous versions I would get 'tx > >> buffer full', messages (after working for a very short moment), but now > >> I get nothing other than NetworkManger telling me to 'get a better > >> one' :-) > > > > Hmm, can you run 'lshal' and find the bit for the wireless device? > > There may be both wmaster0 and wifi0. > > There's this Toshiba laptop in front of me with an iwl3945-driven card > that for some reason, NetworkManager never notices is there -- never > gives any evidence in its menu that a wireless card exists. I've got a > wmaster0 and a wlan0, but no wifi0, if its relevant. Running SELinux? Dan > lshal output here: > > http://people.redhat.com/jwilson/misc/lshal-toshiba-tecra-a8-s8513.txt > > -- > Jarod Wilson > jwilson at redhat.com > From kmacmill at redhat.com Wed May 9 14:18:46 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 09 May 2007 10:18:46 -0400 Subject: Making Fedora a contributer friendly environment (Re: Selinux and package guidelines) In-Reply-To: <200705091555.57932.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705081219.44853.opensource@till.name> <20070509124602.GP355@devserv.devel.redhat.com> <200705091555.57932.opensource@till.name> Message-ID: <1178720326.2379.42.camel@localhost.localdomain> On Wed, 2007-05-09 at 15:55 +0200, Till Maas wrote: > On Mi Mai 9 2007, Jakub Jelinek wrote: > > > DT_TEXTREL shared libraries are (almost always) a packaging bug which > > should be fixed, not worked around by setting SELinux contexts. > > In most cases that just means compiling all the objects that are linked > > into the shared library with -fpic resp. -fPIC (for very large shared > > libraries). > > In my case it is virtualbox, a x86 emulator. It uses code like it is described > in http://people.redhat.com/~drepper/selinux-mem.html so I guess it is not > (only) the -fpic stuff. It's not and for applications like this you aren't likely to avoid executing writable memory. You should set the context correctly to allow executable memory (chcon -t unconfined_execmem_exec_t). Eventually we should avoid hard-coding contexts in the rpms but there is currently no better solution. > Btw. what are very larged shared libraries? And > should "-fpic" only be used when one encounters selinux problems? > Preventing relocations is not just an "selinux problem" - it is a good idea in general and prevents certain kinds of exploits. Karl From tromey at redhat.com Wed May 9 14:16:27 2007 From: tromey at redhat.com (Tom Tromey) Date: Wed, 9 May 2007 07:16:27 -0700 Subject: Sun just released the JDK under the GPL implications for F8 / F9? In-Reply-To: <20070509052747.GA28866@nostromo.devel.redhat.com> References: <4640E098.6@hhs.nl> <1178656650.9601.73.camel@localhost.localdomain> <17985.12800.58208.812026@localhost.localdomain> <20070509052747.GA28866@nostromo.devel.redhat.com> Message-ID: <17985.55227.8862.98723@localhost.localdomain> >>>>> "Bill" == Bill Nottingham writes: >> Which Fedora release this ships in depends on how quickly the >> encumbrances can be lifted. Bill> Is it a matter of lifting the encumberances, or just re-implementing Bill> said parts (and what are those parts?) Re-implementing -- and to be clear, everybody, including Sun, wants to do this. The binary blobs are a temporary measure. The bits I know about are some color management things (Roman has already successfully dropped in the Classpath impl -- but this too is not a permanent fix), parts of the Java 2D rendering pipeline, and some the font rasterizer. This is just what they mentioned on stage, I haven't dug into the sources to see more details. Tom From j.w.r.degoede at hhs.nl Wed May 9 14:43:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 16:43:51 +0200 Subject: Packaging quality, assistance. In-Reply-To: <4641CBB8.1010501@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> <4641CBB8.1010501@leemhuis.info> Message-ID: <4641DE27.8040408@hhs.nl> Thorsten Leemhuis wrote: > On 09.05.2007 14:45, David Woodhouse wrote: >> How about a tracker bug for each SIG? > > Well, we never defined in more detail how Packaging SIGs should work. > Maybe we should create a small set of guidelines that all SIGs follow, > to get such questions answered once and for all and a common "look and > feel". I think we should do that, but don't care enough to do it myself > ATM. And we'll get the usual yelling "to much bureaucracy" or "that's > should be the decision of the SIG itself" of course... ;-) > A tracker bug sounds like a good idea actually, other then that not too much rules please. (/me starts yelling: "to much bureaucracy"). Seriously, the Games SIG works well, really well if you ask me, but I wouldn't want to make what we do compulsory for other SIGs. Like wise I know the KDE SIG has weekly IRC meetings, if that works for them fine, but it doesn't sound like something which I envision the Games SIG doing soon. But as said a tracker bug, where SIG people can put themselves in the CC, and where packagers needing help can add there bug, sounds like a good, clean and simple plan. This same bug could be used by bug reporters who think a bug warrants the SIG's attention. Regards, Hans From jwilson at redhat.com Wed May 9 14:47:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 09 May 2007 10:47:21 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178720436.18370.0.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> <4641CD00.3060604@redhat.com> <1178720436.18370.0.camel@localhost.localdomain> Message-ID: <4641DEF9.6040604@redhat.com> Dan Williams wrote: > On Wed, 2007-05-09 at 09:30 -0400, Jarod Wilson wrote: >> Dan Williams wrote: >>> On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: >>>> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: >>>>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: >>>>>> If you are a rawhide user/tester and have ipw3945 hardware, please >>>>>> try the latest kernels here: [...] >> There's this Toshiba laptop in front of me with an iwl3945-driven card >> that for some reason, NetworkManager never notices is there -- never >> gives any evidence in its menu that a wireless card exists. I've got a >> wmaster0 and a wlan0, but no wifi0, if its relevant. > > Running SELinux? Yep, in enforcing mode. Bouncing w/selinux completely disabled now... No change in behavior, ifconfig still shows wmaster0 and wlan0, but NetworkManager is oblivious to their existence. -- Jarod Wilson jwilson at redhat.com From tcallawa at redhat.com Wed May 9 14:49:03 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 May 2007 09:49:03 -0500 Subject: [Guidelines Change] Conflicts In-Reply-To: <3e4ec4600705080801o3cd6db0ra002c21608b89fdf@mail.gmail.com> References: <1178547645.3661.19.camel@localhost.localdomain> <3e4ec4600705080801o3cd6db0ra002c21608b89fdf@mail.gmail.com> Message-ID: <1178722143.3733.16.camel@localhost.localdomain> On Tue, 2007-05-08 at 11:01 -0400, Michael Wiktowy wrote: > Just seeking some clarity why not doing the right thing is the right > thing to do. It was the attempt to say "Keeping Conflicts for old packages that don't exist anymore, and are not really plausible to come up in an upgrade scenario isn't necessary." Conflicts are one more thing that yum has to parse when performing package installs/upgrades, and anywhere we can make yum's job easier, I wholeheartedly endorse. :) ~spot From nicolas.mailhot at laposte.net Wed May 9 14:50:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 May 2007 16:50:51 +0200 (CEST) Subject: Packaging quality, assistance. In-Reply-To: <1178712743.2824.152.camel@pmac.infradead.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> Message-ID: <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > I am increasingly concerned by the discrepancy between 'Core' and > 'Extras' in such matters -- and now that they're merged, we don't seem > to have the convenient distinction which has always before told me > 'this > package should be taken with a pinch of salt'. Core and Extras also : * had very different lifecycles/staging with Core adhering stricly to rawhide, freezes and sparse use of updates, and Extras not having any common model I can think of (some packagers mirror Core practices, others ignore repo differences and just dump the same updates for all the repositories at any time, sometimes after release EOL, or before a rawhide build) * had very different consistency levels (Core tried to be self-consistent, Extras was forbidden to update Core but the restriction didn't self-apply) The latest clash is people trying to ignore Core rules and apply Extra practices to a Core component. Obviously there needs to be some sort of convergence to avoid new incidents -- Nicolas Mailhot From jwboyer at jdub.homelinux.org Wed May 9 14:48:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 09:48:35 -0500 Subject: Packaging quality, assistance. In-Reply-To: <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> Message-ID: <1178722115.3086.18.camel@zod.rchland.ibm.com> On Wed, 2007-05-09 at 16:50 +0200, Nicolas Mailhot wrote: > Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > > > I am increasingly concerned by the discrepancy between 'Core' and > > 'Extras' in such matters -- and now that they're merged, we don't seem > > to have the convenient distinction which has always before told me > > 'this > > package should be taken with a pinch of salt'. > > Core and Extras also : > > * had very different lifecycles/staging with Core adhering stricly to > rawhide, freezes and sparse use of updates, and Extras not having any > common model I can think of (some packagers mirror Core practices, > others ignore repo differences and just dump the same updates for all > the repositories at any time, sometimes after release EOL, or before a > rawhide build) > > * had very different consistency levels (Core tried to be > self-consistent, Extras was forbidden to update Core but the > restriction didn't self-apply) > > The latest clash is people trying to ignore Core rules and apply Extra > practices to a Core component. Obviously there needs to be some sort > of convergence to avoid new incidents Yes. Merging is a two way street, so some adaptations will be required on both sides. josh From jkeating at redhat.com Wed May 9 14:56:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 07:56:16 -0700 Subject: Status of rawhide Message-ID: <200705090756.17254.jkeating@redhat.com> Hello from the Red Hat summit! We're working very hard to get a rawhide out to you guys, and we're very close. Bill Nottingham started work on some code to pull packages out of Koji, do some multilib fun, and make a repo out of the packages. The next logical step would be hooking in parts of pungi to run buildinstall to make the repo installable. I've done some modifications to Bill's code to handle noarch packages that have ExcludeArch and whatnot, as well as integrated our whitelist/blacklist stuff for multilib. The current code repo is http://people.redhat.com/jkeating/git/mash.git and I'll shortly be making it into a Fedora Hosted project proper on git.fedoraproject.org and such. Unfortunately the code requires that you have the koji package store as a local file system (or nfs file system) so it won't be very usable outside the Fedora infrastructure. What's next? We need group info in the repodata, that means making use of a comps file. We need to compose _to_ the file store and make use of hardlinks for all the packages. We need to do a full arch test run, i386, x86_64, ppc, ppc64. At some point we need to integrate pungi and run buildinstall across the repos, but that requires some sort of runroot facility within Koji as buildinstall needs to be ran on the arch/package set it is 'buildinstalling'. And probably some more things we'll notice along the way. We also need to move some bits around on our staging server and on our master mirror to make use of the new layouts. We are getting very close. I'm going to be taking time when I can while at the RH Summit to work on some of this, and I'll be encouraging folks to help out where possible. Stay tuned, very exciting times ahead! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Wed May 9 15:05:06 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 09 May 2007 11:05:06 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4641DEF9.6040604@redhat.com> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> <4641CD00.3060604@redhat.com> <1178720436.18370.0.camel@localhost.localdomain> <4641DEF9.6040604@redhat.com> Message-ID: <1178723106.18370.37.camel@localhost.localdomain> On Wed, 2007-05-09 at 10:47 -0400, Jarod Wilson wrote: > Dan Williams wrote: > > On Wed, 2007-05-09 at 09:30 -0400, Jarod Wilson wrote: > >> Dan Williams wrote: > >>> On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: > >>>> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: > >>>>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > >>>>>> If you are a rawhide user/tester and have ipw3945 hardware, please > >>>>>> try the latest kernels here: > [...] > > >> There's this Toshiba laptop in front of me with an iwl3945-driven card > >> that for some reason, NetworkManager never notices is there -- never > >> gives any evidence in its menu that a wireless card exists. I've got a > >> wmaster0 and a wlan0, but no wifi0, if its relevant. > > > > Running SELinux? > > Yep, in enforcing mode. Bouncing w/selinux completely disabled now... No > change in behavior, ifconfig still shows wmaster0 and wlan0, but > NetworkManager is oblivious to their existence. You may need to restart NM after turning off enforcing mode to get it recognize the devices, if this is indeed the issue. HAL sends signals to NM, and NM queries HAL on startup, but if the signals or query were blocked originally, and you unblock them, NM will have no idea. Dan > > -- > Jarod Wilson > jwilson at redhat.com > From dcbw at redhat.com Wed May 9 15:05:34 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 09 May 2007 11:05:34 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4641DEF9.6040604@redhat.com> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> <4641CD00.3060604@redhat.com> <1178720436.18370.0.camel@localhost.localdomain> <4641DEF9.6040604@redhat.com> Message-ID: <1178723134.18370.39.camel@localhost.localdomain> On Wed, 2007-05-09 at 10:47 -0400, Jarod Wilson wrote: > Dan Williams wrote: > > On Wed, 2007-05-09 at 09:30 -0400, Jarod Wilson wrote: > >> Dan Williams wrote: > >>> On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: > >>>> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: > >>>>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: > >>>>>> If you are a rawhide user/tester and have ipw3945 hardware, please > >>>>>> try the latest kernels here: > [...] > > >> There's this Toshiba laptop in front of me with an iwl3945-driven card > >> that for some reason, NetworkManager never notices is there -- never > >> gives any evidence in its menu that a wireless card exists. I've got a > >> wmaster0 and a wlan0, but no wifi0, if its relevant. > > > > Running SELinux? > > Yep, in enforcing mode. Bouncing w/selinux completely disabled now... No > change in behavior, ifconfig still shows wmaster0 and wlan0, but > NetworkManager is oblivious to their existence. Obviously we need this to work with enforcing mode on... but for debugging purposes this is a useful exercise. > -- > Jarod Wilson > jwilson at redhat.com > From jwilson at redhat.com Wed May 9 15:20:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 09 May 2007 11:20:32 -0400 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178723106.18370.37.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <200705082301.27510.dennis@ausil.us> <1178689578.13537.25.camel@localhost.localdomain> <1178710852.17189.0.camel@localhost.localdomain> <4641CD00.3060604@redhat.com> <1178720436.18370.0.camel@localhost.localdomain> <4641DEF9.6040604@redhat.com> <1178723106.18370.37.camel@localhost.localdomain> Message-ID: <4641E6C0.1000609@redhat.com> Dan Williams wrote: > On Wed, 2007-05-09 at 10:47 -0400, Jarod Wilson wrote: >> Dan Williams wrote: >>> On Wed, 2007-05-09 at 09:30 -0400, Jarod Wilson wrote: >>>> Dan Williams wrote: >>>>> On Wed, 2007-05-09 at 15:46 +1000, Andrew Bartlett wrote: >>>>>> On Tue, 2007-05-08 at 23:01 -0500, Dennis Gilmore wrote: >>>>>>> Once upon a time Tuesday 08 May 2007, John W. Linville wrote: >>>>>>>> If you are a rawhide user/tester and have ipw3945 hardware, please >>>>>>>> try the latest kernels here: >> [...] >> >>>> There's this Toshiba laptop in front of me with an iwl3945-driven card >>>> that for some reason, NetworkManager never notices is there -- never >>>> gives any evidence in its menu that a wireless card exists. I've got a >>>> wmaster0 and a wlan0, but no wifi0, if its relevant. >>> Running SELinux? >> Yep, in enforcing mode. Bouncing w/selinux completely disabled now... No >> change in behavior, ifconfig still shows wmaster0 and wlan0, but >> NetworkManager is oblivious to their existence. > > You may need to restart NM after turning off enforcing mode to get it > recognize the devices, if this is indeed the issue. HAL sends signals > to NM, and NM queries HAL on startup, but if the signals or query were > blocked originally, and you unblock them, NM will have no idea. I actually did that. I set selinux to disabled in /etc/sysconfig/selinux and restarted the machine entirely. No difference. -- Jarod Wilson jwilson at redhat.com From hughsient at gmail.com Wed May 9 16:24:56 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 09 May 2007 17:24:56 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <1178705587.13537.31.camel@localhost.localdomain> References: <20070508130336.GB23247@redhat.com> <1178639822.2662.0.camel@hughsie-laptop> <1178640767.3606.3.camel@hughsie-laptop> <20070508162949.GA24490@redhat.com> <15e53e180705080948i3db76db3jec00cce37e2d812e@mail.gmail.com> <1178705587.13537.31.camel@localhost.localdomain> Message-ID: <1178727896.4069.3.camel@hughsie-laptop> On Wed, 2007-05-09 at 20:13 +1000, Andrew Bartlett wrote: > Doing things around this driver (in older versions) had the keyboard > playing up for me. I'm trying to build iwlwifi on the fedora kernel to narrow down the interrupts problem. It fails to build. On a custom (linus) kernel it builds fine: hughsie at hughsie-laptop:~/Code/iwlwifi$ make make -C /lib/modules/2.6.21-1.3144.fc7/source O= M=/home/hughsie/Code/iwlwifi/compatible/ modules make[1]: Entering directory `/usr/src/kernels/2.6.21-1.3144.fc7-i686' CC [M] /home/hughsie/Code/iwlwifi/compatible/base-3945.o In file included from :1: ./include/linux/autoconf.h:2017:1: warning: "CONFIG_IWLWIFI_DEBUG" redefined :1:1: warning: this is the location of the previous definition /home/hughsie/Code/iwlwifi/compatible/base.c:46:44: error: ../net/mac80211/ieee80211_rate.h: No such file or directory In file included from /home/hughsie/Code/iwlwifi/compatible/base.c:55: /home/hughsie/Code/iwlwifi/compatible/iwlwifi.h:53:41: error: ../net/mac80211/ieee80211_i.h: No such file or directory In file included from /home/hughsie/Code/iwlwifi/compatible/iwlwifi.h:57, Fedora kernel bug or simply a bad makefile for iwlwifi? The ../net/mac80211/ieee80211_rate.h type path looks fishy to me. Richard. From opensource at till.name Wed May 9 15:25:57 2007 From: opensource at till.name (Till Maas) Date: Wed, 09 May 2007 17:25:57 +0200 Subject: Making Fedora a contributer friendly environment In-Reply-To: <1178720326.2379.42.camel@localhost.localdomain> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091555.57932.opensource@till.name> <1178720326.2379.42.camel@localhost.localdomain> Message-ID: <200705091725.58679.opensource@till.name> On Mi Mai 9 2007, Karl MacMillan wrote: > It's not and for applications like this you aren't likely to avoid > executing writable memory. You should set the context correctly to allow > executable memory (chcon -t unconfined_execmem_exec_t). Eventually we > should avoid hard-coding contexts in the rpms but there is currently no > better solution. There are some drafts in: http://fedoraproject.org/wiki/PackagingDrafts/SELinux Which at least make these changes persistent. As far as I understand selinux, when someone disables it, all the contexts that were created in %post with chcon are lost. Also I am not sure, whether or not they get lost, after an policy-update, but I think I saw this happen once. The method descibed in the PackagingDraft which I followed with the following files: VirtualBox-OSE.te policy_module(VirtualBox-OSE, 1.0.0) VirtualBox-OSE.fc @VBOXINSTDIR@/.*\.so -- gen_context(system_u:object_r:textrel_shlib_t,s0) and the scriptlets there, at least works, but it is imho much to complicated. And when using semanage it is afaik impossible to change a selinux-configuration or remove it, because of the ordering of %post(un) %pre(un). In conlusion, there should first be some methods and (better (documented)) rpm support, before demanding that all packages should support selinux. E.g. what does "%policy" in "%files" do? Regards, Till From fedora at leemhuis.info Wed May 9 15:26:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 May 2007 17:26:29 +0200 Subject: Packaging quality, assistance. In-Reply-To: <4641DE27.8040408@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> <4641CBB8.1010501@leemhuis.info> <4641DE27.8040408@hhs.nl> Message-ID: <4641E825.8010202@leemhuis.info> Hans de Goede schrieb: > Thorsten Leemhuis wrote: >> On 09.05.2007 14:45, David Woodhouse wrote: >>> How about a tracker bug for each SIG? >> Well, we never defined in more detail how Packaging SIGs should work. >> Maybe we should create a small set of guidelines that all SIGs follow, >> to get such questions answered once and for all and a common "look and >> feel". I think we should do that, but don't care enough to do it myself >> ATM. And we'll get the usual yelling "to much bureaucracy" or "that's >> should be the decision of the SIG itself" of course... ;-) > A tracker bug sounds like a good idea actually, other then that not too much > rules please. (/me starts yelling: "to much bureaucracy"). Seriously, the Games > SIG works well, really well if you ask me, Well, you mentioning the Games SIG got me to this: We IMHO need guidelines for proper communication so non-SIG-Members are at least a roughly aware of doings and decisions from the SIG. Because that's what IMHO a big problem with the Games SIG. I'm subscribed to a whole lot of fedora mailing lists, but I did not subscribe to fedora-games-list. But as I package games even I would like to know at least the most important things the Games SIG does or decides -- changes to the games specific "Packaging guidelines" for example or even a "we still exists, are healthy and got xyz new games into Fedora in the past weeks" now and then. IOW: A *short* monthly status mail to fedora-maintainers would be nice; such posts would likely get included in the FWN. So that way you not only keep non-SIG members up2date about the happenings; you also get publicity and maybe find new packagers to join the SIG. > but I wouldn't want to make what we > do compulsory for other SIGs. Like wise I know the KDE SIG has weekly IRC > meetings, if that works for them fine, but it doesn't sound like something > which I envision the Games SIG doing soon. Agreed. > But as said a tracker bug, where SIG people can put themselves in the CC, and > where packagers needing help can add there bug, sounds like a good, clean and > simple plan. This same bug could be used by bug reporters who think a bug > warrants the SIG's attention. +1 CU thl From rc040203 at freenet.de Wed May 9 16:11:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 May 2007 18:11:22 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178722115.3086.18.camel@zod.rchland.ibm.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> Message-ID: <1178727082.3504.297.camel@mccallum.corsepiu.local> On Wed, 2007-05-09 at 09:48 -0500, Josh Boyer wrote: > On Wed, 2007-05-09 at 16:50 +0200, Nicolas Mailhot wrote: > > Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > > The latest clash is people trying to ignore Core rules and apply Extra > > practices to a Core component. Obviously there needs to be some sort > > of convergence to avoid new incidents > > Yes. Merging is a two way street, so some adaptations will be required > on both sides. Don't you think we already have done? Whether you like it or not, from a community point of view, actually nothing substantial has changed so far, except that we have been facing the side-effects of "construction-work near RH" on the Fedora infrastructure. Wrt. "collaboration with RH" and "unifying Core and Extra"s on packaging work actually nothing much has happened. Packages which have been under RH control still are under RH control and what had been under "community maintenance" still also is. The actual development model hasn't changed. It's still "RH vs. community". Ralf From rjones at redhat.com Wed May 9 16:27:21 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 09 May 2007 17:27:21 +0100 Subject: /etc/pki Message-ID: <4641F669.4040206@redhat.com> Is there a Fedora standard for what goes in /etc/pki? Or to put it another way, if I were writing an application and I put its PKI files in /etc/pki//... would that be OK? Particular files that the application needs to store: * self-generated CA certificate and associated files such as revocation list, issued certs, CA's private key * list of client certs of clients allowed to access (on server) * machine's own private key and certificate (client & server) Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From jspaleta at gmail.com Wed May 9 16:34:33 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 May 2007 08:34:33 -0800 Subject: Packaging quality, assistance. In-Reply-To: <4641DE27.8040408@hhs.nl> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> <4641CBB8.1010501@leemhuis.info> <4641DE27.8040408@hhs.nl> Message-ID: <604aa7910705090934q78f93910idf7908b9f7445fb1@mail.gmail.com> On 5/9/07, Hans de Goede wrote: > A tracker bug sounds like a good idea actually, other then that not too much > rules please. (/me starts yelling: "to much bureaucracy"). Seriously, the Games > SIG works well, really well if you ask me, but I wouldn't want to make what we > do compulsory for other SIGs. Like wise I know the KDE SIG has weekly IRC > meetings, if that works for them fine, but it doesn't sound like something > which I envision the Games SIG doing soon. What we really need is some guidance for the package submission process, which encourages new packages (and even old packagers) to review the list of SIGs and make a determination as to whether the new package submission should come to the SIGs attention at package submission time. For example I may at some point actually package a game...maybe....but I'm most likely forget that a Games SIG exists by that point. But if there's a broken out bullet item for the Contributor AND the reviewer in the submission/review process guidance to review the SIG list (and set the appropriate tracker bug if desired) that would be a really good reminder to keep SIGs in mind. Which reminds me, now that I'm in my new job I really need to touch base with the scientific SIG. -jef"hopefully someone else will beat me to it and package up londonlaw, so I do not have to sully myself with packaging a game"spaleta From jwboyer at jdub.homelinux.org Wed May 9 16:28:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 11:28:07 -0500 Subject: Packaging quality, assistance. In-Reply-To: <1178727082.3504.297.camel@mccallum.corsepiu.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> Message-ID: <1178728087.3086.26.camel@zod.rchland.ibm.com> On Wed, 2007-05-09 at 18:11 +0200, Ralf Corsepius wrote: > On Wed, 2007-05-09 at 09:48 -0500, Josh Boyer wrote: > > On Wed, 2007-05-09 at 16:50 +0200, Nicolas Mailhot wrote: > > > Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > > > > The latest clash is people trying to ignore Core rules and apply Extra > > > practices to a Core component. Obviously there needs to be some sort > > > of convergence to avoid new incidents > > > > Yes. Merging is a two way street, so some adaptations will be required > > on both sides. > Don't you think we already have done? > > Whether you like it or not, from a community point of view, actually > nothing substantial has changed so far, except that we have been facing > the side-effects of "construction-work near RH" on the Fedora > infrastructure. > > Wrt. "collaboration with RH" and "unifying Core and Extra"s on packaging > work actually nothing much has happened. Packages which have been under > RH control still are under RH control and what had been under "community > maintenance" still also is. Not true. KDE is now co-maintained with a community developer, and that developer has actually committed changes to CVS now. That's just one concrete example. We're also getting requests from packagers to allow builds for Core packages that bring in Extras deps. Things are not going to change magically overnight. Have patience. But your claims that it's "Red Hat vs. the community" are simply not true. josh From jonathan.underwood at gmail.com Wed May 9 16:35:35 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 9 May 2007 17:35:35 +0100 Subject: Making Fedora a contributer friendly environment In-Reply-To: <200705091725.58679.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091555.57932.opensource@till.name> <1178720326.2379.42.camel@localhost.localdomain> <200705091725.58679.opensource@till.name> Message-ID: <645d17210705090935h5e07b075y21cb5f9feb3563ae@mail.gmail.com> On 09/05/07, Till Maas wrote: [snip] > There are some drafts in: > http://fedoraproject.org/wiki/PackagingDrafts/SELinux [snip] I have been following this discussion a bit, and have read those draft packaging guidelines, and find myself as a packager rather confused. That draft details how to add support for SElinux to your package. But, what isn't clear to me is what the policy is for SElinux support more globally. Recently I've filed a few bugs against packages that have had problems with SElinux contexts and in each case the packager has re-assigned the bugs to the SElinux team, who have fixed the issue in an updated SElinux policy package. This would imply that the policy package is where things should be fixed, SElinux wise. But now that draft leaves me wondering if that is incorrect. Sooo.. where should SElinux contexts be set, in each package, or in the SElinux policy package? [Sorry if this is a dumb question] Jonathan. From rc040203 at freenet.de Wed May 9 16:52:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 May 2007 18:52:49 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178728087.3086.26.camel@zod.rchland.ibm.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> Message-ID: <1178729570.3504.313.camel@mccallum.corsepiu.local> On Wed, 2007-05-09 at 11:28 -0500, Josh Boyer wrote: > On Wed, 2007-05-09 at 18:11 +0200, Ralf Corsepius wrote: > > On Wed, 2007-05-09 at 09:48 -0500, Josh Boyer wrote: > > > On Wed, 2007-05-09 at 16:50 +0200, Nicolas Mailhot wrote: > > > > Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > > > > > > The latest clash is people trying to ignore Core rules and apply Extra > > > > practices to a Core component. Obviously there needs to be some sort > > > > of convergence to avoid new incidents > > > > > > Yes. Merging is a two way street, so some adaptations will be required > > > on both sides. > > Don't you think we already have done? > > > > Whether you like it or not, from a community point of view, actually > > nothing substantial has changed so far, except that we have been facing > > the side-effects of "construction-work near RH" on the Fedora > > infrastructure. > > > > Wrt. "collaboration with RH" and "unifying Core and Extra"s on packaging > > work actually nothing much has happened. Packages which have been under > > RH control still are under RH control and what had been under "community > > maintenance" still also is. > > Not true. KDE is now co-maintained with a community developer, C'mon, Rex has relabeled his former kde-redhat work under the Fedora brand. > and that > developer has actually committed changes to CVS now. That's just one > concrete example. Great, _one_ developer (and FBP, FESCO and FPC member) has CVS access. > We're also getting requests from packagers to allow builds for Core > packages that bring in Extras deps. > Things are not going to change magically overnight. Have patience. Don't you think we already are? I have not complained about nobody having done anything on this (IMO: unusable flagged review stuff causing the bugzilla list to be flooded, I did not complain about the web-pages going on and off almost daily. I did not complain about plague suddenly going offline for devel and being replaced with something largely undocumented called koji. I did not complain about all @RH's missing at the FPC meeting yesterday because (as it had leaked through other channels) them having been at the "RedHat summit". I did not complain about the merger "Freezing former Extras" (A regression in comparison to the pre-merger situation), ... Now accuse me to be impatient again ;) > But > your claims that it's "Red Hat vs. the community" are simply not true. Ask yourselves: Who decides on Core packages? @RH Example: The perl-packaging split, inclusion of non-free firmware packages, @RH's reactions on reviews, etc. Ralf From linux at glossolalie.org Wed May 9 17:03:25 2007 From: linux at glossolalie.org (Thierry Sayegh De Bellis) Date: Wed, 09 May 2007 18:03:25 +0100 Subject: /etc/pki In-Reply-To: <4641F669.4040206@redhat.com> References: <4641F669.4040206@redhat.com> Message-ID: <4641FEDD.1070807@glossolalie.org> Richard W.M. Jones wrote: > Is there a Fedora standard for what goes in /etc/pki? > > Or to put it another way, if I were writing an application and I put its > PKI files in /etc/pki//... would that be OK? > > Particular files that the application needs to store: > > * self-generated CA certificate and associated files such as revocation > list, issued certs, CA's private key > * list of client certs of clients allowed to access (on server) > * machine's own private key and certificate (client & server) > > Rich. > SSL-related keys are now in /etc/pki as far as RHEL5 is concerned so my guess is your approach is quite reasonable hth Thierry -- (o< Thierry Sayegh De Bellis, RHCE //\ http://glossolalie.com V_/_ Fingerprint: 9976 11FE D9C6 8C67 6242 7BB1 6466 3F1D 56ED 7D5A From nicolas.mailhot at laposte.net Wed May 9 17:08:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 09 May 2007 19:08:47 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178727082.3504.297.camel@mccallum.corsepiu.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> Message-ID: <1178730527.7187.18.camel@rousalka.dyndns.org> Le mercredi 09 mai 2007 ? 18:11 +0200, Ralf Corsepius a ?crit : > On Wed, 2007-05-09 at 09:48 -0500, Josh Boyer wrote: > > On Wed, 2007-05-09 at 16:50 +0200, Nicolas Mailhot wrote: > > > Le Mer 9 mai 2007 14:12, David Woodhouse a ?crit : > > > > The latest clash is people trying to ignore Core rules and apply Extra > > > practices to a Core component. Obviously there needs to be some sort > > > of convergence to avoid new incidents > > > > Yes. Merging is a two way street, so some adaptations will be required > > on both sides. > Don't you think we already have done? ... > The actual development model hasn't changed. It's still "RH vs. > community". I think I've been careful enough to point out the boundary was not Core/Extras or RH/Community but is within Extras, as the former FE never managed to reach internal consensus. Even EPEL separation in a sister project seems to have been driven more by RH & Centos requests than by clear shared organisational vision within FE. There can't be a development model clash between Core and Extras when Extras has no structured development model to clash with (individual Extra packagers have their own development models, with a large variance). While this avoids explicit disagreements it also makes managing users/new packagers/outsiders expectations harder. -- 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 paul at city-fan.org Wed May 9 17:11:32 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 09 May 2007 18:11:32 +0100 Subject: Making Fedora a contributer friendly environment In-Reply-To: <645d17210705090935h5e07b075y21cb5f9feb3563ae@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091555.57932.opensource@till.name> <1178720326.2379.42.camel@localhost.localdomain> <200705091725.58679.opensource@till.name> <645d17210705090935h5e07b075y21cb5f9feb3563ae@mail.gmail.com> Message-ID: <464200C4.3000400@city-fan.org> Jonathan Underwood wrote: > On 09/05/07, Till Maas wrote: > [snip] >> There are some drafts in: >> http://fedoraproject.org/wiki/PackagingDrafts/SELinux > [snip] > > I have been following this discussion a bit, and have read those draft > packaging guidelines, and find myself as a packager rather confused. > > That draft details how to add support for SElinux to your package. > But, what isn't clear to me is what the policy is for SElinux support > more globally. Recently I've filed a few bugs against packages that > have had problems with SElinux contexts and in each case the packager > has re-assigned the bugs to the SElinux team, who have fixed the issue > in an updated SElinux policy package. > > This would imply that the policy package is where things should be > fixed, SElinux wise. But now that draft leaves me wondering if that is > incorrect. > > Sooo.. where should SElinux contexts be set, in each package, or in > the SElinux policy package? > > [Sorry if this is a dumb question] There isn't a single correct answer for that one. If the program's behaviour is causing SELinux issues (unnecessary relocations, leaked file descriptors etc.) then the program should be fixed. If file contexts need setting, the best place to do it is in the main policy package. This is common with web applications for instance. There are also more complex cases such as daemons for which no policy currently exists. This may require the writing of policy for the daemon, including the introduction of new file context types. This is probably best done by writing and packaging a policy module (see also http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules) and, when the resulting policy appears stable, to get that policy merged into the upstream reference policy. Paul. From jwboyer at jdub.homelinux.org Wed May 9 17:25:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 12:25:43 -0500 Subject: Packaging quality, assistance. In-Reply-To: <1178729570.3504.313.camel@mccallum.corsepiu.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> Message-ID: <1178731543.3086.45.camel@zod.rchland.ibm.com> On Wed, 2007-05-09 at 18:52 +0200, Ralf Corsepius wrote: > > > Wrt. "collaboration with RH" and "unifying Core and Extra"s on packaging > > > work actually nothing much has happened. Packages which have been under > > > RH control still are under RH control and what had been under "community > > > maintenance" still also is. > > > > Not true. KDE is now co-maintained with a community developer, > C'mon, Rex has relabeled his former kde-redhat work under the Fedora > brand. What does that have to do with anything? > > and that > > developer has actually committed changes to CVS now. That's just one > > concrete example. > Great, _one_ developer (and FBP, FESCO and FPC member) has CVS access. Yeah. One so far. Less than a week after the merge. > > We're also getting requests from packagers to allow builds for Core > > packages that bring in Extras deps. > > > Things are not going to change magically overnight. Have patience. > Don't you think we already are? I think most are yes. > I have not complained about nobody having done anything on this (IMO: > unusable flagged review stuff causing the bugzilla list to be flooded, > I did not complain about the web-pages going on and off almost daily. Um... wtf does that have to do with Red Hat and/or the Core/Extras merge? Hardware breaks, gets upgraded, etc. Not to mention the fact that Red Hat just dropped a significant chunk of money to add new hardware to cope with the merge. Should they apologize for a state of flux while that hardware was integrated? I think not. > I did not complain about plague suddenly going offline for devel and > being replaced with something largely undocumented called koji. Do you have difficulties with koji or ..? Seriously, if there are issues here they can be addressed. From a packager standpoint, building packages is still done with 'make build'. > I did not complain about all @RH's missing at the FPC meeting yesterday > because (as it had leaked through other channels) them having been at > the "RedHat summit". People have day jobs... I miss FESCo meetings because of mine... should I be kicked off of it? And I'm pretty sure it wasn't "leaked through other channels". Nobody was sneaking around not telling people that a Red Hat summit was going on... > I did not complain about the merger "Freezing former Extras" (A > regression in comparison to the pre-merger situation), ... "regression". I disagree. Extras had no structure. Did it work for the most part? Sure. But then again, there were never Extras packages being included in ISO spins, etc. Things like this are what I'm talking about when I say it's a two way street. > Now accuse me to be impatient again ;) It's not your patience that irks me. It's your insistence upon _making_ this a Red Hat versus community fight. > > But > > your claims that it's "Red Hat vs. the community" are simply not true. > Ask yourselves: Who decides on Core packages? @RH Um... because Core _just_ got merged and we're in the middle of trying to get a release out the door... > Example: The perl-packaging split, inclusion of non-free firmware > packages, @RH's reactions on reviews, etc. non-free firmware went to the Board. There are non-Red Hat people on the Board. What more do you want here? josh From sertac.liste at gmail.com Wed May 9 17:31:43 2007 From: sertac.liste at gmail.com (=?utf-8?B?U2VydGHDpyDDli4gWcSxbGTEsXo=?=) Date: Wed, 9 May 2007 20:31:43 +0300 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4c4ba1530705080946w45f53518tadaa5cadc6e92761@mail.gmail.com> References: <20070508130336.GB23247@redhat.com> <4c4ba1530705080926y3b684deby1eb2570378771d7d@mail.gmail.com> <20070508163204.GB24490@redhat.com> <4c4ba1530705080946w45f53518tadaa5cadc6e92761@mail.gmail.com> Message-ID: <20070509173142.GA4089@kerouac> [08.May.07 09:46 -0700] Tom London: > On 5/8/07, John W. Linville wrote: >> I see a lot of "eth0" -- did you rename the interface? By default >> iwl3945 should have a name like "wlan0". >> > Don't know how that happened, but that seems to be the way it is...: > eth0 IEEE 802.11a ESSID:"" > Mode:Managed Frequency:5.18 GHz Access Point: Not-Associated > Retry min limit:7 RTS thr:off Fragment thr=2346 B > Encryption key:off > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > eth1 no wireless extensions. > I was running both iwlwifi and ipw3945 on the same kernel. Perhaps > that got it 'renamed'. I?ve also seen this happen after using iwlwifi. After NM establishes connection this was logged: | kernel: eth1: duplicate address detected! And returning back to ipw3945 (due to suspend/shutdown problems) interface was renamed to eth0 once and then to devXXXX. Also after NetworkManager?s INTERFACE_ADD commands, wpa_supplicant?s logged responses were strange: | NetworkManager: SUP: response was '@d?' | NetworkManager: SUP: response was '`d?' | NetworkManager: SUP: response was '`d?' | NetworkManager: SUP: response was '?' | NetworkManager: SUP: response was 'Hd?' | NetworkManager: SUP: response was 'Hd?' | NetworkManager: SUP: response was '?d?' On the other hand I didn?t have any connection/association problems with 3139 and 3142 kernel. -- ~serta? From dwmw2 at infradead.org Wed May 9 17:34:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 18:34:09 +0100 Subject: /etc/pki In-Reply-To: <4641F669.4040206@redhat.com> References: <4641F669.4040206@redhat.com> Message-ID: <1178732049.2824.207.camel@pmac.infradead.org> On Wed, 2007-05-09 at 17:27 +0100, Richard W.M. Jones wrote: > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. > Registered in England and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David > Owens (Ireland) Please don't pollute public mailing lists with this nonsense -- keep your .sig to 4 lines at a maximum. If you must put the above information in every email you send, at least put it in a header, not the body of the mail -- and you certainly don't need to include the full list of directors. You're welcome to an account @infradead.org if your employer imposes moronic policies on public-facing mail, btw. :) -- dwmw2 From mclasen at redhat.com Wed May 9 17:43:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 May 2007 13:43:45 -0400 Subject: /etc/pki In-Reply-To: <1178732049.2824.207.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> Message-ID: <1178732625.3872.10.camel@localhost.localdomain> On Wed, 2007-05-09 at 18:34 +0100, David Woodhouse wrote: > On Wed, 2007-05-09 at 17:27 +0100, Richard W.M. Jones wrote: > > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. > > Registered in England and Wales under Company Registration No. 3798903 > > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David > > Owens (Ireland) > > Please don't pollute public mailing lists with this nonsense -- keep > your .sig to 4 lines at a maximum. > > If you must put the above information in every email you send, at least > put it in a header, not the body of the mail -- and you certainly don't > need to include the full list of directors. > > You're welcome to an account @infradead.org if your employer imposes > moronic policies on public-facing mail, btw. :) You really can't help it can you ? From michael.wiktowy at gmail.com Wed May 9 17:54:25 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Wed, 9 May 2007 13:54:25 -0400 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178722143.3733.16.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> <3e4ec4600705080801o3cd6db0ra002c21608b89fdf@mail.gmail.com> <1178722143.3733.16.camel@localhost.localdomain> Message-ID: <3e4ec4600705091054t5d008c40x39181fd081d53330@mail.gmail.com> On 5/9/07, Tom spot Callaway wrote: > On Tue, 2007-05-08 at 11:01 -0400, Michael Wiktowy wrote: > > > Just seeking some clarity why not doing the right thing is the right > > thing to do. > > It was the attempt to say "Keeping Conflicts for old packages that don't > exist anymore, and are not really plausible to come up in an upgrade > scenario isn't necessary." > > Conflicts are one more thing that yum has to parse when performing > package installs/upgrades, and anywhere we can make yum's job easier, I > wholeheartedly endorse. :) OK ... that makes a lot of sense ... but that isn't what you wrote in the guidelines :] Thanks for clarifying. /Mike From dwmw2 at infradead.org Wed May 9 18:00:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 19:00:46 +0100 Subject: /etc/pki In-Reply-To: <1178732625.3872.10.camel@localhost.localdomain> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> <1178732625.3872.10.camel@localhost.localdomain> Message-ID: <1178733646.2824.215.camel@pmac.infradead.org> On Wed, 2007-05-09 at 13:43 -0400, Matthias Clasen wrote: > You really can't help it can you ? Help what? Asking people to conform to basic netiquette? I'm sure I _could_ put up with people failing to do so, but I generally choose to ask them to fix it. Is that a problem for you? -- dwmw2 From aph at redhat.com Wed May 9 18:05:49 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 19:05:49 +0100 Subject: /etc/pki In-Reply-To: <1178733646.2824.215.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> <1178732625.3872.10.camel@localhost.localdomain> <1178733646.2824.215.camel@pmac.infradead.org> Message-ID: <17986.3453.963000.683404@zebedee.pink> David Woodhouse writes: > On Wed, 2007-05-09 at 13:43 -0400, Matthias Clasen wrote: > > You really can't help it can you ? > > Help what? Asking people to conform to basic netiquette? > > I'm sure I _could_ put up with people failing to do so, but I generally > choose to ask them to fix it. Is that a problem for you? David, Mathias: both of you are off-topic. Take it to email. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From jkeating at redhat.com Wed May 9 18:06:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 11:06:11 -0700 Subject: /etc/pki In-Reply-To: <1178733646.2824.215.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <1178732625.3872.10.camel@localhost.localdomain> <1178733646.2824.215.camel@pmac.infradead.org> Message-ID: <200705091106.12012.jkeating@redhat.com> On Wednesday 09 May 2007 11:00:46 David Woodhouse wrote: > Help what? Resist dropping unreasonably rude comments in your mails. It really paints you in a "I'm better than everybody" kind of light, which nobody likes to look at. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From debarshi.ray at gmail.com Wed May 9 18:14:36 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 9 May 2007 23:44:36 +0530 Subject: Python 2.4.4 FC6 SRPM Message-ID: <3170f42f0705091114y3096ccc5uccc2e11774f49251@mail.gmail.com> I installed the Python 2.4.4 FC6 SRPM on my Fedora 7 test 4 system and tried to build it using: $ rpmbuild -ba python.spec. However this leads to an error in the %build stage. gcc -pthread -fPIC -fno-strict-aliasing -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 -D_GNU_SOURCE -fPIC -I/usr/kerberos/include -I. -I./Include -I/usr/include/db4 -c ./Modules/_bsddb.c -o Modules/_bsddb.o ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:3844: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5042: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5042: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:5042: error: for each function it appears in.) ./Modules/_bsddb.c:5077: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.54845 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.54845 (%build) What is wrong? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Wed May 9 18:24:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 May 2007 23:54:26 +0530 Subject: Packaging quality, assistance. In-Reply-To: <1178731543.3086.45.camel@zod.rchland.ibm.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> <1178731543.3086.45.camel@zod.rchland.ibm.com> Message-ID: <464211DA.9010600@fedoraproject.org> Josh Boyer wrote: > non-free firmware went to the Board. There are non-Red Hat people on > the Board. What more do you want here? Everybody is born crying. Some of us just learned to stop. Rahul From mclasen at redhat.com Wed May 9 18:34:27 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 May 2007 14:34:27 -0400 Subject: Packaging quality, assistance. In-Reply-To: <1178731543.3086.45.camel@zod.rchland.ibm.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> <1178731543.3086.45.camel@zod.rchland.ibm.com> Message-ID: <1178735668.3872.17.camel@localhost.localdomain> On Wed, 2007-05-09 at 12:25 -0500, Josh Boyer wrote: > > > and that > > > developer has actually committed changes to CVS now. That's just one > > > concrete example. > > Great, _one_ developer (and FBP, FESCO and FPC member) has CVS access. > > Yeah. One so far. Less than a week after the merge. FWIW, we already have Richard Hughes co-maintaining gnome-power-manager, hal and hal-info, and Thomas Vander Stichele has agreed to co-maintain the gstreamer packages, so it is not just _one_ developer anymore, and I'm sure that there will be more examples soon. Matthias From jkeating at redhat.com Wed May 9 18:46:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 11:46:34 -0700 Subject: Packaging quality, assistance. In-Reply-To: <1178735668.3872.17.camel@localhost.localdomain> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178731543.3086.45.camel@zod.rchland.ibm.com> <1178735668.3872.17.camel@localhost.localdomain> Message-ID: <200705091146.35221.jkeating@redhat.com> On Wednesday 09 May 2007 11:34:27 Matthias Clasen wrote: > FWIW, we already have Richard Hughes co-maintaining gnome-power-manager, > hal and hal-info, and Thomas Vander Stichele has agreed to co-maintain > the gstreamer packages, so it is not just _one_ developer anymore, and > I'm sure that there will be more examples soon. Add to that non-Red Hat people not only making decisions about what packages to accept in the final tags, they are tagging them as well. Things _are_ shifting. Really, we're building ONE community, whether your employed by Red Hat, or somebody else, it doesn't matter. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Wed May 9 19:02:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 21:02:44 +0200 Subject: Packaging quality, assistance. In-Reply-To: <4641E825.8010202@leemhuis.info> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> <4641CBB8.1010501@leemhuis.info> <4641DE27.8040408@hhs.nl> <4641E825.8010202@leemhuis.info> Message-ID: <46421AD4.1030209@hhs.nl> Thorsten Leemhuis wrote: > Hans de Goede schrieb: > > IOW: A *short* monthly status mail to fedora-maintainers would be nice; > such posts would likely get included in the FWN. So that way you not > only keep non-SIG members up2date about the happenings; you also get > publicity and maybe find new packagers to join the SIG. > Doesn't sound like a bad plan, any volunteers todo this? Regards, Hans From j.w.r.degoede at hhs.nl Wed May 9 19:06:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 21:06:06 +0200 Subject: Packaging quality, assistance. In-Reply-To: <604aa7910705090934q78f93910idf7908b9f7445fb1@mail.gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <4641BFC6.7080105@leemhuis.info> <1178714732.2824.173.camel@pmac.infradead.org> <4641CBB8.1010501@leemhuis.info> <4641DE27.8040408@hhs.nl> <604aa7910705090934q78f93910idf7908b9f7445fb1@mail.gmail.com> Message-ID: <46421B9E.7030700@hhs.nl> Jeff Spaleta wrote: > > -jef"hopefully someone else will beat me to it and package up > londonlaw, so I do not have to sully myself with packaging a > game"spaleta > I've just added it to the list of potential games to package on the Games SIG wiki page. Notice that since this is a wiki others should feel free to add interesting (FREE!) games there too. Regards, Hans From wtogami at redhat.com Wed May 9 19:00:47 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 May 2007 15:00:47 -0400 Subject: Packaging quality, assistance. In-Reply-To: <1178735668.3872.17.camel@localhost.localdomain> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> <1178731543.3086.45.camel@zod.rchland.ibm.com> <1178735668.3872.17.camel@localhost.localdo! main> Message-ID: <46421A5F.5070903@redhat.com> Matthias Clasen wrote: > On Wed, 2007-05-09 at 12:25 -0500, Josh Boyer wrote: > >>>> and that >>>> developer has actually committed changes to CVS now. That's just one >>>> concrete example. >>> Great, _one_ developer (and FBP, FESCO and FPC member) has CVS access. >> Yeah. One so far. Less than a week after the merge. > > FWIW, we already have Richard Hughes co-maintaining gnome-power-manager, > hal and hal-info, and Thomas Vander Stichele has agreed to co-maintain > the gstreamer packages, so it is not just _one_ developer anymore, and > I'm sure that there will be more examples soon. > > Matthias > Stu Tomlinson (Pidgin upstream developer) is now co-owner of pidgin in Fedora with me. Warren Togami wtogami at redhat.com From debarshi.ray at gmail.com Wed May 9 19:36:18 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 10 May 2007 01:06:18 +0530 Subject: Python 2.5 F7 SPEC Message-ID: <3170f42f0705091236j63769bdmada3db812e14a739@mail.gmail.com> I wonder if the following modification will make the Python 2.5 package more tolerant towards systems having some other version of Python (make altinstall). --- python.spec 2007-04-10 19:53:41.000000000 +0530 +++ python.spec.new 2007-05-10 01:01:34.000000000 +0530 @@ -359,7 +359,11 @@ rm -fr $RPM_BUILD_ROOT %defattr(-, root, root) %doc LICENSE README %{_bindir}/pydoc* -%{_bindir}/python* +%{_bindir}/python +%{_bindir}/python2 +%{_bindir}/python%{pybasever} +%{_bindir}/python-config +%{_bindir}/python%{pybassever}-config %{_mandir}/*/* Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From kevin.kofler at chello.at Wed May 9 19:42:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 9 May 2007 19:42:56 +0000 (UTC) Subject: Python 2.5 F7 SPEC References: <3170f42f0705091236j63769bdmada3db812e14a739@mail.gmail.com> Message-ID: Debarshi 'Rishi' Ray gmail.com> writes: > I wonder if the following modification will make the Python 2.5 > package more tolerant towards systems having some other version of > Python (make altinstall). No. > -%{_bindir}/python* This is just the same as this: > +%{_bindir}/python > +%{_bindir}/python2 > +%{_bindir}/python%{pybasever} > +%{_bindir}/python-config > +%{_bindir}/python%{pybassever}-config because RPMs are installed to a buildroot and only files in that buildroot are packaged, not any files with matching names which happen to be on the system. Kevin Kofler From dwmw2 at infradead.org Wed May 9 19:47:24 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 20:47:24 +0100 Subject: /etc/pki In-Reply-To: <200705091106.12012.jkeating@redhat.com> References: <4641F669.4040206@redhat.com> <1178732625.3872.10.camel@localhost.localdomain> <1178733646.2824.215.camel@pmac.infradead.org> <200705091106.12012.jkeating@redhat.com> Message-ID: <1178740044.2824.229.camel@pmac.infradead.org> On Wed, 2007-05-09 at 11:06 -0700, Jesse Keating wrote: > Resist dropping unreasonably rude comments in your mails. It really > paints you in a "I'm better than everybody" kind of light, which > nobody likes to look at. You seem to be inferring something I didn't imply. I'm not sure what in my response to Richard would make you think that I thought such a thing (that I'm better than him). I certainly don't think that. -- dwmw2 From debarshi.ray at gmail.com Wed May 9 19:48:13 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 10 May 2007 01:18:13 +0530 Subject: Python 2.5 F7 SPEC In-Reply-To: References: <3170f42f0705091236j63769bdmada3db812e14a739@mail.gmail.com> Message-ID: <3170f42f0705091248l332a1282m5a1c4988cc14f508@mail.gmail.com> > because RPMs are installed to a buildroot and only files in that buildroot are > packaged, not any files with matching names which happen to be on the system. Thanks for the explanation. I am new to this, and was a bit confused. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From lightsolphoenix at gmail.com Wed May 9 20:32:53 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 9 May 2007 16:32:53 -0400 Subject: Packaging quality, assistance. In-Reply-To: <200705091146.35221.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178735668.3872.17.camel@localhost.localdomain> <200705091146.35221.jkeating@redhat.com> Message-ID: <200705091632.53814.lightsolphoenix@gmail.com> On Wednesday, May 09, 2007 2:46 pm Jesse Keating wrote: > Really, we're building ONE community, whether your employed by Red Hat, or > somebody else, it doesn't matter. The problem is the people who don't seem to see this. I find it highly interesting that most of the aforementioned are pushing other distros, mainly Ubuntu and openSUSE, both of which work pretty much the same way; central company and a community around it. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From jkeating at redhat.com Wed May 9 20:51:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 13:51:39 -0700 Subject: /etc/pki In-Reply-To: <1178740044.2824.229.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> Message-ID: <200705091351.43232.jkeating@redhat.com> On Wednesday 09 May 2007 12:47:24 David Woodhouse wrote: > You seem to be inferring something I didn't imply. I'm not sure what in > my response to Richard would make you think that I thought such a thing > (that I'm better than him). I certainly don't think that. David, one thing that seems hard for you to grasp is that it does not matter what _you_ think, it matters what readers read into your words. All it takes is a smallest of efforts to avoid calling people or companies things like 'moronic' or 'idiotic' or other such things. A small step will make a big difference. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 9 20:52:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 13:52:52 -0700 Subject: Packaging quality, assistance. In-Reply-To: <200705091632.53814.lightsolphoenix@gmail.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091146.35221.jkeating@redhat.com> <200705091632.53814.lightsolphoenix@gmail.com> Message-ID: <200705091352.53112.jkeating@redhat.com> On Wednesday 09 May 2007 13:32:53 Kelly wrote: > The problem is the people who don't seem to see this. ?I find it highly > interesting that most of the aforementioned are pushing other distros, > mainly Ubuntu and openSUSE, both of which work pretty much the same way; > central company and a community around it. And they're even worse now, as "community" can't touch the basic of packages. There is that wall between what the company touches and what the "community" touches. We're breaking that barrier. With a sledge hammer. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Wed May 9 21:05:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 May 2007 22:05:23 +0100 Subject: /etc/pki In-Reply-To: <200705091351.43232.jkeating@redhat.com> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> Message-ID: <1178744723.2824.248.camel@pmac.infradead.org> On Wed, 2007-05-09 at 13:51 -0700, Jesse Keating wrote: > David, one thing that seems hard for you to grasp is that it does not matter > what _you_ think, it matters what readers read into your words. All it takes > is a smallest of efforts to avoid calling people or companies things > like 'moronic' or 'idiotic' or other such things. A small step will make a > big difference. But I didn't call people or companies 'moronic'; certainly not anyone here. I called a _policy_ moronic. That's almost an oxymoron, in my book -- since 'policy' is so often just a euphemism for not actually having to think. There's a _very_ big jump between "that policy is moronic" or "that law is moronic" or whatever I may have said, and your claimed inference "I am better than everyone". Please don't put words in my mouth. -- dwmw2 From krh at redhat.com Wed May 9 22:06:31 2007 From: krh at redhat.com (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=) Date: Wed, 09 May 2007 18:06:31 -0400 Subject: /etc/pki In-Reply-To: <1178744723.2824.248.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> <1178744723.2824.248.camel@pmac.infradead.org> Message-ID: <464245E7.3010900@redhat.com> David Woodhouse wrote: > On Wed, 2007-05-09 at 13:51 -0700, Jesse Keating wrote: >> David, one thing that seems hard for you to grasp is that it does not matter >> what _you_ think, it matters what readers read into your words. All it takes >> is a smallest of efforts to avoid calling people or companies things >> like 'moronic' or 'idiotic' or other such things. A small step will make a >> big difference. > > But I didn't call people or companies 'moronic'; certainly not anyone > here. I called a _policy_ moronic. > > That's almost an oxymoron, in my book -- since 'policy' is so often just > a euphemism for not actually having to think. This is just splitting hairs. But I'll concede that Richards signature is excessive and I think it's fair game to point that out to him. It would be a fine thing to do if you were otherwise replying to his email, for example, you could say at the end of your reply "Btw, your signature is a bit excessive, would you mind trimming it?". Replying to his mail to point it out is just noise and it looks like you're going out of your way to police the mailing list. > There's a _very_ big jump between "that policy is moronic" or "that law > is moronic" or whatever I may have said, and your claimed inference > "I am better than everyone". Please don't put words in my mouth. Let's look at the words that you did put in your reply, then: > Please don't pollute public mailing lists with this nonsense -- keep > your .sig to 4 lines at a maximum. > > If you must put the above information in every email you send, at least > put it in a header, not the body of the mail -- and you certainly don't > need to include the full list of directors. > > You're welcome to an account @infradead.org if your employer imposes > moronic policies on public-facing mail, btw. :) I'm sure you have the best intentions, but the wording here is insulting. Do you not agree that calling somebody's email 'pollution' is insulting? That calling somebody's signature 'nonsense' is insulting? Calling somebody's employer 'moronic'? Surely you could have chosen less inflammatory words without compromising the message. This is not about enforcing political correctness. It's about not insulting random people over petty details in a community that's supposed to be friendly and constructive. I'm just trying to help. Kristian From Axel.Thimm at ATrpms.net Wed May 9 22:58:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 00:58:23 +0200 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> Message-ID: <20070509225823.GA27033@neu.nirvana> On Wed, May 09, 2007 at 10:41:53AM +0300, Jonathan Dieter wrote: > The "right" way to set a deltaurl for a repository in yum-presto is to > put it in the repository's .repo file. ATM, you can also put the > deltaurl in presto.conf, though I keep on saying that that method will > be removed soon. Would it be possible to have transparent configs, e.g. a canonical folder in the repo which presto checks for existance and uses it if available? Ideally, if deltarpms are a success as they promise to be why touch the repofiles at all and not simply just download the plugin and ready you are? This would also allow repo to slide in presto support w/o having to notify their users to modify repofiles etc. So today you install presto and only a couple of repos support it and automagically you get more and more repos that spare your bandwidth w/o the user doing anything more. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Wed May 9 23:20:00 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 09 May 2007 19:20:00 -0400 Subject: Hello again Message-ID: <1178752801.5313.1.camel@ignacio.lan> Hello all. I realize that I've been gone for a long time, but I'd like to resume helping the Fedora Project where possible. I've been digesting wiki pages and mailing list archives as fast as I can, and I'm hoping to be able to get back into the swing of things by this weekend. I apologize for my long silence, and I realize that it wasn't fair of me to just run off leaving you hanging. What I have been doing for the past 9 or so months is a series of topics for when I'm very, VERY drunk, but rest assured that I will apply the various lessons learned about teamwork and leadership towards my efforts within the Project. Yours Faithfully, Ignacio Vazquez-Abrams From jwboyer at jdub.homelinux.org Wed May 9 23:22:33 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 18:22:33 -0500 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178752954.11253.7.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. Hey! You didn't die! > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Life happens. Your packages were orphaned and absorbed by other maintainers. If you'd like, you could contact them and see if they would like a co-maintainer. Or simply package some new ones up :). In any case, welcome back. josh From bpepple at fedoraproject.org Wed May 9 23:31:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 09 May 2007 19:31:14 -0400 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178753474.5807.8.camel@lincoln> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Welcome back! /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed May 9 23:30:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 18:30:35 -0500 Subject: Packaging quality, assistance. In-Reply-To: <200705091352.53112.jkeating@redhat.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091146.35221.jkeating@redhat.com> <200705091632.53814.lightsolphoenix@gmail.com> <200705091352.53112.jkeating@redhat.com> Message-ID: <1178753436.11253.11.camel@vader.jdub.homelinux.org> On Wed, 2007-05-09 at 13:52 -0700, Jesse Keating wrote: > On Wednesday 09 May 2007 13:32:53 Kelly wrote: > > The problem is the people who don't seem to see this. I find it highly > > interesting that most of the aforementioned are pushing other distros, > > mainly Ubuntu and openSUSE, both of which work pretty much the same way; > > central company and a community around it. > > And they're even worse now, as "community" can't touch the basic of packages. > There is that wall between what the company touches and what the "community" > touches. We're breaking that barrier. With a sledge hammer. Which means there's usually a large mess left after the sledge hammer demolition that needs to be cleaned up. Which is exactly the state we're in now, and working hard to finish. josh From opensource at till.name Wed May 9 23:54:05 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 01:54:05 +0200 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <20070509225823.GA27033@neu.nirvana> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> Message-ID: <200705100154.07186.opensource@till.name> On Do Mai 10 2007, Axel Thimm wrote: > Would it be possible to have transparent configs, e.g. a canonical > folder in the repo which presto checks for existance and uses it if > available? Afaik on presto enabled repositories, this is written in the repo metadata, > Ideally, if deltarpms are a success as they promise to be why touch > the repofiles at all and not simply just download the plugin and ready > you are? so this is already the case. But as long as the delta rpms are in another repository / not mentioned in the repo metadata, manual intervention is needed. Regards, Till From tcallawa at redhat.com Thu May 10 00:13:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 May 2007 19:13:23 -0500 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178756003.3570.19.camel@localhost.localdomain> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Welcome back! ~spot From sundaram at fedoraproject.org Thu May 10 00:21:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 10 May 2007 05:51:55 +0530 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <464265A3.6020102@fedoraproject.org> Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. > Welcome back. You disappearing did have a positive effect. It showed that Fedora Project had reached a stage where it is more or less resilient to active contributors disappearing without a trace. Rahul From skvidal at linux.duke.edu Thu May 10 00:23:33 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 09 May 2007 20:23:33 -0400 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178756613.3862.14.camel@rivendell> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Ignacio, The fedora crack detective agency wandered around parts of canada looking for you. You were missed. We're glad to have you back. -sv From opensource at till.name Thu May 10 00:26:28 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 02:26:28 +0200 Subject: /etc/pki In-Reply-To: <1178732049.2824.207.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> Message-ID: <200705100226.29719.opensource@till.name> On Mi Mai 9 2007, David Woodhouse wrote: > Please don't pollute public mailing lists with this nonsense -- keep > your .sig to 4 lines at a maximum. > > If you must put the above information in every email you send, at least > put it in a header, not the body of the mail -- and you certainly don't > need to include the full list of directors. Are you sure about this? IANAL, but in Germany (maybe it is EU law) one has to include this kind of information[1] in (some)[2] business letters (including e-mail)[3]. And normally including it in the header is at least a grey zone[4] and still can cause a lot of trouble to a company, because of "warning letters" with a demand to give a "declaration of discontinuance with a penalty clause" (in German: Abmahnung mit strafbewerter Unterlassungserkl?rung) that can be written by any competitor and cost the receiving company money. Regards, Till [1] Including the full list of directors. [2] Maybe it is not needed in a mail to a mailing list, but who really knows these days. [3] And maybe even short messages (sms) (messages sent from mobile phones that are normally restricted to 160 characters). [4] Because it is not assurred that the headers are displayed in every e-mail client. Otherwise the Organization-Header may be sufficient, which seems to be also used by some UK RedHat employees. From a.badger at gmail.com Thu May 10 00:36:28 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 09 May 2007 17:36:28 -0700 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178757389.26679.0.camel@localhost.localdomain> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Hey! Good to see your alive and well! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Thu May 10 00:59:09 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 9 May 2007 20:59:09 -0400 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <16de708d0705091759p2a89548eidefc0bf905cf814c@mail.gmail.com> On 5/9/07, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. > > Yours Faithfully, > Ignacio Vazquez-Abrams DUDE, you're alive. We've been searching the internet and the real world for you. We've had guys call the local cops. You okay now? Hold tight, Peace -- Fedora Core 6 and proud From icon at fedoraproject.org Thu May 10 01:15:39 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 9 May 2007 21:15:39 -0400 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: On 5/9/07, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. Welcome back to the world of the living. :) I'm glad my optimism was not unfounded. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From rdieter at math.unl.edu Thu May 10 01:17:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 May 2007 20:17:16 -0500 Subject: Review Request: jss - Java Security Services (bz#230262) Message-ID: <4642729C.1010105@math.unl.edu> FYI, (originally posted to fab-list) reviewer(s) kindly requested. -- Rex --------------- Forwarded message (begin) Subject: Status of JSS in Fedora? From: Margaret Lum Date: Wed, 09 May 2007 19:51:02 -0500 Hi folks, I've noticed this package has been collecting dust for awhile. My team needs this in our first open source release of our product (Certificate System), and I'm working on a parallel port (from internal source) to the build system here @RH. If this is not the most productive forum for such approval, please point me in the right direction. This package was already submitted, but it's almost 2 months past the initial file date. The issue that needs both resolution and an immediate updated status is: Bugzilla Bug 230262 : Review Request: jss - Java Security Services (JSS) Thank you for your time and understanding. From wtogami at redhat.com Thu May 10 03:16:27 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 May 2007 23:16:27 -0400 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <4642729C.1010105@math.unl.edu> References: <4642729C.1010105@math.unl.edu> Message-ID: <46428E8B.5070103@redhat.com> Rex Dieter wrote: > FYI, (originally posted to fab-list) > > reviewer(s) kindly requested. > > -- Rex > > --------------- Forwarded message (begin) > > Subject: Status of JSS in Fedora? > From: Margaret Lum > Date: Wed, 09 May 2007 19:51:02 -0500 > > Hi folks, > > I've noticed this package has been collecting dust for awhile. My team > needs this in our first open source release of our product (Certificate > System), and I'm working on a parallel port (from internal source) to > the build system here @RH. If this is not the most productive forum for > such approval, please point me in the right direction. This package was > already submitted, but it's almost 2 months past the initial file date. > > The issue that needs both resolution and an immediate updated status is: > > > Bugzilla Bug 230262 > : Review > Request: jss - Java Security Services (JSS) > > Thank you for your time and understanding. > As discussed in the past on fedora-extras-list and other mediums, it may be impossible to ship this in Fedora or RHEL signed because that is in conflict with our licenses and guarantees of reproducibility. https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html This idea was the closest even vaguely plausible way to get it into Fedora... however it seems to be both technically impossible and not good enough to bring it into compliance with our rules. Unless somebody else has a new idea, I don't know how we can proceed on this. Red Hat (the company) could (pending legal approval) choose to proceed with this as part of an internal product. But as the rules stand today, Fedora cannot ship this signed. Warren Togami wtogami at redhat.com From david at lovesunix.net Thu May 10 03:22:25 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 10 May 2007 05:22:25 +0200 Subject: OT: Re: Pidgin Icons gone In-Reply-To: <883cfe6d0705011719k76a6a184wa217f255182d43bb@mail.gmail.com> References: <6bb886180704191918l2d5262c9jed01b2d6ce9339ec@mail.gmail.com> <1177065405.25513.70.camel@vader.jdub.homelinux.org> <1177852886.4390.28.camel@localhost.localdomain> <1177944840.19526.2.camel@localhost.localdomain> <46360BCB.3080901@fedoraproject.org> <1177953143.3026.39.camel@zod.rchland.ibm.com> <883cfe6d0705011719k76a6a184wa217f255182d43bb@mail.gmail.com> Message-ID: <1178767345.13329.0.camel@dawkins> tir, 01 05 2007 kl. 20:19 -0400, skrev Michel Salim: > > Hmm, guess I'm one of the few that actually prefer them to the > original icons? It's really nice that the icons are the same > regardless of which protocol a contact is on. And the icon theme > blends quite well with the Tango iconset (I made sure I have as little > of OpenOffice installed as possible, since there are no Tango icons > for them yet, and the upstream icons are .. uh. Absolutely not, the new icons are very Gossip like, I love them. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mlum at redhat.com Thu May 10 03:28:39 2007 From: mlum at redhat.com (Margaret Lum) Date: Wed, 09 May 2007 20:28:39 -0700 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <46428E8B.5070103@redhat.com> References: <4642729C.1010105@math.unl.edu> <46428E8B.5070103@redhat.com> Message-ID: <46429167.4010403@redhat.com> Warren Togami wrote: > Rex Dieter wrote: >> FYI, (originally posted to fab-list) >> >> reviewer(s) kindly requested. >> >> -- Rex >> >> --------------- Forwarded message (begin) >> >> Subject: Status of JSS in Fedora? >> From: Margaret Lum >> Date: Wed, 09 May 2007 19:51:02 -0500 >> >> Hi folks, >> >> I've noticed this package has been collecting dust for awhile. My team >> needs this in our first open source release of our product (Certificate >> System), and I'm working on a parallel port (from internal source) to >> the build system here @RH. If this is not the most productive forum for >> such approval, please point me in the right direction. This package was >> already submitted, but it's almost 2 months past the initial file date. >> >> The issue that needs both resolution and an immediate updated status is: >> >> >> Bugzilla Bug 230262 >> : Review >> Request: jss - Java Security Services (JSS) >> >> Thank you for your time and understanding. >> > > As discussed in the past on fedora-extras-list and other mediums, it > may be impossible to ship this in Fedora or RHEL signed because that > is in conflict with our licenses and guarantees of reproducibility. > IIRC, there was a consensus (which perhaps others on this list can correlate) that we can forego signing this package in Fedora. However, the proprietary version will still be signed. > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00311.html > > This idea was the closest even vaguely plausible way to get it into > Fedora... however it seems to be both technically impossible and not > good enough to bring it into compliance with our rules. Unless > somebody else has a new idea, I don't know how we can proceed on this. > > Red Hat (the company) could (pending legal approval) choose to proceed > with this as part of an internal product. But as the rules stand > today, Fedora cannot ship this signed. We will ship this UNsigned, in Fedora. Can approval be re-evaluated? > > Warren Togami > wtogami at redhat.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From wtogami at redhat.com Thu May 10 03:32:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 May 2007 23:32:25 -0400 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <46429167.4010403@redhat.com> References: <4642729C.1010105@math.unl.edu> <46428E8B.5070103@redhat.com> <46429167.4010403@redhat.com> Message-ID: <46429249.3020102@redhat.com> Margaret Lum wrote: >> As discussed in the past on fedora-extras-list and other mediums, it >> may be impossible to ship this in Fedora or RHEL signed because that >> is in conflict with our licenses and guarantees of reproducibility. >> > IIRC, there was a consensus (which perhaps others on this list can > correlate) that we can forego signing this package in Fedora. However, > the proprietary version will still be signed. Right, unsigned in Fedora. Proprietary or 3rd party apps needing a signed JAR would need to provide it from a separate source. Can you confirm that it could be parallel installed without much trouble? >> >> Red Hat (the company) could (pending legal approval) choose to proceed >> with this as part of an internal product. But as the rules stand >> today, Fedora cannot ship this signed. > We will ship this UNsigned, in Fedora. Can approval be re-evaluated? Right, yes it can. Warren Togami wtogami at redhat.com From luya_tfz at thefinalzone.com Thu May 10 03:49:00 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 9 May 2007 23:49:00 -0400 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178768940.4642962c2f272@ssl.mecca.ca> Glad to hear you again. The whole community were looking for you. Welcome back. Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From jdieter at gmail.com Thu May 10 04:14:25 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 10 May 2007 07:14:25 +0300 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <20070509225823.GA27033@neu.nirvana> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> Message-ID: <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> On Thu, 2007-05-10 at 00:58 +0200, Axel Thimm wrote: > Would it be possible to have transparent configs, e.g. a canonical > folder in the repo which presto checks for existance and uses it if > available? > This is already implemented in yum-presto, but not yet in createprestorepo. The prestomd format is actually identical to the repomd format with a datatype of "deltas" for presto.xml.gz file. Yum-presto will look in repomd.xml for "deltas" if there is no prestomd.xml file available. It should be quite simple to put the small amount of code in createprestorepo that is different from createrepo back into createrepo and add a -d option to createrepo that generates presto.xml.gz and adds it to repomd.xml Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu May 10 04:20:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 10 May 2007 09:50:15 +0530 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> Message-ID: <46429D7F.8010400@fedoraproject.org> Jonathan Dieter wrote: > On Thu, 2007-05-10 at 00:58 +0200, Axel Thimm wrote: >> Would it be possible to have transparent configs, e.g. a canonical >> folder in the repo which presto checks for existance and uses it if >> available? >> > > > This is already implemented in yum-presto, but not yet in > createprestorepo. The prestomd format is actually identical to the > repomd format with a datatype of "deltas" for presto.xml.gz file. > Yum-presto will look in repomd.xml for "deltas" if there is no > prestomd.xml file available. > > It should be quite simple to put the small amount of code in > createprestorepo that is different from createrepo back into createrepo > and add a -d option to createrepo that generates presto.xml.gz and adds > it to repomd.xml You could submit a patch to do this then and get any other relevant packages reviewed, included and then request Fedora Infrastructure team to run new create repo for the Fedora devel as soon as we move beyond Fedora 7. I don't think letting the package connect to a different repo by default is desirable. That doesn't scale. Rahul From fedora at drussell.dnsalias.com Thu May 10 05:17:07 2007 From: fedora at drussell.dnsalias.com (Don Russell) Date: Wed, 09 May 2007 22:17:07 -0700 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <4642AAD3.2050004@drussell.dnsalias.com> Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. > > Yours Faithfully, > Ignacio Vazquez-Abrams If you need to ease back in to it slowly, you could pick up mgetty and have a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232522 I have a 1 line fix for the code, but I don't know how to do all the package maintaining stuff. Welcome back :-) From rc040203 at freenet.de Thu May 10 06:04:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 May 2007 08:04:54 +0200 Subject: Packaging quality, assistance. In-Reply-To: <1178731543.3086.45.camel@zod.rchland.ibm.com> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> <1178731543.3086.45.camel@zod.rchland.ibm.com> Message-ID: <1178777097.7713.50.camel@mccallum.corsepiu.local> On Wed, 2007-05-09 at 12:25 -0500, Josh Boyer wrote: > On Wed, 2007-05-09 at 18:52 +0200, Ralf Corsepius wrote: > > > > Wrt. "collaboration with RH" and "unifying Core and Extra"s on packaging > > > > work actually nothing much has happened. Packages which have been under > > > > RH control still are under RH control and what had been under "community > > > > maintenance" still also is. > > I have not complained about nobody having done anything on this (IMO: > > unusable flagged review stuff causing the bugzilla list to be flooded, > > I did not complain about the web-pages going on and off almost daily. > > Um... wtf does that have to do with Red Hat and/or the Core/Extras > merge? I and others had initially asked and complained. Yet, the implementor (@RH) continued ignoring all concerns and complaints. Now reviewer are being confronted with the mess he has caused (The flagged crap ca. doubled the list traffic and made review close to unreadable). > > I did not complain about plague suddenly going offline for devel and > > being replaced with something largely undocumented called koji. > > Do you have difficulties with koji or ..? Yes, I had. Publicly visible symptoms were me upgrading packages for FC < 7 but not doing so for FC7. ATM you are seeing broken EVRs. I wasted several hours spread over several days on it, because * the koji package doesn't ship with any usable docs, and a google search did not return much useful info either. * at some point the buildserver did not respond, * when it finally responded (a few days later) it referred to an invalid URL. * when this URL finally was valid (yet another day later), it didn't contain useful information. * when this URL contained some useful info (yet several hours later, some time earlier this week), koji started to work. > Seriously, if there are > issues here they can be addressed. Do you want me to bugzilla PR's? > > I did not complain about all @RH's missing at the FPC meeting yesterday > > because (as it had leaked through other channels) them having been at > > the "RedHat summit". > > People have day jobs... I miss FESCo meetings because of mine... should > I be kicked off of it? Other people inform their fellow committee members in advance if they know not to be able to join a meeting. To me this is a matter of fairness and politeness. > And I'm pretty sure it wasn't "leaked through other channels". It did - It was Rex who mentioned it as a side-note on some mailing list (Don't recall which), which made me aware about the "Red Hat Summit". > > I did not complain about the merger "Freezing former Extras" (A > > regression in comparison to the pre-merger situation), ... > > "regression". I disagree. Extras had no structure. It had: Rolling package releases under continuous development, with "FC releases" as "snapshots". > Did it work for > the most part? Sure. But then again, there were never Extras packages > being included in ISO spins, etc. Things like this are what I'm talking > about when I say it's a two way street. Exactly. An IMO superior approach would have been to branch FC8 at the same time the DVD freeze took place and to push subsequent FC7 builts to "updates". > > Now accuse me to be impatient again ;) > > It's not your patience that irks me. It's your insistence upon _making_ > this a Red Hat versus community fight. Because I perceive it as such. Actually as a community contributor I don't see any actual improvements over the time before the merger: "Annonymous circles" drawing questionable decisions from a very RH-centric view, causing many hick-ups and disturbing irritations on the community side. > > > But > > > your claims that it's "Red Hat vs. the community" are simply not true. > > Ask yourselves: Who decides on Core packages? @RH > > Um... because Core _just_ got merged and we're in the middle of trying > to get a release out the door... RH has had many months if not years to prepare their employees for it. > > Example: The perl-packaging split, inclusion of non-free firmware > > packages, @RH's reactions on reviews, etc. > > non-free firmware went to the Board. There are non-Red Hat people on > the Board. Exactly this is the point: "I perceive RH as labeling decisions as community decisions, which have actually been taken @RH or at least in their close vicinity". Remember, none of the Fedora leadership circles represents the community. FESCo once did, but even this doesn't apply anymore. Ralf From giallu at gmail.com Thu May 10 07:11:21 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 10 May 2007 09:11:21 +0200 Subject: Python 2.4.4 FC6 SRPM In-Reply-To: <3170f42f0705091114y3096ccc5uccc2e11774f49251@mail.gmail.com> References: <3170f42f0705091114y3096ccc5uccc2e11774f49251@mail.gmail.com> Message-ID: On 5/9/07, Debarshi 'Rishi' Ray wrote: > I installed the Python 2.4.4 FC6 SRPM on my Fedora 7 test 4 system and > tried to build it using: $ rpmbuild -ba python.spec. However this > leads to an error in the %build stage. > > gcc -pthread -fPIC -fno-strict-aliasing -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 -D_GNU_SOURCE -fPIC > -I/usr/kerberos/include -I. -I./Include -I/usr/include/db4 -c > ./Modules/_bsddb.c -o Modules/_bsddb.o > ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': > ./Modules/_bsddb.c:3844: error: 'DB_ENV' has no member named 'set_lk_max' > What is wrong? API changes in the F7 db4 package? From dominik at greysector.net Thu May 10 07:37:32 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 10 May 2007 09:37:32 +0200 Subject: /etc/pki In-Reply-To: <464245E7.3010900@redhat.com> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> <1178744723.2824.248.camel@pmac.infradead.org> <464245E7.3010900@redhat.com> Message-ID: <20070510073732.GA29472@ryvius.pekin.waw.pl> On Thursday, 10 May 2007 at 00:06, Kristian H?gsberg wrote: > David Woodhouse wrote: [...] > Let's look at the words that you did put in your reply, then: > > > Please don't pollute public mailing lists with this nonsense -- keep > > your .sig to 4 lines at a maximum. > > > > If you must put the above information in every email you send, at least > > put it in a header, not the body of the mail -- and you certainly don't > > need to include the full list of directors. > > > > You're welcome to an account @infradead.org if your employer imposes > > moronic policies on public-facing mail, btw. :) > > I'm sure you have the best intentions, but the wording here is insulting. > Do you not agree that calling somebody's email 'pollution' is insulting? He didn't do that. He said that the overly long signature was 'pollution'. I, too, am tired of too long sigs. > That calling somebody's signature 'nonsense' is insulting? Not if it really is. > Calling somebody's employer 'moronic'? Now, come on. He didn't do that. He said that the policy (if there is such) is moronic. That's far from calling the employer 'moronic'. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jnovy at redhat.com Thu May 10 08:42:58 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 10 May 2007 10:42:58 +0200 Subject: Python 2.4.4 FC6 SRPM In-Reply-To: References: <3170f42f0705091114y3096ccc5uccc2e11774f49251@mail.gmail.com> Message-ID: <1178786578.3138.4.camel@dhcp-lab-186.brq.redhat.com> On Thu, 2007-05-10 at 09:11 +0200, Gianluca Sforna wrote: > On 5/9/07, Debarshi 'Rishi' Ray wrote: > > I installed the Python 2.4.4 FC6 SRPM on my Fedora 7 test 4 system and > > tried to build it using: $ rpmbuild -ba python.spec. However this > > leads to an error in the %build stage. > > > > gcc -pthread -fPIC -fno-strict-aliasing -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 -D_GNU_SOURCE -fPIC > > -I/usr/kerberos/include -I. -I./Include -I/usr/include/db4 -c > > ./Modules/_bsddb.c -o Modules/_bsddb.o > > ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': > > ./Modules/_bsddb.c:3844: error: 'DB_ENV' has no member named 'set_lk_max' > > > > What is wrong? > > API changes in the F7 db4 package? Yes, set_lk_max is now deprecated in 4.5.20 and set_lk_max_locks, set_lk_max_lockers and set_lk_max_objects should be used instead: http://pybsddb.sourceforge.net/api_c/env_set_lk_max.html and here's a code snippet how to do that: http://archives.free.net.ph/message/20070419.041636.7d21bfad.en.html Jindrich From dwmw2 at infradead.org Thu May 10 09:40:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 10 May 2007 10:40:42 +0100 Subject: /etc/pki In-Reply-To: <1178744723.2824.248.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> <1178744723.2824.248.camel@pmac.infradead.org> Message-ID: <1178790042.28494.34.camel@pmac.infradead.org> On Wed, 2007-05-09 at 22:05 +0100, David Woodhouse wrote: > I called a _policy_ moronic. > That's almost an oxymoron, in my book -- since 'policy' is so often just > a euphemism for not actually having to think. Speaking of moronic, I obviously mean _tautology_, not oxymoron, in the above. Basic command of the English language seems to be failing me this week; I blame it on the amount of time staring at ML code, trying to persuade it to emit valid ppc64 assembly. By way of a little light relief, I think I'll go poke at getting kexec to work on the PlayStation today instead... -- dwmw2 From alan at redhat.com Thu May 10 10:10:25 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 10 May 2007 06:10:25 -0400 Subject: /etc/pki In-Reply-To: <200705100226.29719.opensource@till.name> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> <200705100226.29719.opensource@till.name> Message-ID: <20070510101025.GA6871@devserv.devel.redhat.com> On Thu, May 10, 2007 at 02:26:28AM +0200, Till Maas wrote: > Are you sure about this? IANAL, but in Germany (maybe it is EU law) one has to > include this kind of information[1] in (some)[2] business letters (including > e-mail)[3]. And normally including it in the header is at least a grey > zone[4] and still can cause a lot of trouble to a company, because The actual standards for email says the Organisation goes in the header. If you are not doing so then you are not following the standard and you are concealing your information at the bottom in a footer (which for a very long mail may well be hidden and missed).... Alan From jwboyer at jdub.homelinux.org Thu May 10 10:52:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 10 May 2007 05:52:16 -0500 Subject: Packaging quality, assistance. In-Reply-To: <1178777097.7713.50.camel@mccallum.corsepiu.local> References: <1178291788.2702.10.camel@vorpal.macdev.com> <4640C136.3080001@hhs.nl> <1178649619.3175.9.camel@vader.jdub.homelinux.org> <200705082140.25186.opensource@till.name> <1178654305.3175.28.camel@vader.jdub.homelinux.org> <3170f42f0705081317t28385d6o3d5ec1d74d3d92ce@mail.gmail.com> <20070508202925.GA1768@orient.maison.lan> <4640DEA7.4050403@fedoraproject.org> <3170f42f0705081340m1bbc824rf1c11e92ff80feb1@mail.gmail.com> <20070508204517.GA1959@orient.maison.lan> <3170f42f0705081355i702cc39bt18da5ff8890634e7@mail.gmail.com> <1178657658.3175.57.camel@vader.jdub.homelinux.org> <46415696.6050804@leemhuis.info> <1178712743.2824.152.camel@pmac.infradead.org> <52223.192.54.193.51.1178722251.squirrel@rousalka.dyndns.org> <1178722115.3086.18.camel@zod.rchland.ibm.com> <1178727082.3504.297.camel@mccallum.corsepiu.local> <1178728087.3086.26.camel@zod.rchland.ibm.com> <1178729570.3504.313.camel@mccallum.corsepiu.local> <1178731543.3086.45.camel@zod.rchland.ibm.com> <1178777097.7713.50.camel@mccallum.corsepiu.local> Message-ID: <1178794336.11271.17.camel@vader.jdub.homelinux.org> On Thu, 2007-05-10 at 08:04 +0200, Ralf Corsepius wrote: > > > I have not complained about nobody having done anything on this (IMO: > > > unusable flagged review stuff causing the bugzilla list to be flooded, > > > I did not complain about the web-pages going on and off almost daily. > > > > Um... wtf does that have to do with Red Hat and/or the Core/Extras > > merge? > > I and others had initially asked and complained. Yet, the implementor > (@RH) continued ignoring all concerns and complaints. Now reviewer are > being confronted with the mess he has caused (The flagged crap ca. > doubled the list traffic and made review close to unreadable). Bad quoting on my part. I was asking about the web-pages thing. It's really immaterial to the rest of the conversation though. > > > I did not complain about plague suddenly going offline for devel and > > > being replaced with something largely undocumented called koji. > > > > Do you have difficulties with koji or ..? > Yes, I had. > > Publicly visible symptoms were me upgrading packages for FC < 7 but not > doing so for FC7. ATM you are seeing broken EVRs. > > I wasted several hours spread over several days on it, because > * the koji package doesn't ship with any usable docs, and a google > search did not return much useful info either. What kind are you looking for? Docs for what exactly? > * at some point the buildserver did not respond, > * when it finally responded (a few days later) it referred to an invalid > URL. > * when this URL finally was valid (yet another day later), it didn't > contain useful information. > * when this URL contained some useful info (yet several hours later, > some time earlier this week), koji started to work. Without a timeline I'm not sure I can help diagnose what happened for you there. I didn't experience those difficulties. > > Seriously, if there are > > issues here they can be addressed. > Do you want me to bugzilla PR's? Tickets here: https://admin.fedoraproject.org/tickets/ would probably be better for some of the issues you described above. > > > I did not complain about all @RH's missing at the FPC meeting yesterday > > > because (as it had leaked through other channels) them having been at > > > the "RedHat summit". > > > > People have day jobs... I miss FESCo meetings because of mine... should > > I be kicked off of it? > Other people inform their fellow committee members in advance if they > know not to be able to join a meeting. To me this is a matter of > fairness and politeness. If that wasn't done, I find it odd. It is indeed polite to do so. > > Did it work for > > the most part? Sure. But then again, there were never Extras packages > > being included in ISO spins, etc. Things like this are what I'm talking > > about when I say it's a two way street. > Exactly. An IMO superior approach would have been to branch FC8 at the > same time the DVD freeze took place and to push subsequent FC7 builts to > "updates". It's not frozen yet though. It's in a state of slush. See the emails from earlier this week about Freeze and GA slipping. > > > Now accuse me to be impatient again ;) > > > > It's not your patience that irks me. It's your insistence upon _making_ > > this a Red Hat versus community fight. > Because I perceive it as such. Actually as a community contributor I > don't see any actual improvements over the time before the merger: > "Annonymous circles" drawing questionable decisions from a very > RH-centric view, causing many hick-ups and disturbing irritations on the > community side. Your perceptions are your own. As a community member, I see the opposite. > > non-free firmware went to the Board. There are non-Red Hat people on > > the Board. > Exactly this is the point: "I perceive RH as labeling decisions as > community decisions, which have actually been taken @RH or at least in > their close vicinity". Remember, none of the Fedora leadership circles > represents the community. FESCo once did, but even this doesn't apply > anymore. How can you say that? There are elected community members in FESCo. More than half. The Board also has community members. FPC does. Are all of these community members on these committees just puppets that Red Hat controls? I very much do not think so. josh From buildsys at fedoraproject.org Thu May 10 11:39:26 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 10 May 2007 07:39:26 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-10 Message-ID: <20070510113926.56E88152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 15 asymptote-1.28-1.fc6 blender-2.42a-21.fc6 NEW boolstuff-0.1.11-1.fc6 : Disjunctive Normal Form boolean expression library espeak-1.24-1.fc6 NEW FlightGear-0.9.10-6.fc6 : The FlightGear Flight Simulator gallery2-2.2-0.3.svn20070506.fc6 gdal-1.4.1-1.fc6 gnash-0.7.2-2.fc6 NEW perl-Class-C3-XS-0.03-2.fc6 : XS speedups for Class::C3 perl-JSON-1.13-1.fc6 php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc6 php-pear-Net-Socket-1.0.8-1.fc6 NEW pmount-0.9.13-1.fc6 : Enable normal user mount NEW pygoocanvas-0.6.0-2.fc6 : GooCanvas python bindings rosegarden4-1.5.1-1.fc6 Packages built and released for Fedora Extras 5: 11 asymptote-1.28-1.fc5 blender-2.42a-21.fc5 espeak-1.24-1.fc5 funtools-1.3.0-0.5.b33.fc5 gallery2-2.2-0.3.svn20070506.fc5 gnash-0.7.2-2.fc5 perl-CGI-Ex-2.11-1.fc5 NEW perl-Class-C3-XS-0.03-2.fc5 : XS speedups for Class::C3 perl-JSON-1.13-1.fc5 php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc5 php-pear-Net-Socket-1.0.8-1.fc5 Changes in Fedora Extras 6: asymptote-1.28-1.fc6 -------------------- * Tue May 08 2007 Jose Pedro Oliveira - 1.28-1 - Update to 1.28. * Sat May 05 2007 Jose Pedro Oliveira - 1.27-1 - Update to 1.27. blender-2.42a-21.fc6 -------------------- * Mon May 07 2007 Jochen Schmitt 2.42a-21 - Fix security issue (#239338) * Sun Apr 22 2007 Jochen Schmitt 2.42a-20 - Remove the package from the x86_64 arch (#237423) boolstuff-0.1.11-1.fc6 ---------------------- * Sun May 06 2007 Patrice Dumas 0.1.11-1 - update to 0.1.11 - use a directory for in-source docs espeak-1.24-1.fc6 ----------------- * Tue May 08 2007 Francois Aucamp - 1.24-1 - Update to version 1.24 FlightGear-0.9.10-6.fc6 ----------------------- * Wed Apr 18 2007 Fabrice Bellet 0.9.10-6 - desktop-database update - add icons from Josh Babcock * Mon Apr 16 2007 Fabrice Bellet 0.9.10-5 - doc files cleanup - remove -fPIC from CXXFLAGS - add a desktop file (but no dedicated icon is available) - spec file cleanup gallery2-2.2-0.3.svn20070506.fc6 -------------------------------- * Wed May 09 2007 John Berninger - 2.2-0.3.svn20070506 - Mark the config.php symlink as a config file so that the config.php from 2.1 installs doesn't get overwritten. Yes, I did a Bad Thing. gdal-1.4.1-1.fc6 ---------------- * Wed May 09 2007 Balint Cristian 1.4.1-1 - new upstream release. - disable temporary grass-devel requirement untill find a resonable solution for gdal-grass egg-chicken dep problem. * Fri Apr 20 2007 Balint Cristian 1.4.0-22 - and olso dont attempt pack missing docs. * Fri Apr 20 2007 Balint Cristian 1.4.0-21 - exclude some docs, doxygen segfault with those now upstream. * Fri Apr 20 2007 Balint Cristian 1.4.0-20 - rebuild against latest fedora upstream tree. gnash-0.7.2-2.fc6 ----------------- * Wed May 09 2007 Patrice Dumas 0.7.2-2 - fix CVE-2007-2500 (fix 239213) perl-Class-C3-XS-0.03-2.fc6 --------------------------- * Wed May 09 2007 Chris Weyl 0.03-2 - bump * Wed May 09 2007 Chris Weyl 0.03-1 - update to 0.03 * Fri May 04 2007 Chris Weyl 0.02-1 - Specfile autogenerated by cpanspec 1.71. perl-JSON-1.13-1.fc6 -------------------- * Wed May 09 2007 Chris Weyl 1.13-1 - update to 1.13 * Fri May 04 2007 Chris Weyl 1.12-1 - update to 1.12 - add t/ to %doc php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc6 ----------------------------------------------- * Tue May 08 2007 Christohper Stone 0.1.1-1 - Upstream sync php-pear-Net-Socket-1.0.8-1.fc6 ------------------------------- * Tue May 08 2007 Remi Collet 1.0.8-1 - update to 1.0.8 pmount-0.9.13-1.fc6 ------------------- * Sun Sep 24 2006 Patrice Dumas 0.9.13-1 - initial packaging pygoocanvas-0.6.0-2.fc6 ----------------------- * Fri May 04 2007 Bernard Johnson - 0.6.0-2 - enable docbook build rosegarden4-1.5.1-1.fc6 ----------------------- * Wed May 02 2007 Callum Lerwick - 1.5.1-1 - New upstream version. * Tue Feb 13 2007 Callum Lerwick - 1.5.0-1 - New upstream version. Changes in Fedora Extras 5: asymptote-1.28-1.fc5 -------------------- * Tue May 08 2007 Jose Pedro Oliveira - 1.28-1 - Update to 1.28. * Sat May 05 2007 Jose Pedro Oliveira - 1.27-1 - Update to 1.27. * Wed Apr 25 2007 Jose Pedro Oliveira - 1.26-1 - Update to 1.26. blender-2.42a-21.fc5 -------------------- * Mon May 07 2007 Jochen Schmitt 2.42a-21 - Fix security issue (#239338) * Sun Apr 22 2007 Jochen Schmitt 2.42a-20 - Remove the package from the x86_64 arch (#237423) espeak-1.24-1.fc5 ----------------- * Tue May 08 2007 Francois Aucamp - 1.24-1 - Update to version 1.24 funtools-1.3.0-0.5.b33.fc5 -------------------------- * Thu May 03 2007 Sergio Pascual 1.3.0-0.5.b33 - New upstream version gallery2-2.2-0.3.svn20070506.fc5 -------------------------------- * Wed May 09 2007 John Berninger - 2.2-0.3.svn20070506 - Mark the config.php symlink as a config file so that the config.php from 2.1 installs doesn't get overwritten. Yes, I did a Bad Thing. * Mon May 07 2007 John Berninger - 2.2-0.2.svn20070506 - Requires PHP 4.3.0, not 4.1.0 - Add statement of support for DB2, MS SQL server - Don't hardcode /srv/gallery2 in install section, use the g2datadir variable - Up PHP memory chunk to 24M - Known issue - downloading modules and themes from within Gallery will not work with G2 being in /usr/share - esp if /usr is read-only. Would need exception to Fedora packaging guidelines to enable this feature * Sun May 06 2007 John Berninger - 2.2-0.1.svn20070506 - Switch to upstream ver 2.2 base - Add digibug, dynamicalbum, ecard, flashvideo, httpauth, itemadd, keyalbum, mp3audio, multiroot, replica, webdav modules - Add ajaxian, carbon themes - Refactor login.txt and config.php references, update readme for same gnash-0.7.2-2.fc5 ----------------- * Wed May 09 2007 Patrice Dumas 0.7.2-2 - fix CVE-2007-2500 (fix 239213) perl-CGI-Ex-2.11-1.fc5 ---------------------- * Wed May 09 2007 Chris Weyl 2.11-1 - update to 2.11 - add split br's perl-Class-C3-XS-0.03-2.fc5 --------------------------- * Wed May 09 2007 Chris Weyl 0.03-2 - bump * Wed May 09 2007 Chris Weyl 0.03-1 - update to 0.03 * Fri May 04 2007 Chris Weyl 0.02-1 - Specfile autogenerated by cpanspec 1.71. perl-JSON-1.13-1.fc5 -------------------- * Wed May 09 2007 Chris Weyl 1.13-1 - update to 1.13 * Fri May 04 2007 Chris Weyl 1.12-1 - update to 1.12 - add t/ to %doc php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc5 ----------------------------------------------- * Tue May 08 2007 Christohper Stone 0.1.1-1 - Upstream sync php-pear-Net-Socket-1.0.8-1.fc5 ------------------------------- * Tue May 08 2007 Remi Collet 1.0.8-1 - update to 1.0.8 * Sat Mar 31 2007 Remi Collet 1.0.7-1 - remove PEAR from sumnary - update to 1.0.7 - spec cleanup - add generated CHANGELOG For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From alan at redhat.com Thu May 10 13:03:24 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 10 May 2007 09:03:24 -0400 Subject: /etc/pki In-Reply-To: <464245E7.3010900@redhat.com> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> <1178744723.2824.248.camel@pmac.infradead.org> <464245E7.3010900@redhat.com> Message-ID: <20070510130324.GA16667@devserv.devel.redhat.com> On Wed, May 09, 2007 at 06:06:31PM -0400, Kristian H?gsberg wrote: > This is not about enforcing political correctness. It's about not > insulting random people over petty details in a community that's supposed > to be friendly and constructive. Its hard to insult inaninmate objects like signatures. They generally don't seem to have feelings. I see nothing insulting the poster or blaming the poster at all. From kmacmill at redhat.com Thu May 10 13:27:50 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 10 May 2007 09:27:50 -0400 Subject: Making Fedora a contributer friendly environment In-Reply-To: <464200C4.3000400@city-fan.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091555.57932.opensource@till.name> <1178720326.2379.42.camel@localhost.localdomain> <200705091725.58679.opensource@till.name> <645d17210705090935h5e07b075y21cb5f9feb3563ae@mail.gmail.com> <464200C4.3000400@city-fan.org> Message-ID: <1178803670.17816.19.camel@localhost.localdomain> On Wed, 2007-05-09 at 18:11 +0100, Paul Howarth wrote: > Jonathan Underwood wrote: > > On 09/05/07, Till Maas wrote: > > [snip] > >> There are some drafts in: > >> http://fedoraproject.org/wiki/PackagingDrafts/SELinux > > [snip] > > > > I have been following this discussion a bit, and have read those draft > > packaging guidelines, and find myself as a packager rather confused. > > > > That draft details how to add support for SElinux to your package. > > But, what isn't clear to me is what the policy is for SElinux support > > more globally. Recently I've filed a few bugs against packages that > > have had problems with SElinux contexts and in each case the packager > > has re-assigned the bugs to the SElinux team, who have fixed the issue > > in an updated SElinux policy package. > > > > This would imply that the policy package is where things should be > > fixed, SElinux wise. But now that draft leaves me wondering if that is > > incorrect. > > > > Sooo.. where should SElinux contexts be set, in each package, or in > > the SElinux policy package? > > > > [Sorry if this is a dumb question] > > There isn't a single correct answer for that one. > > If the program's behaviour is causing SELinux issues (unnecessary > relocations, leaked file descriptors etc.) then the program should be fixed. > > If file contexts need setting, the best place to do it is in the main > policy package. This is common with web applications for instance. > Right - so for very simple changes (like setting a file context as unconfined_execmem_t) filing a bug against the policy package with the binary path is likely enough. > There are also more complex cases such as daemons for which no policy > currently exists. This may require the writing of policy for the daemon, > including the introduction of new file context types. This is probably > best done by writing and packaging a policy module (see also > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules) > and, when the resulting policy appears stable, to get that policy merged > into the upstream reference policy. > Just to be clear - it is desirable to have specific policy for applications (particularly network facing daemons) but it is not required. Almost all applications should just work with SELinux with the targeted policy. If you are having problems just drop a not to the fedora-selinux list or file a bug against policy. Karl From krh at redhat.com Thu May 10 13:35:55 2007 From: krh at redhat.com (=?ISO-8859-1?Q?Kristian_H=F8gsberg?=) Date: Thu, 10 May 2007 09:35:55 -0400 Subject: /etc/pki In-Reply-To: <20070510130324.GA16667@devserv.devel.redhat.com> References: <4641F669.4040206@redhat.com> <200705091106.12012.jkeating@redhat.com> <1178740044.2824.229.camel@pmac.infradead.org> <200705091351.43232.jkeating@redhat.com> <1178744723.2824.248.camel@pmac.infradead.org> <464245E7.3010900@redhat.com> <20070510130324.GA16667@devserv.devel.redhat.com> Message-ID: <46431FBB.4040806@redhat.com> Alan Cox wrote: > On Wed, May 09, 2007 at 06:06:31PM -0400, Kristian H?gsberg wrote: >> This is not about enforcing political correctness. It's about not >> insulting random people over petty details in a community that's supposed >> to be friendly and constructive. > > Its hard to insult inaninmate objects like signatures. They generally don't > seem to have feelings. > > I see nothing insulting the poster or blaming the poster at all. This is a bit too naiive. Don't you think calling a company policy 'moronic' reflects on the company that implements it? If you call a signature that somebody sat down and wrote and decided to put in his email 'nonsense', doesn't that reflect on that person? And in any case, there's no need to use loaded words such as 'moronic' and 'nonsense', when replying to a person that's writing the list for the first time to ask a question. You can get the message across without resorting to intimidation. Kristian From jorton at redhat.com Thu May 10 13:49:45 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 10 May 2007 14:49:45 +0100 Subject: /etc/pki In-Reply-To: <4641F669.4040206@redhat.com> References: <4641F669.4040206@redhat.com> Message-ID: <20070510134945.GA24910@redhat.com> [warning: this e-mail is on-topic] On Wed, May 09, 2007 at 05:27:21PM +0100, Richard W.M. Jones wrote: > Is there a Fedora standard for what goes in /etc/pki? No, though there problably should be :) > Or to put it another way, if I were writing an application and I put its > PKI files in /etc/pki//... would that be OK? > > Particular files that the application needs to store: > > * self-generated CA certificate and associated files such as revocation > list, issued certs, CA's private key > * list of client certs of clients allowed to access (on server) > * machine's own private key and certificate (client & server) I'd vaguely prefer to see these in /etc/pki/tls/appname if it's all TLS specific. Out of interest, is the PKI use for the app in question something which must be strictly private to the app? Can you give some details of what you're actually doing? (I've been thinking of writing some simple scripts/tools to create system-wide default CA, hostname or service-specific signed certs, etc. At the moment we have a bunch of daemons which have %post scripts to create self-signed certs, it's all a bit disorganised and redundant.) joe From kmacmill at redhat.com Thu May 10 13:55:05 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 10 May 2007 09:55:05 -0400 Subject: Making Fedora a contributer friendly environment In-Reply-To: <200705091725.58679.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091555.57932.opensource@till.name> <1178720326.2379.42.camel@localhost.localdomain> <200705091725.58679.opensource@till.name> Message-ID: <1178805305.17816.29.camel@localhost.localdomain> On Wed, 2007-05-09 at 17:25 +0200, Till Maas wrote: > On Mi Mai 9 2007, Karl MacMillan wrote: > > > It's not and for applications like this you aren't likely to avoid > > executing writable memory. You should set the context correctly to allow > > executable memory (chcon -t unconfined_execmem_exec_t). Eventually we > > should avoid hard-coding contexts in the rpms but there is currently no > > better solution. > > There are some drafts in: > http://fedoraproject.org/wiki/PackagingDrafts/SELinux > > Which at least make these changes persistent. Persistent is not quite right - using semanage (or a policy module) makes the changes survive a full relabel of the system. A chcon is persistent (across reboots and such) until the context is explicitly changed. > As far as I understand selinux, > when someone disables it, all the contexts that were created in %post with > chcon are lost. Not quite - disabling doesn't lose any contexts. The problem is that during the normal course of running the system some file labels are changed or files are created without a label. When selinux is turned on again a full relabel of the filesystem is done to correct these problems. If the custom file context wasn't added to the database of file contexts (via a module or semanage) the file is set to the default label. > Also I am not sure, whether or not they get lost, after an > policy-update, but I think I saw this happen once. The method descibed in the > PackagingDraft which I followed with the following files: > > VirtualBox-OSE.te > policy_module(VirtualBox-OSE, 1.0.0) > > VirtualBox-OSE.fc > @VBOXINSTDIR@/.*\.so -- gen_context(system_u:object_r:textrel_shlib_t,s0) > > and the scriptlets there, at least works, but it is imho much to complicated. This is only needed if you have a policy for that application. Just to change a file context it seems unnecessary. Semanage should be workable. > And when using semanage it is afaik impossible to change a > selinux-configuration or remove it, because of the ordering > of %post(un) %pre(un). > Not sure what you mean - you should be able to run semanage in a post. Perhaps you should also need to do chcon (as opposed to restorecon) because the command may not have run before the file was created. > In conlusion, there should first be some methods and (better (documented)) rpm > support, before demanding that all packages should support selinux. E.g. what > does "%policy" in "%files" do? > I agree that those packaging guidelines should be reviewed, improved where necessary, and adopted. However, most packages do not need any special selinux support. Paul / Dan - how should we proceed with those guidelines. Karl > Regards, > Till > > From debarshi.ray at gmail.com Thu May 10 14:02:33 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 10 May 2007 19:32:33 +0530 Subject: compat-python for Fedora 7 Message-ID: <3170f42f0705100702w43137d74g2c761e0f5d2760e7@mail.gmail.com> Hi Jonathan, I have been trying to make a compatibility Python 2.4 package for Fedora 7. I have based it on the Python 2.4 package for Fedora Core 6, but have removed certain parts of the SPEC file since the python-2.4 FC6 SRPM was not building as it is on a Fedora 7 test 4 system. I am new to packaging and it is taking me some time to learn the tricks of the trade and figure exactly which portions of the older package need to be modified to fix the building problems. For the time being you can have a look at the SPEC file and the SRPM at the following links: http://glug-nith.org/~rishi/download/src/compat-python.spec http://glug-nith.org/~rishi/download/src/compat-python-2.4.4-1.fc7.src.rpm Hope you find it useful. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Thu May 10 14:02:33 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 10 May 2007 19:32:33 +0530 Subject: compat-python for Fedora 7 Message-ID: <3170f42f0705100702w43137d74g2c761e0f5d2760e7@mail.gmail.com> Hi Jonathan, I have been trying to make a compatibility Python 2.4 package for Fedora 7. I have based it on the Python 2.4 package for Fedora Core 6, but have removed certain parts of the SPEC file since the python-2.4 FC6 SRPM was not building as it is on a Fedora 7 test 4 system. I am new to packaging and it is taking me some time to learn the tricks of the trade and figure exactly which portions of the older package need to be modified to fix the building problems. For the time being you can have a look at the SPEC file and the SRPM at the following links: http://glug-nith.org/~rishi/download/src/compat-python.spec http://glug-nith.org/~rishi/download/src/compat-python-2.4.4-1.fc7.src.rpm Hope you find it useful. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From alexl at redhat.com Thu May 10 14:42:40 2007 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 10 May 2007 16:42:40 +0200 Subject: (co)maintainers wanted Message-ID: <1178808160.3068.26.camel@greebo> I'm spending a lot of time on upstream development and some of the core desktop packages, but I also own a bunch of other ex-core packages that I really don't have much time for. I'm looking at getting new maintainers or comaintainers for interested people. First some random packages i've ended up with that I rather not own at all, since I don't really know much about them: * lcms * gmime Then there is a bunch of mono libraries from when I did the initial mono work: * gtk-sharp2 * gnome-sharp * gsf-sharp Do we have any people using mono that want to take over these, or to help me comaintain them. The work for these are mostly version upgrades now that they have been packaged, but its would be nice if someone who uses them a bit could be involved. Then we have beagle: * beagle This generates a bit more work than the libraries, and as such its important to have a active set of maintainers. Since it also touches some of the desktop parts i own (Gnome file handling) i'd like to be comaintainer here rather than totally loose it. There is also mono itself: * mono * libgdiplus It would be interesting if we could get some of the upstream mono developers helping out on this. Do we have any mono developers in the fedora community? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a bookish guerilla paramedic in a wheelchair. She's a plucky wisecracking lawyer operating on the wrong side of the law. They fight crime! From opensource at till.name Thu May 10 14:50:48 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 16:50:48 +0200 Subject: Making Fedora a contributer friendly environment In-Reply-To: <1178805305.17816.29.camel@localhost.localdomain> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091725.58679.opensource@till.name> <1178805305.17816.29.camel@localhost.localdomain> Message-ID: <200705101650.50233.opensource@till.name> On Do Mai 10 2007, Karl MacMillan wrote: > When selinux is turned on again a full relabel of the filesystem is done > to correct these problems. If the custom file context wasn't added to > the database of file contexts (via a module or semanage) the file is set > to the default label. So will chcon in a scriptlet work, when an rpm is installed while selinux is not active? > Not sure what you mean - you should be able to run semanage in a post. > Perhaps you should also need to do chcon (as opposed to restorecon) > because the command may not have run before the file was created. When I tested semanage, the problem occured, how to update the labels with semanage. E.g. when the regex is changed that desribes, which files should be labeled in a certain way. And when one wants to remove the old labels when uninstalling the package. E.g version 1 of the package: %post semanage add RULE1 %postun semanage remove RULE1 As far as I understand rpm, when updating the release of version 1, first semanage add RULE1 from release two runs from %post and then semanage remove RULE1 from release one. This effectivly removes the rule from the /etc/selinux, because identical rules seem not be added more than once to /etc/selinux. When I restrict the %postun only to complete removals of the package, than when one changes the RULES, e.g. in a version 2: %post semanage add RULE2 %postun semanage remove RULE2 then RULE1 will not be removed (it is not the final remove). Then every release has to include "semanage remove RULE1" in "%post" maybe forever. I hope you understand the problem I try to describe, because I did not really use the correct selinux-terms. I would be happy, if I am wrong with this. But if this problem is not solvable with semanage, imho semanage is not a good way to add selinux support to a package. Regards, Till From kevin.kofler at chello.at Thu May 10 15:05:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 May 2007 15:05:38 +0000 (UTC) Subject: (co)maintainers wanted References: <1178808160.3068.26.camel@greebo> Message-ID: Alexander Larsson redhat.com> writes: > First some random packages i've ended up with that I rather not own at > all, since I don't really know much about them: Those 2 used to be in Extras, then got moved to Core due to Mono: > * lcms The last Extras maintainer for lcms was Andreas Bierfert. Andreas, do you want lcms back? > * gmime The last Extras maintainer for gmime was Thorsten Leemhuis. Thorsten, do you want gmime back? Kevin Kofler From kwizart at gmail.com Thu May 10 15:20:51 2007 From: kwizart at gmail.com (KH KH) Date: Thu, 10 May 2007 17:20:51 +0200 Subject: (co)maintainers wanted In-Reply-To: References: <1178808160.3068.26.camel@greebo> Message-ID: 2007/5/10, Kevin Kofler : > > Alexander Larsson redhat.com> writes: > > First some random packages i've ended up with that I rather not own at > > all, since I don't really know much about them: > > Those 2 used to be in Extras, then got moved to Core due to Mono: > > > * lcms I have a bug pending about updating lcms for cinepaint 0.22 ( currently in review...) As such i'm interested in co-maintainership... Nicolas (kwizart) -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Thu May 10 15:22:48 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 10 May 2007 17:22:48 +0200 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <464338C8.7090305@gmail.com> Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > welcome back ;) From orion at cora.nwra.com Thu May 10 15:28:24 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 10 May 2007 09:28:24 -0600 Subject: CVS server load? Message-ID: <46433A18.6030801@cora.nwra.com> Lots of timeouts and waiting for locks.... [orion at cynosure hdf]$ cvs ci cvs commit: Examining . cvs commit: Examining EL-4 cvs commit: Examining EL-5 cvs commit: Examining FC-3 cvs commit: Examining FC-4 cvs commit: Examining FC-5 cvs commit: Examining FC-6 cvs commit: Examining common cvs commit: Examining devel ? devel/make.log ? devel/make-production.log ? devel/i386 ? devel/hdf-4.2r1-12.fc7.src.rpm ? devel/HDF4.2r1.tar.gz ? devel/4.2r1-hrepack-p4 ? devel/.build-4.2r1-12.fc7.log ? FC-4/hdf-4.2r1-6.fc4.src.rpm ? EL-4/HDF4.2r1.tar.gz ? spec.patch **** Access allowed: orion is in ACL for rpms/hdf/EL-5. **** Access allowed: orion is in ACL for rpms/hdf/FC-6. **** Access allowed: orion is in ACL for rpms/hdf/devel. Checking in EL-5/hdf.spec; /cvs/pkgs/rpms/hdf/EL-5/hdf.spec,v <-- hdf.spec new revision: 1.14; previous revision: 1.13 done Traceback (most recent call last): File "/cvs/pkgs/CVSROOT/getnotifylist", line 26, in ? owners = owners.OwnerList(populate_all = 0) File "/cvs/pkgs/CVSROOT/owners.py", line 49, in __init__ self.populate_users() File "/cvs/pkgs/CVSROOT/owners.py", line 64, in populate_users f = urllib2.urlopen("http://app2.fedora.phx.redhat.com/admin/accounts/dump-group.cgi?group=cla_done&format=plain") File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib64/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/lib64/python2.3/urllib2.py", line 886, in do_open raise URLError(err) urllib2.URLError: Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. cvs diff: [15:18:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. Checking in FC-6/hdf.spec; /cvs/pkgs/rpms/hdf/FC-6/hdf.spec,v <-- hdf.spec new revision: 1.14; previous revision: 1.13 done cvs diff: [15:19:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:19:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:20:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:20:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:21:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:21:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 Traceback (most recent call last): File "/cvs/pkgs/CVSROOT/getnotifylist", line 26, in ? owners = owners.OwnerList(populate_all = 0) File "/cvs/pkgs/CVSROOT/owners.py", line 49, in __init__ self.populate_users() File "/cvs/pkgs/CVSROOT/owners.py", line 64, in populate_users f = urllib2.urlopen("http://app2.fedora.phx.redhat.com/admin/accounts/dump-group.cgi?group=cla_done&format=plain") File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib64/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/lib64/python2.3/urllib2.py", line 886, in do_open raise URLError(err) urllib2.URLError: Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. cvs diff: [15:21:56] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. Checking in devel/hdf.spec; /cvs/pkgs/rpms/hdf/devel/hdf.spec,v <-- hdf.spec new revision: 1.14; previous revision: 1.13 done cvs diff: [15:22:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:22:26] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:22:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:22:56] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:23:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:23:26] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:23:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:23:56] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:24:16] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:24:26] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:24:46] waiting for orion's lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:24:56] waiting for orion's lock in /cvs/pkgs/rpms/hdf/FC-6 Traceback (most recent call last): File "/cvs/pkgs/CVSROOT/getnotifylist", line 26, in ? owners = owners.OwnerList(populate_all = 0) File "/cvs/pkgs/CVSROOT/owners.py", line 49, in __init__ self.populate_users() File "/cvs/pkgs/CVSROOT/owners.py", line 64, in populate_users f = urllib2.urlopen("http://app2.fedora.phx.redhat.com/admin/accounts/dump-group.cgi?group=cla_done&format=plain") File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib64/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/lib64/python2.3/urllib2.py", line 886, in do_open raise URLError(err) urllib2.URLError: Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. cvs diff: [15:25:05] waiting for orion's lock in /cvs/pkgs/rpms/hdf/devel Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. cvs diff: [15:25:16] obtained lock in /cvs/pkgs/rpms/hdf/EL-5 cvs diff: [15:25:26] obtained lock in /cvs/pkgs/rpms/hdf/FC-6 cvs diff: [15:25:35] obtained lock in /cvs/pkgs/rpms/hdf/devel -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From paul at city-fan.org Thu May 10 15:33:33 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 10 May 2007 16:33:33 +0100 Subject: Making Fedora a contributer friendly environment In-Reply-To: <200705101650.50233.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091725.58679.opensource@till.name> <1178805305.17816.29.camel@localhost.localdomain> <200705101650.50233.opensource@till.name> Message-ID: <46433B4D.1050304@city-fan.org> Till Maas wrote: > On Do Mai 10 2007, Karl MacMillan wrote: > >> When selinux is turned on again a full relabel of the filesystem is done >> to correct these problems. If the custom file context wasn't added to >> the database of file contexts (via a module or semanage) the file is set >> to the default label. > > So will chcon in a scriptlet work, when an rpm is installed while selinux is > not active? > >> Not sure what you mean - you should be able to run semanage in a post. >> Perhaps you should also need to do chcon (as opposed to restorecon) >> because the command may not have run before the file was created. > > When I tested semanage, the problem occured, how to update the labels with > semanage. E.g. when the regex is changed that desribes, which files should be > labeled in a certain way. And when one wants to remove the old labels when > uninstalling the package. E.g > > version 1 of the package: > > %post > semanage add RULE1 > %postun > semanage remove RULE1 > > As far as I understand rpm, when updating the release of version 1, first > semanage add RULE1 from release two runs from %post and then > semanage remove RULE1 from release one. This effectivly removes the rule from > the /etc/selinux, because identical rules seem not be added more than once > to /etc/selinux. When I restrict the %postun only to complete removals of the > package, than when one changes the RULES, e.g. in a version 2: > > %post > semanage add RULE2 > %postun > semanage remove RULE2 > > then RULE1 will not be removed (it is not the final remove). Then every > release has to include "semanage remove RULE1" in "%post" maybe forever. I > hope you understand the problem I try to describe, because I did not really > use the correct selinux-terms. > > I would be happy, if I am wrong with this. But if this problem is not solvable > with semanage, imho semanage is not a good way to add selinux support to a > package. I agree entirely, and would advocate using a policy module instead of semanage, even if all the module contains are file contexts and no rules (you may need a dummy rule that duplicates an existing one to get the module to build and install properly though). Policy modules have versioning built in and so upgrades work as expected. It's just a lot more work to package them. For simple context fixes, getting them into the main selinux-policy package is almost certainly the best and least hassle method though. Paul. From fedora at leemhuis.info Thu May 10 15:34:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 May 2007 17:34:32 +0200 Subject: gmime (co)maintainers wanted In-Reply-To: References: <1178808160.3068.26.camel@greebo> Message-ID: <46433B88.4070907@leemhuis.info> Kevin Kofler schrieb: >> * gmime > The last Extras maintainer for gmime was Thorsten Leemhuis. Thorsten, do you > want gmime back? Not really -- Iirc I just packaged it because mail-notification needed it. But well, if no one else is interested in it'll at least become official co-maintainer. Then we'll see how things evolve. CU thl From peter at thecodergeek.com Thu May 10 15:47:08 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 10 May 2007 08:47:08 -0700 (PDT) Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <2849.207.233.85.196.1178812028.squirrel@webmail.thecodergeek.com> Ignacio Vazquez-Abrams wrote: > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. *hugs* We missed you, Ignacio. Great to have you back with us! :D -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From kmacmill at redhat.com Thu May 10 15:49:20 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 10 May 2007 11:49:20 -0400 Subject: Making Fedora a contributer friendly environment In-Reply-To: <200705101650.50233.opensource@till.name> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091725.58679.opensource@till.name> <1178805305.17816.29.camel@localhost.localdomain> <200705101650.50233.opensource@till.name> Message-ID: <1178812160.24335.35.camel@localhost.localdomain> [CC'd the selinux development list so that the developers are aware of these issues] On Thu, 2007-05-10 at 16:50 +0200, Till Maas wrote: > On Do Mai 10 2007, Karl MacMillan wrote: > > > When selinux is turned on again a full relabel of the filesystem is done > > to correct these problems. If the custom file context wasn't added to > > the database of file contexts (via a module or semanage) the file is set > > to the default label. > > So will chcon in a scriptlet work, when an rpm is installed while selinux is > not active? > Unfortunately it won't - does semanage / semodule work in this instance (it probably should so that users can turn selinux back on after disabling and doing package management). > > Not sure what you mean - you should be able to run semanage in a post. > > Perhaps you should also need to do chcon (as opposed to restorecon) > > because the command may not have run before the file was created. > > When I tested semanage, the problem occured, how to update the labels with > semanage. E.g. when the regex is changed that desribes, which files should be > labeled in a certain way. And when one wants to remove the old labels when > uninstalling the package. E.g > > version 1 of the package: > > %post > semanage add RULE1 > %postun > semanage remove RULE1 > > As far as I understand rpm, when updating the release of version 1, first > semanage add RULE1 from release two runs from %post and then > semanage remove RULE1 from release one. This effectivly removes the rule from > the /etc/selinux, because identical rules seem not be added more than once > to /etc/selinux. When I restrict the %postun only to complete removals of the > package, Which seems like the right answer. > than when one changes the RULES, e.g. in a version 2: > > %post > semanage add RULE2 > %postun > semanage remove RULE2 > > then RULE1 will not be removed (it is not the final remove). Then every > release has to include "semanage remove RULE1" in "%post" maybe forever. I > hope you understand the problem I try to describe, because I did not really > use the correct selinux-terms. > Seems like there are two cases: 1) The context changes but the file spec stays the same - blindly adding should always work here (it will overwrite the old file context). 2) The file spec changes (doesn't matter if the context changes) - you will have to carry around the removal in the post forever. > I would be happy, if I am wrong with this. But if this problem is not solvable > with semanage, imho semanage is not a good way to add selinux support to a > package. > Maybe - we can make changes as necessary to make it usable. Karl From kmacmill at redhat.com Thu May 10 15:50:46 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 10 May 2007 11:50:46 -0400 Subject: Making Fedora a contributer friendly environment In-Reply-To: <46433B4D.1050304@city-fan.org> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091725.58679.opensource@till.name> <1178805305.17816.29.camel@localhost.localdomain> <200705101650.50233.opensource@till.name> <46433B4D.1050304@city-fan.org> Message-ID: <1178812246.24335.38.camel@localhost.localdomain> On Thu, 2007-05-10 at 16:33 +0100, Paul Howarth wrote: > Till Maas wrote: > > On Do Mai 10 2007, Karl MacMillan wrote: > > [...] > > > > I would be happy, if I am wrong with this. But if this problem is not solvable > > with semanage, imho semanage is not a good way to add selinux support to a > > package. > > I agree entirely, and would advocate using a policy module instead of > semanage, even if all the module contains are file contexts and no rules > (you may need a dummy rule that duplicates an existing one to get the > module to build and install properly though). Policy modules have > versioning built in and so upgrades work as expected. It's just a lot > more work to package them. > I'm not convinced of this yet, but I can be. The modules seem like overkill in many ways, though we could make it possible to make a file context only module. That would ease some of the pain. > For simple context fixes, getting them into the main selinux-policy > package is almost certainly the best and least hassle method though. > Agreed. Karl From stickster at gmail.com Thu May 10 15:52:24 2007 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 10 May 2007 08:52:24 -0700 Subject: Hello again In-Reply-To: <1178752801.5313.1.camel@ignacio.lan> References: <1178752801.5313.1.camel@ignacio.lan> Message-ID: <1178812344.4160.5.camel@localhost.localdomain> On Wed, 2007-05-09 at 19:20 -0400, Ignacio Vazquez-Abrams wrote: > Hello all. I realize that I've been gone for a long time, but I'd like > to resume helping the Fedora Project where possible. I've been digesting > wiki pages and mailing list archives as fast as I can, and I'm hoping to > be able to get back into the swing of things by this weekend. > > I apologize for my long silence, and I realize that it wasn't fair of me > to just run off leaving you hanging. What I have been doing for the past > 9 or so months is a series of topics for when I'm very, VERY drunk, but > rest assured that I will apply the various lessons learned about > teamwork and leadership towards my efforts within the Project. It's good to have you back, Ignacio. We saved you a seat. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields 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 alexl at redhat.com Thu May 10 15:53:31 2007 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 10 May 2007 17:53:31 +0200 Subject: (co)maintainers wanted In-Reply-To: References: <1178808160.3068.26.camel@greebo> Message-ID: <1178812412.3068.31.camel@greebo> On Thu, 2007-05-10 at 17:20 +0200, KH KH wrote: > 2007/5/10, Kevin Kofler : > Alexander Larsson redhat.com> writes: > > First some random packages i've ended up with that I rather > not own at > > all, since I don't really know much about them: > > Those 2 used to be in Extras, then got moved to Core due to > Mono: > > > * lcms > > I have a bug pending about updating lcms for cinepaint 0.22 > ( currently in review...) > As such i'm interested in co-maintainership... Its also used by applications like gimp and inkscape, so maybe their owners are interested. How do one add a co-mainter, practically? Is there any docs for this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding gay cat burglar looking for 'the Big One.' She's a mentally unstable tomboy barmaid on the trail of a serial killer. They fight crime! From sds at tycho.nsa.gov Thu May 10 16:27:10 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 10 May 2007 12:27:10 -0400 Subject: Making Fedora a contributer friendly environment In-Reply-To: <1178812160.24335.35.camel@localhost.localdomain> References: <1178291788.2702.10.camel@vorpal.macdev.com> <200705091725.58679.opensource@till.name> <1178805305.17816.29.camel@localhost.localdomain> <200705101650.50233.opensource@till.name> <1178812160.24335.35.camel@localhost.localdomain> Message-ID: <1178814430.3504.120.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2007-05-10 at 11:49 -0400, Karl MacMillan wrote: > [CC'd the selinux development list so that the developers are aware of > these issues] > > On Thu, 2007-05-10 at 16:50 +0200, Till Maas wrote: > > On Do Mai 10 2007, Karl MacMillan wrote: > > > > > When selinux is turned on again a full relabel of the filesystem is done > > > to correct these problems. If the custom file context wasn't added to > > > the database of file contexts (via a module or semanage) the file is set > > > to the default label. > > > > So will chcon in a scriptlet work, when an rpm is installed while selinux is > > not active? > > > > Unfortunately it won't - does semanage / semodule work in this instance > (it probably should so that users can turn selinux back on after > disabling and doing package management). semodule works with selinux disabled (it won't load the resulting policy naturally, but it manipulates the policy store and regenerates the policy files appropriately, so they would be used when selinux is next enabled, and a relabel would happen at that time). semanage has some dependencies on libselinux (e.g. is_selinux_mls_enabled, security_check_context) that should be converted to using libsemanage or libsepol interfaces, and then there is the separate issue of the context translation support. -- Stephen Smalley National Security Agency From rjones at redhat.com Thu May 10 16:41:39 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 10 May 2007 17:41:39 +0100 Subject: /etc/pki In-Reply-To: <20070510134945.GA24910@redhat.com> References: <4641F669.4040206@redhat.com> <20070510134945.GA24910@redhat.com> Message-ID: <46434B43.2050208@redhat.com> Joe Orton wrote: > Out of interest, is the PKI use for the app in question > something which must be strictly private to the app? Can you give some > details of what you're actually doing? Yes, we need a public key infrastructure for libvirt. See: http://libvirt.org/remote.html#Remote_certificates and for the details: https://www.redhat.com/archives/libvir-list/2007-May/thread.html#00032 in particular: https://www.redhat.com/archives/libvir-list/2007-May/msg00069.html https://www.redhat.com/archives/libvir-list/2007-May/msg00112.html https://www.redhat.com/archives/libvir-list/2007-May/msg00073.html Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at linux.duke.edu Thu May 10 16:39:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 10 May 2007 12:39:11 -0400 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <46429D7F.8010400@fedoraproject.org> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> <46429D7F.8010400@fedoraproject.org> Message-ID: <1178815151.3862.30.camel@rivendell> On Thu, 2007-05-10 at 09:50 +0530, Rahul Sundaram wrote: > You could submit a patch to do this then and get any other relevant > packages reviewed, included and then request Fedora Infrastructure team > to run new create repo for the Fedora devel as soon as we move beyond > Fedora 7. I don't think letting the package connect to a different repo > by default is desirable. That doesn't scale. +1. This needs to be in createrepo and/or modify the repo using modifyrepo. Contact me on tuesday (I'm out of town this week) and I'll see what we can get merged. -sv From pertusus at free.fr Thu May 10 16:34:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 May 2007 18:34:39 +0200 Subject: rpms/curl/devel curl.spec,1.47,1.48 In-Reply-To: <200705101333.l4ADXtHf031167@cvs-int.fedora.redhat.com> References: <200705101333.l4ADXtHf031167@cvs-int.fedora.redhat.com> Message-ID: <20070510163439.GC2847@free.fr> On Thu, May 10, 2007 at 09:33:55AM -0400, Jindrich Novy wrote: > Author: jnovy > > Update of /cvs/extras/rpms/curl/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31062 > > Modified Files: > curl.spec > Log Message: > - package libcurl.m4 in curl-devel (#239664), thanks to Quy Tonthat Only looking at the diff it seems to me that %_datadir/aclocal can be unowned after curl-devel removal. There is more than one way to solve this issue (Requires automake, own the directory...) but one should be used. -- Pat From jdieter at gmail.com Thu May 10 16:56:00 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 10 May 2007 19:56:00 +0300 Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178815151.3862.30.camel@rivendell> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> <46429D7F.8010400@fedoraproject.org> <1178815151.3862.30.camel@rivendell> Message-ID: <1178816160.4081.35.camel@jndwidescreen.lesbg.loc> On Thu, 2007-05-10 at 12:39 -0400, seth vidal wrote: > +1. > > This needs to be in createrepo and/or modify the repo using modifyrepo. > Contact me on tuesday (I'm out of town this week) and I'll see what we > can get merged. > > -sv > > I took a look at createrepo 0.4.8 this morning, and it looks like it does everything I wanted 0.4.4 to do, but it couldn't. Woo-hoo! So we can either (1) have createprestorepo work alongside createrepo without any modification to createrepo or (2) add a "-d" switch to createrepo and merge the few additional steps needed to create presto.xml.gz (which isn't much). If we're moving towards presto integration in F8, I would probably encourage (2) otherwise (1) would be easier for you. I'll contact you again on Tuesday. Jonathan -------------- 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 limb at jcomserv.net Thu May 10 17:17:59 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 10 May 2007 12:17:59 -0500 (CDT) Subject: (co)maintainers wanted In-Reply-To: <1178812412.3068.31.camel@greebo> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> Message-ID: <48776.65.192.24.190.1178817479.squirrel@mail.jcomserv.net> > On Thu, 2007-05-10 at 17:20 +0200, KH KH wrote: >> 2007/5/10, Kevin Kofler : >> Alexander Larsson redhat.com> writes: >> > First some random packages i've ended up with that I rather >> not own at >> > all, since I don't really know much about them: >> >> Those 2 used to be in Extras, then got moved to Core due to >> Mono: >> >> > * lcms >> >> I have a bug pending about updating lcms for cinepaint 0.22 >> ( currently in review...) >> As such i'm interested in co-maintainership... > > Its also used by applications like gimp and inkscape, so maybe their > owners are interested. > > How do one add a co-mainter, practically? Is there any docs for this? > Add a CVS-request to the review bug. If there isn't one, create a new bug and set the cvs flag to ?. http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a sword-wielding gay cat burglar looking for 'the Big One.' She's a > mentally unstable tomboy barmaid on the trail of a serial killer. They > fight > crime! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jima at beer.tclug.org Thu May 10 17:22:54 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 10 May 2007 12:22:54 -0500 (CDT) Subject: DeltaRPM works great on Fedora Core 6 (yum presto plugin) In-Reply-To: <1178816160.4081.35.camel@jndwidescreen.lesbg.loc> References: <64b14b300704102346necde24cx4c2c4a416a8dfdb0@mail.gmail.com> <461E1573.1070900@math.unl.edu> <1176402465.22545.14.camel@jndwidescreen.lesbg.loc> <200704121437.58088.jkeating@redhat.com> <1178696513.9345.167.camel@jndwidescreen.lesbg.loc> <20070509225823.GA27033@neu.nirvana> <1178770465.4081.5.camel@jndwidescreen.lesbg.loc> <46429D7F.8010400@fedoraproject.org> <1178815151.3862.30.camel@rivendell> <1178816160.4081.35.camel@jndwidescreen.lesbg.loc> Message-ID: On Thu, 10 May 2007, Jonathan Dieter wrote: > On Thu, 2007-05-10 at 12:39 -0400, seth vidal wrote: >> This needs to be in createrepo and/or modify the repo using modifyrepo. >> Contact me on tuesday (I'm out of town this week) and I'll see what we >> can get merged. > > I took a look at createrepo 0.4.8 this morning, and it looks like it > does everything I wanted 0.4.4 to do, but it couldn't. Woo-hoo! > > So we can either (1) have createprestorepo work alongside createrepo > without any modification to createrepo or (2) add a "-d" switch to > createrepo and merge the few additional steps needed to create > presto.xml.gz (which isn't much). > > If we're moving towards presto integration in F8, I would probably > encourage (2) otherwise (1) would be easier for you. I'll contact you > again on Tuesday. Not that my opinion means all that much, but I (still) think this would be a great feature for F8, and don't see any reason (upstream willing) that this functionality shouldn't be merged into createrepo. I think it'd be best if the existing Fedora mirrors could offer DRPMs alongside regular RPMs, and left the preference up to the client. Of course, in this ideal world, the mirrors would have all the disk space they needed, and wouldn't have to care about the extra space of the DRPMs, but...we'll see. Jima From tibbs at math.uh.edu Thu May 10 18:29:11 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 May 2007 13:29:11 -0500 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: FYI, I tried out the 3145 kernel and the iwl3945 driver still oopsed as soon as NetworkManager started and left me with a booted machine without keyboard input or networking. Here's the oops; I think this is mostly unchanged from what I reported before on fedora-kernel but perhaps it will be useful nonetheless. May 10 13:20:38 localhost NetworkManager: starting... May 10 13:20:39 localhost kernel: iwl3945: Microcode SW error detected. Restarting 0x82000000. May 10 13:20:40 localhost kernel: iwl3945: Error Reply type 0x0000003A cmd RXON_ASSOC (0x11) seq 0x0409 info 0x00000000 May 10 13:20:40 localhost kernel: iwl3945: Error setting RXON_ASSOC configuration (-5). May 10 13:20:42 localhost kernel: iwl3945: Can't stop Rx DMA. May 10 13:20:42 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000005 May 10 13:20:42 localhost kernel: printing eip: May 10 13:20:43 localhost kernel: f8ae2895 May 10 13:20:43 localhost kernel: *pde = 00000000 May 10 13:20:43 localhost kernel: Oops: 0000 [#1] May 10 13:20:43 localhost kernel: SMP May 10 13:20:44 localhost kernel: last sysfs file: /block/sr0/removable May 10 13:20:44 localhost kernel: Modules linked in: autofs4 hidp rfcomm l2cap sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables cpufreq_ondemand acpi_cpufreq dm_mirror dm_multipath dm_mod video sbs i2c_ec button dock battery ac sonypi parport_pc lp parport loop uinput sony_laptop arc4 ecb blkcipher tpm_infineon tpm rtc_cmos snd_hda_intel tpm_bios e100 snd_hda_codec rtc_core tifm_7xx1 snd_seq_dummy snd_seq_oss rtc_lib tifm_core snd_seq_midi_event iwl3945 serio_raw mii hci_usb snd_seq bluetooth pcspkr fw_ohci fw_core mac80211 iTCO_wdt snd_seq_device i2c_i801 cfg80211 iTCO_vendor_support snd_pcm_oss snd_mixer_oss i2c_core snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod joydev cdrom sg ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd May 10 13:20:44 localhost kernel: CPU: 0 May 10 13:20:44 localhost kernel: EIP: 0060:[] Not tainted VLI May 10 13:20:45 localhost kernel: EFLAGS: 00210246 (2.6.21-1.3145.fc7 #1) May 10 13:20:45 localhost kernel: EIP is at ipw_commit_rxon+0x42b/0x777 [iwl3945] May 10 13:20:45 localhost kernel: eax: 00000000 ebx: f6ca5158 ecx: f6296b20 edx: f6296b24 May 10 13:20:46 localhost kernel: esi: 00000000 edi: f6296b30 ebp: f6ca4fe0 esp: f6296b04 May 10 13:20:46 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 May 10 13:20:46 localhost kernel: Process NetworkManager (pid: 2494, ti=f6296000 task=f6298b70 task.ti=f6296000) May 10 13:20:46 localhost kernel: Stack: 00200282 f6ca5158 00000000 00000000 f6ca5160 f6ca5184 00008025 000c0011 May 10 13:20:46 localhost kernel: f6296b24 0004000c f6296b54 00200286 f6ca4fe0 00000003 00000001 00000003 May 10 13:20:46 localhost kernel: f8adc492 00000000 0000000f 00000000 00008025 00000004 00000315 f6ca4244 May 10 13:20:46 localhost kernel: Call Trace: May 10 13:20:46 localhost kernel: [] ipw_set_rxon_channel+0x22/0xf8 [iwl3945] May 10 13:20:47 localhost kernel: [] d_config_interface+0x219/0x25e [iwl3945] May 10 13:20:47 localhost kernel: [] __ieee80211_if_config+0xf9/0x105 [mac80211] May 10 13:20:47 localhost kernel: [] ieee80211_open+0x2ce/0x30c [mac80211] May 10 13:20:47 localhost kernel: [] dev_open+0x2b/0x62 May 10 13:20:47 localhost kernel: [] dev_change_flags+0x47/0xe4 May 10 13:20:47 localhost kernel: [] rtnl_setlink+0x264/0x363 May 10 13:20:47 localhost kernel: [] rtnl_setlink+0x0/0x363 May 10 13:20:47 localhost kernel: [] rtnetlink_rcv_msg+0x1c1/0x1e6 May 10 13:20:47 localhost kernel: [] netlink_run_queue+0x5c/0xca May 10 13:20:47 localhost kernel: [] rtnetlink_rcv_msg+0x0/0x1e6 May 10 13:20:47 localhost kernel: [] rtnetlink_rcv+0x25/0x3d May 10 13:20:47 localhost kernel: [] netlink_data_ready+0x12/0x52 May 10 13:20:47 localhost kernel: [] netlink_sendskb+0x1c/0x33 May 10 13:20:47 localhost kernel: [] netlink_sendmsg+0x277/0x283 May 10 13:20:47 localhost kernel: [] sock_sendmsg+0xd0/0xeb May 10 13:20:47 localhost kernel: [] autoremove_wake_function+0x0/0x35 May 10 13:20:47 localhost kernel: [] autoremove_wake_function+0x0/0x35 May 10 13:20:47 localhost kernel: [] copy_from_user+0x3a/0x66 May 10 13:20:47 localhost kernel: [] sys_sendmsg+0x192/0x1f7 May 10 13:20:47 localhost kernel: [] sys_recvmsg+0x14b/0x1cd May 10 13:20:47 localhost kernel: [] activate_page+0x61/0x85 May 10 13:20:47 localhost kernel: [] _spin_unlock_irq+0x5/0x7 May 10 13:20:47 localhost kernel: [] mark_page_accessed+0x1c/0x30 May 10 13:20:47 localhost kernel: [] filemap_nopage+0x18b/0x319 May 10 13:20:47 localhost kernel: [] sys_getsockname+0x86/0xb0 May 10 13:20:47 localhost kernel: [] __handle_mm_fault+0x8d9/0x8fb May 10 13:20:47 localhost kernel: [] sys_socketcall+0x240/0x261 May 10 13:20:47 localhost kernel: [] syscall_call+0x7/0xb May 10 13:20:47 localhost kernel: [] netlbl_domhsh_remove+0x7a/0x117 May 10 13:20:47 localhost kernel: ======================= May 10 13:20:47 localhost kernel: Code: 58 8a 85 c1 01 00 00 66 c7 44 24 5a 00 00 88 44 24 59 89 e8 e8 c3 c3 ff ff 85 c0 89 44 24 0c 75 38 8 b 54 24 20 8b 82 a4 00 00 00 40 05 40 74 1f c7 04 24 5e 19 af f8 e8 87 50 94 c7 8b 44 24 May 10 13:20:47 localhost kernel: EIP: [] ipw_commit_rxon+0x42b/0x777 [iwl3945] SS:ESP 0068:f6296b04 May 10 13:20:48 localhost kdm: :0[2581]: IO Error in XOpenDisplay May 10 13:20:48 localhost kdm[2550]: X server for display :0 terminated unexpectedly - J< From pbrobinson at gmail.com Thu May 10 18:52:57 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 10 May 2007 19:52:57 +0100 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: References: <20070508130336.GB23247@redhat.com> Message-ID: <5256d0b0705101152k386cbbe6j5d9d155ddf622ec3@mail.gmail.com> I upgraded my dell d620 to f7 test 4 after testing the intel display driver worked. The iwl3945 on the 3145 kernel works ok for me on an ap using wpa which I've never managed to get working previously with fc6. It did cause me a few problems initially (not sure if it was oopsing but powered off and tried again) but I cleared out the wpa_supplicant configs back to orig and cleared out any other prev attempts and it isn't too bad although it does seem to drop out every 15 mins or so and NM needs to be poked to reconnect. Its also really annoying that the NM box prompting for either the pass phrase or the keyring password seems to pop under the current window. Pete On 10 May 2007 13:29:11 -0500, Jason L Tibbitts III wrote: > FYI, I tried out the 3145 kernel and the iwl3945 driver still oopsed > as soon as NetworkManager started and left me with a booted machine > without keyboard input or networking. > > Here's the oops; I think this is mostly unchanged from what I reported > before on fedora-kernel but perhaps it will be useful nonetheless. > > May 10 13:20:38 localhost NetworkManager: starting... > May 10 13:20:39 localhost kernel: iwl3945: Microcode SW error detected. > Restarting 0x82000000. > May 10 13:20:40 localhost kernel: iwl3945: Error Reply type 0x0000003A cmd > RXON_ASSOC (0x11) seq 0x0409 info 0x00000000 > May 10 13:20:40 localhost kernel: iwl3945: Error setting RXON_ASSOC > configuration (-5). > May 10 13:20:42 localhost kernel: iwl3945: Can't stop Rx DMA. > May 10 13:20:42 localhost kernel: BUG: unable to handle kernel NULL pointer > dereference at virtual address 00000005 > May 10 13:20:42 localhost kernel: printing eip: > May 10 13:20:43 localhost kernel: f8ae2895 > May 10 13:20:43 localhost kernel: *pde = 00000000 > May 10 13:20:43 localhost kernel: Oops: 0000 [#1] > May 10 13:20:43 localhost kernel: SMP > May 10 13:20:44 localhost kernel: last sysfs file: /block/sr0/removable > May 10 13:20:44 localhost kernel: Modules linked in: autofs4 hidp rfcomm > l2cap sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack > nfnetlink xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables > cpufreq_ondemand acpi_cpufreq dm_mirror dm_multipath dm_mod video sbs i2c_ec > button dock battery ac sonypi parport_pc lp parport loop uinput sony_laptop > arc4 ecb blkcipher tpm_infineon tpm rtc_cmos snd_hda_intel tpm_bios e100 > snd_hda_codec rtc_core tifm_7xx1 snd_seq_dummy snd_seq_oss rtc_lib tifm_core > snd_seq_midi_event iwl3945 serio_raw mii hci_usb snd_seq bluetooth pcspkr > fw_ohci fw_core mac80211 iTCO_wdt snd_seq_device i2c_i801 cfg80211 > iTCO_vendor_support snd_pcm_oss snd_mixer_oss i2c_core snd_pcm snd_timer snd > soundcore snd_page_alloc sr_mod joydev cdrom sg ata_generic ata_piix libata > sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > May 10 13:20:44 localhost kernel: CPU: 0 > May 10 13:20:44 localhost kernel: EIP: 0060:[] Not tainted > VLI > May 10 13:20:45 localhost kernel: EFLAGS: 00210246 (2.6.21-1.3145.fc7 #1) > May 10 13:20:45 localhost kernel: EIP is at ipw_commit_rxon+0x42b/0x777 > [iwl3945] > May 10 13:20:45 localhost kernel: eax: 00000000 ebx: f6ca5158 ecx: > f6296b20 edx: f6296b24 > May 10 13:20:46 localhost kernel: esi: 00000000 edi: f6296b30 ebp: > f6ca4fe0 esp: f6296b04 > May 10 13:20:46 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 > ss: 0068 > May 10 13:20:46 localhost kernel: Process NetworkManager (pid: 2494, > ti=f6296000 task=f6298b70 task.ti=f6296000) > May 10 13:20:46 localhost kernel: Stack: 00200282 f6ca5158 00000000 00000000 > f6ca5160 f6ca5184 00008025 000c0011 > May 10 13:20:46 localhost kernel: f6296b24 0004000c f6296b54 00200286 > f6ca4fe0 00000003 00000001 00000003 > May 10 13:20:46 localhost kernel: f8adc492 00000000 0000000f 00000000 > 00008025 00000004 00000315 f6ca4244 > May 10 13:20:46 localhost kernel: Call Trace: > May 10 13:20:46 localhost kernel: [] > ipw_set_rxon_channel+0x22/0xf8 [iwl3945] > May 10 13:20:47 localhost kernel: [] > d_config_interface+0x219/0x25e [iwl3945] > May 10 13:20:47 localhost kernel: [] > __ieee80211_if_config+0xf9/0x105 [mac80211] > May 10 13:20:47 localhost kernel: [] ieee80211_open+0x2ce/0x30c > [mac80211] > May 10 13:20:47 localhost kernel: [] dev_open+0x2b/0x62 > May 10 13:20:47 localhost kernel: [] dev_change_flags+0x47/0xe4 > May 10 13:20:47 localhost kernel: [] rtnl_setlink+0x264/0x363 > May 10 13:20:47 localhost kernel: [] rtnl_setlink+0x0/0x363 > May 10 13:20:47 localhost kernel: [] > rtnetlink_rcv_msg+0x1c1/0x1e6 > May 10 13:20:47 localhost kernel: [] netlink_run_queue+0x5c/0xca > May 10 13:20:47 localhost kernel: [] rtnetlink_rcv_msg+0x0/0x1e6 > May 10 13:20:47 localhost kernel: [] rtnetlink_rcv+0x25/0x3d > May 10 13:20:47 localhost kernel: [] netlink_data_ready+0x12/0x52 > May 10 13:20:47 localhost kernel: [] netlink_sendskb+0x1c/0x33 > May 10 13:20:47 localhost kernel: [] netlink_sendmsg+0x277/0x283 > May 10 13:20:47 localhost kernel: [] sock_sendmsg+0xd0/0xeb > May 10 13:20:47 localhost kernel: [] > autoremove_wake_function+0x0/0x35 > May 10 13:20:47 localhost kernel: [] > autoremove_wake_function+0x0/0x35 > May 10 13:20:47 localhost kernel: [] copy_from_user+0x3a/0x66 > May 10 13:20:47 localhost kernel: [] sys_sendmsg+0x192/0x1f7 > May 10 13:20:47 localhost kernel: [] sys_recvmsg+0x14b/0x1cd > May 10 13:20:47 localhost kernel: [] activate_page+0x61/0x85 > May 10 13:20:47 localhost kernel: [] _spin_unlock_irq+0x5/0x7 > May 10 13:20:47 localhost kernel: [] mark_page_accessed+0x1c/0x30 > May 10 13:20:47 localhost kernel: [] filemap_nopage+0x18b/0x319 > May 10 13:20:47 localhost kernel: [] sys_getsockname+0x86/0xb0 > May 10 13:20:47 localhost kernel: [] > __handle_mm_fault+0x8d9/0x8fb > May 10 13:20:47 localhost kernel: [] sys_socketcall+0x240/0x261 > May 10 13:20:47 localhost kernel: [] syscall_call+0x7/0xb > May 10 13:20:47 localhost kernel: [] > netlbl_domhsh_remove+0x7a/0x117 > May 10 13:20:47 localhost kernel: ======================= > May 10 13:20:47 localhost kernel: Code: 58 8a 85 c1 01 00 00 66 c7 44 24 5a > 00 00 88 44 24 59 89 e8 e8 c3 c3 ff ff 85 c0 89 44 24 0c 75 38 8 > b 54 24 20 8b 82 a4 00 00 00 40 05 40 74 1f c7 04 24 5e 19 af f8 e8 87 > 50 94 c7 8b 44 24 > May 10 13:20:47 localhost kernel: EIP: [] > ipw_commit_rxon+0x42b/0x777 [iwl3945] SS:ESP 0068:f6296b04 > May 10 13:20:48 localhost kdm: :0[2581]: IO Error in XOpenDisplay > May 10 13:20:48 localhost kdm[2550]: X server for display :0 terminated > unexpectedly > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From j.w.r.degoede at hhs.nl Thu May 10 22:00:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 May 2007 00:00:21 +0200 Subject: Need help with libgda build failure on ppc64 Message-ID: <464395F5.5070600@hhs.nl> Hi all, In response to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239128 I've modified libgda to have %ifnarch's around the mono stuff, however now it fails to build because ./configure doesn't detect postgres support on ppc64?? See: http://koji.fedoraproject.org/koji/taskinfo?taskID=6040 And: http://koji.fedoraproject.org/koji/getfile?taskID=6040&name=build.log Since I have no access to a pcc64 machine, I could use some help with this. Regards, Hans From ncjeffgus at zimage.com Thu May 10 21:53:13 2007 From: ncjeffgus at zimage.com (Jeff Gustafson) Date: Thu, 10 May 2007 14:53:13 -0700 Subject: Thinkpad HDD head parking support? Message-ID: <1178833993.5150.14.camel@sally> Hi all, I decided to check out the Test4 release on my Thinkpad T60p. Although the bay eject didn't work with the kernel that was in the test4 distribution, the latest version available in Rawhide did support the bay drive eject. I'm looking forward to this since FC6 doesn't seem to support the T60 bay. Now if only ATI would get their drivers to work with the newer Xorg releases, I'll be set. I do have one suggestion though. Would it be possible for the drive head parking support be added into the kernel? The kernels seem to support the sensor, but without the parking patch, the sensor is basically useless. The newest patch that I could find for this support is here: http://article.gmane.org/gmane.linux.drivers.hdaps.devel/993 ...Jeff From mlum at redhat.com Thu May 10 21:57:34 2007 From: mlum at redhat.com (Margaret Lum) Date: Thu, 10 May 2007 14:57:34 -0700 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <46429249.3020102@redhat.com> References: <4642729C.1010105@math.unl.edu> <46428E8B.5070103@redhat.com> <46429167.4010403@redhat.com> <46429249.3020102@redhat.com> Message-ID: <4643954E.5060608@redhat.com> Warren Togami wrote: > Right, unsigned in Fedora. Proprietary or 3rd party apps needing a > signed JAR would need to provide it from a separate source. Can you > confirm that it could be parallel installed without much trouble? There won't be any need for this, as developers can sign at their own discretion. > >>> >>> Red Hat (the company) could (pending legal approval) choose to >>> proceed with this as part of an internal product. But as the rules >>> stand today, Fedora cannot ship this signed. >> We will ship this UNsigned, in Fedora. Can approval be re-evaluated? > > Right, yes it can. Please let me know what the next steps to working this through the approval committee expediently. I want to make sure there aren't details omitted that would hinder this package from being approved. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Thu May 10 22:13:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 May 2007 18:13:51 -0400 Subject: Need help with libgda build failure on ppc64 In-Reply-To: <464395F5.5070600@hhs.nl> References: <464395F5.5070600@hhs.nl> Message-ID: <20070510221351.GA21734@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Since I have no access to a pcc64 machine, I could use some help with this. $lib = lib. Hence, it's not finding anything. Bill From notting at redhat.com Thu May 10 22:41:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 May 2007 18:41:09 -0400 Subject: Need help with libgda build failure on ppc64 In-Reply-To: <20070510221351.GA21734@nostromo.devel.redhat.com> References: <464395F5.5070600@hhs.nl> <20070510221351.GA21734@nostromo.devel.redhat.com> Message-ID: <20070510224109.GA22171@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > Since I have no access to a pcc64 machine, I could use some help with this. > > $lib = lib. Hence, it's not finding anything. To be more precise, in configure: dnl Test for lib64 architectures dnl FIXME: should really check target case $host_cpu in x86_64* | sparc64*) lib="lib64";; *) lib="lib";; esac Bill From lxtnow at gmail.com Thu May 10 23:36:16 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Thu, 10 May 2007 19:36:16 -0400 Subject: (co)maintainers wanted In-Reply-To: <1178808160.3068.26.camel@greebo> References: <1178808160.3068.26.camel@greebo> Message-ID: <62bc09df0705101636r6c2de324xf6f7dc33b8ca83f7@mail.gmail.com> 2007/5/10, Alexander Larsson : > > I'm spending a lot of time on upstream development and some of the core > desktop packages, but I also own a bunch of other ex-core packages that > I really don't have much time for. I'm looking at getting new > maintainers or comaintainers for interested people. > > First some random packages i've ended up with that I rather not own at > all, since I don't really know much about them: > > * lcms > * gmime > > Then there is a bunch of mono libraries from when I did the initial mono > work: > * gtk-sharp2 > * gnome-sharp > * gsf-sharp > Do we have any people using mono that want to take over these, or to > help me comaintain them. The work for these are mostly version upgrades > now that they have been packaged, but its would be nice if someone who > uses them a bit could be involved. I actually use them, i'm working on some package which need them to build and for developing. I'm interested to co-maintain them. Then we have beagle: > * beagle > This generates a bit more work than the libraries, and as such its > important to have a active set of maintainers. Since it also touches > some of the desktop parts i own (Gnome file handling) i'd like to be > comaintainer here rather than totally loose it. > > There is also mono itself: > * mono > * libgdiplus > It would be interesting if we could get some of the upstream mono > developers helping out on this. Do we have any mono developers in the > fedora community? I'm also interested for mono . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a bookish guerilla paramedic in a wheelchair. She's a plucky > wisecracking > lawyer operating on the wrong side of the law. They fight crime! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Fri May 11 00:00:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 10 May 2007 19:00:44 -0500 Subject: Thinkpad HDD head parking support? In-Reply-To: <1178833993.5150.14.camel@sally> References: <1178833993.5150.14.camel@sally> Message-ID: <1178841644.13113.2.camel@vader.jdub.homelinux.org> On Thu, 2007-05-10 at 14:53 -0700, Jeff Gustafson wrote: > Hi all, > I decided to check out the Test4 release on my Thinkpad T60p. > Although the bay eject didn't work with the kernel that was in the test4 > distribution, the latest version available in Rawhide did support the > bay drive eject. I'm looking forward to this since FC6 doesn't seem to > support the T60 bay. Now if only ATI would get their drivers to work > with the newer Xorg releases, I'll be set. > I do have one suggestion though. Would it be possible for the > drive head parking support be added into the kernel? The kernels seem > to support the sensor, but without the parking patch, the sensor is > basically useless. > The newest patch that I could find for this support is here: > > http://article.gmane.org/gmane.linux.drivers.hdaps.devel/993 This needs to get included in the upstream kernel. josh From j.w.r.degoede at hhs.nl Fri May 11 06:09:43 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 May 2007 08:09:43 +0200 Subject: Need help with libgda build failure on ppc64 In-Reply-To: <20070510224109.GA22171@nostromo.devel.redhat.com> References: <464395F5.5070600@hhs.nl> <20070510221351.GA21734@nostromo.devel.redhat.com> <20070510224109.GA22171@nostromo.devel.redhat.com> Message-ID: <464408A7.70107@hhs.nl> Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> Since I have no access to a pcc64 machine, I could use some help with this. >> $lib = lib. Hence, it's not finding anything. > > To be more precise, in configure: > > > dnl Test for lib64 architectures > dnl FIXME: should really check target > case $host_cpu in > x86_64* | sparc64*) lib="lib64";; > *) lib="lib";; > esac > Thanks, Thats just the help I needed (I think, I'll fire a new build soon). Regards, Hans From j.w.r.degoede at hhs.nl Fri May 11 06:40:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 May 2007 08:40:17 +0200 Subject: comps in the new merged world Message-ID: <46440FD1.1070709@hhs.nl> Hi all, Back in the old FE days, when one wanted to add something to comps, one just edited the comps-feX.xml.in file in the CVS comps module. How does one add something to comps for F7, or has this not changed? I guess once this is clear, it should be added to: http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO Regards, Hans From j.w.r.degoede at hhs.nl Fri May 11 07:14:49 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Fri, 11 May 2007 09:14:49 +0200 Subject: Need help with libgda build failure on ppc64 In-Reply-To: <20070510224109.GA22171@nostromo.devel.redhat.com> References: <464395F5.5070600@hhs.nl> <20070510221351.GA21734@nostromo.devel.redhat.com> <20070510224109.GA22171@nostromo.devel.redhat.com> Message-ID: On Thu, 10 May 2007 18:41:09 -0400 Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > > Since I have no access to a pcc64 machine, I could > use some help with this. > > > > $lib = lib. Hence, it's not finding anything. > > To be more precise, in configure: > > > dnl Test for lib64 architectures > dnl FIXME: should really check target > case $host_cpu in > x86_64* | sparc64*) lib="lib64";; > *) lib="lib";; > esac > Hmm, I'm afraid it isn't that easy, I added this sed command: sed -i 's/x86_64\* | sparc64\*) lib="lib64";;/x86_64\* | sparc64\* | ppc64\*) lib="lib64";;/' configure.in to the spec before all the autoXXX files get regenerated, and I've verified locally that the generated configure contains "x86_64* | sparc64* | ppc64*) lib="lib64";; But it still fails to detect postgress see: http://koji.fedoraproject.org/koji/getfile?taskID=6292&name=build.log From oliver at linux-kernel.at Fri May 11 08:50:58 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 10:50:58 +0200 Subject: kernel package Message-ID: <46442E72.8060402@linux-kernel.at> Hi! A question; Before I open BZ... Is the kernel team (I see Dave Jones is doin' much; that's why CC:) willing to help AlphaCore and add patches to kernel spec? No, it's nothing for upstream. Just fixes for the spec. Some if(n)arch's, sections for alpha, a config, ... Nothing that should break primary archs... [ ] Willing [ ] Not willing :-) -of From kwizart at gmail.com Fri May 11 09:35:57 2007 From: kwizart at gmail.com (KH KH) Date: Fri, 11 May 2007 11:35:57 +0200 Subject: (co)maintainers wanted In-Reply-To: <1178812412.3068.31.camel@greebo> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> Message-ID: 2007/5/10, Alexander Larsson : > On Thu, 2007-05-10 at 17:20 +0200, KH KH wrote: > > 2007/5/10, Kevin Kofler : > > Alexander Larsson redhat.com> writes: > > > First some random packages i've ended up with that I rather > > not own at > > > all, since I don't really know much about them: > > > > Those 2 used to be in Extras, then got moved to Core due to > > Mono: > > > > > * lcms > > > > I have a bug pending about updating lcms for cinepaint 0.22 > > ( currently in review...) > > As such i'm interested in co-maintainership... > > Its also used by applications like gimp and inkscape, so maybe their > owners are interested. Recent Changes From cvs ownerlist : +Fedora EPEL|lcms|Color Management System|andreas.bierfert at lowlatency.de|extras-qa at fedoraproject.org| This was done on 7th of May. So if Andreas owns this package in EPEL, then he may also own it in Fedora ? Unless he requests co-maintainership i think it's fine as it is... (but i would like an update to 1.16 on FC-6 as requested in a bug...) Nicolas (kwizart) > > How do one add a co-mainter, practically? Is there any docs for this? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a sword-wielding gay cat burglar looking for 'the Big One.' She's a > mentally unstable tomboy barmaid on the trail of a serial killer. They fight > crime! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jwboyer at jdub.homelinux.org Fri May 11 10:34:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 05:34:01 -0500 Subject: kernel package In-Reply-To: <46442E72.8060402@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> Message-ID: <1178879641.13113.28.camel@vader.jdub.homelinux.org> On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > Hi! > > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > doin' much; that's why CC:) willing to help AlphaCore and add patches to > kernel spec? > > No, it's nothing for upstream. Just fixes for the spec. Some > if(n)arch's, sections for alpha, a config, ... Nothing that should break > primary archs... Where are these patches? josh From oliver at linux-kernel.at Fri May 11 11:24:02 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 13:24:02 +0200 Subject: kernel package In-Reply-To: <1178879641.13113.28.camel@vader.jdub.homelinux.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> Message-ID: <46445252.8080400@linux-kernel.at> On 05/11/2007 12:34 PM, Josh Boyer wrote: > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: >> Hi! >> >> A question; Before I open BZ... Is the kernel team (I see Dave Jones is >> doin' much; that's why CC:) willing to help AlphaCore and add patches to >> kernel spec? >> >> No, it's nothing for upstream. Just fixes for the spec. Some >> if(n)arch's, sections for alpha, a config, ... Nothing that should break >> primary archs... > > Where are these patches? Please find attached my current cvs diff. The Makefile.config part should be fixed better - I know, but had no time yet... I also attached the patch mentioned in the diff and the config that I currently use. I have no SMP support at the moment, as I don't have a smp capable machine. I don't know if it will build correctly, havn't yet finished my build - but I had a few tries already and today fixed - hopefully - the last build error. I'm also not sure if the kernel will boot fine. I'm just trying to get the first patches in devel, so if you update something in cvs, it's easier to merge with what I have... At the moment I'm not *fixing* things. I just try to build a kernel with make alpha directly in my cvs checkout. If it fails, I check where it fails and disable the appropriate module in my alpha config. I will go through the ifnarch's after I finally managed to boot up the new kernel and see that it works. Where appropriate, I will work with kernel upstream to fix the problems - of course... I'd really like to work together with the current kernel maintainers to provide a kernel spec/srpm, that builds on alpha. -of -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-alpha.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.6-no_fec_for_alpha.patch Type: text/x-patch Size: 352 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-2.6.21-alpha.config Type: application/octet-stream Size: 66077 bytes Desc: not available URL: From alexl at redhat.com Fri May 11 11:25:56 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 11 May 2007 13:25:56 +0200 Subject: (co)maintainers wanted In-Reply-To: References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> Message-ID: <1178882756.4477.15.camel@localhost.localdomain> On Fri, 2007-05-11 at 11:35 +0200, KH KH wrote: > 2007/5/10, Alexander Larsson : > > On Thu, 2007-05-10 at 17:20 +0200, KH KH wrote: > > > 2007/5/10, Kevin Kofler : > > > Alexander Larsson redhat.com> writes: > > > > First some random packages i've ended up with that I rather > > > not own at > > > > all, since I don't really know much about them: > > > > > > Those 2 used to be in Extras, then got moved to Core due to > > > Mono: > > > > > > > * lcms > > > > > > I have a bug pending about updating lcms for cinepaint 0.22 > > > ( currently in review...) > > > As such i'm interested in co-maintainership... > > > > Its also used by applications like gimp and inkscape, so maybe their > > owners are interested. > Recent Changes From cvs ownerlist : > +Fedora EPEL|lcms|Color Management > System|andreas.bierfert at lowlatency.de|extras-qa at fedoraproject.org| > This was done on 7th of May. So if Andreas owns this package in EPEL, > then he may also own it in Fedora ? Unless he requests > co-maintainership i think it's fine as it is... > (but i would like an update to 1.16 on FC-6 as requested in a bug...) CC:in andreas. Are you interested in this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous playboy vagrant from the 'hood. She's a cynical streetsmart bounty hunter in the witness protection program. They fight crime! From alexl at redhat.com Fri May 11 11:29:24 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 11 May 2007 13:29:24 +0200 Subject: gmime (co)maintainers wanted In-Reply-To: <46433B88.4070907@leemhuis.info> References: <1178808160.3068.26.camel@greebo> <46433B88.4070907@leemhuis.info> Message-ID: <1178882964.4477.17.camel@localhost.localdomain> On Thu, 2007-05-10 at 17:34 +0200, Thorsten Leemhuis wrote: > Kevin Kofler schrieb: > >> * gmime > > The last Extras maintainer for gmime was Thorsten Leemhuis. Thorsten, do you > > want gmime back? > > Not really -- Iirc I just packaged it because mail-notification needed > it. But well, if no one else is interested in it'll at least become > official co-maintainer. Then we'll see how things evolve. Ok, Anyone else interested? I'll wait a few days for responses. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lonely ninja filmmaker on a mission from God. She's a time-travelling foul-mouthed barmaid with an MBA from Harvard. They fight crime! From alexl at redhat.com Fri May 11 11:37:12 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 11 May 2007 13:37:12 +0200 Subject: (co)maintainers wanted In-Reply-To: <62bc09df0705101636r6c2de324xf6f7dc33b8ca83f7@mail.gmail.com> References: <1178808160.3068.26.camel@greebo> <62bc09df0705101636r6c2de324xf6f7dc33b8ca83f7@mail.gmail.com> Message-ID: <1178883432.4477.23.camel@localhost.localdomain> On Thu, 2007-05-10 at 19:36 -0400, SmootherFrOgZ wrote: > * gtk-sharp2 > * gnome-sharp > * gsf-sharp > > I actually use them, i'm working on some package which need them to > build and for developing. > I'm interested to co-maintain them. Sounds good. I'll wait a few days to see if anyone else is interested, and then i'll go ahead and request a change. > There is also mono itself: > * mono > * libgdiplus > It would be interesting if we could get some of the upstream > mono > developers helping out on this. Do we have any mono developers > in the > fedora community? > > I'm also interested for mono . Do you have any experience with mono toolchain work? It would be nice if we could get someone who actually work on the compiler and jit a bit to own this. For instance, there is a bug with how the jit:ed code accesses TLS that causes bad segment register accesses in xen leading to loads of syslog spew. Would be nice if we could get someone to look at that. But its pretty hardcore stuff. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a deeply religious dishevelled hairdresser haunted by memories of 'Nam. She's a pregnant belly-dancing former first lady with a knack for trouble. They fight crime! From dwmw2 at infradead.org Fri May 11 11:49:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 May 2007 12:49:17 +0100 Subject: kernel package In-Reply-To: <46442E72.8060402@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> Message-ID: <1178884157.21820.37.camel@shinybook.infradead.org> On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > doin' much; that's why CC:) willing to help AlphaCore and add patches to > kernel spec? > > No, it's nothing for upstream. Just fixes for the spec. Some > if(n)arch's, sections for alpha, a config, ... Nothing that should break > primary archs... We don't like ifarches. Why? Yeah, I'm not averse to babysitting this -- and when I get home in a fortnight or so I can possibly even dig out the SX164 too. Got a ppc{64,}>alpha crosscompiler? :) We could _really_ do with kickstarting the cross-binutils and cross-gcc efforts -- at least for Fedora architectures to start with, and the embedded targets could follow. -- dwmw2 From dwmw2 at infradead.org Fri May 11 11:51:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 May 2007 12:51:42 +0100 Subject: kernel package In-Reply-To: <46445252.8080400@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> Message-ID: <1178884302.21820.40.camel@shinybook.infradead.org> On Fri, 2007-05-11 at 13:24 +0200, Oliver Falk wrote: > Please find attached my current cvs diff. The Makefile.config part > should be fixed better - I know, but had no time yet... echo 'diff -up' >> ~/.cvsrc I have no idea where you're putting those ifarches. -- dwmw2 From oliver at linux-kernel.at Fri May 11 11:57:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 13:57:21 +0200 Subject: kernel package In-Reply-To: <1178884302.21820.40.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884302.21820.40.camel@shinybook.infradead.org> Message-ID: <46445A21.1010407@linux-kernel.at> On 05/11/2007 01:51 PM, David Woodhouse wrote: > On Fri, 2007-05-11 at 13:24 +0200, Oliver Falk wrote: >> Please find attached my current cvs diff. The Makefile.config part >> should be fixed better - I know, but had no time yet... > > echo 'diff -up' >> ~/.cvsrc > > I have no idea where you're putting those ifarches. Sure. Sorry. New diff attached. -of -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-alpha.patch Type: text/x-patch Size: 6390 bytes Desc: not available URL: From dwmw2 at infradead.org Fri May 11 12:01:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 May 2007 13:01:29 +0100 Subject: kernel package In-Reply-To: <46445252.8080400@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> Message-ID: <1178884889.21820.46.camel@shinybook.infradead.org> Readable diff attached. And the answer (at least from me) is no -- I'm not happy about applying it with all the ifdefs. We can apply the clean bits though -- obviously it won't actually build, but then we can set about actually _fixing_ exec-shield, etc. Can you explain each ifarch? And show Patch701? Why at the end? Once upon a time the folks at HP were threatening to send me SMP Alpha boxen -- not sure if I could still pull that off... Index: kernel-2.6.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3148 diff -u -r1.3148 kernel-2.6.spec --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 @@ -167,6 +167,16 @@ %define usesparse 0 %endif +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 +%define with_smp 0 +%define with_pae 0 +%define with_xen 0 +%define with_kdump 0 +%define with_debug 0 +%define usesparse 0 +%define with_modsign 0 +%endif + # Per-arch tweaks %ifarch %{all_x86} @@ -238,6 +248,13 @@ %define xen_image vmlinux.gz %endif +%ifarch alpha alphaev6 alphaev67 +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config +%define image_install_path boot +%define make_target boot +%define kernel_image vmlinux +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -290,13 +307,13 @@ Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} -Release: %{release} +Release: %{release}axp %if 0%{?olpc} ExclusiveArch: i386 i586 %else # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 %endif ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 @@ -363,6 +380,9 @@ #Source67: kernel-%{kversion}-sparc64.config #Source68: kernel-%{kversion}-sparc64-smp.config +Source50: kernel-%{kversion}-alpha.config +Source50: kernel-%{kversion}-alpha-smp.config + Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic @@ -452,6 +472,9 @@ # 600 - 699 sparc(64) +# 700 - 799 alpha +Patch701: linux-2.6-no_fec_for_alpha.patch + # # Patches 800 through 899 are reserved for bugfixes to the core system # and patches related to how RPMs are build @@ -1001,7 +1024,9 @@ # Patches 10 through 100 are meant for core subsystem upgrades # Roland's utrace ptrace replacement. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch10 -p1 +%endif %patch11 -p1 # Power management fixes @@ -1106,7 +1131,9 @@ %patch800 -p1 # Exec shield +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch810 -p1 +%endif # # GPG signed kernel modules @@ -1181,7 +1208,9 @@ %patch1018 -p1 %patch1019 -p1 %patch1020 -p1 +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 %patch1021 -p1 +%endif %patch1022 -p1 %if %{includexen} %patch1023 -p1 @@ -1198,7 +1227,9 @@ # # /dev/crash driver for the crashdump analysis tool # +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1060 -p1 +%endif %if %{includexen} %patch1061 -p1 %endif @@ -1258,7 +1289,9 @@ # DVB spinlock bug %patch1700 -p1 # setuid /proc/self/maps fix. +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch1720 -p1 +%endif # Add a safety net to softlockup so that it doesn't prevent installs. %patch1740 -p1 # Speed up spinlock debug. @@ -1346,7 +1379,9 @@ # # Pull in the new firewire stack +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 %patch5000 -p1 +%endif # # final stuff @@ -1360,6 +1395,9 @@ %patch10002 -p1 %patch10003 -p1 +# alpha related, but must be done at the end... +%patch701 -p0 + # END OF PATCH APPLICATIONS cp %{SOURCE10} Documentation/ -- dwmw2 From oliver at linux-kernel.at Fri May 11 12:04:52 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 14:04:52 +0200 Subject: kernel package In-Reply-To: <1178884889.21820.46.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> Message-ID: <46445BE4.9040108@linux-kernel.at> On 05/11/2007 02:01 PM, David Woodhouse wrote: > Readable diff attached. And the answer (at least from me) is no -- I'm > not happy about applying it with all the ifdefs. We can apply the clean > bits though -- obviously it won't actually build, but then we can set > about actually _fixing_ exec-shield, etc. k. ack. > Can you explain each ifarch? And show Patch701? Why at the end? will do so. > Once upon a time the folks at HP were threatening to send me SMP Alpha > boxen -- not sure if I could still pull that off... give 'em my address :-) I'll try to provide you with all details within the next few days. Maybe on Monday, soonest... I'm not sure. For me weekend starts now. :-) Best, Oliver > Index: kernel-2.6.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3148 > diff -u -r1.3148 kernel-2.6.spec > --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 > +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 > @@ -167,6 +167,16 @@ > %define usesparse 0 > %endif > > +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > +%define with_smp 0 > +%define with_pae 0 > +%define with_xen 0 > +%define with_kdump 0 > +%define with_debug 0 > +%define usesparse 0 > +%define with_modsign 0 > +%endif > + > # Per-arch tweaks > > %ifarch %{all_x86} > @@ -238,6 +248,13 @@ > %define xen_image vmlinux.gz > %endif > > +%ifarch alpha alphaev6 alphaev67 > +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config > +%define image_install_path boot > +%define make_target boot > +%define kernel_image vmlinux > +%endif > + > # To temporarily exclude an architecture from being built, add it to > # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we > # don't build kernel-headers then the new build system will no longer let > @@ -290,13 +307,13 @@ > Group: System Environment/Kernel > License: GPLv2 > Version: %{rpmversion} > -Release: %{release} > +Release: %{release}axp > %if 0%{?olpc} > ExclusiveArch: i386 i586 > %else > # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. > # SET %nobuildarches (ABOVE) INSTEAD > -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x > +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 > %endif > ExclusiveOS: Linux > Provides: kernel-drm = 4.3.0 > @@ -363,6 +380,9 @@ > #Source67: kernel-%{kversion}-sparc64.config > #Source68: kernel-%{kversion}-sparc64-smp.config > > +Source50: kernel-%{kversion}-alpha.config > +Source50: kernel-%{kversion}-alpha-smp.config > + > Source80: config-rhel-generic > Source81: config-rhel-x86-generic > Source82: config-olpc-generic > @@ -452,6 +472,9 @@ > > # 600 - 699 sparc(64) > > +# 700 - 799 alpha > +Patch701: linux-2.6-no_fec_for_alpha.patch > + > # > # Patches 800 through 899 are reserved for bugfixes to the core system > # and patches related to how RPMs are build > @@ -1001,7 +1024,9 @@ > # Patches 10 through 100 are meant for core subsystem upgrades > > # Roland's utrace ptrace replacement. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch10 -p1 > +%endif > %patch11 -p1 > > # Power management fixes > @@ -1106,7 +1131,9 @@ > %patch800 -p1 > > # Exec shield > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch810 -p1 > +%endif > > # > # GPG signed kernel modules > @@ -1181,7 +1208,9 @@ > %patch1018 -p1 > %patch1019 -p1 > %patch1020 -p1 > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch1021 -p1 > +%endif > %patch1022 -p1 > %if %{includexen} > %patch1023 -p1 > @@ -1198,7 +1227,9 @@ > # > # /dev/crash driver for the crashdump analysis tool > # > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1060 -p1 > +%endif > %if %{includexen} > %patch1061 -p1 > %endif > @@ -1258,7 +1289,9 @@ > # DVB spinlock bug > %patch1700 -p1 > # setuid /proc/self/maps fix. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1720 -p1 > +%endif > # Add a safety net to softlockup so that it doesn't prevent installs. > %patch1740 -p1 > # Speed up spinlock debug. > @@ -1346,7 +1379,9 @@ > # > > # Pull in the new firewire stack > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch5000 -p1 > +%endif > > # > # final stuff > @@ -1360,6 +1395,9 @@ > %patch10002 -p1 > %patch10003 -p1 > > +# alpha related, but must be done at the end... > +%patch701 -p0 > + > # END OF PATCH APPLICATIONS > > cp %{SOURCE10} Documentation/ > -- Oliver Falk UNIX/Linux Systems Administrator Mail: oliver at linux-kernel.at Phone: +43 (664) 838 59 25 From oliver at linux-kernel.at Fri May 11 12:08:52 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 14:08:52 +0200 Subject: kernel package In-Reply-To: <1178884157.21820.37.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> Message-ID: <46445CD4.2090104@linux-kernel.at> On 05/11/2007 01:49 PM, David Woodhouse wrote: > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: >> A question; Before I open BZ... Is the kernel team (I see Dave Jones is >> doin' much; that's why CC:) willing to help AlphaCore and add patches to >> kernel spec? >> >> No, it's nothing for upstream. Just fixes for the spec. Some >> if(n)arch's, sections for alpha, a config, ... Nothing that should break >> primary archs... > > We don't like ifarches. Why? I know, we don't like ifarchs, but for now it's the easiest way. We apply patches that will need much rework to don't break alpha - I believe... Of course, I will try to get 'em out as good as I can! > Yeah, I'm not averse to babysitting this -- and when I get home in a > fortnight or so I can possibly even dig out the SX164 too. Oh, great! That's fine to hear! > Got a ppc{64,}>alpha crosscompiler? :) Nop. :-( > We could _really_ do with kickstarting the cross-binutils and cross-gcc > efforts -- at least for Fedora architectures to start with, and the > embedded targets could follow. :-) -of From oliver at linux-kernel.at Fri May 11 12:08:52 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 11 May 2007 14:08:52 +0200 Subject: kernel package In-Reply-To: <1178884157.21820.37.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> Message-ID: <46445CD4.2090104@linux-kernel.at> On 05/11/2007 01:49 PM, David Woodhouse wrote: > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: >> A question; Before I open BZ... Is the kernel team (I see Dave Jones is >> doin' much; that's why CC:) willing to help AlphaCore and add patches to >> kernel spec? >> >> No, it's nothing for upstream. Just fixes for the spec. Some >> if(n)arch's, sections for alpha, a config, ... Nothing that should break >> primary archs... > > We don't like ifarches. Why? I know, we don't like ifarchs, but for now it's the easiest way. We apply patches that will need much rework to don't break alpha - I believe... Of course, I will try to get 'em out as good as I can! > Yeah, I'm not averse to babysitting this -- and when I get home in a > fortnight or so I can possibly even dig out the SX164 too. Oh, great! That's fine to hear! > Got a ppc{64,}>alpha crosscompiler? :) Nop. :-( > We could _really_ do with kickstarting the cross-binutils and cross-gcc > efforts -- at least for Fedora architectures to start with, and the > embedded targets could follow. :-) -of From jwboyer at jdub.homelinux.org Fri May 11 12:03:41 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 07:03:41 -0500 Subject: kernel package In-Reply-To: <1178884889.21820.46.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> Message-ID: <1178885021.29429.6.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote: > Readable diff attached. And the answer (at least from me) is no -- I'm > not happy about applying it with all the ifdefs. We can apply the clean > bits though -- obviously it won't actually build, but then we can set > about actually _fixing_ exec-shield, etc. > > Can you explain each ifarch? And show Patch701? Why at the end? > > Once upon a time the folks at HP were threatening to send me SMP Alpha > boxen -- not sure if I could still pull that off... > > Index: kernel-2.6.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3148 > diff -u -r1.3148 kernel-2.6.spec > --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 > +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 > @@ -167,6 +167,16 @@ > %define usesparse 0 > %endif > > +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 instead of listing all the alpha arches everywhere, you should define a macro like %{all_alpha} > # To temporarily exclude an architecture from being built, add it to > # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we > # don't build kernel-headers then the new build system will no longer let > @@ -290,13 +307,13 @@ > Group: System Environment/Kernel > License: GPLv2 > Version: %{rpmversion} > -Release: %{release} > +Release: %{release}axp Shouldn't need to muck with Release > %if 0%{?olpc} > ExclusiveArch: i386 i586 > %else > # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. > # SET %nobuildarches (ABOVE) INSTEAD > -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x > +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 > %endif > ExclusiveOS: Linux > Provides: kernel-drm = 4.3.0 > @@ -363,6 +380,9 @@ > #Source67: kernel-%{kversion}-sparc64.config > #Source68: kernel-%{kversion}-sparc64-smp.config > > +Source50: kernel-%{kversion}-alpha.config > +Source50: kernel-%{kversion}-alpha-smp.config Do you need an alpha-smp.config since you turned smp builds off? > +# 700 - 799 alpha > +Patch701: linux-2.6-no_fec_for_alpha.patch Where's this? > # > # Patches 800 through 899 are reserved for bugfixes to the core system > # and patches related to how RPMs are build > @@ -1001,7 +1024,9 @@ > # Patches 10 through 100 are meant for core subsystem upgrades > > # Roland's utrace ptrace replacement. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch10 -p1 > +%endif Is utrace really broken on alpha? > # Exec shield > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch810 -p1 > +%endif > > # > # GPG signed kernel modules > @@ -1181,7 +1208,9 @@ > %patch1018 -p1 > %patch1019 -p1 > %patch1020 -p1 > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch1021 -p1 > +%endif Does this patch not apply, or doesn't work, or? > %patch1022 -p1 > %if %{includexen} > %patch1023 -p1 > @@ -1198,7 +1227,9 @@ > # > # /dev/crash driver for the crashdump analysis tool > # > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1060 -p1 > +%endif Same thing here > %if %{includexen} > %patch1061 -p1 > %endif > @@ -1258,7 +1289,9 @@ > # DVB spinlock bug > %patch1700 -p1 > # setuid /proc/self/maps fix. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1720 -p1 > +%endif > # Add a safety net to softlockup so that it doesn't prevent installs. > %patch1740 -p1 > # Speed up spinlock debug. > @@ -1346,7 +1379,9 @@ > # > > # Pull in the new firewire stack > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch5000 -p1 > +%endif Same thing here josh From jwboyer at jdub.homelinux.org Fri May 11 12:04:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 07:04:37 -0500 Subject: kernel package In-Reply-To: <46445A21.1010407@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884302.21820.40.camel@shinybook.infradead.org> <46445A21.1010407@linux-kernel.at> Message-ID: <1178885077.29429.8.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 13:57 +0200, Oliver Falk wrote: > ? kernel-2.6.21-alpha.config.new > ? linux-2.6-no_fec_for_alpha.patch > ? configs/ALPHA > ? configs/config-alpha > Index: Makefile.config > =================================================================== > RCS file: /cvs/dist/devel/kernel/Makefile.config,v > retrieving revision 1.53 > diff -u -p -r1.53 Makefile.config > --- Makefile.config 7 Mar 2007 07:25:46 -0000 1.53 > +++ Makefile.config 11 May 2007 11:56:31 -0000 > @@ -14,9 +14,10 @@ CONFIGFILES = \ > $(CFG)-ppc.config $(CFG)-ppc-smp.config \ > $(CFG)-ppc64.config $(CFG)-ppc64-kdump.config > $(CFG)-ia64.config \ > $(CFG)-i686-xen.config $(CFG)-x86_64-xen.config \ > - $(CFG)-ia64-xen.config > + $(CFG)-ia64-xen.config \ > + $(CFG)-alpha.config > > -PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390 ia64 # > sparc sparc64 > +PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390 ia64 > alpha # sparc sparc64 alpha likely needs to be behind the '#' like sparc is. josh From dwmw2 at infradead.org Fri May 11 12:13:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 May 2007 13:13:05 +0100 Subject: kernel package In-Reply-To: <46445252.8080400@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> Message-ID: <1178885585.21820.51.camel@shinybook.infradead.org> You seem to build for a bunch of different architectures, but don't have separate config files for most of them. I'd suggest building for ev4|up, ev56+|up and ev56+|smp. Are there SMP boxen without BWX? -- dwmw2 From dwmw2 at infradead.org Fri May 11 12:14:30 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 11 May 2007 13:14:30 +0100 Subject: kernel package In-Reply-To: <1178885077.29429.8.camel@zod.rchland.ibm.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884302.21820.40.camel@shinybook.infradead.org> <46445A21.1010407@linux-kernel.at> <1178885077.29429.8.camel@zod.rchland.ibm.com> Message-ID: <1178885670.21820.53.camel@shinybook.infradead.org> On Fri, 2007-05-11 at 07:04 -0500, Josh Boyer wrote: > alpha likely needs to be behind the '#' like sparc is. Actually it doesn't matter -- those rules only affect the temporary files and 'make clean'. No need to have sparc commented out either, afaict. -- dwmw2 From buc at odusz.so-cdu.ru Fri May 11 13:01:24 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 17:01:24 +0400 Subject: Legality of Fedora in production environment Message-ID: <46446924.1080209@odu.neva.ru> The using of software in business and production environment can be a subject for legislative regulation. It can lead to some legal troubles of using of distributions like Fedora. Recently the appropriate laws in my country (Russia) have been significantly toughened. Now the police can check for illegal software usage by their own initiative (without request from the owner). The tax inspection demands that software should be registered at accounts departments. During such a checking, the user is obliged now to show all hardcopy license documents (with original signatures and stamps). But there are no any such things for distros like Fedora, which have been just downloaded from Internet, hence the user shows nothing. In this situation the police *must* temporarily confiscate system blocks (up to 2 weeks) for further checking... Certainly, after the checking period all hardware comes back, but such troubles are not allowed for normal business. Are there any similar troubles in other countries? How it can be avoided? Our local linux distributors recommend to not download from Internet, but buy their box, which includes CDs accompanied with some license facsimile paper (just to show polices at least "something"). Dmitry Butskoy, Saint-Petersburg, Russia Red Hat Certified Engineer 809003662809495 http://www.fedoraproject.org/wiki/DmitryButskoy From andreas.bierfert at lowlatency.de Fri May 11 13:12:16 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 11 May 2007 15:12:16 +0200 Subject: (co)maintainers wanted In-Reply-To: <1178882756.4477.15.camel@localhost.localdomain> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> <1178882756.4477.15.camel@localhost.localdomain> Message-ID: <20070511151216.0fc784a0@spica.a.lan> On Fri, 11 May 2007 13:25:56 +0200 Alexander Larsson wrote: > > CC:in andreas. Are you interested in this? Sure. I do maintain it for EPEL and for FE <= 4? I believe so should not be to much trouble... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri May 11 13:15:34 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 May 2007 09:15:34 -0400 Subject: kernel package In-Reply-To: <1178885021.29429.6.camel@zod.rchland.ibm.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <1178885021.29429.6.camel@zod.rchland.ibm.com> Message-ID: <46446C76.1010105@redhat.com> Josh Boyer wrote: > On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote: >> Readable diff attached. And the answer (at least from me) is no -- I'm >> not happy about applying it with all the ifdefs. We can apply the clean >> bits though -- obviously it won't actually build, but then we can set >> about actually _fixing_ exec-shield, etc. +1 for not happy about all the ifdef alpha's >> +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > > instead of listing all the alpha arches everywhere, you should define a > macro like %{all_alpha} +1 >> # To temporarily exclude an architecture from being built, add it to >> # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we >> # don't build kernel-headers then the new build system will no longer let >> @@ -290,13 +307,13 @@ >> Group: System Environment/Kernel >> License: GPLv2 >> Version: %{rpmversion} >> -Release: %{release} >> +Release: %{release}axp > > Shouldn't need to muck with Release Indeed. There's a %buildid define further up in the spec if you really want to alter the release tag for your own build, but we're certainly not going to merge this part of the patch. :) >> %if 0%{?olpc} >> ExclusiveArch: i386 i586 >> %else >> # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. >> # SET %nobuildarches (ABOVE) INSTEAD >> -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x >> +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 >> %endif >> ExclusiveOS: Linux >> Provides: kernel-drm = 4.3.0 >> @@ -363,6 +380,9 @@ >> #Source67: kernel-%{kversion}-sparc64.config >> #Source68: kernel-%{kversion}-sparc64-smp.config >> >> +Source50: kernel-%{kversion}-alpha.config >> +Source50: kernel-%{kversion}-alpha-smp.config > > Do you need an alpha-smp.config since you turned smp builds off? Not to mention that they should have different SourceX numbers if you do intend to include both. -- Jarod Wilson jwilson at redhat.com From rwwyatt01 at gmail.com Fri May 11 13:17:51 2007 From: rwwyatt01 at gmail.com (Randy Wyatt) Date: Fri, 11 May 2007 06:17:51 -0700 Subject: Legality of Fedora in production environment In-Reply-To: <46446924.1080209@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> Message-ID: <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> Why wouldn't a hard copy of the GPL suffice ? On 5/11/07, Dmitry Butskoy wrote: > > The using of software in business and production environment can be a > subject for legislative regulation. It can lead to some legal troubles > of using of distributions like Fedora. > > Recently the appropriate laws in my country (Russia) have been > significantly toughened. Now the police can check for illegal software > usage by their own initiative (without request from the owner). The tax > inspection demands that software should be registered at accounts > departments. > > During such a checking, the user is obliged now to show all hardcopy > license documents (with original signatures and stamps). But there are > no any such things for distros like Fedora, which have been just > downloaded from Internet, hence the user shows nothing. In this > situation the police *must* temporarily confiscate system blocks (up to > 2 weeks) for further checking... > Certainly, after the checking period all hardware comes back, but such > troubles are not allowed for normal business. > > > Are there any similar troubles in other countries? > > How it can be avoided? > > Our local linux distributors recommend to not download from Internet, > but buy their box, which includes CDs accompanied with some license > facsimile paper (just to show polices at least "something"). > > > Dmitry Butskoy, > Saint-Petersburg, Russia > Red Hat Certified Engineer 809003662809495 > 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 alexl at redhat.com Fri May 11 13:21:58 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 11 May 2007 15:21:58 +0200 Subject: (co)maintainers wanted In-Reply-To: <20070511151216.0fc784a0@spica.a.lan> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> <1178882756.4477.15.camel@localhost.localdomain> <20070511151216.0fc784a0@spica.a.lan> Message-ID: <1178889718.4477.28.camel@localhost.localdomain> On Fri, 2007-05-11 at 15:12 +0200, Andreas Bierfert wrote: > On Fri, 11 May 2007 13:25:56 +0200 > Alexander Larsson wrote: > > > > CC:in andreas. Are you interested in this? > > Sure. I do maintain it for EPEL and for FE <= 4? I believe so should not be to > much trouble... Good. You'll be primary mantainer then. Nicolas, do you still want to be comaintainer? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced crooked werewolf living undercover at Ringling Bros. Circus. She's a blind gold-digging traffic cop with someone else's memories. They fight crime! From pertusus at free.fr Fri May 11 13:16:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 May 2007 15:16:38 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> Message-ID: <20070511131638.GA4791@free.fr> On Fri, May 11, 2007 at 04:54:43AM -0400, Adam Tkac wrote: > Author: atkac > > mtools-3.9.10-sh.patch: I may be completly wrong, but in my recollection using arithmetic/conditionals like > +if [[ $# -eq 0 ]] ; then is not sh compatible but requires some bash extensions. It should be, instead, along if [ $# = 0 ]; then == also in [ ] is not portable. I am not sure and this would benefit from double checking. In any case, for fedora it should be fine even with the bash extensions, and the shebang also may be changed to #! /bin/bash to be safe, but if it is to be submitted upstream (as it should be) you should really take care that no bash extensions are used. -- Pat From buc at odusz.so-cdu.ru Fri May 11 13:28:45 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 17:28:45 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> Message-ID: <46446F8D.7070100@odu.neva.ru> Randy Wyatt wrote: > Why wouldn't a hard copy of the GPL suffice ? Yep, but GPL is not approrved officially in our (and many other) countries. I know that some users do notarially certified translation of GPL, but it costs money too. (Hopefully the ranslation of GPL only is enough, not BSD, MPL etc.) > > On 5/11/07, *Dmitry Butskoy* > wrote: > > The using of software in business and production environment can be a > subject for legislative regulation. It can lead to some legal > troubles > of using of distributions like Fedora. > [snip] ~buc From atkac at redhat.com Fri May 11 13:37:21 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 11 May 2007 15:37:21 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511131638.GA4791@free.fr> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> Message-ID: <46447191.3030508@redhat.com> Patrice Dumas napsal(a): > On Fri, May 11, 2007 at 04:54:43AM -0400, Adam Tkac wrote: > >> Author: atkac >> >> mtools-3.9.10-sh.patch: >> > > I may be completly wrong, but in my recollection using > arithmetic/conditionals like > > >> +if [[ $# -eq 0 ]] ; then >> > > is not sh compatible but requires some bash extensions. > It should be, instead, along > > if [ $# = 0 ]; then > > == also in [ ] is not portable. > > I am not sure and this would benefit from double checking. In any > case, for fedora it should be fine even with the bash extensions, and > the shebang also may be changed to > #! /bin/bash > to be safe, but if it is to be submitted upstream (as it should be) > you should really take care that no bash extensions are used. > > -- > Pat > > Ah, I've tested it on my rawhide machine and I forgot that sh is symlink to bash ( => script works for me) :) I'm going to change /bin/sh to /bin/bash immediately. Regards, -A- From nicu_fedora at nicubunu.ro Fri May 11 13:35:06 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 11 May 2007 16:35:06 +0300 Subject: Legality of Fedora in production environment In-Reply-To: <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> Message-ID: <4644710A.2080409@nicubunu.ro> Randy Wyatt wrote: > Why wouldn't a hard copy of the GPL suffice ? Because such laws are usually made by direct command from BSA and contain specific wording. I heard some similar scary things about a law in my country (Romania) where exist a national registry for computer programs and you are supposed to use only software registered there. I don't know much about it as I am not an expert in law, but it seems the law is ignored by users and not enforced against free software (so far). > On 5/11/07, *Dmitry Butskoy* > wrote: > > The using of software in business and production environment can be a > subject for legislative regulation. It can lead to some legal troubles > of using of distributions like Fedora. > > Recently the appropriate laws in my country (Russia) have been > significantly toughened. Now the police can check for illegal software > usage by their own initiative (without request from the owner). The tax > inspection demands that software should be registered at accounts > departments. -- 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 pertusus at free.fr Fri May 11 13:29:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 May 2007 15:29:12 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <46446F8D.7070100@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> Message-ID: <20070511132912.GC4791@free.fr> On Fri, May 11, 2007 at 05:28:45PM +0400, Dmitry Butskoy wrote: > Randy Wyatt wrote: > >Why wouldn't a hard copy of the GPL suffice ? > Yep, but GPL is not approrved officially in our (and many other) > countries. I know that some users do notarially certified translation of > GPL, but it costs money too. (Hopefully the ranslation of GPL only is > enough, not BSD, MPL etc.) since Russia is a member of the Berne Convention, if I recall well, some lawyer consider that there shouldn't be a need for a translation and even that no translation is better. I know that it depends on the lawyer since, in France there is a dispute against those who think that since the GPL has some clauses that don't translate easily to french law it is not applicable and those who think that under the Bern Convention the GPL should be reinterpretated in the context of the French laws. In any case I am not convinced that this discussion belongs to fedora-devel-list, although I am not sure that there exists a list about those kind of issues. -- Pat From pertusus at free.fr Fri May 11 13:31:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 May 2007 15:31:58 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <46447191.3030508@redhat.com> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> <46447191.3030508@redhat.com> Message-ID: <20070511133158.GD4791@free.fr> On Fri, May 11, 2007 at 03:37:21PM +0200, Adam Tkac wrote: > > > Ah, I've tested it on my rawhide machine and I forgot that sh is symlink > to bash ( => script works for me) :) I am not sure, but I guess that we can consider that in fedora it is always the case that sh is bash, so there is no real need to change the shebang (although it would be cleaner). It is more important for submission upstream. -- Pat From ssorce at redhat.com Fri May 11 13:52:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 May 2007 09:52:43 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070511132912.GC4791@free.fr> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> Message-ID: <1178891564.12871.2.camel@willson> On Fri, 2007-05-11 at 15:29 +0200, Patrice Dumas wrote: > On Fri, May 11, 2007 at 05:28:45PM +0400, Dmitry Butskoy wrote: > > Randy Wyatt wrote: > > >Why wouldn't a hard copy of the GPL suffice ? > > Yep, but GPL is not approrved officially in our (and many other) > > countries. I know that some users do notarially certified translation of > > GPL, but it costs money too. (Hopefully the ranslation of GPL only is > > enough, not BSD, MPL etc.) > > since Russia is a member of the Berne Convention, if I recall well, some > lawyer consider that there shouldn't be a need for a translation and > even that no translation is better. I know that it depends on the lawyer > since, in France there is a dispute against those who think that since > the GPL has some clauses that don't translate easily to french law it is > not applicable and those who think that under the Bern Convention the > GPL should be reinterpretated in the context of the French laws. > > In any case I am not convinced that this discussion belongs to > fedora-devel-list, although I am not sure that there exists a list about > those kind of issues. This is definitively a more general Free Software problem. The law there is obviously broken but there is nothing you can except lobbying for amendments in appropriate forums. Meanwhile I guess the easiest thing you can do is to print the license agreement shown to you by the fedora installer, in English, and show it to the authorities. Simo. From jwboyer at jdub.homelinux.org Fri May 11 13:46:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 08:46:39 -0500 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511133158.GD4791@free.fr> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> <46447191.3030508@redhat.com> <20070511133158.GD4791@free.fr> Message-ID: <1178891199.29429.22.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 15:31 +0200, Patrice Dumas wrote: > On Fri, May 11, 2007 at 03:37:21PM +0200, Adam Tkac wrote: > > > > > Ah, I've tested it on my rawhide machine and I forgot that sh is symlink > > to bash ( => script works for me) :) > > I am not sure, but I guess that we can consider that in fedora it is > always the case that sh is bash, so there is no real need to change the > shebang (although it would be cleaner). It is more important for > submission upstream. I'd rather it be explicit if it relies on bash-isms. I think switching the shebang is correct enough _and_ cleaner as you point out. josh From alan at redhat.com Fri May 11 14:02:43 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 11 May 2007 10:02:43 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <46446924.1080209@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> Message-ID: <20070511140243.GB21356@devserv.devel.redhat.com> On Fri, May 11, 2007 at 05:01:24PM +0400, Dmitry Butskoy wrote: > During such a checking, the user is obliged now to show all hardcopy > license documents (with original signatures and stamps). But there are > no any such things for distros like Fedora, which have been just > downloaded from Internet, hence the user shows nothing. In this > situation the police *must* temporarily confiscate system blocks (up to > 2 weeks) for further checking... > Certainly, after the checking period all hardware comes back, but such > troubles are not allowed for normal business. > > > Are there any similar troubles in other countries? Not that I am aware of. There are plenty of countries where the state is empowered to enforce copyright but they don't usually require bogus paperwork. > How it can be avoided? Print out your own copy ? Or if there is a requirement that it comes from the "supplier" then perhaps someone can prepare a suitable example on the Fedora website that anyone can download, sign for themselves and print out. I've met people who worked in companies with similar idiotic audit policies and they used to just print out the GPL Since you apparently have a boxed set supplier who is empowered somehow to print such certificates then presumably anyone else can with a bit of thinking set up the same way. Alan From buc at odusz.so-cdu.ru Fri May 11 14:03:32 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 18:03:32 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070511132912.GC4791@free.fr> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> Message-ID: <464477B4.7010509@odu.neva.ru> Patrice Dumas wrote: > On Fri, May 11, 2007 at 05:28:45PM +0400, Dmitry Butskoy wrote: > >> Randy Wyatt wrote: >> >>> Why wouldn't a hard copy of the GPL suffice ? >>> >> Yep, but GPL is not approrved officially in our (and many other) >> countries. I know that some users do notarially certified translation of >> GPL, but it costs money too. (Hopefully the ranslation of GPL only is >> enough, not BSD, MPL etc.) >> > > since Russia is a member of the Berne Convention, if I recall well, some > lawyer consider that there shouldn't be a need for a translation and > even that no translation is better. Yes. It is the reason why hardware "comes back after the 2 week checking". Fortunately. > In any case I am not convinced that this discussion belongs to > fedora-devel-list, although I am not sure that there exists a list about > those kind of issues. > "Fedora-devel" implies not home enthusiasts only. Normally a lot of things we use in some non-home place, and all such places are affected. Consider the situation: you go to your employer and say "I want to help to develop Fedora, let's change our, say RHEL2, server to Fedora 7, I can guarantee that I'm skilled enough to support this". What the employer shoild answer? "No, I don't want troubles wiith policy, because your Fedora is not accompanied with any hard copy legal documents". :( ~buc From opensource at till.name Fri May 11 14:08:41 2007 From: opensource at till.name (Till Maas) Date: Fri, 11 May 2007 16:08:41 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511133158.GD4791@free.fr> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <46447191.3030508@redhat.com> <20070511133158.GD4791@free.fr> Message-ID: <200705111608.42693.opensource@till.name> On Fr Mai 11 2007, Patrice Dumas wrote: > I am not sure, but I guess that we can consider that in fedora it is > always the case that sh is bash, so there is no real need to change the > shebang (although it would be cleaner). It is more important for > submission upstream. The beheaviof of bash changes, when it is invocated as sh, i.e. it reads other startup files and changes to posix mode. (man bash -> INVOCATION) Regards, Till From kwizart at gmail.com Fri May 11 14:14:43 2007 From: kwizart at gmail.com (KH KH) Date: Fri, 11 May 2007 16:14:43 +0200 Subject: (co)maintainers wanted In-Reply-To: <1178889718.4477.28.camel@localhost.localdomain> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> <1178882756.4477.15.camel@localhost.localdomain> <20070511151216.0fc784a0@spica.a.lan> <1178889718.4477.28.camel@localhost.localdomain> Message-ID: 2007/5/11, Alexander Larsson : > On Fri, 2007-05-11 at 15:12 +0200, Andreas Bierfert wrote: > > On Fri, 11 May 2007 13:25:56 +0200 > > Alexander Larsson wrote: > > > > > > CC:in andreas. Are you interested in this? > > > > Sure. I do maintain it for EPEL and for FE <= 4? I believe so should not be to > > much trouble... > > Good. You'll be primary mantainer then. > Nicolas, do you still want to be comaintainer? Well my interested in lcms for the short term is to update it 1.16 for FC-6. But i understand we have to discuss it... I can also maintain it for the long term. (if Andreas accept) @Andreas. Can you say why it shoudn't be updated ? I have provided some arguments to do so. I would like to have an argumented answear also... That would be kind. :) Thx Nicolas (kwizart) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a scarfaced crooked werewolf living undercover at Ringling Bros. Circus. > She's a blind gold-digging traffic cop with someone else's memories. They > fight crime! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From alan at redhat.com Fri May 11 14:26:52 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 11 May 2007 10:26:52 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4644710A.2080409@nicubunu.ro> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <4644710A.2080409@nicubunu.ro> Message-ID: <20070511142652.GE21356@devserv.devel.redhat.com> On Fri, May 11, 2007 at 04:35:06PM +0300, Nicu Buculei wrote: > supposed to use only software registered there. I don't know much about > it as I am not an expert in law, but it seems the law is ignored by > users and not enforced against free software (so far). That would appear to violate EU single market law fortunately so hopefully its a byproduct of a byegone and dead age.. From buc at odusz.so-cdu.ru Fri May 11 14:32:08 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 18:32:08 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070511140243.GB21356@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> Message-ID: <46447E68.2030408@odu.neva.ru> Simo Source wrote: > Meanwhile I guess the easiest thing you can do is to print the license > agreement shown to you by the fedora installer, in English, and show it > to the authorities. ... Alan Cox wrote: > Print out your own copy ? Or if there is a requirement that it comes from > the "supplier" then perhaps someone can prepare a suitable example on the > Fedora website that anyone can download, sign for themselves and print out. > In other words, print some couple of documents (license agreement + GPL, at least) and accompany them by their notarially certified translation (just for police who do not know English)... Ideally, it could be nice to have some "official supplier" for Fedora, who can send the user some hard copy document in its language... In other words, to create all needed translations at once, and then send hard copy (with the individual user's requisites) by request. Perhaps with a little cost... ~buc From jwboyer at jdub.homelinux.org Fri May 11 14:29:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 09:29:16 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <464477B4.7010509@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> Message-ID: <1178893756.29429.40.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 18:03 +0400, Dmitry Butskoy wrote: > Patrice Dumas wrote: > > On Fri, May 11, 2007 at 05:28:45PM +0400, Dmitry Butskoy wrote: > > > >> Randy Wyatt wrote: > >> > >>> Why wouldn't a hard copy of the GPL suffice ? > >>> > >> Yep, but GPL is not approrved officially in our (and many other) > >> countries. I know that some users do notarially certified translation of > >> GPL, but it costs money too. (Hopefully the ranslation of GPL only is > >> enough, not BSD, MPL etc.) > >> > > > > since Russia is a member of the Berne Convention, if I recall well, some > > lawyer consider that there shouldn't be a need for a translation and > > even that no translation is better. > Yes. It is the reason why hardware "comes back after the 2 week > checking". Fortunately. > > In any case I am not convinced that this discussion belongs to > > fedora-devel-list, although I am not sure that there exists a list about > > those kind of issues. > > > "Fedora-devel" implies not home enthusiasts only. Normally a lot of > things we use in some non-home place, and all such places are affected. > > Consider the situation: you go to your employer and say "I want to help > to develop Fedora, let's change our, say RHEL2, server to Fedora 7, I > can guarantee that I'm skilled enough to support this". What the > employer shoild answer? "No, I don't want troubles wiith policy, because > your Fedora is not accompanied with any hard copy legal documents". :( The Fedora wiki pages link to a list of all approved licenses for packages. You could systematically go through and print off each of these. It's a bit hard for Fedora to distribute hard copy material given that Fedora doesn't distribute anything physical. josh From alan at redhat.com Fri May 11 14:42:41 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 11 May 2007 10:42:41 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <46447E68.2030408@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46447E68.2030408@odu.neva.ru> Message-ID: <20070511144241.GA23756@devserv.devel.redhat.com> On Fri, May 11, 2007 at 06:32:08PM +0400, Dmitry Butskoy wrote: > In other words, print some couple of documents (license agreement + GPL, > at least) and accompany them by their notarially certified translation > (just for police who do not know English)... Do you need the entire text ? Would a page on the web site with a print your own that only had the following translated be sufficient ? (and possibly an arty 'looks like a legal document' background) [and I'm not a lawyer so legal would probably play with this text and don't take it as anything but an idea] 'The Fedora Project hereby certifies that $ORGANISATION as recipient of license #$LICENSE has the right to use, modify and redistribute the Fedora software in accordance with the precise terms found at [URL], and that this license is for an unlimited number of users and systems' [Fedora Project Contact Details] [Users filled in details] [Date] Alan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 11 14:44:39 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 11 May 2007 16:44:39 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511131638.GA4791@free.fr> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> Message-ID: <20070511164439.211c6561@python3.es.egwn.lan> Patrice Dumas wrote : > On Fri, May 11, 2007 at 04:54:43AM -0400, Adam Tkac wrote: > > Author: atkac > > > > mtools-3.9.10-sh.patch: > > I may be completly wrong, but in my recollection using > arithmetic/conditionals like > > > +if [[ $# -eq 0 ]] ; then > > is not sh compatible but requires some bash extensions. > It should be, instead, along > > if [ $# = 0 ]; then > > == also in [ ] is not portable. > > I am not sure and this would benefit from double checking. In any > case, for fedora it should be fine even with the bash extensions, and > the shebang also may be changed to > #! /bin/bash > to be safe, but if it is to be submitted upstream (as it should be) > you should really take care that no bash extensions are used. I had never seen double square brackets before, and it seems to work, suggesting some kind of bash internal indeed... but as for plain single square brackets, I thought "[" was a symlink to the coreutils "test" command, but just saw on my FC6 workstation that this is no longer the case and that those are two different binaries now. -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[ -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test This is all now way more complicated than I would have thought :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.34 0.36 0.35 From bkoz at redhat.com Fri May 11 14:52:51 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Fri, 11 May 2007 16:52:51 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <20070511140243.GB21356@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> Message-ID: <46448343.5050504@redhat.com> > Print out your own copy ? Or if there is a requirement that it comes from > the "supplier" then perhaps someone can prepare a suitable example on the > Fedora website that anyone can download, sign for themselves and print out. I volunteer to make such a document for Fedora, as elaborate as is still printable with inkscape, if provided with appropriate wording. Dimitry, can you send me or post and example of what it is expected in this certificate? A good place to start might be the certificates used by other Free software distributors in your country. I've had to do similar things in my tangles with French fonctionnaires. I can tell you right now that attaching a shiny metallic stamp will improve your chances 2x. -benjamin From tcallawa at redhat.com Fri May 11 14:53:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 11 May 2007 09:53:34 -0500 Subject: kernel package In-Reply-To: <1178884157.21820.37.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> Message-ID: <1178895214.7756.4.camel@localhost.localdomain> On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote: > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > > doin' much; that's why CC:) willing to help AlphaCore and add patches to > > kernel spec? > > > > No, it's nothing for upstream. Just fixes for the spec. Some > > if(n)arch's, sections for alpha, a config, ... Nothing that should break > > primary archs... > > We don't like ifarches. Why? The utrace patch is the biggest concern here, really. Not that it's bad code, but its a significant divergence from upstream, and it doesn't work on sparc32 (and presumably, alpha). Aurora is %ifarch conditionalizing that patch (and one later patch that has to be modified slightly for the old ptrace behavior) in our kernels as well. ~spot From buc at odusz.so-cdu.ru Fri May 11 14:58:24 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 18:58:24 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <1178893756.29429.40.camel@zod.rchland.ibm.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> Message-ID: <46448490.5040308@odu.neva.ru> Josh Boyer wrote: > The Fedora wiki pages link to a list of all approved licenses for > packages. You could systematically go through and print off each of > these. > > In general, some of packages can have its unique licenses, which compatible with Fedora, but have its own text... > It's a bit hard for Fedora to distribute hard copy material given that > Fedora doesn't distribute anything physical. > But it is more hard for individual user to print, translate and certify. Moreover, there are enough troubles with "Fedora in production environment" due to innovations/stabilities. An addition of legal issues can just kill it. Theoretically, it can lead to a situation, when RHEL, based on Fedora as the upstream, will be based on distro which actually is not used/tested anywhere in business/production. ~buc From buc at odusz.so-cdu.ru Fri May 11 15:08:59 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 19:08:59 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070511144241.GA23756@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46447E68.2030408@odu.neva.ru> <20070511144241.GA23756@devserv.devel.redhat.com> Message-ID: <4644870B.7080804@odu.neva.ru> Alan Cox wrote: > On Fri, May 11, 2007 at 06:32:08PM +0400, Dmitry Butskoy wrote: > >> In other words, print some couple of documents (license agreement + GPL, >> at least) and accompany them by their notarially certified translation >> (just for police who do not know English)... >> > > Do you need the entire text ? > > Would a page on the web site with a print your own that only had the following > translated be sufficient ? (and possibly an arty 'looks like a legal document' > background) > > [and I'm not a lawyer so legal would probably play with this text and don't > take it as anything but an idea] > > 'The Fedora Project hereby certifies that $ORGANISATION as recipient of > license #$LICENSE has the right to use, modify and redistribute the Fedora > software in accordance with the precise terms found at [URL], and that this > license is for an unlimited number of users and systems' > > [Fedora Project Contact Details] > > [Users filled in details] > > [Date] > AFAIK sometimes it is enough to send a document by fax... The Fedora user could fill some form on the web site, and receive an image. If the hard copy is strong required, such an image (with stamps etc.) could be send for user physically. The idea is similar to how RHCE certificates are sent (first an image, then hard copy by post). ~buc From jwboyer at jdub.homelinux.org Fri May 11 15:08:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 10:08:08 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <46448490.5040308@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> Message-ID: <1178896088.29429.55.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > Josh Boyer wrote: > > The Fedora wiki pages link to a list of all approved licenses for > > packages. You could systematically go through and print off each of > > these. > > > > > In general, some of packages can have its unique licenses, which > compatible with Fedora, but have its own text... True. > > It's a bit hard for Fedora to distribute hard copy material given that > > Fedora doesn't distribute anything physical. > > > > But it is more hard for individual user to print, translate and certify. I always forget about translating. I blame it on me being a stupid US born citizen. > Moreover, there are enough troubles with "Fedora in production > environment" due to innovations/stabilities. An addition of legal issues > can just kill it. > Theoretically, it can lead to a situation, when RHEL, based on Fedora as > the upstream, will be based on distro which actually is not used/tested > anywhere in business/production. I understand your concern, but unfortunately I don't see how Fedora as a project can really help here... josh From fedora at camperquake.de Fri May 11 15:19:33 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 11 May 2007 17:19:33 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: References: <20070508130336.GB23247@redhat.com> Message-ID: <20070511171933.77e4d81f@banea.int.addix.net> Hi. On 10 May 2007 13:29:11 -0500, Jason L Tibbitts III wrote: > Here's the oops; I think this is mostly unchanged from what I reported > before on fedora-kernel but perhaps it will be useful nonetheless. I get the same oops, but my mouse/keyboard stay functional (Thinkpad X60s). Nonetheless, the system is severely fudged afterwards :) From jwboyer at jdub.homelinux.org Fri May 11 15:13:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 10:13:21 -0500 Subject: kernel package In-Reply-To: <1178895214.7756.4.camel@localhost.localdomain> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> <1178895214.7756.4.camel@localhost.localdomain> Message-ID: <1178896401.29429.59.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote: > > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > > > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > > > doin' much; that's why CC:) willing to help AlphaCore and add patches to > > > kernel spec? > > > > > > No, it's nothing for upstream. Just fixes for the spec. Some > > > if(n)arch's, sections for alpha, a config, ... Nothing that should break > > > primary archs... > > > > We don't like ifarches. Why? > > The utrace patch is the biggest concern here, really. Not that it's bad > code, but its a significant divergence from upstream, and it doesn't > work on sparc32 (and presumably, alpha). Aurora is %ifarch > conditionalizing that patch (and one later patch that has to be modified > slightly for the old ptrace behavior) in our kernels as well. Does it apply? Seems there's a config option for it... you could just leave that disabled in your .configs. josh From fkautz at pseudocode.cc Fri May 11 15:33:55 2007 From: fkautz at pseudocode.cc (Frederick F. Kautz IV) Date: Fri, 11 May 2007 09:33:55 -0600 (MDT) Subject: Legality of Fedora in production environment In-Reply-To: <20070511132912.GC4791@free.fr> References: <46446924.1080209@odu.neva.ru><34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com><46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> Message-ID: I would also highly recommend contacting the FSF on this matter. Perhaps they can make a recommendation on what action should be taken. We can definitely do things to help on our side, such as the document proposed by Benjamin Kosnik. However, this affects all open source software and not just Fedora. Here is the e-mail address for contacting FSF on this issue: licensing at fsf.org Hopefully, printing/signing the GPL (or whatever license is used) will suffice. If this is the case, we may be able to write a small script/application included in Fedora that scans the License field on installed RPMs to and generates a list of what licenses apply and a verbose flag that also specifies what software falls under each license. -- Frederick F. Kautz IV On Fri, 11 May 2007, Patrice Dumas wrote: > On Fri, May 11, 2007 at 05:28:45PM +0400, Dmitry Butskoy wrote: >> Randy Wyatt wrote: >>> Why wouldn't a hard copy of the GPL suffice ? >> Yep, but GPL is not approrved officially in our (and many other) >> countries. I know that some users do notarially certified translation of >> GPL, but it costs money too. (Hopefully the ranslation of GPL only is >> enough, not BSD, MPL etc.) > > since Russia is a member of the Berne Convention, if I recall well, some > lawyer consider that there shouldn't be a need for a translation and > even that no translation is better. I know that it depends on the lawyer > since, in France there is a dispute against those who think that since > the GPL has some clauses that don't translate easily to french law it is > not applicable and those who think that under the Bern Convention the > GPL should be reinterpretated in the context of the French laws. > > In any case I am not convinced that this discussion belongs to > fedora-devel-list, although I am not sure that there exists a list about > those kind of issues. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From drago01 at gmail.com Fri May 11 15:38:40 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 11 May 2007 17:38:40 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <46448E00.5000806@gmail.com> I tryed 3145 (on x86_64). it works fine but when I disconnect and try to reconnect I get an oops. upstream (james) suggested a patch which I tryed to... I got no more oops but wpa_supplicant hangs when I press ctrl+c and sometimes the whole system hangs too ( not completly but I can't do anything). here is the patch: http://sourceforge.net/mailarchive/message.php?msg_name=463F6CD7.4090501%40linux.intel.com From buc at odusz.so-cdu.ru Fri May 11 15:42:10 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 19:42:10 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <46448343.5050504@redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> Message-ID: <46448ED2.1020704@odu.neva.ru> Benjamin Kosnik wrote: > >> Print out your own copy ? Or if there is a requirement that it comes >> from >> the "supplier" then perhaps someone can prepare a suitable example on >> the >> Fedora website that anyone can download, sign for themselves and >> print out. > > I volunteer to make such a document for Fedora, as elaborate as is > still printable with inkscape, if provided with appropriate wording. > > Dimitry, can you send me or post and example of what it is expected in > this certificate? A good place to start might be the certificates used > by other Free software distributors in your country. Yes, I have some examples (in Russian). But there is no guarantee that it contains "currently expected" text... As I understand, when our local distributors say "don't download, buy our box with a paper", it is some kind of business for them -- i.e. to intimidate users and to force them to buy their boxes instead of free download. Currently I am even not sure that such a solution actually work, but they recommend it. Actually, I heard about several precedents, where users was affected by hard copy absence, but is is not too often, at least now. Therefore I decide to post here about the problem, to prevent (at least partially) possible user troubles in the future. > what it is expected in this certificate? Expected by whom?... By the checking policeman?.. I think the text should be "as robast, as possible". Besides the "unlimited number of users and systems", it should say that "the holographic label is not required", that the label on the case "designed for M*crosoft" does not conflict with, etc. BTW, one of the precedents is when sysadmin was arrested for absence of holographic labels on a computer with Linux. (Next day was released, surely). The police was instructed that each server must have holographic... ~buc From davej at redhat.com Fri May 11 15:42:27 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 11 May 2007 11:42:27 -0400 Subject: kernel package In-Reply-To: <1178896401.29429.59.camel@zod.rchland.ibm.com> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> <1178895214.7756.4.camel@localhost.localdomain> <1178896401.29429.59.camel@zod.rchland.ibm.com> Message-ID: <20070511154227.GA8976@redhat.com> On Fri, May 11, 2007 at 10:13:21AM -0500, Josh Boyer wrote: > On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote: > > On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote: > > > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > > > > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > > > > doin' much; that's why CC:) willing to help AlphaCore and add patches to > > > > kernel spec? > > > > > > > > No, it's nothing for upstream. Just fixes for the spec. Some > > > > if(n)arch's, sections for alpha, a config, ... Nothing that should break > > > > primary archs... > > > > > > We don't like ifarches. Why? > > > > The utrace patch is the biggest concern here, really. Not that it's bad > > code, but its a significant divergence from upstream, and it doesn't > > work on sparc32 (and presumably, alpha). Aurora is %ifarch > > conditionalizing that patch (and one later patch that has to be modified > > slightly for the old ptrace behavior) in our kernels as well. > > Does it apply? Seems there's a config option for it... you could just > leave that disabled in your .configs. Problem is (AIUI) that doing that would remove ptrace functionality completely. With the patch applied, ptrace is implemented as a 'personality' of utrace. Dave -- http://www.codemonkey.org.uk From alan at redhat.com Fri May 11 15:56:36 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 11 May 2007 11:56:36 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <46448ED2.1020704@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> Message-ID: <20070511155636.GA27804@devserv.devel.redhat.com> On Fri, May 11, 2007 at 07:42:10PM +0400, Dmitry Butskoy wrote: > As I understand, when our local distributors say "don't download, buy > our box with a paper", it is some kind of business for them -- i.e. to > intimidate users and to force them to buy their boxes instead of free > download. Currently I am even not sure that such a solution actually > work, but they recommend it. If Russian bussiness people are like everyone else then I bet there are even some enterprising ones pushing the police to "enforce" this .. > I think the text should be "as robast, as possible". Besides the > "unlimited number of users and systems", it should say that "the > holographic label is not required", that the label on the case "designed > for M*crosoft" does not conflict with, etc. We can sort that out I think "The print of this certificate can be compared with the web page at ...... " (and that web page can also have an FAQ for stupid policemen) In theory you could store each "license document" owner name you hand out and invite them to enter it into a web form for verification and have it report the organisation the license is for etc to make it look good. > BTW, one of the precedents is when sysadmin was arrested for absence of > holographic labels on a computer with Linux. (Next day was released, > surely). The police was instructed that each server must have holographic... Some stupidity is only correctable by learning. Even in the UK we've had minor incidents with well meaning trading standards people trying to seize "pirate" copies of Linux (because they were on CD-R so clearly pirate). Nowdays they've learned for the most part 8) Alan From alan at clueserver.org Fri May 11 15:57:16 2007 From: alan at clueserver.org (alan) Date: Fri, 11 May 2007 08:57:16 -0700 (PDT) Subject: Legality of Fedora in production environment In-Reply-To: <46446924.1080209@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> Message-ID: On Fri, 11 May 2007, Dmitry Butskoy wrote: > The using of software in business and production environment can be a subject > for legislative regulation. It can lead to some legal troubles of using of > distributions like Fedora. > > Recently the appropriate laws in my country (Russia) have been significantly > toughened. Now the police can check for illegal software usage by their own > initiative (without request from the owner). The tax inspection demands that > software should be registered at accounts departments. > > During such a checking, the user is obliged now to show all hardcopy license > documents (with original signatures and stamps). But there are no any such > things for distros like Fedora, which have been just downloaded from > Internet, hence the user shows nothing. In this situation the police *must* > temporarily confiscate system blocks (up to 2 weeks) for further checking... > Certainly, after the checking period all hardware comes back, but such > troubles are not allowed for normal business. > > > Are there any similar troubles in other countries? > > How it can be avoided? Scribus and a color printer? With the proper tools you can make something that looks "official". Howe do they know the stamps and discs for the proprietary stuff are "real". Sounds like your local vendor is using the bad law to their advantage. -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox From bkoz at redhat.com Fri May 11 15:59:04 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Fri, 11 May 2007 17:59:04 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <46448ED2.1020704@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> Message-ID: <464492C8.60707@redhat.com> > Yes, I have some examples (in Russian). But there is no guarantee that > it contains "currently expected" text... It looks like Alan has the beginnings of something that we can use for the text. In the meantime, you should try to scan/take photos of these certificates, put them up on the web, and send a link to the images to this thread. In addition, if translations to English could be provided then that would be very helpful. > As I understand, when our local distributors say "don't download, buy > our box with a paper", it is some kind of business for them -- i.e. to > intimidate users and to force them to buy their boxes instead of free > download. Currently I am even not sure that such a solution actually > work, but they recommend it. How unfortunate. Sadly, that's not something the Fedora project or any of the individuals associated with it can do anything about. However, what we can do is come up with an elaborate certificate, suitable for printing and stickering, capable of being beribboned, etc. Note this is not an actual legal document. > Expected by whom?... By the checking policeman?.. Yes. > I think the text should be "as robast, as possible". Besides the > "unlimited number of users and systems", it should say that "the > holographic label is not required", that the label on the case "designed > for M*crosoft" does not conflict with, etc. > > BTW, one of the precedents is when sysadmin was arrested for absence of > holographic labels on a computer with Linux. (Next day was released, > surely). The police was instructed that each server must have > holographic... This seems like something that your local linux LUG, Unix group, or EFF should try to straighten out. best, -benjamin From ssorce at redhat.com Fri May 11 15:59:21 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 May 2007 11:59:21 -0400 Subject: Legality of Fedora in production environment In-Reply-To: References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> Message-ID: <1178899161.12871.7.camel@willson> On Fri, 2007-05-11 at 09:33 -0600, Frederick F. Kautz IV wrote: > I would also highly recommend contacting the FSF on this matter. Perhaps > they can make a recommendation on what action should be taken. We can > definitely do things to help on our side, such as the document proposed by > Benjamin Kosnik. However, this affects all open source software and not > just Fedora. Here is the e-mail address for contacting FSF on this issue: > > licensing at fsf.org > > Hopefully, printing/signing the GPL (or whatever license is used) will > suffice. If this is the case, we may be able to write a small > script/application included in Fedora that scans the License field on > installed RPMs to and generates a list of what licenses apply and a > verbose flag that also specifies what software falls under each license. I don't think you need each license printed, not even the GPL. This is the police wondering if the software on the PC has been legally obtained. We probably just need a document clearly written, with the right legal words for Russia, where Fedora grants the user the right to use the distribution as a whole on any number of machines, for an unlimited time, and includes grants to install updates _and_ upgrades as well under the same terms. Have the same document available on a clearly recognizable Fedora domain name, so that you can show the police that it is not a forged document, and on the site only may be have another page with the detailed set of licenses for the picky ones. Simo. From buc at odusz.so-cdu.ru Fri May 11 16:18:05 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 20:18:05 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <1178899161.12871.7.camel@willson> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <1178899161.12871.7.camel@willson> Message-ID: <4644973D.5040202@odu.neva.ru> Simo Sorce wrote: > We probably just need a document clearly written, with the right legal > words for Russia, Not for Russia only! In general, such a document could be useful for all supported locales. > where Fedora grants the user the right to use the > distribution as a whole on any number of machines, for an unlimited > time, and includes grants to install updates _and_ upgrades as well > under the same terms. > > Have the same document available on a clearly recognizable Fedora domain > name, so that you can show the police that it is not a forged document, > and on the site only may be have another page with the detailed set of > licenses for the picky ones. > ~buc From skasal at redhat.com Fri May 11 16:22:55 2007 From: skasal at redhat.com (Stepan Kasal) Date: Fri, 11 May 2007 18:22:55 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511164439.211c6561@python3.es.egwn.lan> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> <20070511164439.211c6561@python3.es.egwn.lan> Message-ID: <20070511162255.GA24418@camelia.ucw.cz> Hi, On Fri, May 11, 2007 at 04:44:39PM +0200, Matthias Saou wrote: > single square brackets, I thought "[" was a symlink to the > coreutils "test" command, [..] AFAIK, it used to be hard link, not symlink. > -rwxr-xr-x 1 root root 32168 Apr 17 13:48 /usr/bin/[ > -rwxr-xr-x 1 root root 29544 Apr 17 13:48 /usr/bin/test GNU Coding Standards now declare that the behaviour of binary should not depend on its name. Stepan From atkac at redhat.com Fri May 11 16:27:32 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 11 May 2007 18:27:32 +0200 Subject: rpms/mtools/devel mtools-3.9.10-sh.patch,NONE,1.1 In-Reply-To: <20070511162255.GA24418@camelia.ucw.cz> References: <200705110854.l4B8sh5a010671@cvs-int.fedora.redhat.com> <20070511131638.GA4791@free.fr> <20070511164439.211c6561@python3.es.egwn.lan> <20070511162255.GA24418@camelia.ucw.cz> Message-ID: <46449974.6020205@redhat.com> In the end script has been completely rewritten by Stepan Kasal and could be POSIX compatible :) -A- From alan at clueserver.org Fri May 11 16:26:10 2007 From: alan at clueserver.org (alan) Date: Fri, 11 May 2007 09:26:10 -0700 (PDT) Subject: Legality of Fedora in production environment In-Reply-To: <4644973D.5040202@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <1178899161.12871.7.camel@willson> <4644973D.5040202@odu.neva.ru> Message-ID: On Fri, 11 May 2007, Dmitry Butskoy wrote: > Simo Sorce wrote: >> We probably just need a document clearly written, with the right legal >> words for Russia, > > Not for Russia only! In general, such a document could be useful for all > supported locales. >> where Fedora grants the user the right to use the >> distribution as a whole on any number of machines, for an unlimited >> time, and includes grants to install updates _and_ upgrades as well >> under the same terms. >> >> Have the same document available on a clearly recognizable Fedora domain >> name, so that you can show the police that it is not a forged document, >> and on the site only may be have another page with the detailed set of >> licenses for the picky ones. Sounds like an interesting graphics arts project. A do-it-yourself official licence kit for free software. It would need lots of stickers, graphics, and the other useless dohickies that come with the "real" software licences. (The image that comes to mind is a long medaeval scroll with lots of illumination, wax seals and the like.) -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox From nicolas.mailhot at laposte.net Fri May 11 16:30:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 11 May 2007 18:30:36 +0200 Subject: Legality of Fedora in production environment In-Reply-To: References: <46446924.1080209@odu.neva.ru> Message-ID: <1178901036.1172.7.camel@rousalka.dyndns.org> Le vendredi 11 mai 2007 ? 08:57 -0700, alan a ?crit : > Scribus and a color printer? With the proper tools you can make something > that looks "official". They are probably trained to recognize inkjet prints, as making something that looks "official" also occurred to real thieves. -- 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 buc at odusz.so-cdu.ru Fri May 11 16:34:11 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 11 May 2007 20:34:11 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <464492C8.60707@redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> Message-ID: <46449B03.1070700@odu.neva.ru> Benjamin Kosnik wrote: > > In the meantime, you should try to scan/take photos of these > certificates, put them up on the web, and send a link to the images to > this thread. Well, Some good example: (ALTLinux is on of the leading local russian distributions): in English: ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt in Russian: ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt.ru ~buc From jkeating at redhat.com Fri May 11 16:35:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 May 2007 09:35:55 -0700 Subject: comps in the new merged world In-Reply-To: <46440FD1.1070709@hhs.nl> References: <46440FD1.1070709@hhs.nl> Message-ID: <200705110935.55606.jkeating@redhat.com> On Thursday 10 May 2007 23:40:17 Hans de Goede wrote: > Back in the old FE days, when one wanted to add something to comps, one > just edited the comps-feX.xml.in file in the CVS comps module. > > How does one add something to comps for F7, or has this not changed? Edit comps-f7.xml.in -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri May 11 16:37:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 May 2007 22:07:41 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <46449B03.1070700@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> <46449B03.1070700@odu.neva.ru> Message-ID: <46449BD5.3090605@fedoraproject.org> Dmitry Butskoy wrote: > Benjamin Kosnik wrote: >> >> In the meantime, you should try to scan/take photos of these >> certificates, put them up on the web, and send a link to the images to >> this thread. > > Well, > > Some good example: > (ALTLinux is on of the leading local russian distributions): > > in English: > ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt > in Russian: > ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt.ru We have something similar at http://fedoraproject.org/wiki/Legal/Licenses/EULA Rahul From notting at redhat.com Fri May 11 17:08:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 13:08:32 -0400 Subject: Need help with libgda build failure on ppc64 In-Reply-To: References: <464395F5.5070600@hhs.nl> <20070510221351.GA21734@nostromo.devel.redhat.com> <20070510224109.GA22171@nostromo.devel.redhat.com> Message-ID: <20070511170832.GG2444@nostromo.devel.redhat.com> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > > I'm afraid it isn't that easy, I added this sed command: > sed -i 's/x86_64\* | sparc64\*) lib="lib64";;/x86_64\* | > sparc64\* | ppc64\*) lib="lib64";;/' configure.in > to the spec before all the autoXXX files get regenerated, > and I've verified locally that the generated configure > contains > "x86_64* | sparc64* | ppc64*) lib="lib64";; > > But it still fails to detect postgress see: > http://koji.fedoraproject.org/koji/getfile?taskID=6292&name=build.log host_cpu appears to be powerpc64. Yay for consistency. Bill From rc040203 at freenet.de Fri May 11 16:43:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 May 2007 18:43:46 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1178896088.29429.55.camel@zod.rchland.ibm.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> Message-ID: <1178901826.4735.178.camel@mccallum.corsepiu.local> On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > Josh Boyer wrote: > > > The Fedora wiki pages link to a list of all approved licenses for > > > packages. You could systematically go through and print off each of > > > these. > > But it is more hard for individual user to print, translate and certify. > > I always forget about translating. I blame it on me being a stupid US > born citizen. While we're at it: Does Fedora have a rule on a license language? Or conversely: Which languages does Fedora accept as valid wrt. Licenses? As RH is located in the USA, I'd presume Fedora to be subject to "US courts" in case of "legal matters" and as such I'd presume US laws would prescribe "English" (and may-be Spanish - I don't know)? Background: We have precedences of "Japanese-only licenses" in Fedora packages. Ralf From debarshi.ray at gmail.com Fri May 11 17:50:10 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 11 May 2007 23:20:10 +0530 Subject: Liberation fonts package. Message-ID: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> I just came across the announcement of the Liberation fonts (https://www.redhat.com/promo/fonts/) at the Red Hat summit. Since I did not notice any package for Fedora yet, I just rebuilt the RHEL5 SRPM on Rawhide. Here are the SRPM, RPM, and rpmlint output respectively: http://fedoraproject.org/wiki/DebarshiRay?action=AttachFile&do=get&target=liberation-fonts-0.1-1.fc7.src.rpm http://fedoraproject.org/wiki/DebarshiRay?action=AttachFile&do=get&target=liberation-fonts-0.1-1.fc7.noarch.rpm http://fedoraproject.org/wiki/DebarshiRay?action=AttachFile&do=get&target=liberation-fonts-rpmlint Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ssorce at redhat.com Fri May 11 17:51:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 May 2007 13:51:05 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <46449B03.1070700@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> <46449B03.1070700@odu.neva.ru> Message-ID: <1178905866.12871.13.camel@willson> On Fri, 2007-05-11 at 20:34 +0400, Dmitry Butskoy wrote: > Benjamin Kosnik wrote: > > > > In the meantime, you should try to scan/take photos of these > > certificates, put them up on the web, and send a link to the images to > > this thread. > > Well, > > Some good example: > (ALTLinux is on of the leading local russian distributions): > > in English: > ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt > in Russian: > ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt.ru > A Russian friend invloved with it just told me that ALT Linux is going to address the problem in this thread very soon. Maybe it could make sense coordinating with them and produce something that can be reused by other free software projects ? Simo. From jspaleta at gmail.com Fri May 11 17:51:25 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 May 2007 09:51:25 -0800 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <604aa7910705111051y40d07521qb6dfc987e3f42b39@mail.gmail.com> On 5/8/07, John W. Linville wrote: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. I just got a brandy new thinkpad t60. Using the above kernel, the iwl3945 saw my home network via NetworkManager. Biggest obvious problem is the wireless driver and the suspend functionality do not play well together. At the moment it looks like I can either disable the wireless and have working suspend, or having working wireless and never suspend. I haven't done a crapload of specific testing. If there is something in particular you want me to try to reproduce let me know. -jef"but the thinklight works... which is the most important thing"spaleta From rvinyard at cs.nmsu.edu Fri May 11 17:52:42 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 11 May 2007 11:52:42 -0600 Subject: Legality of Fedora in production environment In-Reply-To: <20070511155636.GA27804@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> Message-ID: <4644AD6A.1010804@cs.nmsu.edu> Alan Cox wrote: > On Fri, May 11, 2007 at 07:42:10PM +0400, Dmitry Butskoy wrote: > >> BTW, one of the precedents is when sysadmin was arrested for absence of >> holographic labels on a computer with Linux. (Next day was released, >> surely). The police was instructed that each server must have holographic... >> > > Some stupidity is only correctable by learning. Even in the UK we've had > minor incidents with well meaning trading standards people trying to seize > "pirate" copies of Linux (because they were on CD-R so clearly pirate). > Nowdays they've learned for the most part 8) > Personally, I think it would be cool if each Fedora release (perhaps even starting with the upcoming F7) had an official set of CD/DVD media cover images (one image per iso). And, not only would it look good, it might help mitigate some of the harassment that some people get with Fedora looking like something "downloaded off the 'net". Even cooler if they use the specific release artwork... especially since the Fedora releases have had some pretty cool stuff. From katzj at redhat.com Fri May 11 17:52:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 11 May 2007 13:52:34 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4644AD6A.1010804@cs.nmsu.edu> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <4644AD6A.1010804@cs.nmsu.edu> Message-ID: <1178905954.11631.17.camel@aglarond.local> On Fri, 2007-05-11 at 11:52 -0600, Rick L Vinyard Jr wrote: > Personally, I think it would be cool if each Fedora release (perhaps > even starting with the upcoming F7) had an official set of CD/DVD media > cover images (one image per iso). And, not only would it look good, it > might help mitigate some of the harassment that some people get with > Fedora looking like something "downloaded off the 'net". > > Even cooler if they use the specific release artwork... especially since > the Fedora releases have had some pretty cool stuff. You mean like you can find at http://fedoraproject.org/wiki/Artwork/CDArt :-) Jeremy From andy at smile.org.ua Fri May 11 18:11:11 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 11 May 2007 21:11:11 +0300 Subject: Legality of Fedora in production environment In-Reply-To: <46449BD5.3090605@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> <46449B03.1070700@odu.neva.ru> <46449BD5.3090605@fedoraproject.org> Message-ID: <20070511181111.GB1097@serv.smile.org.ua> Hi Rahul Sundaram! On Fri, May 11, 2007 at 10:07:41PM +0530, Rahul Sundaram wrote next: > We have something similar at > http://fedoraproject.org/wiki/Legal/Licenses/EULA That's good sample. But if I understood Dmitry correctly the EULA should be 'registered' in the Russian officials. The Russian Linux vendors (such as ALT Linux or ASPLinux) have registered company and the EULA in Russian that can be approved by police. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From jwboyer at jdub.homelinux.org Fri May 11 18:16:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 11 May 2007 13:16:17 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1178901826.4735.178.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> Message-ID: <1178907377.29429.92.camel@zod.rchland.ibm.com> On Fri, 2007-05-11 at 18:43 +0200, Ralf Corsepius wrote: > On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > > Josh Boyer wrote: > > > > The Fedora wiki pages link to a list of all approved licenses for > > > > packages. You could systematically go through and print off each of > > > > these. > > > > But it is more hard for individual user to print, translate and certify. > > > > I always forget about translating. I blame it on me being a stupid US > > born citizen. > While we're at it: Does Fedora have a rule on a license language? Not that I know of. > Or conversely: Which languages does Fedora accept as valid wrt. > Licenses? I actually think this depends on the license itself. E.g. you cannot use a translated copy of the GPL unless it has been certified by the FSF, so by default only the original English version is valid. > As RH is located in the USA, I'd presume Fedora to be subject to "US > courts" in case of "legal matters" and as such I'd presume US laws would > prescribe "English" (and may-be Spanish - I don't know)? English when it comes to "legal matters" in the US. > Background: We have precedences of "Japanese-only licenses" in Fedora > packages. I don't see a problem with those per-se. josh From nicolas.mailhot at laposte.net Fri May 11 18:39:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 11 May 2007 20:39:58 +0200 Subject: Liberation fonts package. In-Reply-To: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> Message-ID: <1178908798.4360.29.camel@rousalka.dyndns.org> I'll just copy some points I've already made on the marketing list where Liberation was announced: > The package needs work first: > - the spec does not follow our current rules (forces a fontconfig dep) > - it lacks any form of fontconfig setup, which is required if you want > the ms core font substitution to actually work > - the license file is not properly encoded and is dumped in the wrong > place > > Also: > - a lot of obvious questions are not answered on the web site or in > the package [1] > - the screen and print priority of the font was never discussed in > Fedora instances, which is not a problem for a minor font but is if > you want it to be one of the primary distro ones [1] > 1. Is this a long-term Red Hat project or will it go stagnant after > initial funding dries out ? (Luxi and Vera-like) > > 2. Does Red Hat intend to morph it in a community project (with the > usual wiki+bugzilla+open SCM infrastructure) or will contributions be > restricted to the contracted foundry (ie will it need a fork like Vera > before joining community space ?) > > 3. what is the reasonning behind the licensing choice? Most recent > FLOSS font projects seem to be gravitation towards OFL, and licensing > differences make cross-pollination difficult > > 4. will unicode coverage ever extend past Latin, Greek and Cyrillic ? > Is Latin, Greek and Cyrillic support limited to most common glyphs or > does it also includes regional variants (welsh, catalan, coptic, etc) > > 5. is it intended to be the new RHEL or Fedora default font set or > just a windows compatibility pack ? > > 6. why did Red Hat choose to launch a new font project instead of > improving one of the existing FLOSS fonts? Was metric compatibility > the main reason? If so is it not dangerous to target the windows > 2000/XP font set when vista just introduced a new default font set ? > 7. who is supposed to field this kind of question? 8. who is supposed to push the package through the Fedora QA process? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From j.w.r.degoede at hhs.nl Fri May 11 19:14:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 May 2007 21:14:58 +0200 Subject: Need help with libgda build failure on ppc64 In-Reply-To: <20070511170832.GG2444@nostromo.devel.redhat.com> References: <464395F5.5070600@hhs.nl> <20070510221351.GA21734@nostromo.devel.redhat.com> <20070510224109.GA22171@nostromo.devel.redhat.com> <20070511170832.GG2444@nostromo.devel.redhat.com> Message-ID: <4644C0B2.306@hhs.nl> Bill Nottingham wrote: > Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >> I'm afraid it isn't that easy, I added this sed command: >> sed -i 's/x86_64\* | sparc64\*) lib="lib64";;/x86_64\* | >> sparc64\* | ppc64\*) lib="lib64";;/' configure.in >> to the spec before all the autoXXX files get regenerated, >> and I've verified locally that the generated configure >> contains >> "x86_64* | sparc64* | ppc64*) lib="lib64";; >> >> But it still fails to detect postgress see: >> http://koji.fedoraproject.org/koji/getfile?taskID=6292&name=build.log > > host_cpu appears to be powerpc64. Yay for consistency. > That _really_ fixed it, thanks! Regards, Hans From ericm24x7 at gmail.com Fri May 11 20:08:07 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Fri, 11 May 2007 16:08:07 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070511155636.GA27804@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> Message-ID: <4644CD27.7000008@gmail.com> Alan Cox wrote: >> I think the text should be "as robast, as possible". Besides the >> "unlimited number of users and systems", it should say that "the >> holographic label is not required", that the label on the case "designed >> for M*crosoft" does not conflict with, etc. >> > > We can sort that out I think > > "The print of this certificate can be compared with the web page at > ...... " > I think you can add the following text to the license document, in order to allow hard copy to be treated as the original: "A copy of this form has the same effect as the original." eric > (and that web page can also have an FAQ for stupid policemen) > > In theory you could store each "license document" owner name you hand out > and invite them to enter it into a web form for verification and have it > report the organisation the license is for etc to make it look good. > > >> BTW, one of the precedents is when sysadmin was arrested for absence of >> holographic labels on a computer with Linux. (Next day was released, >> surely). The police was instructed that each server must have holographic... >> > > Some stupidity is only correctable by learning. Even in the UK we've had > minor incidents with well meaning trading standards people trying to seize > "pirate" copies of Linux (because they were on CD-R so clearly pirate). > Nowdays they've learned for the most part 8) > > Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri May 11 20:09:45 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 11 May 2007 13:09:45 -0700 (PDT) Subject: kernel package In-Reply-To: Dave Jones's message of Friday, 11 May 2007 11:42:27 -0400 <20070511154227.GA8976@redhat.com> Message-ID: <20070511200945.E0B011F8512@magilla.localdomain> Indeed utrace does not have an alpha port, and this is necessary to keep the ptrace interface working. rth did some work on one and maybe he'd like to revive it and have you give it a whirl. Thanks, Roland From mclasen at redhat.com Fri May 11 20:56:51 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 11 May 2007 16:56:51 -0400 Subject: Liberation fonts package. In-Reply-To: <1178908798.4360.29.camel@rousalka.dyndns.org> References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> <1178908798.4360.29.camel@rousalka.dyndns.org> Message-ID: <1178917011.5262.2.camel@localhost.localdomain> On Fri, 2007-05-11 at 20:39 +0200, Nicolas Mailhot wrote: > 8. who is supposed to push the package through the Fedora QA process? I'll file a package review request on Monday, or find somebody else who can do it. From mclasen at redhat.com Fri May 11 21:48:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 11 May 2007 17:48:06 -0400 Subject: Liberation fonts package. In-Reply-To: <1178908798.4360.29.camel@rousalka.dyndns.org> References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> <1178908798.4360.29.camel@rousalka.dyndns.org> Message-ID: <1178920086.5262.4.camel@localhost.localdomain> On Fri, 2007-05-11 at 20:39 +0200, Nicolas Mailhot wrote: > 8. who is supposed to push the package through the Fedora QA process? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239884 From martin.sourada at seznam.cz Fri May 11 22:14:11 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 12 May 2007 00:14:11 +0200 Subject: bcm43xx_mac80211 (was Re: Announcing Fedora 7 Test 4 (6.93)) In-Reply-To: <463F7AAB.6060200@seznam.cz> References: <200704302126.25636.jkeating@redhat.com> <1178053751.28491.24.camel@metroid.rdu.redhat.com> <463F1225.6010502@seznam.cz> <20070507124606.GA4761@redhat.com> <463F21C6.3010608@seznam.cz> <463F4ED4.4080307@seznam.cz> <20070507164913.GB4761@redhat.com> <463F59EF.2000101@seznam.cz> <20070507172205.GC4761@redhat.com> <20070507175719.GA3505@nostromo.devel.redhat.com> <463F6B52.7080709@seznam.cz> <463F705B.7040500@gmail.com> <463F7AAB.6060200@seznam.cz> Message-ID: <4644EAB3.8030808@seznam.cz> Martin Sourada wrote: > Hm... the system-config-network then shows it in the hardware list and > allows me to create a device. If I run ifup wlan0 however, I get this > error: > Error for wireless request "Set Bit Rate" (8B20) : > SET failed on device wlan0 ; Operation not supported. > > And it fails to connect - but that is OK, since I don't have there any > wireless network I have access to... > > Maybe I should try eth1, as kudzu find it as eth1? Or is wireless > supposed to be handled by NetworkManager completely? > > Thanks, > Martin > I am still trying the bcm43xx_mac80211 driver. Using the NetworkManager I cannot connect to the network I have access to, with ifup wlan0 (with the edited modprobe.conf to have alias wlan0 bcm43xx_mac80211 set) same error as in my previous message (quoted above) and no luck with connection (and yes, I set the wlan0 device settings in network manager correctly). Any ideas? Tomorrow I plan to try out the bcm43xx driver to see if thinks go better with it. I'll let you know the result. Well, and one another thing: output of iwconfig: # iwconfig wlan0 Warning: Driver for device wlan0 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken... wlan0 IEEE 802.11g ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Is the warning worth noticing or is it OK? Can it cause some of the problems I have? Thanks, Martin From shiva at sewingwitch.com Fri May 11 23:38:05 2007 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 11 May 2007 16:38:05 -0700 Subject: CD version gone? In-Reply-To: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> Message-ID: On Tuesday, May 01, 2007 7:50 PM +0930 n0dalus wrote: > I noticed there is only a LiveCD and a DVD iso of the test version > available on the mirrors. I need to be able to install Fedora without > a dvd drive and essentially without an internet connection -- the lack > of CD isos is a big problem for me. This is related to volunteer work > I do for a organization out in the country with older computers. One > consequence of this is that I am unable to test F7test4 on some of my > computers (I will try the LiveCD though). Do the computers have USB? If so, you could load a DVD image on an external drive. They're getting pretty cheap now. From mcepl at redhat.com Fri May 11 23:31:24 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 12 May 2007 01:31:24 +0200 Subject: Legality of Fedora in production environment References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46447E68.2030408@odu.neva.ru> Message-ID: On 2007-05-11, 14:32 GMT, Dmitry Butskoy wrote: > In other words, print some couple of documents (license > agreement + GPL, at least) and accompany them by their > notarially certified translation (just for police who do not > know English)... http://fedoraproject.org/wiki/Legal/Licenses/EULA looks pretty good to me. It's even called EULA which should make policemen happy :-). > Ideally, it could be nice to have some "official supplier" for Fedora, > who can send the user some hard copy document in its language... In > other words, to create all needed translations at once, and then send > hard copy (with the individual user's requisites) by request. Perhaps > with a little cost... Hey, you can make even your own business, selling hardcopies of Fedora EULA :-). Matej From mcepl at redhat.com Fri May 11 23:35:17 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 12 May 2007 01:35:17 +0200 Subject: Legality of Fedora in production environment References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> Message-ID: On 2007-05-11, 15:59 GMT, Benjamin Kosnik wrote: > It looks like Alan has the beginnings of something that we can > use for the text. As a former lawyer I can tell you that hacking on legal contracts is highly not recommended activity -- there is a reason why people pay lawyers their fees. There is actually official apparently lawyer-made document available which is even conveniently named EULA http://fedoraproject.org/wiki/Legal/Licenses/EULA Matej From rvinyard at cs.nmsu.edu Sat May 12 00:17:05 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 11 May 2007 18:17:05 -0600 Subject: Legality of Fedora in production environment In-Reply-To: <1178905954.11631.17.camel@aglarond.local> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <4644AD6A.1010804@cs.nmsu.edu> <1178905954.11631.17.camel@aglarond.local> Message-ID: <46450781.2040509@cs.nmsu.edu> Jeremy Katz wrote: > On Fri, 2007-05-11 at 11:52 -0600, Rick L Vinyard Jr wrote: > >> Personally, I think it would be cool if each Fedora release (perhaps >> even starting with the upcoming F7) had an official set of CD/DVD media >> cover images (one image per iso). And, not only would it look good, it >> might help mitigate some of the harassment that some people get with >> Fedora looking like something "downloaded off the 'net". >> >> Even cooler if they use the specific release artwork... especially since >> the Fedora releases have had some pretty cool stuff. >> > > You mean like you can find at > http://fedoraproject.org/wiki/Artwork/CDArt > > :-) > > Jeremy > > Yeah, something just like that. How long before it's available? :) On a more serious note... I think it would get a lot more exposure if they were in the same directories as the isos... or more realistically, in a subdirectory if there were too many language specific versions. From miles.lane at gmail.com Sat May 12 01:13:59 2007 From: miles.lane at gmail.com (Miles Lane) Date: Fri, 11 May 2007 18:13:59 -0700 Subject: Liberation fonts package. In-Reply-To: <1178920086.5262.4.camel@localhost.localdomain> References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> <1178908798.4360.29.camel@rousalka.dyndns.org> <1178920086.5262.4.camel@localhost.localdomain> Message-ID: I must say, while I appreciate the intent, these fonts do not have good render hinting for Windows XP. I will test them on Fedora 7 and Ubuntu 7.04 later. Miles From sundaram at fedoraproject.org Sat May 12 01:24:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 May 2007 06:54:45 +0530 Subject: Liberation fonts package. In-Reply-To: References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> <1178908798.4360.29.camel@rousalka.dyndns.org> <1178920086.5262.4.camel@localhost.localdomain> Message-ID: <4645175D.2060704@fedoraproject.org> Miles Lane wrote: > I must say, while I appreciate the intent, these fonts do not have > good render hinting for Windows XP. I will test them on Fedora 7 and > Ubuntu 7.04 later. It wouldn't have good hinting anywhere. You might want to read the some information http://www.press.redhat.com/2007/05/09/liberation-fonts/ "The first release is a set of fully usable fonts, but they will lack the fully hinting capability (hinting adjusts font pixelization so that the fonts render with high quality at large and small sizes) provided by TrueType/FreeType technology. That release is now ready. The second release will provide full hinting of the fonts, and that release will be available by the end of the calendar year." Rahul From dtimms at iinet.net.au Sat May 12 01:28:53 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 12 May 2007 11:28:53 +1000 Subject: Legality of Fedora in production environment - eula In-Reply-To: <46449BD5.3090605@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> <46449B03.1070700@odu.neva.ru> <46449BD5.3090605@fedoraproject.org> Message-ID: <46451855.5050406@iinet.net.au> Rahul Sundaram wrote: > Dmitry Butskoy wrote: >> Benjamin Kosnik wrote: >>> >>> In the meantime, you should try to scan/take photos of these >>> certificates, put them up on the web, and send a link to the images >>> to this thread. >> >> Well, >> >> Some good example: >> (ALTLinux is on of the leading local russian distributions): >> >> in English: >> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt >> in Russian: >> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.0/Server/license.txt.ru >> > > We have something similar at > http://fedoraproject.org/wiki/Legal/Licenses/EULA Currently it finishes with: Copyright (C) 2003, 2004, 2005 Fedora Project. All rights reserved. ... Does this mean changes made in 2006/7 won't be covered ? Do we need to include any year in which changes/work has been performed {or perhaps a range}. I am not sure whether the copyright notice is intended to protect the EULA, or the fedora distribution itself ;) From: http://www.copyright.gov/circs/circ1.html#noc It suggests only the first year of publishing should be included. But it isn't clear whether FC6 is a different work to FC7, and hence should only show it's year of publishing ? In my mind, FC7 is not a "re-print" of FC6 with some typos fixed - it is more a new work. What would rh legal say about this ? DaveT. From jspaleta at gmail.com Sat May 12 01:49:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 May 2007 17:49:00 -0800 Subject: Legality of Fedora in production environment In-Reply-To: <46450781.2040509@cs.nmsu.edu> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <4644AD6A.1010804@cs.nmsu.edu> <1178905954.11631.17.camel@aglarond.local> <46450781.2040509@cs.nmsu.edu> Message-ID: <604aa7910705111849l51bb43dcme499dd85466998c7@mail.gmail.com> On 5/11/07, Rick L Vinyard Jr wrote: > On a more serious note... I think it would get a lot more exposure if > they were in the same directories as the isos... or more realistically, > in a subdirectory if there were too many language specific versions. Howabout bundled with the torrents? -jef From kevin.kofler at chello.at Sat May 12 02:00:50 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 12 May 2007 02:00:50 +0000 (UTC) Subject: Liberation fonts package. References: <3170f42f0705111050w2e835a16w700f3cba28308358@mail.gmail.com> <1178908798.4360.29.camel@rousalka.dyndns.org> <1178920086.5262.4.camel@localhost.localdomain> <4645175D.2060704@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > > I must say, while I appreciate the intent, these fonts do not have > > good render hinting for Windows XP. I will test them on Fedora 7 and > > Ubuntu 7.04 later. > > It wouldn't have good hinting anywhere. You might want to read the some Fedora's freetype won't use the hinting information anyway for patent reasons. Instead, it uses Freetype's autohinter, which doesn't need any hinting information. Only non-Freetype systems or Freetype systems with the autohinter turned off will render unhinted fonts in a really ugly way. Kevin Kofler From n0dalus+redhat at gmail.com Sat May 12 02:32:05 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 12 May 2007 12:02:05 +0930 Subject: CD version gone? In-Reply-To: References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> Message-ID: <6280325c0705111932l713742e6i4923619b07c1008d@mail.gmail.com> On 5/12/07, Kenneth Porter wrote: > > Do the computers have USB? If so, you could load a DVD image on an external > drive. They're getting pretty cheap now. > I think one might have USB, but the BIOS would be too old to allow booting from it. Was there an official decision by the Fedora steering people to not make a CD version for Prime (and somewhere I could read the rationale for this)? I could probably find ways to work around the problem, but that doesn't stop it from being extremely frustrating to not have a CD version. Please don't let Fedora develop a culture of ignoring users with older computers and older hardware (and no internet). As for using pungi to make a CD set, this is a possibility, but I think most people who need CD versions will not even know about pungi or how to use it. People will probably just end up staying with older versions of Fedora, or changing distro. Pungi may be ok for users who know it exists, have good enough internet connections, and already have an operating system that can run pungi, but don't expect it to be a viable solution for "Fedora users" in general. n0dalus. From rvinyard at cs.nmsu.edu Sat May 12 03:48:40 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 11 May 2007 21:48:40 -0600 Subject: Legality of Fedora in production environment In-Reply-To: <604aa7910705111849l51bb43dcme499dd85466998c7@mail.gmail.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <4644AD6A.1010804@cs.nmsu.edu> <1178905954.11631.17.camel@aglarond.local> <46450781.2040509@cs.nmsu.edu> <604aa7910705111849l51bb43dcme499dd85466998c7@mail.gmail.com> Message-ID: <46453918.8010307@cs.nmsu.edu> Jeff Spaleta wrote: > On 5/11/07, Rick L Vinyard Jr wrote: >> On a more serious note... I think it would get a lot more exposure if >> they were in the same directories as the isos... or more realistically, >> in a subdirectory if there were too many language specific versions. > > > Howabout bundled with the torrents? > > -jef > Why not? Also, I didn't see them in either fedora-logos or redhat-artwork. The work at http://fedoraproject.org/wiki/Artwork/CDArt is pretty sharp... IMHO it deserves wider distribution. From debarshi.ray at gmail.com Sat May 12 04:39:23 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 12 May 2007 10:09:23 +0530 Subject: CD version gone? In-Reply-To: <6280325c0705010345v55e9c6cdk71e097abb1162832@mail.gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <4637153C.8020302@fedoraproject.org> <6280325c0705010345v55e9c6cdk71e097abb1162832@mail.gmail.com> Message-ID: <3170f42f0705112139p1666f2e5gac42af0d9537cf73@mail.gmail.com> > That should be ok. Now all I need is a way to put all the other > packages I need (the ones not on the LiveCD) on a CD, the problem > being that in the past this is usually a trial-and-error process of > finding out that x requires y requires z, downloading them all > separately and putting them on disc (where hypothetically more than > one disc could be required during a single transaction -- does yum > handle this?) etc. I think you can have a look at this: http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay You can find a working version of the code at the above page. I have been writing a howto on using the utility at: http://www.ilug-cal.org/wiki/index.php/RUM Hope you find it useful... Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From zaitcev at redhat.com Sat May 12 05:49:23 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 11 May 2007 22:49:23 -0700 Subject: kernel package In-Reply-To: <1178884157.21820.37.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> Message-ID: <20070511224923.a1c6af2f.zaitcev@redhat.com> On Fri, 11 May 2007 12:49:17 +0100, David Woodhouse wrote: > We don't like ifarches. Why? Mostly because rpmbuild -bp is often useful to run on a different arch. At least this was my reason. They also make the spec crufty if they start to proliferate. -- Pete From dwmw2 at infradead.org Sat May 12 06:16:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 12 May 2007 14:16:37 +0800 Subject: kernel package In-Reply-To: <20070511224923.a1c6af2f.zaitcev@redhat.com> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> <20070511224923.a1c6af2f.zaitcev@redhat.com> Message-ID: <1178950598.7671.7.camel@shinybook.infradead.org> On Fri, 2007-05-11 at 22:49 -0700, Pete Zaitcev wrote: > On Fri, 11 May 2007 12:49:17 +0100, David Woodhouse wrote: > > > We don't like ifarches. Why? > > Mostly because rpmbuild -bp is often useful to run on a different arch. > At least this was my reason. They also make the spec crufty if they > start to proliferate. Sorry. I was asking why he wanted them -- not why we don't like them. -- dwmw2 From debarshi.ray at gmail.com Sat May 12 08:48:05 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 12 May 2007 14:18:05 +0530 Subject: Firefox not using ~/Download Message-ID: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> It seems that Firefox is not using the ~/Download directory for storing its downloads. The default location is still ~/Desktop. Although one can easily change the settings in Firefox, isn't it more reasonable if all applications made use of the ~/Download directory by default when one is available? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From snecklifter at gmail.com Sat May 12 10:08:35 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sat, 12 May 2007 11:08:35 +0100 Subject: Firefox not using ~/Download In-Reply-To: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> References: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> Message-ID: <364d303b0705120308k3c27f66dl96f438ed09e1406b@mail.gmail.com> Hello Rishi, On 12/05/07, Debarshi 'Rishi' Ray wrote: > > It seems that Firefox is not using the ~/Download directory for > storing its downloads. The default location is still ~/Desktop. > Although one can easily change the settings in Firefox, isn't it more > reasonable if all applications made use of the ~/Download directory by > default when one is available? > > Regards, > Debarshi > I'm not really convinced of the value of adding those folders by default. My first instinct is to drag and drop to trash. However I do think that having certain apps use them by default - e.g. grip ripping to music, gimp saving to pictures and yes, firefox saving to downloads would be a good start. I imagine this is probably the intention anyway. However I'm not sure said apps wouldn't spit the dummy if those folders didn't exist. Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Sat May 12 10:14:20 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sat, 12 May 2007 11:14:20 +0100 Subject: Legality of Fedora in production environment In-Reply-To: <604aa7910705111849l51bb43dcme499dd85466998c7@mail.gmail.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <4644AD6A.1010804@cs.nmsu.edu> <1178905954.11631.17.camel@aglarond.local> <46450781.2040509@cs.nmsu.edu> <604aa7910705111849l51bb43dcme499dd85466998c7@mail.gmail.com> Message-ID: <364d303b0705120314k70bf6cf9q3bd18f3e2f6aae68@mail.gmail.com> On 12/05/07, Jeff Spaleta wrote: > > On 5/11/07, Rick L Vinyard Jr wrote: > > On a more serious note... I think it would get a lot more exposure if > > they were in the same directories as the isos... or more realistically, > > in a subdirectory if there were too many language specific versions. > > > Howabout bundled with the torrents? > +1 Cheers, Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsof at nodata.co.uk Sat May 12 10:23:12 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 12 May 2007 12:23:12 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1178901036.1172.7.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <1178901036.1172.7.camel@rousalka.dyndns.org> Message-ID: <1178965392.3836.1.camel@sb-home> Am Freitag, den 11.05.2007, 18:30 +0200 schrieb Nicolas Mailhot: > Le vendredi 11 mai 2007 ? 08:57 -0700, alan a ?crit : > > > Scribus and a color printer? With the proper tools you can make something > > that looks "official". > > They are probably trained to recognize inkjet prints, as making > something that looks "official" also occurred to real thieves. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Probably probably probably. I think the top poster needs to contact FSF Russia, or at least FSF and ask them. From notting at redhat.com Sat May 12 13:43:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 12 May 2007 09:43:33 -0400 Subject: rawhide merge status Message-ID: <20070512134333.GB16522@nostromo.devel.redhat.com> A rawhide tree has been pushed to the mirror master, and should show up publically in the near future. Note that it is a very large change from the last published rawhide, and therefore may take some time to land on your local mirror. We hope to get more automated rawhide pushes going soon. Bill From rjones at redhat.com Sat May 12 13:51:09 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 12 May 2007 14:51:09 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <1178208140.5401.3.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> Message-ID: <4645C64D.3090405@redhat.com> Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sat May 12 13:53:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 May 2007 19:23:49 +0530 Subject: Proposal ocaml guidelines In-Reply-To: <4645C64D.3090405@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <4645C64D.3090405@redhat.com> Message-ID: <4645C6ED.3060505@fedoraproject.org> Richard W.M. Jones wrote: > Probably missing something here, but I'm reading > http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to > have a go creating RPMs for some OCaml packages. However where do I > post the spec files for discussion/inclusion? > > Rich. > See http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 Rahul From j.w.r.degoede at hhs.nl Sat May 12 14:08:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 12 May 2007 16:08:58 +0200 Subject: Proposal ocaml guidelines In-Reply-To: <4645C64D.3090405@redhat.com> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <4645C64D.3090405@redhat.com> Message-ID: <4645CA7A.50309@hhs.nl> Richard W.M. Jones wrote: > Probably missing something here, but I'm reading > http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to > have a go creating RPMs for some OCaml packages. However where do I > post the spec files for discussion/inclusion? > > Rich. > See: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess And more specificly fill in this form / bugzilla template: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review Regards, Hans From rjones at redhat.com Sat May 12 13:56:10 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 12 May 2007 14:56:10 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <4645CA7A.50309@hhs.nl> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <4645C64D.3090405@redhat.com> <4645CA7A.50309@hhs.nl> Message-ID: <4645C77A.4070409@redhat.com> Hans de Goede wrote: > Richard W.M. Jones wrote: >> Probably missing something here, but I'm reading >> http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to >> have a go creating RPMs for some OCaml packages. However where do I >> post the spec files for discussion/inclusion? >> >> Rich. >> > > See: > http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess > > And more specificly fill in this form / bugzilla template: > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review Very fast and encouraging responses. Thank you both. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sat May 12 13:56:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 May 2007 19:26:08 +0530 Subject: Proposal ocaml guidelines In-Reply-To: <4645C6ED.3060505@fedoraproject.org> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> <4645C64D.3090405@redhat.com> <4645C6ED.3060505@fedoraproject.org> Message-ID: <4645C778.4040003@fedoraproject.org> Rahul Sundaram wrote: > Richard W.M. Jones wrote: >> Probably missing something here, but I'm reading >> http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to >> have a go creating RPMs for some OCaml packages. However where do I >> post the spec files for discussion/inclusion? >> >> Rich. >> > > See > http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 Oops. never mind. Read that wrong. Rahul From david at lovesunix.net Sat May 12 14:21:01 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 12 May 2007 16:21:01 +0200 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1178979661.3201.9.camel@dawkins> l?r, 12 05 2007 kl. 09:43 -0400, skrev Bill Nottingham: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. > > We hope to get more automated rawhide pushes going soon. This calls for drinking... - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From rvinyard at cs.nmsu.edu Sat May 12 14:42:29 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sat, 12 May 2007 08:42:29 -0600 Subject: Nautilus, MIME and .desktop files Message-ID: <4645D255.5010107@cs.nmsu.edu> I'm having a problem getting nautilus to recognize a xournal PDF annotation file. I have the MIME type specified in the .desktop file and thought I had all the entries in the spec to install the desktop file and update the MIME database. However, nautilus still recognizes .xoj files (the PDF annotation file that Xournal stores PDF highlighting and markups in) as an archive... needing to be opened with "Archive Manager". Any ideas how to fix the problem? Also, what would be necessary to get nautilus to use a specific file-type icon for xournal files? Here's the desktop file: [Desktop Entry] Encoding=UTF-8 Name=Xournal GenericName=Xournal Notetaking Comment=Take notes, sketch and annotate PDFs Exec=xournal %f Icon=xournal.png Terminal=false Type=Application StartupNotify=true MimeType=application/x-xoj Categories=GNOME;GTK;Application;Office;Graphics;Utility; In the spec (install section), I have: %{__install} -D pixmaps/xournal.png %{buildroot}%{_datadir}/pixmaps/xournal.png desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ --add-category X-Fedora \ %{SOURCE1} and also in the spec: %post update-desktop-database %{_datadir}/applications %postun update-desktop-database %{_datadir}/applications From buildsys at fedoraproject.org Sat May 12 17:02:54 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 12 May 2007 13:02:54 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-12 Message-ID: <20070512170254.A982B152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 29 NEW clutter-gtk-0.1.0-3.fc6 : A basic GTK clutter widget crack-5.0a-5.fc6 NEW DMitry-1.3a-2.fc6 : Deepmagic Information Gathering Tool fuse-2.6.5-1.fc6 (!) gdal-1.4.1-1.fc6 : INVALID rebuild, not published! ghc-6.6.1-2.fc6 giggle-0.3-1.fc6 gmediaserver-0.12.0-9.fc6 gtk2hs-0.9.11-3.fc6 hdf-4.2r1-13.fc6 librfid-0.1.0-3.1996svn.fc6 NEW machineball-1.0-2.fc6 : A futuristic ball game with simple rules NEW nbtscan-1.5.1-1.fc6 : Tool to gather NetBIOS info from Windows networks NEW penguin-command-1.6.11-2.fc6 : Open source arcade game NEW perl-libwhisker2-2.4-2.fc6 : Perl module geared specificly for HTTP testing NEW perl-mecab-0.95-5.fc6 : Perl binding for MeCab NEW perl-Sys-Syscall-0.22-2.fc6 : Access system calls that Perl doesn't normally provide access to NEW php-magpierss-0.72-3.fc6 : MagpieRSS is an RSS parser written in PHP NEW python-Coherence-0.2.1-3.fc6 : Python framework to participate in digital living networks quodlibet-1.0-1.fc6 NEW ruby-gettext-package-1.9.0-2.fc6 : Localization Library and Tools for Ruby shorewall-3.4.3-1.fc6 sonata-1.1-1.fc6 NEW taxipilot-0.9.1-2.fc6 : Game where you pilot a taxi in space NEW tiquit-2.4-4.fc6 : A PHP5-compatible help desk incident tracking/knowledgebase system NEW vegastrike-0.4.3-3.fc6 : 3D OpenGL spaceflight simulator wavpack-4.41-1.fc6 NEW xu4-1.1-0.1.20070510.fc6 : Ultima IV recreated yap-5.1.1-3.fc6 Packages built and released for Fedora Extras 5: 13 crack-5.0a-4.fc5 fuse-2.6.5-1.fc5 NEW nbtscan-1.5.1-1.fc5 : Tool to gather NetBIOS info from Windows networks NEW perl-libwhisker2-2.4-2.fc5 : Perl module geared specificly for HTTP testing NEW perl-mecab-0.95-5.fc5 : Perl binding for MeCab NEW perl-Sys-Syscall-0.22-2.fc5 : Access system calls that Perl doesn't normally provide access to NEW python-Coherence-0.2.1-3.fc5 : Python framework to participate in digital living networks quodlibet-1.0-1.fc5 rosegarden4-1.5.1-1.fc5 NEW ruby-gettext-package-1.9.0-2.fc5 : Localization Library and Tools for Ruby shorewall-3.4.3-1.fc5 NEW tiquit-2.4-4.fc5 : A PHP5-compatible help desk incident tracking/knowledgebase system wavpack-4.41-1.fc5 Changes in Fedora Extras development: Changes in Fedora Extras 6: clutter-gtk-0.1.0-3.fc6 ----------------------- * Thu May 10 2007 Allisson Azevedo 0.1.0-3 - fix devel files section * Thu May 10 2007 Allisson Azevedo 0.1.0-2 - INSTALL removed from docs - fix make install for keeping timestamps - fix devel files section - changed license for LGPL * Fri Apr 13 2007 Allisson Azevedo 0.1.0-1 - Initial RPM release crack-5.0a-5.fc6 ---------------- * Thu May 10 2007 Christian Iseli 5.0a-5 - Fix #239575: crack uses obsolete sort option syntax DMitry-1.3a-2.fc6 ----------------- * Sat May 12 2007 Sindre Pedersen Bj?rdal - 1.3a-2 - Bump release for rebuild * Thu May 03 2007 Sindre Pedersen Bj?rdal - 1.3a-1 - Initial build fuse-2.6.5-1.fc6 ---------------- * Sat May 12 2007 Peter Lemenkov 2.6.5-1 - Version 2.6.5 gdal-1.4.1-1.fc6 ---------------- * Wed May 09 2007 Balint Cristian 1.4.1-1 - new upstream release. - disable temporary grass-devel requirement untill find a resonable solution for gdal-grass egg-chicken dep problem. ghc-6.6.1-2.fc6 --------------- * Thu May 10 2007 Bryan O'Sullivan - 6.6.1-2 - exclude ppc64 for now, due to lack of time to bootstrap - install man page for ghc * Wed May 09 2007 Bryan O'Sullivan - 6.6.1-1 - update to 6.6.1 release * Mon Jan 22 2007 Jens Petersen - 6.6-2 - remove truncated duplicate Typeable.h header in network package (Bryan O'Sullivan, #222865) giggle-0.3-1.fc6 ---------------- * Wed May 09 2007 James Bowes - 0.3-1 - Update to 0.3 * Thu Mar 29 2007 James Bowes - 0.2-2 - Add buildrequires for git-core * Thu Mar 29 2007 James Bowes - 0.2-1 - Update to 0.2 gmediaserver-0.12.0-9.fc6 ------------------------- * Mon May 07 2007 Karol Trzcionka - 0.12.0-9 - Rebuild with new libupnp version gtk2hs-0.9.11-3.fc6 ------------------- * Thu May 10 2007 Bryan O'Sullivan - 0.9.11-3 - rebuild against ghc 6.6.1 - disable ppc64 build (#239752) hdf-4.2r1-13.fc6 ---------------- * Thu May 10 2007 Orion Poplawski 4.2r1-13 - Remove netcdf-devel requires. (bug #239631) librfid-0.1.0-3.1996svn.fc6 --------------------------- * Fri May 11 2007 Kushal Das 0.1.0.3.1996svn - bumping the release * Fri May 11 2007 Kushal Das 0.1.0.2.1996svn - trying to fix buildrequires * Fri May 11 2007 Kushal Das 0.1.0.1.1996svn - updating to svn machineball-1.0-2.fc6 --------------------- * Thu May 10 2007 Hans de Goede 1.0-2 - Add missing BuildRequires - Fix Source0 url, and fix version to match nbtscan-1.5.1-1.fc6 ------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 1.5.1-1 - Initial build penguin-command-1.6.11-2.fc6 ---------------------------- * Wed May 09 2007 Rafa? Psota - 1.6.11-2 - add -p flag to install * Mon May 07 2007 Rafa? Psota - 1.6.11-1 - Initial Fedora package perl-libwhisker2-2.4-2.fc6 -------------------------- * Tue May 08 2007 Sindre Pedersen Bj?rdal - 2.4-2 - Fix typo in Source0 url - Update lw1bridge patch to not include License info - Add explicit version to Provides and Obsoletes - Added tests, commented out - Cleaned up BuildRequires and Requires * Fri May 04 2007 Sindre Pedersen Bj?rdal - 2.4-1 - Initial build perl-mecab-0.95-5.fc6 --------------------- * Fri May 11 2007 Mamoru Tasaka - 0.95-5 - Add license notification text for now. * Wed May 09 2007 Mamoru Tasaka - 0.95-4 - Correctly require version specified BuildRequires - Rewrite accroding to perl template perl-Sys-Syscall-0.22-2.fc6 --------------------------- * Tue May 08 2007 Ruben Kerkhof 0.22-2 - Test::More added to BR (#239369) * Mon May 07 2007 Ruben Kerkhof 0.22-1 - Specfile autogenerated by cpanspec 1.69.1. php-magpierss-0.72-3.fc6 ------------------------ * Thu May 10 2007 Michael Stahnke - 0.72-3 - Fixed minor issues in review bug [bug #225434] python-Coherence-0.2.1-3.fc6 ---------------------------- * Tue May 08 2007 Matthias Saou 0.2.1-3 - Rename Coherence -> python-Coherence to match our python naming guidelines. * Mon May 07 2007 Matthias Saou 0.2.1-2 - Rename coherence -> Coherence to match upstream and our naming guidelines. - Obsolete coherence < 0.2.1-2 but don't provide it since elisa's requirement has been updated to match the name change and nothing else requires it. * Fri Apr 20 2007 Matthias Saou 0.2.1-1 - Update to 0.2.1. quodlibet-1.0-1.fc6 ------------------- * Thu May 10 2007 Jeffrey C. Ollie - 1.0-1 - Update to 1.0 * Sat Apr 14 2007 Jeffrey C. Ollie - 0.24-7 - Add requires on gnome-python2-canvas, fixes #236468 ruby-gettext-package-1.9.0-2.fc6 -------------------------------- * Mon May 07 2007 Mamoru Tasaka - 1.9.0-2 - Create -doc subpackage * Sat Apr 21 2007 Mamoru Tasaka - 1.9.0-1 - Initial packaging shorewall-3.4.3-1.fc6 --------------------- * Fri May 11 2007 Robert Marcano - 3.4.2-1 - Update to upstream 3.4.3 sonata-1.1-1.fc6 ---------------- * Wed May 09 2007 Micha? Bentkowski - 1.1-1 - Update to 1.1 taxipilot-0.9.1-2.fc6 --------------------- * Thu Apr 26 2007 Hans de Goede 0.9.1-2 - Ship all relevant docs including COPYING - Link libEXT_wavpo.so with additional libs to fix unresolved non weak syms * Tue Apr 24 2007 Hans de Goede 0.9.1-1 - Initial Fedora Extras package tiquit-2.4-4.fc6 ---------------- * Mon May 07 2007 Jon Ciesla - 2.4-4 - Removed duplicate slash in symlink creation. * Mon May 07 2007 Jon Ciesla - 2.4-3 - Fixed README.fedora handling. * Mon May 07 2007 Jon Ciesla - 2.4-2 - Fixed Source0, PHP Requires. - Added tiquit-README.fedora vegastrike-0.4.3-3.fc6 ---------------------- * Wed May 09 2007 Hans de Goede 0.4.3-3 - Add some missing files including COPYING to %doc - Fix PPC compilation * Mon Apr 23 2007 Hans de Goede 0.4.3-2 - Add some missing BuildRequires - Keep system python paths in python path wavpack-4.41-1.fc6 ------------------ * Sat May 12 2007 Peter Lemenkov 4.41-1 - Version 4.41 - Removed unnecessary --with-pic xu4-1.1-0.1.20070510.fc6 ------------------------ * Fri May 11 2007 Hans de Goede 1.1-0.1.20070510 - Update to latest CVS, as this actually makes the game finishable - Add missing BuildRequires: desktop-file-utils - Add u4download.txt to the docs yap-5.1.1-3.fc6 --------------- * Fri May 11 2007 Gerard Milmeister - 5.1.1-3 - remove -fstack-protector from optflags in order to enable loading of .so modules Changes in Fedora Extras 5: crack-5.0a-4.fc5 ---------------- * Thu May 10 2007 Christian Iseli 5.0a-4 - Fix #239575: crack uses obsolete sort option syntax fuse-2.6.5-1.fc5 ---------------- * Sat May 12 2007 Peter Lemenkov 2.6.5-1 - Version 2.6.5 nbtscan-1.5.1-1.fc5 ------------------- * Sat May 05 2007 Sindre Pedersen Bj?rdal - 1.5.1-1 - Initial build perl-libwhisker2-2.4-2.fc5 -------------------------- * Tue May 08 2007 Sindre Pedersen Bj?rdal - 2.4-2 - Fix typo in Source0 url - Update lw1bridge patch to not include License info - Add explicit version to Provides and Obsoletes - Added tests, commented out - Cleaned up BuildRequires and Requires * Fri May 04 2007 Sindre Pedersen Bj?rdal - 2.4-1 - Initial build perl-mecab-0.95-5.fc5 --------------------- * Fri May 11 2007 Mamoru Tasaka - 0.95-5 - Add license notification text for now. * Wed May 09 2007 Mamoru Tasaka - 0.95-4 - Correctly require version specified BuildRequires - Rewrite accroding to perl template perl-Sys-Syscall-0.22-2.fc5 --------------------------- * Tue May 08 2007 Ruben Kerkhof 0.22-2 - Test::More added to BR (#239369) * Mon May 07 2007 Ruben Kerkhof 0.22-1 - Specfile autogenerated by cpanspec 1.69.1. python-Coherence-0.2.1-3.fc5 ---------------------------- * Tue May 08 2007 Matthias Saou 0.2.1-3 - Rename Coherence -> python-Coherence to match our python naming guidelines. * Mon May 07 2007 Matthias Saou 0.2.1-2 - Rename coherence -> Coherence to match upstream and our naming guidelines. - Obsolete coherence < 0.2.1-2 but don't provide it since elisa's requirement has been updated to match the name change and nothing else requires it. * Fri Apr 20 2007 Matthias Saou 0.2.1-1 - Update to 0.2.1. quodlibet-1.0-1.fc5 ------------------- * Thu May 10 2007 Jeffrey C. Ollie - 1.0-1 - Update to 1.0 * Sat Apr 14 2007 Jeffrey C. Ollie - 0.24-7 - Add requires on gnome-python2-canvas, fixes #236468 rosegarden4-1.5.1-1.fc5 ----------------------- * Wed May 02 2007 Callum Lerwick - 1.5.1-1 - New upstream version. * Tue Feb 13 2007 Callum Lerwick - 1.5.0-1 - New upstream version. ruby-gettext-package-1.9.0-2.fc5 -------------------------------- * Mon May 07 2007 Mamoru Tasaka - 1.9.0-2 - Create -doc subpackage * Sat Apr 21 2007 Mamoru Tasaka - 1.9.0-1 - Initial packaging shorewall-3.4.3-1.fc5 --------------------- * Fri May 11 2007 Robert Marcano - 3.4.2-1 - Update to upstream 3.4.3 tiquit-2.4-4.fc5 ---------------- * Mon May 07 2007 Jon Ciesla - 2.4-4 - Removed duplicate slash in symlink creation. * Mon May 07 2007 Jon Ciesla - 2.4-3 - Fixed README.fedora handling. * Mon May 07 2007 Jon Ciesla - 2.4-2 - Fixed Source0, PHP Requires. - Added tiquit-README.fedora wavpack-4.41-1.fc5 ------------------ * Sat May 12 2007 Peter Lemenkov 4.41-1 - Version 4.41 - Removed unnecessary --with-pic For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lsof at nodata.co.uk Sat May 12 17:21:11 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 12 May 2007 19:21:11 +0200 Subject: /etc/pki In-Reply-To: <1178732049.2824.207.camel@pmac.infradead.org> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> Message-ID: <1178990471.3562.1.camel@sb-home> Am Mittwoch, den 09.05.2007, 18:34 +0100 schrieb David Woodhouse: > On Wed, 2007-05-09 at 17:27 +0100, Richard W.M. Jones wrote: > > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. > > Registered in England and Wales under Company Registration No. 3798903 > > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David > > Owens (Ireland) > > Please don't pollute public mailing lists with this nonsense -- keep > your .sig to 4 lines at a maximum. It's the law. The directors line is unneeded though. "Every company needs to list its company registration number, place of registration and registered office address on its website and in emails." From mschwendt.tmp0701.nospam at arcor.de Sat May 12 18:23:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 12 May 2007 20:23:10 +0200 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <20070512202310.268c23fe.mschwendt.tmp0701.nospam@arcor.de> On Sat, 12 May 2007 09:43:33 -0400, Bill Nottingham wrote: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. > > We hope to get more automated rawhide pushes going soon. > > Bill Is the Wiki page everything that is documented about the merged repo and the work that is going on? Is the rawhide compose tool available in a public place? Is the old rawhide report based on a treediff that can be reused (or will it need something different like how it's done for Extras)? From dennis at ausil.us Sat May 12 18:42:38 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 12 May 2007 13:42:38 -0500 Subject: rawhide merge status In-Reply-To: <20070512202310.268c23fe.mschwendt.tmp0701.nospam@arcor.de> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070512202310.268c23fe.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200705121342.39300.dennis@ausil.us> Once upon a time Saturday 12 May 2007, Michael Schwendt wrote: > On Sat, 12 May 2007 09:43:33 -0400, Bill Nottingham wrote: > > A rawhide tree has been pushed to the mirror master, and should show up > > publically in the near future. Note that it is a very large change from > > the last published rawhide, and therefore may take some time to land on > > your local mirror. > > > > We hope to get more automated rawhide pushes going soon. > > > > Bill > > Is the Wiki page everything that is documented about the merged repo > and the work that is going on? > Is the rawhide compose tool available in a public place? rawhide is being composed by pungi and mash https://hosted.fedoraproject.org/projects/pungi http://people.redhat.com/notting/mash/ > Is the old rawhide report based on a treediff that can be reused > (or will it need something different like how it's done for Extras)? /me does not know that Dennis From alan at redhat.com Sat May 12 20:22:22 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 12 May 2007 16:22:22 -0400 Subject: /etc/pki In-Reply-To: <1178990471.3562.1.camel@sb-home> References: <4641F669.4040206@redhat.com> <1178732049.2824.207.camel@pmac.infradead.org> <1178990471.3562.1.camel@sb-home> Message-ID: <20070512202222.GB32180@devserv.devel.redhat.com> On Sat, May 12, 2007 at 07:21:11PM +0200, nodata wrote: > It's the law. Actually the law doesn't say "stick crap in the wrong place" > "Every company needs to list its company registration number, place of registration and registered office address on its website and in emails." And the RFC documents state the correct place for this is in the email header "Organization:" This isn't the posters fault however, the legal situation is unclear because nobody actually *thought* about the law [as is normal these days] and its application or produced useful guidelines [as companies house should have done] The Red Hat company policy is getting sorted but for the moment please don't shoot the victims. IBM had the same problem and they got it sorted so I know we can ;) Alan From jdieter at gmail.com Sat May 12 20:30:21 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 12 May 2007 23:30:21 +0300 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1179001821.4825.2.camel@jndwidescreen.lesbg.loc> On Sat, 2007-05-12 at 09:43 -0400, Bill Nottingham wrote: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. > > We hope to get more automated rawhide pushes going soon. > > Bill > And deltarpm updates are available for i386 using yum-presto. Note that there won't be deltarpms yet for any packages that were in Extras (as this is the first time I've mirrored them). Jonathan -------------- 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 Sat May 12 20:38:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 May 2007 22:38:26 +0200 Subject: somebody willing to review cernlib-g77? Message-ID: <20070512203826.GC2852@free.fr> Hello, I have submitted https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237579 the cernlib compiled with g77, now that the main package is compiled with gfortran. It would allow packages linked against the previous cernlib packages to work, since gfortran is binary incompatible with g77. I also think it is important to have a possibility to build programs with g77. And I think it would be nice to have it in F7. Any taker? -- Pat From rms at 1407.org Sat May 12 21:00:33 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sat, 12 May 2007 22:00:33 +0100 Subject: Legality of Fedora in production environment In-Reply-To: <46446924.1080209@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> Message-ID: <1179003633.5379.35.camel@roque> Sex, 2007-05-11 ?s 17:01 +0400, Dmitry Butskoy escreveu: > Recently the appropriate laws in my country (Russia) have been > significantly toughened. Now the police can check for illegal software > usage by their own initiative (without request from the owner). The tax > inspection demands that software should be registered at accounts > departments. > > During such a checking, the user is obliged now to show all hardcopy > license documents (with original signatures and stamps). But there are > no any such things for distros like Fedora, which have been just > downloaded from Internet, hence the user shows nothing. In this > situation the police *must* temporarily confiscate system blocks (up to > 2 weeks) for further checking... > Certainly, after the checking period all hardware comes back, but such > troubles are not allowed for normal business. Safest bet: print Fedora's "EULA", print the GNU GPL, GNU Lesser GPL, MIT, BSD (revised or not) etc... of the software you use. Collect them in one document and sign: I Agree, Dmitry Butskoy. Be very careful of racketeers, here in Portugal, ANSOL has incentivated people to use only Free Software on their computers, and send back the "software usage registry form" from the "local" BSA filled with a single comment: We use Free Software, we don't need to worry about this Usamos Software Livre, n?o temos de nos preocupar com isto. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From louisg00 at bellsouth.net Sat May 12 21:53:27 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sat, 12 May 2007 17:53:27 -0400 Subject: rawhide merge status Message-ID: <1179006807.5746.8.camel@sonlaptop> I still see the old layout '/pub/fedora/linux/core/development/' but with the merged tree. Will the new layout '/pub/fedora/linux/development/' come later? As described in: http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge -Louis From jwboyer at jdub.homelinux.org Sat May 12 23:01:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 18:01:08 -0500 Subject: rawhide merge status In-Reply-To: <200705121342.39300.dennis@ausil.us> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070512202310.268c23fe.mschwendt.tmp0701.nospam@arcor.de> <200705121342.39300.dennis@ausil.us> Message-ID: <1179010869.17555.21.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 13:42 -0500, Dennis Gilmore wrote: > Once upon a time Saturday 12 May 2007, Michael Schwendt wrote: > > On Sat, 12 May 2007 09:43:33 -0400, Bill Nottingham wrote: > > > A rawhide tree has been pushed to the mirror master, and should show up > > > publically in the near future. Note that it is a very large change from > > > the last published rawhide, and therefore may take some time to land on > > > your local mirror. > > > > > > We hope to get more automated rawhide pushes going soon. > > > > > > Bill > > > > Is the Wiki page everything that is documented about the merged repo > > and the work that is going on? > > > Is the rawhide compose tool available in a public place? > rawhide is being composed by pungi and mash > https://hosted.fedoraproject.org/projects/pungi > http://people.redhat.com/notting/mash/ > > > Is the old rawhide report based on a treediff that can be reused > > (or will it need something different like how it's done for Extras)? > /me does not know that I believe treediff will be used. josh From jwboyer at jdub.homelinux.org Sat May 12 23:03:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 18:03:28 -0500 Subject: rawhide merge status In-Reply-To: <1179006807.5746.8.camel@sonlaptop> References: <1179006807.5746.8.camel@sonlaptop> Message-ID: <1179011008.17555.23.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 17:53 -0400, Louis E Garcia II wrote: > I still see the old layout '/pub/fedora/linux/core/development/' but > with the merged tree. Will the new layout > '/pub/fedora/linux/development/' come later? Yes, it will come later. This was just to get the initial merged rawhide out the door. josh From kevin.kofler at chello.at Sat May 12 23:05:28 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 12 May 2007 23:05:28 +0000 (UTC) Subject: Nautilus, MIME and .desktop files References: <4645D255.5010107@cs.nmsu.edu> Message-ID: Rick L Vinyard Jr cs.nmsu.edu> writes: > I'm having a problem getting nautilus to recognize a xournal PDF > annotation file. I have the MIME type specified in the .desktop file and > thought I had all the entries in the spec to install the desktop file > and update the MIME database. You need a shared-mime-info entry for the MIME type. You also need a .desktop file for the MIME type for KDE 3 (KDE 4 (>=3.90.1) uses shared-mime-info, but KDE 3 used its own older MIME type system). You also need icons with the correct names (gnome-mime-application-x-xoj for GNOME, application-x-xoj for KDE 4, and any name specified in the MIME type .desktop file (I recommend just using application-x-xoj there to avoid yet another symlink) for KDE 3), which should be installed according to the icon theme spec. For an example, see: http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/ktigcc/fedora/ktigcc.spec?revision=1.23.2.1&view=markup Kevin Kofler From arjan at fenrus.demon.nl Sat May 12 22:12:19 2007 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 12 May 2007 15:12:19 -0700 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? Message-ID: <1179007939.7061.6.camel@laptopd505.fenrus.org> Hi, some of you already know that I've been working on getting Linux (and Fedora) to be a lot better about power usage on laptops by avoiding spurious wakeups and context switches and such (look at the "wakeup" bug in fedora bugzilla ;). As part of my job at Intel I've now released a user friendly tool that allows everyone that uses it to see what the biggest problems on their own laptop are... The results internally to Intel have been really good; several people gained an hour of battery just by using the tool and getting rid of (or fixing) 'broken' applications. PowerTOP can be downloaded from http://www.linuxpowertop.org for completeness I've attached the full announcement text I used in other places below. I hope that enough people will use it and report / fix issues in software so that the whole Linux experience on laptops will be a lot better in a few months.. ---------------------- What's eating the battery life of my laptop? Why isn't it many more hours? Which software component causes the most power to be burned? These are important questions without a good answer... until now. The Linux 2.6.21 kernel introduces the so called tickless-idle feature. This feature allows the processor to be really idle for long periods of time, rather than having to wake up every millisecond for the timer tick. Current processors save a lot of power if they are idle for long periods, which translates into a longer battery life for your laptop, or a lower energy bill for your datacenter. However, a Linux system consists of more software than just the kernel, and there are many tunables involved. It's not easy to see what is going on, and as a result the behavior is sometimes far from optimal, and a lot of power is wasted. Intel is proud to announce the PowerTOP tool (http://www.linuxpowertop.org), a program that collects the various pieces of information from your system and presents an overview of how well your laptop is doing in terms of power savings. In addition, PowerTOP will provide an indication of which tunables and software components are the biggest offenders in slurping up your battery time. PowerTOP will update it's display frequently so that you can directly see the impact of any changes you are making. A typical Linux distribution has many components that wake the processor up frequently for no good reason. In our testing with PowerTOP, we have seen many cases where with some simple fixes, the battery life of typical laptops was increased by one hour or more! We are providing fixes for several of the issues we identified, and we encourage the Linux community to help us in this quest to get the maximum battery life out of your (hopefully Intel based) laptops. Try the PowerTOP tool, join the mailing list or the IRC channel and provide feedback, problem reports or fixes! Website: http://www.linuxpowertop.org IRC: irc.oftc.net #powertop channel Mailing list: http://www.bughost.org/mailman/listinfo/power -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org From snecklifter at gmail.com Sat May 12 23:46:41 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sun, 13 May 2007 00:46:41 +0100 Subject: Ext4 for F7 Message-ID: <364d303b0705121646x4026b985ie3928c648f5092b1@mail.gmail.com> Ext4 appears to be enabled in the latest kernels - will anaconda support it in the same way as it unofficially supports jfs? As in users need to type 'linux ext4' at the prompt to enable to option during install. Or are we looking at F8? Sorry if this has been asked already but if the above is not the case I'd be interested to know why. Reports are that it is now quite stable... :) Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Sun May 13 00:41:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 19:41:19 -0500 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <1179016879.17555.33.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 15:12 -0700, Arjan van de Ven wrote: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). > > As part of my job at Intel I've now released a user friendly tool that > allows everyone that uses it to see what the biggest problems on their > own laptop are... The results internally to Intel have been really good; > several people gained an hour of battery just by using the tool and > getting rid of (or fixing) 'broken' applications. > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > for completeness I've attached the full announcement text I used in > other places below. I hope that enough people will use it and report / > fix issues in software so that the whole Linux experience on laptops > will be a lot better in a few months.. Awesome. Were you planning on packaging this tool for Fedora, or should I whip something together? /me goes off to figure out why liferea causes 50.2% of the wakeups on his machine. josh From halfline at gmail.com Sun May 13 00:45:59 2007 From: halfline at gmail.com (Ray Strode) Date: Sat, 12 May 2007 20:45:59 -0400 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179016879.17555.33.camel@vader.jdub.homelinux.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <1179016879.17555.33.camel@vader.jdub.homelinux.org> Message-ID: <45abe7d80705121745r8c08505nee2d9e3ecbcd5687@mail.gmail.com> Hi, > Awesome. Were you planning on packaging this tool for Fedora, or should > I whip something together? ajax beat you to it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239883 Ray From jwboyer at jdub.homelinux.org Sun May 13 00:51:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 19:51:48 -0500 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <45abe7d80705121745r8c08505nee2d9e3ecbcd5687@mail.gmail.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <1179016879.17555.33.camel@vader.jdub.homelinux.org> <45abe7d80705121745r8c08505nee2d9e3ecbcd5687@mail.gmail.com> Message-ID: <1179017509.17555.36.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 20:45 -0400, Ray Strode wrote: > Hi, > > Awesome. Were you planning on packaging this tool for Fedora, or should > > I whip something together? > > ajax beat you to it: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239883 Even better. Less stuff for me to do. Though I guess I could do the CVS approval. josh From rc040203 at freenet.de Sun May 13 05:54:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 13 May 2007 07:54:58 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1178907377.29429.92.camel@zod.rchland.ibm.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> Message-ID: <1179035699.4735.207.camel@mccallum.corsepiu.local> On Fri, 2007-05-11 at 13:16 -0500, Josh Boyer wrote: > On Fri, 2007-05-11 at 18:43 +0200, Ralf Corsepius wrote: > > On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > > > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > > > Josh Boyer wrote: > > > > > The Fedora wiki pages link to a list of all approved licenses for > > > > > packages. You could systematically go through and print off each of > > > > > these. > > > > > > But it is more hard for individual user to print, translate and certify. > > > > > > I always forget about translating. I blame it on me being a stupid US > > > born citizen. > > While we're at it: Does Fedora have a rule on a license language? > > Not that I know of. > > > Or conversely: Which languages does Fedora accept as valid wrt. > > Licenses? > > I actually think this depends on the license itself. E.g. you cannot > use a translated copy of the GPL unless it has been certified by the > FSF, so by default only the original English version is valid. > > > As RH is located in the USA, I'd presume Fedora to be subject to "US > > courts" in case of "legal matters" and as such I'd presume US laws would > > prescribe "English" (and may-be Spanish - I don't know)? > > English when it comes to "legal matters" in the US. So English is mandated on "legal matters" in the USA, but it's legal to ship products from inside of the USA (such as Fedora) with licenses in "foreign languages/scripts"? > > Background: We have precedences of "Japanese-only licenses" in Fedora > > packages. > > I don't see a problem with those per-se. Well, this might not be much of a problem if things go to court, because you'll probably need an official translation to a "legally valid language" and because such court will not necessarily be located inside of the USA. But, how do you expect "arbitrary users" to be able to apply such licenses? You can't seriously expect any arbitrary user to speak any arbitrary language or read any arbitrary script. Consider the "Russian case" having popped up in recent days on fedora-devel. There a user claimed having to "show all licenses of SW being used in a production environment to the police". While he probably is able to translate "English", further languages would raise an additional level of complications. Ralf From peter at thecodergeek.com Sun May 13 06:55:28 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 12 May 2007 23:55:28 -0700 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1179039328.18262.46.camel@tuxhugs> On Sat, 2007-05-12 at 09:43 -0400, Bill Nottingham wrote: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. > > We hope to get more automated rawhide pushes going soon. > > Bill > Very VERY **VERY** awesome. You people need to come down to the southern California area - I owe you a large quantity of beverages and donuts. 8) Downloading now; We'll see how it goes. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From johan at x-tnd.be Sun May 13 09:08:23 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Sun, 13 May 2007 11:08:23 +0200 Subject: RPM_OPT_FLAGS for klear Message-ID: <4646D587.9010405@x-tnd.be> Hello, I'm trying to package "klear" (a graphical tv viewer), and the reviwer tell me on the bugzilla that build does not use $RPM_OPT_FLAGS (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234355). I don't know how to achieve that, some help would be welcome. Regards, Johan From mtasaka at ioa.s.u-tokyo.ac.jp Sun May 13 09:24:25 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 13 May 2007 18:24:25 +0900 Subject: RPM_OPT_FLAGS for klear In-Reply-To: <4646D587.9010405@x-tnd.be> References: <4646D587.9010405@x-tnd.be> Message-ID: <4646D949.7020008@ioa.s.u-tokyo.ac.jp> Johan Cwiklinski wrote, at 05/13/2007 06:08 PM +9:00: > Hello, > > I'm trying to package "klear" (a graphical tv viewer), and the reviwer > tell me on the bugzilla that build does not use $RPM_OPT_FLAGS > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234355). > > I don't know how to achieve that, some help would be welcome. > > Regards, > Johan I cannot check this package soon because I don't usually use KDE (so I don't have kdebase-devel installed), however as this uses scons, perhaps the method like "aqsis" I reviewed (already imported into Fedora Extras) can be used to honor RPM_OPT_FLAGS (i.e. checking the spec file of "aqsis" may be useful for you) Mamoru From pbrobinson at gmail.com Sun May 13 09:27:06 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 13 May 2007 10:27:06 +0100 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <5256d0b0705130227q11995375s8b95a7483f13b33d@mail.gmail.com> > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). > > As part of my job at Intel I've now released a user friendly tool that > allows everyone that uses it to see what the biggest problems on their > own laptop are... The results internally to Intel have been really good; > several people gained an hour of battery just by using the tool and > getting rid of (or fixing) 'broken' applications. > > PowerTOP can be downloaded from http://www.linuxpowertop.org Very cool. Web site and mail archives are very slow though. Is there some tracker bugs for some of the core issues. Playing with it you see things like firefox right up the top of the list, along with a number of in kernel stuff (usb, libata etc) which, at a guess, people would already be aware of so there's probably already people working on it for things like OLPC. BTW, with the in-kernel cpuspeed stuff does the cpuspeed daemon still need to be run as it seems to be right up there too? Cheers, Pete (hoping one day to get the advertised 6 hours out of his extended battery) From johan at x-tnd.be Sun May 13 10:26:04 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Sun, 13 May 2007 12:26:04 +0200 Subject: RPM_OPT_FLAGS for klear In-Reply-To: <4646D949.7020008@ioa.s.u-tokyo.ac.jp> References: <4646D587.9010405@x-tnd.be> <4646D949.7020008@ioa.s.u-tokyo.ac.jp> Message-ID: <4646E7BC.7090902@x-tnd.be> Mamoru Tasaka a ?crit : > Johan Cwiklinski wrote, at 05/13/2007 06:08 PM +9:00: >> Hello, >> >> I'm trying to package "klear" (a graphical tv viewer), and the >> reviwer tell me on the bugzilla that build does not use >> $RPM_OPT_FLAGS >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234355). >> >> I don't know how to achieve that, some help would be welcome. >> >> Regards, >> Johan > > I cannot check this package soon because I don't usually use KDE > (so I don't have kdebase-devel installed), however as this uses > scons, perhaps the method like "aqsis" I reviewed (already imported > into Fedora Extras) can be used to honor RPM_OPT_FLAGS (i.e. > checking the spec file of "aqsis" may be useful for you) > > Mamoru > > Ok I've checked aqsis specfile, many thanks for your help :) Johan From gilboad at gmail.com Sun May 13 10:19:31 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 13 May 2007 13:19:31 +0300 Subject: Firefox not using ~/Download In-Reply-To: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> References: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> Message-ID: <1179051571.1664.2.camel@gilboa-work-dev.localdomain> On Sat, 2007-05-12 at 14:18 +0530, Debarshi 'Rishi' Ray wrote: > It seems that Firefox is not using the ~/Download directory for > storing its downloads. The default location is still ~/Desktop. > Although one can easily change the settings in Firefox, isn't it more > reasonable if all applications made use of the ~/Download directory by > default when one is available? > > Regards, > Debarshi > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu > I'd suggest you file a bug report about it. - Gilboa From johan at x-tnd.be Sun May 13 10:59:18 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Sun, 13 May 2007 12:59:18 +0200 Subject: Duplicate files - Kickoff RPM - KDE Message-ID: <4646EF86.4030602@x-tnd.be> Hello, I've been trying for a while to build "kickoff", an alternative menu for KDE. This software is developped by suse and is in fact a patched kdebase/kicker. The problem is made of many files which are already present from kdebase package. I've told one of the developers about this problem, who said me to try to install only "kicker/" and "kcontrol/kicker/" subdirs ; but I don't have any idea how to achieve this properly. My spec file in its actual state is there : http://odysseus.x-tnd.be/fedora/kickoff/ Regards, Johan From dominik at greysector.net Sun May 13 11:01:00 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 13 May 2007 13:01:00 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <20070513110100.GC22523@ryvius.pekin.waw.pl> On Sunday, 13 May 2007 at 00:12, Arjan van de Ven wrote: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). > > As part of my job at Intel I've now released a user friendly tool that > allows everyone that uses it to see what the biggest problems on their > own laptop are... The results internally to Intel have been really good; > several people gained an hour of battery just by using the tool and > getting rid of (or fixing) 'broken' applications. > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > for completeness I've attached the full announcement text I used in > other places below. I hope that enough people will use it and report / > fix issues in software so that the whole Linux experience on laptops > will be a lot better in a few months.. Hey, this is pretty cool. Here's what it says on my amd64 desktop: No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option. This option will automatically disable UHCI USB when not in use, and may save approximately 1 Watt of power. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at jdub.homelinux.org Sun May 13 11:42:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 13 May 2007 06:42:42 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1179035699.4735.207.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> Message-ID: <1179056562.17555.38.camel@vader.jdub.homelinux.org> On Sun, 2007-05-13 at 07:54 +0200, Ralf Corsepius wrote: > On Fri, 2007-05-11 at 13:16 -0500, Josh Boyer wrote: > > On Fri, 2007-05-11 at 18:43 +0200, Ralf Corsepius wrote: > > > On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > > > > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > > > > Josh Boyer wrote: > > > > > > The Fedora wiki pages link to a list of all approved licenses for > > > > > > packages. You could systematically go through and print off each of > > > > > > these. > > > > > > > > But it is more hard for individual user to print, translate and certify. > > > > > > > > I always forget about translating. I blame it on me being a stupid US > > > > born citizen. > > > While we're at it: Does Fedora have a rule on a license language? > > > > Not that I know of. > > > > > Or conversely: Which languages does Fedora accept as valid wrt. > > > Licenses? > > > > I actually think this depends on the license itself. E.g. you cannot > > use a translated copy of the GPL unless it has been certified by the > > FSF, so by default only the original English version is valid. > > > > > As RH is located in the USA, I'd presume Fedora to be subject to "US > > > courts" in case of "legal matters" and as such I'd presume US laws would > > > prescribe "English" (and may-be Spanish - I don't know)? > > > > English when it comes to "legal matters" in the US. > So English is mandated on "legal matters" in the USA, but it's legal to > ship products from inside of the USA (such as Fedora) with licenses in > "foreign languages/scripts"? > > > > Background: We have precedences of "Japanese-only licenses" in Fedora > > > packages. > > > > I don't see a problem with those per-se. > Well, this might not be much of a problem if things go to court, because > you'll probably need an official translation to a "legally valid > language" and because such court will not necessarily be located inside > of the USA. > > But, how do you expect "arbitrary users" to be able to apply such > licenses? You can't seriously expect any arbitrary user to speak any > arbitrary language or read any arbitrary script. > > Consider the "Russian case" having popped up in recent days on > fedora-devel. There a user claimed having to "show all licenses of SW > being used in a production environment to the police". While he probably > is able to translate "English", further languages would raise an > additional level of complications. What exactly is your point? That was the purpose of this whole thread... josh From dtimms at iinet.net.au Sun May 13 13:52:10 2007 From: dtimms at iinet.net.au (David Timms) Date: Sun, 13 May 2007 23:52:10 +1000 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <4647180A.1030800@iinet.net.au> Arjan van de Ven wrote: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). ... Would this tool help one in tracing the cause of disk accesses in an otherwise inactive/idle notebook. It seems to be about every 3 seconds or so that the hard disk LED lights. This must make it impossible for the hard drive to get powered down - and save power. DaveT. From rdieter at math.unl.edu Sun May 13 14:17:28 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 13 May 2007 09:17:28 -0500 Subject: Duplicate files - Kickoff RPM - KDE In-Reply-To: <4646EF86.4030602@x-tnd.be> References: <4646EF86.4030602@x-tnd.be> Message-ID: Johan Cwiklinski wrote: > I've told one of the developers about this problem, who said me to try > to install only "kicker/" and "kcontrol/kicker/" subdirs ; but I don't > have any idea how to achieve this properly. (Haven't tried, but hopefully): Replace: unsermake install DESTDIR=$RPM_BUILD_ROOT with (cd kcontrol/kicker ; unsermake install DESTDIR=$RPM_BUILD_ROOT ) (cd kicker/ ; unsermake install DESTDIR=$RPM_BUILD_ROOT ) and adjust %files accordingly. -- Rex From gfc at altern.org Sun May 13 13:55:28 2007 From: gfc at altern.org (Guillaume Chazarain) Date: Sun, 13 May 2007 15:55:28 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <4647180A.1030800@iinet.net.au> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> Message-ID: <464718D0.3030902@altern.org> David Timms a ?crit : > Would this tool help one in tracing the cause of disk accesses in an > otherwise inactive/idle notebook. It seems to be about every 3 seconds > or so that the hard disk LED lights. This must make it impossible for > the hard drive to get powered down - and save power. echo 1 > /proc/sys/vm/block_dump and then watching dmesg should tell you what happens. Typically: some processing reading some files and updating the atimes. So, look for mount -o noatime. Cheers. -- Guillaume From dtimms at iinet.net.au Sun May 13 14:29:19 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 14 May 2007 00:29:19 +1000 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <464718D0.3030902@altern.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <464718D0.3030902@altern.org> Message-ID: <464720BF.7080702@iinet.net.au> Guillaume Chazarain wrote: > David Timms a ?crit : >> Would this tool help one in tracing the cause of disk accesses in an >> otherwise inactive/idle notebook. It seems to be about every 3 seconds >> or so that the hard disk LED lights. This must make it impossible for >> the hard drive to get powered down - and save power. > > echo 1 > /proc/sys/vm/block_dump > and then watching dmesg should tell you what happens. > Typically: some processing reading some files and updating the atimes. > So, look for mount -o noatime. OK, that works. Is there some way to tell dmesg to do the equivalent of: tail -f dmesg {which doesn't work} ? DaveT. From gfc at altern.org Sun May 13 14:39:45 2007 From: gfc at altern.org (Guillaume Chazarain) Date: Sun, 13 May 2007 16:39:45 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <464720BF.7080702@iinet.net.au> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <464718D0.3030902@altern.org> <464720BF.7080702@iinet.net.au> Message-ID: <46472331.7040203@altern.org> David Timms a ?crit : > OK, that works. Is there some way to tell dmesg to do the equivalent of: > tail -f dmesg {which doesn't work} ? # /etc/init.d/syslog stop # cat /proc/kmsg Should do it. Regards. -- Guillaume From dominik at greysector.net Sun May 13 15:04:23 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 13 May 2007 17:04:23 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <464720BF.7080702@iinet.net.au> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <464718D0.3030902@altern.org> <464720BF.7080702@iinet.net.au> Message-ID: <20070513150423.GB1634@ryvius.pekin.waw.pl> On Sunday, 13 May 2007 at 16:29, David Timms wrote: > Guillaume Chazarain wrote: > >David Timms a ?crit : > >>Would this tool help one in tracing the cause of disk accesses in an > >>otherwise inactive/idle notebook. It seems to be about every 3 seconds > >>or so that the hard disk LED lights. This must make it impossible for > >>the hard drive to get powered down - and save power. > > > >echo 1 > /proc/sys/vm/block_dump > >and then watching dmesg should tell you what happens. > >Typically: some processing reading some files and updating the atimes. > >So, look for mount -o noatime. > OK, that works. Is there some way to tell dmesg to do the equivalent of: > tail -f dmesg {which doesn't work} ? watch tail dmesg ;) Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From arjan at fenrus.demon.nl Sun May 13 17:06:05 2007 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 13 May 2007 10:06:05 -0700 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <4647180A.1030800@iinet.net.au> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> Message-ID: <1179075965.19106.1.camel@laptopd505.fenrus.org> On Sun, 2007-05-13 at 23:52 +1000, David Timms wrote: > Arjan van de Ven wrote: > > Hi, > > > > some of you already know that I've been working on getting Linux (and > > Fedora) to be a lot better about power usage on laptops by avoiding > > spurious wakeups and context switches and such (look at the "wakeup" bug > > in fedora bugzilla ;). > ... > Would this tool help one in tracing the cause of disk accesses in an > otherwise inactive/idle notebook. It seems to be about every 3 seconds > or so that the hard disk LED lights. This must make it impossible for > the hard drive to get powered down - and save power. I've gotten this request a few times now; I'll be looking into this for version 2.0; I'd think it would be possible with blktrace but I need to look into the details (don't want this tracing to spoil any other measurements ;) From fedora at leemhuis.info Sun May 13 17:24:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 19:24:35 +0200 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <1179075965.19106.1.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> Message-ID: <464749D3.3090500@leemhuis.info> On 13.05.2007 19:06, Arjan van de Ven wrote: > On Sun, 2007-05-13 at 23:52 +1000, David Timms wrote: >> Arjan van de Ven wrote: >>> some of you already know that I've been working on getting Linux (and >>> Fedora) to be a lot better about power usage on laptops by avoiding >>> spurious wakeups and context switches and such (look at the "wakeup" bug >>> in fedora bugzilla ;). >> ... >> Would this tool help one in tracing the cause of disk accesses in an >> otherwise inactive/idle notebook. It seems to be about every 3 seconds >> or so that the hard disk LED lights. This must make it impossible for >> the hard drive to get powered down - and save power. > I've gotten this request a few times now; I'll be looking into this for > version 2.0; I'd think it would be possible with blktrace but I need to > look into the details (don't want this tracing to spoil any other > measurements ;) Just wondering: does Fedora spin down the hard disk by default? It doesn't afaics and it's not easily user-configurable either afaik. Gnome-power-manager sounds like the proper place to control if the hard disk gets powered down; but well, seem Richard got burned when he tried it last time: See http://lists.freedesktop.org/archives/hal/2005-October/003538.html and quoting from http://live.gnome.org/GnomePowerManager/FAQ : ---- GNOME Power Manager doesn't spin down my hard-drive! After numerous debates, the consensus was that is was not a good idea to add this functionality to HAL. It's was decided user-configurable powermanagement was not really required when modern hard disks have really intelligent powermanagment. A disk on Low Power idle need less than 1 Watt per hour. For a normal battery with 50000mWh you could run the harddisk for over 50 hours. If you do not read/write from/to the harddisk the disk regulates power, but never shuts down the device. The reason is easy: you lost more power with each startup than to leave the harddisk online somewhere between 'Active idle' and 'Low power idle' (depends on the model/manufacturer). The other reason to leave this to the internal powermanagement of the disk is: the time needed to reactivate the device. You lose more performance than you lose power between 'Active idle' and 'Low power idle'. If you use a journaling file system you normally need to flush periodically. This could run in a race between shut down device and restart device by system to flush. This means more power consumption as you change nothing. You can't set powermanagement for exteral USB harddisks, because you can't send the needed commands over the USB link to the disk. ---- So maybe this is not worth the trouble? CU thl @Richard: the link to the FAQ in the top header on http://www.gnome.org/projects/gnome-power-manager/ gives a 404; the one in the right "Feedback" section point to a URL that redirects the user to http://svn.gnome.org/viewcvs/*checkout*/gnome-power-manager/trunk/docs/faq.html which doesn't work. From nicolas.mailhot at laposte.net Sun May 13 17:38:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 13 May 2007 19:38:44 +0200 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <464749D3.3090500@leemhuis.info> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> Message-ID: <1179077925.5040.1.camel@rousalka.dyndns.org> Le dimanche 13 mai 2007 ? 19:24 +0200, Thorsten Leemhuis a ?crit : > Just wondering: does Fedora spin down the hard disk by default? It > doesn't afaics and it's not easily user-configurable either afaik. Also is smartctl poking the disks with a frequency low enough to allow spin down? -- 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 hughsient at gmail.com Sun May 13 18:23:02 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 13 May 2007 19:23:02 +0100 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <464749D3.3090500@leemhuis.info> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> Message-ID: <1179080582.2511.9.camel@hughsie-laptop> On Sun, 2007-05-13 at 19:24 +0200, Thorsten Leemhuis wrote: > On 13.05.2007 19:06, Arjan van de Ven wrote: > > On Sun, 2007-05-13 at 23:52 +1000, David Timms wrote: > >> Arjan van de Ven wrote: > >>> some of you already know that I've been working on getting Linux (and > >>> Fedora) to be a lot better about power usage on laptops by avoiding > >>> spurious wakeups and context switches and such (look at the "wakeup" bug > >>> in fedora bugzilla ;). > >> ... > >> Would this tool help one in tracing the cause of disk accesses in an > >> otherwise inactive/idle notebook. It seems to be about every 3 seconds > >> or so that the hard disk LED lights. This must make it impossible for > >> the hard drive to get powered down - and save power. > > I've gotten this request a few times now; I'll be looking into this for > > version 2.0; I'd think it would be possible with blktrace but I need to > > look into the details (don't want this tracing to spoil any other > > measurements ;) (cheers for the cc) > Just wondering: does Fedora spin down the hard disk by default? It > doesn't afaics and it's not easily user-configurable either afaik. It doesn't - you have to be very careful with the amount of power it takes to spin-up a drive (often significant) compared to the amount of time it's spun down. The amount of disk accesses is indeed horrific in a modern distro, and the drive doesn't usually spin down for long, even with laptop-mode flushing. This is bad. > Gnome-power-manager sounds like the proper place to control if the hard > disk gets powered down; but well, seem Richard got burned when he tried > it last time: Heh, burned is one word. :-) Unless we keep the disk from spinning up, my patch isn't actually that effective. I am however using a similar patch to HAL on my media center embedded PC, where I'm only running a pretty stripped system, and spin the disks down mostly for noise, not power saving. My view still is that this is a valid patch to HAL, and I would be quite happy to do the action automatically in g-p-m. I'm not sure we need UI - we can probably just profile the mean time that the disk is idle and work out if it is worth powering down. Ideas welcome. > See http://lists.freedesktop.org/archives/hal/2005-October/003538.html > and quoting from http://live.gnome.org/GnomePowerManager/FAQ : > ---- > GNOME Power Manager doesn't spin down my hard-drive! > > After numerous debates, the consensus was that is was not a good idea to > add this functionality to HAL. It's was decided user-configurable > powermanagement was not really required when modern hard disks have > really intelligent powermanagment. (I wrote this after numerous conversations with dannyk) True about the intelligent pm, although I still think we can make big savings if we do this carefully. > ...You can't set powermanagement for exteral USB > harddisks, because you can't send the needed commands over the USB link > to the disk. Can we still do this using libata? > So maybe this is not worth the trouble? I think it is - we are trimming easy stuff (like cpufreq and brightness) and I think we need to start looking at the drive spindown with a new vigour. Richard. (g-p-m dude) From drago01 at gmail.com Sun May 13 18:26:00 2007 From: drago01 at gmail.com (dragoran dragoran) Date: Sun, 13 May 2007 20:26:00 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <20070513110100.GC22523@ryvius.pekin.waw.pl> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <20070513110100.GC22523@ryvius.pekin.waw.pl> Message-ID: On 5/13/07, Dominik 'Rathann' Mierzejewski wrote: > > On Sunday, 13 May 2007 at 00:12, Arjan van de Ven wrote: > > Hi, > > > > some of you already know that I've been working on getting Linux (and > > Fedora) to be a lot better about power usage on laptops by avoiding > > spurious wakeups and context switches and such (look at the "wakeup" bug > > in fedora bugzilla ;). > > > > As part of my job at Intel I've now released a user friendly tool that > > allows everyone that uses it to see what the biggest problems on their > > own laptop are... The results internally to Intel have been really good; > > several people gained an hour of battery just by using the tool and > > getting rid of (or fixing) 'broken' applications. > > > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > > > > for completeness I've attached the full announcement text I used in > > other places below. I hope that enough people will use it and report / > > fix issues in software so that the whole Linux experience on laptops > > will be a lot better in a few months.. > > Hey, this is pretty cool. > > Here's what it says on my amd64 desktop: > > No detailed statistics available; please enable the CONFIG_TIMER_STATS > kernel option > > Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option. > This option will automatically disable UHCI USB when not in use, and may > save approximately 1 Watt of power. same here using a core 2 duo t7400 on fc6 x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Sun May 13 18:40:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 20:40:28 +0200 Subject: hard disk power down In-Reply-To: <1179080582.2511.9.camel@hughsie-laptop> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> Message-ID: <46475B9C.4090003@leemhuis.info> On 13.05.2007 20:23, Richard Hughes wrote: > On Sun, 2007-05-13 at 19:24 +0200, Thorsten Leemhuis wrote: > >> Just wondering: does Fedora spin down the hard disk by default? It >> doesn't afaics and it's not easily user-configurable either afaik. > It doesn't - you have to be very careful with the amount of power it > takes to spin-up a drive (often significant) compared to the amount of > time it's spun down. Yeah, likely; but with Robson/TurboMemory (that gets deployed in some of the the Santa Rosa Notebooks that were announced in the past days) and hybrid hard disks it might become much more attractive to spin down the hard drive *if* (big if) linux starts supporting that stuff. > The amount of disk accesses is indeed horrific in a modern distro, and > the drive doesn't usually spin down for long, even with laptop-mode > flushing. This is bad. Sounds like there is a lot of stuff to fix in a whole lot of different areas :-/ > [...] CU thl From ruben at rubenkerkhof.com Sun May 13 18:43:37 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sun, 13 May 2007 20:43:37 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <20070513150423.GB1634@ryvius.pekin.waw.pl> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <464718D0.3030902@altern.org> <464720BF.7080702@iinet.net.au> <20070513150423.GB1634@ryvius.pekin.waw.pl> Message-ID: On 13-mei-2007, at 17:04, Dominik 'Rathann' Mierzejewski wrote: > watch tail dmesg > > ;) > > Regards, > R. [ruben at odin ~]$ watch tail dmesg tail: cannot open `dmesg' for reading: No such file or directory this works for me: [ruben at odin ~]$ watch "dmesg | tail" Cheers, Ruben From debarshi.ray at gmail.com Sun May 13 19:01:19 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 14 May 2007 00:31:19 +0530 Subject: Firefox not using ~/Download In-Reply-To: <1179051571.1664.2.camel@gilboa-work-dev.localdomain> References: <3170f42f0705120148t6313296ao7816e194c7081996@mail.gmail.com> <1179051571.1664.2.camel@gilboa-work-dev.localdomain> Message-ID: <3170f42f0705131201ueafecc7j262e278d44cec64e@mail.gmail.com> > I'd suggest you file a bug report about it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239975 Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ville.skytta at iki.fi Sun May 13 19:10:47 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 13 May 2007 22:10:47 +0300 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <1179080582.2511.9.camel@hughsie-laptop> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> Message-ID: <200705132210.48978.ville.skytta@iki.fi> On Sunday 13 May 2007, Richard Hughes wrote: > On Sun, 2007-05-13 at 19:24 +0200, Thorsten Leemhuis wrote: > > > Just wondering: does Fedora spin down the hard disk by default? It > > doesn't afaics and it's not easily user-configurable either afaik. > > It doesn't - you have to be very careful with the amount of power it > takes to spin-up a drive (often significant) compared to the amount of > time it's spun down. In addition to power consumption, noise may be important in some setups. > The amount of disk accesses is indeed horrific in a modern distro, and > the drive doesn't usually spin down for long, even with laptop-mode > flushing. This is bad. A bit off topic, but I'm currently (ab?)using FC6's read only root/temporary state config in my PVR point get the "unwanted" reads and writes to a tmpfs, and persist those files back on disk at shutdown. The implementation is not too pretty and is applicable to a fairly limited set of scenarios, but has worked well for me. Anyway it'd be nice to have something like that in the distro so it'd be likely less fragile. More details and a RFE at https://bugzilla.redhat.com/223722 From selinux at gmail.com Sun May 13 19:54:46 2007 From: selinux at gmail.com (Tom London) Date: Sun, 13 May 2007 12:54:46 -0700 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <4c4ba1530705131254y8e818detbcacb1ddf8c066b5@mail.gmail.com> On 5/12/07, Arjan van de Ven wrote: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). > > As part of my job at Intel I've now released a user friendly tool that > allows everyone that uses it to see what the biggest problems on their > own laptop are... The results internally to Intel have been really good; > several people gained an hour of battery just by using the tool and > getting rid of (or fixing) 'broken' applications. > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > for completeness I've attached the full announcement text I used in > other places below. I hope that enough people will use it and report / > fix issues in software so that the whole Linux experience on laptops > will be a lot better in a few months.. > > > > ---------------------- > > What's eating the battery life of my laptop? Why isn't it many more > hours? Which software component causes the most power to be burned? > These are important questions without a good answer... until now. > > The Linux 2.6.21 kernel introduces the so called tickless-idle > feature. This feature allows the processor to be really idle for long > periods of time, rather than having to wake up every millisecond for > the timer tick. Current processors save a lot of power if they are > idle for long periods, which translates into a longer battery life for > your laptop, or a lower energy bill for your datacenter. However, a > Linux system consists of more software than just the kernel, and there > are many tunables involved. It's not easy to see what is going on, and > as a result the behavior is sometimes far from optimal, and a lot of > power is wasted. > > Intel is proud to announce the PowerTOP tool > (http://www.linuxpowertop.org), a program that collects the various > pieces of information from your system and presents an overview of how > well your laptop is doing in terms of power savings. In addition, > PowerTOP will provide an indication of which tunables and software > components are the biggest offenders in slurping up your battery time. > PowerTOP will update it's display frequently so that you can directly > see the impact of any changes you are making. > > A typical Linux distribution has many components that wake the > processor up frequently for no good reason. In our testing with > PowerTOP, we have seen many cases where with some simple fixes, the > battery life of typical laptops was increased by one hour or more! > > We are providing fixes for several of the issues we identified, and we > encourage the Linux community to help us in this quest to get the > maximum battery life out of your (hopefully Intel based) laptops. Try > the PowerTOP tool, join the mailing list or the IRC channel and > provide feedback, problem reports or fixes! > Interesting..... Bringing up a gmail tab in firefox appears to push firefox from about 60 to about 500 wakeups per second.... Selecting 'standard without chat' mode brings it back down to about 60. Anyone know what is going on with google/gmail chat? tom -- Tom London From nicolas.mailhot at laposte.net Sun May 13 20:04:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 13 May 2007 22:04:49 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <4c4ba1530705131254y8e818detbcacb1ddf8c066b5@mail.gmail.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4c4ba1530705131254y8e818detbcacb1ddf8c066b5@mail.gmail.com> Message-ID: <1179086689.5959.0.camel@rousalka.dyndns.org> Le dimanche 13 mai 2007 ? 12:54 -0700, Tom London a ?crit : > Bringing up a gmail tab in firefox appears to push firefox from about > 60 to about 500 wakeups per second.... > > Selecting 'standard without chat' mode brings it back down to about 60. > > Anyone know what is going on with google/gmail chat? Behold the wonders of ajax and asynchroneous processing -- 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 martin.sourada at seznam.cz Sun May 13 19:37:35 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 13 May 2007 21:37:35 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <464768FF.70202@seznam.cz> Arjan van de Ven wrote: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). > > As part of my job at Intel I've now released a user friendly tool that > allows everyone that uses it to see what the biggest problems on their > own laptop are... The results internally to Intel have been really good; > several people gained an hour of battery just by using the tool and > getting rid of (or fixing) 'broken' applications. > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > for completeness I've attached the full announcement text I used in > other places below. I hope that enough people will use it and report / > fix issues in software so that the whole Linux experience on laptops > will be a lot better in a few months.. > > > > ---------------------- > > What's eating the battery life of my laptop? Why isn't it many more > hours? Which software component causes the most power to be burned? > These are important questions without a good answer... until now. > > The Linux 2.6.21 kernel introduces the so called tickless-idle > feature. This feature allows the processor to be really idle for long > periods of time, rather than having to wake up every millisecond for > the timer tick. Current processors save a lot of power if they are > idle for long periods, which translates into a longer battery life for > your laptop, or a lower energy bill for your datacenter. However, a > Linux system consists of more software than just the kernel, and there > are many tunables involved. It's not easy to see what is going on, and > as a result the behavior is sometimes far from optimal, and a lot of > power is wasted. > > Intel is proud to announce the PowerTOP tool > (http://www.linuxpowertop.org), a program that collects the various > pieces of information from your system and presents an overview of how > well your laptop is doing in terms of power savings. In addition, > PowerTOP will provide an indication of which tunables and software > components are the biggest offenders in slurping up your battery time. > PowerTOP will update it's display frequently so that you can directly > see the impact of any changes you are making. > > A typical Linux distribution has many components that wake the > processor up frequently for no good reason. In our testing with > PowerTOP, we have seen many cases where with some simple fixes, the > battery life of typical laptops was increased by one hour or more! > > We are providing fixes for several of the issues we identified, and we > encourage the Linux community to help us in this quest to get the > maximum battery life out of your (hopefully Intel based) laptops. Try > the PowerTOP tool, join the mailing list or the IRC channel and > provide feedback, problem reports or fixes! > > Website: http://www.linuxpowertop.org > IRC: irc.oftc.net #powertop channel > Mailing list: http://www.bughost.org/mailman/listinfo/power > Cool thing, just tried it on rawhide with the not-so-unexpected result where the top is liferea and epiphany followed by usb, XOrg and eth0.... But what I didn't expect was the power usage and count of wakeups: Wakeups-from-idle per second : 413.0 Power usage (ACPI estimate) : 1.1 W (2.4 hours left) 1.1 W? That is really low IMO... Really, really interesting. Hope this tool helps to improve linux powersaving capabilities in the future. Keep the good work :-) Martin From tonynelson at georgeanelson.com Sun May 13 21:00:07 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sun, 13 May 2007 17:00:07 -0400 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <4c4ba1530705131254y8e818detbcacb1ddf8c066b5@mail.gmail.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4c4ba1530705131254y8e818detbcacb1ddf8c066b5@mail.gmail.com> Message-ID: At 12:54 PM -0700 5/13/07, Tom London wrote: >Interesting..... > >Bringing up a gmail tab in firefox appears to push firefox from about >60 to about 500 wakeups per second.... > >Selecting 'standard without chat' mode brings it back down to about 60. > >Anyone know what is going on with google/gmail chat? Could it be Google Talk? -- ____________________________________________________________________ TonyN.:' ' From martin.sourada at seznam.cz Sun May 13 21:11:32 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 13 May 2007 23:11:32 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <464768FF.70202@seznam.cz> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464768FF.70202@seznam.cz> Message-ID: <46477F04.1050608@seznam.cz> Martin Sourada wrote: > > > Cool thing, just tried it on rawhide with the not-so-unexpected result > where the top is liferea and epiphany followed by usb, XOrg and eth0.... > But what I didn't expect was the power usage and count of wakeups: > Wakeups-from-idle per second : 413.0 > Power usage (ACPI estimate) : 1.1 W (2.4 hours left) > > 1.1 W? That is really low IMO... Really, really interesting. Hope this > tool helps to improve linux powersaving capabilities in the future. Keep > the good work :-) > > Martin > I looked once more at the power usage: 1.1W... is it OK? Shouldn't there be 11W? I have quite ordinal laptop with Intel Celeron M 420, I don't think such low power usage is possible on this... Any idea? And well, I have the 1.1 version of PowerTOP. Thanks, Martin From martin.sourada at seznam.cz Sun May 13 21:38:27 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 13 May 2007 23:38:27 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <46477F04.1050608@seznam.cz> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464768FF.70202@seznam.cz> <46477F04.1050608@seznam.cz> Message-ID: <46478553.5050409@seznam.cz> Martin Sourada wrote: > Martin Sourada wrote: >> >> >> Cool thing, just tried it on rawhide with the not-so-unexpected result >> where the top is liferea and epiphany followed by usb, XOrg and >> eth0.... But what I didn't expect was the power usage and count of >> wakeups: >> Wakeups-from-idle per second : 413.0 >> Power usage (ACPI estimate) : 1.1 W (2.4 hours left) >> >> 1.1 W? That is really low IMO... Really, really interesting. Hope this >> tool helps to improve linux powersaving capabilities in the future. >> Keep the good work :-) >> >> Martin >> > > I looked once more at the power usage: 1.1W... is it OK? Shouldn't there > be 11W? I have quite ordinal laptop with Intel Celeron M 420, I don't > think such low power usage is possible on this... Any idea? And well, I > have the 1.1 version of PowerTOP. > > Thanks, > Martin > As kernel says: # cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 1212 mA remaining capacity: 262 mAh present voltage: 13759 mV the power usage should be around 16 W. Is it a bug in the PowerTOP, or is it supposed to mean something different (currently it shows 1.2 W)? Thanks, Martin From hughsient at gmail.com Sun May 13 21:46:27 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 13 May 2007 22:46:27 +0100 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <46478553.5050409@seznam.cz> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464768FF.70202@seznam.cz> <46477F04.1050608@seznam.cz> <46478553.5050409@seznam.cz> Message-ID: <1179092787.8130.4.camel@hughsie-laptop> On Sun, 2007-05-13 at 23:38 +0200, Martin Sourada wrote: > As kernel says: > # cat /proc/acpi/battery/BAT1/state > present: yes > capacity state: ok > charging state: discharging > present rate: 1212 mA > remaining capacity: 262 mAh > present voltage: 13759 mV >From real life experience, trusting these numbers is dangerous. > the power usage should be around 16 W. Is it a bug in the PowerTOP, or > is it supposed to mean something different (currently it shows 1.2 W)? Do; lshal | grep battery.reporting.rate Then it's normalised and made a little more sane. Richard. From martin.sourada at seznam.cz Sun May 13 21:54:59 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 13 May 2007 23:54:59 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179092787.8130.4.camel@hughsie-laptop> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464768FF.70202@seznam.cz> <46477F04.1050608@seznam.cz> <46478553.5050409@seznam.cz> <1179092787.8130.4.camel@hughsie-laptop> Message-ID: <46478933.3080801@seznam.cz> Richard Hughes wrote: > On Sun, 2007-05-13 at 23:38 +0200, Martin Sourada wrote: >> As kernel says: >> # cat /proc/acpi/battery/BAT1/state >> present: yes >> capacity state: ok >> charging state: discharging >> present rate: 1212 mA >> remaining capacity: 262 mAh >> present voltage: 13759 mV > >>From real life experience, trusting these numbers is dangerous. > Maybe, but 16W to 1.2W is way too big difference to ignore it. > > Do; > > lshal | grep battery.reporting.rate > > Then it's normalised and made a little more sane. > > Richard. > > # lshal | grep battery.reporting.rate battery.reporting.rate = 1018 (0x3fa) (int) Martin From jburgess777 at googlemail.com Sun May 13 22:23:59 2007 From: jburgess777 at googlemail.com (Jon Burgess) Date: Sun, 13 May 2007 23:23:59 +0100 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <46478553.5050409@seznam.cz> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <464768FF.70202@seznam.cz> <46477F04.1050608@seznam.cz> <46478553.5050409@seznam.cz> Message-ID: <1179095039.23409.66.camel@localhost.localdomain> On Sun, 2007-05-13 at 23:38 +0200, Martin Sourada wrote: > Martin Sourada wrote: > > Martin Sourada wrote: > >> > >> > >> Cool thing, just tried it on rawhide with the not-so-unexpected result > >> where the top is liferea and epiphany followed by usb, XOrg and > >> eth0.... But what I didn't expect was the power usage and count of > >> wakeups: > >> Wakeups-from-idle per second : 413.0 > >> Power usage (ACPI estimate) : 1.1 W (2.4 hours left) > >> > >> 1.1 W? That is really low IMO... Really, really interesting. Hope this > >> tool helps to improve linux powersaving capabilities in the future. > >> Keep the good work :-) > >> > >> Martin > >> > > > > I looked once more at the power usage: 1.1W... is it OK? Shouldn't there > > be 11W? I have quite ordinal laptop with Intel Celeron M 420, I don't > > think such low power usage is possible on this... Any idea? And well, I > > have the 1.1 version of PowerTOP. > > > > Thanks, > > Martin > > > > As kernel says: > # cat /proc/acpi/battery/BAT1/state > present: yes > capacity state: ok > charging state: discharging > present rate: 1212 mA > remaining capacity: 262 mAh > present voltage: 13759 mV > > the power usage should be around 16 W. Is it a bug in the PowerTOP, or is it > supposed to mean something different (currently it shows 1.2 W)? > It looks to me like it is using "present rate" which would be 1.2A forgetting that to calculate Watts you need to multiply the current(A) by voltage (V). A more reasonable answer would be... Power drain = 1.212A * 13.759V = 16.676W Jon From opensource at till.name Sun May 13 22:41:32 2007 From: opensource at till.name (Till Maas) Date: Mon, 14 May 2007 00:41:32 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179095039.23409.66.camel@localhost.localdomain> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <46478553.5050409@seznam.cz> <1179095039.23409.66.camel@localhost.localdomain> Message-ID: <200705140041.34048.opensource@till.name> On Mo Mai 14 2007, Jon Burgess wrote: > It looks to me like it is using "present rate" which would be 1.2A The unit of "present rate" varies from notebook to notebook, Thinkpad X40 and X41 use mW instead of mA, Regards, Till From i at stingr.net Sun May 13 23:13:25 2007 From: i at stingr.net (Paul P Komkoff Jr) Date: Mon, 14 May 2007 03:13:25 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <46446924.1080209@odu.neva.ru> References: <46446924.1080209@odu.neva.ru> Message-ID: <20070513231325.GB22452@stingr.net> Replying to Dmitry Butskoy: > The using of software in business and production environment can be a > subject for legislative regulation. It can lead to some legal troubles > of using of distributions like Fedora. Such an interesting thread and I almost missed it! First, what is teh License. Not a single entity who are now involved in IP law enforcement in Russia understands this. And, despite what Alan said about learning, I don't see how it can be improved. The situation will be only worse. But then, how to deal with it. Typical scenario starts when teh police comes and asks for the licenses. The only thing we need to do here is to show them proof of purchase or the printed licenses when someone with rights grants you permission to use the software. In other words, you, as Dmitry Butskoy, can comply to Fedora' EULA and GPL by redistributing entire distribution to your organization for free. Print the GPL, print the russian translation (non-official/for info purposes only), sign, show. This will be enough - in cases They haven't "told" to shutdown your business specifically. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From jbarnes at virtuousgeek.org Sun May 13 23:23:02 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sun, 13 May 2007 16:23:02 -0700 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <20070513110100.GC22523@ryvius.pekin.waw.pl> Message-ID: <200705131623.02391.jbarnes@virtuousgeek.org> On Sunday, May 13, 2007, dragoran dragoran wrote: > On 5/13/07, Dominik 'Rathann' Mierzejewski wrote: > > On Sunday, 13 May 2007 at 00:12, Arjan van de Ven wrote: > > > Hi, > > > > > > some of you already know that I've been working on getting Linux > > > (and Fedora) to be a lot better about power usage on laptops by > > > avoiding spurious wakeups and context switches and such (look at the > > > "wakeup" bug in fedora bugzilla ;). > > > > > > As part of my job at Intel I've now released a user friendly tool > > > that allows everyone that uses it to see what the biggest problems > > > on their own laptop are... The results internally to Intel have been > > > really good; several people gained an hour of battery just by using > > > the tool and getting rid of (or fixing) 'broken' applications. > > > > > > PowerTOP can be downloaded from http://www.linuxpowertop.org > > > > > > > > > for completeness I've attached the full announcement text I used in > > > other places below. I hope that enough people will use it and report > > > / fix issues in software so that the whole Linux experience on > > > laptops will be a lot better in a few months.. > > > > Hey, this is pretty cool. > > > > Here's what it says on my amd64 desktop: > > > > No detailed statistics available; please enable the CONFIG_TIMER_STATS > > kernel option > > > > Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option. > > This option will automatically disable UHCI USB when not in use, and > > may save approximately 1 Watt of power. > > same here using a core 2 duo t7400 on fc6 x86_64 You need to use a tickless kernel (CONFIG_NO_HZ iirc) and one with CONFIG_TIMER_STATS enable for the tool to work. I think recent rawhide kernels fit the bill... Jesse From jbarnes at virtuousgeek.org Sun May 13 23:24:44 2007 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Sun, 13 May 2007 16:24:44 -0700 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <200705131623.02391.jbarnes@virtuousgeek.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <200705131623.02391.jbarnes@virtuousgeek.org> Message-ID: <200705131624.44671.jbarnes@virtuousgeek.org> On Sunday, May 13, 2007, Jesse Barnes wrote: > > same here using a core 2 duo t7400 on fc6 x86_64 > > You need to use a tickless kernel (CONFIG_NO_HZ iirc) and one with > CONFIG_TIMER_STATS enable for the tool to work. I think recent rawhide > kernels fit the bill... Oh, and for x86_64 tickless support isn't quite ready yet. tglx posted a patch for it recently but I don't think it's upstream or in rawhide kernels yet, so you'll have to patch it in yourself... Jesse From wtogami at redhat.com Mon May 14 03:02:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 13 May 2007 23:02:02 -0400 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <4643954E.5060608@redhat.com> References: <4642729C.1010105@math.unl.edu> <46428E8B.5070103@redhat.com> <46429167.4010403@redhat.com> <46429249.3020102@redhat.com> <4643954E.5060608@redhat.com> Message-ID: <4647D12A.4010209@redhat.com> Margaret Lum wrote: > Warren Togami wrote: >> Right, unsigned in Fedora. Proprietary or 3rd party apps needing a >> signed JAR would need to provide it from a separate source. Can you >> confirm that it could be parallel installed without much trouble? > There won't be any need for this, as developers can sign at their own > discretion. >> >>>> >>>> Red Hat (the company) could (pending legal approval) choose to >>>> proceed with this as part of an internal product. But as the rules >>>> stand today, Fedora cannot ship this signed. >>> We will ship this UNsigned, in Fedora. Can approval be re-evaluated? >> >> Right, yes it can. > Please let me know what the next steps to working this through the > approval committee expediently. I want to make sure there aren't > details omitted that would hinder this package from being approved. > > Thanks! > There is no approval committee. Inclusion of the package only requires package review approval of ANYBODY. The reviewer could even be another member of the same team of the submitter of the package review. http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess Please familiarize yourself with this process document. Many dozens of java packages were included in Fedora in the past few months in this fashion, where a team within Red Hat had separate people act as package submitter and package reviewer. I don't remember all their names at the moment, though I believe rafaels@ and dbhole@ were among the RH participants involved with inclusion of those many java packages. If you have deadlines for business reasons to get packages into Fedora or EPEL, please don't wait for unaccountable external volunteers. Any team has the power to get a package in without the need for external participation or approval. Please let us know here on this list if you have further questions. Thanks, Warren Togami wtogami at redhat.com From bojan at rexursive.com Mon May 14 04:17:29 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 14 May 2007 04:17:29 +0000 (UTC) Subject: rawhide merge status References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: Bill Nottingham redhat.com> writes: > We hope to get more automated rawhide pushes going soon. So, all the stuff built with koji for development will show up when this happens, right? -- Bojan From rc040203 at freenet.de Mon May 14 03:55:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 05:55:07 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1179056562.17555.38.camel@vader.jdub.homelinux.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> Message-ID: <1179114907.4735.221.camel@mccallum.corsepiu.local> On Sun, 2007-05-13 at 06:42 -0500, Josh Boyer wrote: > On Sun, 2007-05-13 at 07:54 +0200, Ralf Corsepius wrote: > > On Fri, 2007-05-11 at 13:16 -0500, Josh Boyer wrote: > > > On Fri, 2007-05-11 at 18:43 +0200, Ralf Corsepius wrote: > > > > On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > > > > > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > > > > > Josh Boyer wrote: > > > > > > > The Fedora wiki pages link to a list of all approved licenses for > > > > > > > packages. You could systematically go through and print off each of > > > > > > > these. > > > > > > > > > > But it is more hard for individual user to print, translate and certify. > > > > > > > > > > I always forget about translating. I blame it on me being a stupid US > > > > > born citizen. > > > > While we're at it: Does Fedora have a rule on a license language? > > > > > > Not that I know of. > > > > > > > Or conversely: Which languages does Fedora accept as valid wrt. > > > > Licenses? > > > > > > I actually think this depends on the license itself. E.g. you cannot > > > use a translated copy of the GPL unless it has been certified by the > > > FSF, so by default only the original English version is valid. > > > > > > > As RH is located in the USA, I'd presume Fedora to be subject to "US > > > > courts" in case of "legal matters" and as such I'd presume US laws would > > > > prescribe "English" (and may-be Spanish - I don't know)? > > > > > > English when it comes to "legal matters" in the US. > > So English is mandated on "legal matters" in the USA, but it's legal to > > ship products from inside of the USA (such as Fedora) with licenses in > > "foreign languages/scripts"? > > > > > > Background: We have precedences of "Japanese-only licenses" in Fedora > > > > packages. > > > > > > I don't see a problem with those per-se. > > Well, this might not be much of a problem if things go to court, because > > you'll probably need an official translation to a "legally valid > > language" and because such court will not necessarily be located inside > > of the USA. > > > > But, how do you expect "arbitrary users" to be able to apply such > > licenses? You can't seriously expect any arbitrary user to speak any > > arbitrary language or read any arbitrary script. > > > > Consider the "Russian case" having popped up in recent days on > > fedora-devel. There a user claimed having to "show all licenses of SW > > being used in a production environment to the police". While he probably > > is able to translate "English", further languages would raise an > > additional level of complications. > > What exactly is your point? In a nutshell: Fedora ships packages with un-readable, non-verifiable licenses. Ralf From hughsient at gmail.com Mon May 14 06:49:27 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 May 2007 07:49:27 +0100 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <1179077925.5040.1.camel@rousalka.dyndns.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179077925.5040.1.camel@rousalka.dyndns.org> Message-ID: <1179125367.11395.0.camel@hughsie-laptop> On Sun, 2007-05-13 at 19:38 +0200, Nicolas Mailhot wrote: > > > Just wondering: does Fedora spin down the hard disk by default? It > > doesn't afaics and it's not easily user-configurable either afaik. > > Also is smartctl poking the disks with a frequency low enough to allow > spin down? I didn't think smartctl spun them up - I thought it just read a bit of embedded address space. I'll do some testing today. Richard. From bkoz at redhat.com Mon May 14 07:33:24 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Mon, 14 May 2007 09:33:24 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <20070511155636.GA27804@devserv.devel.redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> Message-ID: <464810C4.70309@redhat.com> Hey dudes. You'll find an A4-sized certificate, based on the Fedora EULA, and an A9-sized certificate of authenticity here: http://people.redhat.com/bkoz/fedora_certificates/ The plan would be to combine: http://people.redhat.com/bkoz/fedora_certificates/a4_certificate_3_blank.jpg with the correct, locale-specific EULA, like so for en_US: http://people.redhat.com/bkoz/fedora_certificates/a4_certificate_3_en_US.jpg Then, for the individual machines you should be able to make stickers with: http://people.redhat.com/bkoz/fedora_certificates/a9_certificate.jpg I suspect you'll find that this will go down better with pencil-pushers if you add some flash. Adding a metallic strip behind the A9 sticker will do nicely. The inkscape SVG files are in this directory, so if you need to edit this or alter the image use the inkscape file, not the jpg. In particular, you'll need to do the edits for the Russian locale yourself, as I didn't see the EULA for other locales. It would be pretty fun to print out a sheet of the A9 stickers and hand them out to fedora users at the next FUDcon or linux meeting. It would be even more fun to have an "authentication" party with libations, since the idea of an "authentic" linux install is pretty humorous to me. > In theory you could store each "license document" owner name you hand out > and invite them to enter it into a web form for verification and have it > report the organisation the license is for etc to make it look good. ... of course, doing this server-side and either having the option to print out the fancy-EULA from the anaconda install screen or adding it as an option/carrot to the smote agreement would be pretty slick. However, I leave this bit to others. best, -benjamin From oliver at linux-kernel.at Mon May 14 07:53:45 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 09:53:45 +0200 Subject: kernel package In-Reply-To: <1178884889.21820.46.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> Message-ID: <46481589.6010409@linux-kernel.at> On 05/11/2007 02:01 PM, David Woodhouse wrote: > Readable diff attached. And the answer (at least from me) is no -- I'm > not happy about applying it with all the ifdefs. We can apply the clean > bits though -- obviously it won't actually build, but then we can set > about actually _fixing_ exec-shield, etc. OK. If you enable alpha and apply the patches that are really needed, I can build it and tell you where and how it breaks then. > Can you explain each ifarch? Sure. > And show Patch701? Why at the end? --- drivers/net/Kconfig.no_fec_mpc52xx_for_alpha.patch 2007-05-03 14:18:50.000000000 +0200 +++ drivers/net/Kconfig 2007-05-03 14:18:55.000000000 +0200 @@ -1889,7 +1889,6 @@ controller on the Renesas H8/300 processor. source "drivers/net/fec_8xx/Kconfig" -source "drivers/net/fec_mpc52xx/Kconfig" source "drivers/net/fs_enet/Kconfig" endmenu linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via config as far as I can remember; So I had to patch it out at the end... > Once upon a time the folks at HP were threatening to send me SMP Alpha > boxen -- not sure if I could still pull that off... Anyone from HP here? Jay, do you have any good contacts? > Index: kernel-2.6.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3148 > diff -u -r1.3148 kernel-2.6.spec > --- kernel-2.6.spec 10 May 2007 23:26:42 -0000 1.3148 > +++ kernel-2.6.spec 11 May 2007 11:57:12 -0000 > @@ -167,6 +167,16 @@ > %define usesparse 0 > %endif > > +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > +%define with_smp 0 > +%define with_pae 0 > +%define with_xen 0 > +%define with_kdump 0 > +%define with_debug 0 > +%define usesparse 0 > +%define with_modsign 0 > +%endif > + This part is needed for sure. We will enable SMP after the normal up kernel compiles fine and I found someone with a smp-capable box who can do the testing. > # Per-arch tweaks > > %ifarch %{all_x86} > @@ -238,6 +248,13 @@ > %define xen_image vmlinux.gz > %endif > > +%ifarch alpha alphaev6 alphaev67 > +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-alpha*.config > +%define image_install_path boot > +%define make_target boot > +%define kernel_image vmlinux > +%endif > + Also quite clear I think. > # To temporarily exclude an architecture from being built, add it to > # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we > # don't build kernel-headers then the new build system will no longer let > @@ -290,13 +307,13 @@ > Group: System Environment/Kernel > License: GPLv2 > Version: %{rpmversion} > -Release: %{release} > +Release: %{release}axp Of course we do not need this. It's just because I intentionally wanted to build an new kernel for AlphaCore and we have the convention to add axp to the release, so people know, it's coming from Fedora, but is modified for AC. > %if 0%{?olpc} > ExclusiveArch: i386 i586 > %else > # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. > # SET %nobuildarches (ABOVE) INSTEAD > -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x > +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev6 alphaev67 > %endif > ExclusiveOS: Linux > Provides: kernel-drm = 4.3.0 > @@ -363,6 +380,9 @@ > #Source67: kernel-%{kversion}-sparc64.config > #Source68: kernel-%{kversion}-sparc64-smp.config > > +Source50: kernel-%{kversion}-alpha.config > +Source50: kernel-%{kversion}-alpha-smp.config I don't have a smp config at the moment. So we need to put this out, else up will no build clean. > Source80: config-rhel-generic > Source81: config-rhel-x86-generic > Source82: config-olpc-generic > @@ -452,6 +472,9 @@ > > # 600 - 699 sparc(64) > > +# 700 - 799 alpha > +Patch701: linux-2.6-no_fec_for_alpha.patch > + See above notes. > # > # Patches 800 through 899 are reserved for bugfixes to the core system > # and patches related to how RPMs are build > @@ -1001,7 +1024,9 @@ > # Patches 10 through 100 are meant for core subsystem upgrades > > # Roland's utrace ptrace replacement. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch10 -p1 > +%endif > %patch11 -p1 Compile errors. > # Power management fixes > @@ -1106,7 +1131,9 @@ > %patch800 -p1 > > # Exec shield > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch810 -p1 > +%endif Even more compile errors. :-) > # > # GPG signed kernel modules > @@ -1181,7 +1208,9 @@ > %patch1018 -p1 > %patch1019 -p1 > %patch1020 -p1 > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 > %patch1021 -p1 > +%endif Don't remember why. Must have been a compile error as well. > %patch1022 -p1 > %if %{includexen} > %patch1023 -p1 > @@ -1198,7 +1227,9 @@ > # > # /dev/crash driver for the crashdump analysis tool > # > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1060 -p1 > +%endif Compile error. > %if %{includexen} > %patch1061 -p1 > %endif > @@ -1258,7 +1289,9 @@ > # DVB spinlock bug > %patch1700 -p1 > # setuid /proc/self/maps fix. > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch1720 -p1 > +%endif Compile error. > # Add a safety net to softlockup so that it doesn't prevent installs. > %patch1740 -p1 > # Speed up spinlock debug. > @@ -1346,7 +1379,9 @@ > # > > # Pull in the new firewire stack > +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > %patch5000 -p1 > +%endif Compile error. > # > # final stuff > @@ -1360,6 +1395,9 @@ > %patch10002 -p1 > %patch10003 -p1 > > +# alpha related, but must be done at the end... > +%patch701 -p0 > + > # END OF PATCH APPLICATIONS See above note. There are not *many* ifnarchs at the moment, but it makes the kernel compile for alpha. Last run was successful, but packaging was a problem because smp config is missing... Best, Oliver From oliver at linux-kernel.at Mon May 14 07:57:22 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 09:57:22 +0200 Subject: kernel package In-Reply-To: <1178885021.29429.6.camel@zod.rchland.ibm.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <1178885021.29429.6.camel@zod.rchland.ibm.com> Message-ID: <46481662.6090705@linux-kernel.at> On 05/11/2007 02:03 PM, Josh Boyer wrote: [ ... ] >> +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 > > instead of listing all the alpha arches everywhere, you should define a > macro like %{all_alpha} Sure. Go with it. [ ... ] >> +# 700 - 799 alpha >> +Patch701: linux-2.6-no_fec_for_alpha.patch > > Where's this? See my other mail. >> # >> # Patches 800 through 899 are reserved for bugfixes to the core system >> # and patches related to how RPMs are build >> @@ -1001,7 +1024,9 @@ >> # Patches 10 through 100 are meant for core subsystem upgrades >> >> # Roland's utrace ptrace replacement. >> +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev67 >> %patch10 -p1 >> +%endif > > Is utrace really broken on alpha? As already stated. I can build it without the ifnarch and send you the error - will take a while of course. My DS10 is quite fast, but not *very* fast... [ ... ] See also the notes from my previous mail. -of From nicolas.mailhot at laposte.net Mon May 14 08:15:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 10:15:13 +0200 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1179130513.8667.0.camel@rousalka.dyndns.org> Le lundi 14 mai 2007 ? 04:17 +0000, Bojan Smojver a ?crit : > Bill Nottingham redhat.com> writes: > > > We hope to get more automated rawhide pushes going soon. > > So, all the stuff built with koji for development will show up when this > happens, right? Is it possible to queue stuff for post-F7 fedora-devel or F7 updates today ? -- 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 oliver at linux-kernel.at Mon May 14 08:16:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 10:16:17 +0200 Subject: kernel package In-Reply-To: <1178885585.21820.51.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178885585.21820.51.camel@shinybook.infradead.org> Message-ID: <46481AD1.1070300@linux-kernel.at> On 05/11/2007 02:13 PM, David Woodhouse wrote: > You seem to build for a bunch of different architectures, but don't have > separate config files for most of them. Good point; Good idea! > I'd suggest building for ev4|up, ev56+|up and ev56+|smp. No ev4, we disable ev in glibc for example. So no need to build a kernel for it. We shouldn't forget ev6 and ev67, there should be a lot of them out there. I don't know about ev7, ev7z and the ev68. I think one or the other es45 (ev68) should be also out there... Also a good question. For x86, we don't build extra SMP capable kernels anymore, true? Maybe we should do this here as well!? SMP wasn't also working stable on alpha. But if it does now, maybe we should enable it by default... > Are there SMP boxen without BWX? Hm. Maybe someone with more knowledge about h/w can answer this; EV5 afaik doesn't have bwx. And there's the AS1200; SMP capable and with a 21164 processor, maybe ev5, maybe already ev56 (ev5 was only <= 366 MHz and AS1200 has >= 400 Mhz.). If all this is true :-) I'm sure there's someone who can answer this better... -of From oliver at linux-kernel.at Mon May 14 08:19:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 10:19:24 +0200 Subject: kernel package In-Reply-To: <46446C76.1010105@redhat.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <1178885021.29429.6.camel@zod.rchland.ibm.com> <46446C76.1010105@redhat.com> Message-ID: <46481B8C.4080206@linux-kernel.at> On 05/11/2007 03:15 PM, Jarod Wilson wrote: > Josh Boyer wrote: >> On Fri, 2007-05-11 at 13:01 +0100, David Woodhouse wrote: >>> Readable diff attached. And the answer (at least from me) is no -- I'm >>> not happy about applying it with all the ifdefs. We can apply the clean >>> bits though -- obviously it won't actually build, but then we can set >>> about actually _fixing_ exec-shield, etc. > > +1 for not happy about all the ifdef alpha's For me it was the fastest and easiest method to actually *build* a newer kernel from this spec. I would be very happy if we can fix it - sure! >>> +%ifarch alpha alphaev5 alphaev56 alphaev6 alphaev67 >> >> instead of listing all the alpha arches everywhere, you should define a >> macro like %{all_alpha} > > +1 Sure. Yes. Not much work. >>> # To temporarily exclude an architecture from being built, add it to >>> # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we >>> # don't build kernel-headers then the new build system will no >>> longer let >>> @@ -290,13 +307,13 @@ >>> Group: System Environment/Kernel >>> License: GPLv2 >>> Version: %{rpmversion} >>> -Release: %{release} >>> +Release: %{release}axp >> >> Shouldn't need to muck with Release > > Indeed. There's a %buildid define further up in the spec if you really > want to alter the release tag for your own build, but we're certainly > not going to merge this part of the patch. :) Yes guys, I know. Sorry, shouldn't have added this hunk. :-) >>> %if 0%{?olpc} >>> ExclusiveArch: i386 i586 >>> %else >>> # DO NOT CHANGE THIS LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. >>> # SET %nobuildarches (ABOVE) INSTEAD >>> -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 >>> s390 s390x >>> +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 >>> s390 s390x alpha alphaev6 alphaev67 >>> %endif >>> ExclusiveOS: Linux >>> Provides: kernel-drm = 4.3.0 >>> @@ -363,6 +380,9 @@ >>> #Source67: kernel-%{kversion}-sparc64.config >>> #Source68: kernel-%{kversion}-sparc64-smp.config >>> >>> +Source50: kernel-%{kversion}-alpha.config >>> +Source50: kernel-%{kversion}-alpha-smp.config >> >> Do you need an alpha-smp.config since you turned smp builds off? > > Not to mention that they should have different SourceX numbers if you do > intend to include both. That's true. Typo :-) -of From oliver at linux-kernel.at Mon May 14 08:23:13 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 10:23:13 +0200 Subject: kernel package In-Reply-To: <20070511154227.GA8976@redhat.com> References: <46442E72.8060402@linux-kernel.at> <1178884157.21820.37.camel@shinybook.infradead.org> <1178895214.7756.4.camel@localhost.localdomain> <1178896401.29429.59.camel@zod.rchland.ibm.com> <20070511154227.GA8976@redhat.com> Message-ID: <46481C71.5040604@linux-kernel.at> On 05/11/2007 05:42 PM, Dave Jones wrote: > On Fri, May 11, 2007 at 10:13:21AM -0500, Josh Boyer wrote: > > On Fri, 2007-05-11 at 09:53 -0500, Tom "spot" Callaway wrote: > > > On Fri, 2007-05-11 at 12:49 +0100, David Woodhouse wrote: > > > > On Fri, 2007-05-11 at 10:50 +0200, Oliver Falk wrote: > > > > > A question; Before I open BZ... Is the kernel team (I see Dave Jones is > > > > > doin' much; that's why CC:) willing to help AlphaCore and add patches to > > > > > kernel spec? > > > > > > > > > > No, it's nothing for upstream. Just fixes for the spec. Some > > > > > if(n)arch's, sections for alpha, a config, ... Nothing that should break > > > > > primary archs... > > > > > > > > We don't like ifarches. Why? > > > > > > The utrace patch is the biggest concern here, really. Not that it's bad > > > code, but its a significant divergence from upstream, and it doesn't > > > work on sparc32 (and presumably, alpha). Aurora is %ifarch > > > conditionalizing that patch (and one later patch that has to be modified > > > slightly for the old ptrace behavior) in our kernels as well. > > > > Does it apply? Seems there's a config option for it... you could just > > leave that disabled in your .configs. > > Problem is (AIUI) that doing that would remove ptrace functionality completely. > With the patch applied, ptrace is implemented as a 'personality' of utrace. So. If it doesn't work for sparc32 and we cannot simply disable it via .config, we should stick with ifnarch-ing it for now /me thinks. Maybe some good kernel-hacker can have a look into it. Working out a patch, so we can disable utrace by .config and automatically enabling ptrace would be the best way!? -of From jonathan.underwood at gmail.com Mon May 14 09:37:34 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 14 May 2007 10:37:34 +0100 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <1179080582.2511.9.camel@hughsie-laptop> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> Message-ID: <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> On 13/05/07, Richard Hughes wrote: > Unless we keep the disk from spinning up, my patch isn't actually that > effective. I am however using a similar patch to HAL on my media center > embedded PC, where I'm only running a pretty stripped system, and spin > the disks down mostly for noise, not power saving. > > My view still is that this is a valid patch to HAL, and I would be quite > happy to do the action automatically in g-p-m. I'm not sure we need UI - > we can probably just profile the mean time that the disk is idle and > work out if it is worth powering down. [snip] > I think it is - we are trimming easy stuff (like cpufreq and brightness) > and I think we need to start looking at the drive spindown with a new > vigour. There's another factor here though, as I understand it hard drive lifetime is largely determined by the spin up/spin down frequency. So while it may save a bit of power spinning down more often, this might significantly shorten drive lifetimes. I'd definately want to have an option to disable that, if my understanding is correct. [However, my understanding is often incorrect] Jonathan. From buildsys at fedoraproject.org Mon May 14 10:22:04 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 14 May 2007 10:22:04 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2007-05-14 Message-ID: <20070514102204.10116.36651@extras64.linux.duke.edu> Summary of broken packages (by owner): matthias AT rpmforge.net python-Coherence - 0.2.1-3.fc5.noarch python-Coherence - 0.2.1-3.fc5.noarch python-Coherence - 0.2.1-3.fc5.noarch ====================================================================== Broken packages in fedora-extras-5-i386: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj ====================================================================== Broken packages in fedora-extras-5-ppc: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj ====================================================================== Broken packages in fedora-extras-5-x86_64: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj From hughsient at gmail.com Mon May 14 10:53:51 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 May 2007 11:53:51 +0100 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> Message-ID: <1179140031.3167.4.camel@hughsie-laptop> On Mon, 2007-05-14 at 10:37 +0100, Jonathan Underwood wrote: > > There's another factor here though, as I understand it hard drive > lifetime is largely determined by the spin up/spin down frequency. So > while it may save a bit of power spinning down more often, this might > significantly shorten drive lifetimes. I'd definately want to have an > option to disable that, if my understanding is correct. Correct, hence why we only want to spin down the drive after a few hours, rather than minutes or seconds. Richard. From davehoz at gmail.com Mon May 14 11:25:31 2007 From: davehoz at gmail.com (David Hunter) Date: Mon, 14 May 2007 21:25:31 +1000 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. Message-ID: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> How do I easily establish what causes pidgin to crash on my system? -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfy at nobugconsulting.ro Mon May 14 11:33:48 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 14 May 2007 14:33:48 +0300 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> Message-ID: <4648491C.5010805@nobugconsulting.ro> David Hunter wrote: > How do I easily establish what causes pidgin to crash on my system? on my system it crashes randomly when connecting to YM From pbrobinson at gmail.com Mon May 14 11:34:35 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 14 May 2007 12:34:35 +0100 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> Message-ID: <5256d0b0705140434v3618cd37h2ede9fa1339fc1b@mail.gmail.com> > How do I easily establish what causes pidgin to crash on my system? Its doing so on mine too. I noticed we're still running the beta7, I think there were a couple of issues fixed in the final release. I also found the evolution plugin was making it unstable so I disabled that but it seems that when a newer build came out that the plugin was automatically re-enabled. Peter From fedora at leemhuis.info Mon May 14 11:38:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 May 2007 13:38:55 +0200 Subject: hard disk power down In-Reply-To: <1179140031.3167.4.camel@hughsie-laptop> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> <1179140031.3167.4.camel@hughsie-laptop> Message-ID: <46484A4F.9050300@leemhuis.info> On 14.05.2007 12:53, Richard Hughes wrote: > On Mon, 2007-05-14 at 10:37 +0100, Jonathan Underwood wrote: >> There's another factor here though, as I understand it hard drive >> lifetime is largely determined by the spin up/spin down frequency. So >> while it may save a bit of power spinning down more often, this might >> significantly shorten drive lifetimes. I'd definately want to have an >> option to disable that, if my understanding is correct. > Correct, hence why we only want to spin down the drive after a few > hours, rather than minutes or seconds. Laptop drives are designed for lots of power spinning cycles (lots more than server drivers for example). So spinning hard disks in laptops down after 15 or 20 minutes should be totally fine afaics. Even after a shorter timeframe (5 minutes) might be fine. But doing the same on the server might destroy you hard disk quickly. CU thl From buildsys at fedoraproject.org Mon May 14 11:41:13 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 14 May 2007 07:41:13 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-14 Message-ID: <20070514114113.1C973152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 13 NEW autodir-0.99.9-2.fc6 : Creates user directories on demand fltk-1.1.8-0.3.r5750.fc6 gallery2-2.2-0.4.svn20070506.fc6 NEW gsm-1.0.12-3.fc6 : Shared libraries for GSM speech compressor mbuffer-20070502-1.fc6 pan-0.129-1.fc6 perl-CGI-Ex-2.12-1.fc6 perl-Class-C3-XS-0.04-1.fc6 perl-File-Copy-Recursive-0.33-1.fc6 perl-JSON-1.14-1.fc6 perl-POE-Component-Client-Keepalive-0.1000-1.fc6 tcllib-1.9-2.fc6 NEW vegastrike-data-0.4.3-2 : Data files for Vega Strike Packages built and released for Fedora Extras 5: 8 NEW autodir-0.99.9-2.fc5 : Creates user directories on demand gallery2-2.2-0.4.svn20070506.fc5 NEW gsm-1.0.12-3.fc5 : Shared libraries for GSM speech compressor mbuffer-20070502-1.fc5 perl-CGI-Ex-2.12-1.fc5 perl-Class-C3-XS-0.04-1.fc5 perl-JSON-1.14-1.fc5 perl-POE-Component-Client-Keepalive-0.1000-1.fc5 Changes in Fedora Extras 6: autodir-0.99.9-2.fc6 -------------------- * Mon May 07 2007 Matthias Saou 0.99.9-2 - Add missing scriplets requirements. - Update sf.net source URL. - Switch away from %makeinstall. * Wed Apr 18 2007 Matthias Saou 0.99.9-1 - Update to 0.99.9. fltk-1.1.8-0.3.r5750.fc6 ------------------------ * Sun Apr 29 2007 Rex Dieter 1.1.8-0.3.r5750 - *really* fix --rpath issue, using non-empty patch this time (#238284) * Sun Apr 29 2007 Rex Dieter 1.1.8-0.2.r5750 - nuke --rpath (#238284) * Thu Apr 05 2007 Rex Dieter 1.1.8-0.1.r5750 - fltk-1.1.x-r5750 snapshot (1.1.8 pre-release) - --enable-xinerama - patch for undefined symbols in libfltk_gl * Wed Apr 04 2007 Thomas Fitzsimmons - 1.1.7-9.r5555 - Always apply fltk-config patch (#199656) - Update fltk-1.1.7-config.patch * Wed Dec 13 2006 Rex Dieter 1.1.7-8.r5555 - more 64bit hackage to workaround broken Makefile logic (#219348) * Wed Dec 13 2006 Rex Dieter 1.1.7-7.r5555 - fltk-1.1.x-r5555 snapshot, for 64bit issues (#219348) - restore static libs (they're tightly coupled with fltk-config) - cleanup %description's * Mon Dec 11 2006 Rex Dieter 1.1.7-6 - move tests to %check section * Mon Dec 11 2006 Rex Dieter 1.1.7-5 - use included icon/.desktop files - fix up fltk-config (#199656) * Mon Dec 11 2006 Rex Dieter 1.1.7-3 - follow icon spec - omit static libs gallery2-2.2-0.4.svn20070506.fc6 -------------------------------- * Sun May 13 2007 John Benringer - 2.2-0.4.svn20070506 - Correct shell syntax in post scriptlet gsm-1.0.12-3.fc6 ---------------- * Sun May 13 2007 Dominik Mierzejewski 1.0.12-3 - fix parallel make * Fri May 11 2007 Dominik Mierzejewski 1.0.12-2 - fix some warnings - fix 64bit testsuite issue as described at gsm homepage - add compatibility header symlink - split off binaries into a separate package * Sun Apr 15 2007 Michael Schwendt 1.0.12-1 - Update to Release 1.0 Patchlevel 12. - Build with -fPIC not just for non-ix86. - Add check section to ensure proper library version. - Remove static library. mbuffer-20070502-1.fc6 ---------------------- * Sat May 12 2007 Alexander Dalloz - 20070502-1 - Updated to latest version. pan-0.129-1.fc6 --------------- * Sat May 12 2007 Alexander Dalloz - 1:0.129-1 - Update to 0.129 * Sun May 06 2007 Alexander Dalloz - 1:0.128-1 - Update to 0.128 perl-CGI-Ex-2.12-1.fc6 ---------------------- * Sun May 13 2007 Chris Weyl 2.12-1 - update to 2.12 * Wed May 09 2007 Chris Weyl 2.11-1 - update to 2.11 - add split br's perl-Class-C3-XS-0.04-1.fc6 --------------------------- * Sun May 13 2007 Chris Weyl 0.04-1 - update to 0.04 perl-File-Copy-Recursive-0.33-1.fc6 ----------------------------------- * Mon May 14 2007 Ralf Cors?pius - 0.33-1 - Upstream update. * Mon Mar 12 2007 Ralf Cors?pius - 0.31-2 - BR: perl(ExtUtils::MakeMaker). perl-JSON-1.14-1.fc6 -------------------- * Sun May 13 2007 Chris Weyl 1.14-1 - update to 1.14 perl-POE-Component-Client-Keepalive-0.1000-1.fc6 ------------------------------------------------ * Sun May 13 2007 Chris Weyl 0.1000-1 - update to 0.1000 - add t/ to %doc - perl splittage BR tweaks tcllib-1.9-2.fc6 ---------------- * Fri May 11 2007 Wart - 1.9-2 - Include command line applications vegastrike-data-0.4.3-2 ----------------------- * Mon Apr 23 2007 Hans de Goede 0.4.3-2 - Remove included copies of default python builtin's like "string" Changes in Fedora Extras 5: autodir-0.99.9-2.fc5 -------------------- * Mon May 07 2007 Matthias Saou 0.99.9-2 - Add missing scriplets requirements. - Update sf.net source URL. - Switch away from %makeinstall. * Wed Apr 18 2007 Matthias Saou 0.99.9-1 - Update to 0.99.9. gallery2-2.2-0.4.svn20070506.fc5 -------------------------------- * Sun May 13 2007 John Benringer - 2.2-0.4.svn20070506 - Correct shell syntax in post scriptlet gsm-1.0.12-3.fc5 ---------------- * Sun May 13 2007 Dominik Mierzejewski 1.0.12-3 - fix parallel make * Fri May 11 2007 Dominik Mierzejewski 1.0.12-2 - fix some warnings - fix 64bit testsuite issue as described at gsm homepage - add compatibility header symlink - split off binaries into a separate package * Sun Apr 15 2007 Michael Schwendt 1.0.12-1 - Update to Release 1.0 Patchlevel 12. - Build with -fPIC not just for non-ix86. - Add check section to ensure proper library version. - Remove static library. mbuffer-20070502-1.fc5 ---------------------- * Sat May 12 2007 Alexander Dalloz - 20070502-1 - Updated to latest version. * Sat Apr 14 2007 Alexander Dalloz - 20070401-1 - Updated to latest version. perl-CGI-Ex-2.12-1.fc5 ---------------------- * Sun May 13 2007 Chris Weyl 2.12-1 - update to 2.12 perl-Class-C3-XS-0.04-1.fc5 --------------------------- * Sun May 13 2007 Chris Weyl 0.04-1 - update to 0.04 perl-JSON-1.14-1.fc5 -------------------- * Sun May 13 2007 Chris Weyl 1.14-1 - update to 1.14 perl-POE-Component-Client-Keepalive-0.1000-1.fc5 ------------------------------------------------ * Sun May 13 2007 Chris Weyl 0.1000-1 - update to 0.1000 - add t/ to %doc - perl splittage BR tweaks For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jwboyer at jdub.homelinux.org Mon May 14 11:41:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 06:41:59 -0500 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1179142919.19267.2.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 04:17 +0000, Bojan Smojver wrote: > Bill Nottingham redhat.com> writes: > > > We hope to get more automated rawhide pushes going soon. > > So, all the stuff built with koji for development will show up when this > happens, right? No, only if you've submitted a tag request for f7-final to rel-eng. josh From jwboyer at jdub.homelinux.org Mon May 14 11:42:47 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 06:42:47 -0500 Subject: rawhide merge status In-Reply-To: <1179130513.8667.0.camel@rousalka.dyndns.org> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179130513.8667.0.camel@rousalka.dyndns.org> Message-ID: <1179142967.19267.4.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 10:15 +0200, Nicolas Mailhot wrote: > Le lundi 14 mai 2007 ? 04:17 +0000, Bojan Smojver a ?crit : > > Bill Nottingham redhat.com> writes: > > > > > We hope to get more automated rawhide pushes going soon. > > > > So, all the stuff built with koji for development will show up when this > > happens, right? > > Is it possible to queue stuff for post-F7 fedora-devel or F7 updates > today ? Not at the moment. You could build stuff today and it will get tagged with dist-fc7 and not have it tagged for f7-final. However that won't make it show up in updates. josh From jwboyer at jdub.homelinux.org Mon May 14 11:43:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 06:43:34 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1179114907.4735.221.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> Message-ID: <1179143015.19267.6.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > On Sun, 2007-05-13 at 06:42 -0500, Josh Boyer wrote: > > On Sun, 2007-05-13 at 07:54 +0200, Ralf Corsepius wrote: > > > On Fri, 2007-05-11 at 13:16 -0500, Josh Boyer wrote: > > > > On Fri, 2007-05-11 at 18:43 +0200, Ralf Corsepius wrote: > > > > > On Fri, 2007-05-11 at 10:08 -0500, Josh Boyer wrote: > > > > > > On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > > > > > > Josh Boyer wrote: > > > > > > > > The Fedora wiki pages link to a list of all approved licenses for > > > > > > > > packages. You could systematically go through and print off each of > > > > > > > > these. > > > > > > > > > > > > But it is more hard for individual user to print, translate and certify. > > > > > > > > > > > > I always forget about translating. I blame it on me being a stupid US > > > > > > born citizen. > > > > > While we're at it: Does Fedora have a rule on a license language? > > > > > > > > Not that I know of. > > > > > > > > > Or conversely: Which languages does Fedora accept as valid wrt. > > > > > Licenses? > > > > > > > > I actually think this depends on the license itself. E.g. you cannot > > > > use a translated copy of the GPL unless it has been certified by the > > > > FSF, so by default only the original English version is valid. > > > > > > > > > As RH is located in the USA, I'd presume Fedora to be subject to "US > > > > > courts" in case of "legal matters" and as such I'd presume US laws would > > > > > prescribe "English" (and may-be Spanish - I don't know)? > > > > > > > > English when it comes to "legal matters" in the US. > > > So English is mandated on "legal matters" in the USA, but it's legal to > > > ship products from inside of the USA (such as Fedora) with licenses in > > > "foreign languages/scripts"? > > > > > > > > Background: We have precedences of "Japanese-only licenses" in Fedora > > > > > packages. > > > > > > > > I don't see a problem with those per-se. > > > Well, this might not be much of a problem if things go to court, because > > > you'll probably need an official translation to a "legally valid > > > language" and because such court will not necessarily be located inside > > > of the USA. > > > > > > But, how do you expect "arbitrary users" to be able to apply such > > > licenses? You can't seriously expect any arbitrary user to speak any > > > arbitrary language or read any arbitrary script. > > > > > > Consider the "Russian case" having popped up in recent days on > > > fedora-devel. There a user claimed having to "show all licenses of SW > > > being used in a production environment to the police". While he probably > > > is able to translate "English", further languages would raise an > > > additional level of complications. > > > > What exactly is your point? > In a nutshell: > > Fedora ships packages with un-readable, non-verifiable licenses. Hyperbole josh From andy at warmcat.com Mon May 14 11:56:49 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 14 May 2007 12:56:49 +0100 Subject: hard disk power down In-Reply-To: <46484A4F.9050300@leemhuis.info> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> <1179140031.3167.4.camel@hughsie-laptop> <46484A4F.9050300@leemhuis.info> Message-ID: <46484E81.10107@warmcat.com> Thorsten Leemhuis wrote: > On 14.05.2007 12:53, Richard Hughes wrote: >> On Mon, 2007-05-14 at 10:37 +0100, Jonathan Underwood wrote: >>> There's another factor here though, as I understand it hard drive >>> lifetime is largely determined by the spin up/spin down frequency. So >>> while it may save a bit of power spinning down more often, this might >>> significantly shorten drive lifetimes. I'd definately want to have an >>> option to disable that, if my understanding is correct. >> Correct, hence why we only want to spin down the drive after a few >> hours, rather than minutes or seconds. > > Laptop drives are designed for lots of power spinning cycles (lots more > than server drivers for example). So spinning hard disks in laptops down > after 15 or 20 minutes should be totally fine afaics. Even after a > shorter timeframe (5 minutes) might be fine. But doing the same on the > server might destroy you hard disk quickly. You can get some numbers on it: random 3.5" desktop drive specifies a lifetime of 50,000 "start/stops" http://www.hitachigst.com/tech/techlib.nsf/techdocs/C5C895A725AC713E862571D5004E4EDB/$file/Deskstar_E7K500_DS.pdf Random 2.5" drive specifies a lifetime of 300,000 "load/unload cycles": http://www.hitachigst.com/tech/techlib.nsf/techdocs/D9DA661AA5D3E44B86256CEC0075C7B2/$file/Travelstar5K80-Datasheet.pdf The 3.5 drive quotes a "low duty cycle" MTBF of 114 years ;-) but I don't think the flash holding the firmware will last that long. If in reality you expected the drive to last 5 years and it was in use half that time, spreading the budget of 300,000 starts and stops over that period looks like you can afford to do something like 6 an hour... vs one an hour for the 3.5" drive... -Andy From snecklifter at gmail.com Mon May 14 11:58:25 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 12:58:25 +0100 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> Message-ID: <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> On 14/05/07, David Hunter wrote: > > How do I easily establish what causes pidgin to crash on my system? > > -- > David Hunter > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Maybe gdb will help here. As in: http://developer.pidgin.im/wiki/GetABacktrace Sometimes just launching from a shell will output errors when it crashes. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Mon May 14 12:18:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 14 May 2007 13:18:19 +0100 Subject: hard disk power down In-Reply-To: <46484E81.10107@warmcat.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> <1179140031.3167.4.camel@hughsie-laptop> <46484A4F.9050300@leemhuis.info> <46484E81.10107@warmcat.com> Message-ID: <1179145099.28363.0.camel@hughsie-laptop> On Mon, 2007-05-14 at 12:56 +0100, Andy Green wrote: > > If in reality you expected the drive to last 5 years and it was in use > half that time, spreading the budget of 300,000 starts and stops over > that period looks like you can afford to do something like 6 an > hour... > vs one an hour for the 3.5" drive... Cheers for doing that - that's useful to know. David, this makes some of the discussion with DannyK moot - what do you think about hdd powerdown from the desktop? Richard. From pbrobinson at gmail.com Mon May 14 12:23:35 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 14 May 2007 13:23:35 +0100 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> Message-ID: <5256d0b0705140523m29070c51ka9c831204fabeb22@mail.gmail.com> Crash data attached. In my case it looks like its the evo exchange connector. Also amusing is the bottom bit about the spamassassin plugin... I have it disabled in the plugins bit, and the check spam is unselected so it shouldn't load anyway. Peter On 5/14/07, Chris Brown wrote: > > > On 14/05/07, David Hunter wrote: > > How do I easily establish what causes pidgin to crash on my system? > > > > -- > > David Hunter > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Maybe gdb will help here. As in: > > http://developer.pidgin.im/wiki/GetABacktrace > > Sometimes just launching from a shell will output errors when it crashes. > > Regards > Chris > > -- > http://www.chruz.com > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- System: Linux 2.6.21-1.3149.fc7 #1 SMP Fri May 11 12:12:11 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: Fedora Memory status: size: 71827456 vsize: 71827456 resident: 13684736 share: 7155712 rss: 13684736 rss_rlim: 4294967295 CPU usage: start_time: 1179139767 rtime: 235 utime: 206 stime: 29 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/libexec/evolution-exchange-storage' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208719120 (LWP 7545)] [New Thread -1221579888 (LWP 10295)] [New Thread -1210819696 (LWP 7547)] 0x00fe7402 in __kernel_vsyscall () #0 0x00fe7402 in __kernel_vsyscall () #1 0x003f0b63 in poll () from /lib/libc.so.6 #2 0x004f5633 in g_main_context_iterate (context=0x9a757c0, block=1, dispatch=1, self=0x9a544b8) at gmain.c:2979 #3 0x004f59a9 in IA__g_main_loop_run (loop=0x9a84ce8) at gmain.c:2881 #4 0x058e57e3 in bonobo_main () at bonobo-main.c:311 #5 0x0805ff50 in main (argc=3, argv=) at main.c:238 Thread 3 (Thread -1210819696 (LWP 7547)): #0 0x00fe7402 in __kernel_vsyscall () No symbol table info available. #1 0x003f0b63 in poll () from /lib/libc.so.6 No symbol table info available. #2 0x004f5633 in g_main_context_iterate (context=0x9a85018, block=1, dispatch=1, self=0x9a84ea8) at gmain.c:2979 got_ownership = max_priority = 2147483647 timeout = -1 some_ready = nfds = 11 allocated_nfds = fds = (GPollFD *) 0x9ac1098 __PRETTY_FUNCTION__ = "g_main_context_iterate" #3 0x004f59a9 in IA__g_main_loop_run (loop=0x9a85098) at gmain.c:2881 got_ownership = 7082480 self = (GThread *) 0x9a84ea8 __PRETTY_FUNCTION__ = "IA__g_main_loop_run" #4 0x0555a510 in link_io_thread_fn (data=0x0) at linc.c:399 No locals. #5 0x0051049f in g_thread_create_proxy (data=0x9a84ea8) at gthread.c:591 __PRETTY_FUNCTION__ = "g_thread_create_proxy" #6 0x006bf2db in start_thread () from /lib/libpthread.so.0 No symbol table info available. #7 0x003fa83e in clone () from /lib/libc.so.6 No symbol table info available. Thread 2 (Thread -1221579888 (LWP 10295)): #0 0x00fe7402 in __kernel_vsyscall () No symbol table info available. #1 0x006c6beb in waitpid () from /lib/libpthread.so.0 No symbol table info available. #2 0x05998a46 in ?? () from /usr/lib/libgnomeui-2.so.0 No symbol table info available. #3 No symbol table info available. #4 e2k_restriction_unref (rn=0x0) at e2k-restriction.c:495 i = #5 0x0806a414 in e_book_backend_exchange_get_contact_list ( backend=0x9a86b48, book=0x9aad4c0, opid=2, query=0x9e353d9 "(is \"im_msn\" \"blahblah at gmail.com\")", contacts=0xb7302018) at e-book-backend-exchange.c:1844 be = (EBookBackendExchange *) 0x9a86b48 bepriv = rn = (E2kRestriction *) 0x0 iter = (E2kResultIter *) 0x0 result = status = 0 vcard = vcard_list = offline_contacts = #6 0x0635651c in e_book_backend_sync_get_contact_list (backend=0x9a86b48, book=0x9aad4c0, opid=2, query=0x9e353d9 "(is \"im_msn\" \"blahblah at gmail.com\")", contacts=0xb7302018) at e-book-backend-sync.c:206 __PRETTY_FUNCTION__ = "e_book_backend_sync_get_contact_list" #7 0x063565b9 in _e_book_backend_get_contact_list (backend=0x9a86b48, book=0x9aad4c0, opid=2, query=0x9e353d9 "(is \"im_msn\" \"blahblah at gmail.com\")") at e-book-backend-sync.c:443 status = cards = (GList *) 0x0 #8 0x06358007 in e_book_backend_get_contact_list (backend=0x9a86b48, book=0x9aad4c0, opid=2, query=0x9e353d9 "(is \"im_msn\" \"blahblah at gmail.com\")") at e-book-backend.c:284 __PRETTY_FUNCTION__ = "e_book_backend_get_contact_list" #9 0x0635cc63 in impl_GNOME_Evolution_Addressbook_Book_getContactList ( servant=0x9aad4d4, opid=2, query=0x9e353d9 "(is \"im_msn\" \"blahblah at gmail.com\")", ev=0xb73022a8) at e-data-book.c:79 No locals. #10 0x0634dcda in _ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_getContactList (_o_servant=0x9aad4d4, _o_retval=0x0, _o_args=0xb7302160, _o_ctx=0xb73021d8, _o_ev=0xb73022a8, _impl_getContactList=0x635cc00 ) at Evolution-DataServer-Addressbook-common.c:84 No locals. #11 0x0554e7f7 in ORBit_POAObject_invoke (pobj=0x9e81e80, ret=0x0, args=0xb7302160, ctx=0xb73021d8, data=0xb7302258, ev=0xb73022a8) at poa.c:1142 No locals. #12 0x05554965 in ORBit_OAObject_invoke (adaptor_obj=0x9e81e80, ret=0x0, args=0xb7302160, ctx=0xb73021d8, data=0xb7302258, ev=0xb73022a8) at orbit-adaptor.c:338 No locals. #13 0x05541d0c in ORBit_small_invoke_adaptor (adaptor_obj=0x9e81e80, recv_buffer=0xb6800bc8, m_data=0x63655c0, data=0xb7302258, ev=0xb73022a8) at orbit-small.c:844 a = ctx = {parent = {interface = 0xb7302208, refs = 89392076}, mappings = 0x6c22fc, children = 0x40000001, the_name = 0x634ef7a "\201??n]\001", parent_ctx = 0x1} args = (gpointer *) 0xb7302160 scratch = (gpointer *) 0xb7302140 pretval = (gpointer) 0x0 retval = (gpointer) 0x0 send_buffer = orb = (CORBA_ORB) 0x9a769a0 tc = (CORBA_TypeCode) 0xb7302164 i = #14 0x05552526 in ORBit_POAObject_handle_request (pobj=0x9e81e80, opname=0xb6800c74 "getContactList", ret=0x0, args=0x0, ctx=0x0, recv_buffer=0xb6800bc8, ev=0xb73022a8) at poa.c:1351 invoke_data = { small_skel = 0x634dcb0 <_ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_getContactList>, imp = 0x635cc00} poa = (PortableServer_POA) 0x9a57500 cookie = (PortableServer_ServantLocator_Cookie) 0x0 oid = (PortableServer_ObjectId *) 0x9eab7ac m_data = (ORBit_IMethod *) 0x63655c0 small_skel = ( ORBitSmallSkeleton) 0x634dcb0 <_ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_getContactList> imp = (gpointer) 0x635cc00 __PRETTY_FUNCTION__ = "ORBit_POAObject_handle_request" #15 0x05552bd2 in ORBit_POAObject_invoke_incoming_request (pobj=0x9e81e80, recv_buffer=0xb6800bc8, opt_ev=0x0) at poa.c:1421 opname = real_ev = {_id = 0x0, _major = 0, _any = {_type = 0x0, _value = 0x0, _release = 0 '\0'}} ev = (CORBA_Environment *) 0xb73022a8 #16 0x0553a68d in giop_thread_queue_process (tdata=0xb6803298) at giop.c:771 ent = (GIOPMessageQueueEntry *) 0x0 qe = (GIOPQueueEntry *) 0xb6800988 request = (GList *) 0x0 no_policy = 1 #17 0x0553af68 in giop_request_handler_thread (data=0xb6803298, user_data=0x0) at giop.c:481 done = 89370427 l = (GList *) 0xb6803298 #18 0x00511e68 in g_thread_pool_thread_proxy (data=0x9a75e18) at gthreadpool.c:265 task = (gpointer) 0xb6803298 pool = (GRealThreadPool *) 0x9a75e18 #19 0x0051049f in g_thread_create_proxy (data=0xb6800f18) at gthread.c:591 __PRETTY_FUNCTION__ = "g_thread_create_proxy" #20 0x006bf2db in start_thread () from /lib/libpthread.so.0 No symbol table info available. #21 0x003fa83e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread -1208719120 (LWP 7545)): #0 0x00fe7402 in __kernel_vsyscall () No symbol table info available. #1 0x003f0b63 in poll () from /lib/libc.so.6 No symbol table info available. #2 0x004f5633 in g_main_context_iterate (context=0x9a757c0, block=1, dispatch=1, self=0x9a544b8) at gmain.c:2979 got_ownership = max_priority = 2147483647 timeout = 515546 some_ready = nfds = 7 allocated_nfds = fds = (GPollFD *) 0x9d29d38 __PRETTY_FUNCTION__ = "g_main_context_iterate" #3 0x004f59a9 in IA__g_main_loop_run (loop=0x9a84ce8) at gmain.c:2881 got_ownership = 7082480 self = (GThread *) 0x9a544b8 __PRETTY_FUNCTION__ = "IA__g_main_loop_run" #4 0x058e57e3 in bonobo_main () at bonobo-main.c:311 loop = (GMainLoop *) 0x9a84ce8 #5 0x0805ff50 in main (argc=3, argv=) at main.c:238 path = 0x9a7fb90 "ExchangeConfigListener" #0 0x00fe7402 in __kernel_vsyscall () The program is running. Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal] ----------- .xsession-errors (162 sec old) --------------------- (evolution:7728): e-utils-WARNING **: Plugin 'Spamassassin junk plugin' failed to load hook 'org.gnome.evolution.mail.junk:1.0' ** (evolution:7728): DEBUG: mailto URL command: evolution %s ** (evolution:7728): DEBUG: mailto URL program: evolution (evolution:7728): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 0 (evolution:7728): e-data-server-DEBUG: Loading categories from "/home/peterr/.evolution/categories.xml" (evolution:7728): e-data-server-DEBUG: Loaded 29 categories (evolution:7728): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 1 (pidgin:7535): libebook-WARNING **: EBookView: Exception while releasing BookView BBDB spinning up... (evolution:7728): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 1 (pidgin:7535): Bonobo-WARNING **: Leaked a total of 1 refs to 1 bonobo object(s) -------------------------------------------------- From abartlet at samba.org Mon May 14 12:26:08 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 14 May 2007 22:26:08 +1000 Subject: Review Request: jss - Java Security Services (bz#230262) In-Reply-To: <4643954E.5060608@redhat.com> References: <4642729C.1010105@math.unl.edu> <46428E8B.5070103@redhat.com> <46429167.4010403@redhat.com> <46429249.3020102@redhat.com> <4643954E.5060608@redhat.com> Message-ID: <1179145568.1379.21.camel@localhost.localdomain> On Thu, 2007-05-10 at 14:57 -0700, Margaret Lum wrote: > Warren Togami wrote: > > Right, unsigned in Fedora. Proprietary or 3rd party apps needing a > > signed JAR would need to provide it from a separate source. Can you > > confirm that it could be parallel installed without much trouble? > There won't be any need for this, as developers can sign at their own > discretion. Wouldn't that would break the RPM verification of the installed jss? 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 buildsys at fedoraproject.org Mon May 14 12:44:43 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 14 May 2007 12:44:43 -0000 Subject: Summary - Broken dependencies in Fedora Extras 6 - 2007-05-14 Message-ID: <20070514124443.12430.92900@extras64.linux.duke.edu> Summary of broken packages (by owner): davidz AT redhat.com livecd-tools - 008-1.fc6.noarch (9 days) livecd-tools - 008-1.fc6.noarch (9 days) ====================================================================== Broken packages in fedora-extras-needsign-6-i386: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 ====================================================================== Broken packages in fedora-extras-needsign-6-x86_64: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 From warren at togami.com Mon May 14 12:50:49 2007 From: warren at togami.com (Warren Togami) Date: Mon, 14 May 2007 08:50:49 -0400 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <5256d0b0705140523m29070c51ka9c831204fabeb22@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> <5256d0b0705140523m29070c51ka9c831204fabeb22@mail.gmail.com> Message-ID: <46485B29.60700@togami.com> Peter Robinson wrote: > Crash data attached. In my case it looks like its the evo exchange > connector. Also amusing is the bottom bit about the spamassassin > plugin... I have it disabled in the plugins bit, and the check spam is > unselected so it shouldn't load anyway. > > Peter > Please file this in Bugzilla. It needs to be properly tracked and the appropriate people notified. I checked the plugin defaults. The evolution plugin isn't enabled by default (because it never was stable), and I don't see how it could be enabling itself after upgrade. Warren Togami wtogami at redhat.com From pbrobinson at gmail.com Mon May 14 13:03:40 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 14 May 2007 14:03:40 +0100 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <46485B29.60700@togami.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> <5256d0b0705140523m29070c51ka9c831204fabeb22@mail.gmail.com> <46485B29.60700@togami.com> Message-ID: <5256d0b0705140603g94e3ca2xc95f811a5658ce50@mail.gmail.com> > > Crash data attached. In my case it looks like its the evo exchange > > connector. Also amusing is the bottom bit about the spamassassin > > plugin... I have it disabled in the plugins bit, and the check spam is > > unselected so it shouldn't load anyway. > > > > Peter > > > > Please file this in Bugzilla. It needs to be properly tracked and the > appropriate people notified. > > I checked the plugin defaults. The evolution plugin isn't enabled by > default (because it never was stable), and I don't see how it could be > enabling itself after upgrade. Nor do I but it did. Do you want it filed in RH BZ or upstream? Peter From laroche at redhat.com Mon May 14 13:11:38 2007 From: laroche at redhat.com (Florian La Roche) Date: Mon, 14 May 2007 15:11:38 +0200 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> On Sat, May 12, 2007 at 09:43:33AM -0400, Bill Nottingham wrote: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. Hello Bill, Great to see a new tree out. Obsoletes in that tree: SysVinit-2.86-16.i386.rpm is obsoleted by sysvinit-2.86-17.i386.rpm cdda2wav-2.01-11.fc7.i386.rpm is obsoleted by icedax-1.1.2-4.fc7.i386.rpm cdrecord-2.01-11.fc7.i386.rpm is obsoleted by wodim-1.1.2-4.fc7.i386.rpm gaim-meanwhile-2.0.0-0.7.beta6.fc7.i386.rpm is obsoleted by libpurple-2.0.0-3.fc7.i386.rpm jaxen-bootstrap-1.1-1jpp.1.fc7.noarch.rpm is obsoleted by jaxen-1.1-1jpp.2.fc7.noarch.rpm mkisofs-2.01-11.fc7.i386.rpm is obsoleted by genisoimage-1.1.2-4.fc7.i386.rpm moodle-sr_lt-1.8-4.fc7.noarch.rpm is obsoleted by moodle-sr_cr_bo-1.8-4.fc7.noarch.rpm moodle-sr_cr_bo-1.8-4.fc7.noarch.rpm is obsoleted by moodle-sr_cr-1.8-4.fc7.noarch.rpm moodle-zh_tw-1.8-4.fc7.noarch.rpm is obsoleted by moodle-zh_cn-1.8-4.fc7.noarch.rpm moodle looks like a packaging bug, but at least sysvinit seems to be a normal name transition and the old one could be blocked. regards, Florian La Roche From snecklifter at gmail.com Mon May 14 13:14:29 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 14:14:29 +0100 Subject: F7 Test 4 with USB ks.cfg Message-ID: <364d303b0705140614y76e8ee67r53685e0929a52812@mail.gmail.com> Hi folks, Before I bug this if someone can dupe it I would appreciate it. I am trying to install F7 Test 4 using a kickstart file (ks.cfg) from my USB key. After inserting DVD I press TAB to edit options and append ks=usb to the install options. Installation starts but then anaconda complains that it can't find the ks.cfg file and asks me to specify its location. Can anyone else replicate this? Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dblistsub-fedora at yahoo.it Mon May 14 13:16:04 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Mon, 14 May 2007 15:16:04 +0200 Subject: Experiences with rawhide-20070502-kde-x86_64-Live Message-ID: <200705141516.04713.dblistsub-fedora@yahoo.it> Greetings, I put the above Live image for a spin on an Intel 965 motherboard (exact details available on request) and my findings are below. I plan to bugzilla most of what follows, and I would appreciate directions, starting from the appropriate components to pick. Both "run from image" and "run image from ram" work, while "verify and run" does not: the symlink /dev/root -> /dev/mapper/live-rw does not get created and after a delay I got dropped in a shell suggesting that I create it. While initializing services, a line like the following unknown username gdm in message bus configuration file appears, but this seems harmless. The message from BZ #238688 is still there, but I guess it has been already fixed and this is just the DVD lagging. In /var/log/messages a quick inspection only turned up: ... hub 7-0 unable to load NLS charset utf8 unable to load NLS charset utf8 ... probe rtc_cmos 00:03 failed with error -16 ... Please note that the clock was however correctly set, although the timezone was wrong (I have my clock on GMT). KDE user switching works, it did not in FC6 because apparently the i810/intel driver did not correctly manipulate video modes and the display got garbled. My Benq wide monitor is correctly detected and brought up at 60Hz, 1680x1050, 433x271 mm, which is just about right. Suspend and resume (to RAM, judging from speed) both work, although on resume the display is blurred - this is noticeable with text, which looks as if antialising extended two or three pixels around each character: explicitly turning off and back on the monitor fixes the artifact. The host has 2 SATA disk and a Plextor on the ATA bus (found using pata_marvell, which works) but the MD arrays /dev/md0, /dev/md1 and /dev/md2 on the SATA disks are not autodetected; this prevents vgscan from detecting the PVs on said arrays. I did not try the "install to hard drive" icon, because I do not plan to install rawhide. While trying to test DVD burning, which in FC6 under the current kernel might lock up this machine as I found out trying to burn the DVD, I set out to create a junk ISO image while running off RAM, but I found upon returning that the filesystem had gone read-only about halfway in the process of creating a test.iso from the contents of /usr (I did not run out of space, was at about 75% of /). Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From snecklifter at gmail.com Mon May 14 13:17:50 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 14:17:50 +0100 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <5256d0b0705140603g94e3ca2xc95f811a5658ce50@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> <364d303b0705140458j676cbdadq859a47a11c425f75@mail.gmail.com> <5256d0b0705140523m29070c51ka9c831204fabeb22@mail.gmail.com> <46485B29.60700@togami.com> <5256d0b0705140603g94e3ca2xc95f811a5658ce50@mail.gmail.com> Message-ID: <364d303b0705140617o71d0bacfq14e21b6d4b98e167@mail.gmail.com> On 14/05/07, Peter Robinson wrote: > > > > Crash data attached. In my case it looks like its the evo exchange > > > connector. Also amusing is the bottom bit about the spamassassin > > > plugin... I have it disabled in the plugins bit, and the check spam is > > > unselected so it shouldn't load anyway. > > > > > > Peter > > > > > > > Please file this in Bugzilla. It needs to be properly tracked and the > > appropriate people notified. > > > > I checked the plugin defaults. The evolution plugin isn't enabled by > > default (because it never was stable), and I don't see how it could be > > enabling itself after upgrade. > > Nor do I but it did. > > Do you want it filed in RH BZ or upstream? > > Peter > I'm always inclined to file in RH BZ as it *may* be a packing issue given the recent name change etc. You can always hope... :) Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Mon May 14 13:20:22 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 14 May 2007 09:20:22 -0400 Subject: I miss the old artwork Message-ID: FC7 has some nice, new artwork - but I really still like the FC6 version. I hope it will still be available. From snecklifter at gmail.com Mon May 14 13:25:35 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 14:25:35 +0100 Subject: I miss the old artwork In-Reply-To: References: Message-ID: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> On 14/05/07, Neal Becker wrote: > > FC7 has some nice, new artwork - but I really still like the FC6 > version. I > hope it will still be available. > It will. You can even use Fedora Core 5 if you want that Retro 2006 feel.... Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Mon May 14 13:27:41 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 14:27:41 +0100 Subject: I miss the old artwork In-Reply-To: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> References: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> Message-ID: <364d303b0705140627r715ae9f1pe49ce27fa0611410@mail.gmail.com> On 14/05/07, Chris Brown wrote: > > On 14/05/07, Neal Becker wrote: > > > > FC7 has some nice, new artwork - but I really still like the FC6 > > version. I > > hope it will still be available. > > > > > It will. You can even use Fedora Core 5 if you want that Retro 2006 > feel.... > > Cheers > Chris Sorry, that should be you can still use Fedora Core 5's _artwork_ which is included in Fedora 7... Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Mon May 14 13:29:48 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 14 May 2007 09:29:48 -0400 Subject: pidgin-2.0.0-3.fc7 - i386 version crasheseasily on my system. In-Reply-To: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> References: <6bb886180705140425h22dd68f9u83f3078f119f3fda@mail.gmail.com> Message-ID: <16de708d0705140629r664ec263y9c2efd639bed5bb1@mail.gmail.com> On 5/14/07, David Hunter wrote: > How do I easily establish what causes pidgin to crash on my system? I'm seeing this behavior on Windows too. (not that that helps) -- Fedora Core 6 and proud From dcantrell at redhat.com Mon May 14 13:49:15 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 14 May 2007 09:49:15 -0400 Subject: I miss the old artwork In-Reply-To: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> References: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> Message-ID: <1179150555.2805.8.camel@mortise.boston.redhat.com> On Mon, 2007-05-14 at 14:25 +0100, Chris Brown wrote: > On 14/05/07, Neal Becker wrote: > FC7 has some nice, new artwork - but I really still like the > FC6 version. I > hope it will still be available. > > > It will. You can even use Fedora Core 5 if you want that Retro 2006 > feel.... Isn't it too early to use "retro" and "2006" together? -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dcantrell at redhat.com Mon May 14 13:51:31 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 14 May 2007 09:51:31 -0400 Subject: rawhide merge status In-Reply-To: <20070512134333.GB16522@nostromo.devel.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> Message-ID: <1179150691.2805.10.camel@mortise.boston.redhat.com> On Sat, 2007-05-12 at 09:43 -0400, Bill Nottingham wrote: > A rawhide tree has been pushed to the mirror master, and should show up > publically in the near future. Note that it is a very large change from > the last published rawhide, and therefore may take some time to land on > your local mirror. ^^^^ Crosscheck and standby for all call. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From snecklifter at gmail.com Mon May 14 14:01:52 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 14 May 2007 15:01:52 +0100 Subject: I miss the old artwork In-Reply-To: <1179150555.2805.8.camel@mortise.boston.redhat.com> References: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> <1179150555.2805.8.camel@mortise.boston.redhat.com> Message-ID: <364d303b0705140701g70e1e35bn9b45b83340500d55@mail.gmail.com> On 14/05/07, David Cantrell wrote: > > On Mon, 2007-05-14 at 14:25 +0100, Chris Brown wrote: > > On 14/05/07, Neal Becker wrote: > > FC7 has some nice, new artwork - but I really still like the > > FC6 version. I > > hope it will still be available. > > > > > > It will. You can even use Fedora Core 5 if you want that Retro 2006 > > feel.... > > Isn't it too early to use "retro" and "2006" together? > Not at the speed we move. :) Plus there's always the slim chance I was trying to be humorous... Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Mon May 14 13:59:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 14 May 2007 08:59:21 -0500 (CDT) Subject: I miss the old artwork In-Reply-To: <1179150555.2805.8.camel@mortise.boston.redhat.com> References: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> <1179150555.2805.8.camel@mortise.boston.redhat.com> Message-ID: <30568.65.192.24.190.1179151161.squirrel@mail.jcomserv.net> When I was your age, the advent of the heliocentric cosmological model was considered, "retro". And we LIKED it! Damn kids. Get off my lawn! :)P > On Mon, 2007-05-14 at 14:25 +0100, Chris Brown wrote: >> On 14/05/07, Neal Becker wrote: >> FC7 has some nice, new artwork - but I really still like the >> FC6 version. I >> hope it will still be available. >> >> >> It will. You can even use Fedora Core 5 if you want that Retro 2006 >> feel.... > > Isn't it too early to use "retro" and "2006" together? > > -- > David Cantrell > Red Hat / Westford, MA > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From kanarip at kanarip.com Mon May 14 14:02:51 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 14 May 2007 16:02:51 +0200 Subject: I miss the old artwork In-Reply-To: <1179150555.2805.8.camel@mortise.boston.redhat.com> References: <364d303b0705140625o46034348ta8ba50f9d72e1581@mail.gmail.com> <1179150555.2805.8.camel@mortise.boston.redhat.com> Message-ID: <46486C0B.9060809@kanarip.com> David Cantrell wrote: > On Mon, 2007-05-14 at 14:25 +0100, Chris Brown wrote: > >> On 14/05/07, Neal Becker wrote: >> FC7 has some nice, new artwork - but I really still like the >> FC6 version. I >> hope it will still be available. >> >> >> It will. You can even use Fedora Core 5 if you want that Retro 2006 >> feel.... >> > > Isn't it too early to use "retro" and "2006" together? > > Isn't everything "2006" already "retro"? -kanarip From sundaram at fedoraproject.org Mon May 14 14:31:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 20:01:00 +0530 Subject: I miss the old artwork In-Reply-To: References: Message-ID: <464872A4.8050908@fedoraproject.org> Neal Becker wrote: > FC7 has some nice, new artwork - but I really still like the FC6 version. I > hope it will still be available. It will be available in CVS anyway but if you want to make it available in the repository you got to package it. Rahul From rc040203 at freenet.de Mon May 14 14:34:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 16:34:23 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1179143015.19267.6.camel@vader.jdub.homelinux.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> Message-ID: <1179153263.4735.331.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 06:43 -0500, Josh Boyer wrote: > On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > > > What exactly is your point? > > In a nutshell: > > > > Fedora ships packages with un-readable, non-verifiable licenses. > > Hyperbole I guess, you mean FESCO and FPB ignorance? No? In international projects, normally, standardizing languages is one of the first step - Apparently forgotten in Fedora. No? Then you'll probably be able to provide a translation of this within seconds: http://cvs.fedora.redhat.com/viewcvs/rpms/python-mecab/devel/MeCab-license-Fedora?root=extras&rev=1.1&view=markup Ralf From vmakarov at redhat.com Mon May 14 14:42:01 2007 From: vmakarov at redhat.com (Vladimir Makarov) Date: Mon, 14 May 2007 10:42:01 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <1178896088.29429.55.camel@zod.rchland.ibm.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> Message-ID: <46487539.3030701@redhat.com> Josh Boyer wrote: >On Fri, 2007-05-11 at 18:58 +0400, Dmitry Butskoy wrote: > > >I understand your concern, but unfortunately I don't see how Fedora as a >project can really help here... > > > Sorry, I missed this thread and most probably what I am writing here does not belong to this mailing list devoted to Fedora developing. I know that GPL was translated to Russian several times (the first time as I remember was in 1989). I think it is better ask FSF about the issues. By the way Richard Stallman participated in creation of first Russian copyright law (about 1991) through prof. Ivannikov who was an official expert of such law. The first law was quite liberal. Now the situation is quit different. Russia has been trying to become a member of WTO for long time (about 10 years). Currently Russia has biggest unregulated issues with the USA which is pushing software piracy agenda. I think Russian police knows well what is Linux. The problem is their attitude to Linux. Here is the typical example. http://pcnews.ru/news/linux-microsoft-open-170187.html In brief, the russian police believes that Linux is a sign of ongoing criminal activity. Here is a babel fish translation of the news. May 10, 2007. The conference of the division chiefs of the Moscow police took place on Friday. The Moscow poliece chief Vladimir Pronin gathered conference for determining the new tasks to the colleagues resulting from the new federal law about the copyright protection. On the conference lieutenant general Pronin conducted the associative parallel that software pirates are rapers and killers. This conclusion Pronin drew, on the basis of the measures of the punishments, which the state introduced. Checking all companies and organizations of Moscow to the object of the observance of the copyright law will become the first stage on the fight with the piracy. At the conference they noted that the determination of status of some Microsoft program products is already worked out. Complicated situations appear, when an enterprise uses operating system Linux. Pronin is iron confident, that the enterprise, which uses Linux, has something to hide. Police experience showed that Linux is used by the "dark companies", which carry out pornography, by a money laundering, by hackers and so on. One of the representatives of police division commented about Linux: "The usage of Linux according to the Russian laws, unfortunately, is not a crime. However, this fact testifies that the user fears that those checking can find something forbidden on his computer and the user desires to hide that. One should place all such hackers on the calculation and conduct the periodic inspections, carry out explanatory conversations. Linux on the computer as storing pornography according to our laws is not a crime, but Linux and the pronograpy are closely connected with the activity of production, circulation, propagation, seducing young and that is absolutely illegal". From jkeating at redhat.com Mon May 14 14:46:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 14:46:36 -0000 Subject: rawhide merge status In-Reply-To: <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> Message-ID: <200409302026.29968.jkeating@redhat.com> On Monday 14 May 2007 09:11:38 Florian La Roche wrote: > SysVinit-2.86-16.i386.rpm is obsoleted by sysvinit-2.86-17.i386.rpm Rename, will block. > cdda2wav-2.01-11.fc7.i386.rpm is obsoleted by icedax-1.1.2-4.fc7.i386.rpm > cdrecord-2.01-11.fc7.i386.rpm is obsoleted by wodim-1.1.2-4.fc7.i386.rpm > mkisofs-2.01-11.fc7.i386.rpm is obsoleted by genisoimage-1.1.2-4.fc7.i386.rpm These can finally go away, will block. > gaim-meanwhile-2.0.0-0.7.beta6.fc7.i386.rpm is obsoleted by > libpurple-2.0.0-3.fc7.i386.rpm jaxen-bootstrap-1.1-1jpp.1.fc7.noarch.rpm is > obsoleted by jaxen-1.1-1jpp.2.fc7.noarch.rpm Not sure what exactly is going on with these. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 14 14:50:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 14:50:31 -0000 Subject: Ext4 for F7 In-Reply-To: <364d303b0705121646x4026b985ie3928c648f5092b1@mail.gmail.com> References: <364d303b0705121646x4026b985ie3928c648f5092b1@mail.gmail.com> Message-ID: <200409302030.25625.jkeating@redhat.com> On Saturday 12 May 2007 19:46:41 Chris Brown wrote: > Ext4 appears to be enabled in the latest kernels - will anaconda support it > in the same way as it unofficially supports jfs? As in users need to type > 'linux ext4' at the prompt to enable to option during install. Or are we > looking at F8? Sorry if this has been asked already but if the above is not > the case I'd be interested to know why. Reports are that it is now quite > stable... :) I'd hope F8. I attended an ext4 talk at the RH Summit last week and based on information gathered there I wouldn't expect ext4 to be remotely safe to use for a while. It should be there for you to create test file systems and play around with it, but I don't think it would be prudent to allow anaconda to throw it into the mix. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at redhat.com Mon May 14 14:58:11 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 14 May 2007 16:58:11 +0200 Subject: Making beagle optional Message-ID: <1179154692.3560.23.camel@localhost.localdomain> I just commited a change to comps which makes beagle optional instead of installed by default. The idea with beagle (and tracker) is nice, but bugs keep on showing up causing the search daemon to use a lot of cpu and/or memory, and this makes the default install look pretty bad. This is somewhat of a feature regression in the default install, but at this point we just don't have the manpower to make it work 100%. But if people want it its still there, and eventually it'll be good enought to turn on by default without affecting the general distro quality. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a witless one-eyed Green Beret haunted by an iconic dead American confidante She's a strong-willed paranoid schoolgirl with an incredible destiny. They fight crime! From jkeating at redhat.com Mon May 14 15:04:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 11:04:04 -0400 Subject: rawhide merge status In-Reply-To: <200409302026.29968.jkeating@redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> <200409302026.29968.jkeating@redhat.com> Message-ID: <200705141104.04319.jkeating@redhat.com> On Thursday 30 September 2004 20:26:29 Jesse Keating wrote: > > cdda2wav-2.01-11.fc7.i386.rpm is obsoleted by icedax-1.1.2-4.fc7.i386.rpm > > cdrecord-2.01-11.fc7.i386.rpm is obsoleted by wodim-1.1.2-4.fc7.i386.rpm > > mkisofs-2.01-11.fc7.i386.rpm is obsoleted by > > genisoimage-1.1.2-4.fc7.i386.rpm > > These can finally go away, will block. Hrm, these aren't in koji actually, where are you seeing them, I need to investigate more. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 14 15:05:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 11:05:09 -0400 Subject: rawhide merge status In-Reply-To: <200705141104.04319.jkeating@redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <200409302026.29968.jkeating@redhat.com> <200705141104.04319.jkeating@redhat.com> Message-ID: <200705141105.09557.jkeating@redhat.com> On Monday 14 May 2007 11:04:04 Jesse Keating wrote: > On Thursday 30 September 2004 20:26:29 Jesse Keating wrote: > > > cdda2wav-2.01-11.fc7.i386.rpm is obsoleted by > > > icedax-1.1.2-4.fc7.i386.rpm cdrecord-2.01-11.fc7.i386.rpm is obsoleted > > > by wodim-1.1.2-4.fc7.i386.rpm mkisofs-2.01-11.fc7.i386.rpm is obsoleted > > > by > > > > genisoimage-1.1.2-4.fc7.i386.rpm > > > > These can finally go away, will block. > > Hrm, these aren't in koji actually, where are you seeing them, I need to > investigate more. d'oh. cdrtools. Blocking. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Mon May 14 15:12:22 2007 From: laroche at redhat.com (Florian La Roche) Date: Mon, 14 May 2007 17:12:22 +0200 Subject: rawhide merge status In-Reply-To: <200705141104.04319.jkeating@redhat.com> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> <200409302026.29968.jkeating@redhat.com> <200705141104.04319.jkeating@redhat.com> Message-ID: <20070514151222.GA21859@dudweiler.stuttgart.redhat.com> On Mon, May 14, 2007 at 11:04:04AM -0400, Jesse Keating wrote: > On Thursday 30 September 2004 20:26:29 Jesse Keating wrote: > > > cdda2wav-2.01-11.fc7.i386.rpm is obsoleted by icedax-1.1.2-4.fc7.i386.rpm > > > cdrecord-2.01-11.fc7.i386.rpm is obsoleted by wodim-1.1.2-4.fc7.i386.rpm > > > mkisofs-2.01-11.fc7.i386.rpm is obsoleted by > > > > genisoimage-1.1.2-4.fc7.i386.rpm > > > > These can finally go away, will block. > > Hrm, these aren't in koji actually, where are you seeing them, I need to > investigate more. Hello Jesse, Current fedora/development trees have them. regards, Florian La Roche From oliver at linux-kernel.at Mon May 14 15:14:08 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 17:14:08 +0200 Subject: kernel package In-Reply-To: <46487A25.70405@hp.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <46481589.6010409@linux-kernel.at> <46487A25.70405@hp.com> Message-ID: <46487CC0.20005@linux-kernel.at> On 05/14/2007 05:03 PM, Jay Estabrook wrote: > Oliver Falk wrote: >> On 05/11/2007 02:01 PM, David Woodhouse wrote: >> >>> Once upon a time the folks at HP were threatening to send me SMP Alpha >>> boxen -- not sure if I could still pull that off... >> Anyone from HP here? Jay, do you have any good contacts? > > I've been trying, but unfortunately, no one has stepped forward... :-( > > I'll keep trying, but don't hold your breath. OK. Good to know you're on it. >>> +Source50: kernel-%{kversion}-alpha.config >>> +Source50: kernel-%{kversion}-alpha-smp.config >> I don't have a smp config at the moment. So we need to put this out, >> else up will no build clean. > > SMP config is really just UP config with SMP turned on; another option, > NR_CPUS should be in the range 2-32, others should default OK, unless > things have changed drastically. I've been building against the latest > FC5 kernel, ie 2.6.20-1.2316, and haven't had anything unusual turn up. CONFIG_SMP=y CONFIG_NR_CPUS=16 Is what I saw recently... Will put a up and smp config in my tree now. If it builds fine, someone will be able to test it - I'm sure :-) >>> # Exec shield >>> +%ifnarch alpha alphaev5 alphaev56 alphaev6 alphaev6 >>> %patch810 -p1 >>> +%endif >> Even more compile errors. :-) > > One reason we seem to have to put in the multiple Alpha > arches is, that if ":--target=..." is set for some reason, > without all the arches listed, build will fail. If there > were some way to override and reset to base-arch==alpha if > one of the others shows up would be fine. We really do NOT > want to build the GENERIC kernel for anything BUT the base > architecture, of course. Other more specific kernels, like > TITAN or LX164 or the like, may themselves ask "--mcpu=ev67" > or "--mcpu=ev56" or some such. ok. -of From oliver at linux-kernel.at Mon May 14 15:18:14 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 17:18:14 +0200 Subject: [AC-Admin] Re: kernel package In-Reply-To: <46487C47.6030803@hp.com> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178885585.21820.51.camel@shinybook.infradead.org> <46481AD1.1070300@linux-kernel.at> <46487C47.6030803@hp.com> Message-ID: <46487DB6.6060805@linux-kernel.at> On 05/14/2007 05:12 PM, Jay Estabrook wrote: [ ... ] >>> Are there SMP boxen without BWX? >> Hm. Maybe someone with more knowledge about h/w can answer this; EV5 >> afaik doesn't have bwx. And there's the AS1200; SMP capable and with a >> 21164 processor, maybe ev5, maybe already ev56 (ev5 was only <= 366 MHz >> and AS1200 has >= 400 Mhz.). > > Yes, SABLE/LYNX (AS2100/AS2100A) and RAWHIDE (AS4100 and DS5300/7300) > are all SMP and have non-BWX-capable core logic chipsets, even if the > CPUs are EV56. I knew, you know that :-) However. I wonder... /me thought, that all ev56 have bwx... -of From sundaram at fedoraproject.org Mon May 14 15:19:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 20:49:24 +0530 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <46487DFC.3020402@fedoraproject.org> Alexander Larsson wrote: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. > A very good decision. Thank you. Rahul From dwmw2 at infradead.org Mon May 14 15:30:51 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 May 2007 23:30:51 +0800 Subject: kernel package In-Reply-To: <46481589.6010409@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <46481589.6010409@linux-kernel.at> Message-ID: <1179156651.3482.21.camel@shinybook.infradead.org> On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote: > > source "drivers/net/fec_8xx/Kconfig" > -source "drivers/net/fec_mpc52xx/Kconfig" > source "drivers/net/fs_enet/Kconfig" > > endmenu > > linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via > config as far as I can remember; So I had to patch it out at the end... That's weird -- it doesn't affect any other architectures. Sure you're not defining PPC_MPC52xx? :) -- dwmw2 From andy at smile.org.ua Mon May 14 15:32:56 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 14 May 2007 18:32:56 +0300 Subject: Legality of Fedora in production environment In-Reply-To: <46487539.3030701@redhat.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <46487539.3030701@redhat.com> Message-ID: <20070514153256.GC1097@serv.smile.org.ua> Hi Vladimir Makarov! On Mon, May 14, 2007 at 10:42:01AM -0400, Vladimir Makarov wrote next: > Here is the typical example. > http://pcnews.ru/news/linux-microsoft-open-170187.html Please, DO NOT READ that. It's very famoust 1st April joke. But issue in other words in the corruption. I mean the Microsoft's software (due to its fee > 0) can be used for money back (also called "reverts"). I try to explain this. Person A and company C agree to buy some software for company B. Note: A is a official workers on C. The B write bill with higher price (about 30%). After C pay to software approx 130% of price the part of that price A and people from B share between each other. Understandable? The OSS model is not acceptable for this financial tricks. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From oliver at linux-kernel.at Mon May 14 15:35:43 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 17:35:43 +0200 Subject: kernel package In-Reply-To: <1179156651.3482.21.camel@shinybook.infradead.org> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <46481589.6010409@linux-kernel.at> <1179156651.3482.21.camel@shinybook.infradead.org> Message-ID: <464881CF.1050306@linux-kernel.at> On 05/14/2007 05:30 PM, David Woodhouse wrote: > On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote: >> source "drivers/net/fec_8xx/Kconfig" >> -source "drivers/net/fec_mpc52xx/Kconfig" >> source "drivers/net/fs_enet/Kconfig" >> >> endmenu >> >> linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it via >> config as far as I can remember; So I had to patch it out at the end... > > That's weird -- it doesn't affect any other architectures. > Sure you're not defining PPC_MPC52xx? :) Hm... Would wonder... However; Will try to rebuild without the patch - maybe something was weird at my end... No, it's not defined! ;-) -of From davej at redhat.com Mon May 14 15:37:32 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 14 May 2007 11:37:32 -0400 Subject: Ext4 for F7 In-Reply-To: <200409302030.25625.jkeating@redhat.com> References: <364d303b0705121646x4026b985ie3928c648f5092b1@mail.gmail.com> <200409302030.25625.jkeating@redhat.com> Message-ID: <20070514153731.GA23258@redhat.com> On Thu, Sep 30, 2004 at 08:30:25PM -0400, Jesse Keating wrote: > On Saturday 12 May 2007 19:46:41 Chris Brown wrote: > > Ext4 appears to be enabled in the latest kernels - will anaconda support it > > in the same way as it unofficially supports jfs? As in users need to type > > 'linux ext4' at the prompt to enable to option during install. Or are we > > looking at F8? Sorry if this has been asked already but if the above is not > > the case I'd be interested to know why. Reports are that it is now quite > > stable... :) > > I'd hope F8. I attended an ext4 talk at the RH Summit last week and based on > information gathered there I wouldn't expect ext4 to be remotely safe to use > for a while. It should be there for you to create test file systems and play > around with it, but I don't think it would be prudent to allow anaconda to > throw it into the mix. It won't be in *any* release until it loses its 'dev' moniker upstream. I'll turn it back on in rawhide after F7 is out, with the usual caveats wrt your fs's being accessable with future versions of ext4dev. So far the only real purpose of using ext4 is extents & >32bit blocknrs, which unless you have really large filesystems, isn't really useful anyway. Dave -- http://www.codemonkey.org.uk From oliver at linux-kernel.at Mon May 14 15:38:49 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 14 May 2007 17:38:49 +0200 Subject: [AC-Admin] Re: kernel package In-Reply-To: <464881CF.1050306@linux-kernel.at> References: <46442E72.8060402@linux-kernel.at> <1178879641.13113.28.camel@vader.jdub.homelinux.org> <46445252.8080400@linux-kernel.at> <1178884889.21820.46.camel@shinybook.infradead.org> <46481589.6010409@linux-kernel.at> <1179156651.3482.21.camel@shinybook.infradead.org> <464881CF.1050306@linux-kernel.at> Message-ID: <46488289.1060008@linux-kernel.at> On 05/14/2007 05:35 PM, Oliver Falk wrote: > On 05/14/2007 05:30 PM, David Woodhouse wrote: >> On Mon, 2007-05-14 at 09:53 +0200, Oliver Falk wrote: >>> source "drivers/net/fec_8xx/Kconfig" >>> -source "drivers/net/fec_mpc52xx/Kconfig" >>> source "drivers/net/fs_enet/Kconfig" >>> >>> endmenu >>> >>> linux-2.6-mpc52xx-fec.patch adds it and I wasn't able to disable it >>> via config as far as I can remember; So I had to patch it out at the >>> end... >> >> That's weird -- it doesn't affect any other architectures. >> Sure you're not defining PPC_MPC52xx? :) > > Hm... Would wonder... However; Will try to rebuild without the patch - > maybe something was weird at my end... No, it's not defined! ;-) Ah... That's why: + make -s ARCH=alpha nonint_oldconfig drivers/net/fec_mpc52xx/Kconfig:14:warning: leading whitespace ignored drivers/net/fec_mpc52xx/Kconfig:7:warning: 'select' used by config symbol 'FEC_MPC52xx' refer to undefined symbol 'PPC_BESTCOMM' + make -s ARCH=alpha -j2 boot drivers/net/fec_mpc52xx/Kconfig:14:warning: leading whitespace ignored drivers/net/fec_mpc52xx/Kconfig:7:warning: 'select' used by config symbol 'FEC_MPC52xx' refer to undefined symbol 'PPC_BESTCOMM' Let's see if it compiles... -of From ssorce at redhat.com Mon May 14 15:47:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 11:47:43 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070514153256.GC1097@serv.smile.org.ua> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <46487539.3030701@redhat.com> <20070514153256.GC1097@serv.smile.org.ua> Message-ID: <1179157663.29833.5.camel@willson> On Mon, 2007-05-14 at 18:32 +0300, Andy Shevchenko wrote: > Hi Vladimir Makarov! > > On Mon, May 14, 2007 at 10:42:01AM -0400, Vladimir Makarov wrote next: > > > Here is the typical example. > > http://pcnews.ru/news/linux-microsoft-open-170187.html > Please, DO NOT READ that. > > It's very famoust 1st April joke. > > But issue in other words in the corruption. > I mean the Microsoft's software (due to its fee > 0) can be used for money > back (also called "reverts"). > > I try to explain this. > Person A and company C agree to buy some software for company B. Note: A is > a official workers on C. The B write bill with higher price (about 30%). > After C pay to software approx 130% of price the part of that price A and > people from B share between each other. Understandable? > > The OSS model is not acceptable for this financial tricks. Oh it is, you can bill for services you never give, it is the same thing. You don't need to exchange physical goods to be able to issue false bills with the intent of committing fraud against the tax department or your own company. Simo. From giallu at gmail.com Mon May 14 15:51:26 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 14 May 2007 17:51:26 +0200 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: On 5/14/07, Alexander Larsson wrote: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but Does this means both are optional now? If so, isn't it better to have one installed but, if not considered stable enough, just disabled by default? From jwboyer at jdub.homelinux.org Mon May 14 15:56:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 10:56:36 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1179153263.4735.331.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> Message-ID: <1179158196.19267.20.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 16:34 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-14 at 06:43 -0500, Josh Boyer wrote: > > On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > > > > > What exactly is your point? > > > In a nutshell: > > > > > > Fedora ships packages with un-readable, non-verifiable licenses. > > > > Hyperbole > > I guess, you mean FESCO and FPB ignorance? > > No? In international projects, normally, standardizing languages is one > of the first step - Apparently forgotten in Fedora. > > No? Then you'll probably be able to provide a translation of this within > seconds: > http://cvs.fedora.redhat.com/viewcvs/rpms/python-mecab/devel/MeCab-license-Fedora?root=extras&rev=1.1&view=markup Me personally? No. But just because you and I can't read it doesn't make it un-readable and non-verifiable. josh From Jerry.James at usu.edu Mon May 14 16:00:53 2007 From: Jerry.James at usu.edu (Jerry James) Date: Mon, 14 May 2007 10:00:53 -0600 Subject: rawhide merge status In-Reply-To: <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> (Florian La Roche's message of "Mon, 14 May 2007 15:11:38 +0200") References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> Message-ID: On Mon, 14 May 2007 at 15:11:38 +0200, Florian La Roche wrote: > Obsoletes in that tree: [snip] > moodle-sr_lt-1.8-4.fc7.noarch.rpm is obsoleted by moodle-sr_cr_bo-1.8-4.fc7.noarch.rpm > moodle-sr_cr_bo-1.8-4.fc7.noarch.rpm is obsoleted by moodle-sr_cr-1.8-4.fc7.noarch.rpm > moodle-zh_tw-1.8-4.fc7.noarch.rpm is obsoleted by moodle-zh_cn-1.8-4.fc7.noarch.rpm > > moodle looks like a packaging bug, but at least sysvinit seems to be a normal > name transition and the old one could be blocked. Darn. This is what happens when you people let a green packager like me take over maintenance of an established package. What I was trying to accomplish was splitting out related, but different languages, which were packaged together in earlier versions of moodle. (They are packaged in separate source files upstream.) So the current spec file has this, for example: %package zh_cn Obsoletes: moodle-zh <= 1.6.3 Provides: moodle-zh = 1.6.3 %package zh_tw Obsoletes: moodle-zh <= 1.6.3 Provides: moodle-zh = 1.6.3 I thought AutoReqProv would do the right thing here, but this problem makes me suspect I should have written this: %package zh_cn Obsoletes: moodle-zh <= 1.6.3 Provides: moodle-zh = 1.6.3, moodle-zh_cn = %{version}-%{release} %package zh_tw Obsoletes: moodle-zh <= 1.6.3 Provides: moodle-zh = 1.6.3, moodle-zh_tw = %{version}-%{release} Would that solve the problem? -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From rc040203 at freenet.de Mon May 14 16:09:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 18:09:45 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1179158196.19267.20.camel@vader.jdub.homelinux.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> Message-ID: <1179158985.4735.348.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 10:56 -0500, Josh Boyer wrote: > On Mon, 2007-05-14 at 16:34 +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-14 at 06:43 -0500, Josh Boyer wrote: > > > On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > > > > > > > What exactly is your point? > > > > In a nutshell: > > > > > > > > Fedora ships packages with un-readable, non-verifiable licenses. > > > > > > Hyperbole > > > > I guess, you mean FESCO and FPB ignorance? > > > > No? In international projects, normally, standardizing languages is one > > of the first step - Apparently forgotten in Fedora. > > > > No? Then you'll probably be able to provide a translation of this within > > seconds: > > http://cvs.fedora.redhat.com/viewcvs/rpms/python-mecab/devel/MeCab-license-Fedora?root=extras&rev=1.1&view=markup > > Me personally? No. But just because you and I can't read it doesn't > make it un-readable and non-verifiable. What kind of argument is this? None of us both can read it, nor will the police man wait behind our Russian friends, nor will the FBI agent raiding your home because somebody accused you to own "stolen SW". May-be you now realize why we can't avoid to have an agreement on "acceptable license's languages"? It's quite simple: You have to agree on a common language (or a limited set of thereof) otherwise you can't communicate with your customers (here: users) and 3rd parties (here: authorities). For a US based distro, I'd expect this language to be English. This would at least enable users to translate it into his native language without major effort. Ralf From vmakarov at redhat.com Mon May 14 16:10:24 2007 From: vmakarov at redhat.com (Vladimir Makarov) Date: Mon, 14 May 2007 12:10:24 -0400 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <46488512.2020803@samba.org> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> Message-ID: <464889F0.5040505@redhat.com> Alexander Bokovoy wrote: >Simo, Vladimir, folks, > >please stop distributing this crap. It is unfortunate drop of black PR >from our enemies during current discussions on improving legality of >software in schools at Russian government. But it is far from reality. > > Alexander, I am really sorry about this. My appologies. I did not know that it was April 1st joke. I read this just recently and took it seriously. Probably my knowledege about modern Russia is not adequate anymore. I left it ten years ago. >The case described below is April, 1st joke which was created by >www.securitylab.ru portal (a good one!) but went largely unnoticed until >someone showed it to general IT media without linking to the original. > >http://www.securitylab.ru/news/293577.php > > > From jwboyer at jdub.homelinux.org Mon May 14 16:13:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 11:13:23 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1179158985.4735.348.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> Message-ID: <1179159204.19267.23.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 18:09 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-14 at 10:56 -0500, Josh Boyer wrote: > > On Mon, 2007-05-14 at 16:34 +0200, Ralf Corsepius wrote: > > > On Mon, 2007-05-14 at 06:43 -0500, Josh Boyer wrote: > > > > On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > > > > > > > > > What exactly is your point? > > > > > In a nutshell: > > > > > > > > > > Fedora ships packages with un-readable, non-verifiable licenses. > > > > > > > > Hyperbole > > > > > > I guess, you mean FESCO and FPB ignorance? > > > > > > No? In international projects, normally, standardizing languages is one > > > of the first step - Apparently forgotten in Fedora. > > > > > > No? Then you'll probably be able to provide a translation of this within > > > seconds: > > > http://cvs.fedora.redhat.com/viewcvs/rpms/python-mecab/devel/MeCab-license-Fedora?root=extras&rev=1.1&view=markup > > > > Me personally? No. But just because you and I can't read it doesn't > > make it un-readable and non-verifiable. > What kind of argument is this? Wasn't an argument. > None of us both can read it, nor will the police man wait behind our > Russian friends, nor will the FBI agent raiding your home because > somebody accused you to own "stolen SW". > > May-be you now realize why we can't avoid to have an agreement on > "acceptable license's languages"? > > It's quite simple: You have to agree on a common language (or a limited > set of thereof) otherwise you can't communicate with your customers > (here: users) and 3rd parties (here: authorities). For a US based > distro, I'd expect this language to be English. > > This would at least enable users to translate it into his native > language without major effort. Aren't you on the Packaging Committee? Why don't you bring this up as a proposal. It doesn't sound like a bad idea to me. josh From sundaram at fedoraproject.org Mon May 14 16:15:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 21:45:49 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179158985.4735.348.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> Message-ID: <46488B35.7010202@fedoraproject.org> Ralf Corsepius wrote: > It's quite simple: You have to agree on a common language (or a limited > set of thereof) otherwise you can't communicate with your customers > (here: users) and 3rd parties (here: authorities). For a US based > distro, I'd expect this language to be English. Correct. The license not being readable is a misleading exaggeration but the underlying point is valid. We need review guidelines that enforce this and bugs should be filed against packages which don't have license text in English. Ralf, do you know of other packages beside the example you cited? Rahul From ville.skytta at iki.fi Mon May 14 16:20:06 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 14 May 2007 19:20:06 +0300 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> Message-ID: <200705141920.06902.ville.skytta@iki.fi> On Monday 14 May 2007, Jerry James wrote: > On Mon, 14 May 2007 at 15:11:38 +0200, Florian La Roche > > What I was trying to accomplish was splitting out related, but different > languages, which were packaged together in earlier versions of moodle. > (They are packaged in separate source files upstream.) So the current > spec file has this, for example: > > %package zh_cn > Obsoletes: moodle-zh <= 1.6.3 > Provides: moodle-zh = 1.6.3 > > %package zh_tw > Obsoletes: moodle-zh <= 1.6.3 > Provides: moodle-zh = 1.6.3 > > I thought AutoReqProv would do the right thing here, but this problem > makes me suspect I should have written this: > > %package zh_cn > Obsoletes: moodle-zh <= 1.6.3 > Provides: moodle-zh = 1.6.3, moodle-zh_cn = %{version}-%{release} > > %package zh_tw > Obsoletes: moodle-zh <= 1.6.3 > Provides: moodle-zh = 1.6.3, moodle-zh_tw = %{version}-%{release} > > Would that solve the problem? I don't think so. Providing eg. moodle-zh_tw = %{version}-%{release} in itself is redundant. One thing that you may want to have a look in the above is that there are self-obsoletion problems - changing those to these in both zh_cn and zh_tw could help (assuming %{version} is greater than or equal to 1.6.4): Obsoletes: moodle-zh < 1.6.4 Provides: moodle-zh = %{version}-%{release} Or perhaps drop the Provides altogether? See http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d From rc040203 at freenet.de Mon May 14 16:33:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 18:33:27 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <1179159204.19267.23.camel@vader.jdub.homelinux.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <1179159204.19267.23.camel@vader.jdub.homelinux.org> Message-ID: <1179160407.4735.352.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 11:13 -0500, Josh Boyer wrote: > On Mon, 2007-05-14 at 18:09 +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-14 at 10:56 -0500, Josh Boyer wrote: > > > On Mon, 2007-05-14 at 16:34 +0200, Ralf Corsepius wrote: > > > > On Mon, 2007-05-14 at 06:43 -0500, Josh Boyer wrote: > > > > > On Mon, 2007-05-14 at 05:55 +0200, Ralf Corsepius wrote: > > > > > > > > > > > What exactly is your point? > > > > > > In a nutshell: > > > > > > > > > > > > Fedora ships packages with un-readable, non-verifiable licenses. > > > > > > > > > > Hyperbole > > > > > > > > I guess, you mean FESCO and FPB ignorance? > > > > > > > > No? In international projects, normally, standardizing languages is one > > > > of the first step - Apparently forgotten in Fedora. > > > > > > > > No? Then you'll probably be able to provide a translation of this within > > > > seconds: > > > > http://cvs.fedora.redhat.com/viewcvs/rpms/python-mecab/devel/MeCab-license-Fedora?root=extras&rev=1.1&view=markup > > > > > > Me personally? No. But just because you and I can't read it doesn't > > > make it un-readable and non-verifiable. > > What kind of argument is this? > > Wasn't an argument. > > > None of us both can read it, nor will the police man wait behind our > > Russian friends, nor will the FBI agent raiding your home because > > somebody accused you to own "stolen SW". > > > > May-be you now realize why we can't avoid to have an agreement on > > "acceptable license's languages"? > > > > It's quite simple: You have to agree on a common language (or a limited > > set of thereof) otherwise you can't communicate with your customers > > (here: users) and 3rd parties (here: authorities). For a US based > > distro, I'd expect this language to be English. > > > > This would at least enable users to translate it into his native > > language without major effort. > > Aren't you on the Packaging Committee? Yes, but ... the FPC only deals with questions related to "how to package" (technical questions) and not with political issues (What to package and what not) rsp. legal issues (Which licenses are considered valid.) In my understanding, the "what" is FESCO's job, the "legal" is GdK's job. > Why don't you bring this up as a > proposal. It doesn't sound like a bad idea to me. From rc040203 at freenet.de Mon May 14 16:39:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 18:39:08 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <46488B35.7010202@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> Message-ID: <1179160748.4735.358.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 21:45 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > It's quite simple: You have to agree on a common language (or a limited > > set of thereof) otherwise you can't communicate with your customers > > (here: users) and 3rd parties (here: authorities). For a US based > > distro, I'd expect this language to be English. > > Correct. The license not being readable is a misleading exaggeration but > the underlying point is valid. We need review guidelines that enforce > this and bugs should be filed against packages which don't have license > text in English. > > Ralf, do you know of other packages beside the example you cited? Not off head. I was aware about the mecab case because I had blocked the review due to lack of "applicable license", when Spot had OK'ed it after a Japanese email had been added. Without having checked details, I'd expect other "primarily Japanese audience/Asian language packages" having the same issue. Ralf From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 14 16:51:26 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 15 May 2007 01:51:26 +0900 Subject: Legality of Fedora in production environment In-Reply-To: <1179160748.4735.358.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179160748.4735.358.camel@mccallum.corsepiu.local> Message-ID: <4648938E.2070104@ioa.s.u-tokyo.ac.jp> Ralf Corsepius wrote, at 05/15/2007 01:39 AM +9:00: > On Mon, 2007-05-14 at 21:45 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: >>> It's quite simple: You have to agree on a common language (or a limited >>> set of thereof) otherwise you can't communicate with your customers >>> (here: users) and 3rd parties (here: authorities). For a US based >>> distro, I'd expect this language to be English. >> Correct. The license not being readable is a misleading exaggeration but >> the underlying point is valid. We need review guidelines that enforce >> this and bugs should be filed against packages which don't have license >> text in English. >> >> Ralf, do you know of other packages beside the example you cited? > Not off head. I was aware about the mecab case because I had blocked the > review due to lack of "applicable license", when Spot had OK'ed it after > a Japanese email had been added. Without having checked details, I'd > expect other "primarily Japanese audience/Asian language packages" > having the same issue. > > Ralf In this case we must make it sure that the translated license can be accepted on Fedora. Actually I have one software which I want to submit into Fedora, of which the license is written completely in Japanese. I asked the developer (, who is Japanese) some questions about the license, then translated into English, sent to Callaway, and he asked FSF about my translated license. And we (Callaway and me) are waiting the reply from FSF from more than one month..... Note: the maintainer of mecab related packages is me. Mamoru From aph at redhat.com Mon May 14 16:57:06 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 May 2007 17:57:06 +0100 Subject: Legality of Fedora in production environment In-Reply-To: <4648938E.2070104@ioa.s.u-tokyo.ac.jp> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179160748.4735.358.camel@mccallum.corsepiu.local> <4648938E.2070104@ioa.s.u-tokyo.ac.jp> Message-ID: <17992.38114.58422.948857@zebedee.pink> Mamoru Tasaka writes: > In this case we must make it sure that the translated license can > be accepted on Fedora. Actually I have one software which I want to > submit into Fedora, of which the license is written completely in > Japanese. I asked the developer (, who is Japanese) some questions > about the license, then translated into English, sent to Callaway, > and he asked FSF about my translated license. And we (Callaway and > me) are waiting the reply from FSF from more than one month..... Well, that's hardly surprising: it's not the FSF's mission to review other people's licences. Is it really quite impossible to relicense this package using one of the well-known free licences? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From sundaram at fedoraproject.org Mon May 14 17:00:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 22:30:33 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <17992.38114.58422.948857@zebedee.pink> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179160748.4735.358.camel@mccallum.corsepiu.local> <4648938E.2070104@ioa.s.u-tokyo.ac.jp> <17992.38114.58422.948857@zebedee.pink> Message-ID: <464895B1.5020507@fedoraproject.org> Andrew Haley wrote: > Mamoru Tasaka writes: > > > In this case we must make it sure that the translated license can > > be accepted on Fedora. Actually I have one software which I want to > > submit into Fedora, of which the license is written completely in > > Japanese. I asked the developer (, who is Japanese) some questions > > about the license, then translated into English, sent to Callaway, > > and he asked FSF about my translated license. And we (Callaway and > > me) are waiting the reply from FSF from more than one month..... > > Well, that's hardly surprising: it's not the FSF's mission to review > other people's licences. It is. It is something they have agreed to do and they have done so repeatedly whenever we asked them. Rahul From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 14 17:05:17 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 15 May 2007 02:05:17 +0900 Subject: Legality of Fedora in production environment In-Reply-To: <17992.38114.58422.948857@zebedee.pink> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179160748.4735.358.camel@mccallum.corsepiu.local> <4648938E.2070104@ioa.s.u-tokyo.ac.jp> <17992.38114.58422.948857@zebedee.pink> Message-ID: <464896CD.7030001@ioa.s.u-tokyo.ac.jp> (Sorry, I sent to Andrew directly. I re-send this to fedel list) Andrew Haley wrote, at 05/15/2007 01:57 AM +9:00: > Mamoru Tasaka writes: > > > In this case we must make it sure that the translated license can > > be accepted on Fedora. Actually I have one software which I want to > > submit into Fedora, of which the license is written completely in > > Japanese. I asked the developer (, who is Japanese) some questions > > about the license, then translated into English, sent to Callaway, > > and he asked FSF about my translated license. And we (Callaway and > > me) are waiting the reply from FSF from more than one month..... > > Well, that's hardly surprising: it's not the FSF's mission to review > other people's licences. Is it really quite impossible to relicense > this package using one of the well-known free licences? > > Andrew. (Just note that I have not submitted the review request of this package and I won't do until this license issue is resolved) I asked the developer to change the license to GPL or something, but the developer said "I don't want to change this license"...... And note that it is not the first time for me that I asked to Callaway about the translation of license originally written in Japanese and he asked FSF about the translation (not mecab package) Mamoru From david at lovesunix.net Mon May 14 17:20:01 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 14 May 2007 19:20:01 +0200 Subject: Making beagle optional In-Reply-To: References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <1179163201.28960.32.camel@dawkins> man, 14 05 2007 kl. 17:51 +0200, skrev Gianluca Sforna: > On 5/14/07, Alexander Larsson wrote: > > I just commited a change to comps which makes beagle optional instead of > > installed by default. The idea with beagle (and tracker) is nice, but > > Does this means both are optional now? > If so, isn't it better to have one installed but, if not considered > stable enough, just disabled by default? Both have been optional for a while, we installed Beagle by default since FC6 but this is not going to happen anymore since Beagle out of the box still consumes 100% CPU. Tracker in this sense is much better, I've been giving it a trial run for a while now, it seems stable and doesn't spin out of control.. sadly it doesn't cover as many formats as Beagle does. Both I think needs more use cases outside of replacing the search dialog, something like Banshee or Rhythmbox could arrange their media libraries using this kind of technology. The fact is that this technology has been around for a while and yet nobody is really using it to make the desktop better. Hopefully this will change for F8. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From nicolas.mailhot at laposte.net Mon May 14 17:35:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 19:35:40 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <46488B35.7010202@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> Message-ID: <1179164140.14036.13.camel@rousalka.dyndns.org> Le lundi 14 mai 2007 ? 21:45 +0530, Rahul Sundaram a ?crit : > Ralf Corsepius wrote: > > It's quite simple: You have to agree on a common language (or a limited > > set of thereof) otherwise you can't communicate with your customers > > (here: users) and 3rd parties (here: authorities). For a US based > > distro, I'd expect this language to be English. > > Correct. The license not being readable is a misleading exaggeration but > the underlying point is valid. We need review guidelines that enforce > this and bugs should be filed against packages which don't have license > text in English. English is no more blessed than another langage. If you think the English-only GPL has some power internationally, you have to accept the corrollary: other single-langage licenses have power in the USA despite not being written in English. And the only document that will have any legal value is the original licence in its original langage (with translations from locally-legaly-accredited entities) You want to "Fix" the problem you do what Mandriva did: have dedicated packages for each license. And include there proposed translations of the root document (which may or may not be in english). Ideally done by accredited people for each locale. Mandating English is just a stupid way to annoy local juridictions and remind them they have laws requiring documents in their own language (Yes every country has those including sometimes import laws forbidding untranslated stuff. The EU is one example.) -- 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 jon at fedoraunity.org Mon May 14 17:44:55 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 14 May 2007 11:44:55 -0600 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <4648A017.7060604@fedoraunity.org> +1 Thank you. Alexander Larsson wrote: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a witless one-eyed Green Beret haunted by an iconic dead American > confidante She's a strong-willed paranoid schoolgirl with an incredible > destiny. They fight crime! > > From sundaram at fedoraproject.org Mon May 14 17:46:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 23:16:02 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179164140.14036.13.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> Message-ID: <4648A05A.9010006@fedoraproject.org> Nicolas Mailhot wrote: > Le lundi 14 mai 2007 ? 21:45 +0530, Rahul Sundaram a ?crit : >> Ralf Corsepius wrote: >>> It's quite simple: You have to agree on a common language (or a limited >>> set of thereof) otherwise you can't communicate with your customers >>> (here: users) and 3rd parties (here: authorities). For a US based >>> distro, I'd expect this language to be English. >> Correct. The license not being readable is a misleading exaggeration but >> the underlying point is valid. We need review guidelines that enforce >> this and bugs should be filed against packages which don't have license >> text in English. > > English is no more blessed than another langage. No but it is a requirement for a legal entity based on US which Fedora via Red Hat is. Official English translations would be required for us to understand and enforce the license. What if a Japanese license including text that says that the software is proprietary? Rahul From ssorce at redhat.com Mon May 14 17:52:04 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 13:52:04 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4648A05A.9010006@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> Message-ID: <1179165125.29833.7.camel@willson> On Mon, 2007-05-14 at 23:16 +0530, Rahul Sundaram wrote: > Nicolas Mailhot wrote: > > Le lundi 14 mai 2007 ? 21:45 +0530, Rahul Sundaram a ?crit : > >> Ralf Corsepius wrote: > >>> It's quite simple: You have to agree on a common language (or a limited > >>> set of thereof) otherwise you can't communicate with your customers > >>> (here: users) and 3rd parties (here: authorities). For a US based > >>> distro, I'd expect this language to be English. > >> Correct. The license not being readable is a misleading exaggeration but > >> the underlying point is valid. We need review guidelines that enforce > >> this and bugs should be filed against packages which don't have license > >> text in English. > > > > English is no more blessed than another langage. > > No but it is a requirement for a legal entity based on US which Fedora > via Red Hat is. Official English translations would be required for us > to understand and enforce the license. > > What if a Japanese license including text that says that the software is > proprietary? Then I guess the burden should be on Fedora in this case. Asking the developer of a package (or a packager) to provide a legally verified translation to English is a bit too much IMO. Simo. From sundaram at fedoraproject.org Mon May 14 17:57:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 23:27:59 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179165125.29833.7.camel@willson> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165125.29833.7.camel@willson> Message-ID: <4648A327.8080309@fedoraproject.org> Simo Sorce wrote: > > Then I guess the burden should be on Fedora in this case. Asking the > developer of a package (or a packager) to provide a legally verified > translation to English is a bit too much IMO. Fedora does not have the legal resources to pursue translations of every new license that people come up. If the developer does not want to have this trouble then they should just adopt more commonly used licenses instead of insisting on more unique licenses that adds to the burden of maintainers, redistributors and increasing the potential for Free software silos. We cannot accept the legal risk of including software under licenses that we don't understand. Rahul From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 14 17:58:07 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 15 May 2007 02:58:07 +0900 Subject: Legality of Fedora in production environment In-Reply-To: <4648A05A.9010006@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> Message-ID: <4648A32F.6060608@ioa.s.u-tokyo.ac.jp> Rahul Sundaram wrote, at 05/15/2007 02:46 AM +9:00: > Nicolas Mailhot wrote: >> Le lundi 14 mai 2007 ? 21:45 +0530, Rahul Sundaram a ?crit : >>> Ralf Corsepius wrote: >>>> It's quite simple: You have to agree on a common language (or a limited >>>> set of thereof) otherwise you can't communicate with your customers >>>> (here: users) and 3rd parties (here: authorities). For a US based >>>> distro, I'd expect this language to be English. >>> Correct. The license not being readable is a misleading exaggeration >>> but the underlying point is valid. We need review guidelines that >>> enforce this and bugs should be filed against packages which don't >>> have license text in English. >> >> English is no more blessed than another langage. > > No but it is a requirement for a legal entity based on US which Fedora > via Red Hat is. Official English translations would be required for us > to understand and enforce the license. The trouble is that while many people cannot judge if the license can be accepted if no translation into English is attached, many people also cannot judge if the *translation itself* is correct...... Actually I have one package in Fedora where translation itself became a problem. More precisely, the license of the software is originally written in Japanese, and the software also has English-translated version. However the content differs in some points and the English-translated version is rejected by debian... I don't write the details any further, but I just note that the license was finally accepted by Callaway. > What if a Japanese license including text that says that the software is > proprietary? So even I translate the license into English, perhaps almost no one can check my translation... Mamoru From i at stingr.net Mon May 14 17:59:18 2007 From: i at stingr.net (Paul P Komkoff Jr) Date: Mon, 14 May 2007 21:59:18 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <20070514153256.GC1097@serv.smile.org.ua> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <46487539.3030701@redhat.com> <20070514153256.GC1097@serv.smile.org.ua> Message-ID: <20070514175918.GC22452@stingr.net> Replying to Andy Shevchenko: > But issue in other words in the corruption. > I mean the Microsoft's software (due to its fee > 0) can be used for money > back (also called "reverts"). Also called "kickbacks". > I try to explain this. > Person A and company C agree to buy some software for company B. Note: A is > a official workers on C. The B write bill with higher price (about 30%). > After C pay to software approx 130% of price the part of that price A and > people from B share between each other. Understandable? You are such an optimist... 30% kickbacks is so 2001... now it's way more :) > The OSS model is not acceptable for this financial tricks. Jokes aside, yes. Because free software is, essentially, free, any person in power of making decisions (on the fixed salary less than $800/mo) don't have any incentive to go for it. Technical arguments don't matter. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From nicolas.mailhot at laposte.net Mon May 14 18:04:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 20:04:13 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648A05A.9010006@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> Message-ID: <1179165853.14036.23.camel@rousalka.dyndns.org> Le lundi 14 mai 2007 ? 23:16 +0530, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: > > Le lundi 14 mai 2007 ? 21:45 +0530, Rahul Sundaram a ?crit : > > English is no more blessed than another langage. > > No but it is a requirement for a legal entity based on US which Fedora > via Red Hat is. Official English translations would be required for us > to understand and enforce the license. And it's the same requirement for legal entities that are not based in the US and are Fedora or RHEL users. Do you think they don't need to check licensing too? > What if a Japanese license including text that says that the software is > proprietary? Then you do the same thing as everyone else - you pay a legally-accredited translator to translate, you don't require a change in the core license. Or you do the sane no-offensive neutral thing - you setup the infrastructure so everyone gets translations. Why do you think the GPL does not include a "litigation must happen in $foo court of $bar city of $baz country" clause? That "good" idea is just a great way to have many people angry at you. Legal code is not software code. It's not english-centric. -- 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 nicolas.mailhot at laposte.net Mon May 14 18:07:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 20:07:00 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648A32F.6060608@ioa.s.u-tokyo.ac.jp> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <4648A32F.6060608@ioa.s.u-tokyo.ac.jp> Message-ID: <1179166020.14036.25.camel@rousalka.dyndns.org> Le mardi 15 mai 2007 ? 02:58 +0900, Mamoru Tasaka a ?crit : > The trouble is that while many people cannot judge if the license can > be accepted if no translation into English is attached, many people > also cannot judge if the *translation itself* is correct...... That's why a legal document can not be translated by just anyone, and certainly not a bunch of hackers who are not native english speakers. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at jdub.homelinux.org Mon May 14 18:11:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 13:11:55 -0500 Subject: Legality of Fedora in production environment In-Reply-To: <1179160407.4735.352.camel@mccallum.corsepiu.local> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <1179159204.19267.23.camel@vader.jdub.homelinux.org> <1179160407.4735.352.camel@mccallum.corsepiu.local> Message-ID: <1179166316.19267.27.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 18:33 +0200, Ralf Corsepius wrote: > > > It's quite simple: You have to agree on a common language (or a limited > > > set of thereof) otherwise you can't communicate with your customers > > > (here: users) and 3rd parties (here: authorities). For a US based > > > distro, I'd expect this language to be English. > > > > > > This would at least enable users to translate it into his native > > > language without major effort. > > > > Aren't you on the Packaging Committee? > Yes, but ... the FPC only deals with questions related to "how to > package" (technical questions) and not with political issues (What to > package and what not) rsp. legal issues (Which licenses are considered > valid.) > > In my understanding, the "what" is FESCO's job, the "legal" is GdK's > job. You seem to have a good understanding of the issue. There are no rules that say you can't write a guideline up for submission. And I personally think something like this will need to go into the Packaging guidelines anyway, so it can start in the FPC. josh From sundaram at fedoraproject.org Mon May 14 18:13:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 23:43:22 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179165853.14036.23.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> Message-ID: <4648A6C2.8000204@fedoraproject.org> Nicolas Mailhot wrote: > And it's the same requirement for legal entities that are not based in > the US and are Fedora or RHEL users. Do you think they don't need to > check licensing too? Sure they do. From the Fedora legal perspective what legal entities outside of US do is none of our concern. > Then you do the same thing as everyone else - you pay a > legally-accredited translator to translate, you don't require a change > in the core license. I didn't require a change to the core license. Who told you I was? What I wanted was a official translation. That's the minimum we need to ensure that we don't include software under licenses don't understand or not enforceable. I am just not sure we have the legal and financial resources to pay for translations every time we include new software under regional licenses that people cook up. It's time to get back to Red Hat legal and asked for their opinion I guess. Rahul From ssorce at redhat.com Mon May 14 18:25:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 14:25:27 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4648A327.8080309@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165125.29833.7.camel@willson> <4648A327.8080309@fedoraproject.org> Message-ID: <1179167128.29833.13.camel@willson> On Mon, 2007-05-14 at 23:27 +0530, Rahul Sundaram wrote: > Simo Sorce wrote: > > > > > Then I guess the burden should be on Fedora in this case. Asking the > > developer of a package (or a packager) to provide a legally verified > > translation to English is a bit too much IMO. > > Fedora does not have the legal resources to pursue translations of every > new license that people come up. If the developer does not want to have > this trouble then they should just adopt more commonly used licenses > instead of insisting on more unique licenses that adds to the burden of > maintainers, redistributors and increasing the potential for Free > software silos. > > We cannot accept the legal risk of including software under licenses > that we don't understand. I guess Fedora can set up a rule for which software that do not have the binding license in English cannot be accepted. But I don't think you will please developers of other countries. I think a compromises should be attempted. Simo. From nicolas.mailhot at laposte.net Mon May 14 18:26:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 20:26:56 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648A6C2.8000204@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> Message-ID: <1179167216.14036.36.camel@rousalka.dyndns.org> Le lundi 14 mai 2007 ? 23:43 +0530, Rahul Sundaram a ?crit : > I am just not sure we have the legal and financial resources to pay for > translations every time we include new software under regional licenses > that people cook up. Why to you think you can trust just any random translation? Can as well process licenses through the fish. I'd have thought all the soap opera around the meaning of Free in English (which speakers of other langages watch with horror) would have taught people some caution. The process should probably start with review by local FSF chapters, then production of authoritative translations if the license checks, then bundling of those translations (not limited to English) in a license package. -- 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 sundaram at fedoraproject.org Mon May 14 18:28:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 23:58:30 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179167216.14036.36.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> Message-ID: <4648AA4E.7030505@fedoraproject.org> Nicolas Mailhot wrote: > Le lundi 14 mai 2007 ? 23:43 +0530, Rahul Sundaram a ?crit : > >> I am just not sure we have the legal and financial resources to pay for >> translations every time we include new software under regional licenses >> that people cook up. > > Why to you think you can trust just any random translation? Can as well > process licenses through the fish. Again, I said official translation. Did you even bother reading what you are responding to? Rahul From ssorce at redhat.com Mon May 14 18:38:35 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 14:38:35 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4648AA4E.7030505@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> Message-ID: <1179167916.29833.19.camel@willson> On Mon, 2007-05-14 at 23:58 +0530, Rahul Sundaram wrote: > Nicolas Mailhot wrote: > > Le lundi 14 mai 2007 ? 23:43 +0530, Rahul Sundaram a ?crit : > > > >> I am just not sure we have the legal and financial resources to pay for > >> translations every time we include new software under regional licenses > >> that people cook up. > > > > Why to you think you can trust just any random translation? Can as well > > process licenses through the fish. > > Again, I said official translation. Did you even bother reading what you > are responding to? The problem is in who can produce these translations. You can't force upstream, also because it may just cost to much for Joe casual developer, or for any other reason. If the packages is good enough and worth including in Fedora and a local FS savvy person can tell that the license is not crap, than I guess you have enough filters to be willing to see if someone can sponsor a legal translation for Fedora's organization records. After all it is Fedora that have a problem with a foreign language license not the upstream distributor. Simo. From nicolas.mailhot at laposte.net Mon May 14 18:38:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 20:38:43 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648AA4E.7030505@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> Message-ID: <1179167923.14036.43.camel@rousalka.dyndns.org> Le lundi 14 mai 2007 ? 23:58 +0530, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: > > Le lundi 14 mai 2007 ? 23:43 +0530, Rahul Sundaram a ?crit : > > > >> I am just not sure we have the legal and financial resources to pay for > >> translations every time we include new software under regional licenses > >> that people cook up. > > > > Why to you think you can trust just any random translation? Can as well > > process licenses through the fish. > > Again, I said official translation. Did you even bother reading what you > are responding to? Official meaning what? If it's official as in legally binding wise upstreams will refuse to commit to a document in a langage they don't master (even the FSF is careful enough to point out there is a single binding document, the english one) If it's official as in "produced by the original hacker but not legally binding" the fish may be just as good for a legal analysis by Fedora. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Mon May 14 18:37:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 14:37:49 -0400 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> Message-ID: <20070514183749.GN5267@nostromo.devel.redhat.com> Jerry James (Jerry.James at usu.edu) said: > What I was trying to accomplish was splitting out related, but different > languages, which were packaged together in earlier versions of moodle. > (They are packaged in separate source files upstream.) So the current > spec file has this, for example: Note that for things like comps, there is only one languge support group per language (Chinese, Serbian, etc.); so leaving them together probably won't hurt. Bill From notting at redhat.com Mon May 14 18:40:15 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 14:40:15 -0400 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179075965.19106.1.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> Message-ID: <20070514184015.GO5267@nostromo.devel.redhat.com> Arjan van de Ven (arjan at fenrus.demon.nl) said: > I've gotten this request a few times now; I'll be looking into this for > version 2.0; I'd think it would be possible with blktrace but I need to > look into the details (don't want this tracing to spoil any other > measurements ;) Note that we don't ship blktrace at the moment in Fedora. Bill From sundaram at fedoraproject.org Mon May 14 18:45:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 00:15:16 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179167923.14036.43.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> Message-ID: <4648AE3C.8020802@fedoraproject.org> Nicolas Mailhot wrote: > > Official meaning what? From upstream. Next time do read my mails completely before responding and avoid making assumptions about what I am conveying. > If it's official as in legally binding wise upstreams will refuse to > commit to a document in a langage they don't master This is just your assumption. They might. They might not. If they do, well and good. If not, we might choose to just block that on review. There might be possible compromises which doesn't affect us legally. We need to ask Red Hat legal that. Rahul From wtogami at redhat.com Mon May 14 18:52:47 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 14 May 2007 14:52:47 -0400 Subject: Wireless Testing Needed for F7 Message-ID: <4648AFFF.80906@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 We are attempting to get wireless working on x86_64. http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ If you use wireless on ANY arch of rawhide, please test this latest wireless-tools build. We need to be sure that the x86_64 fix doesn't break i386 or ppc*. Please report in the above bug if release -3 is any better or worse than release -1 or -2. We really would like to confirm this before the proposed F7 final freeze on Thursday. Warren Togami wtogami at redhat.com From sundaram at fedoraproject.org Mon May 14 18:58:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 00:28:39 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <464810C4.70309@redhat.com> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <464810C4.70309@redhat.com> Message-ID: <4648B15F.8080809@fedoraproject.org> Benjamin Kosnik wrote: > > Hey dudes. > > You'll find an A4-sized certificate, based on the Fedora EULA, and an > A9-sized certificate of authenticity here: > > http://people.redhat.com/bkoz/fedora_certificates/ Note that this EULA requires modifications for Fedora 7 release. We need to replace all occurrences of "Fedora Core" with "Fedora" and add a section on firmware. Rahul From nicolas.mailhot at laposte.net Mon May 14 19:11:30 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 21:11:30 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648AE3C.8020802@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> Message-ID: <1179169890.14036.54.camel@rousalka.dyndns.org> Le mardi 15 mai 2007 ? 00:15 +0530, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: > > Official meaning what? > > From upstream. Which does not mean it has more than incidental legal value (courts will wisely refuse to consider any translation but the one done by an accredited expert except if the "from upstream" translation is an actual binding legal doc) Even if you manage to get people to commit to a legal document in a foreign tongue and offload the translation risk the PR fallout in case of conflict is going to be ugly. > Next time do read my mails completely before responding > and avoid making assumptions about what I am conveying. Pot. Kettle -- 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 lsof at nodata.co.uk Mon May 14 19:28:07 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 14 May 2007 21:28:07 +0200 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <1179170887.3250.5.camel@sb-home> Am Montag, den 14.05.2007, 16:58 +0200 schrieb Alexander Larsson: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a witless one-eyed Green Beret haunted by an iconic dead American > confidante She's a strong-willed paranoid schoolgirl with an incredible > destiny. They fight crime! > Please can you also disable the firefox plugin if you do this. From sundaram at fedoraproject.org Mon May 14 19:29:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 00:59:20 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179169890.14036.54.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> Message-ID: <4648B890.8080703@fedoraproject.org> Nicolas Mailhot wrote: > Even if you manage to get people to commit to a legal document in a > foreign tongue and offload the translation risk the PR fallout in case > of conflict is going to be ugly. Legal risk is different from PR risk. We shouldn't mix them. >> Next time do read my mails completely before responding >> and avoid making assumptions about what I am conveying. > > Pot. Kettle I didn't assume anything about what you said while you clearly did assume that I was asking to replace the core license or that I was going to advocate for random translations. Rahul From wtogami at redhat.com Mon May 14 19:29:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 14 May 2007 15:29:53 -0400 Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php Message-ID: <4648B8B1.3030701@redhat.com> Aside from the kernel module packages, these are the packages in rawhide as of May 12th with broken deps. Please get these fixed before Thursday's final F7 freeze. http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Follow the procedure here to get a build included in F7. package: gaim-gaym - 0.96-3.7.293svn.fc7.x86_64 from development unresolved deps: libgaim.so.0()(64bit) gaim < 2:3.0.0 package: php-eaccelerator - 5.2.1_0.9.5-1.fc7.x86_64 from development unresolved deps: php-common = 0:5.2.1 package: redhat-artwork-kde - 7.0.0-4.fc7.x86_64 from development unresolved deps: redhat-artwork = 0:%{epoch}:7.0.0-4.fc7 package: syck-php - 0.55-14.fc7.x86_64 from development unresolved deps: php = 0:5.2.1 Warren Togami wtogami at redhat.com From nicolas.mailhot at laposte.net Mon May 14 19:41:02 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 May 2007 21:41:02 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648B890.8080703@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <1178901826.4735.178.camel@mccallum.corsepiu.local> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> Message-ID: <1179171662.5930.5.camel@rousalka.dyndns.org> Le mardi 15 mai 2007 ? 00:59 +0530, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: > > > Even if you manage to get people to commit to a legal document in a > > foreign tongue and offload the translation risk the PR fallout in case > > of conflict is going to be ugly. > > Legal risk is different from PR risk. We shouldn't mix them. Even in this case you'll probably get both. > >> Next time do read my mails completely before responding > >> and avoid making assumptions about what I am conveying. > > > > Pot. Kettle > > I didn't assume anything about what you said while you clearly did > assume that I was asking to replace the core license or that I was going > to advocate for random translations. And exactly how a software project (composed mainly of people that chose tech over literature or law) and chose a license in its own language (presumably because they didn't feel confortable with English) is going to produce anything but a random translation? Especially if you tell them it's not binding? -- 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 sundaram at fedoraproject.org Mon May 14 19:52:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 01:22:40 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179171662.5930.5.camel@rousalka.dyndns.org> References: <46446924.1080209@odu.neva.ru> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> <1179171662.5930.5.camel@rousalka.dyndns.org> Message-ID: <4648BE08.5010104@fedoraproject.org> Nicolas Mailhot wrote: > Le mardi 15 mai 2007 ? 00:59 +0530, Rahul Sundaram a ?crit : >> Nicolas Mailhot wrote: >> >>> Even if you manage to get people to commit to a legal document in a >>> foreign tongue and offload the translation risk the PR fallout in case >>> of conflict is going to be ugly. >> Legal risk is different from PR risk. We shouldn't mix them. > > Even in this case you'll probably get both. It is probably going to rain tomorrow too. > And exactly how a software project (composed mainly of people that chose > tech over literature or law) and chose a license in its own language > (presumably because they didn't feel confortable with English) is going > to produce anything but a random translation? Especially if you tell > them it's not binding? How exactly are people who choose technology over literature or law even going to write a proper license in their own language? If you want good licenses in any language you need to talk to a lawyer. So that's the process they need to follow. Rahul From jkeating at redhat.com Mon May 14 20:14:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 16:14:48 -0400 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <200705141614.51678.jkeating@redhat.com> On Monday 14 May 2007 10:58:11 Alexander Larsson wrote: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. The Release Team discussed this today and agreed with your proposal with the following addition. The beagle package set will be added to the manifest for the 'Fedora' spin of Fedora 7. This will help folks upgrading from Fedora Core 6 that may have beagle installed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Mon May 14 20:16:28 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 16:16:28 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4648BE08.5010104@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <1178907377.29429.92.camel@zod.rchland.ibm.com> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> <1179171662.5930.5.camel@rousalka.dyndns.org> <4648BE08.5010104@fedoraproject.org> Message-ID: <1179173789.29833.27.camel@willson> On Tue, 2007-05-15 at 01:22 +0530, Rahul Sundaram wrote: > Nicolas Mailhot wrote: > > Le mardi 15 mai 2007 ? 00:59 +0530, Rahul Sundaram a ?crit : > >> Nicolas Mailhot wrote: > >> > >>> Even if you manage to get people to commit to a legal document in a > >>> foreign tongue and offload the translation risk the PR fallout in case > >>> of conflict is going to be ugly. > >> Legal risk is different from PR risk. We shouldn't mix them. > > > > Even in this case you'll probably get both. > > It is probably going to rain tomorrow too. > > > And exactly how a software project (composed mainly of people that chose > > tech over literature or law) and chose a license in its own language > > (presumably because they didn't feel confortable with English) is going > > to produce anything but a random translation? Especially if you tell > > them it's not binding? > > How exactly are people who choose technology over literature or law even > going to write a proper license in their own language? If you want good > licenses in any language you need to talk to a lawyer. So that's the > process they need to follow. Yet this is different then having a legal translation in English. You need a lawyer that master English and knows how to express legal concept in English but presumably related to local laws. This is not something you can find easily in many places. Lawyers do not need to master any other language but their own usually. Or, you need a lawyer that Master both English and your language and also knows about a different law system as well as his own, which is _rare_. There are cases where you cannot reasonably ask upstream to provide a legally binding translated license (I'd say most of the cases). Now you can, of course , ask them to trust licenses written for US Common Law and let them hope they apply cleanly in their legal system. But then, they have all the rights to decline the request. Simo. From sundaram at fedoraproject.org Mon May 14 20:18:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 01:48:47 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179173789.29833.27.camel@willson> References: <46446924.1080209@odu.neva.ru> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> <1179171662.5930.5.camel@rousalka.dyndns.org> <4648BE08.5010104@fedoraproject.org> <1179173789.29833.27.camel@willson> Message-ID: <4648C427.2040809@fedoraproject.org> Simo Sorce wrote: > > Now you can, of course , ask them to trust licenses written for US > Common Law and let them hope they apply cleanly in their legal system. > But then, they have all the rights to decline the request. Right. We then decline to include their software in Fedora. Do you see another way to deal with this without involving Red Hat legal? Rahul From ssorce at redhat.com Mon May 14 20:29:12 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 May 2007 16:29:12 -0400 Subject: Legality of Fedora in production environment In-Reply-To: <4648C427.2040809@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <1179035699.4735.207.camel@mccallum.corsepiu.local> <1179056562.17555.38.camel@vader.jdub.homelinux.org> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> <1179171662.5930.5.camel@rousalka.dyndns.org> <4648BE08.5010104@fedoraproject.org> <1179173789.29833.27.camel@willson> <4648C427.2040809@fedoraproject.org> Message-ID: <1179174552.29833.34.camel@willson> On Tue, 2007-05-15 at 01:48 +0530, Rahul Sundaram wrote: > Simo Sorce wrote: > > > > > Now you can, of course , ask them to trust licenses written for US > > Common Law and let them hope they apply cleanly in their legal system. > > But then, they have all the rights to decline the request. > > Right. We then decline to include their software in Fedora. Do you see > another way to deal with this without involving Red Hat legal? We shouldn't abuse Red Hat legal, but discarding the option a priori seem a bit hard to me. What you are implying is that Fedora is an "English" only distribution. Well, while I have no problems with English, this seem a bit discriminatory and I don't like it. I think we can be more pragmatic and be open, and deal with each issue when it comes up. If, and when, the number of packages with foreign language licenses will be too high, then we can reopen the discussion and see if there are more creative ideas on how to solve this issue. Simo. From jkeating at redhat.com Mon May 14 20:32:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 16:32:17 -0400 Subject: Making beagle optional In-Reply-To: <200705141614.51678.jkeating@redhat.com> References: <1179154692.3560.23.camel@localhost.localdomain> <200705141614.51678.jkeating@redhat.com> Message-ID: <200705141632.18242.jkeating@redhat.com> On Monday 14 May 2007 16:14:48 Jesse Keating wrote: > The beagle package set will be added to the manifest for the 'Fedora' spin > of Fedora 7. ?This will help folks upgrading from Fedora Core 6 that may > have beagle installed. To clarify, this will make the beagle packages available on the Fedora spin isos, but still only optional packages. They will be available for the upgrade case, and users would have to click on them specifically in the package selection screen to get them on the install case. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon May 14 20:36:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 02:06:44 +0530 Subject: Legality of Fedora in production environment In-Reply-To: <1179174552.29833.34.camel@willson> References: <46446924.1080209@odu.neva.ru> <1179114907.4735.221.camel@mccallum.corsepiu.local> <1179143015.19267.6.camel@vader.jdub.homelinux.org> <1179153263.4735.331.camel@mccallum.corsepiu.local> <1179158196.19267.20.camel@vader.jdub.homelinux.org> <1179158985.4735.348.camel@mccallum.corsepiu.local> <46488B35.7010202@fedoraproject.org> <1179164140.14036.13.camel@rousalka.dyndns.org> <4648A05A.9010006@fedoraproject.org> <1179165853.14036.23.camel@rousalka.dyndns.org> <4648A6C2.8000204@fedoraproject.org> <1179167216.14036.36.camel@rousalka.dyndns.org> <4648AA4E.7030505@fedoraproject.org> <1179167923.14036.43.camel@rousalka.dyndns.org> <4648AE3C.8020802@fedoraproject.org> <1179169890.14036.54.camel@rousalka.dyndns.org> <4648B890.8080703@fedoraproject.org> <1179171662.5930.5.camel@rousalka.dyndns.org> <4648BE08.5010104@fedoraproject.org> <1179173789.29833.27.camel@willson> <4648C427.2040809@fedoraproject.org> <1179174552.29833.34.camel@willson> Message-ID: <4648C85C.4060901@fedoraproject.org> Simo Sorce wrote: > On Tue, 2007-05-15 at 01:48 +0530, Rahul Sundaram wrote: >> Simo Sorce wrote: >> >>> Now you can, of course , ask them to trust licenses written for US >>> Common Law and let them hope they apply cleanly in their legal system. >>> But then, they have all the rights to decline the request. >> Right. We then decline to include their software in Fedora. Do you see >> another way to deal with this without involving Red Hat legal? > > We shouldn't abuse Red Hat legal, but discarding the option a priori > seem a bit hard to me. > What you are implying is that Fedora is an "English" only distribution. > Well, while I have no problems with English, this seem a bit > discriminatory and I don't like it. Nope. I have been a translator before myself. That's far from what I am saying. What I am saying that is the Red Hat is a US based legal entity for Fedora and English is mandated as the language for legal communication in that region. Even having a single software in a license that we can't understand legally is not good for us to enforce anything or avoid risks. It is not a question of pragmatism, discrimination of openness. Rahul From mschwendt.tmp0701.nospam at arcor.de Mon May 14 20:42:27 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 14 May 2007 22:42:27 +0200 Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php In-Reply-To: <4648B8B1.3030701@redhat.com> References: <4648B8B1.3030701@redhat.com> Message-ID: <20070514224227.86a88b9a.mschwendt.tmp0701.nospam@arcor.de> On Mon, 14 May 2007 15:29:53 -0400, Warren Togami wrote: > Aside from the kernel module packages, these are the packages in rawhide > as of May 12th with broken deps. Please get these fixed before > Thursday's final F7 freeze. > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > Follow the procedure here to get a build included in F7. Reconfigured Extras repoclosure adds: source rpm: glest-data-2.0.0-2.fc7.src.rpm package: glest-data - 2.0.0-2.fc7.noarch from fedora-development-ppc unresolved deps: glest = 0:2.0.0 [also for ppc64, glest is only available for i386/x86_64] source rpm: cdrtools-2.01-11.fc7.src.rpm package: cdrecord-devel - 9:2.01-11.fc7 from fedora-development-all unresolved deps: cdrecord = 9:2.01-11.fc7 From jkeating at redhat.com Mon May 14 20:41:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 16:41:19 -0400 Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php In-Reply-To: <20070514224227.86a88b9a.mschwendt.tmp0701.nospam@arcor.de> References: <4648B8B1.3030701@redhat.com> <20070514224227.86a88b9a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200705141641.19447.jkeating@redhat.com> On Monday 14 May 2007 16:42:27 Michael Schwendt wrote: > source rpm: cdrtools-2.01-11.fc7.src.rpm > package: cdrecord-devel - 9:2.01-11.fc7 from fedora-development-all > ? unresolved deps: > ? ? ?cdrecord = 9:2.01-11.fc7 cdrtools has been blocked from the distribution, cdrkit is taking over. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pemboa at gmail.com Mon May 14 20:59:17 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 14 May 2007 16:59:17 -0400 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> On 5/14/07, Alexander Larsson wrote: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. > Thank you my good sir. I hated that thing. -- Fedora Core 6 and proud From johan at x-tnd.be Mon May 14 20:59:45 2007 From: johan at x-tnd.be (Johan Cwiklinski) Date: Mon, 14 May 2007 22:59:45 +0200 Subject: Duplicate files - Kickoff RPM - KDE In-Reply-To: References: <4646EF86.4030602@x-tnd.be> Message-ID: <4648CDC1.3000308@x-tnd.be> Rex Dieter a ?crit : > Johan Cwiklinski wrote: > > >> I've told one of the developers about this problem, who said me to try >> to install only "kicker/" and "kcontrol/kicker/" subdirs ; but I don't >> have any idea how to achieve this properly. >> > > (Haven't tried, but hopefully): > Replace: > unsermake install DESTDIR=$RPM_BUILD_ROOT > with > (cd kcontrol/kicker ; unsermake install DESTDIR=$RPM_BUILD_ROOT ) > (cd kicker/ ; unsermake install DESTDIR=$RPM_BUILD_ROOT ) > > and adjust %files accordingly. > > -- Rex > > It seems to do the job :) Thanks Rex :) Johan From mcepl at redhat.com Mon May 14 20:48:49 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 14 May 2007 22:48:49 +0200 Subject: Legality of Fedora in production environment References: <46446924.1080209@odu.neva.ru> Message-ID: On 2007-05-14, 18:13 GMT, Rahul Sundaram wrote: > I didn't require a change to the core license. Who told you > I was? What I wanted was a official translation. That's the > minimum we need to ensure that we don't include software under > licenses don't understand or not enforceable. If you mean by official translation, a piece of paper which would have the same legal relevance as the English original, then it is really bad idea. There is a reason why commercial contracts are almost never bilingual, but only the original version is given legal status, and all translations are for information purposes only (except for agreeements among countries, where negotiators rely on the hope that their terms in office will expire sooner, then the shooting begins ;-)). Moreover, of course, what is a binding contract in one country, doesn't have to be the one in other (e.g., until the last summer, all shrinkp-wrap and internet-wrap licenses were void and unenforceable under the Czech law, and I believe it is true in most of the countries in the Europe). And GPL et all for information purposes only is available in many places and in many languages. Best, Matej From hondaman at gmail.com Mon May 14 22:02:40 2007 From: hondaman at gmail.com (hondaman) Date: Mon, 14 May 2007 17:02:40 -0500 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels Message-ID: <9bec46470705141502q5d467dch4a80307e146192bb@mail.gmail.com> Bought a new toshiba p105-s9337 yesterday using the 3945ABG wireless (rev 02), and now find myself here. Dave's .3149 kernel was the first that was able to let me at least try and connect to an AP in NetworkManager. Any previous kernel, and it simply wasnt an option, like my wireless didnt exist. I wasnt able to connect to the AP yet, as I encountered a crash. After I tried to create a new wireless network and failed, I then tried the (whats the other wireless option, join existing? I cant remember, the option isnt there anymore) other wireless option in NetworkManager, and crashed. Sent the bug report, rebooted, and now my wireless again doesnt appear. Only wired as an option. selinux is off, using x86-64 -- "Do you know about the dangers of DRM? Find out at http://www.defectivebydesign.org/what_is_drm" -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsof at nodata.co.uk Mon May 14 22:03:21 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 15 May 2007 00:03:21 +0200 Subject: Making beagle optional In-Reply-To: <1179154692.3560.23.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <1179180201.4627.50.camel@sb-home> Am Montag, den 14.05.2007, 16:58 +0200 schrieb Alexander Larsson: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but > bugs keep on showing up causing the search daemon to use a lot of cpu > and/or memory, and this makes the default install look pretty bad. > > This is somewhat of a feature regression in the default install, but at > this point we just don't have the manpower to make it work 100%. But if > people want it its still there, and eventually it'll be good enought to > turn on by default without affecting the general distro quality. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a witless one-eyed Green Beret haunted by an iconic dead American > confidante She's a strong-willed paranoid schoolgirl with an incredible > destiny. They fight crime! > Does this mean the Places> Search option in the menu, will return to searching for files that match given criteria? From austinf at cetoncorp.com Mon May 14 22:19:09 2007 From: austinf at cetoncorp.com (Austin Foxley) Date: Mon, 14 May 2007 15:19:09 -0700 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <9bec46470705141502q5d467dch4a80307e146192bb@mail.gmail.com> References: <9bec46470705141502q5d467dch4a80307e146192bb@mail.gmail.com> Message-ID: <4648E05D.1020308@cetoncorp.com> hondaman wrote: > After I tried to create a new wireless network and failed, I then tried the > (whats the other wireless option, join existing? I cant remember, the > option isnt there anymore) other wireless option in NetworkManager, and > crashed. Sent the bug report, rebooted, and now my wireless again doesnt > appear. Only wired as an option. > selinux is off, using x86-64 Did you try the new wireless-tools build at: http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ -- Austin Foxley Ceton Corporation http://www.cetoncorp.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Mon May 14 22:32:34 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 May 2007 22:32:34 +0000 (UTC) Subject: I miss the old artwork References: Message-ID: Neal Becker gmail.com> writes: > FC7 has some nice, new artwork - but I really still like the FC6 version. I > hope it will still be available. At least the FedoraDNA KDM theme is still installed (but not enabled, the new default is FedoraFlyingHigh) by default as part of redhat-artwork-kde. Kevin Kofler From jburgess777 at googlemail.com Mon May 14 22:39:31 2007 From: jburgess777 at googlemail.com (Jon Burgess) Date: Mon, 14 May 2007 23:39:31 +0100 Subject: I miss the old artwork In-Reply-To: References: Message-ID: <1179182371.23409.172.camel@localhost.localdomain> On Mon, 2007-05-14 at 22:32 +0000, Kevin Kofler wrote: > Neal Becker gmail.com> writes: > > FC7 has some nice, new artwork - but I really still like the FC6 version. I > > hope it will still be available. > > At least the FedoraDNA KDM theme is still installed (but not enabled, the new > default is FedoraFlyingHigh) by default as part of redhat-artwork-kde. > > Kevin Kofler > Is this broken? [root at shark ~]# yum install redhat-artwork-kde Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package redhat-artwork-kde.x86_64 0:7.0.0-4.fc7 set to be updated --> Processing Dependency: redhat-artwork = %{epoch}:7.0.0-4.fc7 for package: redhat-artwork-kde --> Finished Dependency Resolution Error: Missing Dependency: redhat-artwork = %{epoch}:7.0.0-4.fc7 is needed by package redhat-artwork-kde [root at shark ~]# rpm -q redhat-artwork redhat-artwork-7.0.0-4.fc7 redhat-artwork-7.0.0-4.fc7 Jon From kevin.kofler at chello.at Mon May 14 22:40:27 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 May 2007 22:40:27 +0000 (UTC) Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php References: <4648B8B1.3030701@redhat.com> Message-ID: Warren Togami redhat.com> writes: > package: redhat-artwork-kde - 7.0.0-4.fc7.x86_64 from development > unresolved deps: > redhat-artwork = 0:%{epoch}:7.0.0-4.fc7 This one is trivial to fix, see #240017 (just remove the "%{epoch}:"), but I can't do it because this is now built from the redhat-artwork SRPM which I don't have write access to. So one of the following people (account names straight out of pkg.acl) will have to fix it: ajax alexl behdad caillon caolanm cworth davidz hadess johnp jrb krh mbarnes mclasen rhughes rnorwood rstrode ssp xiphmont I hope this gets fixed quickly because at least the KDE live CD is broken by this. It's already marked FC7Blocker. Kevin Kofler From david at lovesunix.net Mon May 14 22:44:16 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 15 May 2007 00:44:16 +0200 Subject: Making beagle optional In-Reply-To: <1179180201.4627.50.camel@sb-home> References: <1179154692.3560.23.camel@localhost.localdomain> <1179180201.4627.50.camel@sb-home> Message-ID: <1179182656.28960.36.camel@dawkins> tir, 15 05 2007 kl. 00:03 +0200, skrev nodata: > > Does this mean the Places> Search option in the menu, will return to > searching for files that match given criteria? Good question if we install it, then the deamon gets starts so far as we replace the search tool.. thus bringing back the suckage. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From kevin.kofler at chello.at Mon May 14 22:42:50 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 May 2007 22:42:50 +0000 (UTC) Subject: I miss the old artwork References: <1179182371.23409.172.camel@localhost.localdomain> Message-ID: Jon Burgess googlemail.com> writes: > Is this broken? > Error: Missing Dependency: redhat-artwork = %{epoch}:7.0.0-4.fc7 is > needed by package redhat-artwork-kde Yes, it is, see the "broken deps" thread. Kevin Kofler From david at lovesunix.net Mon May 14 22:55:17 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 15 May 2007 00:55:17 +0200 Subject: Making beagle optional In-Reply-To: <1179182656.28960.36.camel@dawkins> References: <1179154692.3560.23.camel@localhost.localdomain> <1179180201.4627.50.camel@sb-home> <1179182656.28960.36.camel@dawkins> Message-ID: <1179183317.28960.40.camel@dawkins> tir, 15 05 2007 kl. 00:44 +0200, skrev David Nielsen: > tir, 15 05 2007 kl. 00:03 +0200, skrev nodata: > > > > Does this mean the Places> Search option in the menu, will return to > > searching for files that match given criteria? > > Good question if we install it, then the deamon gets starts so far as we > replace the search tool.. thus bringing back the suckage. Wow.. that came out wrong.. See what happens when I celebrate bugs going away. If we ship with the beagle search tool, it will ask to start the deamon and thus suckage is back. It would likely be a good idea to bring back the official gnome search tool. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From ajackson at redhat.com Mon May 14 23:04:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 14 May 2007 19:04:39 -0400 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1178203980.2733.18.camel@hughsie-laptop> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178201382.16280.3.camel@localhost.localdomain> <1178203980.2733.18.camel@hughsie-laptop> Message-ID: <1179183879.24664.62.camel@localhost.localdomain> On Thu, 2007-05-03 at 15:53 +0100, Richard Hughes wrote: > On Thu, 2007-05-03 at 10:09 -0400, Adam Jackson wrote: > > Could certainly deliver it as a different binary RPM. This is like > > five minutes of work, if we think it's worth doing. > > Yes, PLEASE PRETTY PLEASE. :-) I can then rebuild daily snapshots of > nouveau ddx automatically without playing about with the nv RPM. This is done now as of 2.0.2-2. BIG FREAKING WARNING: If you're using nouveau, and for some reason decide to upgrade just xorg-x11-drv-nv, you will lose your driver. Plain yum upgrade should work though, as xorg-x11-drivers has been updated to depend on xorg-x11-drv-nouveau. - ajax From jensk.maps at gmail.com Mon May 14 23:11:19 2007 From: jensk.maps at gmail.com (Jens Knutson) Date: Mon, 14 May 2007 18:11:19 -0500 Subject: Making beagle optional In-Reply-To: <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> Message-ID: <1179184279.3478.9.camel@daemon> On Mon, 2007-05-14 at 16:59 -0400, Arthur Pemberton wrote: > On 5/14/07, Alexander Larsson wrote: > > I just commited a change to comps which makes beagle optional instead of > > installed by default. The idea with beagle (and tracker) is nice, but > > bugs keep on showing up causing the search daemon to use a lot of cpu > > and/or memory, and this makes the default install look pretty bad. > > > > This is somewhat of a feature regression in the default install, but at > > this point we just don't have the manpower to make it work 100%. But if > > people want it its still there, and eventually it'll be good enought to > > turn on by default without affecting the general distro quality. > > Thank you my good sir. I hated that thing. I'm personally really disappointed that Beagle's no longer in the default install. This isn't to rag on Alex, or to even disagree with him - if it's causing bugs like this, then I understand why this had to be done, at least for now. But Beagle's a great tool - I use it *daily*, and while it's no problem for me to simply add it back into my package set, it's too bad that new users won't have Beagle's great features out of the box. I hope that this can be re-evaluated for F8! - Jens Knutson (Preemptive note to Tracker fanboys: I tried Tracker for a few days and disabled Beagle. At the end of my testing, I very happily re-enabled Beagle and removed Tracker completely - Tracker's not a /fraction/ as useful, Beagle doesn't use much CPU on my system, and RAM usage is hardly a concern - memory is CHEAP.) From david at lovesunix.net Mon May 14 23:33:19 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 15 May 2007 01:33:19 +0200 Subject: Making beagle optional In-Reply-To: <1179184279.3478.9.camel@daemon> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> Message-ID: <1179185599.28960.46.camel@dawkins> man, 14 05 2007 kl. 18:11 -0500, skrev Jens Knutson: > On Mon, 2007-05-14 at 16:59 -0400, Arthur Pemberton wrote: > > On 5/14/07, Alexander Larsson wrote: > > > I just commited a change to comps which makes beagle optional instead of > > > installed by default. The idea with beagle (and tracker) is nice, but > > > bugs keep on showing up causing the search daemon to use a lot of cpu > > > and/or memory, and this makes the default install look pretty bad. > > > > > > This is somewhat of a feature regression in the default install, but at > > > this point we just don't have the manpower to make it work 100%. But if > > > people want it its still there, and eventually it'll be good enought to > > > turn on by default without affecting the general distro quality. > > > > Thank you my good sir. I hated that thing. > > I'm personally really disappointed that Beagle's no longer in the > default install. This isn't to rag on Alex, or to even disagree with > him - if it's causing bugs like this, then I understand why this had to > be done, at least for now. But Beagle's a great tool - I use it > *daily*, and while it's no problem for me to simply add it back into my > package set, it's too bad that new users won't have Beagle's great > features out of the box. > > I hope that this can be re-evaluated for F8! The main problem really is that every release seems to fix a bug like this and uncover a new one, if enough testing is done in the F8 cycle then I'm sure the functionality alone is enough to bring it back. I think it might be good if someone started helping Alex with beagle maintainership so we could ensure quick pushes of new updates as bugs are fixed. That would aid a lot as upstream fixes their issues. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From hondaman at gmail.com Mon May 14 23:53:44 2007 From: hondaman at gmail.com (hondaman) Date: Mon, 14 May 2007 18:53:44 -0500 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <4648E05D.1020308@cetoncorp.com> References: <9bec46470705141502q5d467dch4a80307e146192bb@mail.gmail.com> <4648E05D.1020308@cetoncorp.com> Message-ID: <9bec46470705141653i513f6cc0m7aa460343383604d@mail.gmail.com> I just did, at your suggestion. Rebooted, and I still dont have a wireless option in NetworkManager Checked the logs, and the only thing that might be abnormal is this: May 14 18:49:56 hondalap2 NetworkManager: Updating allowed wireless network lists. May 14 18:49:56 hondalap2 NetworkManager: nm_dbus_get_networks_cb(): error received: org.freedesktop.NetworkManagerInfo.NoNetworks - There are no wireless networks stored.. May 14 18:50:00 hondalap2 setroubleshoot: [rpc.ERROR] attempt to open server connection failed: (2, 'No such file or directory') May 14 18:50:06 hondalap2 NetworkManager: Disconnected. On 5/14/07, Austin Foxley wrote: > > hondaman wrote: > > After I tried to create a new wireless network and failed, I then tried > the > > (whats the other wireless option, join existing? I cant remember, the > > option isnt there anymore) other wireless option in NetworkManager, and > > crashed. Sent the bug report, rebooted, and now my wireless again > doesnt > > appear. Only wired as an option. > > > selinux is off, using x86-64 > > Did you try the new wireless-tools build at: > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > > -- > Austin Foxley > Ceton Corporation > http://www.cetoncorp.com > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- "Do you know about the dangers of DRM? Find out at http://www.defectivebydesign.org/what_is_drm" -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiva at sewingwitch.com Tue May 15 00:13:50 2007 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 14 May 2007 17:13:50 -0700 Subject: CD version gone? In-Reply-To: <6280325c0705111932l713742e6i4923619b07c1008d@mail.gmail.com> References: <6280325c0705010320n26678f7dt41218ef9a549bdcc@mail.gmail.com> <6280325c0705111932l713742e6i4923619b07c1008d@mail.gmail.com> Message-ID: On Saturday, May 12, 2007 12:02 PM +0930 n0dalus wrote: > On 5/12/07, Kenneth Porter wrote: >> >> Do the computers have USB? If so, you could load a DVD image on an >> external drive. They're getting pretty cheap now. >> > > I think one might have USB, but the BIOS would be too old to allow > booting from it. You could boot from a CD with just the installer/rescue image (which is small) and use a "hard disk" installation with the DVD ISO image on the USB hard drive. I usually do upgrades this way, copying the image to the system to be upgraded, then requesting a hard disk install. From mclasen at redhat.com Tue May 15 00:19:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 14 May 2007 20:19:15 -0400 Subject: Making beagle optional In-Reply-To: <1179180201.4627.50.camel@sb-home> References: <1179154692.3560.23.camel@localhost.localdomain> <1179180201.4627.50.camel@sb-home> Message-ID: <1179188355.3088.0.camel@localhost.localdomain> On Tue, 2007-05-15 at 00:03 +0200, nodata wrote: > > > Does this mean the Places> Search option in the menu, will return to > searching for files that match given criteria? > Yes, if neither beagle nor tracker is installed, the panel will pick up the gnome-search-tool. From kevin at scrye.com Tue May 15 01:53:33 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 14 May 2007 19:53:33 -0600 Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php In-Reply-To: <4648B8B1.3030701@redhat.com> References: <4648B8B1.3030701@redhat.com> Message-ID: <20070514195333.2c7be9b8@ghistelwchlohm.scrye.com> On Mon, 14 May 2007 15:29:53 -0400 wtogami at redhat.com (Warren Togami) wrote: > Aside from the kernel module packages, these are the packages in > rawhide as of May 12th with broken deps. Please get these fixed > before Thursday's final F7 freeze. > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > Follow the procedure here to get a build included in F7. > ...snip... One more for ppc32 at least, although it's a weird case: package: glest-data - 2.0.0-2.fc7.noarch from development unresolved deps: glest = 0:2.0.0 Bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219540 Did we ever decide how to deal with a noarch package that requires an arch package that exists only on some arches? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From miles.lane at gmail.com Tue May 15 01:59:13 2007 From: miles.lane at gmail.com (Miles Lane) Date: Mon, 14 May 2007 18:59:13 -0700 Subject: F7 -- Broken deps: Error: Missing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 is needed by package kmod-nvidia Message-ID: ---> Package kmod-nvidia.i686 0:1.0.9755-3.2.6.20_1.3104.fc7 set to be updated ---> Package xorg-x11-drv-nvidia.i386 0:1.0.9755-2.lvn7 set to be updated --> Processing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 for package: kmod-nvidia --> Finished Dependency Resolution Error: Missing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 is needed by package kmod-nvidia From sundaram at fedoraproject.org Tue May 15 02:03:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 07:33:17 +0530 Subject: F7 -- Broken deps: Error: Missing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 is needed by package kmod-nvidia In-Reply-To: References: Message-ID: <464914E5.9040304@fedoraproject.org> Miles Lane wrote: > ---> Package kmod-nvidia.i686 0:1.0.9755-3.2.6.20_1.3104.fc7 set to be > updated > ---> Package xorg-x11-drv-nvidia.i386 0:1.0.9755-2.lvn7 set to be updated > --> Processing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 for > package: kmod-nvidia > --> Finished Dependency Resolution > Error: Missing Dependency: kernel-i686 = 2.6.20-1.3104.fc7 is needed > by package kmod-nvidia This is a dependency issue in a third party repository package and should be reported to them instead of here. Please use fedora-test list or bugzilla for similar issues in packages in the official repo. Rahul From peter at thecodergeek.com Tue May 15 02:22:29 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 14 May 2007 19:22:29 -0700 Subject: Wireless Testing Needed for F7 In-Reply-To: <4648AFFF.80906@redhat.com> References: <4648AFFF.80906@redhat.com> Message-ID: <1179195749.3286.13.camel@tuxhugs> On Mon, 2007-05-14 at 14:52 -0400, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 > We are attempting to get wireless working on x86_64. > > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > If you use wireless on ANY arch of rawhide, please test this latest > wireless-tools build. We need to be sure that the x86_64 fix doesn't > break i386 or ppc*. Hi, Warren. I've tested the updated wireless-tools and have found no noticable regressions. It works just as well as the previous version I had installed (1:28-2.fc7). This is on a Development install, updated as of the afternoon of May 13 (pacific time). My workstation hardware is based on a Core2 Duo E6600 (x86_64 only, no multilib), using a "2Wire Wireless PC Card Version 01.01" PCMCIA card (a rebranded Prism2, using the orinoco_cs kernel driver). It's connected via a "Ricoh Co Ltd RL5c475 (rev 80)" PCI cardbus (using the yenta_socket kernel driver). My network is a simple SO/HO 802.11b router using WEP. Scanning, association, and encryption all seem to work as they should. The system-config-network configuration is holding well. If it's relevant to this discussion, I don't use NetworkManager at all, since the network setup is mostly static. (Though on second thought, I probably would if it would accept my WEP key... but that's a problem for another day. ^_^) Hope that helps. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bojan at rexursive.com Tue May 15 02:56:16 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 15 May 2007 02:56:16 +0000 (UTC) Subject: rawhide merge status References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179142919.19267.2.camel@vader.jdub.homelinux.org> Message-ID: Josh Boyer jdub.homelinux.org> writes: > No, only if you've submitted a tag request for f7-final to rel-eng. OK. So, the deal is that we just need to rebuild the packages once the release is done and they will end up in updates. Is that correct? -- Bojan From jwboyer at jdub.homelinux.org Tue May 15 03:07:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 22:07:34 -0500 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179142919.19267.2.camel@vader.jdub.homelinux.org> Message-ID: <1179198454.19267.91.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 02:56 +0000, Bojan Smojver wrote: > Josh Boyer jdub.homelinux.org> writes: > > > No, only if you've submitted a tag request for f7-final to rel-eng. > > OK. So, the deal is that we just need to rebuild the packages once the release > is done and they will end up in updates. Is that correct? Erm... not quite. You can rebuild after the CVS branch and it will be tagged with dist-fc7-updates-candidate. Then using bodhi, you can promote this to -testing, and further on to -final which would then tag it with dist-fc7-updates and show up in the updates repo and be available to the buildroot. If you don't use bodhi, then the build sits there and collects dust. There will be lots of questions on this, and the Bodhi developer will have some documentation explaining this when it's ready. He's a bit busy, as I understand it, taking final exams. josh From kevin.kofler at chello.at Tue May 15 03:16:58 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 May 2007 03:16:58 +0000 (UTC) Subject: rawhide merge status References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179142919.19267.2.camel@vader.jdub.homelinux.org> <1179198454.19267.91.camel@vader.jdub.homelinux.org> Message-ID: Josh Boyer jdub.homelinux.org> writes: > > > No, only if you've submitted a tag request for f7-final to rel-eng. > > > > OK. So, the deal is that we just need to rebuild the packages once the release > > is done and they will end up in updates. Is that correct? > > Erm... not quite. You can rebuild after the CVS branch and it will be > tagged with dist-fc7-updates-candidate. Then using bodhi, you can > promote this to -testing, and further on to -final which would then tag > it with dist-fc7-updates and show up in the updates repo and be > available to the buildroot. If you don't use bodhi, then the build sits > there and collects dust. Wouldn't it make sense to have the builds tagged dist-fc7, but not f7-final, available for pushing to updates too, e.g. by (either automatically or on request) putting them in dist-fc7-updates-candidate? Kevin Kofler From pemboa at gmail.com Tue May 15 03:24:24 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 14 May 2007 23:24:24 -0400 Subject: Fedora KDE Channel? Message-ID: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> Does it make sense to anyone else to have a Fedora KDE irc chatroom? I'm not too fond of being spoken down to when I mention KDE, and my usage thereof. I wanted to attach this to the KDE SIG thread, but it seemed to far from the original topic. -- Fedora Core 6 and proud From sundaram at fedoraproject.org Tue May 15 03:31:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 09:01:51 +0530 Subject: Fedora KDE Channel? In-Reply-To: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> References: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> Message-ID: <464929A7.3060308@fedoraproject.org> Arthur Pemberton wrote: > Does it make sense to anyone else to have a Fedora KDE irc chatroom? > I'm not too fond of being spoken down to when I mention KDE, and my > usage thereof. How is having a channel like this going to make you stop feeling so insecure about your usage of a desktop environment? Why should anyone else care? > I wanted to attach this to the KDE SIG thread, but it seemed to far > from the original topic. If any such channel is created it should be by the SIG for contributors to get involved. Your goal doesn't seem to be that at all. I think KDE developers in Fedora (which is a pretty small group) should use common channels like #fedora-devel for participation. Living in your own island helps no one. Rahul From pemboa at gmail.com Tue May 15 03:42:12 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 14 May 2007 23:42:12 -0400 Subject: Fedora KDE Channel? In-Reply-To: <464929A7.3060308@fedoraproject.org> References: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> <464929A7.3060308@fedoraproject.org> Message-ID: <16de708d0705142042r63ff8896q3e361b4cc3dbae5f@mail.gmail.com> On 5/14/07, Rahul Sundaram wrote: > Arthur Pemberton wrote: > > Does it make sense to anyone else to have a Fedora KDE irc chatroom? > > I'm not too fond of being spoken down to when I mention KDE, and my > > usage thereof. > > How is having a channel like this going to make you stop feeling so > insecure about your usage of a desktop environment? Why should anyone > else care? The goal isn't to feel more or less secure, nor am I suggesting that this be done for me. The question is whether or not _others_ see any benefit in this. Nor did I ask anyone else to care. I don't go to the IRC channel to deal with overly aggressive people, but to help newbies, and others whom I am able to. > > I wanted to attach this to the KDE SIG thread, but it seemed to far > > from the original topic. > > If any such channel is created it should be by the SIG for contributors > to get involved. Your goal doesn't seem to be that at all. I think KDE > developers in Fedora (which is a pretty small group) should use common > channels like #fedora-devel for participation. Living in your own island > helps no one. Fair enough. -- Fedora Core 6 and proud From chris.stone at gmail.com Tue May 15 03:46:33 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 14 May 2007 20:46:33 -0700 Subject: Fedora KDE Channel? In-Reply-To: <16de708d0705142042r63ff8896q3e361b4cc3dbae5f@mail.gmail.com> References: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> <464929A7.3060308@fedoraproject.org> <16de708d0705142042r63ff8896q3e361b4cc3dbae5f@mail.gmail.com> Message-ID: We have a IRC channel for #fedora-games. Why don't you join us at the KDE SIG meeting tomorrow in #fedora-meeting and ask about it there. Regards, Chris From kevin.kofler at chello.at Tue May 15 05:45:59 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 May 2007 05:45:59 +0000 (UTC) Subject: Making beagle optional References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: Alexander Larsson redhat.com> writes: > I just commited a change to comps which makes beagle optional instead of > installed by default. The idea with beagle (and tracker) is nice, but ... and strigi. :-) Which is now available in Fedora too (I did the review and approval). Kevin Kofler From kevin.kofler at chello.at Tue May 15 05:50:04 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 May 2007 05:50:04 +0000 (UTC) Subject: Making beagle optional References: <1179154692.3560.23.camel@localhost.localdomain> <1179163201.28960.32.camel@dawkins> Message-ID: David Nielsen lovesunix.net> writes: > Both I think needs more use cases outside of replacing the search > dialog, something like Banshee or Rhythmbox could arrange their media > libraries using this kind of technology. The fact is that this > technology has been around for a while and yet nobody is really using it > to make the desktop better. Hopefully this will change for F8. Well, the plan is to ship KDE 4 in F8, and the KDE folks are working on supporting Strigi in some apps. But I don't know how work is going on the GNOME side, that probably also depends on whether Beagle or Tracker will end up as the "default" there. I'm a bit worried about ending up with 2 or 3 different desktop search daemons autostarted by different apps. (Heck, personally, I don't even want _one_ search daemon autostarted, but users and use cases differ. ;-) ) Kevin Kofler From kevin at scrye.com Tue May 15 05:58:41 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 14 May 2007 23:58:41 -0600 Subject: Making beagle optional In-Reply-To: References: <1179154692.3560.23.camel@localhost.localdomain> Message-ID: <20070514235841.1231a19a@ghistelwchlohm.scrye.com> On Tue, 15 May 2007 05:45:59 +0000 (UTC) kevin.kofler at chello.at (Kevin Kofler) wrote: > Alexander Larsson redhat.com> writes: > > I just commited a change to comps which makes beagle optional > > instead of installed by default. The idea with beagle (and tracker) > > is nice, but > > ... and strigi. :-) Which is now available in Fedora too (I did the > review and approval). And there is also recoll... http://www.lesbonscomptes.com/recoll/ (not yet in Fedora). I think we might want to look at a shootout early in the f8 cycle and see if any of them stand out for any reason. > Kevin Kofler kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Tue May 15 06:00:14 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 15 May 2007 06:00:14 +0000 (UTC) Subject: rawhide merge status References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179142919.19267.2.camel@vader.jdub.homelinux.org> <1179198454.19267.91.camel@vader.jdub.homelinux.org> Message-ID: Josh Boyer jdub.homelinux.org> writes: > If you don't use bodhi, then the build sits > there and collects dust. OK. Looking forward to doing "yum -y install bodhi" :-) -- Bojan From carlos at quantumfx.com Tue May 15 05:56:55 2007 From: carlos at quantumfx.com (Carlos Ramirez) Date: Mon, 14 May 2007 22:56:55 -0700 Subject: Fedora Core base system package list Message-ID: <46494BA7.6080406@quantumfx.com> Is there a file, web page or command that can provide a list of packages that are part of the Fedora base system? I tried searching in various places without much luck. Any help in the right direct is appreciated. Thanks, -Carlos From kevin.kofler at chello.at Tue May 15 06:40:54 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 15 May 2007 06:40:54 +0000 (UTC) Subject: Making beagle optional References: <1179154692.3560.23.camel@localhost.localdomain> <20070514235841.1231a19a@ghistelwchlohm.scrye.com> Message-ID: Kevin Fenzi scrye.com> writes: > I think we might want to look at a shootout early in the f8 cycle and > see if any of them stand out for any reason. Well, Strigi "stands out" by being required to build and run KDE 4. ;-) So an install including KDE 4 will have to include at least the indexing libraries from Strigi (even in the case the alternatives turn out to be way better ;-) ). It should be possible to package them separately from the daemon though. However, they're also working on making the apps integrate with the daemon, which of course will only work if the daemon is running, and as Strigi is now required anyway, I don't think integration with other similar daemons is planned. Kevin Kofler From david at lovesunix.net Tue May 15 07:00:25 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 15 May 2007 09:00:25 +0200 Subject: Making beagle optional In-Reply-To: References: <1179154692.3560.23.camel@localhost.localdomain> <1179163201.28960.32.camel@dawkins> Message-ID: <1179212425.28960.56.camel@dawkins> tir, 15 05 2007 kl. 05:50 +0000, skrev Kevin Kofler: > Well, the plan is to ship KDE 4 in F8, and the KDE folks are working on > supporting Strigi in some apps. But I don't know how work is going on the GNOME > side, that probably also depends on whether Beagle or Tracker will end up as > the "default" there. > > I'm a bit worried about ending up with 2 or 3 different desktop search daemons > autostarted by different apps. (Heck, personally, I don't even want _one_ > search daemon autostarted, but users and use cases differ. ;-) ) The FreeDesktop.org Xesam standard nicely solves this by providing a standard DBus API application developers can use when wanting to employ such functionality instead of tying it to one specific indexer. This way Fedora KDE could ship with Stringi and even GNOME apps would work since they only depend on the Xesam calls and not the backend. This should entirely remove the multiple indexer problem and ensure a much improved user experience. Everybody wins. The best bit is that Xesam has buyin from every major indexer project from the word go, this should hopefully ensure that the standard gets adopted smoothly. I love it when Open Standards work out correctly. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From alex at tvtransilvania.ro Tue May 15 07:04:05 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Tue, 15 May 2007 10:04:05 +0300 Subject: Wireless Testing Needed for F7 In-Reply-To: <4648AFFF.80906@redhat.com> References: <4648AFFF.80906@redhat.com> Message-ID: <46495B65.8060201@tvtransilvania.ro> Warren Togami wrote: > > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > If you use wireless on ANY arch of rawhide, please test this latest > wireless-tools build. We need to be sure that the x86_64 fix doesn't > break i386 or ppc*. > Just like release -2, the -3 release is flowless here. kernel 2.6.21-1.3142.fc7 on a i686 with my Intel 2200BG wireless (ipw2200) From mschwendt.tmp0701.nospam at arcor.de Tue May 15 07:47:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 15 May 2007 09:47:01 +0200 Subject: F7 Broken Deps: gaim-gaym, php-eaccelerator, redhat-artwork-kde, syck-php In-Reply-To: <20070514195333.2c7be9b8@ghistelwchlohm.scrye.com> References: <4648B8B1.3030701@redhat.com> <20070514195333.2c7be9b8@ghistelwchlohm.scrye.com> Message-ID: <20070515094701.045efcee.mschwendt.tmp0701.nospam@arcor.de> On Mon, 14 May 2007 19:53:33 -0600, Kevin Fenzi wrote: > On Mon, 14 May 2007 15:29:53 -0400 > wtogami at redhat.com (Warren Togami) wrote: > > > Aside from the kernel module packages, these are the packages in > > rawhide as of May 12th with broken deps. Please get these fixed > > before Thursday's final F7 freeze. > > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > Follow the procedure here to get a build included in F7. > > > ...snip... > > One more for ppc32 at least, although it's a weird case: > > package: glest-data - 2.0.0-2.fc7.noarch from development > unresolved deps: > glest = 0:2.0.0 > > Bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219540 > > Did we ever decide how to deal with a noarch package that requires an > arch package that exists only on some arches? You could keep the ExcludeArch in sync or remove the dependency. A data package without a program for the data is less bad than a broken dependency that results in a confusing/fatal error during package installation attempts. From alexl at redhat.com Tue May 15 07:48:28 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 15 May 2007 09:48:28 +0200 Subject: (co)maintainers wanted In-Reply-To: <1178889718.4477.28.camel@localhost.localdomain> References: <1178808160.3068.26.camel@greebo> <1178812412.3068.31.camel@greebo> <1178882756.4477.15.camel@localhost.localdomain> <20070511151216.0fc784a0@spica.a.lan> <1178889718.4477.28.camel@localhost.localdomain> Message-ID: <1179215308.3755.0.camel@localhost.localdomain> On Fri, 2007-05-11 at 15:21 +0200, Alexander Larsson wrote: > On Fri, 2007-05-11 at 15:12 +0200, Andreas Bierfert wrote: > > On Fri, 11 May 2007 13:25:56 +0200 > > Alexander Larsson wrote: > > > > > > CC:in andreas. Are you interested in this? > > > > Sure. I do maintain it for EPEL and for FE <= 4? I believe so should not be to > > much trouble... > > Good. You'll be primary mantainer then. > Nicolas, do you still want to be comaintainer? I put you both down as mainainers in bug 225981. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous hunchbacked vagrant in drag. She's a high-kicking streetsmart nun with a birthmark shaped like Liberty's torch. They fight crime! From alexl at redhat.com Tue May 15 07:52:33 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 15 May 2007 09:52:33 +0200 Subject: gmime (co)maintainers wanted In-Reply-To: <46433B88.4070907@leemhuis.info> References: <1178808160.3068.26.camel@greebo> <46433B88.4070907@leemhuis.info> Message-ID: <1179215553.3755.2.camel@localhost.localdomain> On Thu, 2007-05-10 at 17:34 +0200, Thorsten Leemhuis wrote: > Kevin Kofler schrieb: > >> * gmime > > The last Extras maintainer for gmime was Thorsten Leemhuis. Thorsten, do you > > want gmime back? > > Not really -- Iirc I just packaged it because mail-notification needed > it. But well, if no one else is interested in it'll at least become > official co-maintainer. Then we'll see how things evolve. Requested in bug 225808. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lonely coffee-fuelled paranormal investigator in a wheelchair. She's a ditzy out-of-work mermaid with the power to see death. They fight crime! From alexl at redhat.com Tue May 15 08:02:03 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 15 May 2007 10:02:03 +0200 Subject: (co)maintainers wanted In-Reply-To: <62bc09df0705101636r6c2de324xf6f7dc33b8ca83f7@mail.gmail.com> References: <1178808160.3068.26.camel@greebo> <62bc09df0705101636r6c2de324xf6f7dc33b8ca83f7@mail.gmail.com> Message-ID: <1179216123.3755.4.camel@localhost.localdomain> On Thu, 2007-05-10 at 19:36 -0400, SmootherFrOgZ wrote: > Then there is a bunch of mono libraries from when I did the > initial mono > work: > * gtk-sharp2 > * gnome-sharp > * gsf-sharp > > I actually use them, i'm working on some package which need them to > build and for developing. > I'm interested to co-maintain them. Requested in bug 225862, 225874 and 240103. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted vegetarian hairdresser in drag. She's a disco-crazy green-skinned cab driver with an MBA from Harvard. They fight crime! From bkoz at redhat.com Tue May 15 08:42:06 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Tue, 15 May 2007 10:42:06 +0200 Subject: Legality of Fedora in production environment In-Reply-To: <4648B15F.8080809@fedoraproject.org> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <20070511155636.GA27804@devserv.devel.redhat.com> <464810C4.70309@redhat.com> <4648B15F.8080809@fedoraproject.org> Message-ID: <4649725E.5030504@redhat.com> >> http://people.redhat.com/bkoz/fedora_certificates/ > > Note that this EULA requires modifications for Fedora 7 release. We need > to replace all occurrences of "Fedora Core" with "Fedora" and add a > section on firmware. These certificates should be considered for demonstration purposes only. Unlike the EULA.... I'm just taking the text verbatim from what is existing presently on the web. If it's not right on the web, it should be fixed pronto. Other parts of this conversation have pointed out the weaknesses/inapplicability of a US-legal language EULA worldwide. Hopefully this issue will be fixed, or a plan or strategy devised for legal support in all Fedora locales. If I had valid language for other locales, I'd be happy to come up with certificates of authenticity for them. best, -benjamin From mcepl at redhat.com Tue May 15 09:21:58 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 15 May 2007 11:21:58 +0200 Subject: Making beagle optional References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <1179185599.28960.46.camel@dawkins> Message-ID: On 2007-05-14, 23:33 GMT, David Nielsen wrote: > I think it might be good if someone started helping Alex with > beagle maintainership so we could ensure quick pushes of new > updates as bugs are fixed. I am not sure, whether Alex had it on his mind, but I am afraid, one of the reasons why there is insufficient support for beagle is that the idea of Mono doesn't look that great lately. I think that advantage of other search engines (tracker, strigi, something based on JLucene) is that they don't require Mono. Just my 0.02 CZK. Matej From ffesti at redhat.com Tue May 15 09:53:49 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 15 May 2007 11:53:49 +0200 Subject: Yum performance review Message-ID: <4649832D.30403@redhat.com> Hi! Yum traditionally used the rpmlib to resolve the dependecies of the packages being installed/removed/updated. This has always restricted yum to very simple algorithms as the interface of the rpmlib doesn't allow much control. The current yum - that will be shipped with F7 - has now replaced the rpmlib by a Python only resolver. I did some test runs to find out the current state of development and to see if the new resolver is an improvement over the rpmlib. The candidates: =============== * yum-3.0.3 as used in FC6 * yum from CVS head (2007/05/07), which is very similar to the yum in F7 * pyrpmyum CVS head (2007/05/07) - a pure Python implementation developed for testing purposed [1]. The test cases: =============== Tests are based in FC-5 run on FC-6.x86_64. All operations are aborted by "pressing n". Installs: Try to install into an empty build root. There is a big number of excluded pkgs to make the install '*' work. * Normal install: several groups, 856 Pkgs * Full install: "*", 6057 Pkgs * Install "[a-k]*", 3052 Pkgs - needs to drag in a lot of pkgs to satisfy dependencies Updates: Before the Updates the "Normal Install" is run and the Pkgs are installed into the build root. * Empty update * Update libgnome: 1 Pkg * Big update: 346u+12i Pkgs * Dist upgrade: Enable FC6 repos and do an upgrade; fails for both yum versions,so don't take results too serious Erase: * glibc: 828 Pkgs Warm ups: Do a install '*'/upgrade to build the caches. Each program has different issues with that. yum-3.0.3 needs to download the rpm headers (Test was run with repos in a NFS mount). All need to build the sqlite databases. pyrpmyum currently uses a Python only implementation that uses a lot of time. Warm up operations fail for all programs. This all make the results of the warm ups a bit unreliable and questionable. They are included for completeness. Measured Values: ================ All data is from just one test run - so don't expect too high precision. I put 3 different test results into tables: * Real time passed during the test * Heap peak - maximum of Memory used * Heap total - amount of heap memory allocated The last one gives an idea of how much data has been moved around. Conclusions: ============ Please read the data tables first to get your own impression. Memory usage: The new yum saves a lot of memory for big operations (about 50%). The comparison to pyrpmyum shows that it is possible to save even more memory and to drop memory usage below 100MB for all cases. In pyrpmyum this is achieved with dynamic loading of rpm tags. Some are not even kept in the pkgs but just cached in a least recently used list. For really small updates the old 3.0.3 yum wins. I guess this is because it does not do any obsolete handling. Runtime: Although the new yum save the very costly rpm header downloads (which take nearly 3 minutes for the whole repository) it is still significantly slower for big operations. Things may look a bit different in real world scenarios where downloading the headers is even more expensive. Nevertheless the performance of the current yum is poor. Runtime behavior has dropped from O(#prco * #rpmlib_calls) to O(#prco^2) (prco = Provides, Requires, Conflicts, Obsoletes). The results of pyrpmyum show that is it possible to do the depsolving in O(#prco) (Probably just O(#prco * log #prco) but that doesn't matter much). There are already plans how to get rid of the quadratic behavior and I hope we can fix these issues before Fedora 8. Have fun Florian Festi [1] https://hosted.fedoraproject.org/projects/pyrpm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: heap.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: heaptotal.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: real.txt URL: From valent.turkovic at gmail.com Tue May 15 10:28:11 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 15 May 2007 12:28:11 +0200 Subject: Making beagle optional In-Reply-To: <1179184279.3478.9.camel@daemon> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> Message-ID: <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> On 5/15/07, Jens Knutson wrote: > On Mon, 2007-05-14 at 16:59 -0400, Arthur Pemberton wrote: > > On 5/14/07, Alexander Larsson wrote: > > > I just commited a change to comps which makes beagle optional instead of > > > installed by default. The idea with beagle (and tracker) is nice, but > > > bugs keep on showing up causing the search daemon to use a lot of cpu > > > and/or memory, and this makes the default install look pretty bad. > > > > > > This is somewhat of a feature regression in the default install, but at > > > this point we just don't have the manpower to make it work 100%. But if > > > people want it its still there, and eventually it'll be good enought to > > > turn on by default without affecting the general distro quality. > > > > Thank you my good sir. I hated that thing. > > I'm personally really disappointed that Beagle's no longer in the > default install. This isn't to rag on Alex, or to even disagree with > him - if it's causing bugs like this, then I understand why this had to > be done, at least for now. But Beagle's a great tool - I use it > *daily*, and while it's no problem for me to simply add it back into my > package set, it's too bad that new users won't have Beagle's great > features out of the box. > > I hope that this can be re-evaluated for F8! > > - Jens Knutson > > (Preemptive note to Tracker fanboys: I tried Tracker for a few days and > disabled Beagle. At the end of my testing, I very happily re-enabled > Beagle and removed Tracker completely - Tracker's not a /fraction/ as > useful, Beagle doesn't use much CPU on my system, and RAM usage is > hardly a concern - memory is CHEAP.) I must say that I agree with Jen 100% I use beagle and firefox beagle plugin all the time and they are real life savers! I can't imagine my deskop without beagle and deskbar! I also tried tracked and wasn't impressed. Please make beagle and deskbar default on for Fedora 7! There are a lot of new users who would really benefit from these functions. Is there maybe an option to whip beagle into shape and not to use 100% of cpu? Is there no other way? Is disabling it really the only option? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From valent.turkovic at gmail.com Tue May 15 10:41:41 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 15 May 2007 12:41:41 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <20070508130336.GB23247@redhat.com> References: <20070508130336.GB23247@redhat.com> Message-ID: <64b14b300705150341u6c079569q88198d80625c3ed1@mail.gmail.com> On 5/8/07, John W. Linville wrote: > If you are a rawhide user/tester and have ipw3945 hardware, please > try the latest kernels here: > > http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I am having mixed results with the latest iwl3945 updates, but I'm > not sure if it is this particular laptop having problems or the driver > in general. > > Please give the latest kernels a try and let me know how it is working > for you. Please also let me know what was the last kernel that worked > any better for ipw3945 hardware than the current ones. > > At this point, I am quite uneasy about this driver. It seems to work > fine at times, then crash or simply refuse to associate at others. > I am considering backing it out to the 0.0.16 tag or possibly even > removing it (since the driver has _still_ not been posted upstream). > Thoughts? > > Thanks, > > John I have 3945 wireless card and I have one bug that looked much more serious before I looked into it - but for new users it is a really show-stopper bug. I have wireless turned off via wireless switch on my laptop. When I need wireless I turn it on. On fedora 7 test 4 with all the latest updates (kernel 2.6.21-1.3142.fc7) when I turn wireless on I still get no wireless! # iwconfig lo no wireless extensions. eth0 no wireless extensions. I looked at module list and the module is loaded! # lsmod |grep iwl iwl3945 140797 0 mac80211 139133 1 iwl3945 When I remove and reload the module I get my wireless card regisered! [root at fedora74 ~]# rmmod iwl3945 [root at fedora74 ~]# [root at fedora74 ~]# lsmod |grep iwl [root at fedora74 ~]# modprobe iwl3945 [root at fedora74 ~]# iwconfig lo no wireless extensions. eth0 no wireless extensions. wmaster0 no wireless extensions. Warning: Driver for device wlan0 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken... wlan0 IEEE 802.11a ESSID:"" Mode:Managed Frequency:5.17 GHz Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Please fix this nasty bug! -- 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 jwboyer at jdub.homelinux.org Tue May 15 10:50:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 05:50:10 -0500 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179142919.19267.2.camel@vader.jdub.homelinux.org> <1179198454.19267.91.camel@vader.jdub.homelinux.org> Message-ID: <1179226211.19267.93.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 03:16 +0000, Kevin Kofler wrote: > Josh Boyer jdub.homelinux.org> writes: > > > > No, only if you've submitted a tag request for f7-final to rel-eng. > > > > > > OK. So, the deal is that we just need to rebuild the packages once the > release > > > is done and they will end up in updates. Is that correct? > > > > Erm... not quite. You can rebuild after the CVS branch and it will be > > tagged with dist-fc7-updates-candidate. Then using bodhi, you can > > promote this to -testing, and further on to -final which would then tag > > it with dist-fc7-updates and show up in the updates repo and be > > available to the buildroot. If you don't use bodhi, then the build sits > > there and collects dust. > > Wouldn't it make sense to have the builds tagged dist-fc7, but not f7-final, > available for pushing to updates too, e.g. by (either automatically or on > request) putting them in dist-fc7-updates-candidate? Hm... yes perhaps. That might already be planned. Jesse? josh From valent.turkovic at gmail.com Tue May 15 11:10:00 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 15 May 2007 13:10:00 +0200 Subject: ipw3945/iwlwifi/iwl3945 users, please test latest davej kernels In-Reply-To: <64b14b300705150341u6c079569q88198d80625c3ed1@mail.gmail.com> References: <20070508130336.GB23247@redhat.com> <64b14b300705150341u6c079569q88198d80625c3ed1@mail.gmail.com> Message-ID: <64b14b300705150410g67dec3e0r2be487bb14e7f899@mail.gmail.com> here is the bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116 -- 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 rdieter at math.unl.edu Tue May 15 11:56:48 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 May 2007 06:56:48 -0500 Subject: Fedora KDE Channel? In-Reply-To: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> References: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> Message-ID: <4649A000.9000607@math.unl.edu> Arthur Pemberton wrote: > Does it make sense to anyone else to have a Fedora KDE irc chatroom? > I'm not too fond of being spoken down to when I mention KDE, and my > usage thereof. Continue use of #fedora and/or #kde. If anyone gives you a hard time in the future, feel free to look me up (rdieter), and I'll promise to properly chastise those responsible. :) -- Rex From camilo at mesias.co.uk Tue May 15 11:13:45 2007 From: camilo at mesias.co.uk (Cam) Date: Tue, 15 May 2007 12:13:45 +0100 Subject: Making beagle optional In-Reply-To: <1179184279.3478.9.camel@daemon> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> Message-ID: <464995E9.1010200@mesias.co.uk> Jens > I'm personally really disappointed that Beagle's no longer in the > default install. This isn't to rag on Alex, or to even disagree with > him - if it's causing bugs like this, then I understand why this had to > be done, at least for now. But Beagle's a great tool - I use it > *daily*, and while it's no problem for me to simply add it back into my > package set, it's too bad that new users won't have Beagle's great > features out of the box. I can appreciate the idea behind a system wide search, but I feel that it is not viable in a distribution until the usability of that search exceeds or matches the usability of search features built into individual apps. For example at the moment I can use Firefox to search remote IMAP mailboxes very effectively. Similarly I can use rhythmbox to search for some music, and I can use to find pictures. I wouldn't dream of using a search tool to try and find any of these because the apps I would then use to edit/view/use the files already do a really good job. So the use case for the search tool evaporates, and it becomes an annoyance, even if it only uses 30% CPU. Do any of the search engines try to publish an API that applications can use to implement their indexing / searches? I think that could be a step towards a unified search tool. -Cam -- camilo at mesias.co.uk <-- From buc at odusz.so-cdu.ru Tue May 15 13:35:45 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 May 2007 17:35:45 +0400 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <464889F0.5040505@redhat.com> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> <464889F0.5040505@redhat.com> Message-ID: <4649B731.1040704@odu.neva.ru> Vladimir Makarov wrote: > Alexander Bokovoy wrote: > >> Simo, Vladimir, folks, >> >> please stop distributing this crap. It is unfortunate drop of black PR >> from our enemies during current discussions on improving legality of >> software in schools at Russian government. But it is far from reality. >> >> > Alexander, I am really sorry about this. My appologies. I did not > know that it was April 1st joke. I read this just recently and took > it seriously. Probably my knowledege about modern Russia is not > adequate anymore. I left it ten years ago. > >> The case described below is April, 1st joke which was created by >> www.securitylab.ru portal (a good one!) but went largely unnoticed until >> someone showed it to general IT media without linking to the original. >> >> http://www.securitylab.ru/news/293577.php >> What do you speak about now? To be clearly understood: The Russian case described is not "a joke", unfortunately. Certainly, it is (still) not wide-spread, but I hear about such a threat at each RHEL-related seminar now. A user ask "what about if I just download from Internet", the "official" answer is "it is dangerous, because your computers can be confiscated etc...", and "if you don't want such troubles, buy (our) box with some license paper..." From pemboa at gmail.com Tue May 15 13:53:14 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 15 May 2007 09:53:14 -0400 Subject: Fedora KDE Channel? In-Reply-To: <4649A000.9000607@math.unl.edu> References: <16de708d0705142024m22c20c69iad817b7873dfd75@mail.gmail.com> <4649A000.9000607@math.unl.edu> Message-ID: <16de708d0705150653r1b992cfdn4042052bbc9bde96@mail.gmail.com> On 5/15/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > Does it make sense to anyone else to have a Fedora KDE irc chatroom? > > I'm not too fond of being spoken down to when I mention KDE, and my > > usage thereof. > > Continue use of #fedora and/or #kde. If anyone gives you a hard time in > the future, feel free to look me up (rdieter), and I'll promise to > properly chastise those responsible. :) It is a matter of simply ignoring me if I'm the only one who finds that this may be useful. -- Fedora Core 6 and proud From buc at odusz.so-cdu.ru Tue May 15 14:21:40 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 May 2007 18:21:40 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <1178905866.12871.13.camel@willson> References: <46446924.1080209@odu.neva.ru> <20070511140243.GB21356@devserv.devel.redhat.com> <46448343.5050504@redhat.com> <46448ED2.1020704@odu.neva.ru> <464492C8.60707@redhat.com> <46449B03.1070700@odu.neva.ru> <1178905866.12871.13.camel@willson> Message-ID: <4649C1F4.3020204@odu.neva.ru> Simo Sorce wrote: > A Russian friend invloved with it just told me that ALT Linux is going > to address the problem in this thread very soon. Maybe it could make > sense coordinating with them and produce something that can be reused by > other free software projects ? > Well, I know this team, I believe that they will try to do something. But in general, there is an obvious case of the "conflict of interests". Any Linux/Free-software related group in my country usually has no sponsor support. Hence such a group is compelled to earn money independently for the existence. Besides user support, one of the business is the sale of "software boxes" (CDs of free software, accompanied with some docs, licenses etc.). The last one clashes with desire of the user to download something from the Internet directly. :( ~buc From jkeating at redhat.com Tue May 15 14:22:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 10:22:52 -0400 Subject: rawhide merge status In-Reply-To: <1179226211.19267.93.camel@vader.jdub.homelinux.org> References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179226211.19267.93.camel@vader.jdub.homelinux.org> Message-ID: <200705151022.52229.jkeating@redhat.com> On Tuesday 15 May 2007 06:50:10 Josh Boyer wrote: > > Wouldn't it make sense to have the builds tagged dist-fc7, but not > > f7-final, available for pushing to updates too, e.g. by (either > > automatically or on request) putting them in dist-fc7-updates-candidate? > > Hm... yes perhaps. ?That might already be planned. ?Jesse? Yes, they are available to be released as updates as well. dist-fc7-updates-candidate inherits from dist-fc7-updates which inherits from dist-fc7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 15 14:23:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 10:23:16 -0400 Subject: rawhide merge status In-Reply-To: References: <20070512134333.GB16522@nostromo.devel.redhat.com> <1179198454.19267.91.camel@vader.jdub.homelinux.org> Message-ID: <200705151023.16234.jkeating@redhat.com> On Tuesday 15 May 2007 02:00:14 Bojan Smojver wrote: > OK. Looking forward to doing "yum -y install bodhi" :-) Actually bodhi will be a web interface that you use if I understand it correctly, not a client package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Tue May 15 14:32:05 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 May 2007 10:32:05 -0400 Subject: Selinux and package guidelines In-Reply-To: References: <1178291788.2702.10.camel@vorpal.macdev.com> <1178298825.2785.9.camel@aglarond.local> <463B71F1.4040300@leemhuis.info> <1178387453.17680.38.camel@shinybook.infradead.org> <463D1CC2.8000204@fedoraunity.org> <1178439873.17680.104.camel@shinybook.infradead.org> <463D9B4B.2080407@gmail.com> Message-ID: <4649C465.4020207@redhat.com> Kevin Kofler wrote: > dragoran gmail.com> writes: > >> David Woodhouse wrote: >> >>> [...] >>> *SElinux*, >>> [..] >>> >> thx for mentioning this I suggest that any package that create avcs >> should not pass a review. We have suchs packages in extras and nothing >> in the review process takes care of selinux integration which is wrong. >> > > So you want to force reviewers to run with SELinux enabled? That's going to > reduce the number of reviewers significantly and increase the load on the > review queue even more. I for one have SELinux disabled (completely, so I don't > get even permissive AVCs) and I'm surely not the only one. Reviewing is already > tedious enough as it stands (it took me over an hour to review Strigi, and it > already had some quick pre-review comments by Rex Dieter and me). (It does work > though, for example I caught some plugin .so files being mistaken for symlinks > and thus accidentally shipped in strigi-devel rather than in the main strigi > package, that would definitely have broken things for the end user. So I'm not > complaining about the current process, just about your suggestion to add that > SELinux requirement.) > > Kevin Kofler > > I think the point being is that someone should test with SELinux enabled. (Especially the packager.) Having these packages go out and blowing up on an SELinux enabled system, causes me no end of headaches. I would like to see the guidelines eventually state that any network facing daemon would come with an SELinux policy for it. But requiring the app to at least start and stop and maybe run a few rudimentary tests with SELinux in enforcing mode. From buc at odusz.so-cdu.ru Tue May 15 14:44:34 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 May 2007 18:44:34 +0400 Subject: Legality of Fedora in production environment In-Reply-To: <46487539.3030701@redhat.com> References: <46446924.1080209@odu.neva.ru> <34e52d0c0705110617r56e953e0h1e5ef26aeaba3b84@mail.gmail.com> <46446F8D.7070100@odu.neva.ru> <20070511132912.GC4791@free.fr> <464477B4.7010509@odu.neva.ru> <1178893756.29429.40.camel@zod.rchland.ibm.com> <46448490.5040308@odu.neva.ru> <1178896088.29429.55.camel@zod.rchland.ibm.com> <46487539.3030701@redhat.com> Message-ID: <4649C752.1090804@odu.neva.ru> Vladimir Makarov wrote: > > I know that GPL was translated to Russian several times Actually, notarially certified translations of GPL have been appeared only recently. > I think Russian police knows well what is Linux. Unfortunately, it is wrong assumption. A policeman, who checks the computers later, either already know about Linux, or learns during the check. The problem is the "confiscating policeman" (normally *not* software expert). Even if he know about Linux, he have a formal occasion for confiscation. (BTW, just another case which feeds corruption). ~buc From alexl at redhat.com Tue May 15 14:47:40 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 15 May 2007 16:47:40 +0200 Subject: Making beagle optional In-Reply-To: References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <1179185599.28960.46.camel@dawkins> Message-ID: <1179240460.3755.24.camel@localhost.localdomain> On Tue, 2007-05-15 at 11:21 +0200, Matej Cepl wrote: > On 2007-05-14, 23:33 GMT, David Nielsen wrote: > > I think it might be good if someone started helping Alex with > > beagle maintainership so we could ensure quick pushes of new > > updates as bugs are fixed. > > I am not sure, whether Alex had it on his mind, but I am afraid, > one of the reasons why there is insufficient support for beagle > is that the idea of Mono doesn't look that great lately. I think > that advantage of other search engines (tracker, strigi, > something based on JLucene) is that they don't require Mono. This isn't really the main reason. Any indexer is bound to run in to the same issues, since it will try to read and parse a *lot* of data. Since so much data is read its very common to stumble upon some data that causes a bug in the indexer. You have to be extremely carefull when working on indexing code so that you handle all weird cases right. In fact, its likely that being in mono (or any "managed" runtime) is an advantage for that particular reason, since its harder to crash or leak in such systems. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an all-American playboy rock star with no name. She's a sarcastic red-headed wrestler from the wrong side of the tracks. They fight crime! From alexl at redhat.com Tue May 15 14:49:46 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 15 May 2007 16:49:46 +0200 Subject: Making beagle optional In-Reply-To: <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> Message-ID: <1179240586.3755.27.camel@localhost.localdomain> On Tue, 2007-05-15 at 12:28 +0200, Valent Turkovic wrote: > Is there maybe an option to whip beagle into shape and not to use 100% of cpu? > > Is there no other way? Is disabling it really the only option? The decision has been made for Fedora 7. But you can help out for Fedora 8 by fixing bugs like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced gay gangster who hides his scarred face behind a mask. She's a manipulative streetsmart detective trying to make a difference in a man's world. They fight crime! From david at lovesunix.net Tue May 15 15:00:57 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 15 May 2007 17:00:57 +0200 Subject: Making beagle optional In-Reply-To: References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <1179185599.28960.46.camel@dawkins> Message-ID: <1179241257.28960.73.camel@dawkins> tir, 15 05 2007 kl. 11:21 +0200, skrev Matej Cepl: > On 2007-05-14, 23:33 GMT, David Nielsen wrote: > > I think it might be good if someone started helping Alex with > > beagle maintainership so we could ensure quick pushes of new > > updates as bugs are fixed. > > I am not sure, whether Alex had it on his mind, but I am afraid, > one of the reasons why there is insufficient support for beagle > is that the idea of Mono doesn't look that great lately. I think > that advantage of other search engines (tracker, strigi, > something based on JLucene) is that they don't require Mono. While I understand that it is all the fad to blame Mono for all the evils in the world including the lack of lasting peace in the middle east but that's simply not true. The problem is the data parsers and it's caused by insufficent care in design and the lack of good input fuzzing in terms to testing. There's also a terrible design problem seeing as Beagle is made to get stuck on a file it can't parse instead of dropping it after a while and logging the problem for the user to report. Luckily Beagle has very good documentation to help users help the developers. I wish more developers would take the time to write up a page explaining how to extract the information they need, it saves so much time. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From pertusus at free.fr Tue May 15 15:14:21 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 17:14:21 +0200 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> Message-ID: <20070515151421.GF2815@free.fr> On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: > Author: ajax > + mkdir -p ${DESTDIR}${MANDIR} > + cp powertop.1 ${DESTDIR}${MANDIR} cp -p would keep timestamps. Maybe not worth it if powertop.1 is generated, I haven't checked... -- Pat From ajackson at redhat.com Tue May 15 15:40:59 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 15 May 2007 11:40:59 -0400 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <20070515151421.GF2815@free.fr> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> Message-ID: <1179243659.16274.40.camel@localhost.localdomain> On Tue, 2007-05-15 at 17:14 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: > > Author: ajax > > + mkdir -p ${DESTDIR}${MANDIR} > > + cp powertop.1 ${DESTDIR}${MANDIR} > > cp -p would keep timestamps. Maybe not worth it if powertop.1 is > generated, I haven't checked... It isn't. Why would I care about timestamp? - ajax From ericm24x7 at gmail.com Tue May 15 16:00:13 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Tue, 15 May 2007 12:00:13 -0400 Subject: Wireless Testing Needed for F7 In-Reply-To: <46495B65.8060201@tvtransilvania.ro> References: <4648AFFF.80906@redhat.com> <46495B65.8060201@tvtransilvania.ro> Message-ID: <4649D90D.3010204@gmail.com> Alexandru Ciobanu wrote: > Warren Togami wrote: >> >> http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ >> If you use wireless on ANY arch of rawhide, please test this latest >> wireless-tools build. We need to be sure that the x86_64 fix doesn't >> break i386 or ppc*. This version (28-3) fixed the segfault cause by iwlist under 28-2. Tested on: os: 2.6.21-1.3116.fc7.x86_64 driver: zd1211rw_mac80211 eric From hughsient at gmail.com Tue May 15 16:06:59 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 May 2007 17:06:59 +0100 Subject: F7T4 -- I tried the Nouveau driver from the LiveCD and hit major problems In-Reply-To: <1179183879.24664.62.camel@localhost.localdomain> References: <1178126572.29891.2.camel@rousalka.dyndns.org> <200705021230.47824.jkeating@redhat.com> <604aa7910705021419o744748dbw8d1641b6e8fcbaf7@mail.gmail.com> <1178201382.16280.3.camel@localhost.localdomain> <1178203980.2733.18.camel@hughsie-laptop> <1179183879.24664.62.camel@localhost.localdomain> Message-ID: <15e53e180705150906u54d278d0ucf5aeb7b5290b5a9@mail.gmail.com> On 15/05/07, Adam Jackson wrote: > On Thu, 2007-05-03 at 15:53 +0100, Richard Hughes wrote: > > On Thu, 2007-05-03 at 10:09 -0400, Adam Jackson wrote: > > > Could certainly deliver it as a different binary RPM. This is like > > > five minutes of work, if we think it's worth doing. > > > > Yes, PLEASE PRETTY PLEASE. :-) I can then rebuild daily snapshots of > > nouveau ddx automatically without playing about with the nv RPM. > > This is done now as of 2.0.2-2. > > BIG FREAKING WARNING: If you're using nouveau, and for some reason > decide to upgrade just xorg-x11-drv-nv, you will lose your driver. > Plain yum upgrade should work though, as xorg-x11-drivers has been > updated to depend on xorg-x11-drv-nouveau. Very cool. Thanks for doing this. Richard. From sundaram at fedoraproject.org Tue May 15 16:21:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 21:51:39 +0530 Subject: Fedora Core base system package list In-Reply-To: <46494BA7.6080406@quantumfx.com> References: <46494BA7.6080406@quantumfx.com> Message-ID: <4649DE13.2030604@fedoraproject.org> Carlos Ramirez wrote: > Is there a file, web page or command that can provide a list of packages > that are part of the Fedora base system? I tried searching in various > places without much luck. Any help in the right direct is appreciated. > Try #yum list . Use fedoraforum.org or fedora-list for end user questions. Rahul From lsof at nodata.co.uk Tue May 15 16:51:32 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 15 May 2007 18:51:32 +0200 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <4649B731.1040704@odu.neva.ru> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> <464889F0.5040505@redhat.com> <4649B731.1040704@odu.neva.ru> Message-ID: <1179247893.3569.9.camel@sb-home> Am Dienstag, den 15.05.2007, 17:35 +0400 schrieb Dmitry Butskoy: > Vladimir Makarov wrote: > > Alexander Bokovoy wrote: > > > >> Simo, Vladimir, folks, > >> > >> please stop distributing this crap. It is unfortunate drop of black PR > >> from our enemies during current discussions on improving legality of > >> software in schools at Russian government. But it is far from reality. > >> > >> > > Alexander, I am really sorry about this. My appologies. I did not > > know that it was April 1st joke. I read this just recently and took > > it seriously. Probably my knowledege about modern Russia is not > > adequate anymore. I left it ten years ago. > > > >> The case described below is April, 1st joke which was created by > >> www.securitylab.ru portal (a good one!) but went largely unnoticed until > >> someone showed it to general IT media without linking to the original. > >> > >> http://www.securitylab.ru/news/293577.php > >> > > What do you speak about now? > > To be clearly understood: > The Russian case described is not "a joke", unfortunately. > > Certainly, it is (still) not wide-spread, but I hear about such a threat > at each RHEL-related seminar now. A user ask "what about if I just > download from Internet", the "official" answer is "it is dangerous, > because your computers can be confiscated etc...", and "if you don't > want such troubles, buy (our) box with some license paper..." > Did you experience this yourself first hand, or hear it off someone at a conference? Did they experience it first hand? From Michael_E_Brown at dell.com Tue May 15 17:04:23 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 15 May 2007 12:04:23 -0500 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <1179243659.16274.40.camel@localhost.localdomain> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> Message-ID: <20070515170422.GB23349@humbolt.us.dell.com> On Tue, May 15, 2007 at 11:40:59AM -0400, Adam Jackson wrote: > On Tue, 2007-05-15 at 17:14 +0200, Patrice Dumas wrote: > > On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: > > > Author: ajax > > > + mkdir -p ${DESTDIR}${MANDIR} > > > + cp powertop.1 ${DESTDIR}${MANDIR} > > > > cp -p would keep timestamps. Maybe not worth it if powertop.1 is > > generated, I haven't checked... > > It isn't. Why would I care about timestamp? Packaging guidelines state that it is preferrable to keep timestamps on installed files the same as what was packaged. -- Michael From fedora at leemhuis.info Tue May 15 17:15:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 19:15:07 +0200 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <20070515170422.GB23349@humbolt.us.dell.com> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> <20070515170422.GB23349@humbolt.us.dell.com> Message-ID: <4649EA9B.9090802@leemhuis.info> On 15.05.2007 19:04, Michael E Brown wrote: > On Tue, May 15, 2007 at 11:40:59AM -0400, Adam Jackson wrote: >> On Tue, 2007-05-15 at 17:14 +0200, Patrice Dumas wrote: >>> On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: >>>> Author: ajax >>>> + mkdir -p ${DESTDIR}${MANDIR} >>>> + cp powertop.1 ${DESTDIR}${MANDIR} >>> cp -p would keep timestamps. Maybe not worth it if powertop.1 is >>> generated, I haven't checked... >> It isn't. Why would I care about timestamp? > Packaging guidelines state that it is preferrable to keep timestamps on > installed files the same as what was packaged. Well, to give a better reasons than "because it's written": for multilib installs it's important that the timestamps are identical for files that are in both the i386 and x86_64 packages. And (in the long term) making sure the timestamp didn't get changed might make things easier for presto as well. Cu thl From mclasen at redhat.com Tue May 15 17:16:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 15 May 2007 13:16:50 -0400 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <4649EA9B.9090802@leemhuis.info> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> <20070515170422.GB23349@humbolt.us.dell.com> <4649EA9B.9090802@leemhuis.info> Message-ID: <1179249410.10173.0.camel@localhost.localdomain> On Tue, 2007-05-15 at 19:15 +0200, Thorsten Leemhuis wrote: > On 15.05.2007 19:04, Michael E Brown wrote: > > On Tue, May 15, 2007 at 11:40:59AM -0400, Adam Jackson wrote: > >> On Tue, 2007-05-15 at 17:14 +0200, Patrice Dumas wrote: > >>> On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: > >>>> Author: ajax > >>>> + mkdir -p ${DESTDIR}${MANDIR} > >>>> + cp powertop.1 ${DESTDIR}${MANDIR} > >>> cp -p would keep timestamps. Maybe not worth it if powertop.1 is > >>> generated, I haven't checked... > >> It isn't. Why would I care about timestamp? > > Packaging guidelines state that it is preferrable to keep timestamps on > > installed files the same as what was packaged. > > Well, to give a better reasons than "because it's written": for multilib > installs it's important that the timestamps are identical for files that > are in both the i386 and x86_64 packages. > > And (in the long term) making sure the timestamp didn't get changed > might make things easier for presto as well. > For once I have to agree with David Woodhouse: including timestamps into file identity tests is seriously misguided. From mschwendt.tmp0701.nospam at arcor.de Tue May 15 17:20:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 15 May 2007 19:20:54 +0200 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <4649EA9B.9090802@leemhuis.info> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> <20070515170422.GB23349@humbolt.us.dell.com> <4649EA9B.9090802@leemhuis.info> Message-ID: <20070515192054.7755c500.mschwendt.tmp0701.nospam@arcor.de> On Tue, 15 May 2007 19:15:07 +0200, Thorsten Leemhuis wrote: > > >>>> Author: ajax > >>>> + mkdir -p ${DESTDIR}${MANDIR} > >>>> + cp powertop.1 ${DESTDIR}${MANDIR} > >>> cp -p would keep timestamps. Maybe not worth it if powertop.1 is > >>> generated, I haven't checked... > >> It isn't. Why would I care about timestamp? > > Packaging guidelines state that it is preferrable to keep timestamps on > > installed files the same as what was packaged. > > Well, to give a better reasons than "because it's written": for multilib > installs it's important that the timestamps are identical for files that > are in both the i386 and x86_64 packages. > > And (in the long term) making sure the timestamp didn't get changed > might make things easier for presto as well. For documentation files and scripts -- and files in general ;) -- it is nice to know when a file is several years old. For %config files it is great when mtime only changes when a file is updated actually. From buc at odusz.so-cdu.ru Tue May 15 17:24:43 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 May 2007 21:24:43 +0400 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <1179247893.3569.9.camel@sb-home> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> <464889F0.5040505@redhat.com> <4649B731.1040704@odu.neva.ru> <1179247893.3569.9.camel@sb-home> Message-ID: <4649ECDB.2030500@odu.neva.ru> nodata wrote: > Am Dienstag, den 15.05.2007, 17:35 +0400 schrieb Dmitry Butskoy: >> Certainly, it is (still) not wide-spread, but I hear about such a threat >> at each RHEL-related seminar now. A user ask "what about if I just >> download from Internet", the "official" answer is "it is dangerous, >> because your computers can be confiscated etc...", and "if you don't >> want such troubles, buy (our) box with some license paper..." >> >> > > Did you experience this yourself first hand, Fortunately, still no. > or hear it off someone at a conference? Yes. It has begun recently. On each conference, more "off everyone" rather than "off someone". > Did they experience it first hand? > They know the actual cases. I am inclined to trust them. Besides that, I know about some cases from independent sources (off non-software people). It is enough to start worry. ~buc From buc at odusz.so-cdu.ru Tue May 15 17:30:55 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 15 May 2007 21:30:55 +0400 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <1179247893.3569.9.camel@sb-home> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> <464889F0.5040505@redhat.com> <4649B731.1040704@odu.neva.ru> <1179247893.3569.9.camel@sb-home> Message-ID: <4649EE4F.5080409@odu.neva.ru> nodata wrote: >>> Alexander, I am really sorry about this. My appologies. I did not >>> know that it was April 1st joke. I read this just recently and took >>> it seriously. Probably my knowledege about modern Russia is not >>> adequate anymore. I left it ten years ago. >>> >>> >>>> The case described below is April, 1st joke which was created by >>>> www.securitylab.ru portal (a good one!) but went largely unnoticed until >>>> someone showed it to general IT media without linking to the original. >>>> >>>> http://www.securitylab.ru/news/293577.php >>>> >>>> >> What do you speak about now? >> >> To be clearly understood: >> The Russian case described is not "a joke", unfortunately. >> >> Certainly, it is (still) not wide-spread, but I hear about such a threat >> at each RHEL-related seminar now. A user ask "what about if I just >> download from Internet", the "official" answer is "it is dangerous, >> because your computers can be confiscated etc...", and "if you don't >> want such troubles, buy (our) box with some license paper..." >> >> > > Did you experience this yourself first hand, or hear it off someone at a > conference? Did they experience it first hand? > nswer > Oops, it seems you ask about the joke, but I answer about the actual troubles. Surely my post above is not about the joke :) ~buc From Jerry.James at usu.edu Tue May 15 17:35:04 2007 From: Jerry.James at usu.edu (Jerry James) Date: Tue, 15 May 2007 11:35:04 -0600 Subject: rawhide merge status In-Reply-To: <200705141920.06902.ville.skytta@iki.fi> (Ville Skytt's message of "Mon, 14 May 2007 19:20:06 +0300") References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> <200705141920.06902.ville.skytta@iki.fi> Message-ID: On Mon, 14 May 2007 at 19:20:06 +0300 Ville Skytt? wrote: > I don't think so. Providing eg. moodle-zh_tw = %{version}-%{release} in > itself is redundant. One thing that you may want to have a look in the above > is that there are self-obsoletion problems - changing those to these in both > zh_cn and zh_tw could help (assuming %{version} is greater than or equal to > 1.6.4): > > Obsoletes: moodle-zh < 1.6.4 > Provides: moodle-zh = %{version}-%{release} > > Or perhaps drop the Provides altogether? See > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d I decided that dropping the Provides altogether was the best approach. For one thing, the old language packs being obsoleted weren't the real language packs; they only contained translations for the installation code. For another, they were in the wrong place, so they didn't work anyway. Hence, it is unlikely that anybody actually used them. Thanks, Ville. -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From Jerry.James at usu.edu Tue May 15 17:37:08 2007 From: Jerry.James at usu.edu (Jerry James) Date: Tue, 15 May 2007 11:37:08 -0600 Subject: rawhide merge status In-Reply-To: <20070514183749.GN5267@nostromo.devel.redhat.com> (Bill Nottingham's message of "Mon, 14 May 2007 14:37:49 -0400") References: <20070512134333.GB16522@nostromo.devel.redhat.com> <20070514131138.GA19176@dudweiler.stuttgart.redhat.com> <20070514183749.GN5267@nostromo.devel.redhat.com> Message-ID: On Mon, 14 May 2007 at 14:37:49 -0400 Bill Nottingham wrote: > Note that for things like comps, there is only one languge support group > per language (Chinese, Serbian, etc.); so leaving them together probably > won't hurt. I took this step because upstream supplies separate files per language. Separating them out so that there is one subpackage per upstream file makes it easier for me to see when an update is necessary for some language. I don't know that moodle users care so much; I'm just trying to make maintenance easy for me. Regards, -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From ajackson at redhat.com Tue May 15 17:37:53 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 15 May 2007 13:37:53 -0400 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <4649EA9B.9090802@leemhuis.info> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> <20070515170422.GB23349@humbolt.us.dell.com> <4649EA9B.9090802@leemhuis.info> Message-ID: <1179250673.16274.44.camel@localhost.localdomain> On Tue, 2007-05-15 at 19:15 +0200, Thorsten Leemhuis wrote: > On 15.05.2007 19:04, Michael E Brown wrote: > > On Tue, May 15, 2007 at 11:40:59AM -0400, Adam Jackson wrote: > >> On Tue, 2007-05-15 at 17:14 +0200, Patrice Dumas wrote: > >>> On Tue, May 15, 2007 at 09:01:41AM -0400, Adam Jackson wrote: > >>>> Author: ajax > >>>> + mkdir -p ${DESTDIR}${MANDIR} > >>>> + cp powertop.1 ${DESTDIR}${MANDIR} > >>> cp -p would keep timestamps. Maybe not worth it if powertop.1 is > >>> generated, I haven't checked... > >> It isn't. Why would I care about timestamp? > > Packaging guidelines state that it is preferrable to keep timestamps on > > installed files the same as what was packaged. > > Well, to give a better reasons than "because it's written": for multilib > installs it's important that the timestamps are identical for files that > are in both the i386 and x86_64 packages. It's not a multilib package, but sure, why not. - ajax From lsof at nodata.co.uk Tue May 15 17:41:38 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 15 May 2007 19:41:38 +0200 Subject: rpms/powertop/devel powertop-1.2-install-man-page.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 powertop.spec, 1.2, 1.3 sources, 1.3, 1.4 powertop-1.1-build-fixes.patch, 1.1, NONE In-Reply-To: <20070515192054.7755c500.mschwendt.tmp0701.nospam@arcor.de> References: <200705151301.l4FD1fZg024328@cvs-int.fedora.redhat.com> <20070515151421.GF2815@free.fr> <1179243659.16274.40.camel@localhost.localdomain> <20070515170422.GB23349@humbolt.us.dell.com> <4649EA9B.9090802@leemhuis.info> <20070515192054.7755c500.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1179250898.3569.16.camel@sb-home> Am Dienstag, den 15.05.2007, 19:20 +0200 schrieb Michael Schwendt: > On Tue, 15 May 2007 19:15:07 +0200, Thorsten Leemhuis wrote: > > > > > >>>> Author: ajax > > >>>> + mkdir -p ${DESTDIR}${MANDIR} > > >>>> + cp powertop.1 ${DESTDIR}${MANDIR} > > >>> cp -p would keep timestamps. Maybe not worth it if powertop.1 is > > >>> generated, I haven't checked... > > >> It isn't. Why would I care about timestamp? > > > Packaging guidelines state that it is preferrable to keep timestamps on > > > installed files the same as what was packaged. > > > > Well, to give a better reasons than "because it's written": for multilib > > installs it's important that the timestamps are identical for files that > > are in both the i386 and x86_64 packages. > > > > And (in the long term) making sure the timestamp didn't get changed > > might make things easier for presto as well. > > For documentation files and scripts -- and files in general ;) -- it is > nice to know when a file is several years old. For %config files it is > great when mtime only changes when a file is updated actually. > +1 From lsof at nodata.co.uk Tue May 15 18:01:24 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 15 May 2007 20:01:24 +0200 Subject: [Fwd: Re: Legality of Fedora in production environment] In-Reply-To: <4649EE4F.5080409@odu.neva.ru> References: <1179157263.29833.1.camel@willson> <46488512.2020803@samba.org> <464889F0.5040505@redhat.com> <4649B731.1040704@odu.neva.ru> <1179247893.3569.9.camel@sb-home> <4649EE4F.5080409@odu.neva.ru> Message-ID: <1179252084.7302.0.camel@sb-home> Am Dienstag, den 15.05.2007, 21:30 +0400 schrieb Dmitry Butskoy: > nodata wrote: > >>> Alexander, I am really sorry about this. My appologies. I did not > >>> know that it was April 1st joke. I read this just recently and took > >>> it seriously. Probably my knowledege about modern Russia is not > >>> adequate anymore. I left it ten years ago. > >>> > >>> > >>>> The case described below is April, 1st joke which was created by > >>>> www.securitylab.ru portal (a good one!) but went largely unnoticed until > >>>> someone showed it to general IT media without linking to the original. > >>>> > >>>> http://www.securitylab.ru/news/293577.php > >>>> > >>>> > >> What do you speak about now? > >> > >> To be clearly understood: > >> The Russian case described is not "a joke", unfortunately. > >> > >> Certainly, it is (still) not wide-spread, but I hear about such a threat > >> at each RHEL-related seminar now. A user ask "what about if I just > >> download from Internet", the "official" answer is "it is dangerous, > >> because your computers can be confiscated etc...", and "if you don't > >> want such troubles, buy (our) box with some license paper..." > >> > >> > > > > Did you experience this yourself first hand, or hear it off someone at a > > conference? Did they experience it first hand? > > nswer > > > Oops, it seems you ask about the joke, but I answer about the actual > troubles. Surely my post above is not about the joke :) > > > ~buc > I was asking about real life. There seems to be some confusion between the joke and real life, and I wanted to find out if you had first hand experience, or were passing on information from other people who had been fooled by the joke... From pp at ee.oulu.fi Tue May 15 19:11:26 2007 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 15 May 2007 22:11:26 +0300 Subject: Wireless Testing Needed for F7 In-Reply-To: <4648AFFF.80906@redhat.com> References: <4648AFFF.80906@redhat.com> Message-ID: <20070515191126.GA15534@ee.oulu.fi> On Mon, May 14, 2007 at 02:52:47PM -0400, Warren Togami wrote: > If you use wireless on ANY arch of rawhide, please test this latest > wireless-tools build. We need to be sure that the x86_64 fix doesn't > break i386 or ppc*. Well, not rawhide but FC6 with rawhide kernel (--nodeps, looks like I don't need the newer mkinitrd :) ) + wireless-tools-28-3.fc7, i386 and aironet. Other than the 22 vs. 20 warning everything works just like before, iwlist, NM etc. -- Pekka Pietikainen From wcohen at redhat.com Tue May 15 19:28:15 2007 From: wcohen at redhat.com (William Cohen) Date: Tue, 15 May 2007 15:28:15 -0400 Subject: Looking for GUI application programs for experiments Message-ID: <464A09CF.6030303@redhat.com> Hi all, I am working with a couple researchers at North Carolina State University looking at the TLB behavior. Past studies in this area have used statically linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application available on the desktop. We would like to have a sampling of workload programs that are more like the typical programs that people use on desktop machines. The characteristics we are looking for in the examples are: -represent commonly-performed tasks, e.g. edit file and view document -depend on a number of dynamically-linked libraries -use GUI -have built-in accessibility features needed to automate the experiment with dogtail -run for a couple seconds, so instrumented version doesn't take too long -doesn't require network access Currently, we have some example workloads using gthumb, evince, and abiword. They are driven by dogtail. We are looking for some additional examples to round out the experiments. Some GUI tests might be suitable for this, but would like to have examples that are more like normal person might use the software rather than a minimal test cases. -Will From wolfy at nobugconsulting.ro Tue May 15 19:35:55 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 15 May 2007 22:35:55 +0300 Subject: Looking for GUI application programs for experiments In-Reply-To: <464A09CF.6030303@redhat.com> References: <464A09CF.6030303@redhat.com> Message-ID: <464A0B9B.4040502@nobugconsulting.ro> On 05/15/2007 10:28 PM, William Cohen wrote: > Hi all, > > I am working with a couple researchers at North Carolina State > University looking at the TLB behavior. Past studies in this area have > used statically linked programs like SPEC CPU to provide workload for > the simulator. This is very different than the typical shared-library, > GUI application available on the desktop. We would like to have a > sampling of workload programs that are more like the typical programs > that people use on desktop machines. The characteristics we are > looking for in the examples are: > > -represent commonly-performed tasks, e.g. edit file and view document > -depend on a number of dynamically-linked libraries > -use GUI > -have built-in accessibility features needed to automate the > experiment with dogtail > -run for a couple seconds, so instrumented version doesn't take too long > -doesn't require network access > > Currently, we have some example workloads using gthumb, evince, and > abiword. They are driven by dogtail. We are looking for some > additional examples to round out the experiments. Some GUI tests might > be suitable for this, but would like to have examples that are more > like normal person might use the software rather than a minimal test > cases. > > -Will > my colleagues are very fond of nedit From jspaleta at gmail.com Tue May 15 21:40:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 15 May 2007 13:40:59 -0800 Subject: Looking for GUI application programs for experiments In-Reply-To: <464A09CF.6030303@redhat.com> References: <464A09CF.6030303@redhat.com> Message-ID: <604aa7910705151440n7ffd2feci6d1ac6fb7acd9b61@mail.gmail.com> On 5/15/07, William Cohen wrote: > The > characteristics we are looking for in the examples are: > > -represent commonly-performed tasks, e.g. edit file and view document > -depend on a number of dynamically-linked libraries > -use GUI > -have built-in accessibility features needed to automate the > experiment with dogtail > -run for a couple seconds, so instrumented version doesn't take too long > -doesn't require network access Have you looked at the mugshot compiled stats for most commonly used applications for registered mugshot users who are running fedora? http://mugshot.org/applications I think gedit and evince are obvious candidates, but pretty much all the gtk based applications that are highly ranked should work for you. -jef From notting at redhat.com Tue May 15 21:43:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 May 2007 17:43:34 -0400 Subject: rawhide report: 20070515 changes Message-ID: <20070515214334.GA29257@nostromo.devel.redhat.com> New package boolstuff Disjunctive Normal Form boolean expression library New package leafpad GTK+ based simple text editor New package machineball A futuristic ball game with simple rules New package mapserver Environment for building spatially-enabled internet applications New package penguin-command Open source arcade game New package perl-mecab Perl binding for MeCab New package pmount Enable normal user mount New package powertop Power consumption monitor New package python-mecab Python binding for MeCab New package ruby-amazon Ruby interface to Amazon Web Services New package ruby-gettext-package Localization Library and Tools for Ruby New package ruby-mecab Ruby binding for MeCab New package xu4 Ultima IV recreated Removed package SysVinit Removed package gaim-meanwhile Removed package cdrtools Updated Packages: arts-8:1.5.6-3.fc7 ------------------ * Mon May 14 2007 Rex Dieter - 6:1.5.6-3 - BR: nas-devel jack-audio-connection-kit-devel - omit extraneous .la file references (#178733) - -devel: Requires: qt-devel pkgconfig blender-2.42a-24.fc7 -------------------- * Wed May 09 2007 Jochen Schmitt 2.42a-24 - Remove ffmpeg lib during a legal issue (#239476) dap-server-3.7.4-3.fc7 ---------------------- * Sat May 05 2007 Patrice Dumas 3.7.4-3 - update patch, perl(CGI) is not needed * Mon Apr 30 2007 Patrice Dumas 3.7.4-2 - update to 3.7.4 - fix security issue - remove config files upstreamed patch digikam-0.9.1-3.fc7 ------------------- * Mon May 14 2007 Rex Dieter 0.9.1-3 - respin against libkexiv2-0.1.5 - preserve upstream .desktop vendor (f7 branch at least) * Mon Apr 02 2007 Rex Dieter 0.9.1-2 - exiv2-0.14 patch - cleanup/simplify BR's,Requires,d-f-i usage * Fri Mar 09 2007 Marcin Garski 0.9.1-1 - Update to version 0.9.1 - Update BuildRequires dvb-apps-1.1.1-8.fc7 -------------------- * Sun May 13 2007 Ville Skytt? - 1.1.1-8 - Update tuning files to 20070513. - Drop non-upstream license file. eclipse-cdt-1:3.1.2-3.fc7 ------------------------- * Mon Apr 16 2007 Jeff Johnston 3.1.2-3 - Add missing gif to org.eclipse.cdt.make.ui. - Resolves: #236558 em8300-0.16.2-1.fc7 ------------------- * Mon May 07 2007 Ville Skytt? - 0.16.2-1 - 0.16.2. * Wed Apr 04 2007 Ville Skytt? - 0.16.2-0.1.rc1 - 0.16.2-rc1. - Update examples in README-modprobe.conf. * Thu Mar 01 2007 Ville Skytt? - 0.16.1-1 - 0.16.1. fontconfig-2.4.2-3.fc7 ---------------------- * Fri May 11 2007 Matthias Clasen - 2.4.2-3 - Add Liberation fonts to 30-aliases-fedora.conf fonts-hebrew-fancy-0.20051122-2.fc7 ----------------------------------- * Mon May 14 2007 Rex Dieter 0.20051122-2 - robust scriptlets (#238917) gaim-otr-3.0.1-0.6.20060712cvs.fc7 ---------------------------------- * Fri May 11 2007 Stu Tomlinson 3.0.1-0.5.20060712cvs - Actually fix it to work with Pidgin * Wed Apr 18 2007 Paul Wouters 3.0.1-0.4.20060921cvs - Support for the rename of gaim to pidgin gdal-1.4.1-3.fc7 ---------------- * Sat May 12 2007 Balint Cristian 1.4.1-3 - re-build against grass. * Fri May 11 2007 Balint Cristian 1.4.1-2 - fix python lookup paths for ppc64. * Wed May 09 2007 Balint Cristian 1.4.1-1 - new upstream release. - disable temporary grass-devel requirement untill find a resonable solution for gdal-grass egg-chicken dep problem. gnash-0.7.2-2.fc7 ----------------- * Wed May 09 2007 Patrice Dumas 0.7.2-2 - fix CVE-2007-2500 (fix 239213) gnome-commander-1.2.3-6.fc7.1 ----------------------------- grass-6.2.1-16.fc7 ------------------ * Sat May 12 2007 Balint Cristian 6.2.1-16 - fix koji build for ppc ppc64, dont use _host macro anymore. * Sat May 12 2007 Balint Cristian 6.2.1-15 - rebuild against new gdal hdf-4.2r1-14.fc7 ---------------- * Thu May 10 2007 Balint Cristian 4.2r1-14 - Fix ppc64 too. * Thu May 10 2007 Orion Poplawski 4.2r1-13 - Remove netcdf-devel requires. (bug #239631) * Fri Apr 20 2007 Orion Poplawski 4.2r1-12 - Use 4.2r1-hrepack-p4.tar.gz for hrepack patch - Remove configure patch applied upstream - Use --disable-production configure flag to avoid stripping -g compile flag - Add patch to fix open file test when run under mock htmldoc-1.8.27-2.fc7 -------------------- * Sat May 05 2007 Adam Goode - 1.8.27-2 - Remove X-Fedora hyperestraier-1.4.10-1.fc7.2 ---------------------------- jd-1.8.8-1.fc7.2 ---------------- * Fri May 04 2007 Mamoru Tasaka - 1.8.8-1.dist.2 - rebuild jfbterm-0.4.7-10.fc7.1 ---------------------- kazehakase-0.4.6-1.fc7.1 ------------------------ kernel-2.6.21-1.3149.fc7 ------------------------ * Thu May 10 2007 Dave Jones - Disable RTC class CMOS driver. * Thu May 10 2007 Dave Jones - GFS2 updates * Wed May 09 2007 Dave Jones - Disable some debug config options. kipi-plugins-0.1.3-5.fc7 ------------------------ * Mon May 14 2007 Rex Dieter 0.1.3-5 - respin against libkexiv2-0.1.5 kita-0.177.3-10.fc7.1 --------------------- libgda-1:1.9.100-12.fc7 ----------------------- * Thu May 10 2007 Hans de Goede 1:1.9.100-12 - Don't build mono/sharp bits on ppc64 - Fixup packaging of sharp bindings to match the mono packaging guidelines * Fri Dec 15 2006 Hans de Goede 1:1.9.100-11 - Rebuild for new postgres * Mon Aug 28 2006 Hans de Goede 1:1.9.100-10 - FE6 Rebuild libgnomedb-1:1.9.100-15.fc7 --------------------------- * Thu May 10 2007 Hans de Goede 1:1.9.100-15 - Don't build mono/sharp bits on ppc64 libkexiv2-0.1.5-1.fc7 --------------------- * Mon May 14 2007 Rex Dieter 1.1.5-1 - libkexiv2-0.1.5 libtcd-2.2.2-1.fc7.1 -------------------- libvirt-0.2.2-4.fc7 ------------------- * Mon May 14 2007 Daniel P. Berrange - 0.2.2-4.fc7 - Fixed uninitialized value causing stack overflow - Fixed bridged networking when no virtual network is defined (bz 239273) liferea-1.2.10c-2.fc7 --------------------- * Sat May 12 2007 Brian Pepple - 1.2.10c-2 - Add patch to fix cpu from waking up frequently. (#239945) listen-0.5-15.fc7.1 ------------------- * Mon May 07 2007 Ha?kel Gu?mar 0.5-15 - ppc64 build enabled again. * Fri May 04 2007 Ha?kel Gu?mar 0.5-14 - ppc64 build temporary disabled. * Thu May 03 2007 Ha?kel Gu?mar 0.5-14 - fixed typo in desktop file - fixed dbus issue (upstream bug #566) courtesy of Martin Sourada manedit-0.8.1-1.fc7.1 --------------------- mecab-0.95-2.fc7.2 ------------------ * Fri May 04 2007 Mamoru Tasaka - 0.95-2.dist.2 - rebuild mecab-ipadic-2.7.0.20060707-2.fc7.1 ----------------------------------- mecab-jumandic-5.1.20070304-1.fc7.1 ----------------------------------- mirage-0.8.3-1.fc7.1 -------------------- notification-daemon-0.3.7-2.fc7 ------------------------------- * Mon May 14 2007 Matthias Clasen - 0.3.7-2 - Escape markup in summaries (#239950) ochusha-0.5.99.66-0.2.cvs070110.fc7.1 ------------------------------------- opensc-0.11.2-2.fc7 ------------------- * Sun May 06 2007 Ville Skytt? - 0.11.2-2 - Add explicit build dependency on ncurses-devel. * Sat May 05 2007 Ville Skytt? - 0.11.2-1 - 0.11.2. pam_abl-0.2.3-3.fc7 ------------------- * Sun May 13 2007 Alexander Dalloz - 0.2.3-3 - Rebuild to fix #219947. panelfm-1.2-2.fc7.1 ------------------- perl-CGI-Ex-2.12-1.fc7 ---------------------- * Sun May 13 2007 Chris Weyl 2.12-1 - update to 2.12 * Wed May 09 2007 Chris Weyl 2.11-1 - update to 2.11 - add split br's perl-Data-Alias-1.04-1.fc7 -------------------------- * Fri May 04 2007 Chris Weyl 1.04-1 - update to 1.04 - add t/ to %doc - perl splittage BR's added * Mon Mar 19 2007 Chris Weyl 1.03-1 - update to 1.03 perl-JSON-1.14-1.fc7 -------------------- * Sun May 13 2007 Chris Weyl 1.14-1 - update to 1.14 perl-Moose-0.21-1.fc7 --------------------- * Fri May 04 2007 Chris Weyl 0.21-1 - update to 0.21 * Tue May 01 2007 Chris Weyl 0.20-2 - add t/ to %doc - add br for optional test #7 * Sat Apr 07 2007 Chris Weyl 0.20-1 - update to 0.20 - add additional BR's for new optional tests perl-POE-Component-Client-Keepalive-0.1000-1.fc7 ------------------------------------------------ * Sun May 13 2007 Chris Weyl 0.1000-1 - update to 0.1000 - add t/ to %doc - perl splittage BR tweaks perl-POE-Component-IRC-5.29-1.fc7 --------------------------------- * Sat May 05 2007 Chris Weyl 5.29-1 - update to 5.29 * Wed May 02 2007 Chris Weyl 5.28-1 - update to 5.28 perl-POE-Component-SSLify-0.07-1.fc7 ------------------------------------ * Sun May 06 2007 Chris Weyl 0.07-1 - update to 0.07 - add t/ to %doc - some spec rework due to perl splittage pygame-1.7.1-13.fc7 ------------------- * Sat May 12 2007 Christopher Stone 1.7.1-13 - Apply 64-bit patch for python 2.5 (bz #239899) - Some minor spec file cleanups pykickstart-1.1-1.fc7 --------------------- * Mon May 14 2007 Chris Lumens - 1.1-1 - Better regexes for splitting version strings into family and version. - Add basic support for RHEL3. - Update translations. python-kaa-metadata-0.6.1-4.fc7 ------------------------------- * Tue May 01 2007 kwizart < kwizart at gmail.com > - 0.6.1-4 - Fix Obsolete also for mmpython 0.4.10 qdbm-1.8.75-1.fc7.1 ------------------- redhat-artwork-7.0.0-7.fc7 -------------------------- * Mon May 14 2007 Matthias Clasen 7.0.0-7 - Fix broken dependencies of the kde subpackage * Thu May 10 2007 Matthias Clasen 7.0.0-4 - move qt bits to -kde, too - Fix file ownership in the -kde subpackage (#239495) * Thu May 10 2007 Matthias Clasen 7.0.0-3 - Fix userlist in kdm (#239644) - Fix some issues with the -kde subpackage (#239495) ruby-zoom-0.2.2-2.fc7.1 ----------------------- samba-0:3.0.25-2.fc7 -------------------- * Mon May 14 2007 Simo Sorce - final 3.0.25 - includes security fixes for CVE-2007-2444,CVE-2007-2446,CVE-2007-2447 * Mon Apr 30 2007 Guenther Deschner - move to 3.0.25rc3 * Thu Apr 19 2007 Simo Sorce - fixes in the spec file - moved to 3.0.25rc1 - addedd patches (merged upstream so they will be removed in 3.0.25rc2) sparse-0.3-1.fc7 ---------------- * Thu May 03 2007 Roland McGrath - 0.3-1 - Upgrade to 0.3 tcd-utils-20061127-1.fc7.1 -------------------------- tideEditor-1.4.1-1.fc7.1 ------------------------ vdr-femon-1.1.2-1.fc7 --------------------- * Thu May 03 2007 Ville Skytt? - 1.1.2-1 - 1.1.2. wireless-tools-1:28-3.fc7 ------------------------- * Mon May 14 2007 Christopher Aillon - 1:28-3 - Only the sscanf fixes this time. xorg-x11-drv-i810-2.0.0-3.fc7 ----------------------------- * Mon May 14 2007 Adam Jackson 2.0.0-3 - intel-2.0-vblank-power-savings.patch: Disable vblank interrupts when no DRI clients are active, for better battery life. xorg-x11-server-1.3.0.0-5.fc7 ----------------------------- * Fri May 11 2007 Adam Jackson 1.3.0.0-5 - xserver-1.3.0-fbdevhw-magic-numbers.patch: If the fbdev driver claims to have a zero pixel clock, believe it. Fixes Xen paravirt. (#238451) xscreensaver-1:5.02-1.fc7.1 --------------------------- xtide-2.9.3-1.fc7.1 ------------------- From caillon at redhat.com Tue May 15 21:47:14 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 15 May 2007 17:47:14 -0400 Subject: Making beagle optional In-Reply-To: <1179170887.3250.5.camel@sb-home> References: <1179154692.3560.23.camel@localhost.localdomain> <1179170887.3250.5.camel@sb-home> Message-ID: <464A2A62.60804@redhat.com> nodata wrote: > Please can you also disable the firefox plugin if you do this. It gets installed as part of beagle. Beagle not installed => no plugin. From ggw at wolves.durham.nc.us Tue May 15 21:53:33 2007 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Tue, 15 May 2007 17:53:33 -0400 Subject: rawhide report: 20070515 changes - SysVinit? In-Reply-To: <20070515214334.GA29257@nostromo.devel.redhat.com> References: <20070515214334.GA29257@nostromo.devel.redhat.com> Message-ID: <20070515215333.GA11333@wolves.durham.nc.us> On Tue, May 15, 2007 at 05:43:34PM -0400, Bill Nottingham wrote: > Removed package SysVinit What is replacing this package? What did I miss? -- Wolfe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 15 21:54:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 17:54:00 -0400 Subject: rawhide report: 20070515 changes - SysVinit? In-Reply-To: <20070515215333.GA11333@wolves.durham.nc.us> References: <20070515214334.GA29257@nostromo.devel.redhat.com> <20070515215333.GA11333@wolves.durham.nc.us> Message-ID: <200705151754.00913.jkeating@redhat.com> On Tuesday 15 May 2007 17:53:33 G.Wolfe Woodbury wrote: > What is replacing this package? ?What did I miss? 'sysvinit' is replacing SysVinit. Just a rename. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue May 15 21:47:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 23:47:56 +0200 Subject: rawhide report: 20070515 changes - SysVinit? In-Reply-To: <20070515215333.GA11333@wolves.durham.nc.us> References: <20070515214334.GA29257@nostromo.devel.redhat.com> <20070515215333.GA11333@wolves.durham.nc.us> Message-ID: <20070515214756.GI2828@free.fr> On Tue, May 15, 2007 at 05:53:33PM -0400, G.Wolfe Woodbury wrote: > On Tue, May 15, 2007 at 05:43:34PM -0400, Bill Nottingham wrote: > > > Removed package SysVinit > > What is replacing this package? What did I miss? I think that it is called sysvinit now. -- Pat From cra at WPI.EDU Tue May 15 22:12:39 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 15 May 2007 18:12:39 -0400 Subject: missing i686 debuginfo? Message-ID: <20070515221239.GA31145@angus.ind.WPI.EDU> I'm trying to debug emacs and there is no glibc-debuginfo*.i686 in rawhide. Upon further investigation, it appears that there are no non-i386 debuginfo packages at all in fedora/linux/core/development/i386/debug. I >rpm -qa --qf='%{name}-%{version}-%{release}.%{arch}\n' glibc\* glibc-2.5.90-22.i686 glibc-common-2.5.90-22.i386 glibc-devel-2.5.90-22.i386 glibc-headers-2.5.90-22.i386 lftp download.fedora.redhat.com:/pub/fedora/linux/core/development/i386/debug> dir | grep -v i386 drwxr-xr-x 2 ftp ftp 4096 May 15 07:18 repodata Were these missed in the merge? From orion at cora.nwra.com Tue May 15 22:22:26 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 15 May 2007 16:22:26 -0600 Subject: Reliable rpm database corruption with rawhide In-Reply-To: <4640F4D6.1080809@cora.nwra.com> References: <4640F4D6.1080809@cora.nwra.com> Message-ID: <464A32A2.8040005@cora.nwra.com> Orion Poplawski wrote: > I'm pretty reliably getting rpm database corruption when installing new > packages on a freshly installed system: > [log snipped] > > This has happened for at least three installs over the last couple of > months. As anyone else seen this? > > I'm off to run some memory tests, but I haven't seen any other messages > in the logs and my disk looks pretty good. > Memory tests look good. Just did an install on a fairly different machine (Dual Athlon AMD-760/8 based machine using LVM vs Dell Inspiron 4150 Pentium-4M Intel 82801 no LVM) and got the same RPM corruption during my first yum install on the new system. Install method is the same - pxe boot, nfs install + multiple http repositories. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230362 Does no one else see this? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From alan at redhat.com Tue May 15 22:36:23 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 15 May 2007 18:36:23 -0400 Subject: Looking for GUI application programs for experiments In-Reply-To: <464A09CF.6030303@redhat.com> References: <464A09CF.6030303@redhat.com> Message-ID: <20070515223623.GA30538@devserv.devel.redhat.com> On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote: > linked programs like SPEC CPU to provide workload for the simulator. This > is very different than the typical shared-library, GUI application You know you can catch TLB misses on some real x86 processors I assume ? (You load the page table entry as missing then when you take the trap you put the entry in, touch the page to load it, and then mark it missing again) Alan From ggw at wolves.durham.nc.us Tue May 15 22:47:02 2007 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Tue, 15 May 2007 18:47:02 -0400 Subject: rawhide report: 20070515 changes - SysVinit - Thanks In-Reply-To: <200705151754.00913.jkeating@redhat.com> References: <20070515214334.GA29257@nostromo.devel.redhat.com> <20070515215333.GA11333@wolves.durham.nc.us> <200705151754.00913.jkeating@redhat.com> Message-ID: <20070515224702.GA11992@wolves.durham.nc.us> On Tue, May 15, 2007 at 05:54:00PM -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 17:53:33 G.Wolfe Woodbury wrote: > > What is replacing this package? ?What did I miss? > > 'sysvinit' is replacing SysVinit. Just a rename. > > -- > Jesse Keating > Release Engineer: Fedora Thank You Jesse. -- Wolfe From seg at haxxed.com Tue May 15 23:48:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 15 May 2007 18:48:32 -0500 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <464749D3.3090500@leemhuis.info> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> Message-ID: <1179272912.22044.17.camel@localhost> On Sun, 2007-05-13 at 19:24 +0200, Thorsten Leemhuis wrote: > Just wondering: does Fedora spin down the hard disk by default? It > doesn't afaics and it's not easily user-configurable either afaik. I had laptop-mode installed back during FC6 devel, but a few months ago (after acquiring a newer laptop with an again functional battery...) I noticed it had disappeared. Couldn't find it anywhere. It apparently split off into an independent project: http://www.samwel.tk/laptop_mode/laptop_mode And the only Fedora package for it is in Dries. The hd in this thing is VERY loud for some reason, (Near death? SMART claims its okay...) I tuned it up like so: LM_BATT_MAX_LOST_WORK_SECONDS=600 LM_AC_MAX_LOST_WORK_SECONDS=3600 LM_AC_HD_IDLE_TIMEOUT_SECONDS=40 LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20 Which is highly effective at keeping the drive spun down, pretty much forever, when the system is idle and on AC, and the 20/40 spindown timeout seems to be just enough to prevent obnoxious yo-yoing. Now only if Galeon wouldn't constantly keep the drive spun up... (killall -STOP is my friend...) -------------- 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 May 15 23:54:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 15 May 2007 18:54:36 -0500 Subject: hard disk power down (was: Re: PowerTOP tool released; time to fix the wasted laptop power on fedora?) In-Reply-To: <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> <4647180A.1030800@iinet.net.au> <1179075965.19106.1.camel@laptopd505.fenrus.org> <464749D3.3090500@leemhuis.info> <1179080582.2511.9.camel@hughsie-laptop> <645d17210705140237l60c67b55md4724187e24fad15@mail.gmail.com> Message-ID: <1179273276.22044.20.camel@localhost> On Mon, 2007-05-14 at 10:37 +0100, Jonathan Underwood wrote: > There's another factor here though, as I understand it hard drive > lifetime is largely determined by the spin up/spin down frequency. So > while it may save a bit of power spinning down more often, this might > significantly shorten drive lifetimes. I'd definately want to have an > option to disable that, if my understanding is correct. http://www.samwel.tk/laptop_mode/faq "Desktop hard drives are usually rated for only 40,000-50,000 spinups, and one spinup every 10 minutes will kill your 40,000-spinup HD in 277 days. So this is NOT recommended for server use, unless you increase the spinup interval dramatically, to say once every hour or two. Laptop hard drives are usually rated for around 300,000 spinups, so those will last about 2083 days or 6 years if you have them powered on 24-7." -------------- 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 roland at redhat.com Wed May 16 00:05:30 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 15 May 2007 17:05:30 -0700 (PDT) Subject: missing i686 debuginfo? In-Reply-To: Chuck Anderson's message of Tuesday, 15 May 2007 18:12:39 -0400 <20070515221239.GA31145@angus.ind.WPI.EDU> Message-ID: <20070516000530.2CBBD1F84E6@magilla.localdomain> The builds exist (see http://koji.fedoraproject.org/packages/glibc/). It must be an issue with the distro-making thing, whatever that is this week. From dennis at ausil.us Wed May 16 00:22:50 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 15 May 2007 19:22:50 -0500 Subject: Wireless Testing Needed for F7 In-Reply-To: <4648AFFF.80906@redhat.com> References: <4648AFFF.80906@redhat.com> Message-ID: <200705151922.50717.dennis@ausil.us> Once upon a time Monday 14 May 2007, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 > We are attempting to get wireless working on x86_64. > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > If you use wireless on ANY arch of rawhide, please test this latest > wireless-tools build. We need to be sure that the x86_64 fix doesn't > break i386 or ppc*. > > Please report in the above bug if release -3 is any better or worse than > release -1 or -2. > > We really would like to confirm this before the proposed F7 final freeze > on Thursday. > > Warren Togami > wtogami at redhat.com wireless started working for me with this wireless-tools package. i'm on a Dell Latitude D820 x86_64 with iwl3945 driver Dennis From abartlet at samba.org Wed May 16 00:40:23 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 16 May 2007 10:40:23 +1000 Subject: Wireless Testing Needed for F7 In-Reply-To: <200705151922.50717.dennis@ausil.us> References: <4648AFFF.80906@redhat.com> <200705151922.50717.dennis@ausil.us> Message-ID: <1179276023.2940.69.camel@localhost.localdomain> On Tue, 2007-05-15 at 19:22 -0500, Dennis Gilmore wrote: > Once upon a time Monday 14 May 2007, Warren Togami wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 > > We are attempting to get wireless working on x86_64. > > > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > > If you use wireless on ANY arch of rawhide, please test this latest > > wireless-tools build. We need to be sure that the x86_64 fix doesn't > > break i386 or ppc*. > > > > Please report in the above bug if release -3 is any better or worse than > > release -1 or -2. > > > > We really would like to confirm this before the proposed F7 final freeze > > on Thursday. > > > > Warren Togami > > wtogami at redhat.com > > wireless started working for me with this wireless-tools package. i'm on a > Dell Latitude D820 x86_64 with iwl3945 driver For me, on an Lenovo X60 (x86) with the iwl3945 driver, on the current rawhide kernel (2.6.21-1.3149.fc7) and 28-3 release of the wireless tool this works until NetworkManager does a rescan. This is pretty much in line with what I've been seeing for quite a while over various kernels now (I've never had it work any more than this much, and often worse). 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 selinux at gmail.com Wed May 16 00:52:44 2007 From: selinux at gmail.com (Tom London) Date: Tue, 15 May 2007 17:52:44 -0700 Subject: Wireless Testing Needed for F7 In-Reply-To: <1179276023.2940.69.camel@localhost.localdomain> References: <4648AFFF.80906@redhat.com> <200705151922.50717.dennis@ausil.us> <1179276023.2940.69.camel@localhost.localdomain> Message-ID: <4c4ba1530705151752x2c269464y9b3f98ee79d97d42@mail.gmail.com> On 5/15/07, Andrew Bartlett wrote: > On Tue, 2007-05-15 at 19:22 -0500, Dennis Gilmore wrote: > > Once upon a time Monday 14 May 2007, Warren Togami wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 > > > We are attempting to get wireless working on x86_64. > > > > > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > > > If you use wireless on ANY arch of rawhide, please test this latest > > > wireless-tools build. We need to be sure that the x86_64 fix doesn't > > > break i386 or ppc*. > > > > > > Please report in the above bug if release -3 is any better or worse than > > > release -1 or -2. > > > > > > We really would like to confirm this before the proposed F7 final freeze > > > on Thursday. > > > > > > Warren Togami > > > wtogami at redhat.com > > > > wireless started working for me with this wireless-tools package. i'm on a > > Dell Latitude D820 x86_64 with iwl3945 driver > > For me, on an Lenovo X60 (x86) with the iwl3945 driver, on the current > rawhide kernel (2.6.21-1.3149.fc7) and 28-3 release of the wireless tool > this works until NetworkManager does a rescan. > > This is pretty much in line with what I've been seeing for quite a while > over various kernels now (I've never had it work any more than this > much, and often worse). > > Andrew Bartlett > Same hardware, same results... I get about 15 seconds worth of traffic through before it 'stops working'. Get lots of these (don't remember getting these before): wlan0: CTS protection disabled (BSSID=00:14:6a:5b:3a:80) printk: 18 messages suppressed. wlan0: CTS protection enabled (BSSID=00:14:6a:5b:3a:80) printk: 17 messages suppressed. wlan0: CTS protection enabled (BSSID=00:14:6a:5b:3a:80) printk: 20 messages suppressed. wlan0: CTS protection disabled (BSSID=00:14:6a:5b:3a:80) tom -- Tom London From notting at redhat.com Wed May 16 01:06:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 May 2007 21:06:36 -0400 Subject: missing i686 debuginfo? In-Reply-To: <20070516000530.2CBBD1F84E6@magilla.localdomain> References: <20070515221239.GA31145@angus.ind.WPI.EDU> <20070516000530.2CBBD1F84E6@magilla.localdomain> Message-ID: <20070516010636.GA29986@nostromo.devel.redhat.com> Roland McGrath (roland at redhat.com) said: > The builds exist (see http://koji.fedoraproject.org/packages/glibc/). > It must be an issue with the distro-making thing, whatever that is this week. Yep, we'll get it fixed. Bill From bpepple at fedoraproject.org Wed May 16 02:13:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 15 May 2007 22:13:32 -0400 Subject: FESCo Meeting Summary for 2007-05-10 Message-ID: <1179281612.5749.0.camel@lincoln> Members Present: * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) Absent: * Christian Iseli (c4chris) * Tom Callaway (spot) * Rex Dieter (rdieter) * Warren Togami (warren) * Jeremy Katz (jeremy) == Summary == * No major decisions made this week, since several of the FESCo members where at the RedHat summit. = EPEL Meeting summaries = * EPEL meeting summaries will be sent to the maintainers and FESCo mailing lists. FESCo members have 72 hours to make any objections known on a public mailing list (in this case the maintainers list). = EPEL Repotag = * Thorsten Leemhuis wanted FESCo members opinion regarding the use of repotags. The general concensus from the members present was that they didn't care for them. = Misc = * Discussed the package review for xu4. The FESCo members present didn't have any issues with the solution used for downloading the game data, since it was basically the same solution used for the codec buddy. * a handfull of stuff needs to get done with bodhi. I'm locking myself in my room this weekend until it gets done :) it will be deployed this weekend. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070510 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wcohen at redhat.com Wed May 16 02:46:24 2007 From: wcohen at redhat.com (William Cohen) Date: Tue, 15 May 2007 22:46:24 -0400 Subject: Looking for GUI application programs for experiments In-Reply-To: <604aa7910705151440n7ffd2feci6d1ac6fb7acd9b61@mail.gmail.com> References: <464A09CF.6030303@redhat.com> <604aa7910705151440n7ffd2feci6d1ac6fb7acd9b61@mail.gmail.com> Message-ID: <464A7080.2020904@redhat.com> Jeff Spaleta wrote: > On 5/15/07, William Cohen wrote: >> The >> characteristics we are looking for in the examples are: >> >> -represent commonly-performed tasks, e.g. edit file and view document >> -depend on a number of dynamically-linked libraries >> -use GUI >> -have built-in accessibility features needed to automate the >> experiment with dogtail >> -run for a couple seconds, so instrumented version doesn't take too long >> -doesn't require network access > > Have you looked at the mugshot compiled stats for most commonly used > applications for registered mugshot users who are running fedora? > http://mugshot.org/applications > I think gedit and evince are obvious candidates, but pretty much all > the gtk based applications that are highly ranked should work for you. > > -jef > Jef, Thanks for the suggestion. We already have an evince example. Have abiword as a word processor example, but the gedit might be good also. -Will From wcohen at redhat.com Wed May 16 02:50:03 2007 From: wcohen at redhat.com (William Cohen) Date: Tue, 15 May 2007 22:50:03 -0400 Subject: Looking for GUI application programs for experiments In-Reply-To: <20070515223623.GA30538@devserv.devel.redhat.com> References: <464A09CF.6030303@redhat.com> <20070515223623.GA30538@devserv.devel.redhat.com> Message-ID: <464A715B.9040806@redhat.com> Alan Cox wrote: > On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote: >> linked programs like SPEC CPU to provide workload for the simulator. This >> is very different than the typical shared-library, GUI application > > You know you can catch TLB misses on some real x86 processors I assume ? > > (You load the page table entry as missing then when you take the trap you > put the entry in, touch the page to load it, and then mark it missing again) > > Alan > Hi Alan, The use of the page table traps might be faster than the valgrind simulator. It also might simplify some of the analysis; valgrind has a lot of additional pages for the binary translation. However, the valgrind simulator does everything in user space and avoid needing root access on the machine. -Will From fedora at leemhuis.info Wed May 16 07:10:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 May 2007 09:10:46 +0200 Subject: FESCo Meeting Summary for 2007-05-10 In-Reply-To: <1179281612.5749.0.camel@lincoln> References: <1179281612.5749.0.camel@lincoln> Message-ID: <464AAE76.1070109@leemhuis.info> Hi All! On 16.05.2007 04:13, Brian Pepple wrote: > = EPEL Repotag = > * Thorsten Leemhuis wanted FESCo members opinion regarding the use > of repotags. The general concensus from the members present was > that they didn't care for them. Sorry, but from looking at the full logs with statements like >[...] * f13 peeks in, -1 on a repotag (again). >[...] * dgilmore -1 >[...] 0. i think it's silly, but that's EPELs choice >[...] -0.5. it's the wrong solution. not sure whether fesco wants to let epel be wrong on their own :) >[...] and some others (see full log) I would make the summary statement more a "FESCO members want to leave the decision to the EPEL Steering Committee, but are not in favour of repotags." CU thl From valent.turkovic at gmail.com Wed May 16 09:05:40 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 May 2007 11:05:40 +0200 Subject: Making beagle optional In-Reply-To: <1179240586.3755.27.camel@localhost.localdomain> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> <1179240586.3755.27.camel@localhost.localdomain> Message-ID: <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> On 5/15/07, Alexander Larsson wrote: > On Tue, 2007-05-15 at 12:28 +0200, Valent Turkovic wrote: > > Is there maybe an option to whip beagle into shape and not to use 100% of cpu? > > > > Is there no other way? Is disabling it really the only option? > > The decision has been made for Fedora 7. > > But you can help out for Fedora 8 by fixing bugs like: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 I subscribet to that bug, but for me on my 2 Fedora Core 6 systems beagle works flawlessly! And I use it all the time... not 100% cpu usage, no slowdowns... it "just works"tm :) If this aproach would be the same with all components of Fedora I personaly have trouble with then there would be an empty application menue if you would remove all apps that have some little bugs. For me this is an ovekill - there are much worst apps in Fedora 7 and aren't being removed from Fedora 7. From valent.turkovic at gmail.com Wed May 16 09:07:46 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 May 2007 11:07:46 +0200 Subject: Making beagle optional In-Reply-To: <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> <1179240586.3755.27.camel@localhost.localdomain> <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> Message-ID: <64b14b300705160207r1a189743q46dacbe5777c6f6c@mail.gmail.com> On 5/16/07, Valent Turkovic wrote: > On 5/15/07, Alexander Larsson wrote: > > On Tue, 2007-05-15 at 12:28 +0200, Valent Turkovic wrote: > > > Is there maybe an option to whip beagle into shape and not to use 100% of cpu? > > > > > > Is there no other way? Is disabling it really the only option? > > > > The decision has been made for Fedora 7. > > > > But you can help out for Fedora 8 by fixing bugs like: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 > > I subscribet to that bug, but for me on my 2 Fedora Core 6 systems > beagle works flawlessly! And I use it all the time... not 100% cpu > usage, no slowdowns... it "just works"tm :) > > If this aproach would be the same with all components of Fedora I > personaly have trouble with then there would be an empty application > menue if you would remove all apps that have some little bugs. > > For me this is an ovekill - there are much worst apps in Fedora 7 and > aren't being removed from Fedora 7. > ps. I also use beagle+deskbar+beagle firefox plugin in Fedora 7 test 4 and I'm really pleased - they work FAST and without bugs. I feel that beagle has really matured since my testing it on Fedora Core 5 - and other parts of Fedora have degraded and aren't removed. It is a shame. From jspaleta at gmail.com Wed May 16 10:36:32 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 02:36:32 -0800 Subject: Making beagle optional In-Reply-To: <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> <1179240586.3755.27.camel@localhost.localdomain> <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> Message-ID: <604aa7910705160336r31d5918aq82112829f91294bb@mail.gmail.com> On 5/16/07, Valent Turkovic wrote: > I subscribet to that bug, but for me on my 2 Fedora Core 6 systems > beagle works flawlessly! And I use it all the time... not 100% cpu > usage, no slowdowns... it "just works"tm :) I'm glad it works for you, I mean.. it has to work for someone. I've uninstall beagle on my 4 personal machines running fc6 or fedora development because it repeatedly decided to start thrashing disk and cpu while i was trying to do "important" things. If beagle was smart enough to do whatever necessary system thrashing late at night or when things were really idle, it would have escaped my scrutiny entirely. > > If this aproach would be the same with all components of Fedora I > personaly have trouble with then there would be an empty application > menue if you would remove all apps that have some little bugs. 100% cpu utilization of a background process isn't a little bug. Beagle is acting essentially a daemon process, initiated as part of desktop session startup. The indexer which is the underlying problem is not even really a desktop application in the traditional sense. You don't manually start it, you don't interact with it while its doing its job. We don't even get a little cute tray icon that pops up when the indexer is active for us to monitor or interact with. It runs on its own and as such its a pain in the ass to keep an eye on if its going wonky. if you aren't running a system monitor like application constantly you aren't necessarily going to notice when it decides to flip out and burn your cpu for 10 minutes while the other running processess suffer. I however do run a system monitor like application constantly, and pay close attention to when the cpu spikes. > For me this is an ovekill - there are much worst apps in Fedora 7 and > aren't being removed from Fedora 7. Yes, we all have our pet applications and applications with love to hate. Shall I wax eloquent about how desperately vital I find inkscape or revelation as applications that I simply can not live without on a day-to-day basis? Or how much I absolutely loath gaim/pidgon? Just because I find certain applications supremely useful (or dishearteningly unusable), does not mean I'm going to stand up on a soapbox, shake my fist in the air, and demand those applications to be in or out of a default install target simply on the strength of my personal preferences. Beagle is still available in the repository. Is it really that burdensome for you to install beagle from the repository instead of having in the default media spin? And the answer is, its no less burdensome for you to install it as it is for me to uninstall it after the fact...which I have gladly done up till this point without complaint. But I think you need to appreciate the bigger picture that release-eng and QA have to take in...there are competing demands on default install targets..they need to be featureful as well as having robust system performance. There is a need to make sure general perception concerning Fedora's performance is not unduly impacted by misbehaving background processes. There is most definitely a elevated risk to overall system performance in the Fedora desktop if beagle is enabled. Whether or not your personal data doesn't cause beagle to misfire is immaterial to the larger issue. Beagle is not just one buggy application that crashes unexpectedly while its being used resulting sharp bursts of user frustration. When beagle running as a background process craps out, its causing a noticeable degradation on the whole system (especially low-end to middle of the road systems), with absolutely no user-visible feedback at all to indicate to an unsuspecting user that beagle is causing the system slowdown. That's a userbase wide issue, which deserves release-eng and QA consideration. -jef"so which indexer should i write a netcdf indexer for first... i'm thinking medusa"spaleta From dakingun at gmail.com Wed May 16 10:40:53 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 16 May 2007 06:40:53 -0400 Subject: Making beagle optional In-Reply-To: <64b14b300705160207r1a189743q46dacbe5777c6f6c@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> <1179240586.3755.27.camel@localhost.localdomain> <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> <64b14b300705160207r1a189743q46dacbe5777c6f6c@mail.gmail.com> Message-ID: On 5/16/07, Valent Turkovic wrote: > On 5/16/07, Valent Turkovic wrote: > > ps. I also use beagle+deskbar+beagle firefox plugin in Fedora 7 test 4 > and I'm really pleased - they work FAST and without bugs. > > I feel that beagle has really matured since my testing it on Fedora > Core 5 - and other parts of Fedora have degraded and aren't removed. > It (beagle) IS NOT being removed, just not installed by default. You can easily select it at installation if you want/like it. Deji > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at fedoraproject.org Wed May 16 11:36:41 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 16 May 2007 07:36:41 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-05-16 Message-ID: <20070516113641.08A2B152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 22 ack-1.60-2.fc6 aircrack-ng-0.9-1.fc6 blender-2.42a-24.fc6 catfish-0.3-0.1.b.fc6 NEW clutter-gst-0.1.1-2.fc6 : ClutterMedia interface to GStreamer gallery2-2.2-0.5.svn20070506.fc6 libiptcdata-1.0.2-1.fc6 linphone-1.7.1-2.fc6 monotone-0.35-2.fc6 moodle-1.6.5-5.fc6 ntfs-3g-1.516-1.fc6 NEW perl-Catalyst-Runtime-5.7007-4.fc6 : Catalyst core modules NEW perl-JSON-XS-1.21-3.fc6 : JSON serialising/deserialising, done correctly and fast perl-Params-Util-0.24-1.fc6 NEW php-pear-File-Passwd-1.1.6-2.fc6 : Manipulate many kinds of password files NEW php-pear-File-SMBPasswd-1.0.2-1.fc6 : Class for managing SAMBA style password files python-krbV-1.0.13-5.fc6 NEW python-tag-0.91-3.fc6 : Python bindings for TagLib to read and write music files tags TeXmacs-1.0.6.10-2.fc6 viewvc-1.0.4-1.fc6 NEW xfce4-places-plugin-0.2.0-1.fc6 : Places menu for the Xfce panel NEW xfce4-verve-plugin-0.3.5-2.fc6 : A comfortable command line plugin for the Xfce panel Packages built and released for Fedora Extras 5: 14 ack-1.60-2.fc5 blender-2.42a-24.fc5 catfish-0.3-0.1.b.fc5 gallery2-2.2-0.5.svn20070506.fc5 libiptcdata-1.0.2-1.fc5 moodle-1.6.5-5.fc5 ntfs-3g-1.516-1.fc5 NEW perl-Catalyst-Runtime-5.7007-4.fc5 : Catalyst core modules NEW perl-JSON-XS-1.21-3.fc5 : JSON serialising/deserialising, done correctly and fast perl-Params-Util-0.24-1.fc5 NEW php-pear-File-Passwd-1.1.6-2.fc5 : Manipulate many kinds of password files NEW php-pear-File-SMBPasswd-1.0.2-1.fc5 : Class for managing SAMBA style password files NEW python-krbV-1.0.13-5.fc5 : Python extension module for Kerberos 5 NEW python-tag-0.91-3.fc5 : Python bindings for TagLib to read and write music files tags Changes in Fedora Extras 6: ack-1.60-2.fc6 -------------- * Tue May 15 2007 Ian M. Burrell - 1.60-1 - add BuildRequires perl(ExtUtils::MakeMaker) * Sat May 05 2007 - 1.60-4 - Update to 1.60; requires File::Next 0.40 aircrack-ng-0.9-1.fc6 --------------------- * Mon May 14 2007 Till Maas - 0.9-1 - update to latest version * Sun May 06 2007 Till Maas - 0.8-2 - fix disttag * Sun May 06 2007 Till Maas - 0.8-1 - update to latest version * Thu Apr 12 2007 Till Maas - 0.8-0.2.20070417svn - some more bugfixes * Thu Apr 12 2007 Till Maas - 0.8-0.1.20070413svn - update to 0.8 - fixes http://archives.neohapsis.com/archives/fulldisclosure/2007-04/0408.html (remote code execution) - fix race condition in %install blender-2.42a-24.fc6 -------------------- * Wed May 09 2007 Jochen Schmitt 2.42a-24 - Remove ffmpeg lib during a legal issue (#239476) catfish-0.3-0.1.b.fc6 --------------------- * Tue May 15 2007 Mamoru Tasaka 0.3-0.1.b - 0.3b clutter-gst-0.1.1-2.fc6 ----------------------- * Sun May 13 2007 Allisson Azevedo 0.1.1-2 - INSTALL removed from docs - fix make install for keeping timestamps - changed license for LGPL - Fix requires/buildrequires gallery2-2.2-0.5.svn20070506.fc6 -------------------------------- * Sun May 13 2007 John Benringer - 2.2-0.4.svn20070506 - Correct shell syntax in post scriptlet libiptcdata-1.0.2-1.fc6 ----------------------- * Tue May 15 2007 David Moore 1.0.2-1 - New upstream version linphone-1.7.1-2.fc6 -------------------- * Mon May 14 2007 Jeffrey C. Ollie - 1.7.1-2 - Add patch for compiling against external GSM library. monotone-0.35-2.fc6 ------------------- * Wed May 09 2007 Roland McGrath - 0.35-2 - Updated for 0.35 release. - Avoid unnecessary "db migrate" in monotone-server init script. (#213893) * Wed Apr 04 2007 Roland McGrath - 0.34-1 - Updated for 0.34 release. moodle-1.6.5-5.fc6 ------------------ * Tue May 15 2007 Jerry James - 1.8-5 - Fix language packs to not obsolete themselves. - Update language packs to the 15 May 2007 versions. ntfs-3g-1.516-1.fc6 ------------------- * Tue May 15 2007 Tom "spot" Callaway 2:1.516-1 - bump to 1.516 - fix bugzilla 232031 perl-Catalyst-Runtime-5.7007-4.fc6 ---------------------------------- * Mon May 14 2007 Chris Weyl 5.7007-4 - bump * Mon May 14 2007 Chris Weyl 5.7007-3 - additional br's * Fri Apr 27 2007 Chris Weyl 5.7007-2 - exclude catalyst.pl from this package -- it depends on perl(Catalyst::Helper), which is provided by perl-Catalyst-Devel (but which has a buildreq on this package). We will provide catalyst.pl in perl-Catalyst-Devel instead. perl-JSON-XS-1.21-3.fc6 ----------------------- * Mon May 14 2007 Chris Weyl 1.21-3 - bump * Mon May 14 2007 Chris Weyl 1.21-2 - add eg/ to doc * Sun May 13 2007 Chris Weyl 1.21-1 - Specfile autogenerated by cpanspec 1.71. perl-Params-Util-0.24-1.fc6 --------------------------- * Mon May 14 2007 Ralf Cors?pius - 0.24-1 - Upstream update. * Mon Mar 12 2007 Ralf Cors?pius - 0.23-2 - BR: perl(ExtUtils::MakeMaker). php-pear-File-Passwd-1.1.6-2.fc6 -------------------------------- * Sun May 13 2007 Christopher Stone 1.1.6-2 - Include samba extension as default for Fedora - Exclude samba extension from Enterprise Linux php-pear-File-SMBPasswd-1.0.2-1.fc6 ----------------------------------- * Tue Mar 13 2007 Christopher Stone 1.0.2-1 - Initial Fedora release python-krbV-1.0.13-5.fc6 ------------------------ * Mon Dec 11 2006 Mike Bonnet - 1.0.13-5 - remove obsolete python-abi Requires: python-tag-0.91-3.fc6 --------------------- * Fri May 11 2007 Matthias Saou 0.91-3 - Actually include LICENSE file. * Thu May 10 2007 Matthias Saou 0.91-2 - Include BSD license text, copied from the debian package (Debian #417372). - Include minor patch for upstream 0.92 backports. TeXmacs-1.0.6.10-2.fc6 ---------------------- * Mon May 14 2007 Gerard Milmeister - 1.0.6.10-1 - new version 1.0.6.10 viewvc-1.0.4-1.fc6 ------------------ * Tue May 15 2007 Bojan Smojver - 1.0.4-1 - Bump up to 1.0.4 xfce4-places-plugin-0.2.0-1.fc6 ------------------------------- * Sun Apr 29 2007 Christoph Wickert - 0.2.0-1 - Update to 0.2.0 xfce4-verve-plugin-0.3.5-2.fc6 ------------------------------ * Sun Apr 29 2007 Christoph Wickert - 0.3.5-2 - Rebuild for Xfce 4.4.1 Changes in Fedora Extras 5: ack-1.60-2.fc5 -------------- * Tue May 15 2007 Ian M. Burrell - 1.60-1 - add BuildRequires perl(ExtUtils::MakeMaker) * Sat May 05 2007 - 1.60-4 - Update to 1.60; requires File::Next 0.40 blender-2.42a-24.fc5 -------------------- * Wed May 09 2007 Jochen Schmitt 2.42a-24 - Remove ffmpeg lib during a legal issue (#239476) catfish-0.3-0.1.b.fc5 --------------------- * Tue May 15 2007 Mamoru Tasaka 0.3-0.1.b - 0.3b gallery2-2.2-0.5.svn20070506.fc5 -------------------------------- * Tue May 15 2007 John Berninger - 2.2-0.5.svn20070506 - README file update and new build libiptcdata-1.0.2-1.fc5 ----------------------- * Tue May 15 2007 David Moore 1.0.2-1 - New upstream version moodle-1.6.5-5.fc5 ------------------ * Tue May 15 2007 Jerry James - 1.8-5 - Fix language packs to not obsolete themselves. - Update language packs to the 15 May 2007 versions. ntfs-3g-1.516-1.fc5 ------------------- * Tue May 15 2007 Tom "spot" Callaway 2:1.516-1 - bump to 1.516 - fix bugzilla 232031 perl-Catalyst-Runtime-5.7007-4.fc5 ---------------------------------- * Mon May 14 2007 Chris Weyl 5.7007-4 - bump * Mon May 14 2007 Chris Weyl 5.7007-3 - additional br's * Fri Apr 27 2007 Chris Weyl 5.7007-2 - exclude catalyst.pl from this package -- it depends on perl(Catalyst::Helper), which is provided by perl-Catalyst-Devel (but which has a buildreq on this package). We will provide catalyst.pl in perl-Catalyst-Devel instead. perl-JSON-XS-1.21-3.fc5 ----------------------- * Mon May 14 2007 Chris Weyl 1.21-3 - bump * Mon May 14 2007 Chris Weyl 1.21-2 - add eg/ to doc * Sun May 13 2007 Chris Weyl 1.21-1 - Specfile autogenerated by cpanspec 1.71. perl-Params-Util-0.24-1.fc5 --------------------------- * Mon May 14 2007 Ralf Cors?pius - 0.24-1 - Upstream update. * Mon Mar 12 2007 Ralf Cors?pius - 0.23-2 - BR: perl(ExtUtils::MakeMaker). php-pear-File-Passwd-1.1.6-2.fc5 -------------------------------- * Sun May 13 2007 Christopher Stone 1.1.6-2 - Include samba extension as default for Fedora - Exclude samba extension from Enterprise Linux php-pear-File-SMBPasswd-1.0.2-1.fc5 ----------------------------------- * Tue Mar 13 2007 Christopher Stone 1.0.2-1 - Initial Fedora release python-krbV-1.0.13-5.fc5 ------------------------ * Mon Dec 11 2006 Mike Bonnet - 1.0.13-5 - remove obsolete python-abi Requires: python-tag-0.91-3.fc5 --------------------- * Fri May 11 2007 Matthias Saou 0.91-3 - Actually include LICENSE file. * Thu May 10 2007 Matthias Saou 0.91-2 - Include BSD license text, copied from the debian package (Debian #417372). - Include minor patch for upstream 0.92 backports. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From alan at redhat.com Wed May 16 12:08:25 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 16 May 2007 08:08:25 -0400 Subject: Looking for GUI application programs for experiments In-Reply-To: <464A715B.9040806@redhat.com> References: <464A09CF.6030303@redhat.com> <20070515223623.GA30538@devserv.devel.redhat.com> <464A715B.9040806@redhat.com> Message-ID: <20070516120825.GC28020@devserv.devel.redhat.com> On Tue, May 15, 2007 at 10:50:03PM -0400, William Cohen wrote: > The use of the page table traps might be faster than the valgrind > simulator. It also might simplify some of the analysis; valgrind has a lot Its a lot faster and if you keep the trap handler in a 4MB page its fairly close to accurate in its results as the 4MB and standard TLB isn't generally shared > of additional pages for the binary translation. However, the valgrind > simulator does everything in user space and avoid needing root access on > the machine. And finding a PC for the experiment that you can wipe and use is hard ? Oh wait this is a university perhaps thats true From nicolas.mailhot at laposte.net Wed May 16 12:23:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 14:23:32 +0200 Subject: [RFC] Make koji a complete rpmfind replacement Message-ID: <1179318212.6394.8.camel@rousalka.dyndns.org> Hi, With the rawhide sync down and packages stuck on various non-mirrored state I couldn't help noticing the retro rpmfind-ish experience of koji (go to the web site, select the right package letter, open the package info page, click on the download link, repeat for deps?) While I'm sure the yum repo situation will correct itself soon I couldn't help wondering if koji could not serve the same purpose as rpmfind for fly-by users (typically users of another distro/release version that just want to look at how something was done in Fedora X to provide feedback or adapt) Right now it only needs: 1. a search field 2. resolving dependency links 3. displaying of rpm metadata to provide a full modern rpmfind replacement (internal files are already resolvable) Do other people feel that would be a useful thing to add? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dev at nigelj.com Wed May 16 12:30:18 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 00:30:18 +1200 Subject: [RFC] Make koji a complete rpmfind replacement In-Reply-To: <1179318212.6394.8.camel@rousalka.dyndns.org> References: <1179318212.6394.8.camel@rousalka.dyndns.org> Message-ID: <464AF95A.1080807@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: > Hi, > > With the rawhide sync down and packages stuck on various non-mirrored > state I couldn't help noticing the retro rpmfind-ish experience of koji > (go to the web site, select the right package letter, open the package > info page, click on the download link, repeat for deps?) > > While I'm sure the yum repo situation will correct itself soon I > couldn't help wondering if koji could not serve the same purpose as > rpmfind for fly-by users (typically users of another distro/release > version that just want to look at how something was done in Fedora X to > provide feedback or adapt) > > Right now it only needs: > 1. a search field Well there is the search section (top menu bar) > 2. resolving dependency links > 3. displaying of rpm metadata Yes I agree on the 2nd two points, it'd be quite handy. I also think having koji to show BR trees would be useful people can then look at it and say "right if I rebuild libxyz now, rpmx rpmy and rpmz need to be rebuilt, maybe I should contact those maintainers". I have yet to really find a decent way for handling those sorts of issues. N.J. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSvlapldg9bRmG6kRAoI8AJ9SHHlIktqA5ugRiKJOV9ov745m7gCfeR5d 44uHlSsmQKOdXjWJii6U3EI= =iehS -----END PGP SIGNATURE----- From oliver at linux-kernel.at Wed May 16 12:31:50 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 16 May 2007 14:31:50 +0200 Subject: [RFC] Make koji a complete rpmfind replacement In-Reply-To: <1179318212.6394.8.camel@rousalka.dyndns.org> References: <1179318212.6394.8.camel@rousalka.dyndns.org> Message-ID: <464AF9B6.2020907@linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/16/2007 02:23 PM, Nicolas Mailhot wrote: > Hi, > > With the rawhide sync down and packages stuck on various non-mirrored > state I couldn't help noticing the retro rpmfind-ish experience of koji > (go to the web site, select the right package letter, open the package > info page, click on the download link, repeat for deps?) > > While I'm sure the yum repo situation will correct itself soon I > couldn't help wondering if koji could not serve the same purpose as > rpmfind for fly-by users (typically users of another distro/release > version that just want to look at how something was done in Fedora X to > provide feedback or adapt) > > Right now it only needs: > 1. a search field > 2. resolving dependency links > 3. displaying of rpm metadata > > to provide a full modern rpmfind replacement (internal files are already > resolvable) > > Do other people feel that would be a useful thing to add? Sure. I had the idea also quite some while ago: http://sapporo.linux-kernel.at/rpmsearch/index.pl It's not regular updated or so and it's running on a slow machine. Also the links are currently dead links. It was just a quick hack of an idea - - but then busy... :-) If I can help with my source/experience (backend is python, frontend is perl), I will... Best, Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFGSvm2xWN5Ge8lKUMRApSVAKCNGdpyu2VbvgzNY45i/6sYLp4pXACYuohe Lg58jAqpkr9TaowrOASyTQ== =MPvE -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Wed May 16 12:41:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 07:41:43 -0500 Subject: [RFC] Make koji a complete rpmfind replacement In-Reply-To: <1179318212.6394.8.camel@rousalka.dyndns.org> References: <1179318212.6394.8.camel@rousalka.dyndns.org> Message-ID: <1179319303.13214.17.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 14:23 +0200, Nicolas Mailhot wrote: > Hi, > > With the rawhide sync down and packages stuck on various non-mirrored > state I couldn't help noticing the retro rpmfind-ish experience of koji > (go to the web site, select the right package letter, open the package > info page, click on the download link, repeat for deps?) > > While I'm sure the yum repo situation will correct itself soon I > couldn't help wondering if koji could not serve the same purpose as > rpmfind for fly-by users (typically users of another distro/release > version that just want to look at how something was done in Fedora X to > provide feedback or adapt) > > Right now it only needs: > 1. a search field > 2. resolving dependency links > 3. displaying of rpm metadata > > to provide a full modern rpmfind replacement (internal files are already > resolvable) > > Do other people feel that would be a useful thing to add? https://hosted.fedoraproject.org/projects/koji Patches welcome. josh From ndbecker2 at gmail.com Wed May 16 13:22:43 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 16 May 2007 09:22:43 -0400 Subject: plans for gcc-4.2? Message-ID: Since gcc-4.2 is now released, what are plans to incorporate into Fedora? From jwboyer at jdub.homelinux.org Wed May 16 13:27:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 08:27:36 -0500 Subject: plans for gcc-4.2? In-Reply-To: References: Message-ID: <1179322056.13214.51.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 09:22 -0400, Neal Becker wrote: > Since gcc-4.2 is now released, what are plans to incorporate into Fedora? As I understand it, the GCC in F7 contains several backports from what was GCC 4.2 CVS. Exactly how large the differences between F7 gcc and gcc 4.2 are, I'm not sure. But it's a bit late to get it into F7 I think. Jakub (the gcc maintainer) is out this week I think so you might have to wait a bit for more info. josh From fedora at camperquake.de Wed May 16 14:08:54 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 16 May 2007 16:08:54 +0200 Subject: rawhide report: 20070515 changes In-Reply-To: <20070515214334.GA29257@nostromo.devel.redhat.com> References: <20070515214334.GA29257@nostromo.devel.redhat.com> Message-ID: <20070516160854.073bc553@banea.int.addix.net> Hi. On Tue, 15 May 2007 17:43:34 -0400, Bill Nottingham wrote: > xorg-x11-drv-i810-2.0.0-3.fc7 > ----------------------------- > * Mon May 14 2007 Adam Jackson 2.0.0-3 > - intel-2.0-vblank-power-savings.patch: Disable vblank interrupts > when no DRI clients are active, for better battery life. Hm. Maybe this does not do what I think it does, or I am doing something wrong. Scenario: Log into gnome with compiz disabled, observe interrupts with powertop. Interrupts for the GPU are pretty low. Enable compiz, see interupts soar. Disable compiz again, but the interrupt number decreases just a little. Is there some "residue" left after disabling compiz? From mikeb at redhat.com Wed May 16 14:35:38 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 16 May 2007 10:35:38 -0400 Subject: [RFC] Make koji a complete rpmfind replacement In-Reply-To: <464AF95A.1080807@nigelj.com> References: <1179318212.6394.8.camel@rousalka.dyndns.org> <464AF95A.1080807@nigelj.com> Message-ID: <1179326138.15942.7.camel@burren.boston.redhat.com> On Thu, 2007-05-17 at 00:30 +1200, Nigel Jones wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicolas Mailhot wrote: > > Hi, > > > > With the rawhide sync down and packages stuck on various non-mirrored > > state I couldn't help noticing the retro rpmfind-ish experience of koji > > (go to the web site, select the right package letter, open the package > > info page, click on the download link, repeat for deps?) > > > > While I'm sure the yum repo situation will correct itself soon I > > couldn't help wondering if koji could not serve the same purpose as > > rpmfind for fly-by users (typically users of another distro/release > > version that just want to look at how something was done in Fedora X to > > provide feedback or adapt) > > > > Right now it only needs: > > 1. a search field > Well there is the search section (top menu bar) > > 2. resolving dependency links Not sure what you mean by this. You want the web interface to perform the same functions as yum? > > 3. displaying of rpm metadata Like http://koji.fedoraproject.org/koji/rpminfo?rpmID=69779 for example? (follow the (info) link next to the RPM list on the buildinfo page) What other metadata would you like displayed here? > Yes I agree on the 2nd two points, it'd be quite handy. > > I also think having koji to show BR trees would be useful people can > then look at it and say "right if I rebuild libxyz now, rpmx rpmy and > rpmz need to be rebuilt, maybe I should contact those maintainers". http://koji.fedoraproject.org/koji/rpmlist?buildrootID=2540&type=component (from the taskinfo page click Buildroot -> Component RPMs) Every RPM with a check mark in the "Update" column was pulled in as a BuildRequires or a dependency of a BuildRequires. RPMs without a check mark in the "Update" column were pulled in as part of the minimal buildroot. Note that there is usually overlap in these sets. > I have yet to really find a decent way for handling those sorts of issues. > > N.J. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFGSvlapldg9bRmG6kRAoI8AJ9SHHlIktqA5ugRiKJOV9ov745m7gCfeR5d > 44uHlSsmQKOdXjWJii6U3EI= > =iehS > -----END PGP SIGNATURE----- > From hughsient at gmail.com Wed May 16 14:33:26 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 May 2007 15:33:26 +0100 Subject: Explaining the new suspend quirks functionality in F7 Message-ID: <1179326006.14246.44.camel@localhost.localdomain> New in Fedora 7 we have the new pm-utils and hal-info dmi based matching of suspend quirks. We are doing finer matching to the laptop make and model, to make suspend (and more importantly resume) work for more people. What this means: * Some machines that suspended in FC6 might not work in F7 * Lots of machines that did not suspend in FC6 might work in F7 So, if you have to edit a file or add stuff to grub to get suspend working in F7, that's a bug. This stuff should just work on the majority or laptops. To help, and to try and make clearer all this new stuff, I've written a few pages here: http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html This is not the permanent location, nor are these documents finished - I'm hoping to add more and more content to them over the next few days. So please point out new ideas, typos or maybe just general questions, and I'll try to answer then on these pages as best I can. Feedback welcome, Richard Hughes From skvidal at linux.duke.edu Wed May 16 14:47:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 16 May 2007 10:47:07 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179326006.14246.44.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> Message-ID: <1179326827.10457.9.camel@rivendell> On Wed, 2007-05-16 at 15:33 +0100, Richard Hughes wrote: > New in Fedora 7 we have the new pm-utils and hal-info dmi based matching > of suspend quirks. We are doing finer matching to the laptop make and > model, to make suspend (and more importantly resume) work for more > people. > > What this means: > > * Some machines that suspended in FC6 might not work in F7 > * Lots of machines that did not suspend in FC6 might work in F7 > > So, if you have to edit a file or add stuff to grub to get suspend > working in F7, that's a bug. This stuff should just work on the majority > or laptops. > > To help, and to try and make clearer all this new stuff, I've written a > few pages here: > http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html > > This is not the permanent location, nor are these documents finished - > I'm hoping to add more and more content to them over the next few days. > > So please point out new ideas, typos or maybe just general questions, > and I'll try to answer then on these pages as best I can. Is it possible to put together a style sheet for the fdi files to make them easier to read as a web page? I'm really happy about the content you have there to figure out how to fix laptop suspends - but it'd be nice if it was a little easier to read. thanks, -sv From nicolas.mailhot at laposte.net Wed May 16 15:11:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 17:11:35 +0200 Subject: [RFC] Make koji a complete rpmfind replacement In-Reply-To: <1179326138.15942.7.camel@burren.boston.redhat.com> References: <1179318212.6394.8.camel@rousalka.dyndns.org> <464AF95A.1080807@nigelj.com> <1179326138.15942.7.camel@burren.boston.redhat.com> Message-ID: <1179328295.23605.5.camel@rousalka.dyndns.org> Le mercredi 16 mai 2007 ? 10:35 -0400, Mike Bonnet a ?crit : > Not sure what you mean by this. [...] > What other metadata would you like displayed here? [...] Just go to rpmfind.net and select a random package, that'll answer both questions I may add rpmfind.net has a nifty colour-coding to distinguish various repos in the UI. -- 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 hughsient at gmail.com Wed May 16 15:00:02 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 May 2007 16:00:02 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179326827.10457.9.camel@rivendell> References: <1179326006.14246.44.camel@localhost.localdomain> <1179326827.10457.9.camel@rivendell> Message-ID: <1179327602.14246.50.camel@localhost.localdomain> On Wed, 2007-05-16 at 10:47 -0400, seth vidal wrote: > > > So please point out new ideas, typos or maybe just general > questions, > > and I'll try to answer then on these pages as best I can. > > Is it possible to put together a style sheet for the fdi files to make > them easier to read as a web page? I'm really happy about the content > you have there to figure out how to fix laptop suspends - but it'd be > nice if it was a little easier to read. I'll see what my xslt-foo can manage. Cheers for the feedback. Richard. From jkeating at redhat.com Wed May 16 15:21:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 11:21:10 -0400 Subject: rawhide report: 20070515 changes In-Reply-To: <20070515214334.GA29257@nostromo.devel.redhat.com> References: <20070515214334.GA29257@nostromo.devel.redhat.com> Message-ID: <200705161121.11138.jkeating@redhat.com> On Tuesday 15 May 2007 17:43:34 Bill Nottingham wrote: > rawhide report: 20070515 changes FYI this is just a repo of packages, not installable. We're getting the repo of packages automated which is the easy task. At the same time we're working on making it installable in an automated fashion which is the harder case. Instead of waiting for both to be done before releasing everything, we're releasing the repo of packages now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lsof at nodata.co.uk Wed May 16 16:39:07 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 May 2007 18:39:07 +0200 Subject: PowerTOP tool released; time to fix the wasted laptop power on fedora? In-Reply-To: <1179007939.7061.6.camel@laptopd505.fenrus.org> References: <1179007939.7061.6.camel@laptopd505.fenrus.org> Message-ID: <1179333547.3513.5.camel@sb-home> Am Samstag, den 12.05.2007, 15:12 -0700 schrieb Arjan van de Ven: > Hi, > > some of you already know that I've been working on getting Linux (and > Fedora) to be a lot better about power usage on laptops by avoiding > spurious wakeups and context switches and such (look at the "wakeup" bug > in fedora bugzilla ;). Nice tool, I get: 47.4% (75.0) : yenta, radeon at pci:0000:01:05.0 right at the top. From jspaleta at gmail.com Wed May 16 16:42:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 08:42:48 -0800 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179326006.14246.44.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> Message-ID: <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> On 5/16/07, Richard Hughes wrote: > So please point out new ideas, typos or maybe just general questions, > and I'll try to answer then on these pages as best I can. When did the new quirkiness control go live in Fedora development? I'm assuming its in use as of today in the development tree, but I'd like to know at what point it was added so I can do a pre/post test of this feature for my own enjoyment :-> (like for example... did test2 have it?) -jef From rdieter at math.unl.edu Wed May 16 16:49:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 16 May 2007 11:49:11 -0500 Subject: rpms/kdelibs/devel kdelibs.spec Message-ID: <464B3607.2070602@math.unl.edu> Than Ngo (than) wrote: > Author: than > Update of /cvs/extras/rpms/kdelibs/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29578 > Modified Files: > kdelibs.spec > Log Message: ... > - disable kde_settings wtf? I just went through the work enabling kde-settings, why are you disabling it? -- Rex From lsof at nodata.co.uk Wed May 16 17:04:33 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 May 2007 19:04:33 +0200 Subject: kernel debuginfo packages for rawhide Message-ID: <1179335073.3513.10.camel@sb-home> Hi. Are kernel-debuginfo packages available for rawhide? I can't find them with yum, or on the ftp server. Thanks a lot. From Lam at Lam.pl Wed May 16 17:22:21 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 16 May 2007 19:22:21 +0200 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179335073.3513.10.camel@sb-home> References: <1179335073.3513.10.camel@sb-home> Message-ID: <1179336141.3921.1.camel@pensja.lam.pl> Dnia 16-05-2007, ?ro o godzinie 19:04 +0200, nodata napisa?(a): > Hi. > Are kernel-debuginfo packages available for rawhide? As you're not using kernel.i386 for sure, check https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01036.html Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mmcgrath at redhat.com Wed May 16 17:26:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 May 2007 12:26:51 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] Message-ID: <464B3EDB.2070709@redhat.com> There will be an outage starting at 2007-05-17 04:00 [UTC], which will last approximately 1 hour. To convert UTC to your local time, use: http://www.timeanddate.com/worldclock/converter.html Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Reason for Outage: Upgrading Koji to a new version and moving koji store to new hardware. This outage should be approximately 1 hour, maybe longer if the sync is running slower then expected. Will be coordinating in #fedora-admin The build system should either reject connections or queue connections during this time. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From ddmbox2 at yahoo.co.uk Wed May 16 17:26:32 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 16 May 2007 18:26:32 +0100 Subject: what happened to kcalc & ksim ? Message-ID: <200705161826.35366.ddmbox2@yahoo.co.uk> howdy doody, rpm -ql kdeutils|grep kcalc /usr/share/apps/kconf_update/kcalcrc.upd /usr/share/doc/HTML/en/kdeutils-apidocs/kcalc /usr/share/doc/HTML/en/kdeutils-apidocs/kcalc/html /usr/share/doc/HTML/en/kdeutils-apidocs/kcalc/knumber /usr/share/doc/HTML/en/kdeutils-apidocs/kcalc/knumber/html rpm -ql kdeutils|grep ksim rpm -qi kdeutils Name : kdeutils Relocations: (not relocatable) Version : 3.5.6 Vendor: Koji Release : 3.fc7 Build Date: Thu 10 May 2007 01:55:09 BST Install Date: Sat 12 May 2007 17:05:37 BST Build Host: xenbuilder1.fedora.redhat.com Group : Applications/System Source RPM: kdeutils-3.5.6-3.fc7.src.rpm Size : 10437522 License: GPL Signature : (none) Packager : Koji URL : http://www.kde.org Summary : K Desktop Environment - Utilities Description : Utilities for the K Desktop Environment. Includes: ark (tar/gzip archive manager); kcalc (scientific calculator); kcharselect (character selector); kdepasswd (change password); kdessh (ssh front end); kdf (view disk usage); kedit (simple text editor); kfloppy (floppy formatting tool); khexedit (hex editor); kjots (note taker); klaptopdaemon (battery monitoring and management for laptops); ksim (system information monitor); ktimer (task scheduler); kwikdisk (removable media utility) Did I miss a repack or is it a miss pack? ...dex ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From jamatos at fc.up.pt Wed May 16 17:29:07 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 16 May 2007 18:29:07 +0100 Subject: what happened to kcalc & ksim ? In-Reply-To: <200705161826.35366.ddmbox2@yahoo.co.uk> References: <200705161826.35366.ddmbox2@yahoo.co.uk> Message-ID: <200705161829.07266.jamatos@fc.up.pt> On Wednesday 16 May 2007 18:26:32 dexter wrote: > howdy doody, $ yum search kcalc kdeutils-extras.i386 6:3.5.6-3.fc7 development Matched from: More Utilities for the K Desktop Environment: * kcalc (scientific calculator); * kmilo * ksim (system information monitor); * klaptopdaemon (battery monitoring and management for laptops); -- Jos? Ab?lio From hughsient at gmail.com Wed May 16 17:34:57 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 May 2007 18:34:57 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> Message-ID: <1179336897.14246.66.camel@localhost.localdomain> On Wed, 2007-05-16 at 08:42 -0800, Jeff Spaleta wrote: > On 5/16/07, Richard Hughes wrote: > > So please point out new ideas, typos or maybe just general > questions, > > and I'll try to answer then on these pages as best I can. > > When did the new quirkiness control go live in Fedora development? About 6 months ago if my memory serves me correctly. It's been evolving as upstream has evolved since FC6 was split. > I'm assuming its in use as of today in the development tree, but I'd > like to know at what point it was added so I can do a pre/post test of > this feature for my own enjoyment :-> (like for example... did test2 > have it?) Try FC6. Thanks, Richard. From lsof at nodata.co.uk Wed May 16 17:37:29 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 May 2007 19:37:29 +0200 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179336141.3921.1.camel@pensja.lam.pl> References: <1179335073.3513.10.camel@sb-home> <1179336141.3921.1.camel@pensja.lam.pl> Message-ID: <1179337049.3513.13.camel@sb-home> Am Mittwoch, den 16.05.2007, 19:22 +0200 schrieb Leszek Matok: > Dnia 16-05-2007, ?ro o godzinie 19:04 +0200, nodata napisa?(a): > > Hi. > > Are kernel-debuginfo packages available for rawhide? > As you're not using kernel.i386 for sure, check > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01036.html > > Lam Thanks. Google found nothing, too new :) From ddmbox2 at yahoo.co.uk Wed May 16 17:43:53 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 16 May 2007 18:43:53 +0100 Subject: what happened to kcalc & ksim ? In-Reply-To: <200705161829.07266.jamatos@fc.up.pt> References: <200705161826.35366.ddmbox2@yahoo.co.uk> <200705161829.07266.jamatos@fc.up.pt> Message-ID: <200705161843.55786.ddmbox2@yahoo.co.uk> On Wed May 16 2007 18:29:07 Jos? Matos wrote: > On Wednesday 16 May 2007 18:26:32 dexter wrote: > > howdy doody, > > $ yum search kcalc > > kdeutils-extras.i386 6:3.5.6-3.fc7 development > Matched from: > More Utilities for the K Desktop Environment: > * kcalc (scientific calculator); > * kmilo > * ksim (system information monitor); > * klaptopdaemon (battery monitoring and management for laptops); > > -- > Jos? Ab?lio thanx I'll grab it from koji as it aint showing in devel mirrors near me ...dex ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From lsof at nodata.co.uk Wed May 16 17:48:43 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 May 2007 19:48:43 +0200 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464B3EDB.2070709@redhat.com> References: <464B3EDB.2070709@redhat.com> Message-ID: <1179337723.3513.19.camel@sb-home> Am Mittwoch, den 16.05.2007, 12:26 -0500 schrieb Mike McGrath: > There will be an outage starting at 2007-05-17 04:00 [UTC], which will last > approximately 1 hour. To convert UTC to your local time, use: > http://www.timeanddate.com/worldclock/converter.html Or use date: date -d "2007-05-17 04:00 UTC" (if your time zone is set correctly) From wwoods at redhat.com Wed May 16 17:57:56 2007 From: wwoods at redhat.com (Will Woods) Date: Wed, 16 May 2007 13:57:56 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> Message-ID: <1179338276.8294.2.camel@metroid.rdu.redhat.com> On Wed, 2007-05-16 at 08:42 -0800, Jeff Spaleta wrote: > On 5/16/07, Richard Hughes wrote: > > So please point out new ideas, typos or maybe just general questions, > > and I'll try to answer then on these pages as best I can. > > When did the new quirkiness control go live in Fedora development? > I'm assuming its in use as of today in the development tree, but I'd > like to know at what point it was added so I can do a pre/post test of > this feature for my own enjoyment :-> (like for example... did test2 > have it?) The code was in previous test versions, but broken. We didn't actually start using the quirks properly until hal-0.5.9-6, which is a post-F7t4 update. So if you noticed suspend/resume suddenly working (or not working, as the case may be) after updating your F7Test4 system, that's why. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed May 16 18:01:04 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 10:01:04 -0800 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179338276.8294.2.camel@metroid.rdu.redhat.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> Message-ID: <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> On 5/16/07, Will Woods wrote: > The code was in previous test versions, but broken. We didn't actually > start using the quirks properly until hal-0.5.9-6, which is a post-F7t4 > update. So if you noticed suspend/resume suddenly working (or not > working, as the case may be) after updating your F7Test4 system, that's > why. Ah yes, pushed development onto this laptop as of May 10th, suspend went boom. got hal-0.5.9-6 on May 11th, haven't tried to suspend since then... let's see if it still goes boom. -jef From miles.lane at gmail.com Wed May 16 18:01:18 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 16 May 2007 11:01:18 -0700 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179336897.14246.66.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: On 5/16/07, Richard Hughes wrote: > On Wed, 2007-05-16 at 08:42 -0800, Jeff Spaleta wrote: > > On 5/16/07, Richard Hughes wrote: > > > So please point out new ideas, typos or maybe just general > > questions, It appears that something isn't working quite right in the system matching code. The 20-video-quirk-pm-hp.fdi file on my laptop currently contains: true true I tested that "pm-suspend --quirk-vbe-post --quirk-vbestate-restore" works for my machine, which is a HP Pavilion dv1240us. # lshal | grep system.hardware.product system.hardware.product = 'HP Pavilion dv1000 (PX324UA#ABA)' (string) So, as you can see, my system information should match the existing rule, but when I try to suspend, my video never comes back after resume. Evidently, the rule isn't being triggered. One more observation. It would be very useful for you to include that command I used ("lshal | grep system.hardware.product") in your online documentation. All the best, Miles From selinux at gmail.com Wed May 16 18:01:56 2007 From: selinux at gmail.com (Tom London) Date: Wed, 16 May 2007 11:01:56 -0700 Subject: Wireless Testing Needed for F7 In-Reply-To: <4c4ba1530705151752x2c269464y9b3f98ee79d97d42@mail.gmail.com> References: <4648AFFF.80906@redhat.com> <200705151922.50717.dennis@ausil.us> <1179276023.2940.69.camel@localhost.localdomain> <4c4ba1530705151752x2c269464y9b3f98ee79d97d42@mail.gmail.com> Message-ID: <4c4ba1530705161101j1957bfc6w5dafcda904c55878@mail.gmail.com> On 5/15/07, Tom London wrote: > On 5/15/07, Andrew Bartlett wrote: > > On Tue, 2007-05-15 at 19:22 -0500, Dennis Gilmore wrote: > > > Once upon a time Monday 14 May 2007, Warren Togami wrote: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238657 > > > > We are attempting to get wireless working on x86_64. > > > > > > > http://kojiweb.fedoraproject.org/packages/wireless-tools/28/3.fc7/ > > > > If you use wireless on ANY arch of rawhide, please test this latest > > > > wireless-tools build. We need to be sure that the x86_64 fix doesn't > > > > break i386 or ppc*. > > > > > > > > Please report in the above bug if release -3 is any better or worse than > > > > release -1 or -2. > > > > > > > > We really would like to confirm this before the proposed F7 final freeze > > > > on Thursday. > > > > > > > > Warren Togami > > > > wtogami at redhat.com > > > > > > wireless started working for me with this wireless-tools package. i'm on a > > > Dell Latitude D820 x86_64 with iwl3945 driver > > > > For me, on an Lenovo X60 (x86) with the iwl3945 driver, on the current > > rawhide kernel (2.6.21-1.3149.fc7) and 28-3 release of the wireless tool > > this works until NetworkManager does a rescan. > > > > This is pretty much in line with what I've been seeing for quite a while > > over various kernels now (I've never had it work any more than this > > much, and often worse). > > > > Andrew Bartlett > > > Same hardware, same results... I get about 15 seconds worth of > traffic through before it 'stops working'. > > Get lots of these (don't remember getting these before): > > wlan0: CTS protection disabled (BSSID=00:14:6a:5b:3a:80) > printk: 18 messages suppressed. > wlan0: CTS protection enabled (BSSID=00:14:6a:5b:3a:80) > printk: 17 messages suppressed. > wlan0: CTS protection enabled (BSSID=00:14:6a:5b:3a:80) > printk: 20 messages suppressed. > wlan0: CTS protection disabled (BSSID=00:14:6a:5b:3a:80) > This seems more complicated.... With above hardware/system (Thinkpad X60, NetworkManager, ...), if I connect to a 'very close' AP (i.e., Linksys WRT54G, less than 3 feet away), system stays connected and is rock solid. The above unstable situation is ('@work') where there are multiple APs for the same SSID, and I'm (much) further away, so the link quality is not as good. Here is the output from 'iwlist wlan0 scan' when connected to the very close AP. I believe the 'Quality' numbers are not correct: Cell 01 - Address: 00:12:17:46:42:51 ESSID:"free4all" Mode:Master Channel:10 Frequency:2.457 GHz Quality=92/100 Signal level=-35 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s 12 Mb/s; 48 Mb/s Extra:tsf=0000008d40a4e6be Extra:bcn_int=100 Extra:capab=0x0431 Cell 02 - Address: 00:0D:97:04:0C:BE ESSID:"GoogleWiFi" Mode:Master Channel:9 Frequency:2.452 GHz Quality=95/100 Signal level=-71 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000000619d91557c Extra:bcn_int=250 Extra:capab=0x0001 Running from '@work' (multiple APs, multiple networks), network 'disassociates' quickly. I attach output from dmesg. tom -- Tom London -------------- next part -------------- wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: RX authentication from 00:14:6a:5b:3a:80 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:14:6a:5b:3a:80 wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: RX AssocResp from 00:14:6a:5b:3a:80 (capab=0x431 status=0 aid=143) wlan0: associated wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready iwl3945: REPLY_ADD_STA failed wlan0: association frame received from 00:14:6a:5b:3a:80, but not in associate state - ignored iwl3945: REPLY_ADD_STA failed hwcrypto disabled! hwcrypto disabled! hwcrypto disabled! hwcrypto disabled! wlan0: no IPv6 routers present wlan0: no IPv6 routers present wlan0: No ProbeResp from current AP 00:14:6a:5b:3a:80 - assume out of range hwcrypto disabled! wlan0: No STA entry for own AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authentication with AP 00:14:6a:5b:3a:80 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: deauthenticated wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authentication with AP 00:14:6a:5b:3a:80 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authentication with AP 00:14:6a:5b:3a:80 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authentication with AP 00:14:6a:5b:3a:80 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: authentication with AP 00:14:6a:5b:3a:80 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:16:c8:9b:7d:60 wlan0: authenticate with AP 00:16:c8:9b:7d:60 wlan0: authenticate with AP 00:16:c8:9b:7d:60 wlan0: authentication with AP 00:16:c8:9b:7d:60 timed out wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:16:c8:9b:7d:60 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:16:c8:9b:7d:60 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: RX authentication from 00:14:6a:5b:3a:80 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:14:6a:5b:3a:80 wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: authentication frame received from 00:14:6a:5b:3a:80, but not in authenticate state - ignored wlan0: RX ReassocResp from 00:14:6a:5b:3a:80 (capab=0x431 status=0 aid=169) wlan0: associated wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 wlan0: association frame received from 00:14:6a:5b:3a:80, but not in associate state - ignored iwl3945: REPLY_ADD_STA failed iwl3945: REPLY_ADD_STA failed wlan0: RX WEP frame with unknown keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80 A3=00:00:74:ad:43:b1) wlan0: RX deauthentication from 00:14:6a:5b:3a:80 (reason=2) wlan0: deauthenticated wlan0: RX WEP frame with unknown keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80 A3=00:c0:b7:7f:67:8a) wlan0: RX WEP frame with unknown keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80 A3=00:0d:56:bc:0e:d0) wlan0: RX WEP frame with unknown keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80 A3=00:30:48:43:86:f4) wlan0: RX WEP frame with unknown keyidx 1 (A1=01:80:c2:00:00:00 A2=00:14:6a:5b:3a:80 A3=00:04:80:c9:54:2f) wlan0: RX WEP frame with unknown keyidx 1 (A1=01:80:c2:00:00:00 A2=00:14:6a:5b:3a:80 A3=00:04:80:c9:54:2f) wlan0: RX WEP frame with unknown keyidx 1 (A1=ff:ff:ff:ff:ff:ff A2=00:14:6a:5b:3a:80 A3=00:00:74:ad:43:b1) wlan0: authenticate with AP 00:14:6a:5b:3a:80 wlan0: RX authentication from 00:14:6a:5b:3a:80 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:14:6a:5b:3a:80 wlan0: RX ReassocResp from 00:14:6a:5b:3a:80 (capab=0x431 status=0 aid=170) wlan0: associated iwl3945: REPLY_ADD_STA failed iwl3945: REPLY_ADD_STA failed wlan0: disassociate(reason=3) iwl3945: check mac addr 1 | 1 iwl3945: check basic rate 2 | 1 iwl3945: check assoc id 3 | 1 iwl3945: check CCK and short slot 4 | 1 iwl3945: check CCK & auto detect 5 | 1 iwl3945: check TGG 6 | 1 iwl3945: check antenna 7 1 iwl3945: Tuning to channel 2 iwl3945: Error not a valid ipw_rxon_assoc_cmd field values iwl3945: Invalid RXON configuration. Not committing. From jspaleta at gmail.com Wed May 16 18:17:21 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 10:17:21 -0800 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> Message-ID: <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> On 5/16/07, Jeff Spaleta wrote: > Ah yes, pushed development onto this laptop as of May 10th, suspend went boom. > got hal-0.5.9-6 on May 11th, haven't tried to suspend since then... > let's see if it still goes boom. Hey it sort of works... suspending while in the dock and resuming while still in the dock...NM is a bit confused after the resume and didn't re-enable my wired network..but it resumed. Need to see how screwed up all permutations of wired/wireles, dock/no-dock and suspend/resume are. -jef From wcohen at redhat.com Wed May 16 18:47:34 2007 From: wcohen at redhat.com (William Cohen) Date: Wed, 16 May 2007 14:47:34 -0400 Subject: Looking for GUI application programs for experiments In-Reply-To: <20070515223623.GA30538@devserv.devel.redhat.com> References: <464A09CF.6030303@redhat.com> <20070515223623.GA30538@devserv.devel.redhat.com> Message-ID: <464B51C6.7050609@redhat.com> Alan Cox wrote: > On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote: >> linked programs like SPEC CPU to provide workload for the simulator. This >> is very different than the typical shared-library, GUI application > > You know you can catch TLB misses on some real x86 processors I assume ? > > (You load the page table entry as missing then when you take the trap you > put the entry in, touch the page to load it, and then mark it missing again) > > Alan > Hi Alan, This method would address some of the for future work: how to speed up the data collection and avoid the distortions caused by the addition mmap regions valgrind pulls in. I think that there have been some previous research implementing this, e.g. Tape Worm. Just thinking how this TLB trap handling would work for the following cases: instructions spanning pages instructions with data reference (two (or more) page accesses) The ability not to need a dedicated machine did factor into the choice. The use of Valgrind was also influence about what students are comfortable with. Modifying valgrind, a user-space only tool, is a bit easier when things don't work correctly for a student. -Will From miles.lane at gmail.com Wed May 16 18:52:42 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 16 May 2007 11:52:42 -0700 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: I notice what seems to be a bug in pm-suspend. If I run "pm-suspend --quirk-vbestate-restore --quirk-vbe-post", when I resume I get about a hundred linefeeds in the terminal where I ran the command. Also, one time I ran pm-suspend with the needed arguments and when I resumed the display stayed showing a VT. I switched to Xorg and shortly thereafter the machine locked up. Miles From sundaram at fedoraproject.org Wed May 16 19:18:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 00:48:45 +0530 Subject: Making beagle optional In-Reply-To: <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> References: <1179154692.3560.23.camel@localhost.localdomain> <16de708d0705141359wf65f859uf747c89a245c6870@mail.gmail.com> <1179184279.3478.9.camel@daemon> <64b14b300705150328le23057nec1f878d6a676293@mail.gmail.com> <1179240586.3755.27.camel@localhost.localdomain> <64b14b300705160205mf0a685dkd333541b5f04b306@mail.gmail.com> Message-ID: <464B5915.4050202@fedoraproject.org> Valent Turkovic wrote: > On 5/15/07, Alexander Larsson wrote: >> On Tue, 2007-05-15 at 12:28 +0200, Valent Turkovic wrote: >> > Is there maybe an option to whip beagle into shape and not to use >> 100% of cpu? >> > >> > Is there no other way? Is disabling it really the only option? >> >> The decision has been made for Fedora 7. >> >> But you can help out for Fedora 8 by fixing bugs like: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 > > I subscribet to that bug, but for me on my 2 Fedora Core 6 systems > beagle works flawlessly! And I use it all the time... not 100% cpu > usage, no slowdowns... it "just works"tm :) > > If this aproach would be the same with all components of Fedora I > personaly have trouble with then there would be an empty application > menue if you would remove all apps that have some little bugs. 100% cpu utilization is by no means a little bug. Beagle is not being removed. Merely not installed by default. Rahul From pjones at redhat.com Wed May 16 19:22:26 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 16 May 2007 15:22:26 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179336897.14246.66.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: <464B59F2.5070800@redhat.com> Richard Hughes wrote: > On Wed, 2007-05-16 at 08:42 -0800, Jeff Spaleta wrote: >> On 5/16/07, Richard Hughes wrote: >>> So please point out new ideas, typos or maybe just general >> questions, >>> and I'll try to answer then on these pages as best I can. >> When did the new quirkiness control go live in Fedora development? > > About 6 months ago if my memory serves me correctly. It's been evolving > as upstream has evolved since FC6 was split. > >> I'm assuming its in use as of today in the development tree, but I'd >> like to know at what point it was added so I can do a pre/post test of >> this feature for my own enjoyment :-> (like for example... did test2 >> have it?) > > Try FC6. Thanks, Actually, the "quirks" code hit the tree March 13, in pm-utils-0.99.2-1 and hal-0.5.9-0.git20070304 , which was between test2 and test3. But alas, there was a bug that didn't get fixed until hal-0.5.9-6 (April 25) that caused it not to work for some people. -- Peter From karsten at redhat.de Wed May 16 19:22:38 2007 From: karsten at redhat.de (Karsten Hopp) Date: Wed, 16 May 2007 21:22:38 +0200 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <464B3607.2070602@math.unl.edu> References: <464B3607.2070602@math.unl.edu> Message-ID: <20070516192238.GA825@redhat.de> On Wed, May 16, 2007 at 11:49:11AM -0500, Rex Dieter wrote: > Than Ngo (than) wrote: > > > Author: than > > Update of /cvs/extras/rpms/kdelibs/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29578 > > Modified Files: > > kdelibs.spec > > > Log Message: > ... > > - disable kde_settings > > wtf? I just went through the work enabling kde-settings, why are you > disabling it? > > -- Rex > Well, did you discuss such changes with the maintainer before you started working on it (as I would expect from a co-maintainer) ? Or did you just commit them in the hope that he would agree ? Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From pjones at redhat.com Wed May 16 19:25:01 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 16 May 2007 15:25:01 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: <464B5A8D.9060201@redhat.com> Miles Lane wrote: > I notice what seems to be a bug in pm-suspend. If I run "pm-suspend > --quirk-vbestate-restore --quirk-vbe-post", when I resume I get about > a hundred linefeeds in the terminal where I ran the command. That's actually an X bug -- changing the terminal from X to a text console causes the X event buffer to be locked for some time while it thinks your enter key is held down, and it counts one press for every interrupt taken during the terminal switch. If you want to run pm-suspend directly from a terminal in X, you should basically do: sleep 1 ; pm-suspend --quirk-vbestate-restore ... -- Peter From rdieter at math.unl.edu Wed May 16 19:39:24 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 16 May 2007 14:39:24 -0500 Subject: rpms/kdelibs/devel kdelibs.spec References: <464B3607.2070602@math.unl.edu> <20070516192238.GA825@redhat.de> Message-ID: Karsten Hopp wrote: > On Wed, May 16, 2007 at 11:49:11AM -0500, Rex Dieter wrote: >> Than Ngo (than) wrote: >> >> > Author: than >> > Update of /cvs/extras/rpms/kdelibs/devel >> > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29578 >> > Modified Files: >> > kdelibs.spec >> >> > Log Message: >> ... >> > - disable kde_settings >> >> wtf? I just went through the work enabling kde-settings, why are you >> disabling it? > Well, did you discuss such changes with the maintainer before you started > working on it (as I would expect from a co-maintainer) ? > Or did you just commit them in the hope that he would agree ? Yes, we discussed it(*). KDE SIG meetings have also included the topic for many weeks (most of which than hasn't been present, unfortunately). -- Rex (*) admittedly than wasn't thrilled about such a non-trivial change going in at such a late-date, starting at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 From pjones at redhat.com Wed May 16 19:46:13 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 16 May 2007 15:46:13 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> Message-ID: <464B5F85.8070100@redhat.com> Jeff Spaleta wrote: > On 5/16/07, Jeff Spaleta wrote: >> Ah yes, pushed development onto this laptop as of May 10th, suspend >> went boom. >> got hal-0.5.9-6 on May 11th, haven't tried to suspend since then... >> let's see if it still goes boom. > > Hey it sort of works... suspending while in the dock and resuming > while still in the dock...NM is a bit confused after the resume and > didn't re-enable my wired network..but it resumed. Yeah, I've seen that happen sometimes, but haven't yet had a chance to hunt down why. Can you reproduce it consistently? If so, does dissabling /apps/gnome-power-manager/networkmanager_sleep in gconf make it better? If that doesn't help, does re-enabling it and doing: touch /etc/pm/sleep.d/10NetworkManager help? (Richard, why does this setting still exist in g-p-m? Or is my gconf entry a relic?) -- Peter From zcerza at redhat.com Wed May 16 19:55:33 2007 From: zcerza at redhat.com (Zack Cerza) Date: Wed, 16 May 2007 15:55:33 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> Message-ID: <464B61B5.5080205@redhat.com> Jeff Spaleta wrote: > On 5/16/07, Jeff Spaleta wrote: >> Ah yes, pushed development onto this laptop as of May 10th, suspend >> went boom. >> got hal-0.5.9-6 on May 11th, haven't tried to suspend since then... >> let's see if it still goes boom. > > Hey it sort of works... suspending while in the dock and resuming > while still in the dock...NM is a bit confused after the resume and > didn't re-enable my wired network..but it resumed. Need to see how > screwed up all permutations of wired/wireles, dock/no-dock and > suspend/resume are. > > -jef Not that this'll help you right now, but I filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239108 when I saw the wired network issue. Zack From caillon at redhat.com Wed May 16 19:55:08 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 16 May 2007 15:55:08 -0400 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: References: <464B3607.2070602@math.unl.edu> <20070516192238.GA825@redhat.de> Message-ID: <464B619C.2030605@redhat.com> Rex Dieter wrote: > (*) admittedly than wasn't thrilled about such a non-trivial change going in > at such a late-date, starting at: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 And you went ahead and did it anyway? "I'll do it anyway" flippancy especially from long time contributors is not going to encourage ex-Core package maintainers to want to add others to the ACL/co-maintainers lists for the packages they own. Than should retain a certain level of respect and I support his decision in this case. From sundaram at fedoraproject.org Wed May 16 19:59:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 01:29:04 +0530 Subject: Making beagle optional In-Reply-To: <200705141632.18242.jkeating@redhat.com> References: <1179154692.3560.23.camel@localhost.localdomain> <200705141614.51678.jkeating@redhat.com> <200705141632.18242.jkeating@redhat.com> Message-ID: <464B6288.2050706@fedoraproject.org> Jesse Keating wrote: > On Monday 14 May 2007 16:14:48 Jesse Keating wrote: >> The beagle package set will be added to the manifest for the 'Fedora' spin >> of Fedora 7. This will help folks upgrading from Fedora Core 6 that may >> have beagle installed. > > To clarify, this will make the beagle packages available on the Fedora spin > isos, but still only optional packages. They will be available for the > upgrade case, and users would have to click on them specifically in the > package selection screen to get them on the install case. It won't be available within the live images. Right? Rahul From katzj at redhat.com Wed May 16 20:09:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 16 May 2007 16:09:51 -0400 Subject: Making beagle optional In-Reply-To: <464B6288.2050706@fedoraproject.org> References: <1179154692.3560.23.camel@localhost.localdomain> <200705141614.51678.jkeating@redhat.com> <200705141632.18242.jkeating@redhat.com> <464B6288.2050706@fedoraproject.org> Message-ID: <1179346191.2025.12.camel@erebor.boston.redhat.com> On Thu, 2007-05-17 at 01:29 +0530, Rahul Sundaram wrote: > Jesse Keating wrote: > > On Monday 14 May 2007 16:14:48 Jesse Keating wrote: > >> The beagle package set will be added to the manifest for the 'Fedora' spin > >> of Fedora 7. This will help folks upgrading from Fedora Core 6 that may > >> have beagle installed. > > > > To clarify, this will make the beagle packages available on the Fedora spin > > isos, but still only optional packages. They will be available for the > > upgrade case, and users would have to click on them specifically in the > > package selection screen to get them on the install case. > > It won't be available within the live images. Right? Right, as that's defined by the default packages for a "normal" install. It's just as available to install afterwards[1]. Jeremy [1] One of the things I want to at least consider for F8 is how to do somewhat of a "hybrid" live install... where you get the live image and can then add any packages that you want or remove packages. Or maybe it doesn't make sense to do that and people should just run pirut after rebooting into the installed system. I can really go both ways about this From miles.lane at gmail.com Wed May 16 21:38:13 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 16 May 2007 14:38:13 -0700 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <464B5A8D.9060201@redhat.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> <464B5A8D.9060201@redhat.com> Message-ID: On 5/16/07, Peter Jones wrote: [...] > That's actually an X bug -- changing the terminal from X to a text > console causes the X event buffer to be locked for some time while it > thinks your enter key is held down, and it counts one press for every > interrupt taken during the terminal switch. > > If you want to run pm-suspend directly from a terminal in X, you should > basically do: > > sleep 1 ; pm-suspend --quirk-vbestate-restore ... Yep. That worked. Thanks. Miles From miles.lane at gmail.com Wed May 16 21:40:22 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 16 May 2007 14:40:22 -0700 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: > > true > true erge> > > > # lshal | grep system.hardware.product > system.hardware.product = 'HP Pavilion dv1000 (PX324UA#ABA)' (string) Hello, Can someone please tell me how I might discover why pressing the lid button on my laptop isn't triggering this rule? Thanks! Miles From hughsient at gmail.com Wed May 16 22:18:46 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 May 2007 23:18:46 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: <1179353926.2520.14.camel@localhost.localdomain> On Wed, 2007-05-16 at 14:40 -0700, Miles Lane wrote: > Can someone please tell me how I might discover why pressing the lid > button on my laptop isn't triggering this rule? Are you using gnome-power-manager (which uses HAL) or some script in /etc/acpid/ to detect the lid press? If stuff doesn't use HAL, then the quirks are not matched. Richard. From rodd at clarkson.id.au Thu May 17 00:04:17 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 17 May 2007 10:04:17 +1000 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179335073.3513.10.camel@sb-home> References: <1179335073.3513.10.camel@sb-home> Message-ID: <1179360257.2967.23.camel@localhost.localdomain> On Wed, 2007-05-16 at 19:04 +0200, nodata wrote: > Hi. > Are kernel-debuginfo packages available for rawhide? > > I can't find them with yum, or on the ftp server. debuginfo has it's own repo that needs to be enabled. either use --enablerepo or do it manually in /etc/yum.repo.d R. -- "It's a fine line between denial and faith. It's much better on my side" From skvidal at linux.duke.edu Thu May 17 00:07:24 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 16 May 2007 20:07:24 -0400 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179360257.2967.23.camel@localhost.localdomain> References: <1179335073.3513.10.camel@sb-home> <1179360257.2967.23.camel@localhost.localdomain> Message-ID: <1179360444.10909.14.camel@rivendell> On Thu, 2007-05-17 at 10:04 +1000, Rodd Clarkson wrote: > On Wed, 2007-05-16 at 19:04 +0200, nodata wrote: > > Hi. > > Are kernel-debuginfo packages available for rawhide? > > > > I can't find them with yum, or on the ftp server. > > debuginfo has it's own repo that needs to be enabled. > > either use --enablerepo or do it manually in /etc/yum.repo.d > > and if you have the latest yum-utils installed you can run: debuginfo-install kernel and see if it gets it right :) -sv From dennis at ausil.us Thu May 17 01:58:58 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 16 May 2007 20:58:58 -0500 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <464B619C.2030605@redhat.com> References: <464B3607.2070602@math.unl.edu> <464B619C.2030605@redhat.com> Message-ID: <200705162059.02949.dennis@ausil.us> Once upon a time Wednesday 16 May 2007, Christopher Aillon wrote: > Rex Dieter wrote: > > (*) admittedly than wasn't thrilled about such a non-trivial change going > > in at such a late-date, starting at: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 > > And you went ahead and did it anyway? "I'll do it anyway" flippancy > especially from long time contributors is not going to encourage ex-Core > package maintainers to want to add others to the ACL/co-maintainers > lists for the packages they own. Than should retain a certain level of > respect and I support his decision in this case. The way Than has not participated makes him more a co-maintainer than maintainer. in all honesty he is lucky to have any access to the kde packages at all right now. We had to drag him kicking and screaming to work with the community. Right now i'm willing to have him removed from all Fedora KDE access. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Thu May 17 02:26:27 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 16 May 2007 22:26:27 -0400 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <200705162059.02949.dennis@ausil.us> References: <464B3607.2070602@math.unl.edu> <464B619C.2030605@redhat.com> <200705162059.02949.dennis@ausil.us> Message-ID: <1179368787.32749.1.camel@localhost.localdomain> On Wed, 2007-05-16 at 20:58 -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 16 May 2007, Christopher Aillon wrote: > > Rex Dieter wrote: > > > (*) admittedly than wasn't thrilled about such a non-trivial change going > > > in at such a late-date, starting at: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 > > > > And you went ahead and did it anyway? "I'll do it anyway" flippancy > > especially from long time contributors is not going to encourage ex-Core > > package maintainers to want to add others to the ACL/co-maintainers > > lists for the packages they own. Than should retain a certain level of > > respect and I support his decision in this case. > > The way Than has not participated makes him more a co-maintainer than > maintainer. in all honesty he is lucky to have any access to the kde > packages at all right now. We had to drag him kicking and screaming to work > with the community. Right now i'm willing to have him removed from all > Fedora KDE access. Yeah, this kind of talk is sure to close doors for community participation in maintenance of core packages. Last I looked, hostile takeovers of packages were not part of the accepted norms in Fedora. From rdieter at math.unl.edu Thu May 17 03:07:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 16 May 2007 22:07:32 -0500 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <1179368787.32749.1.camel@localhost.localdomain> References: <464B3607.2070602@math.unl.edu> <464B619C.2030605@redhat.com> <200705162059.02949.dennis@ausil.us> <1179368787.32749.1.camel@localhost.localdomain> Message-ID: <464BC6F4.90703@math.unl.edu> Look folks, chill. This thread is going nowhere (good) fast. I apologize profusely for even raising the issue here at all. I'll work out any differences I have with than privately. -- Rex p.s. don't get me wrong, I will continue to fight tooth-n-nail for this vital feature to be included in F7, but not at the cost of fracturing community or relationships. From dennis at ausil.us Thu May 17 03:35:07 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 16 May 2007 22:35:07 -0500 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <1179368787.32749.1.camel@localhost.localdomain> References: <464B3607.2070602@math.unl.edu> <200705162059.02949.dennis@ausil.us> <1179368787.32749.1.camel@localhost.localdomain> Message-ID: <200705162235.07385.dennis@ausil.us> Once upon a time Wednesday 16 May 2007, Matthias Clasen wrote: > On Wed, 2007-05-16 at 20:58 -0500, Dennis Gilmore wrote: > > Once upon a time Wednesday 16 May 2007, Christopher Aillon wrote: > > > Rex Dieter wrote: > > > > (*) admittedly than wasn't thrilled about such a non-trivial change > > > > going in at such a late-date, starting at: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 > > > > > > And you went ahead and did it anyway? "I'll do it anyway" flippancy > > > especially from long time contributors is not going to encourage > > > ex-Core package maintainers to want to add others to the > > > ACL/co-maintainers lists for the packages they own. Than should retain > > > a certain level of respect and I support his decision in this case. > > > > The way Than has not participated makes him more a co-maintainer than > > maintainer. in all honesty he is lucky to have any access to the kde > > packages at all right now. We had to drag him kicking and screaming to > > work with the community. Right now i'm willing to have him removed from > > all Fedora KDE access. > > Yeah, this kind of talk is sure to close doors for community > participation in maintenance of core packages. Last I looked, hostile > takeovers of packages were not part of the accepted norms in Fedora. Indeed i should not have been so harsh and i appologise to all. There really needs to be no us and them we are all the same team. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu May 17 03:42:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 May 2007 23:42:49 -0400 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179360257.2967.23.camel@localhost.localdomain> References: <1179335073.3513.10.camel@sb-home> <1179360257.2967.23.camel@localhost.localdomain> Message-ID: <20070517034249.GF18242@nostromo.devel.redhat.com> Rodd Clarkson (rodd at clarkson.id.au) said: > On Wed, 2007-05-16 at 19:04 +0200, nodata wrote: > > Hi. > > Are kernel-debuginfo packages available for rawhide? > > > > I can't find them with yum, or on the ftp server. > > debuginfo has it's own repo that needs to be enabled. > > either use --enablerepo or do it manually in /etc/yum.repo.d Right, but there was a bug in the tree creation that was not including i[56]86 debuginfo in the i386 tree. Should be fixed in the next push. Bill From jkeating at redhat.com Thu May 17 05:14:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 01:14:12 -0400 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464B3EDB.2070709@redhat.com> References: <464B3EDB.2070709@redhat.com> Message-ID: <200705170114.13392.jkeating@redhat.com> On Wednesday 16 May 2007 13:26:51 Mike McGrath wrote: > There will be an outage starting at 2007-05-17 04:00 [UTC], which will last > approximately 1 hour. To convert UTC to your local time, use: > http://www.timeanddate.com/worldclock/converter.html > > Affected Services: > > Buildsystem > > Unaffected Services: > > Websites > CVS / Source Control > Database > DNS > Mail > Torrent > > > > Reason for Outage: > Upgrading Koji to a new version and moving koji store to new hardware. > This outage should be approximately 1 hour, maybe longer if the sync is > running slower then expected. Will be coordinating in #fedora-admin The > build system should either reject connections or queue connections during > this time. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to > track the status of this outage. > Current status: Koji software has been updated. We're still waiting for the final rsync to finish to move to new storage. The outage may wind up taking more than an hour, however we really need to get to this new storage so we'll keep things down until that is done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu May 17 05:17:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 May 2007 00:17:33 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464B3EDB.2070709@redhat.com> References: <464B3EDB.2070709@redhat.com> Message-ID: <464BE56D.604@redhat.com> Mike McGrath wrote: > There will be an outage starting at 2007-05-17 04:00 [UTC], which will > last > approximately 1 hour. To convert UTC to your local time, use: > http://www.timeanddate.com/worldclock/converter.html An outage is as an outage does. This one is taking longer then we had planned for a few reasons. Stop by #fedora-admin to check on the status but we're going to see this one through till its done. I'll send a notification when that is. -Mike From buildsys at redhat.com Thu May 17 06:40:23 2007 From: buildsys at redhat.com (Build System) Date: Thu, 17 May 2007 02:40:23 -0400 Subject: rawhide report: changes Message-ID: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> New package gsm Shared libraries for GSM speech compressor New package kde-settings Config files for kde New package liberation-fonts Fonts to replace commonly used Microsoft Windows Fonts New package mcpp Alternative C/C++ preprocessor New package php-pear-HTML-QuickForm-ElementGrid Meta-element which holds any other element in a grid Removed package gaim-gaym Updated Packages: ack-1.60-2.fc7 -------------- * Tue May 15 2007 Ian M. Burrell - 1.60-1 - add BuildRequires perl(ExtUtils::MakeMaker) * Sat May 05 2007 - 1.60-4 - Update to 1.60; requires File::Next 0.40 aircrack-ng-0.9-1.fc7 --------------------- * Mon May 14 2007 Till Maas - 0.9-1 - update to latest version anaconda-11.2.0.59-1 -------------------- * Tue May 15 2007 Chris Lumens - 11.2.0.59-1 - Set the timezone when language is changed in text mode (#239826). - Replace pump-stub with dhcpclient-stub (dcantrell, #239427). - Set preferred color on upgrades (pnasrat, #235757). - Fix livecd text mode traceback (katzj). - Kickstart documentation updates (#234187). - Increase early swap size on 64bit platforms (katzj, #238266). - Various network fixes (dcantrell). - Fix syslinux highlighting (katzk). cacti-0.8.6j-1.fc7 ------------------ * Sat May 05 2007 Mike McGrath - 0.8.6j-5 - Upstream released new version catfish-0.3-0.1.b.fc7 --------------------- * Tue May 15 2007 Mamoru Tasaka 0.3-0.1.b - 0.3b cernlib-2006-11.fc7 ------------------- * Mon May 14 2007 Patrice Dumas 2006-11 - disable the same tests on ppc64 than on x86_64 * Mon May 14 2007 Patrice Dumas 2006-10.1 - packlib/{ffread,hbook} test segfaults on ppc64 * Sun May 13 2007 Patrice Dumas 2006-9 - add a compat prefix when built with g77 - new debian patcheset control-center-1:2.18.0-16.fc7 ------------------------------ * Tue May 01 2007 - Bastien Nocera - 2.18.0-16 - Add missing dbus-x11 dependency, otherwise gnome-settings-daemon cannot be started (#204706) * Tue May 01 2007 - Bastien Nocera - 2.18.0-15 - Add a patch to set the permissions on ~/.face so that GDM can show them (#236393) createrepo-0.4.8-4.fc7 ---------------------- * Tue May 15 2007 Jeremy Katz - 0.4.8-4 - fix the last patch * Tue May 15 2007 Jeremy Katz - 0.4.8-3 - use dbversion given by yum-metadata-parser instead of hardcoded value (#239938) cups-pdf-2.4.6-1.fc7 -------------------- * Sun May 06 2007 Remi Collet 2.4.6-1 - update to 2.4.6 * Sun Apr 08 2007 Remi Collet 2.4.5-1 - update to 2.4.5 * Sat Feb 03 2007 Remi Collet 2.4.4-1 - update to 2.4.4 cyphesis-0.5.12-1.fc7 --------------------- * Mon May 07 2007 Wart 0.5.12-1 - Update to 0.5.12 eclipse-1:3.2.2-13.fc7 ---------------------- * Tue May 15 2007 Ben Konrath 3.2.2-13 - Another bug fix for launch-addplatformtotildeeclipse.patch. - Add BR/B tomcat >= 5.5.20 instead of just = 5.5.20. - Resolves: #240025. * Wed May 02 2007 Ben Konrath 3.2.2-12 - Fix additional problem with launcher-addplatformtotildeeclipse.patch. - Resolves: #238109. * Mon Apr 30 2007 Ben Konrath 3.2.2-11 - Add workaround in launcher-addplatformtotildeeclipse.patch for problems caused by bug #238109. - Resolves: #238109. gdm-1:2.18.0-14.fc7 ------------------- * Tue May 15 2007 Ray Strode - 1:2.18.0-14 - hide users from userlist that have disabled shells (bug 240148) * Thu May 10 2007 Matthias Clasen - 1:2.18.0-13 - Follow packaging guidelines for scrollkeeper dependencies ghc-6.6.1-3.fc7 --------------- * Thu May 10 2007 Bryan O'Sullivan - 6.6.1-3 - install man page for ghc * Thu May 10 2007 Bryan O'Sullivan - 6.6.1-2 - exclude ppc64 for now, due to lack of time to bootstrap * Wed May 09 2007 Bryan O'Sullivan - 6.6.1-1 - update to 6.6.1 release glibc-2.6-1 ----------- * Tue May 15 2007 Roland McGrath - 2.6-1 - glibc 2.6 release * Fri May 11 2007 Jakub Jelinek 2.5.90-24 - utimensat, futimens and lutimes support * Thu May 10 2007 Jakub Jelinek 2.5.90-23 - use madvise MADV_DONTNEED in malloc - fix ia64 feraiseexcept - fix s390{,x} feholdexcept (BZ#3427) - ppc fenv fixes - make fdatasync a cancellation point (BZ#4465) - fix *printf for huge precisions with wide char code and multi-byte strings - fix dladdr (#232224, BZ#4131) gnome-power-manager-2.18.2-4.fc7 -------------------------------- * Wed May 16 2007 Matthias Clasen - 2.18.2-4 - Don't put markup in notification summaries (#240258) gnome-session-2.18.0-7.fc7 -------------------------- * Tue May 15 2007 Ray Strode - 2.18.0-7 - Don't show iris animation when using compiz (bug 237842) * Sun May 06 2007 Matthias Clasen - 2.18.0-6 - Don't own /usr/share/applications gnonlin-0.10.8-1.fc7 -------------------- * Tue May 15 2007 Brian Pepple - 0.10.8-1 - Update to 0.10.8. gtk2-2.10.11-6.fc7 ------------------ * Tue May 15 2007 Matthias Clasen - 1.10.11-6 - Backport some fixes for the ftw()-based search engine * Tue Apr 10 2007 Matthias Clasen - 1.10.11-5 - Use DESKTOP xdg-user-dir in the file chooser * Mon Apr 09 2007 Matthias Clasen - 1.10.11-4 - Fix a memory leak in the search patch gtk2-engines-2.10.0-3.fc7 ------------------------- * Tue May 15 2007 Matthias Clasen - 2.10.0-3 - Fix some memory corruption errors * Wed Apr 25 2007 Matthias Clasen - 2.10.0-2 - Remove and undefined macro (#237810) gtk2hs-0.9.11-4.fc7 ------------------- * Thu May 10 2007 Bryan O'Sullivan - 0.9.11-4 - disable ppc64 build (#239752) * Thu May 10 2007 Bryan O'Sullivan - 0.9.11-3 - rebuild against ghc 6.6.1 httpd-2.2.4-4 ------------- * Wed May 09 2007 Joe Orton 2.2.4-4 - update welcome page branding initscripts-8.54-1 ------------------ * Tue May 15 2007 Bill Nottingham 8.54-1 - translation updates: as, bg, cs, ja, ms - redirect bogus errors from cryptsetup to /dev/null jakarta-commons-modeler-0:2.0-3jpp.1.fc7 ---------------------------------------- * Wed Mar 21 2007 Matt Wringe - 0:2.0-3jpp.1 - Merge with lastest jpp version * Wed Mar 21 2007 Matt Wringe - 0:2.0-3jpp - Make provides and obsoletes versioned - Fix eol encoding on various files * Mon Mar 12 2007 Jason Corley - 0:2.0-2jpp - respin to upload to main repo - fix rpmlint warnings jd-1.9.5-0.1.beta070516.fc7 --------------------------- * Tue May 15 2007 Mamoru Tasaka - 1.9.5-0.1.beta070516 - 1.9.5 beta 070516 * Tue Apr 03 2007 Mamoru Tasaka - 1.8.8-1 - 1.8.8 * Fri Mar 30 2007 Mamoru Tasaka - 1.8.8-0.3.rc070330 - 1.8.8 rc 070330 kdebase-6:3.5.6-10.fc7 ---------------------- * Tue May 15 2007 Rex Dieter - 6:3.5.6-10 - drop unconditional --with-sensors, let %configure autodetect * Tue May 15 2007 Rex Dieter - 6:3.5.6-9 - create/own {/usr,/etc/kde}/{env,shutdown} (#178326) * Tue May 15 2007 Rex Dieter - 6:3.5.6-8 - cleanup/simplify scriptlets - drop Req/Prov's that include %_arch (they don't work) - Req: +samba-common - BR: +OpenEXR-devel, -cdparanoia - env.sh: use XDG_MENU_PREFIX - npapi-64bit-fixes.patch kdelibs-6:3.5.6-7.fc7 --------------------- * Mon May 14 2007 Rex Dieter - 6:3.5.6-7 - BR: +keyutils-libs-devel (until krb5-devel's Reqs are fixed) * Mon May 14 2007 Rex Dieter - 6:3.5.6-6 - kde.sh: fix typo/thinko * Mon May 14 2007 Rex Dieter - 6:3.5.6-5 - %changelog: prune pre-kde3 entries - %ghost %{_datadir}/services/ksycoca - omit extraneous .la file references (#178733) - BR: jasper-devel OpenEXR-devel - xdg-menu compat symlinks (to help transition to using XDG_MENU_PREFIX) - fix kde#126812.patch to be non-empty - cleanup kde.(sh|csh) - Requires: +kde-settings -redhat-artwork - make apidocs build optional (default on) - use FHS-friendly /etc/kde (#238136) kernel-2.6.21-1.3163.fc7 ------------------------ * Tue May 15 2007 Dave Jones - Add quirk for Siemens Nixdorf AG FSC Multiprocessor Interrupt Controller * Tue May 15 2007 Dave Jones - Fix oprofile. * Tue May 15 2007 Dave Jones - Add cpufreq-git, fixes #239724 koji-1.2.0-3.fc7 ---------------- * Tue May 15 2007 Jesse Keating - 1.2.0-3 - More fixes to fedora-packager-setup.sh from mbonnet * Tue May 15 2007 Jesse Keating - 1.2.0-2 - overwrite and hardlink ssl cert for fedora packagers (dgilmore) * Tue May 15 2007 Mike Bonnet - 1.2.0-1 - change version numbering to a 3-token scheme - install the koji favicon kvm-24-1 -------- * Wed May 16 2007 Jeremy Katz - 24-1 - update to kvm-24 libiptcdata-1.0.2-1.fc7 ----------------------- * Tue May 15 2007 David Moore 1.0.2-1 - New upstream version libuser-0.56.2-1 ---------------- * Thu Apr 19 2007 Miloslav Trmac - 0.56.2-1 - New release with updated translations libxml2-2.6.28-2 ---------------- * Wed May 16 2007 Matthias Clasen 2.6.28-2 - Bump revision to fix N-V-R problem loudmouth-1.2.2-2.fc7 --------------------- * Tue May 15 2007 Brian Pepple - 1.2.2-2 - Drop BR on libtasn1-devel. * Mon May 14 2007 Brian Pepple - 1.2.2-1 - Update to 1.2.2. m17n-db-1.3.4-9.fc7 ------------------- * Wed May 16 2007 Jens Petersen - 1.3.4-9 - update ta-typewriter.mim with bug fixes (I Felix, #236169) * Thu Mar 15 2007 Mayank Jain 1.3.4-8 - Added key summary to kn-itrans,inscript keymaps - resolves 228806 * Thu Feb 15 2007 Mayank Jain - Added ZWNJ (U+200d) needed in kn-* keymaps, resolved - 221965 - Added kn-itrans-ZWNJ-221965.patch mbuffer-20070502-1.fc7 ---------------------- * Sat May 12 2007 Alexander Dalloz - 20070502-1 - Updated to latest version. moin-1.5.8-1.fc7 ---------------- * Wed May 16 2007 Matthias Saou 1.5.8-1 - Update to 1.5.8, which includes most previous security fixes. - Remove the (apparently) no longer needed dos2unix conversion for patch. - Use %{python_sitelib} macro. * Mon May 07 2007 Matthias Saou 1.5.7-2 - Include security fixes from the Debian package (Jonas Smedegaard). - FIX_use_ACL_in_include_directive (Alexander Schremmer). - fix_MonthCalendar_respect_ACLs (Thomas Waldmann). - FIX_XSS_in_AttachFile_do_parameter (Thomas Waldmann). - CVE-2007-0857. moodle-1.8-5.fc7 ---------------- * Tue May 15 2007 Jerry James - 1.8-5 - Fix language packs to not obsolete themselves. - Update language packs to the 15 May 2007 versions. ntfs-3g-2:1.516-1.fc7 --------------------- * Tue May 15 2007 Tom "spot" Callaway 2:1.516-1 - bump to 1.516 - fix bugzilla 232031 pan-1:0.129-1.fc7 ----------------- * Sat May 12 2007 Alexander Dalloz - 1:0.129-1 - Update to 0.129 * Sun May 06 2007 Alexander Dalloz - 1:0.128-1 - Update to 0.128 * Sat Apr 14 2007 Alexander Dalloz - 1:0.127-1 - Update to 0.127 perl-4:5.8.8-17.fc7 ------------------- * Fri May 04 2007 Robin Norwood - 4:5.8.8-17 - Includes patch from Ralf Corsepius to split out some more perl modules. - Further split out development related perl modules. - Remove Requires: perl-devel from perl - Move libperl.so -> perl-libs - Patch39 to disable test_hosts in Net::Config * Fri Mar 09 2007 Robin Norwood - 4:5.8.8-15 - Incorporate fixes from spot and others on fedora-perl-devel - The main perl package will temporarily Require perl-devel - move ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, Test::Harness into devel - also move perlcc, perlivp, h2xs, libnetcfg to devel * Tue Feb 27 2007 Robin Norwood - 4:5.8.8-14 - Add a description for most of the patches, to reflect Spot's work to report said patches upstream. perl-File-Copy-Recursive-0.33-2.fc7 ----------------------------------- * Mon May 14 2007 Ralf Cors??pius - 0.33-2 - BR: perl(Test::More). * Mon May 14 2007 Ralf Cors??pius - 0.33-1 - Upstream update. perl-File-Next-0.40-1.fc7 ------------------------- perl-Module-Refresh-0.13-1.fc7 ------------------------------ * Tue May 08 2007 Ralf Cors??pius < - 0.13-1 - Upstream update. perl-Text-Glob-0.08-1.fc7 ------------------------- * Tue May 08 2007 Ralf Cors??pius - 0.08-1 - Upstream update. perl-Want-0.14-1.fc7 -------------------- * Mon May 07 2007 Ralf Cors??pius - 0.14-1 - Upstream update. php-eaccelerator-5.2.2_0.9.5-2.fc7 ---------------------------------- * Wed May 16 2007 Matthias Saou 5.2.2_0.9.5-2 - Include ppc64 %ifarch, since it's now a Fedora target. - Include patch to fix trac bug #187. * Wed May 16 2007 Matthias Saou 5.2.2_0.9.5-1 - Rebuild against PHP 5.2.2. php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7 ---------------------------------------------------- * Sun May 06 2007 Christopher Stone 1.0.0-0.5.RC7 - Require new HTML_QuickForm_ElementGrid package * Mon Apr 02 2007 Christopher Stone 1.0.0-0.4.RC7 - Upstream sync * Sun Jan 14 2007 Christopher Stone 1.0.0-0.3.RC6 - Add new documentation, data and test files php-pear-MDB2-2.4.1-1.fc7 ------------------------- * Sat May 05 2007 Christopher Stone 2.4.1-1 - Upstream sync php-pear-MDB2-Driver-mysql-1.4.1-1.fc7 -------------------------------------- php-pear-Net-Socket-1.0.8-1.fc7 ------------------------------- * Tue May 08 2007 Remi Collet 1.0.8-1 - update to 1.0.8 php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc7 -------------------------------------------------------------- * Mon May 07 2007 Christopher Stone 0.1.2-1 - Upstream sync policycoreutils-2.0.16-1.fc7 ---------------------------- * Fri May 04 2007 Dan Walsh 2.0.16-1 - Updated version of policycoreutils * Merged support for modifying the prefix via semanage from Dan Walsh. - Fixed genhomedircon to find homedirs correctly. * Tue May 01 2007 Dan Walsh 2.0.15-1 - Updated version of policycoreutils * Merged po file updates from Dan Walsh. - Fix semanage to be able to modify prefix in user record * Mon Apr 30 2007 Dan Walsh 2.0.14-2 - Fix title on system-config-selinux powertop-1.2-1.fc7 ------------------ pygame-1.7.1-14.fc7 ------------------- * Tue May 15 2007 Christopher Stone 1.7.1-14 - Add one more bit to 64-bit patch redhat-artwork-7.0.0-8.fc7 -------------------------- * Tue May 15 2007 Than Ngo - 7.0.0-8 - add missing colorscheme for FedoraFlyingHigh selinux-policy-2.6.4-1.fc7 -------------------------- * Mon May 14 2007 Dan Walsh 2.6.4-1 - Update to latest from upstream * Fri May 04 2007 Dan Walsh 2.6.3-1 - Update to latest from upstream * Mon Apr 30 2007 Dan Walsh 2.6.2-1 - Update to latest from upstream sgml-common-0.6.3-20.fc7 ------------------------ * Tue May 15 2007 Tim Waugh 0.6.3-20 - Added dist tag. - Fixed summary. - Removed build dependency on autoconf/automake. squirrelmail-1.4.10a-1.fc7 -------------------------- * Fri May 11 2007 Martin Bacovsky - 1.4.10a-1 - upgrade to new upstream 1.4.10a - resolves: #239704: CVE-2007-1262 squirrelmail cross-site scripting flaw - resolves: #218297: CVE-2006-6142 Three XSS issues in SquirrelMail * Mon Apr 23 2007 Martin Bacovsky - 1.4.9a-2 - resolves: #237136:PHP Fatal error: Call to a member function getParameter() on a non-object in /usr/share/squirrelmail/functions/mime.php on line 317 - resolves: #229454: Errors in /var/log/httpd/error_log - resolves: #222879: squirrelmail ja_JP patches break build sylpheed-2.3.1-3.fc7 -------------------- * Sun May 13 2007 Michael Schwendt - 2.3.1-3 - Patch PGP/MIME signed message compose, so it doesn't strip off whitespace of the "-- " body signature delimiter. It's upstream preference that it still does that for ISO 2022 JP to be compatible with a few broken MUAs that have problems with QP encoding. - Remove .desktop categories "Application" and "X-Fedora". usermode-1.91.1-1 ----------------- * Thu Apr 19 2007 Miloslav Trmac - 1.91.1-1 - New release with updated translations wallpapoz-0.4-0.5.rc2.fc7 ------------------------- * Tue Apr 17 2007 Mamoru Tasaka - 0.4-0.5.rc2 - 0.4 rc2 xdg-user-dirs-0.8-1.fc7 ----------------------- * Wed May 16 2007 - 0.8-1 - Update to 0.8, (only) fixing bug that always recreated deleted directories (#240139) * Wed Apr 11 2007 Alexander Larsson - 0.6-1 - Update to 0.6 (minor fixes) * Mon Mar 26 2007 Alexander Larsson - 0.5-1 - update to 0.5 (more translations) yum-metadata-parser-1.1.0-2.fc7 ------------------------------- * Tue May 15 2007 Jeremy Katz - 1.1.0-2 - export dbversion so that things like createrepo can discover it (#239938) yum-utils-1.1.4-1.fc7 --------------------- From miles.lane at gmail.com Thu May 17 07:26:20 2007 From: miles.lane at gmail.com (Miles Lane) Date: Thu, 17 May 2007 00:26:20 -0700 Subject: rawhide report: changes In-Reply-To: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> Message-ID: Why is it that although I have fedora-development.repo set with baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ and I can see http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/control-center-2.18.0-16.fc7.i386.rpm and I have run "yum clean all", when I run "yum update" the updated control-center is not found. "yum list control-center" reports: control-center.i386 1:2.18.0-14.fc7 installed Thanks, Miles From petersen at redhat.com Thu May 17 08:33:01 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 17 May 2007 18:33:01 +1000 Subject: better package review list bugzilla queries Message-ID: <464C133D.7010403@redhat.com> FYI I improved (hopefully!) the bugzilla links at the bottom of http://fedoraproject.org/wiki/PackageReviewProcess to: New review bugs: https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Extras&component=Package+Review&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review Current under-review bugs: https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&component=Package+Review&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=fedora-review%3F Packages reviewed but not closed: https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&component=Package+Review&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=fedora-review%2B Before this there were bugs in edge or corner corner states not showing up in the lists. There may still be room for improvement. Jens ps Hmm, maybe modified should be removed from "reviewed but not closed"? From rodd at clarkson.id.au Thu May 17 08:33:20 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 17 May 2007 18:33:20 +1000 Subject: rawhide report: changes In-Reply-To: References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> Message-ID: <1179390800.3544.0.camel@localhost.localdomain> On Thu, 2007-05-17 at 00:26 -0700, Miles Lane wrote: > Why is it that although I have fedora-development.repo set with > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > and I can see > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/control-center-2.18.0-16.fc7.i386.rpm > and I have run "yum clean all", when I run "yum update" the updated > control-center is not found. "yum list control-center" reports: > control-center.i386 1:2.18.0-14.fc7 installed Along similar lines ... ? [rodd at localhost ~]$ sudo yum clean metadata Loading "installonlyn" plugin 17 metadata files removed [rodd at localhost ~]$ sudo yum update Loading "installonlyn" plugin Setting up Update Process development 100% |=========================| 1.1 kB 00:00 primary.xml.gz 100% |=========================| 2.6 MB 00:55 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. [rodd at localhost ~]$ sudo yum update Password: Loading "installonlyn" plugin Setting up Update Process primary.xml.gz 100% |=========================| 2.6 MB 00:51 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. [rodd at localhost ~]$ R. -- "It's a fine line between denial and faith. It's much better on my side" From nicolas.mailhot at laposte.net Thu May 17 08:35:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 10:35:35 +0200 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179360444.10909.14.camel@rivendell> References: <1179335073.3513.10.camel@sb-home> <1179360257.2967.23.camel@localhost.localdomain> <1179360444.10909.14.camel@rivendell> Message-ID: <1179390935.30352.16.camel@rousalka.dyndns.org> Le mercredi 16 mai 2007 ? 20:07 -0400, seth vidal a ?crit : > debuginfo-install kernel > and see if it gets it right :) I suspect it won't as it's confused by packages like glibc where the root to debuginfo name mapping is not conventional (and IIRC kernel was in the same case) Not too difficult to fix manually, and an order of magnitude less annoying than the previous situation. Thank you for your work! -- 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 kushaldas at gmail.com Thu May 17 08:38:33 2007 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 17 May 2007 14:08:33 +0530 Subject: Different python versions in a Fedora system Message-ID: <200705171408.34149.kushaldas@gmail.com> Hi, Is there any way to keep different Python versions in a Fedora system ? There will some installation (around 292) state wise in kiosks. But the only reason the team is refusing Fedora is its lack of support of keeping & running different versions of Python . So, is there any work around ? Kushal -- Fedora Ambassador, India http://kushaldas.in From mmcgrath at redhat.com Thu May 17 08:40:56 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 May 2007 03:40:56 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464BE56D.604@redhat.com> References: <464B3EDB.2070709@redhat.com> <464BE56D.604@redhat.com> Message-ID: <464C1518.5080706@redhat.com> Mike McGrath wrote: > Mike McGrath wrote: >> There will be an outage starting at 2007-05-17 04:00 [UTC], which >> will last >> approximately 1 hour. To convert UTC to your local time, use: >> http://www.timeanddate.com/worldclock/converter.html > > An outage is as an outage does. This one is taking longer then we had > planned for a few reasons. Stop by #fedora-admin to check on the > status but we're going to see this one through till its done. I'll > send a notification when that is. Outage Over. There were multiple changes with this outage so if anything seems out of place please contact us and let us know. Total outage time: roughly 4 hours. -Mike From nicolas.mailhot at laposte.net Thu May 17 08:42:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 10:42:09 +0200 Subject: rawhide report: changes In-Reply-To: <1179390800.3544.0.camel@localhost.localdomain> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> Message-ID: <1179391329.30352.22.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 18:33 +1000, Rodd Clarkson a ?crit : > Along similar lines ... ? > > [rodd at localhost ~]$ sudo yum clean metadata > Loading "installonlyn" plugin > 17 metadata files removed > [rodd at localhost ~]$ sudo yum update > Loading "installonlyn" plugin > Setting up Update Process > development 100% |=========================| 1.1 kB 00:00 > primary.xml.gz 100% |=========================| 2.6 MB 00:55 > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum If you're behind a (transparent or not) proxy you have to manually forbid caching of repodata directories, else you'll periodically get those messages. Yum metadata is not proxy-friendly (ie if you're behind a corp proxy you're dead) Though for http mirrors we control the no-proxy rules should be done at the http server level, and I hope yum is fixed someday -- 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 laroche at redhat.com Thu May 17 08:49:31 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 17 May 2007 10:49:31 +0200 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <200705162059.02949.dennis@ausil.us> References: <464B3607.2070602@math.unl.edu> <464B619C.2030605@redhat.com> <200705162059.02949.dennis@ausil.us> Message-ID: <20070517084931.GA5185@dudweiler.stuttgart.redhat.com> On Wed, May 16, 2007 at 08:58:58PM -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 16 May 2007, Christopher Aillon wrote: > > Rex Dieter wrote: > > > (*) admittedly than wasn't thrilled about such a non-trivial change going > > > in at such a late-date, starting at: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239701#c35 > > > > And you went ahead and did it anyway? "I'll do it anyway" flippancy > > especially from long time contributors is not going to encourage ex-Core > > package maintainers to want to add others to the ACL/co-maintainers > > lists for the packages they own. Than should retain a certain level of > > respect and I support his decision in this case. > > The way Than has not participated makes him more a co-maintainer than > maintainer. in all honesty he is lucky to have any access to the kde > packages at all right now. We had to drag him kicking and screaming to work > with the community. Right now i'm willing to have him removed from all > Fedora KDE access. Hello Dennis, Than Ngo has maintained the KDE packages for many years and they show a real good stability for all our releases. Than Ngo is a very well respected person to work on the packages. The decision was to keep the core packages with Than Ngo and open up more development via adding more KDE packages to Fedora. Then the next bigger step is to work on KDE4 where a bigger development step happens. Than Ngo is very active and he is very fast to respond to integrating patches etc. Also he knows devel cycles very well where we are right now frozen for F7 and look at F7-updates. Than Ngo is the maintainer for the core kde packages. regards, Florian La Roche From than at than.com Thu May 17 08:56:28 2007 From: than at than.com (Than Ngo) Date: Thu, 17 May 2007 10:56:28 +0200 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <464B3607.2070602@math.unl.edu> References: <464B3607.2070602@math.unl.edu> Message-ID: <200705171056.29062.than@than.com> Am Mittwoch, 16. Mai 2007 schrieb Rex Dieter: > Than Ngo (than) wrote: > > Author: than > > Update of /cvs/extras/rpms/kdelibs/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29578 > > Modified Files: > > kdelibs.spec > > > > Log Message: > > ... > > > - disable kde_settings > > wtf? I just went through the work enabling kde-settings, why are you > disabling it? > > -- Rex i have disabled it because it caused the package conflict. We still don't have the FC7 CVS branch ATM and we are still using devel CVS branch to commit only bugfixes (not experimental or features) there, therefore you should be carefull and does not commit the experimental or features changes in devel branch CVS. Could you please discuss such changes with me before you started working on it and commit the change in CVS. Thanks Than From miles.lane at gmail.com Thu May 17 09:04:27 2007 From: miles.lane at gmail.com (Miles Lane) Date: Thu, 17 May 2007 02:04:27 -0700 Subject: rawhide report: changes In-Reply-To: <1179391329.30352.22.camel@rousalka.dyndns.org> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> Message-ID: On 5/17/07, Nicolas Mailhot wrote: > Le jeudi 17 mai 2007 ? 18:33 +1000, Rodd Clarkson a ?crit : > > > Along similar lines ... ? > > > > [rodd at localhost ~]$ sudo yum clean metadata > > Loading "installonlyn" plugin > > 17 metadata files removed > > [rodd at localhost ~]$ sudo yum update > > Loading "installonlyn" plugin > > Setting up Update Process > > development 100% |=========================| 1.1 kB 00:00 > > primary.xml.gz 100% |=========================| 2.6 MB 00:55 > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum > > If you're behind a (transparent or not) proxy you have to manually > forbid caching of repodata directories, else you'll periodically get > those messages. Yum metadata is not proxy-friendly (ie if you're behind > a corp proxy you're dead) > > Though for http mirrors we control the no-proxy rules should be done at > the http server level, and I hope yum is fixed someday I added "http_caching=packages" to yum/conf and ran rm -fr /var/cache/yum/* I still get: development 100% |=========================| 1.1 kB 00:00 primary.xml.gz 100% |=========================| 2.6 MB 00:06 http://download.fedoraproject.org/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:18 developmen: ################################################## 7296/7296 No Packages marked for Update/Obsoletion My fedora-development.repo contains: [development] name=Fedora Core - Development baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ # mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide.us.west # mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide enabled=1 failovermethod=priority gpgcheck=0 From dev at nigelj.com Thu May 17 09:11:40 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 21:11:40 +1200 Subject: rawhide report: changes In-Reply-To: References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> Message-ID: <464C1C4C.6050206@nigelj.com> Miles Lane wrote: > On 5/17/07, Nicolas Mailhot wrote: >> Le jeudi 17 mai 2007 ? 18:33 +1000, Rodd Clarkson a ?crit : >> >> > Along similar lines ... ? >> > >> > [rodd at localhost ~]$ sudo yum clean metadata >> > Loading "installonlyn" plugin >> > 17 metadata files removed >> > [rodd at localhost ~]$ sudo yum update >> > Loading "installonlyn" plugin >> > Setting up Update Process >> > development 100% |=========================| 1.1 kB >> 00:00 >> > primary.xml.gz 100% |=========================| 2.6 MB >> 00:55 >> > >> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: >> [Errno -1] Metadata file does not match checksum >> >> If you're behind a (transparent or not) proxy you have to manually >> forbid caching of repodata directories, else you'll periodically get >> those messages. Yum metadata is not proxy-friendly (ie if you're behind >> a corp proxy you're dead) >> >> Though for http mirrors we control the no-proxy rules should be done at >> the http server level, and I hope yum is fixed someday > > I added "http_caching=packages" to yum/conf and ran > rm -fr /var/cache/yum/* > I still get: > development 100% |=========================| 1.1 kB 00:00 > primary.xml.gz 100% |=========================| 2.6 MB 00:06 > http://download.fedoraproject.org/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: > > [Errno -1] Metadata file does not match checksum > Trying other mirror. > primary.xml.gz 100% |=========================| 2.6 MB 00:18 > developmen: ################################################## 7296/7296 > No Packages marked for Update/Obsoletion > > My fedora-development.repo contains: > [development] > name=Fedora Core - Development > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > > # > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide.us.west > > # mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > enabled=1 > failovermethod=priority > gpgcheck=0 > It's got nothing to do with proxies... [njones at ip-96 ~]$ wget http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/repodata/primary.xml.gz --20:59:10-- http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/repodata/primary.xml.gz Resolving download.fedora.redhat.com... 209.132.176.221, 209.132.176.20, 209.132.176.220, ... Connecting to download.fedora.redhat.com|209.132.176.221|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2075290 (2.0M) [application/x-gzip] Saving to: `primary.xml.gz' 100%[=======================================>] 2,075,290 39.2K/s in 52s 21:00:03 (39.0 KB/s) - `primary.xml.gz' saved [2075290/2075290] [njones at ip-96 ~]$ sha1sum primary.xml.gz 09f7c50c2bbe57f4157e5e92e56752f6f86cb916 primary.xml.gz http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/repodata/repomd.xml reports 1fe98d83f6061a33cdfdd9a02856c5523561518a And I can guarantee it is not cached because I only have i386's and x86_64's here and I noticed the issue on another ppc64 machine on a remote network. I think someone/something messed up? N.J. From fedora at leemhuis.info Thu May 17 09:15:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 11:15:13 +0200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179326006.14246.44.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> Message-ID: <464C1D21.3000001@leemhuis.info> On 16.05.2007 16:33, Richard Hughes wrote: > New in Fedora 7 we have the new pm-utils and hal-info dmi based matching > of suspend quirks. We are doing finer matching to the laptop make and > model, to make suspend (and more importantly resume) work for more > people. > > What this means: > > * Some machines that suspended in FC6 might not work in F7 > * Lots of machines that did not suspend in FC6 might work in F7 > > So, if you have to edit a file or add stuff to grub to get suspend > working in F7, that's a bug. This stuff should just work on the majority > or laptops. > > To help, and to try and make clearer all this new stuff, I've written a > few pages here: > http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html Some comments: The page http://people.freedesktop.org/~hughsient/temp/quirk/quirk-debug.html only asks "Are you using the proprietary NVIDIA driver?" -- what about the proprietary ATI driver? You're not asking if people use a plain vga consile (vga=0 or vga=normal on the kernel command line -- default in Fedora) or a framebuffer console (vga=792 or something like that -- default in Ubuntu, OpenSuse, no idea about Mandriva). Further: Both details mentioned above according to my tests on several laptops heavily influence if laptops suspends or what quicks they need. So those informations thus IMHO should be tracked in the fdi files. Otherwise we soon might end in situations like "my laptops suspends fine under Fedora with the fdi file, but does not under OpenSuse (or vice versa). CU thl From hughsient at gmail.com Thu May 17 09:34:31 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 May 2007 10:34:31 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <464C1D21.3000001@leemhuis.info> References: <1179326006.14246.44.camel@localhost.localdomain> <464C1D21.3000001@leemhuis.info> Message-ID: <1179394471.16432.19.camel@localhost.localdomain> On Thu, 2007-05-17 at 11:15 +0200, Thorsten Leemhuis wrote: > > On 16.05.2007 16:33, Richard Hughes wrote: > > New in Fedora 7 we have the new pm-utils and hal-info dmi based matching > > of suspend quirks. We are doing finer matching to the laptop make and > > model, to make suspend (and more importantly resume) work for more > > people. > > > > What this means: > > > > * Some machines that suspended in FC6 might not work in F7 > > * Lots of machines that did not suspend in FC6 might work in F7 > > > > So, if you have to edit a file or add stuff to grub to get suspend > > working in F7, that's a bug. This stuff should just work on the majority > > or laptops. > > > > To help, and to try and make clearer all this new stuff, I've written a > > few pages here: > > http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html > > Some comments: > > The page > http://people.freedesktop.org/~hughsient/temp/quirk/quirk-debug.html > only asks "Are you using the proprietary NVIDIA driver?" -- what about > the proprietary ATI driver? Good point, I'll add that too. What's the name of the proprietary driver in xorg.conf? > You're not asking if people use a plain vga consile (vga=0 or vga=normal > on the kernel command line -- default in Fedora) or a framebuffer > console (vga=792 or something like that -- default in Ubuntu, OpenSuse, > no idea about Mandriva). Sure, I need to debug this myself. I'll add this to the document. > Further: Both details mentioned above according to my tests on several > laptops heavily influence if laptops suspends or what quicks they need. > So those informations thus IMHO should be tracked in the fdi files. > Otherwise we soon might end in situations like "my laptops suspends fine > under Fedora with the fdi file, but does not under OpenSuse (or vice versa). Sure. Which would be bad. Thanks for your mail. Richard. From dev at nigelj.com Thu May 17 09:38:28 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 21:38:28 +1200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179394471.16432.19.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <464C1D21.3000001@leemhuis.info> <1179394471.16432.19.camel@localhost.localdomain> Message-ID: <464C2294.8060601@nigelj.com> Richard Hughes wrote: > On Thu, 2007-05-17 at 11:15 +0200, Thorsten Leemhuis wrote: >> On 16.05.2007 16:33, Richard Hughes wrote: >>> New in Fedora 7 we have the new pm-utils and hal-info dmi based matching >>> of suspend quirks. We are doing finer matching to the laptop make and >>> model, to make suspend (and more importantly resume) work for more >>> people. >>> >>> What this means: >>> >>> * Some machines that suspended in FC6 might not work in F7 >>> * Lots of machines that did not suspend in FC6 might work in F7 >>> >>> So, if you have to edit a file or add stuff to grub to get suspend >>> working in F7, that's a bug. This stuff should just work on the majority >>> or laptops. >>> >>> To help, and to try and make clearer all this new stuff, I've written a >>> few pages here: >>> http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html >> Some comments: >> >> The page >> http://people.freedesktop.org/~hughsient/temp/quirk/quirk-debug.html >> only asks "Are you using the proprietary NVIDIA driver?" -- what about >> the proprietary ATI driver? > > Good point, I'll add that too. What's the name of the proprietary driver > in xorg.conf? Section "Device" Identifier "aticonfig-Device[0]" Driver "fglrx" Option "UseInternalAGPGART" "no" Option "VideoOverlay" "on" EndSection Hope that helps... N.J. From hughsient at gmail.com Thu May 17 09:47:29 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 May 2007 10:47:29 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <464C2294.8060601@nigelj.com> References: <1179326006.14246.44.camel@localhost.localdomain> <464C1D21.3000001@leemhuis.info> <1179394471.16432.19.camel@localhost.localdomain> <464C2294.8060601@nigelj.com> Message-ID: <1179395249.16432.28.camel@localhost.localdomain> On Thu, 2007-05-17 at 21:38 +1200, Nigel Jones wrote: > Driver "fglrx" > Hope that helps... Yup, thanks. Richard From lsof at nodata.co.uk Thu May 17 10:49:45 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 17 May 2007 12:49:45 +0200 Subject: kernel debuginfo packages for rawhide In-Reply-To: <1179360257.2967.23.camel@localhost.localdomain> References: <1179335073.3513.10.camel@sb-home> <1179360257.2967.23.camel@localhost.localdomain> Message-ID: <1179398985.3612.2.camel@sb-home> Am Donnerstag, den 17.05.2007, 10:04 +1000 schrieb Rodd Clarkson: > On Wed, 2007-05-16 at 19:04 +0200, nodata wrote: > > Hi. > > Are kernel-debuginfo packages available for rawhide? > > > > I can't find them with yum, or on the ftp server. > > debuginfo has it's own repo that needs to be enabled. > > either use --enablerepo or do it manually in /etc/yum.repo.d > > > R. The problem was they we're on the ftp server. From hughsient at gmail.com Thu May 17 10:53:10 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 May 2007 11:53:10 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> Message-ID: <1179399190.16432.64.camel@localhost.localdomain> On Wed, 2007-05-16 at 11:01 -0700, Miles Lane wrote: > > So, as you can see, my system information should match the existing > rule, but when I try to suspend, my video never comes back after > resume. Evidently, the rule isn't being triggered. I think I've spotted a bug where there is some sort of race between the dmi prober and the fdi cache reading. I'll debug it some more later today. > One more observation. It would be very useful for you to include that > command I used ("lshal | grep system.hardware.product") in your online > documentation. Sure. I intend on doing a "explaining fdi matching" tutorial to explain to mere mortals how to make the rules :-) Richard. From jwboyer at jdub.homelinux.org Thu May 17 10:52:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 05:52:24 -0500 Subject: rpms/kdelibs/devel kdelibs.spec In-Reply-To: <20070517084931.GA5185@dudweiler.stuttgart.redhat.com> References: <464B3607.2070602@math.unl.edu> <464B619C.2030605@redhat.com> <200705162059.02949.dennis@ausil.us> <20070517084931.GA5185@dudweiler.stuttgart.redhat.com> Message-ID: <1179399144.8746.30.camel@vader.jdub.homelinux.org> On Thu, 2007-05-17 at 10:49 +0200, Florian La Roche wrote:. > > Than Ngo is the maintainer for the core kde packages. And Rex is the co-maintainer. josh From mcepl at redhat.com Thu May 17 11:21:42 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 17 May 2007 13:21:42 +0200 Subject: Explaining the new suspend quirks functionality in F7 References: <1179326006.14246.44.camel@localhost.localdomain> <464C1D21.3000001@leemhuis.info> <1179394471.16432.19.camel@localhost.localdomain> Message-ID: On 2007-05-17, 09:34 GMT, Richard Hughes wrote: > Good point, I'll add that too. What's the name of the > proprietary driver > in xorg.conf? fglrx From goeran at uddeborg.se Thu May 17 11:44:02 2007 From: goeran at uddeborg.se (=?iso-8859-1?Q?G=F6ran?= Uddeborg) Date: Thu, 17 May 2007 13:44:02 +0200 Subject: The scroll bar in emacs 22 Message-ID: <17996.16386.783263.165528@mimmi.uddeborg.se> Late in the cycle I start to notice the details: The scroll bar in emacs 22, with GTK, is a bit strange. It acts as if there is an empty page after the actual contents of a buffer. Since it is possible to place the last line of the buffer at the top of the window, there is in some technical sense such a page in the DISPLAY of the buffer. But I find this non-intuitive. It is more natural if the scroll bar reflects the part of the buffer CONTENT that is shown. It was like that previously, in the non-GTK emacs 21. Does anybody know if this is some kind of configuration error? Or something I should report upstreams? Or maybe an intentional, eh, quirk, of GTK emacs? From jonathan.underwood at gmail.com Thu May 17 11:57:57 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 17 May 2007 12:57:57 +0100 Subject: The scroll bar in emacs 22 In-Reply-To: <17996.16386.783263.165528@mimmi.uddeborg.se> References: <17996.16386.783263.165528@mimmi.uddeborg.se> Message-ID: <645d17210705170457g2484dca5v5cfa624b0681e908@mail.gmail.com> On 17/05/07, G?ran Uddeborg wrote: > Late in the cycle I start to notice the details: > > The scroll bar in emacs 22, with GTK, is a bit strange. It acts as if > there is an empty page after the actual contents of a buffer. Since > it is possible to place the last line of the buffer at the top of the > window, there is in some technical sense such a page in the DISPLAY of > the buffer. But I find this non-intuitive. It is more natural if the > scroll bar reflects the part of the buffer CONTENT that is shown. It > was like that previously, in the non-GTK emacs 21. > > Does anybody know if this is some kind of configuration error? Or > something I should report upstreams? Or maybe an intentional, eh, > quirk, of GTK emacs? I see the same thing. Actually, it's more tricky than that - you get a different result depending upon whether you use the mousewheel to scroll, or the scroll bar. With the mouse wheel you get the behaviour that I think you desire. This is inconsistent though - I suggest reporting it to emacs-devel mailing list. From katzj at redhat.com Thu May 17 12:00:11 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 17 May 2007 08:00:11 -0400 Subject: rawhide report: changes In-Reply-To: <1179390800.3544.0.camel@localhost.localdomain> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> Message-ID: <1179403211.7682.18.camel@aglarond.local> On Thu, 2007-05-17 at 18:33 +1000, Rodd Clarkson wrote: > Along similar lines ... ? [snip] > [rodd at localhost ~]$ sudo yum update > Loading "installonlyn" plugin > Setting up Update Process > development 100% |=========================| 1.1 kB 00:00 > primary.xml.gz 100% |=========================| 2.6 MB 00:55 > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. Something definitely isn't matching up with the tree (the metadata is inconsistent), but I'm not quite sure why. Looking now, but might need someone else to wake up to get to the bottom of it and get a fix Jeremy From dev at nigelj.com Thu May 17 12:15:43 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 18 May 2007 00:15:43 +1200 Subject: rawhide report: changes In-Reply-To: <1179403211.7682.18.camel@aglarond.local> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179403211.7682.18.camel@aglarond.local> Message-ID: <464C476F.9000309@nigelj.com> Jeremy Katz wrote: > On Thu, 2007-05-17 at 18:33 +1000, Rodd Clarkson wrote: >> Along similar lines ... ? > [snip] >> [rodd at localhost ~]$ sudo yum update >> Loading "installonlyn" plugin >> Setting up Update Process >> development 100% |=========================| 1.1 kB 00:00 >> primary.xml.gz 100% |=========================| 2.6 MB 00:55 >> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum >> Trying other mirror. >> Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. > > Something definitely isn't matching up with the tree (the metadata is > inconsistent), but I'm not quite sure why. Looking now, but might need > someone else to wake up to get to the bottom of it and get a fix Repodata for http://mirrors.usc.edu/pub/linux/distributions/fedora/core/development/ppc64/os looks correct though. I'm not sure, so I'm leaving it to the experts. N.J. From jwboyer at jdub.homelinux.org Thu May 17 12:35:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 07:35:20 -0500 Subject: rawhide report: changes In-Reply-To: <464C476F.9000309@nigelj.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179403211.7682.18.camel@aglarond.local> <464C476F.9000309@nigelj.com> Message-ID: <1179405320.8746.49.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 00:15 +1200, Nigel Jones wrote: > Jeremy Katz wrote: > > On Thu, 2007-05-17 at 18:33 +1000, Rodd Clarkson wrote: > >> Along similar lines ... ? > > [snip] > >> [rodd at localhost ~]$ sudo yum update > >> Loading "installonlyn" plugin > >> Setting up Update Process > >> development 100% |=========================| 1.1 kB 00:00 > >> primary.xml.gz 100% |=========================| 2.6 MB 00:55 > >> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum > >> Trying other mirror. > >> Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. > > > > Something definitely isn't matching up with the tree (the metadata is > > inconsistent), but I'm not quite sure why. Looking now, but might need > > someone else to wake up to get to the bottom of it and get a fix > Repodata for > http://mirrors.usc.edu/pub/linux/distributions/fedora/core/development/ppc64/os > looks correct though. I think that's because it's stale now. Doesn't seem to contain the latest rawhide push yet, so it probably hasn't synced. josh From opensource at till.name Thu May 17 13:05:34 2007 From: opensource at till.name (Till Maas) Date: Thu, 17 May 2007 15:05:34 +0200 Subject: rawhide report: changes In-Reply-To: <1179403211.7682.18.camel@aglarond.local> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179403211.7682.18.camel@aglarond.local> Message-ID: <200705171505.38861.opensource@till.name> On Do Mai 17 2007, Jeremy Katz wrote: > On Thu, 2007-05-17 at 18:33 +1000, Rodd Clarkson wrote: > >os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match > > checksum Trying other mirror. > > Error: failure: repodata/primary.xml.gz from development: [Errno 256] No > > more mirrors to try. > > Something definitely isn't matching up with the tree (the metadata is > inconsistent), but I'm not quite sure why. Looking now, but might need > someone else to wake up to get to the bottom of it and get a fix Whenever I get this "Metadata file does not math checksum" error, "yum clean metadata" helps, maybe it helps you, too. Regards, Till From sean.stangl at gmail.com Thu May 17 12:39:01 2007 From: sean.stangl at gmail.com (Sean Stangl) Date: Thu, 17 May 2007 08:39:01 -0400 Subject: Different python versions in a Fedora system In-Reply-To: <200705171408.34149.kushaldas@gmail.com> References: <200705171408.34149.kushaldas@gmail.com> Message-ID: <1179405541.9521.13.camel@localhost.localdomain> On Thu, 2007-05-17 at 14:08 +0530, Kushal Das wrote: > Hi, > Is there any way to keep different Python versions in a Fedora system ? > There will some installation (around 292) state wise in kiosks. But the only > reason the team is refusing Fedora is its lack of support of keeping & > running different versions of Python . So, is there any work around ? Python 2.4 is provided in FC6; Python 2.5 will be installed by default on F7. Upstream does not maintain older versions in any way, not even in terms of vulnerability patching, and therefore neither does Fedora. We previously discussed the creation of a compat-python24 or the equivalent on this list: if curious it might be telling to look into it. That being said, since neither Fedora nor Python are providing "support" for Python, and moreover, since those old versions will never change and will never require update, what's there to stop you from explicitly installing the older version from source in a directory such as /opt? The entire process is exceedingly trivial, and a simple script (called, for example, python-2.4) could be created that simply changes the library path and runs the appropriate version. -sstangl From ndbecker2 at gmail.com Thu May 17 13:12:58 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 17 May 2007 09:12:58 -0400 Subject: Conflict in /usr/lib/kde3/plugins/styles/keramik.so: Message-ID: I ran this on current fc7test with all updates, on x86_64: kdiff3 idma-cdma idma-cdma.nbecker4 Conflict in /usr/lib/kde3/plugins/styles/keramik.so: Plugin uses incompatible Qt library! expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-4.* full-config". What does this mean? BTW, I'm the kdiff3 maintainer, so maybe I need to do something? From rc040203 at freenet.de Thu May 17 13:20:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 15:20:42 +0200 Subject: rpms/drgeo/EL-4 drgeo.spec,1.3,1.4 In-Reply-To: <200705170955.l4H9tmlQ003031@cvs-int.fedora.redhat.com> References: <200705170955.l4H9tmlQ003031@cvs-int.fedora.redhat.com> Message-ID: <1179408042.4735.830.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 05:55 -0400, Eric Tanguy wrote: > Author: tanguy > > Update of /cvs/extras/rpms/drgeo/EL-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2999 > > Modified Files: > drgeo.spec > Log Message: > > > > Index: drgeo.spec > =================================================================== > RCS file: /cvs/extras/rpms/drgeo/EL-4/drgeo.spec,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- drgeo.spec 3 Nov 2005 18:19:11 -0000 1.3 > +++ drgeo.spec 17 May 2007 09:55:13 -0000 1.4 > @@ -1,7 +1,7 @@ > Summary: Interactive educational geometry software > Name: drgeo > Version: 1.1.0 > -Release: 4%{?dist} > +Release: 5%{?dist} > License: GPL > Group: Applications/Engineering > URL: http://www.ofset.org/drgeo > @@ -10,7 +10,7 @@ > Patch0: drgeo-1.1.0-htmlview.patch > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > -BuildRequires: flex, bison, gmp-devel >= 2.0.2, desktop-file-utils > +BuildRequires: flex, bison, gmp-devel >= 2.0.2, desktop-file-utils, perl-XML-Parser Please use perl(XML::Parser) instead of perl-XML-Parser Ralf From kevin.kofler at chello.at Thu May 17 13:24:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 17 May 2007 13:24:38 +0000 (UTC) Subject: Conflict in /usr/lib/kde3/plugins/styles/keramik.so: References: Message-ID: Neal Becker gmail.com> writes: > kdiff3 idma-cdma idma-cdma.nbecker4 > Conflict in /usr/lib/kde3/plugins/styles/keramik.so: > Plugin uses incompatible Qt library! > expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-4.* full-config". > > What does this mean? This sounds like a multilib problem, it's trying to load a 32-bit plugin into a 64-bit application, which obviously won't work. > BTW, I'm the kdiff3 maintainer, so maybe I need to do something? I think this sounds more like a KDE or Qt problem. But why doesn't this affect other KDE apps too then? Maybe Than Ngo or Rex Dieter have an idea what's going on there. Kevin Kofler From rdieter at math.unl.edu Thu May 17 13:49:40 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 May 2007 08:49:40 -0500 Subject: Conflict in /usr/lib/kde3/plugins/styles/keramik.so: References: Message-ID: Neal Becker wrote: > I ran this on current fc7test with all updates, on x86_64: > > kdiff3 idma-cdma idma-cdma.nbecker4 > Conflict in /usr/lib/kde3/plugins/styles/keramik.so: > Plugin uses incompatible Qt library! > expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux > g++-4.* full-config". > > What does this mean? > > BTW, I'm the kdiff3 maintainer, so maybe I need to do something? Funky wierd. it's 99% *not* kdiff3 at play here, it appears to be a multilib thing. I'd assume other kde apps would give the same warning/error, do they? If so, bugzilla it against kdelibs. -- Rex From ndbecker2 at gmail.com Thu May 17 14:10:52 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 17 May 2007 10:10:52 -0400 Subject: Conflict in /usr/lib/kde3/plugins/styles/keramik.so: References: Message-ID: Rex Dieter wrote: > Neal Becker wrote: > >> I ran this on current fc7test with all updates, on x86_64: >> >> kdiff3 idma-cdma idma-cdma.nbecker4 >> Conflict in /usr/lib/kde3/plugins/styles/keramik.so: >> Plugin uses incompatible Qt library! >> expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux >> g++-4.* full-config". >> >> What does this mean? >> >> BTW, I'm the kdiff3 maintainer, so maybe I need to do something? > > Funky wierd. > > it's 99% *not* kdiff3 at play here, it appears to be a multilib thing. > > I'd assume other kde apps would give the same warning/error, do they? If > so, bugzilla it against kdelibs. > > -- Rex > This is interesting. I have a file: ~/.qt/qt_plugins_3.3rc: With entries like: [usr] lib/kde3/plugins/styles/highcolor.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-04-05T10:57:13^e lib/kde3/plugins/styles/highcontrast.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-04-05T10:57:13^e lib/kde3/plugins/styles/keramik.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-05-15T16:25:23^e lib/kde3/plugins/styles/kthemestyle.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-04-05T10:57:13^e lib/kde3/plugins/styles/light.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-04-05T10:57:13^e lib/kde3/plugins/styles/plastik.so=30308^e3^ei686 Linux g++-4.* full-config^e2007-04-05T10:57:13^e lib/kde3/plugins/styles/scheck.so=30307^e3^ei686 Linux g++-4.* full-config^e2007-02-07T18:29:21^e I have no idea what this is or how it got there (but it seems to have been written this morning). Hmm. I think I know. I'm running this on an x86_64, but it's running through 2xterminal (NX), which is i386 (they don't have an x86_64 native version). One more thing, I can't reproduce it (but I haven't changed anything AFAIK). From Matt_Domsch at dell.com Thu May 17 14:27:53 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 17 May 2007 09:27:53 -0500 Subject: rawhide report: changes In-Reply-To: References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> Message-ID: <20070517142752.GA25891@lists.us.dell.com> On Thu, May 17, 2007 at 02:04:27AM -0700, Miles Lane wrote: > My fedora-development.repo contains: > [development] > name=Fedora Core - Development > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > # > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide.us.west For the record, I recommend people use: mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch as the content at fedora.redhat.com/download/mirrors is quite stale and no longer updated. The content at mirrors.fedoraproject.org is generated several times a day by crawling all the mirrors, and uses GeoIP to return you a country-local up-to-date mirror if possible. Thanks, Matt Fedora Mirror Wrangler -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jspaleta at gmail.com Thu May 17 15:33:26 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 May 2007 07:33:26 -0800 Subject: Different python versions in a Fedora system In-Reply-To: <200705171408.34149.kushaldas@gmail.com> References: <200705171408.34149.kushaldas@gmail.com> Message-ID: <604aa7910705170833u37dea059k97059cc105b37fff@mail.gmail.com> On 5/17/07, Kushal Das wrote: > Hi, > Is there any way to keep different Python versions in a Fedora system ? > There will some installation (around 292) state wise in kiosks. But the only > reason the team is refusing Fedora is its lack of support of keeping & > running different versions of Python . So, is there any work around ? Can you give me a specific reason why you need multiple versions of python installed? -jef From mschwendt.tmp0701.nospam at arcor.de Thu May 17 15:39:04 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 17 May 2007 17:39:04 +0200 Subject: rawhide report: changes In-Reply-To: <200705171505.38861.opensource@till.name> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179403211.7682.18.camel@aglarond.local> <200705171505.38861.opensource@till.name> Message-ID: <20070517173904.54d07d9e.mschwendt.tmp0701.nospam@arcor.de> On Thu, 17 May 2007 15:05:34 +0200, Till Maas wrote: > On Do Mai 17 2007, Jeremy Katz wrote: > > On Thu, 2007-05-17 at 18:33 +1000, Rodd Clarkson wrote: > > > >os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match > > > checksum Trying other mirror. > > > Error: failure: repodata/primary.xml.gz from development: [Errno 256] No > > > more mirrors to try. > > > > Something definitely isn't matching up with the tree (the metadata is > > inconsistent), but I'm not quite sure why. Looking now, but might need > > someone else to wake up to get to the bottom of it and get a fix > > Whenever I get this "Metadata file does not math checksum" error, "yum clean > metadata" helps, maybe it helps you, too. Consider yourself lucky. I've seen this error very often over the past weeks, and since it also was reported for Extras, I've examined it multiple times, because only complete/sane metadata are published there. Everytime I used wget/lftp to examine mirrors, I found that they had incomplete metadata files or a repomd.xml that was newer than the compressed xml files. From notting at redhat.com Thu May 17 16:07:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 12:07:06 -0400 Subject: rawhide report: changes In-Reply-To: <1179390800.3544.0.camel@localhost.localdomain> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> Message-ID: <20070517160706.GA1938@nostromo.devel.redhat.com> Rodd Clarkson (rodd at clarkson.id.au) said: > Loading "installonlyn" plugin > Setting up Update Process > primary.xml.gz 100% |=========================| 2.6 MB 00:51 > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum > Trying other mirror. > Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. The fix has been pushed to the mirror master and should propagate out soon. Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure. Bill From bruno at wolff.to Thu May 17 16:46:26 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 17 May 2007 11:46:26 -0500 Subject: Different python versions in a Fedora system In-Reply-To: <604aa7910705170833u37dea059k97059cc105b37fff@mail.gmail.com> References: <200705171408.34149.kushaldas@gmail.com> <604aa7910705170833u37dea059k97059cc105b37fff@mail.gmail.com> Message-ID: <20070517164626.GC6475@wolff.to> On Thu, May 17, 2007 at 07:33:26 -0800, Jeff Spaleta wrote: > > Can you give me a specific reason why you need multiple versions of > python installed? The discussion started because zope doesn't work with 2.5 and isn't likely to soon. From miles.lane at gmail.com Thu May 17 17:31:37 2007 From: miles.lane at gmail.com (Miles Lane) Date: Thu, 17 May 2007 10:31:37 -0700 Subject: rawhide report: changes In-Reply-To: <20070517142752.GA25891@lists.us.dell.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> <20070517142752.GA25891@lists.us.dell.com> Message-ID: On 5/17/07, Matt Domsch wrote: > On Thu, May 17, 2007 at 02:04:27AM -0700, Miles Lane wrote: > > My fedora-development.repo contains: > > [development] > > name=Fedora Core - Development > > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > > # > > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide.us.west > > For the record, I recommend people use: > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch > > as the content at fedora.redhat.com/download/mirrors is quite stale > and no longer updated. The content at mirrors.fedoraproject.org is > generated several times a day by crawling all the mirrors, and uses > GeoIP to return you a country-local up-to-date mirror if possible. Thanks for the suggestion Matt. I gave it a try, but I am still not seeing the updates. # yum update Setting up Update Process development 100% |=========================| 1.1 kB 00:00 primary.xml.gz 100% |=========================| 2.6 MB 00:23 http://mirrors.cat.pdx.edu/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:10 ftp://fedora.bu.edu/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:08 ftp://ftp.cse.buffalo.edu/pub/Linux/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. ftp://mirror.colorado.edu/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno 4] IOError: [Errno ftp error] 421 There are too many connected users, please try later. Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:06 http://ftp.linux.ncsu.edu/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:40 http://coblitz.planet-lab.org/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 2.6 MB 00:07 developmen: ################################################## 7296/7296 No Packages marked for Update/Obsoletion [root at hogwarts yum.repos.d]# yum list control-center Installed Packages control-center.i386 1:2.18.0-14.fc7 installed I also tried http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ again. I still get: # yum update Setting up Update Process development 100% |=========================| 1.1 kB 00:00 primary.xml.gz 100% |=========================| 2.6 MB 00:08 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. From mlum at redhat.com Thu May 17 17:57:24 2007 From: mlum at redhat.com (Margaret Lum) Date: Thu, 17 May 2007 10:57:24 -0700 Subject: Different python versions in a Fedora system In-Reply-To: <20070517164626.GC6475@wolff.to> References: <200705171408.34149.kushaldas@gmail.com> <604aa7910705170833u37dea059k97059cc105b37fff@mail.gmail.com> <20070517164626.GC6475@wolff.to> Message-ID: <464C9784.6070702@redhat.com> Bruno Wolff III wrote: > On Thu, May 17, 2007 at 07:33:26 -0800, > Jeff Spaleta wrote: > >> Can you give me a specific reason why you need multiple versions of >> python installed? >> > > The discussion started because zope doesn't work with 2.5 and isn't likely > to soon. > > I'm able to do this, but I just re-symlink /usr/local/bin/python when I need zope to use 2.5, and 2.4 when yum needs it. This probably a hack, but I've had no problems with zope or yum while doing this. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From blc at redhat.com Thu May 17 17:57:47 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 17 May 2007 11:57:47 -0600 Subject: rawhide report: changes In-Reply-To: <20070517160706.GA1938@nostromo.devel.redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <20070517160706.GA1938@nostromo.devel.redhat.com> Message-ID: <464C979B.6020309@redhat.com> Bill Nottingham wrote: > The fix has been pushed to the mirror master and should propagate out soon. > Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure. Also repomd.xml needs to be regenerated with primary.xml.gz's updated sha1 sum. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From walters at redhat.com Thu May 17 18:23:12 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 17 May 2007 14:23:12 -0400 Subject: random thoughts on software installation Message-ID: <1179426193.15705.58.camel@neutron> Recently as part of the online desktop project we've been doing some work on installing desktop applications, a blog entry is here: http://clarkbw.net/blog/2007/05/04/bullish-on-finding-new-applications/ However, what I was thinking about on the drive in this morning though is how we could make the experience kick ass for the other kinds of software out there, like developer libraries and tools (foo-devel, mercurial) and server software (postfix). For the first part - developer software, my ideal tool would look something like this. Just a search box, and a list of result hits. Like a web search engine basically. /----- | Search: [ hg ] | | Package: mercurial _Install_ | - /usr/bin/hg | \----- Searches executable names /----- | Search: [ db.h ] | | Package: libdb2-devel _Install_ | - /usr/include/db2/db.h | | Package: libdb3-devel _Install_ | - /usr/include/db3/db.h \----- Searches files. /----- | Search: [ ssh python ] | | Package: python-paramiko _Install_ | "Paramiko is an implementation of ssh for Python..." | | Package: openssh _Install_ | - /usr/bin/ssh \----- Searches descriptions and names too. No support for conflicts[1], removing packages[2], installing multiple packages at a time[3] (if the user clicks multiple, just queue them up), updating to new package versions[4], whatever. Let me search for that developer thing I need and one click blat it to the disk from the web. Menu entry would be 'Install Programming Tools'. Would require a local cache of the contents of all packages - also being able to search the individual symbols in things like shared libraries, Python modules, etc. Probably large, but I bet gzip would do quite well on it for a CD, and hard disks are big so store uncompressed to make it fast. Use rsync to periodically keep it up to date. Or perhaps we could dump the local cache idea and have it be a fedoraproject.org web service. Now there's another class of software - server software like apache, mediawiki, postfix, etc. These kinds of packages could legitimately conflict with others. But the difference is a lot more fundamental - for this kind of software, downloading the package is only the *very first* step in actually getting it working. You have to configure these, and there's no way around that. We could talk a lot about what installing server software could be like, but an idea of where we could go would be towards something like "RHX for Fedora": https://rhx.redhat.com Being able to click on Postfix and click on reviews, comparisons to other things like Sendmail would be cool. I know we have some people that are passionate about particluar server software that would likely add reviews. Could be hosted on the fedoraproject.org wiki. A super small thing that would be *easy* to implement for server software would be to include a "Next-Step-URL" or something in the RPM spec file that opens in a browser after you install the software. Let's be realistic - admins rely on the web for setting these things up. Unless you're an admin god, but in the case you are you can help add to the wiki page =) We could define this to always point to a fedoraproject.org wiki page, which could then link to "official" setup instructions like: http://www.mediawiki.org/wiki/Installation and also have Fedora-specific tweaks and instructions, like a link to a description of the Fedora Apache SELinux policy, etc. If there was no content on the fedora page it could just be an auto-redirect to the upstream site until some content is added. Anyways, just some random thoughts. [1] None of this software should conflict with anything else. [2] Should be extremely rare to remove any of this stuff...in the odd event you are really scraping for disk space, an "out of disk space" tool could detect which things are unused, but it's more likely anyways that what's actually eating your disk space is all those Battlestar Galactica or whatever episodes you've been bittorrenting. Bad user! [3] Don't need transactions, etc...as soon as the user clicks start downloading and installing. Since there are no conflicts there shouldn't be an issue. [4] The pirut update applet is great for this From katzj at redhat.com Thu May 17 18:34:16 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 17 May 2007 14:34:16 -0400 Subject: random thoughts on software installation In-Reply-To: <1179426193.15705.58.camel@neutron> References: <1179426193.15705.58.camel@neutron> Message-ID: <1179426856.19885.16.camel@erebor.boston.redhat.com> On Thu, 2007-05-17 at 14:23 -0400, Colin Walters wrote: [snip] > No support for conflicts[1], removing packages[2], installing multiple > packages at a time[3] (if the user clicks multiple, just queue them up), This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc. All that said -- it'd be trivial to split out the search bit of pirut and have that run stand-alone. But that doesn't get rid of the need to do transactions, depsolving, etc. Jeremy From walters at redhat.com Thu May 17 18:37:16 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 17 May 2007 14:37:16 -0400 Subject: random thoughts on software installation In-Reply-To: <1179426856.19885.16.camel@erebor.boston.redhat.com> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> Message-ID: <1179427037.15705.63.camel@neutron> On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote: > This is a fundamentally broken assumption. Multiple packages are > required because packages can and do depend on other packages. Even > things like python-paramiko, etc. Sure, I guess I didn't mean transaction in the techncial sense but more like how it's exposed in the interface; i.e. that you don't need to take the current approach that pirut does where you click on a bunch of things and then have an "apply" step and a confirm step, or yum's install confirmation. Could just start downloading and installing on the first click. From katzj at redhat.com Thu May 17 18:43:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 17 May 2007 14:43:51 -0400 Subject: random thoughts on software installation In-Reply-To: <1179427037.15705.63.camel@neutron> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> <1179427037.15705.63.camel@neutron> Message-ID: <1179427431.19885.23.camel@erebor.boston.redhat.com> On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote: > On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote: > > This is a fundamentally broken assumption. Multiple packages are > > required because packages can and do depend on other packages. Even > > things like python-paramiko, etc. > > Sure, I guess I didn't mean transaction in the techncial sense but more > like how it's exposed in the interface; i.e. that you don't need to take > the current approach that pirut does where you click on a bunch of > things and then have an "apply" step and a confirm step, or yum's > install confirmation. Could just start downloading and installing on > the first click. And then people complain you didn't tell them what was going to be pulled in or why did this that or the other get installed or why did something get _removed_ due to an obsoletes. And the people who complain the most about this stuff are the exact people you're trying to target with this interface (developers and sysadmins). Jeremy From walters at redhat.com Thu May 17 18:53:27 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 17 May 2007 14:53:27 -0400 Subject: random thoughts on software installation In-Reply-To: <1179427431.19885.23.camel@erebor.boston.redhat.com> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> <1179427037.15705.63.camel@neutron> <1179427431.19885.23.camel@erebor.boston.redhat.com> Message-ID: <1179428007.15705.73.camel@neutron> On Thu, 2007-05-17 at 14:43 -0400, Jeremy Katz wrote: > On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote: > > On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote: > > > This is a fundamentally broken assumption. Multiple packages are > > > required because packages can and do depend on other packages. Even > > > things like python-paramiko, etc. > > > > Sure, I guess I didn't mean transaction in the techncial sense but more > > like how it's exposed in the interface; i.e. that you don't need to take > > the current approach that pirut does where you click on a bunch of > > things and then have an "apply" step and a confirm step, or yum's > > install confirmation. Could just start downloading and installing on > > the first click. > > And then people complain you didn't tell them what was going to be > pulled in or why did this that or the other get installed or why did > something get _removed_ due to an obsoletes. Seems solvable - display below each name the list of packages you'd need to install to get it. I doubt any of these have huge dependency trees because we're assuming for this tool that you already have base things like the 'Development Tools' group installed. I'd imagine this tool would come with that group, or maybe we need a 'Base Development Environment' that has graphical things. Would be cool to have anyways say for a spin of Fedora explicitly targeted for developers. As for packages getting removed...are there really any developer tools that obsolete earlier ones that would matter to someone? The obsolete type situations I imagine would mostly have already been done when someone does a big upgrade from Fedora x to x+1, not after they've installed. Anyways...techncial details! Think about how cool it would be =) From miles.lane at gmail.com Thu May 17 18:59:31 2007 From: miles.lane at gmail.com (Miles Lane) Date: Thu, 17 May 2007 11:59:31 -0700 Subject: rawhide report: changes In-Reply-To: <464C979B.6020309@redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <20070517160706.GA1938@nostromo.devel.redhat.com> <464C979B.6020309@redhat.com> Message-ID: On 5/17/07, Brendan Conoboy wrote: > Bill Nottingham wrote: > > The fix has been pushed to the mirror master and should propagate out soon. > > Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure. > > Also repomd.xml needs to be regenerated with primary.xml.gz's updated > sha1 sum. I have successfully gotten the updates. Thanks for your help, Miles From nicolas.mailhot at laposte.net Thu May 17 19:03:23 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 21:03:23 +0200 Subject: random thoughts on software installation In-Reply-To: <1179427431.19885.23.camel@erebor.boston.redhat.com> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> <1179427037.15705.63.camel@neutron> <1179427431.19885.23.camel@erebor.boston.redhat.com> Message-ID: <1179428603.3539.4.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 14:43 -0400, Jeremy Katz a ?crit : > On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote: > > On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote: > > > This is a fundamentally broken assumption. Multiple packages are > > > required because packages can and do depend on other packages. Even > > > things like python-paramiko, etc. > > > > Sure, I guess I didn't mean transaction in the techncial sense but more > > like how it's exposed in the interface; i.e. that you don't need to take > > the current approach that pirut does where you click on a bunch of > > things and then have an "apply" step and a confirm step, or yum's > > install confirmation. Could just start downloading and installing on > > the first click. > > And then people complain you didn't tell them what was going to be > pulled in or why did this that or the other get installed or why did > something get _removed_ due to an obsoletes. > > And the people who complain the most about this stuff are the exact > people you're trying to target with this interface (developers and > sysadmins). +10 no more of this "it's hard/not-windowsish so let's not do/expose it" madness. We don't need an "easy" broken-by-design model and we don't have to be ashamed of how our tools work (compared to the competition) Users won't complain long if the stuff works. Making sure our model works is where efforts should focus. -- 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 miles.lane at gmail.com Thu May 17 19:28:09 2007 From: miles.lane at gmail.com (Miles Lane) Date: Thu, 17 May 2007 12:28:09 -0700 Subject: rawhide report: changes -- conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 Message-ID: On 5/17/07, Miles Lane wrote: > On 5/17/07, Brendan Conoboy wrote: > > Bill Nottingham wrote: > > > The fix has been pushed to the mirror master and should propagate out soon. > > > Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure. > > > > Also repomd.xml needs to be regenerated with primary.xml.gz's updated > > sha1 sum. > > I have successfully gotten the updates. Transaction Check Error: file /usr/share/config/kdm conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/Xaccess conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/Xsession conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/Xsetup conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/Xwilling conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/backgroundrc conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 file /usr/share/config/kdm/kdmrc conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 From walters at redhat.com Thu May 17 19:45:43 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 17 May 2007 15:45:43 -0400 Subject: random thoughts on software installation In-Reply-To: <1179428603.3539.4.camel@rousalka.dyndns.org> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> <1179427037.15705.63.camel@neutron> <1179427431.19885.23.camel@erebor.boston.redhat.com> <1179428603.3539.4.camel@rousalka.dyndns.org> Message-ID: <1179431143.15705.88.camel@neutron> On Thu, 2007-05-17 at 21:03 +0200, Nicolas Mailhot wrote: > +10 no more of this "it's hard/not-windowsish so let's not do/expose it" > madness. We don't need an "easy" broken-by-design model and we don't > have to be ashamed of how our tools work (compared to the competition) Not sure what you're saying here...clearly what Fedora has now is way better than Windows since there is basically nothing equivalent there; I was hoping to think about how we could do even better. Also there's nothing about shame here...the fact that yum exists doesn't mean that the rpm developers should be ashamed. Likewise, taking the "http://serversoftware.fedoraproject.org" example, that doesn't mean anything is wrong with yum! Clearly it would backend to yum. I'm just trying to think about the kinds of things we can build on top of those tools, especially when you consider targeting design for particular audiences or particular classes of package. And also when you consider things like more tightly integrating Fedora-the-software with Fedora-the-website. Anyways I think my first example got too sidetracked by the specific details of transactions or whatever...skvidal is doing some work on search which should help in getting through Fedora's huge collection of developer stuff. Personally think the "http://serversoftware.fedoraproject.org" idea is a lot more interesting thing to talk about and was hoping to spur discussion on that =) From rdieter at math.unl.edu Thu May 17 20:07:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 May 2007 15:07:12 -0500 Subject: rawhide report: changes -- conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 References: Message-ID: Miles Lane wrote: > Transaction Check Error: > file /usr/share/config/kdm conflicts between attempted installs of > kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7 Yerp, fixed in kdebase-3.5.6-11 -- Rex From orion at cora.nwra.com Thu May 17 20:35:46 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 14:35:46 -0600 Subject: Massive size increases in certain packages Message-ID: <464CBCA2.8050500@cora.nwra.com> I just got a bug report on python-numarray (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240289) indicating that the size of the installed package has increased from around 6.7MB in FC6 (1.5.2-1.fc6) to around 56MB currently (1.5.2-2.fc7). Now, the only this that was done was to rebuild the package for python 2.5 back in December. If I rebuild the package now the size is back to "normal". The differences are in the size of the shared libraries: < 1272 /usr/lib/python2.5/site-packages/numarray/_bytes.so < 1264 /usr/lib/python2.5/site-packages/numarray/_chararray.so < 1308 /usr/lib/python2.5/site-packages/numarray/_conv.so < 1268 /usr/lib/python2.5/site-packages/numarray/_converter.so < 1280 /usr/lib/python2.5/site-packages/numarray/_ndarray.so < 1280 /usr/lib/python2.5/site-packages/numarray/_numarray.so < 1260 /usr/lib/python2.5/site-packages/numarray/_numerictype.so < 1264 /usr/lib/python2.5/site-packages/numarray/_objectarray.so < 1260 /usr/lib/python2.5/site-packages/numarray/_operator.so < 1376 /usr/lib/python2.5/site-packages/numarray/_sort.so < 1292 /usr/lib/python2.5/site-packages/numarray/_ufunc.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so < 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so < 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so < 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so < 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so < 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so < 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so < 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so --- > 28 /usr/lib/python2.5/site-packages/numarray/_bytes.so > 20 /usr/lib/python2.5/site-packages/numarray/_chararray.so > 72 /usr/lib/python2.5/site-packages/numarray/_conv.so > 20 /usr/lib/python2.5/site-packages/numarray/_converter.so > 36 /usr/lib/python2.5/site-packages/numarray/_ndarray.so > 36 /usr/lib/python2.5/site-packages/numarray/_numarray.so > 12 /usr/lib/python2.5/site-packages/numarray/_numerictype.so > 16 /usr/lib/python2.5/site-packages/numarray/_objectarray.so > 16 /usr/lib/python2.5/site-packages/numarray/_operator.so > 136 /usr/lib/python2.5/site-packages/numarray/_sort.so > 48 /usr/lib/python2.5/site-packages/numarray/_ufunc.so > 80 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so > 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so > 80 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so > 84 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so > 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so and so on. I did a quick compare of FE 6 to the last FE devel and found that the following packages have increased in size by more than a factor of 2. Some of these may be fine, I haven't looked into it in detail. What's up? banshee 2536364 -> 6770157 cppunit-doc 4504311 -> 10063237 duplicity 936214 -> 2255520 fwbackups 347859 -> 894038 graphviz-tcl 298038 -> 2020760 libburn-devel 47334 -> 944521 libcaca-devel 507545 -> 1482955 libhugetlbfs 97382 -> 206633 libhugetlbfs-test 1031501 -> 135632714 libpreludedb-python 91466 -> 1355682 linux-libertine-fonts 2589874 -> 10225720 mercurial 2063651 -> 6487353 nsd 446095 -> 1665847 ogre 6374746 -> 29476134 openbabel-perl 1206495 -> 3376667 openbabel-python 1501764 -> 3509293 ortp-devel 197141 -> 3761868 php-pear-PHPUnit 126756 -> 1106041 plplot-wxGTK 54287 -> 144831 pybluez 341942 -> 1617662 pyflowtools 35170 -> 1302402 pyfribidi 27095 -> 1299303 pygpgme 79943 -> 1349853 python-CDDB 55383 -> 1324169 python-GeoIP 30419 -> 1299395 python-adns 60844 -> 1327860 python-alsaaudio 28238 -> 1297182 python-chm 121632 -> 2670312 python-durus 419912 -> 1718919 python-numarray 6771218 -> 56416870 python-protocols 766774 -> 2075564 python-pycurl 212612 -> 1485863 python-quixote 1853963 -> 7008959 python-ruledispatch 933214 -> 2272446 python-smbpasswd 34293 -> 1302773 python-twisted-runner 74839 -> 1349825 python-zope-interface 1013800 -> 2358938 pyxmms 327987 -> 2871939 rdiff-backup 1286381 -> 3896666 supertux 15057058 -> 49666684 wallpapoz 110963 -> 363890 xpa 945338 -> 1979801 zvbi-fonts 43808 -> 132817 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From notting at redhat.com Thu May 17 20:35:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 16:35:39 -0400 Subject: Massive size increases in certain packages In-Reply-To: <464CBCA2.8050500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> Message-ID: <20070517203539.GB6900@nostromo.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > I just got a bug report on python-numarray > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240289) indicating > that the size of the installed package has increased from around 6.7MB > in FC6 (1.5.2-1.fc6) to around 56MB currently (1.5.2-2.fc7). Now, the > only this that was done was to rebuild the package for python 2.5 back > in December. > > If I rebuild the package now the size is back to "normal". The > differences are in the size of the shared libraries: Do you turn off debug packages? Bill From email.ahmedkamal at googlemail.com Thu May 17 20:39:45 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 17 May 2007 23:39:45 +0300 Subject: random thoughts on software installation In-Reply-To: <1179426193.15705.58.camel@neutron> References: <1179426193.15705.58.camel@neutron> Message-ID: <3da3b5b40705171339r46746e3hbfb8c9be7c6d616c@mail.gmail.com> > > conflict with others. But the difference is a lot more fundamental - > for this kind of software, downloading the package is only the *very > first* step in actually getting it working. You have to configure > these, and there's no way around that. > Well, why not start integrating pre-configured "puppet recipes" that configure the server software (postfix for example) for popular configurations. The way I see it, you select your server software, and you get a list of popular configurations: 1) Standalone primary mail server 2) Backup MX mail-server 3) Anti-Virus, Anti-Spam gateway The user chooses a configuration, gets a simple web-interface to fill "parameters" as in "your domain name", "the primary MX IP address" ... etc The user clicks "Go", the software is downloaded, installed, configured, started. New users will be happy, advanced admins will hack on the configuration even more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu May 17 20:55:04 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 14:55:04 -0600 Subject: Massive size increases in certain packages In-Reply-To: <20070517203539.GB6900@nostromo.devel.redhat.com> References: <464CBCA2.8050500@cora.nwra.com> <20070517203539.GB6900@nostromo.devel.redhat.com> Message-ID: <464CC128.7020803@cora.nwra.com> Bill Nottingham wrote: > Orion Poplawski (orion at cora.nwra.com) said: >> I just got a bug report on python-numarray >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240289) indicating >> that the size of the installed package has increased from around 6.7MB >> in FC6 (1.5.2-1.fc6) to around 56MB currently (1.5.2-2.fc7). Now, the >> only this that was done was to rebuild the package for python 2.5 back >> in December. >> >> If I rebuild the package now the size is back to "normal". The >> differences are in the size of the shared libraries: > > Do you turn off debug packages? > > Bill > I do nothing but rebuild. Perhaps debug packages were broken for a bit? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From sundaram at fedoraproject.org Thu May 17 21:17:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 18 May 2007 02:47:20 +0530 Subject: rawhide report: changes In-Reply-To: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> Message-ID: <464CC660.6030001@fedoraproject.org> Build System wrote: > New package gsm > Shared libraries for GSM speech compressor > > New package kde-settings > Config files for kde > > New package liberation-fonts > Fonts to replace commonly used Microsoft Windows Fonts > > New package mcpp > Alternative C/C++ preprocessor > > New package php-pear-HTML-QuickForm-ElementGrid > Meta-element which holds any other element in a grid > > Please fix these reports to have a date in the subject. Rahul From jspaleta at gmail.com Thu May 17 21:24:28 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 May 2007 13:24:28 -0800 Subject: Massive size increases in certain packages In-Reply-To: <464CC128.7020803@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <20070517203539.GB6900@nostromo.devel.redhat.com> <464CC128.7020803@cora.nwra.com> Message-ID: <604aa7910705171424w70fbe56j9b87766a0b0b07e6@mail.gmail.com> On 5/17/07, Orion Poplawski wrote: > I do nothing but rebuild. Perhaps debug packages were broken for a bit? Is there a way to systematically check for this possibility via postmortem analysis of the current package tree? Like can we do a check for unstripped debug symbols on a rawhide installed system and map back to build timestamps in the associated rpm? -jef From walters at redhat.com Thu May 17 21:31:37 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 17 May 2007 17:31:37 -0400 Subject: random thoughts on software installation In-Reply-To: <3da3b5b40705171339r46746e3hbfb8c9be7c6d616c@mail.gmail.com> References: <1179426193.15705.58.camel@neutron> <3da3b5b40705171339r46746e3hbfb8c9be7c6d616c@mail.gmail.com> Message-ID: <1179437497.15705.115.camel@neutron> On Thu, 2007-05-17 at 23:39 +0300, Ahmed Kamal wrote: > conflict with others. But the difference is a lot more > fundamental - > for this kind of software, downloading the package is only the > *very > first* step in actually getting it working. You have to > configure > these, and there's no way around that. > > Well, why not start integrating pre-configured "puppet recipes" that > configure the server software (postfix for example) for popular > configurations. Ah, interesting idea, yeah. A long time ago when I was a Debian developer and into server software, I wrote the "debconf" bits to configure postfix with a few common scenarios, although less complex ones than you're suggesting. I think it wasn't hugely successful (and the same is true of debconf in general) because a good number of admins want more flexibility, and control/understanding of what's going on. Now certainly it's not exactly the same thing as what you're talking about, but it just reminded me. Could be that puppet is a better technology for this sort of stuff than debconf is though. I guess what I would maybe think about is more generally allowing people to attach files like sample configurations or their puppet scripts to the package wiki pages. Wouldn't it be cool if Fedora made it really easy to edit the "http://servers.fedoraproject.org/wiki/postfix" wiki page and add "Joe Bob's Tutorial on setting up Postfix+ClamAV", and then if he made it all into a puppet script he could add it there. Right now you often see pages like this that are kind of random - wherever the sysadmin happened to find web hosting. Actually just for the very first cut I think having a defined wiki page for server software where people could add just random content like: "Here's what I did to make my config work with SELinux on FC6..." "If you're setting up Postfix, be sure to check out [[ClamAV]] too." in addition to a link to the upstream website's common installation instructions or other tutorials around the web would be a pretty nice first step. Things like comment/discussion boards, reviews, configuration file attachements could come later. From orion at cora.nwra.com Thu May 17 21:39:32 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 15:39:32 -0600 Subject: Massive size increases in certain packages In-Reply-To: <464CC128.7020803@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <20070517203539.GB6900@nostromo.devel.redhat.com> <464CC128.7020803@cora.nwra.com> Message-ID: <464CCB94.8020501@cora.nwra.com> Orion Poplawski wrote: > > I do nothing but rebuild. Perhaps debug packages were broken for a bit? > Although the .so files in -2.fc7 appear to be stripped: /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped # nm /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so nm: /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so: no symbols # ls -l /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so -rwxr-xr-x 1 root root 1308096 2006-12-12 22:22 /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so It appeara that the "big" one doesn't have a "NEEDED libpython2.5.so.1.0" entry, perhaps it was getting included directly? This would have to have been an effect of a change in some other package though. Big: # objdump -x /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so: file format elf32-i386 /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so architecture: i386, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x0001c810 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x00119e0c memsz 0x00119e0c flags r-x LOAD off 0x0011a000 vaddr 0x0011a000 paddr 0x0011a000 align 2**12 filesz 0x000250c0 memsz 0x0002b90c flags rw- DYNAMIC off 0x0011a0ec vaddr 0x0011a0ec paddr 0x0011a0ec align 2**2 filesz 0x000000d0 memsz 0x000000d0 flags rw- EH_FRAME off 0x001001c8 vaddr 0x001001c8 paddr 0x001001c8 align 2**2 filesz 0x000052cc memsz 0x000052cc flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rw- Dynamic Section: NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED libc.so.6 INIT 0x18d78 FINI 0xdf334 GNU_HASH 0xd4 STRTAB 0x75f8 SYMTAB 0x25a8 STRSZ 0x5203 SYMENT 0x10 PLTGOT 0x11a528 PLTRELSZ 0x1d38 PLTREL 0x11 JMPREL 0x17040 REL 0xd2e8 RELSZ 0x9d58 RELENT 0x8 VERNEED 0xd208 VERNEEDNUM 0x3 VERSYM 0xc7fc RELCOUNT 0x11fb Version References: required from libpthread.so.0: 0x0d696912 0x00 09 GLIBC_2.2 0x0d696911 0x00 08 GLIBC_2.1 0x0d696910 0x00 04 GLIBC_2.0 required from libm.so.6: 0x0d696910 0x00 03 GLIBC_2.0 required from libc.so.6: 0x09691f73 0x00 12 GLIBC_2.1.3 0x0d696914 0x00 11 GLIBC_2.4 0x0d696913 0x00 10 GLIBC_2.3 0x09691974 0x00 07 GLIBC_2.3.4 0x0d696912 0x00 06 GLIBC_2.2 0x0d696911 0x00 05 GLIBC_2.1 0x0d696910 0x00 02 GLIBC_2.0 Sections: Idx Name Size VMA LMA File off Algn 0 .gnu.hash 000024d4 000000d4 000000d4 000000d4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 00005050 000025a8 000025a8 000025a8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00005203 000075f8 000075f8 000075f8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu.version 00000a0a 0000c7fc 0000c7fc 0000c7fc 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.version_r 000000e0 0000d208 0000d208 0000d208 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rel.dyn 00009d58 0000d2e8 0000d2e8 0000d2e8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .rel.plt 00001d38 00017040 00017040 00017040 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .init 00000017 00018d78 00018d78 00018d78 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .plt 00003a80 00018d90 00018d90 00018d90 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .text 000c2b24 0001c810 0001c810 0001c810 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .fini 0000001c 000df334 000df334 000df334 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .rodata 00020e68 000df360 000df360 000df360 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .eh_frame_hdr 000052cc 001001c8 001001c8 001001c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .eh_frame 00014978 00105494 00105494 00105494 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .ctors 00000008 0011a000 0011a000 0011a000 2**2 CONTENTS, ALLOC, LOAD, DATA 15 .dtors 00000008 0011a008 0011a008 0011a008 2**2 CONTENTS, ALLOC, LOAD, DATA 16 .jcr 00000004 0011a010 0011a010 0011a010 2**2 CONTENTS, ALLOC, LOAD, DATA 17 .data.rel.ro 000000cc 0011a020 0011a020 0011a020 2**5 CONTENTS, ALLOC, LOAD, DATA 18 .dynamic 000000d0 0011a0ec 0011a0ec 0011a0ec 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .got 0000036c 0011a1bc 0011a1bc 0011a1bc 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .got.plt 00000ea8 0011a528 0011a528 0011a528 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .data 00023ce0 0011b3e0 0011b3e0 0011b3e0 2**5 CONTENTS, ALLOC, LOAD, DATA 22 .bss 0000684c 0013f0c0 0013f0c0 0013f0c0 2**5 ALLOC 23 .gnu_debuglink 00000018 00000000 00000000 0013f0c0 2**2 CONTENTS, READONLY SYMBOL TABLE: no symbols Small: /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so: file format elf32-i386 /usr/lib/python2.5/site-packages/numarray/random_array/ranlib2.so architecture: i386, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00001480 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x0000843c memsz 0x0000843c flags r-x LOAD off 0x00009000 vaddr 0x00009000 paddr 0x00009000 align 2**12 filesz 0x000005f0 memsz 0x00000ea4 flags rw- DYNAMIC off 0x00009018 vaddr 0x00009018 paddr 0x00009018 align 2**2 filesz 0x000000d8 memsz 0x000000d8 flags rw- EH_FRAME off 0x00007bac vaddr 0x00007bac paddr 0x00007bac align 2**2 filesz 0x000001cc memsz 0x000001cc flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rw- Dynamic Section: NEEDED libpython2.5.so.1.0 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED libc.so.6 INIT 0x1118 FINI 0x7104 GNU_HASH 0xd4 STRTAB 0x878 SYMTAB 0x2a8 STRSZ 0x383 SYMENT 0x10 PLTGOT 0x917c PLTRELSZ 0x1a0 PLTREL 0x11 JMPREL 0xf78 REL 0xd18 RELSZ 0x260 RELENT 0x8 VERNEED 0xcb8 VERNEEDNUM 0x2 VERSYM 0xbfc RELCOUNT 0x29 Version References: required from libc.so.6: 0x09691f73 0x00 05 GLIBC_2.1.3 0x0d696910 0x00 04 GLIBC_2.0 0x09691974 0x00 03 GLIBC_2.3.4 required from libm.so.6: 0x0d696910 0x00 02 GLIBC_2.0 Sections: Idx Name Size VMA LMA File off Algn 0 .gnu.hash 000001d4 000000d4 000000d4 000000d4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 000005d0 000002a8 000002a8 000002a8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00000383 00000878 00000878 00000878 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu.version 000000ba 00000bfc 00000bfc 00000bfc 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.version_r 00000060 00000cb8 00000cb8 00000cb8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rel.dyn 00000260 00000d18 00000d18 00000d18 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .rel.plt 000001a0 00000f78 00000f78 00000f78 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .init 00000017 00001118 00001118 00001118 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .plt 00000350 00001130 00001130 00001130 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .text 00005c84 00001480 00001480 00001480 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .fini 0000001c 00007104 00007104 00007104 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .rodata 00000a8a 00007120 00007120 00007120 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .eh_frame_hdr 000001cc 00007bac 00007bac 00007bac 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .eh_frame 000006c4 00007d78 00007d78 00007d78 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .ctors 00000008 00009000 00009000 00009000 2**2 CONTENTS, ALLOC, LOAD, DATA 15 .dtors 00000008 00009008 00009008 00009008 2**2 CONTENTS, ALLOC, LOAD, DATA 16 .jcr 00000004 00009010 00009010 00009010 2**2 CONTENTS, ALLOC, LOAD, DATA 17 .data.rel.ro 00000004 00009014 00009014 00009014 2**2 CONTENTS, ALLOC, LOAD, DATA 18 .dynamic 000000d8 00009018 00009018 00009018 2**2 CONTENTS, ALLOC, LOAD, DATA 19 .got 0000008c 000090f0 000090f0 000090f0 2**2 CONTENTS, ALLOC, LOAD, DATA 20 .got.plt 000000dc 0000917c 0000917c 0000917c 2**2 CONTENTS, ALLOC, LOAD, DATA 21 .data 00000390 00009260 00009260 00009260 2**5 CONTENTS, ALLOC, LOAD, DATA 22 .bss 000008a4 00009600 00009600 000095f0 2**5 ALLOC 23 .gnu_debuglink 00000018 00000000 00000000 000095f0 2**2 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jima at beer.tclug.org Thu May 17 21:41:56 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 17 May 2007 16:41:56 -0500 (CDT) Subject: Massive size increases in certain packages In-Reply-To: <464CBCA2.8050500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> Message-ID: On Thu, 17 May 2007, Orion Poplawski wrote: > graphviz-tcl 298038 -> 2020760 Newer upstream version; they added some more libraries. Thanks for the heads-up, though. This is a good check to do. Jima From orion at cora.nwra.com Thu May 17 21:49:07 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 15:49:07 -0600 Subject: Massive size increases in certain packages In-Reply-To: <464CCB94.8020501@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <20070517203539.GB6900@nostromo.devel.redhat.com> <464CC128.7020803@cora.nwra.com> <464CCB94.8020501@cora.nwra.com> Message-ID: <464CCDD3.8020500@cora.nwra.com> Here's a diff of the objdumps. Looks like different glibc versions as well? < = big, > = small 6c6 < start address 0x0001c810 --- > start address 0x00001480 10,16c10,16 < filesz 0x00119e0c memsz 0x00119e0c flags r-x < LOAD off 0x0011a000 vaddr 0x0011a000 paddr 0x0011a000 align 2**12 < filesz 0x000250c0 memsz 0x0002b90c flags rw- < DYNAMIC off 0x0011a0ec vaddr 0x0011a0ec paddr 0x0011a0ec align 2**2 < filesz 0x000000d0 memsz 0x000000d0 flags rw- < EH_FRAME off 0x001001c8 vaddr 0x001001c8 paddr 0x001001c8 align 2**2 < filesz 0x000052cc memsz 0x000052cc flags r-- --- > filesz 0x0000843c memsz 0x0000843c flags r-x > LOAD off 0x00009000 vaddr 0x00009000 paddr 0x00009000 align 2**12 > filesz 0x000005f0 memsz 0x00000ea4 flags rw- > DYNAMIC off 0x00009018 vaddr 0x00009018 paddr 0x00009018 align 2**2 > filesz 0x000000d8 memsz 0x000000d8 flags rw- > EH_FRAME off 0x00007bac vaddr 0x00007bac paddr 0x00007bac align 2**2 > filesz 0x000001cc memsz 0x000001cc flags r-- 20a21 > NEEDED libpython2.5.so.1.0 24,25c25,26 < INIT 0x18d78 < FINI 0xdf334 --- > INIT 0x1118 > FINI 0x7104 27,29c28,30 < STRTAB 0x75f8 < SYMTAB 0x25a8 < STRSZ 0x5203 --- > STRTAB 0x878 > SYMTAB 0x2a8 > STRSZ 0x383 31,32c32,33 < PLTGOT 0x11a528 < PLTRELSZ 0x1d38 --- > PLTGOT 0x917c > PLTRELSZ 0x1a0 34,36c35,37 < JMPREL 0x17040 < REL 0xd2e8 < RELSZ 0x9d58 --- > JMPREL 0xf78 > REL 0xd18 > RELSZ 0x260 38,41c39,42 < VERNEED 0xd208 < VERNEEDNUM 0x3 < VERSYM 0xc7fc < RELCOUNT 0x11fb --- > VERNEED 0xcb8 > VERNEEDNUM 0x2 > VERSYM 0xbfc > RELCOUNT 0x29 44,46c45,46 < required from libpthread.so.0: < 0x0d696912 0x00 09 GLIBC_2.2 < 0x0d696911 0x00 08 GLIBC_2.1 --- > required from libc.so.6: > 0x09691f73 0x00 05 GLIBC_2.1.3 47a48 > 0x09691974 0x00 03 GLIBC_2.3.4 49,56d49 < 0x0d696910 0x00 03 GLIBC_2.0 < required from libc.so.6: < 0x09691f73 0x00 12 GLIBC_2.1.3 < 0x0d696914 0x00 11 GLIBC_2.4 < 0x0d696913 0x00 10 GLIBC_2.3 < 0x09691974 0x00 07 GLIBC_2.3.4 < 0x0d696912 0x00 06 GLIBC_2.2 < 0x0d696911 0x00 05 GLIBC_2.1 61c54 < 0 .gnu.hash 000024d4 000000d4 000000d4 000000d4 2**2 --- > 0 .gnu.hash 000001d4 000000d4 000000d4 000000d4 2**2 63c56 < 1 .dynsym 00005050 000025a8 000025a8 000025a8 2**2 --- > 1 .dynsym 000005d0 000002a8 000002a8 000002a8 2**2 65c58 < 2 .dynstr 00005203 000075f8 000075f8 000075f8 2**0 --- > 2 .dynstr 00000383 00000878 00000878 00000878 2**0 67c60 < 3 .gnu.version 00000a0a 0000c7fc 0000c7fc 0000c7fc 2**1 --- > 3 .gnu.version 000000ba 00000bfc 00000bfc 00000bfc 2**1 69c62 < 4 .gnu.version_r 000000e0 0000d208 0000d208 0000d208 2**2 --- > 4 .gnu.version_r 00000060 00000cb8 00000cb8 00000cb8 2**2 71c64 < 5 .rel.dyn 00009d58 0000d2e8 0000d2e8 0000d2e8 2**2 --- > 5 .rel.dyn 00000260 00000d18 00000d18 00000d18 2**2 73c66 < 6 .rel.plt 00001d38 00017040 00017040 00017040 2**2 --- > 6 .rel.plt 000001a0 00000f78 00000f78 00000f78 2**2 75c68 < 7 .init 00000017 00018d78 00018d78 00018d78 2**2 --- > 7 .init 00000017 00001118 00001118 00001118 2**2 77c70 < 8 .plt 00003a80 00018d90 00018d90 00018d90 2**2 --- > 8 .plt 00000350 00001130 00001130 00001130 2**2 79c72 < 9 .text 000c2b24 0001c810 0001c810 0001c810 2**4 --- > 9 .text 00005c84 00001480 00001480 00001480 2**4 81c74 < 10 .fini 0000001c 000df334 000df334 000df334 2**2 --- > 10 .fini 0000001c 00007104 00007104 00007104 2**2 83c76 < 11 .rodata 00020e68 000df360 000df360 000df360 2**5 --- > 11 .rodata 00000a8a 00007120 00007120 00007120 2**5 85c78 < 12 .eh_frame_hdr 000052cc 001001c8 001001c8 001001c8 2**2 --- > 12 .eh_frame_hdr 000001cc 00007bac 00007bac 00007bac 2**2 87c80 < 13 .eh_frame 00014978 00105494 00105494 00105494 2**2 --- > 13 .eh_frame 000006c4 00007d78 00007d78 00007d78 2**2 89c82 < 14 .ctors 00000008 0011a000 0011a000 0011a000 2**2 --- > 14 .ctors 00000008 00009000 00009000 00009000 2**2 91c84 < 15 .dtors 00000008 0011a008 0011a008 0011a008 2**2 --- > 15 .dtors 00000008 00009008 00009008 00009008 2**2 93c86 < 16 .jcr 00000004 0011a010 0011a010 0011a010 2**2 --- > 16 .jcr 00000004 00009010 00009010 00009010 2**2 95c88 < 17 .data.rel.ro 000000cc 0011a020 0011a020 0011a020 2**5 --- > 17 .data.rel.ro 00000004 00009014 00009014 00009014 2**2 97c90 < 18 .dynamic 000000d0 0011a0ec 0011a0ec 0011a0ec 2**2 --- > 18 .dynamic 000000d8 00009018 00009018 00009018 2**2 99c92 < 19 .got 0000036c 0011a1bc 0011a1bc 0011a1bc 2**2 --- > 19 .got 0000008c 000090f0 000090f0 000090f0 2**2 101c94 < 20 .got.plt 00000ea8 0011a528 0011a528 0011a528 2**2 --- > 20 .got.plt 000000dc 0000917c 0000917c 0000917c 2**2 103c96 < 21 .data 00023ce0 0011b3e0 0011b3e0 0011b3e0 2**5 --- > 21 .data 00000390 00009260 00009260 00009260 2**5 105c98 < 22 .bss 0000684c 0013f0c0 0013f0c0 0013f0c0 2**5 --- > 22 .bss 000008a4 00009600 00009600 000095f0 2**5 107c100 < 23 .gnu_debuglink 00000018 00000000 00000000 0013f0c0 2**2 --- > 23 .gnu_debuglink 00000018 00000000 00000000 000095f0 2**2 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Thu May 17 22:04:45 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 16:04:45 -0600 Subject: Looks like we need to rebuild some python packages. In-Reply-To: <464CBCA2.8050500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> Message-ID: <464CD17D.9090709@cora.nwra.com> Looks like the bad time frame for python packages is about Dec 8 -> Jan 6. python-enchant built on Jan 14 looks okay. Relevant python changelog: * Sat Jan 06 2007 Jeremy Katz - 2.5.3-8 - fix extensions to use shared libpython (#219564) - all 64bit platforms need the regex fix (#122304) Looks like all non-noarch python modules/apps built before 2.5.3-8 should be rebuilt. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Thu May 17 22:45:40 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 May 2007 16:45:40 -0600 Subject: Looks like we need to rebuild some python packages. In-Reply-To: <464CD17D.9090709@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <464CD17D.9090709@cora.nwra.com> Message-ID: <464CDB14.5040803@cora.nwra.com> Orion Poplawski wrote: > Looks like the bad time frame for python packages is about Dec 8 -> Jan > 6. python-enchant built on Jan 14 looks okay. > > Relevant python changelog: > > > * Sat Jan 06 2007 Jeremy Katz - 2.5.3-8 > - fix extensions to use shared libpython (#219564) > - all 64bit platforms need the regex fix (#122304) > > Looks like all non-noarch python modules/apps built before 2.5.3-8 > should be rebuilt. > > These are all the ones with "py" in the binary rpm name. Probably should check for BR python-devel or something. apt-0.5.15lorg3.2-9.fc7.src.rpm hamlib-1.2.5-4.fc7.src.rpm libpreludedb-0.9.11.1-2.fc7.src.rpm MySQL-python-1.2.1_p2-2.src.rpm notify-python-0.1.0-4.fc7.src.rpm OpenIPMI-2.0.6-7.fc7.src.rpm pybluez-0.9.1-3.fc7.src.rpm pyflowtools-0.3-8.fc7.src.rpm pyfribidi-0.6.0-3.fc7.src.rpm pygpgme-0.1-4.fc7.src.rpm pygsl-0.3.2-7.fc7.src.rpm pyOpenSSL-0.6-1.p24.9.src.rpm pypoker-eval-133.0-1.fc7.src.rpm python-adns-1.1.0-5.fc7.src.rpm python-alsaaudio-0.2-2.fc7.src.rpm python-CDDB-1.4-1.fc7.src.rpm python-chm-0.8.4-1.fc7.src.rpm python-durus-3.5-3.fc7.src.rpm python-GeoIP-1.2.1-6.fc7.src.rpm python-krbV-1.0.13-5.fc7.src.rpm python-ldap-2.2.0-3.src.rpm python-numarray-1.5.2-2.fc7.src.rpm python-psycopg-1.1.21-6.fc7.src.rpm python-pycurl-7.16.0-0.1.20061207.fc7.src.rpm python-quixote-2.4-5.fc7.src.rpm python-sexy-0.1.9-3.fc7.src.rpm python-smbpasswd-1.0.1-5.fc7.src.rpm python-twisted-conch-0.7.0-4.fc7.src.rpm python-twisted-core-2.4.0-6.fc7.src.rpm python-twisted-lore-0.2.0-4.fc7.src.rpm python-twisted-mail-0.3.0-4.fc7.src.rpm python-twisted-names-0.3.0-3.fc7.src.rpm python-twisted-runner-0.2.0-4.fc7.src.rpm python-twisted-web-0.6.0-4.fc7.src.rpm python-twisted-words-0.4.0-3.fc7.src.rpm python-zope-interface-3.0.1-7.fc7.src.rpm pyxmms-2.06-4.fc7.src.rpm -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rodd at clarkson.id.au Fri May 18 01:39:48 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 18 May 2007 11:39:48 +1000 Subject: rawhide report: changes In-Reply-To: <1179391329.30352.22.camel@rousalka.dyndns.org> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> Message-ID: <1179452388.3544.3.camel@localhost.localdomain> On Thu, 2007-05-17 at 10:42 +0200, Nicolas Mailhot wrote: > Le jeudi 17 mai 2007 ? 18:33 +1000, Rodd Clarkson a ?crit : > > > Along similar lines ... ? > > > > [rodd at localhost ~]$ sudo yum clean metadata > > Loading "installonlyn" plugin > > 17 metadata files removed > > [rodd at localhost ~]$ sudo yum update > > Loading "installonlyn" plugin > > Setting up Update Process > > development 100% |=========================| 1.1 kB 00:00 > > primary.xml.gz 100% |=========================| 2.6 MB 00:55 > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum > > If you're behind a (transparent or not) proxy you have to manually > forbid caching of repodata directories, else you'll periodically get > those messages. Yum metadata is not proxy-friendly (ie if you're behind > a corp proxy you're dead) > > Though for http mirrors we control the no-proxy rules should be done at > the http server level, and I hope yum is fixed someday I'm not behind any proxy that I'm aware of. R. -- "It's a fine line between denial and faith. It's much better on my side" From Axel.Thimm at ATrpms.net Fri May 18 01:45:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 May 2007 03:45:12 +0200 Subject: Missing mass rebuild starting to show? (was: Looks like we need to rebuild some python packages.) In-Reply-To: <464CD17D.9090709@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <464CD17D.9090709@cora.nwra.com> Message-ID: <20070518014512.GB3457@neu.nirvana> On Thu, May 17, 2007 at 04:04:45PM -0600, Orion Poplawski wrote: > Looks like the bad time frame for python packages is about Dec 8 -> Jan > 6. python-enchant built on Jan 14 looks okay. > > Relevant python changelog: > > > * Sat Jan 06 2007 Jeremy Katz - 2.5.3-8 > - fix extensions to use shared libpython (#219564) > - all 64bit platforms need the regex fix (#122304) > > Looks like all non-noarch python modules/apps built before 2.5.3-8 > should be rebuilt. Yet another reason for doing a mass rebuild at the end of the development cycle. Bad time windows of python, gcc and whatnot have always existed and will continue to do so. Sometimes we notice, sometimes not. That's the price for piecing together a distribution from different states of the environment from over 8 months. Oh and did I mention that changes in glibc (chownat) *run-time* broke the fakeroot packages as well? So much for glibc hasn't changed enough to warrant rebuilds. Mass rebuilds for F7 are out of the question now, but they should become mandatory for F8 again. Once towards the end of a development cycle before freezing. I just hope this isn't the tip of the iceberg, otherwise F7 will be re-codenamed Titanic. :( -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Fri May 18 02:38:51 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 17 May 2007 22:38:51 -0400 Subject: random thoughts on software installation In-Reply-To: <1179431143.15705.88.camel@neutron> References: <1179426193.15705.58.camel@neutron> <1179426856.19885.16.camel@erebor.boston.redhat.com> <1179427037.15705.63.camel@neutron> <1179427431.19885.23.camel@erebor.boston.redhat.com> <1179428603.3539.4.camel@rousalka.dyndns.org> <1179431143.15705.88.camel@neutron> Message-ID: <1179455931.24494.3.camel@rivendell> On Thu, 2007-05-17 at 15:45 -0400, Colin Walters wrote: > On Thu, 2007-05-17 at 21:03 +0200, Nicolas Mailhot wrote: > > I'm just trying to think about the kinds of things we can build on top > of those tools, especially when you consider targeting design for > particular audiences or particular classes of package. And also when > you consider things like more tightly integrating Fedora-the-software > with Fedora-the-website. > > Anyways I think my first example got too sidetracked by the specific > details of transactions or whatever...skvidal is doing some work on > search which should help in getting through Fedora's huge collection of > developer stuff. let's try this on yum 3.1.5 or higher grab: http://linux.duke.edu/~skvidal/useful-scripts/search-sorting.py and run: python search-sorting.py term1 term2 term3 term4 it should return the top ten hits matching those terms in order from most to least matches in a single package. that's a start, at least. -sv From fedora at camperquake.de Fri May 18 06:33:07 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 18 May 2007 08:33:07 +0200 Subject: Massive size increases in certain packages In-Reply-To: <464CCDD3.8020500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <20070517203539.GB6900@nostromo.devel.redhat.com> <464CC128.7020803@cora.nwra.com> <464CCB94.8020501@cora.nwra.com> <464CCDD3.8020500@cora.nwra.com> Message-ID: <20070518083307.7ff15c62@banea.int.addix.net> Hi. On Thu, 17 May 2007 15:49:07 -0600, Orion Poplawski wrote: > Here's a diff of the objdumps. Looks like different glibc versions > as well? > > < = big, > = small Could you please use unified diffs (-u) in the future? I find those below somewhat hard to read. Thanks. From j.w.r.degoede at hhs.nl Fri May 18 08:14:54 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 10:14:54 +0200 Subject: Massive size increases in certain packages In-Reply-To: <464CBCA2.8050500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> Message-ID: <464D607E.1050307@hhs.nl> Orion Poplawski wrote: > I did a quick compare of FE 6 to the last FE devel and found that the > following packages have increased in size by more than a factor of 2. > Some of these may be fine, I haven't looked into it in detail. > Thanks for the effort, however it looks like you've looked at the combined size of all subpackages of a package, for example ogre which is mine: > ogre 6374746 -> 29476134 Has a main package of only 2 Mb, most of the size increase is explained by the adding of a new samples sub package which ways in at 15Mb (previously the samples were unpackaged). The rest of the size increase seems to be due to errors in the way you've calculated the size, the FE6 ogre, excluding debuginfo ways in at 10 Mb (x86_64), the F7 one at 25 Mb. Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Fri May 18 08:08:50 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 18 May 2007 17:08:50 +0900 Subject: Massive size increases in certain packages In-Reply-To: <464CBCA2.8050500@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> Message-ID: <464D5F12.1050702@ioa.s.u-tokyo.ac.jp> Orion Poplawski wrote, at 05/18/2007 05:35 AM +9:00: > I did a quick compare of FE 6 to the last FE devel and found that the > following packages have increased in size by more than a factor of 2. > Some of these may be fine, I haven't looked into it in detail. > > wallpapoz 110963 -> 363890 Well, wallpapoz is maintained by me. During FE6->F7 wallpapoz version changed FE-6: 0.3-1.fc6 F-7: 0.4-0.5.rc2.fc7 (Currently I don't have a plan to update FE-6 wallpapoz to 0.4rc2) and actually the contents increased (with new function, translation, etc...). So for this package thereis no problem. BTW I like wallpapoz very much. Mamoru From mschwendt.tmp0701.nospam at arcor.de Fri May 18 09:05:57 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 18 May 2007 11:05:57 +0200 Subject: rawhide report: changes In-Reply-To: <464C979B.6020309@redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <20070517160706.GA1938@nostromo.devel.redhat.com> <464C979B.6020309@redhat.com> Message-ID: <20070518110557.a8a9654f.mschwendt.tmp0701.nospam@arcor.de> On Thu, 17 May 2007 11:57:47 -0600, Brendan Conoboy wrote: > Bill Nottingham wrote: > > The fix has been pushed to the mirror master and should propagate out soon. > > Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure. > > Also repomd.xml needs to be regenerated with primary.xml.gz's updated > sha1 sum. Is it intentional that the sqlite files are missing? From nicolas.mailhot at laposte.net Fri May 18 09:16:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 18 May 2007 11:16:48 +0200 Subject: random thoughts on software installation In-Reply-To: <3da3b5b40705171339r46746e3hbfb8c9be7c6d616c@mail.gmail.com> References: <1179426193.15705.58.camel@neutron> <3da3b5b40705171339r46746e3hbfb8c9be7c6d616c@mail.gmail.com> Message-ID: <1179479808.5137.16.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 23:39 +0300, Ahmed Kamal a ?crit : > Well, why not start integrating pre-configured "puppet recipes" You can already dump recipes and config samples in %doc Anything that tries to go further by adding an UI to blindly fill fields in those recipes is overengeneering. We have countless examples where this was tried and only resulted in very broken systems no one trusted. gconf is hated because of this and they started from a semi-sane structured file syntax designed to allow UI writing Just write good sample config files. Ping upstream so it sanitizes its config syntax. That's more work and less sexy than slapping an UI and worrying fonts and icons but it's the only successful approach. -- 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 than at than.com Fri May 18 09:29:26 2007 From: than at than.com (Than Ngo) Date: Fri, 18 May 2007 11:29:26 +0200 Subject: Conflict in /usr/lib/kde3/plugins/styles/keramik.so: In-Reply-To: References: Message-ID: <200705181129.26808.than@than.com> Am Donnerstag, 17. Mai 2007 schrieb Rex Dieter: > Neal Becker wrote: > > I ran this on current fc7test with all updates, on x86_64: > > > > kdiff3 idma-cdma idma-cdma.nbecker4 > > Conflict in /usr/lib/kde3/plugins/styles/keramik.so: > > Plugin uses incompatible Qt library! > > expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux > > g++-4.* full-config". > > > > What does this mean? > > > > BTW, I'm the kdiff3 maintainer, so maybe I need to do something? > > Funky wierd. > > it's 99% *not* kdiff3 at play here, it appears to be a multilib thing. > > I'd assume other kde apps would give the same warning/error, do they? If > so, bugzilla it against kdelibs. > It's a multilib problem on your machine. the problem is that you are using the Qt, build for x86_64, and kde plugins (in your case, keramik.so), built for i688. I caused this conflict. removing /usr/lib64/qt-3.3/etc/settings/qt_plugins_3.3rc and ~/.qt/qt_plugins_3.3rc should perhaps fix the problem. Than From nicolas.mailhot at laposte.net Fri May 18 09:31:23 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 18 May 2007 11:31:23 +0200 Subject: rawhide report: changes In-Reply-To: <1179452388.3544.3.camel@localhost.localdomain> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> <1179452388.3544.3.camel@localhost.localdomain> Message-ID: <1179480683.5137.18.camel@rousalka.dyndns.org> Le vendredi 18 mai 2007 ? 11:39 +1000, Rodd Clarkson a ?crit : > I'm not behind any proxy that I'm aware of. Transparent proxys are not always advertised -- 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 ndbecker2 at gmail.com Fri May 18 10:04:29 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 18 May 2007 06:04:29 -0400 Subject: emacs glibc corruption with glibc-2.6-1 Message-ID: emacs-23.0.0.1 now won't even start. emacs *** glibc detected *** emacs: malloc(): memory corruption: 0x00000000016f3860 *** From dev at nigelj.com Fri May 18 10:09:53 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 18 May 2007 22:09:53 +1200 Subject: emacs glibc corruption with glibc-2.6-1 In-Reply-To: References: Message-ID: <464D7B71.3060905@nigelj.com> Neal Becker wrote: > emacs-23.0.0.1 now won't even start. > emacs > *** glibc detected *** emacs: malloc(): memory corruption: 0x00000000016f3860 *** > > Already known, and well discussed on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344 N.J. From rjones at redhat.com Fri May 18 13:27:11 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 18 May 2007 14:27:11 +0100 Subject: Proposal ocaml guidelines In-Reply-To: <1178208140.5401.3.camel@localhost.localdomain> References: <4638E087.60102@hhs.nl> <1178208140.5401.3.camel@localhost.localdomain> Message-ID: <464DA9AF.7060306@redhat.com> I had a go at producing a package for findlib: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240557 Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From kevin.kofler at chello.at Fri May 18 13:57:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 May 2007 13:57:31 +0000 (UTC) Subject: random thoughts on software installation References: <1179426193.15705.58.camel@neutron> Message-ID: Colin Walters redhat.com> writes: > For the first part - developer software, my ideal tool would look > something like this. Just a search box, and a list of result hits. > Like a web search engine basically. > /----- > | Search: [ ssh python ] > | > | Package: python-paramiko _Install_ > | "Paramiko is an implementation of ssh for Python..." > | > | Package: openssh _Install_ > | - /usr/bin/ssh > \----- > Searches descriptions and names too. This is essentially how Synaptic works already. Searching ssh python on an FC6 system gives you: cobbler, denyhosts, pexpect, python-paramiko, python-twisted-conch, rdiff-backup. > /----- > | Search: [ hg ] > | > | Package: mercurial _Install_ > | - /usr/bin/hg > | > \----- > Searches executable names > > /----- > | Search: [ db.h ] > | > | Package: libdb2-devel _Install_ > | - /usr/include/db2/db.h > | > | Package: libdb3-devel _Install_ > | - /usr/include/db3/db.h > \----- > Searches files. Those 2 are essentially the same thing. Unfortunately, Synaptic won't help you here, but this works: repoquery -f /usr/bin/hg as does this: repoquery --whatprovides /usr/bin/hg However, both these only work by full path name, searching for just db.h won't work. But I think all this could easily be done with the already-available RPM and repomd infrastructure, which already contains full file lists for all packages in the repositories. No new packaging system needed, no additions to the repository even, just some work on the client side. (In fact, you could even write a shell script which does a repoquery -a, then repoquery -l on all the results, and greps for the file name in this. But it's a lot faster faster if you read the metadata in only once, of course.) Kevin Kofler From cdhouch at gmail.com Fri May 18 14:30:49 2007 From: cdhouch at gmail.com (Caerie Houchins) Date: Fri, 18 May 2007 09:30:49 -0500 Subject: rawhide report: changes In-Reply-To: <1179480683.5137.18.camel@rousalka.dyndns.org> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> <1179452388.3544.3.camel@localhost.localdomain> <1179480683.5137.18.camel@rousalka.dyndns.org> Message-ID: perl-libs wasn't downloaded automatically for me in todays update so everything was complaining it couldn't find libperl.so. Should perl-libs be added to the Requirements for the perl package now that libperl.so is split out? -- Caerie Houchins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt.tmp0701.nospam at arcor.de Fri May 18 15:11:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 18 May 2007 17:11:26 +0200 Subject: rawhide report: changes In-Reply-To: References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <1179391329.30352.22.camel@rousalka.dyndns.org> <1179452388.3544.3.camel@localhost.localdomain> <1179480683.5137.18.camel@rousalka.dyndns.org> Message-ID: <20070518171126.704dc6c9.mschwendt.tmp0701.nospam@arcor.de> On Fri, 18 May 2007 09:30:49 -0500, Caerie Houchins wrote: > perl-libs wasn't downloaded automatically for me in todays update so > everything was complaining it couldn't find libperl.so. Should perl-libs be > added to the Requirements for the perl package now that libperl.so is split > out? Dependencies on shared library SONAMEs are automatic. Please state details about the issues you've seen. Also, do you refer to x86_64? From jkeating at redhat.com Fri May 18 15:16:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 11:16:53 -0400 Subject: rawhide report: changes In-Reply-To: References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179480683.5137.18.camel@rousalka.dyndns.org> Message-ID: <200705181116.53823.jkeating@redhat.com> On Friday 18 May 2007 10:30:49 Caerie Houchins wrote: > perl-libs wasn't downloaded automatically for me in todays update so > everything was complaining it couldn't find libperl.so. ?Should perl-libs > be added to the Requirements for the perl package now that libperl.so is > split out? I can't duplicate this on either my i386 nor my x86_64 system. Both with plain 'yum update' and with a targetted 'yum update perl' pull in perl-libs as a dep. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cdhouch at gmail.com Fri May 18 15:40:18 2007 From: cdhouch at gmail.com (Caerie Houchins) Date: Fri, 18 May 2007 10:40:18 -0500 Subject: rawhide report: changes In-Reply-To: <200705181116.53823.jkeating@redhat.com> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179480683.5137.18.camel@rousalka.dyndns.org> <200705181116.53823.jkeating@redhat.com> Message-ID: On 5/18/07, Jesse Keating wrote: > > On Friday 18 May 2007 10:30:49 Caerie Houchins wrote: > > perl-libs wasn't downloaded automatically for me in todays update so > > everything was complaining it couldn't find libperl.so. Should perl-libs > > be added to the Requirements for the perl package now that libperl.so is > > split out? > > I can't duplicate this on either my i386 nor my x86_64 system. Both with > plain 'yum update' and with a targetted 'yum update perl' pull in > perl-libs > as a dep. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Nope I'm on the x86 32 bit version. All I did this morning was a plain 'yum update' to match up to rawhide. Afterwards I did not have the perl-libs package installed and things that depended on libperl.so were complaining. I wish I had more details for you but I didn't capture any real logs during the yum update process. This laptop was upgraded from FC6 to FC7T4 and then kept in sync with rawhide since then. -- Caerie Houchins -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri May 18 16:18:42 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 18 May 2007 10:18:42 -0600 Subject: Massive size increases in certain packages In-Reply-To: <464D607E.1050307@hhs.nl> References: <464CBCA2.8050500@cora.nwra.com> <464D607E.1050307@hhs.nl> Message-ID: <464DD1E2.5080900@cora.nwra.com> Hans de Goede wrote: > Orion Poplawski wrote: >> I did a quick compare of FE 6 to the last FE devel and found that the >> following packages have increased in size by more than a factor of 2. >> Some of these may be fine, I haven't looked into it in detail. >> > > Thanks for the effort, however it looks like you've looked at the > combined size of all subpackages of a package, for example ogre which is > mine: > >> ogre 6374746 -> 29476134 > > Has a main package of only 2 Mb, most of the size increase is explained > by the adding of a new samples sub package which ways in at 15Mb > (previously the samples were unpackaged). > > The rest of the size increase seems to be due to errors in the way > you've calculated the size, the FE6 ogre, excluding debuginfo ways in at > 10 Mb (x86_64), the F7 one at 25 Mb. I'm not looking at the size of the rpms, I'm looking at installed sizes as reported by rpm -q --qf "%{SIZE}\n" -p . # rpm -q --qf '%{SIZE}\n' -p development/i386/ogre-1.2.5-1.fc7.i386.rpm 29476134 # rpm -q --qf '%{SIZE}\n' -p 6/i386/ogre-1.2.2-2.p1.fc6.i386.rpm 6374746 I installed ogre on my devel system however and the total installed size appears to be about 8476 KB. So perhaps a bug in rpm's size calculation? # rpm -ql ogre | xargs du -k | sort -n | awk '{ tot+=$1 }; END { print tot }' 8476 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From poelstra at redhat.com Fri May 18 16:47:25 2007 From: poelstra at redhat.com (John Poelstra) Date: Fri, 18 May 2007 09:47:25 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-May-14 Message-ID: <464DD89D.3020603@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-may-14 Please make corrections and clarifications to the wiki page. == Rawhide == * Notting put a lot of work into getting rawhide to build again--see IRC log for how it works * Discussion of mash and future rawhide building plans == Current Issues and Freeze Status == * we agreed last week to revisit this week. * are we ready to freeze on Thursday? * discussion of packages causing problems 1. beagle * re-evaluate beagle and tracker for F8 * bug #217031 * maintainer made changes to comps * DECISION (UNANIMOUS): Accept maintainer's comps change, making beagle optional. Include it in manifest so that it is on media for upgrades. 1. wireless-tools * newest wireless-tools has a patch that's supposed to fix 64-bit that actually breaks all wireless scanning on 64-bit systems. * https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html * warren will drive issue to conclusion * we not only need x86_64 testers, but also ppc and i386 to be sure the 64bit fix didn't break 32bit. * DECISION (UNANIMOUS): If that -3 build turns out to be No Good then we just revert the 64-bit patches entirely and call that -3 (or -4 or whatever) 1. hal * wwoods--hal-0.5.9-6.fc7 fixed the suspend/resume quirks for some stuff (T60 maybe?), but broke it for others (my pitiable t43) * without passing the quirks there's no way suspend to work on large classes of laptops * ACTION: jeremy will try to get hughsie to take a look--davidz won't be back until the 20th. 1. mdraid * wwoods--the old raidautorun stuff + IDE = doooom * wwoods will enage Peter Jones * realy need IDE drives to do good testing * lots of bugs; BZ: 151653, 231426, 238353, 221696, 213586, 238926 * wwoods--never tested dmraid because no hardware; f13 is going to test now * DECISION: None reached * we should direct new packages to updates, not the final tree. * f13 will announce and update the freeze/release dates * everything must be done and ready for GA on 29-MAY-07 == Outstanding GA Blocker Bugs == * 81 bugs still on the fc7blocker * http://fedoraproject.org/wiki/QA/ReleaseCriteria provides guidance on release blockers * DECISION (UNANIMOUS): * Blocker only fixes starting Thursday (branch CVS same day) * Broken EVR paths and broken deps (including from the Merge) in the entire distro must be fixed before GA * wwoods to add this to release criteria == EULA == * EULA only available online; not in the distro * http://fedoraproject.org/wiki/Legal/Licenses/EULA From jspaleta at gmail.com Fri May 18 17:20:43 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 18 May 2007 09:20:43 -0800 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <464B5F85.8070100@redhat.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> <464B5F85.8070100@redhat.com> Message-ID: <604aa7910705181020v554a7482w25dff85ff4eff3eb@mail.gmail.com> On 5/16/07, Peter Jones wrote: > Yeah, I've seen that happen sometimes, but haven't yet had a chance to > hunt down why. Can you reproduce it consistently? If so, does > dissabling /apps/gnome-power-manager/networkmanager_sleep in gconf make > it better? Disabling networkmanager_sleep appears to have fixed the issue with the wired network on resume from suspend. With that change, the suspend/resume on the T60 while in the dock using wired networking appears to work flawlessly. Now on to testing more salient permutations of dock and network. -jef"It makes perfect sense that the suspend/resume is working flawlessly for the one case that i really don't need suspend to work in."spaleta From j.w.r.degoede at hhs.nl Fri May 18 17:36:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 19:36:36 +0200 Subject: Massive size increases in certain packages In-Reply-To: <464DD1E2.5080900@cora.nwra.com> References: <464CBCA2.8050500@cora.nwra.com> <464D607E.1050307@hhs.nl> <464DD1E2.5080900@cora.nwra.com> Message-ID: <464DE424.6080407@hhs.nl> Orion Poplawski wrote: > Hans de Goede wrote: >> Orion Poplawski wrote: >>> I did a quick compare of FE 6 to the last FE devel and found that the >>> following packages have increased in size by more than a factor of 2. >>> Some of these may be fine, I haven't looked into it in detail. >>> >> >> Thanks for the effort, however it looks like you've looked at the >> combined size of all subpackages of a package, for example ogre which >> is mine: >> >>> ogre 6374746 -> 29476134 >> >> Has a main package of only 2 Mb, most of the size increase is >> explained by the adding of a new samples sub package which ways in at >> 15Mb (previously the samples were unpackaged). >> >> The rest of the size increase seems to be due to errors in the way >> you've calculated the size, the FE6 ogre, excluding debuginfo ways in >> at 10 Mb (x86_64), the F7 one at 25 Mb. > > I'm not looking at the size of the rpms, I'm looking at installed sizes > as reported by rpm -q --qf "%{SIZE}\n" -p . > > # rpm -q --qf '%{SIZE}\n' -p development/i386/ogre-1.2.5-1.fc7.i386.rpm > 29476134 > # rpm -q --qf '%{SIZE}\n' -p 6/i386/ogre-1.2.2-2.p1.fc6.i386.rpm > 6374746 > > I installed ogre on my devel system however and the total installed size > appears to be about 8476 KB. So perhaps a bug in rpm's size calculation? > Perhaps, or maybe rpm is showing the size of all subpackages together? Regards, Hans From wtogami at redhat.com Fri May 18 17:48:36 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 18 May 2007 13:48:36 -0400 Subject: Pidgin Plan for FC-6 Message-ID: <464DE6F4.5000907@redhat.com> FC-5 will remain with gaim-1.5.0 and upgrade into pidgin-1.5.X if necessary for a security update. FC-6 will upgrade to pidgin-2.0.0 to match the F7 version. Unfortunately this will be a bumpy ride due to various factors: - pidgin would need to be built and pushed in FE-6 in order to build against stuff in Extras, instead of FC-6 like gaim. This currently means no updates-testing is possible. - This would break nautilus-sendto which links against gaim in Core. We dealt with this in F7 by temporarily disabling the link to gaim from nautilus-sendto until the merge. We could do the same thing here. nautilus-sendto can regain the ability to Send To Pidgin after FC-6 is merged. - Ready plugins: meanwhile (built by main pidgin package), otr (fixed and built againnst pidgin, but confusingly still named gaim-otr... that should be fixed proactively and allow upstream to follow later IMHO.) - A few plugins in process: gaym, galago, libnotify, guifications. cweyl and nosnilmot are attempting to get the plugins fixed ASAP. It isn't exactly helping that upstream isn't cooperating... Out of all the broken plugins, only gaym is an actual protocol and fairly close to getting fixed. The others are less important to the function of pidgin... will only cause temporary annoyance. Proposal ======== 1) Push pidgin-2.0.0 to FE-6 ASAP. Suddenly broken plugins will be a kick-in-the-ass to get themselves fixed sooner. 2) Allow the remaining plugin packages to follow. 3) After FC-6 is merged, rehook nautilus-sendto into pidgin. I don't think we should leave gaim in FC-6 stagnant anymore. JUST DOING IT at this point wont be so painful to existing users, perhaps only a little annoying. Any objections? Warren Togami wtogami at redhat.com From pjones at redhat.com Fri May 18 18:01:20 2007 From: pjones at redhat.com (Peter Jones) Date: Fri, 18 May 2007 14:01:20 -0400 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <604aa7910705181020v554a7482w25dff85ff4eff3eb@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> <464B5F85.8070100@redhat.com> <604aa7910705181020v554a7482w25dff85ff4eff3eb@mail.gmail.com> Message-ID: <464DE9F0.10609@redhat.com> Jeff Spaleta wrote: > On 5/16/07, Peter Jones wrote: >> Yeah, I've seen that happen sometimes, but haven't yet had a chance to >> hunt down why. Can you reproduce it consistently? If so, does >> dissabling /apps/gnome-power-manager/networkmanager_sleep in gconf make >> it better? > > Disabling networkmanager_sleep appears to have fixed the issue with > the wired network on resume from suspend. With that change, the > suspend/resume on the T60 while in the dock using wired networking > appears to work flawlessly. Now on to testing more salient > permutations of dock and network. > > -jef"It makes perfect sense that the suspend/resume is working > flawlessly for the one case that i really don't need suspend to work > in."spaleta Richard, is there a good reason g-p-m is still doing this? It seems to be a relic from the days before pm-utils. Can we kill it? -- Peter From notting at redhat.com Fri May 18 18:15:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 May 2007 14:15:31 -0400 Subject: rawhide report: changes In-Reply-To: <20070518110557.a8a9654f.mschwendt.tmp0701.nospam@arcor.de> References: <200705170640.l4H6eNbl019194@porkchop.devel.redhat.com> <1179390800.3544.0.camel@localhost.localdomain> <20070517160706.GA1938@nostromo.devel.redhat.com> <464C979B.6020309@redhat.com> <20070518110557.a8a9654f.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070518181531.GA19544@nostromo.devel.redhat.com> Michael Schwendt (mschwendt.tmp0701.nospam at arcor.de) said: > > Also repomd.xml needs to be regenerated with primary.xml.gz's updated > > sha1 sum. > > Is it intentional that the sqlite files are missing? No, but that won't be fixed until the push after the current one Bill From kevin.kofler at chello.at Fri May 18 18:48:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 May 2007 18:48:44 +0000 (UTC) Subject: X-Chat in Fedora Message-ID: I have noticed that Christopher Aillon seems to be way too busy to keep X-Chat up to date in Fedora. See for example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224180 (which is too late to get into the F7 release now, unfortunately (sigh, I opened this 4 months ago when 2.8.0 was current!), but it could go into updates). He hasn't even replied to this bug report. Now that Core and Extras have merged, would it be possible to get a community comaintainer (or even maintainer) for this package? Seeing how R?mi Collet has been keeping X-Chat up to date in his repository and how his updated versions have always worked fine for me, I think he would be a good comaintainer or maintainer for X-Chat (if he accepts, of course). Kevin Kofler From a.badger at gmail.com Fri May 18 18:58:21 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 18 May 2007 11:58:21 -0700 Subject: Massive size increases in certain packages In-Reply-To: <464DE424.6080407@hhs.nl> References: <464CBCA2.8050500@cora.nwra.com> <464D607E.1050307@hhs.nl> <464DD1E2.5080900@cora.nwra.com> <464DE424.6080407@hhs.nl> Message-ID: <1179514701.26613.35.camel@localhost.localdomain> On Fri, 2007-05-18 at 19:36 +0200, Hans de Goede wrote: > Orion Poplawski wrote: > > I'm not looking at the size of the rpms, I'm looking at installed sizes > > as reported by rpm -q --qf "%{SIZE}\n" -p . > > > > # rpm -q --qf '%{SIZE}\n' -p development/i386/ogre-1.2.5-1.fc7.i386.rpm > > 29476134 > > # rpm -q --qf '%{SIZE}\n' -p 6/i386/ogre-1.2.2-2.p1.fc6.i386.rpm > > 6374746 > > > > I installed ogre on my devel system however and the total installed size > > appears to be about 8476 KB. So perhaps a bug in rpm's size calculation? > > > > Perhaps, or maybe rpm is showing the size of all subpackages together? > It's a bug in rpm. Namely, these lines from ogre.spec are throwing things off: %exclude %{_bindir}/Ogre-Samples %exclude %{_libdir}/OGRE/Samples %exclude %{_datadir}/OGRE/Samples Rpm's size calculation doesn't properly handle %exclude. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Fri May 18 19:02:58 2007 From: buildsys at redhat.com (Build System) Date: Fri, 18 May 2007 15:02:58 -0400 Subject: rawhide report: 20070518 changes Message-ID: <200705181902.l4IJ2wq8015807@porkchop.devel.redhat.com> From kevin.kofler at chello.at Fri May 18 19:02:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 May 2007 19:02:35 +0000 (UTC) Subject: X-Chat in Fedora References: Message-ID: By the way, while I hope we don't have to go to this point (Christopher Aillon, I know you're still around, could you please reply to the bug report?), does this policy apply in the new merged world? http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Or if not, what IS the policy now? Kevin Kofler From buildsys at redhat.com Fri May 18 19:06:14 2007 From: buildsys at redhat.com (Build System) Date: Fri, 18 May 2007 15:06:14 -0400 Subject: rawhide report: 20070518 changes Message-ID: <200705181906.l4IJ6EXE015872@porkchop.devel.redhat.com> New package perl-Archive-Any Single interface to deal with file archives New package perl-CGI-Prototype Create a CGI application by subclassing New package perl-Catalyst-Plugin-ConfigLoader Load config files of various types New package perl-Catalyst-Runtime Catalyst core modules New package perl-Class-Base Useful base class for deriving other modules New package perl-Class-C3-XS XS speedups for Class::C3 New package perl-Class-Data-Accessor Inheritable, overridable class and instance data accessor creation New package perl-Data-Visitor Visitor style traversal of Perl data structures New package perl-Declare-Constraints-Simple Declarative Validation of Data Structures New package perl-File-Modified Checks intelligently if files have changed New package perl-JSON-XS JSON serialising/deserialising, done correctly and fast New package perl-MooseX-Getopt Moose role for processing command line options New package perl-Text-SimpleTable Simple Eyecandy ASCII Tables New package perl-Text-TabularDisplay Display text in formatted table output New package referencer A document organiser and bibliography manager for Gnome New package xfce4-places-plugin Places menu for the Xfce panel New package xfce4-verve-plugin A comfortable command line plugin for the Xfce panel Updated Packages: anaconda-11.2.0.60-1 -------------------- * Wed May 16 2007 Chris Lumens - 11.2.0.60-1 - Add yum logger (katzj, #240226). - Fix up Bulgarian keyboard support (#240087). - Fix text mode language selection tracebacks. autodownloader-0.2.0-2.fc7 -------------------------- bitlbee-1.0.3-6.fc7 ------------------- * Mon May 07 2007 Robert Scheck 1.0.3-6 - Rebuilt dejavu-fonts-2.17-1.fc7 ----------------------- * Sun May 13 2007 Nicolas Mailhot ??? 2.17-1 ??? rebase scriptlets from guidelines ??? fontforge broke compat: BR the current version, ask for a version bump before 2.18 is released ??? simplify font directory naming ??? clean up fc5 obsoletes ??? remove technical mes files from doc * Fri May 11 2007 Nicolas Mailhot ??? 2.17-0.3.rc1 ??? fontconfig setup has stabilized and can be marked noreplace now ??? 2.17-0.2.rc1 ??? mimick Vera unhint conf split ??? 2.17-0.1.rc1 ??? 2.17 rc1 ??? make room for liberations font conf file duplicity-0.4.2-7.fc7 --------------------- * Mon May 07 2007 Robert Scheck 0.4.2-7 - Rebuild eggdrop-1.6.18-8.fc7 -------------------- * Mon May 07 2007 Robert Scheck 1.6.18-8 - Rebuild emacs-vm-7.19.devo282-11.fc7 ---------------------------- * Thu May 17 2007 Jonathan G. Underwood - 7.19.devo282-11 - Fix missnaming of startup file - Fix changelog entry gxine-0.5.11-4.fc7 ------------------ * Wed May 16 2007 Martin Sourada - 0.5.11-4 - rebuild to include ppc64 arch hal-info-20070516-2.fc7 ----------------------- jakarta-commons-dbcp-0:1.2.1-10jpp.1.fc7 ---------------------------------------- * Mon Mar 12 2007 Matt Wringe 0:1.2.1-10jpp.1 - Merger with newest jpp version - Fix rpmlint issues - Disable testThreaded for now as it will sometimes fail * Fri Feb 23 2007 Jason Corley 0:1.2.1-10jpp - update copyright to contain current year - rebuild on RHEL4 to avoid broken jar repack script in FC6 * Fri Jan 26 2007 Matt Wringe 0:1.2.1-9jpp - Fix bug in dbcp-tomcat5-build.xml jokosher-0.9-1.fc7 ------------------ * Wed May 16 2007 Christopher Brown - 0.9-1 - 0.9 final * Sat Apr 21 2007 Christopher Brown - 0.9-0.3.rc1 - rc1 - remove redundant directories * Thu Apr 05 2007 Christopher Brown - 0.9-0.2.20070405svn - update to svn 20070405 - added python macros krb5-1.6-6 ---------- * Wed May 16 2007 Nalin Dahyabhai 1.6-6 - omit dependent libraries from the krb5-config --libs output, as using shared libraries (no more static libraries) makes them unnecessary and they're not part of the libkrb5 interface (patch by Rex Dieter, #240220) (strips out libkeyutils, libresolv, libdl) * Fri May 04 2007 Nalin Dahyabhai 1.6-5 - pull in keyutils as a build requirement to get the "KEYRING:" ccache type, because we've merged * Fri May 04 2007 Nalin Dahyabhai 1.6-4 - fix an uninitialized length value which could cause a crash when parsing key data coming from a directory server - correct a typo in the krb5.conf man page ("ldap_server"->"ldap_servers") libopm-0.1-4.20050731cvs.fc7 ---------------------------- * Mon May 07 2007 Robert Scheck 0.1-4.20050731cvs - Rebuild librsync-0.9.7-10.fc7 --------------------- * Mon May 07 2007 Robert Scheck 0.9.7-10 - rebuilt loudmouth-1.2.2-3.fc7 --------------------- * Wed May 16 2007 Brian Pepple - 1.2.2-3 - Add patch to fix stream error. mimedefang-2.62-2.fc7 --------------------- * Mon May 07 2007 Robert Scheck 2.62-2 - Changed sendmail build requirement slightly (#237157) perl-4:5.8.8-18.fc7 ------------------- * Wed May 16 2007 Robin Norwood - 4:5.8.8-18 - Have perl-devel Require the other development/build related modules for simplicity. * Fri May 04 2007 Robin Norwood - 4:5.8.8-17 - Includes patch from Ralf Corsepius to split out some more perl modules. - Further split out development related perl modules. - Remove Requires: perl-devel from perl - Move libperl.so -> perl-libs - Patch39 to disable test_hosts in Net::Config * Fri Mar 09 2007 Robin Norwood - 4:5.8.8-15 - Incorporate fixes from spot and others on fedora-perl-devel - The main perl package will temporarily Require perl-devel - move ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, Test::Harness into devel - also move perlcc, perlivp, h2xs, libnetcfg to devel perl-Net-LibIDN-0.09-3.fc7 -------------------------- * Mon May 07 2007 Robert Scheck 0.09-3 - Rebuild perl-Params-Util-0.24-1.fc7 --------------------------- * Mon May 14 2007 Ralf Cors??pius - 0.24-1 - Upstream update. php-idn-1.2-2.fc7 ----------------- * Mon May 07 2007 Robert Scheck 1.2-2 - Rebuild pm-utils-0.99.3-5.fc7 --------------------- * Wed May 16 2007 Peter Jones - 0.99.3-5 - ... and create the directory the logfile goes in. * Wed May 16 2007 Peter Jones - 0.99.3-4 - Bump release to appease Koji. * Wed May 16 2007 Peter Jones - 0.99.3-3 - Create logfile in %post and %gost it. policycoreutils-2.0.16-2.fc7 ---------------------------- * Thu May 17 2007 Dan Walsh 2.0.16-2 - Fixes for polgentool templates file redhat-artwork-7.0.0-9.fc7 -------------------------- * Wed May 16 2007 Matthias Clasen 7.0.0-9 - Add a timed-login label to the gdm login screen rhpl-0.206-1 ------------ * Wed May 16 2007 Chris Lumens - 0.206-1 - Use the correct Bulgarian keyboard layout (#238345, #240087). - Fix Pegasos platform detection (#237413). selinux-policy-2.6.4-6.fc7 -------------------------- * Thu May 17 2007 Dan Walsh 2.6.4-6 - allow alsactl to read kernel state * Wed May 16 2007 Dan Walsh 2.6.4-5 - More fixes for alsactl - Transition from hal and modutils - Fixes for suspend resume. - insmod domtrans to alsactl - insmod writes to hal log * Wed May 16 2007 Dan Walsh 2.6.4-2 - Allow unconfined_t to transition to NetworkManager_t - Fix netlabel policy sonata-1.1-1.fc7 ---------------- * Wed May 09 2007 Micha?? Bentkowski - 1.1-1 - Update to 1.1 strigi-0.5.1-5.fc7 ------------------ * Wed May 16 2007 Deji Akingunola - 0.5.1-5 - Split out a strigi-libs subpackage as suggested in BZ#223586 _ Include a strigidaemon autostart desktop file tcpick-0.2.1-12.fc7 ------------------- * Mon May 07 2007 Robert Scheck 0.2.1-12 - Rebuilt tomcat5-0:5.5.23-9jpp.2.fc7 --------------------------- * Wed May 16 2007 Vivek Lakshmanan 0:5.5.23-9jpp.2 - Add requires(post) on j-c-*-tomcat5 in tomcat5 package to ensure proper ordering at installation time - Replace more references to ecj with eclipse-ecj * Tue May 15 2007 Vivek Lakshmanan 0:5.5.23-9jpp.1 - Resolve: bug 240242 - Import and merge 0:5.5.23-9jpp from JPP - Fix formatting of spec - Use eclipse-ecj in place of ecj - Apply GCJ specific patches - Use generic jta for now instead of geronimo-jta-1.0.1B-api - Add tomcat-juli.jar since gcc bug 29869 is fixed * Fri May 11 2007 Jason Corley 0:5.5.23-9jpp - rebuild through mock and centos 4 vorbis-tools-1:1.1.1.svn20070412-2.fc7 -------------------------------------- * Wed May 16 2007 Christopher Aillon 1:1.1.1.svn20070412-2.fc7 - Bring back support for http URLs which was broken with the previous update See https://bugzilla.redhat.com/240351 wine-0.9.36-2.fc7 ----------------- * Wed May 02 2007 Andreas Bierfert 0.9.36-2 - fix BR (#238774) - fix some typos yum-3.2.0-1.fc7 --------------- * Wed May 16 2007 Seth Vidal - 3.2.0-1 - pull out yum-misc-fixes patch - bump to 3.2.0 From hughsient at gmail.com Fri May 18 19:06:54 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 18 May 2007 20:06:54 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <464DE9F0.10609@redhat.com> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179338276.8294.2.camel@metroid.rdu.redhat.com> <604aa7910705161101g4d9859b2p336f9026caedb4bc@mail.gmail.com> <604aa7910705161117n32c642cdo15af2bba7629391a@mail.gmail.com> <464B5F85.8070100@redhat.com> <604aa7910705181020v554a7482w25dff85ff4eff3eb@mail.gmail.com> <464DE9F0.10609@redhat.com> Message-ID: <1179515214.2880.8.camel@localhost.localdomain> On Fri, 2007-05-18 at 14:01 -0400, Peter Jones wrote: > Jeff Spaleta wrote: > > On 5/16/07, Peter Jones wrote: > >> Yeah, I've seen that happen sometimes, but haven't yet had a chance to > >> hunt down why. Can you reproduce it consistently? If so, does > >> dissabling /apps/gnome-power-manager/networkmanager_sleep in gconf make > >> it better? > > > > Disabling networkmanager_sleep appears to have fixed the issue with > > the wired network on resume from suspend. With that change, the > > suspend/resume on the T60 while in the dock using wired networking > > appears to work flawlessly. Now on to testing more salient > > permutations of dock and network. > > > > -jef"It makes perfect sense that the suspend/resume is working > > flawlessly for the one case that i really don't need suspend to work > > in."spaleta > > Richard, is there a good reason g-p-m is still doing this? It seems to > be a relic from the days before pm-utils. Can we kill it? Yes we can stop doing this now - do you want me to just change the default gconf entry, or just kill the code completely? Richard. From caillon at redhat.com Fri May 18 19:07:37 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 18 May 2007 15:07:37 -0400 Subject: X-Chat in Fedora In-Reply-To: References: Message-ID: <464DF979.9060607@redhat.com> Kevin Kofler wrote: > I have noticed that Christopher Aillon seems to be way too busy to keep X-Chat More recalcitrant here than busy. I've been waiting for the merge to happen to find it a new home since nobody has been willing to take it from me. I lost interest when the patches to support multiline as per CTCP have taken ages to get committed upstream and I think it was rejected finally and I got bored of constantly merging it back in. Maybe someone can resurrect and champion it in. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136545 http://sourceforge.net/tracker/index.php?func=detail&atid=100239&aid=1051098&group_id=239 > up to date in Fedora. See for example: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224180 > (which is too late to get into the F7 release now, unfortunately (sigh, I > opened this 4 months ago when 2.8.0 was current!), but it could go into > updates). He hasn't even replied to this bug report. Now that Core and Extras > have merged, would it be possible to get a community comaintainer (or even > maintainer) for this package? Seeing how R?mi Collet has been keeping X-Chat up > to date in his repository and how his updated versions have always worked fine > for me, I think he would be a good comaintainer or maintainer for X-Chat (if he > accepts, of course). Sure, I'll accept a co-maintainer for now in good faith if someone wants it. The above patch would be great to get back into xchat and would give me some reason to start caring again. Any one want to step to the plate? From jspaleta at gmail.com Fri May 18 19:35:33 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 18 May 2007 11:35:33 -0800 Subject: X-Chat in Fedora In-Reply-To: <464DF979.9060607@redhat.com> References: <464DF979.9060607@redhat.com> Message-ID: <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> On 5/18/07, Christopher Aillon wrote: > Any one want to step to the plate? on a side note.... now that we are post merge we have xchat and xchat-gnome in the same repo. Would it be that horrible if xchat fell out of the repo? Is xchat-gnome upstream more responsive to patching? -jef"I'm an xchat user, but i no real reason to prefer xchat over xchat-gnome or vice versa"spaleta From wtogami at redhat.com Fri May 18 19:37:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 18 May 2007 15:37:22 -0400 Subject: X-Chat in Fedora In-Reply-To: References: Message-ID: <464E0072.2070309@redhat.com> I took a look at upgrading xchat in rawhide to a more recent version, but I gave up when newer versions broke IM (scim and XIM) input which would be an unacceptable regression to ship in Fedora. Perhaps newer versions have fixed that issue. Warren Togami wtogami at redhat.com From jwboyer at jdub.homelinux.org Fri May 18 19:43:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 14:43:12 -0500 Subject: X-Chat in Fedora In-Reply-To: <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> Message-ID: <1179517392.3046.21.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 11:35 -0800, Jeff Spaleta wrote: > On 5/18/07, Christopher Aillon wrote: > > Any one want to step to the plate? > > on a side note.... now that we are post merge we have xchat and > xchat-gnome in the same repo. Would it be that horrible if xchat fell > out of the repo? Is xchat-gnome upstream more responsive to patching? Yes, it would be very very horrible. I hate xchat-gnome. josh From kevin.kofler at chello.at Fri May 18 19:48:01 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 May 2007 19:48:01 +0000 (UTC) Subject: X-Chat in Fedora References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > on a side note.... now that we are post merge we have xchat and > xchat-gnome in the same repo. Would it be that horrible if xchat fell > out of the repo? Uh, yes... ;-) I like the configurability of the regular X-Chat, xchat-gnome has been "gnomized" by removing much of that configurability and relegating parts to gconf (yuck!). As you can probably tell from the above paragraph, I'm a KDE user. :-) The reason I use X-Chat and not one of the KDE alternatives (Konversation, KSirc, KVirc or Kopete) is because of its C plugin interface. I'd be willing to take up comaintainership (or even maintainership if Chris wants to get rid of it completely) if nobody else wants it, though I want to give R?mi Collet a chance to pick it up first. Kevin Kofler From dimi at lattica.com Fri May 18 19:57:24 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 18 May 2007 15:57:24 -0400 (EDT) Subject: X-Chat in Fedora In-Reply-To: <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> Message-ID: <34813.142.205.241.254.1179518244.squirrel@lattica.com> > on a side note.... now that we are post merge we have xchat and > xchat-gnome in the same repo. Would it be that horrible if xchat fell > out of the repo? Is xchat-gnome upstream more responsive to patching? That would be sad AFAIAC: I've tried xchat-gnome and I must say that xchat is much nicer looking, etc. It's a better GNOME app than xchat-gnome! I don't think we should prefer the -gnome version just because it has the "gnome" in the name... -- Dimi Paun Lattica, Inc. From jspaleta at gmail.com Fri May 18 20:23:52 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 18 May 2007 12:23:52 -0800 Subject: X-Chat in Fedora In-Reply-To: <34813.142.205.241.254.1179518244.squirrel@lattica.com> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> <34813.142.205.241.254.1179518244.squirrel@lattica.com> Message-ID: <604aa7910705181323o76569b14sb1b0392849970ebd@mail.gmail.com> On 5/18/07, Dimi Paun wrote: > I don't think we should prefer the -gnome version just because it > has the "gnome" in the name... I was suggesting that perhaps the upstream developers were more willing to incorporate patches, since that is exactly the issue the current package maintainer cited as why he's lost interest in the package. And to be quite honest, that should be a big ass red flag for any potential new maintainer. If upstream isn't cooperating and integrating patchsets adequately from Fedora maintainers, I have to really question whether or not it makes sense to include that piece of software into fedora at all if there are multiple alternatives already in that application space. Featuresets are at best orthogonal to maintainability, and am not arguing for for or against any application here on the basis of featureset. But I will argue, passionately, to drop applications from the repository which are unnecessarily difficult to work when driving patchsets upstream. Caillon's comments suggest to me that maybe in this case it is....and if so we need to take a really hard look at whether or not xchat as a project is worth including compared to the 14 million other irc enabled alternatives in the tree. -jef From orion at cora.nwra.com Fri May 18 20:33:38 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 18 May 2007 14:33:38 -0600 Subject: Any way to search all .spec files? Message-ID: <464E0DA2.9020606@cora.nwra.com> Is there any was to do a grep/search on all of the Fedora .spec files for a specific release (or devel)? I'd be fine with checking them all out if there was a way to just the the spec files for a specific release. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From notting at redhat.com Fri May 18 20:32:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 May 2007 16:32:40 -0400 Subject: Any way to search all .spec files? In-Reply-To: <464E0DA2.9020606@cora.nwra.com> References: <464E0DA2.9020606@cora.nwra.com> Message-ID: <20070518203240.GA22150@nostromo.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > Is there any was to do a grep/search on all of the Fedora .spec files > for a specific release (or devel)? I'd be fine with checking them all > out if there was a way to just the the spec files for a specific release. You should be able to check out the FC-6 meta-module, for example. Not sure if one really works for devel/. Bill From jima at beer.tclug.org Fri May 18 20:38:26 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 18 May 2007 15:38:26 -0500 (CDT) Subject: Any way to search all .spec files? In-Reply-To: <20070518203240.GA22150@nostromo.devel.redhat.com> References: <464E0DA2.9020606@cora.nwra.com> <20070518203240.GA22150@nostromo.devel.redhat.com> Message-ID: On Fri, 18 May 2007, Bill Nottingham wrote: > You should be able to check out the FC-6 meta-module, for example. Not > sure if one really works for devel/. I swore I'd done that with devel/ before, so I tested it just now, and indeed: It does work. Jima From miles.lane at gmail.com Fri May 18 20:43:21 2007 From: miles.lane at gmail.com (Miles Lane) Date: Fri, 18 May 2007 13:43:21 -0700 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179399190.16432.64.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> <1179399190.16432.64.camel@localhost.localdomain> Message-ID: On 5/17/07, Richard Hughes wrote: > On Wed, 2007-05-16 at 11:01 -0700, Miles Lane wrote: > > > > So, as you can see, my system information should match the existing > > rule, but when I try to suspend, my video never comes back after > > resume. Evidently, the rule isn't being triggered. > > I think I've spotted a bug where there is some sort of race between the > dmi prober and the fdi cache reading. I'll debug it some more later > today. > > > One more observation. It would be very useful for you to include that > > command I used ("lshal | grep system.hardware.product") in your online > > documentation. > > Sure. I intend on doing a "explaining fdi matching" tutorial to explain > to mere mortals how to make the rules :-) Any progress on this? I am glad to send debugging info if you tell me how to gather it for you. Not matching systems correctly to rules seems like a pretty important problem to solve ASAP. Miles From orion at cora.nwra.com Fri May 18 20:44:39 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 18 May 2007 14:44:39 -0600 Subject: Any way to search all .spec files? In-Reply-To: References: <464E0DA2.9020606@cora.nwra.com> <20070518203240.GA22150@nostromo.devel.redhat.com> Message-ID: <464E1037.7000206@cora.nwra.com> Jima wrote: > On Fri, 18 May 2007, Bill Nottingham wrote: >> You should be able to check out the FC-6 meta-module, for example. Not >> sure if one really works for devel/. > > I swore I'd done that with devel/ before, so I tested it just now, and > indeed: It does work. > > Jima > It does indeed. Any way I can avoid pulling all of the .patch files? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From hughsient at gmail.com Fri May 18 23:03:52 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 19 May 2007 00:03:52 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <604aa7910705160942x64e073fbmc284d5423d40351f@mail.gmail.com> <1179336897.14246.66.camel@localhost.localdomain> <1179399190.16432.64.camel@localhost.localdomain> Message-ID: <1179529432.2516.1.camel@localhost.localdomain> On Fri, 2007-05-18 at 13:43 -0700, Miles Lane wrote: > > Sure. I intend on doing a "explaining fdi matching" tutorial to explain > > to mere mortals how to make the rules :-) > > Any progress on this? Nope, been out partying. :-) I'll crack on with this on Monday. > I am glad to send debugging info if you tell me > how to gather it for you. Not matching systems correctly to rules > seems like a pretty important problem to solve ASAP. Yes, indeed. I'll give you an email when I'm done, and you can tell me what you think. Richard. From kevin.kofler at chello.at Fri May 18 23:06:24 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 May 2007 23:06:24 +0000 (UTC) Subject: X-Chat in Fedora References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> <34813.142.205.241.254.1179518244.squirrel@lattica.com> <604aa7910705181323o76569b14sb1b0392849970ebd@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > And to be quite honest, that should be a big ass red flag for any > potential new maintainer. If upstream isn't cooperating and > integrating patchsets adequately from Fedora maintainers, I have to > really question whether or not it makes sense to include that piece of > software into fedora at all if there are multiple alternatives already > in that application space. Don't worry, I'm used to maintaining patchsets. Ever maintained a 317 KB GCC patchset? ;-) I do (look in TIGCC's CVS if you don't believe me), so the few patches X-Chat may need don't scare me in the least. Kevin Kofler From seg at haxxed.com Fri May 18 23:26:35 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 18 May 2007 18:26:35 -0500 Subject: X-Chat in Fedora In-Reply-To: <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> Message-ID: <1179530795.8263.4.camel@localhost> On Fri, 2007-05-18 at 11:35 -0800, Jeff Spaleta wrote: > On 5/18/07, Christopher Aillon wrote: > > Any one want to step to the plate? > > on a side note.... now that we are post merge we have xchat and > xchat-gnome in the same repo. Would it be that horrible if xchat fell > out of the repo? Is xchat-gnome upstream more responsive to patching? > > -jef"I'm an xchat user, but i no real reason to prefer xchat over > xchat-gnome or vice versa"spaleta xchat is some of the most astoundingly bad UI design I've ever seen. You have to manually type in a comma separated list of channels to autojoin? WTF. On the flip side, at least last I tried it, xchat-gnome lacked basic, vital functionality. Like autojoining channels. Or automatically identifying to nickserv. ... So now I use irssi. -------------- 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 markg85 at gmail.com Fri May 18 23:29:07 2007 From: markg85 at gmail.com (Mark) Date: Sat, 19 May 2007 01:29:07 +0200 Subject: Yum performance review In-Reply-To: <4649832D.30403@redhat.com> References: <4649832D.30403@redhat.com> Message-ID: <6e24a8e80705181629g4bc10784sb4f325e73840d4f2@mail.gmail.com> interesting timings.. specially interesting to see that pyrpm is alot faster than the yum for fc7 and the yum used in PRE fc7.. yum (pre fc7) vs yum fc7 doesn't realy seem to be much of a speed improvement.. some parts are faster but some parts are slower. funny to see how those 3 versions differ in speed i still thinks that a pure c or c++ implementation in combination with mysql will be the fastest.. downside of that is that python and the repository data itself will have to be rebuilded.. and RPM itself will most likely have to get some vital updates.. like bringing in logic in versioning. o well.. that will take time till it gets done i guess. 2007/5/15, Florian Festi : > > Hi! > > Yum traditionally used the rpmlib to resolve the dependecies of the > packages > being installed/removed/updated. This has always restricted yum to very > simple algorithms as the interface of the rpmlib doesn't allow much > control. > > The current yum - that will be shipped with F7 - has now replaced the > rpmlib > by a Python only resolver. I did some test runs to find out the current > state of development and to see if the new resolver is an improvement over > the rpmlib. > > The candidates: > =============== > > * yum-3.0.3 as used in FC6 > * yum from CVS head (2007/05/07), which is very similar to the yum in F7 > * pyrpmyum CVS head (2007/05/07) - a pure Python implementation developed > for testing purposed [1]. > > The test cases: > =============== > > Tests are based in FC-5 run on FC-6.x86_64. All operations are aborted by > "pressing n". > > Installs: > Try to install into an empty build root. There is a big number of excluded > pkgs to make the install '*' work. > * Normal install: several groups, 856 Pkgs > * Full install: "*", 6057 Pkgs > * Install "[a-k]*", 3052 Pkgs - needs to drag in a lot of > pkgs to satisfy dependencies > > Updates: > Before the Updates the "Normal Install" is run and the Pkgs are installed > into the build root. > * Empty update > * Update libgnome: 1 Pkg > * Big update: 346u+12i Pkgs > * Dist upgrade: Enable FC6 repos and do an upgrade; fails for both yum > versions,so don't take results too serious > > Erase: > * glibc: 828 Pkgs > > Warm ups: > Do a install '*'/upgrade to build the caches. Each program has different > issues with that. yum-3.0.3 needs to download the rpm headers (Test was > run > with repos in a NFS mount). All need to build the sqlite databases. > pyrpmyum > currently uses a Python only implementation that uses a lot of time. Warm > up > operations fail for all programs. > This all make the results of the warm ups a bit unreliable and > questionable. > They are included for completeness. > > Measured Values: > ================ > > All data is from just one test run - so don't expect too high precision. I > put 3 different test results into tables: > > * Real time passed during the test > * Heap peak - maximum of Memory used > * Heap total - amount of heap memory allocated > > The last one gives an idea of how much data has been moved around. > > Conclusions: > ============ > > Please read the data tables first to get your own impression. > > Memory usage: > > The new yum saves a lot of memory for big operations (about 50%). The > comparison to pyrpmyum shows that it is possible to save even more memory > and to drop memory usage below 100MB for all cases. In pyrpmyum this is > achieved with dynamic loading of rpm tags. Some are not even kept in the > pkgs but just cached in a least recently used list. > > For really small updates the old 3.0.3 yum wins. I guess this is because > it > does not do any obsolete handling. > > Runtime: > > Although the new yum save the very costly rpm header downloads (which take > nearly 3 minutes for the whole repository) it is still significantly > slower > for big operations. Things may look a bit different in real world > scenarios > where downloading the headers is even more expensive. > > Nevertheless the performance of the current yum is poor. Runtime behavior > has dropped from O(#prco * #rpmlib_calls) to O(#prco^2) (prco = Provides, > Requires, Conflicts, Obsoletes). The results of pyrpmyum show that is it > possible to do the depsolving in O(#prco) (Probably just O(#prco * log > #prco) but that doesn't matter much). > > There are already plans how to get rid of the quadratic behavior and I > hope > we can fix these issues before Fedora 8. > > Have fun > > Florian Festi > > [1] https://hosted.fedoraproject.org/projects/pyrpm > > > > Heap peak (MB) > > Operation | 3.0.3 | 05/07 | pyrpm > ------------------------------------------------ > Warmup: Full install | 475.3 | 226.6 | 128.6 > Resolve normal install | 94.6 | 74.1 | 27.0 > Resolve full install | 462.4 | 218.5 | 59.8 > Resolve install [a-k]* | 278.5 | 137.8 | 52.0 > Resolve empty update | 25.9 | 52.9 | 45.2 > Resolve update libgnome | 30.3 | 57.0 | 48.8 > Resolve big update | 112.5 | 108.2 | 60.3 > Resolve erase glibc | 210.0 | 99.8 | 39.6 > Warmup: Dist upgrade | 162.7 | 107.3 | 112.0 > Resolve dist upgrade | 162.4 | 107.3 | 62.9 > > > > > > Heap total (MB) > > This is the total amount of memory requested. > The amount of memory being allocated at one time > is much less! > > Operation | 3.0.3 | 05/07 | pyrpm > ----------------------------------------------- > Warmup: Full install | 20003 | 90859 | 10829 > Resolve normal install | 2088 | 9448 | 639 > Resolve full install | 15402 | 84951 | 4987 > Resolve install [a-k]* | 17542 | 24805 | 4121 > Resolve empty update | 167 | 80 | 747 > Resolve update libgnome | 282 | 136 | 1247 > Resolve big update | 3497 | 2699 | 2574 > Resolve erase glibc | 1732 | 2192 | 3369 > Warmup: Dist upgrade | 6203 | 2644 | 7395 > Resolve dist upgrade | 5869 | 2644 | 2154 > > > > > > Real time (s) > > Operation | 3.0.3 | 07/05/07| pyrpm > ---------------------------------------------------- > Warmup: Full install | 653.51 | 1064.35 | 147.23 > Resolve normal install | 40.59 | 134.11 | 8.04 > Resolve full install | 477.67 | 1093.57 | 51.01 > Resolve install [a-k]* | 313.56 | 887.40 | 33.52 > Resolve empty update | 6.91 | 6.57 | 13.36 > Resolve update libgnome | 3.34 | 2.57 | 7.51 > Resolve big update | 33.04 | 45.56 | 24.81 > Resolve erase glibc | 29.83 | 37.72 | 30.95 > Warmup: Dist upgrade | 81.42 | 40.67 | 108.50 > Resolve dist upgrade | 52.07 | 40.29 | 27.20 > > > > -- > 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 bpepple at fedoraproject.org Fri May 18 23:34:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 18 May 2007 19:34:32 -0400 Subject: X-Chat in Fedora In-Reply-To: <1179530795.8263.4.camel@localhost> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> <1179530795.8263.4.camel@localhost> Message-ID: <1179531272.5876.12.camel@lincoln> On Fri, 2007-05-18 at 18:26 -0500, Callum Lerwick wrote: > On Fri, 2007-05-18 at 11:35 -0800, Jeff Spaleta wrote: > > On 5/18/07, Christopher Aillon wrote: > > > Any one want to step to the plate? > > > > on a side note.... now that we are post merge we have xchat and > > xchat-gnome in the same repo. Would it be that horrible if xchat fell > > out of the repo? Is xchat-gnome upstream more responsive to patching? > > > > -jef"I'm an xchat user, but i no real reason to prefer xchat over > > xchat-gnome or vice versa"spaleta > > xchat is some of the most astoundingly bad UI design I've ever seen. You > have to manually type in a comma separated list of channels to autojoin? > WTF. On the flip side, at least last I tried it, xchat-gnome lacked > basic, vital functionality. Like autojoining channels. Or automatically > identifying to nickserv. Ummm, those functions have always been available in xchat-gnome. Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dyoung at mesd.k12.or.us Fri May 18 23:35:27 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Fri, 18 May 2007 16:35:27 -0700 Subject: X-Chat in Fedora In-Reply-To: <1179530795.8263.4.camel@localhost> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> <1179530795.8263.4.camel@localhost> Message-ID: <464E383F.6040503@mesd.k12.or.us> Callum Lerwick wrote: > On the flip side, at least last I tried it, xchat-gnome lacked basic, > vital functionality. Like autojoining channels. Or automatically > identifying to nickserv. Set a nickserv password: Edit -> Preferences Networks -> Edit Users and Channels Add Enter -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From dmalcolm at redhat.com Fri May 18 23:48:57 2007 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 18 May 2007 19:48:57 -0400 Subject: X-Chat in Fedora In-Reply-To: <464E383F.6040503@mesd.k12.or.us> References: <464DF979.9060607@redhat.com> <604aa7910705181235ib6ef659hb1bbf358522c0346@mail.gmail.com> <1179530795.8263.4.camel@localhost> <464E383F.6040503@mesd.k12.or.us> Message-ID: <1179532137.5887.11.camel@cassandra.boston.redhat.com> On Fri, 2007-05-18 at 16:35 -0700, Dan Young wrote: > Callum Lerwick wrote: > > On the flip side, at least last I tried it, xchat-gnome lacked basic, > > vital functionality. Like autojoining channels. Or automatically > > identifying to nickserv. > [snip] > Autojoin channels: > Edit -> Preferences > Networks >